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