* Re: [Qemu-devel] [libvirt] [PATCH] qemu: Adjust size for qcow2/qed if not on sector boundary
2014-04-08 16:45 ` [Qemu-devel] [libvirt] [PATCH] qemu: Adjust size for qcow2/qed if not on sector boundary Eric Blake
@ 2014-04-08 18:02 ` John Ferlan
0 siblings, 0 replies; 2+ messages in thread
From: John Ferlan @ 2014-04-08 18:02 UTC (permalink / raw)
To: Eric Blake, libvir-list, qemu-devel@nongnu.org
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
^ permalink raw reply [flat|nested] 2+ messages in thread