From: John Ferlan <jferlan@redhat.com>
To: Eric Blake <eblake@redhat.com>,
libvir-list@redhat.com,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] [PATCH] qemu: Adjust size for qcow2/qed if not on sector boundary
Date: Tue, 08 Apr 2014 14:02:37 -0400 [thread overview]
Message-ID: <534439BD.6000403@redhat.com> (raw)
In-Reply-To: <534427C6.7090101@redhat.com>
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
prev parent reply other threads:[~2014-04-08 18:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1396974411-18051-1-git-send-email-jferlan@redhat.com>
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534439BD.6000403@redhat.com \
--to=jferlan@redhat.com \
--cc=eblake@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).