-
Bug
-
Resolution: Done-Errata
-
None
-
Quality / Stability / Reliability
-
0.42
-
False
-
False
-
CLOSED
-
Undefined
-
Storage Core Sprint 205, Storage Core Sprint 206
-
Critical
-
No
Description of problem:
I think this is a bug so raising one with what we have, as the customer has not replied with additional info we requested for troubleshooting.
The customer is using IBM Spectrum Scale Storage, with 1MiB block size.
If they create a new disk and attach to a VM using that storage, it fails to start because its not aligned.
{"component":"virt-launcher","level":"error","msg":"internal error: qemu unexpectedly closed the monitor: 2021-06-15T15:16:06.788431Z qemu-kvm: -device virtio-blk-pci-non-transitional,bus=pci.6,addr=0x0,drive=li bvirt-1-format,id=ua-disk-0,write-cache=on: Cannot get 'write' permission without 'resize': Image size is not a multiple of request alignment","pos":"qemuProcessReportLogError:2111","subcomponent":"libvirt","thread":"290","timestamp":"2021-06-15T15:16:06.811000Z"}Here: https://github.com/qemu/qemu/blob/8e6dad2028d01b7f9ec76cf3b83457fab57fa1eb/block.c#L2309
Our current theory is the "fs overhead" doing a round down based on a hardcoded block size (512), here:
https://github.com/kubevirt/containerized-data-importer/blob/2014ddecfd39ba69fe75970ce613f31c32d2b182/pkg/importer/data-processor.go#L364
So it reduces the size by the overhead % and then rounds it down to 512 block size multiple. This may fail to set the file size correctly if the block size is not 512. The customer on this case was 1MiB.
How reproducible:
Unknown (I tried on NFS but it worked, not the right scenario though)