On 04/08/2014 12:45 PM, Eric Blake wrote: > On 04/08/2014 10:26 AM, John Ferlan wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1002813 >> >> If qemuDomainBlockResize() is passed a size not on a KiB boundary - that >> is passed a size based in bytes (VIR_DOMAIN_BLOCK_RESIZE_BYTES), then >> depending on the source format (qcow2 or qed), the value passed must >> be on a sector (or 512 byte) boundary. Since other libvirt code quietly >> adjusts the capacity values, then do so here as well - of course ensuring >> that adjustment still fits. > > qed may require aligned multiples for size, but I thought that qcow2 can > support an unaligned size (uncommon, but not technically impossible) - > after all, the 'size' field in the qcow2 header (bytes 24-31) is an > 8-byte value in bytes, not a count of sectors. Maybe we should try the > user's size, and only then fall back to a rounded up alignment if the > unaligned size fails. > > Hmm, now that I've experimented a bit: > > $ qemu-img create -f qcow2 img 12345 > Formatting 'img', fmt=qcow2 size=12345 encryption=off cluster_size=65536 > lazy_refcounts=off > $ qemu-img info img > image: img > file format: qcow2 > virtual size: 12K (12288 bytes) > disk size: 196K > cluster_size: 65536 > Format specific information: > compat: 1.1 > lazy refcounts: false > > Wait a second - qemu-img rounded DOWN. That's wrong - it allocated less > bytes than I requested. I think we need to first figure out what's > going on with the qemu side, on whether qemu should be supporting > unaligned requestes, before trying to paper around it in libvirt. > According to the bug report qemu requires multiples of sector size for the size value. Furthermore there's other places in the libvirt code where we adjust a provided value - virStorageBackendCreateQemuImgCmd() for example. So regardless of what qemu-img does with 12345 - we've already set the precedent of rounding up on the size (cscope VIR_DIV_UP). I'm OK with truncating or even returning an error, but I was following what Dan said in the case (comment 4): "Whenever QEMU has granularity constraints, libvirt ought to be rounding up the user value to nearest acceptable boundary for QEMU. We do this in many other places, so just need to figure out where todo it for this case." I did test volumes created as 5K on/for a guest and then attempt to change to 10K. Adding the volumes is no problem (I used qemu-img -f {qcow2|qed} disk-5k-{qcow2|qed}). Once attached to the running guest, a blockresize using 10K failed before my change and succeeded afterwards. I checked inside the guest /proc/partitions to see that the sizes changed. Prior to the change the volumes were 5120 bytes and after 10240. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list