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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org