Re: [Qemu-devel] active block commit bug?

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

On 06/04/2014 08:09 PM, Fam Zheng wrote:

>> Sounds like we have an off-by-one condition if empty files behave
>> differently from other files.  We ought to fix that bug (not that your
>> normal guest will ever have a 0-length backing file, but this was what I
>> was trying to use for libvirt's probing of whether active commit is
>> supported)
>>
> 
> Yes, agreed, this special case is only going to make management confused. I
> will send a patch to fix this.

Thanks.

> 
> Eric, is this a good way to probe the active commit? I was expecting full
> instrospection of QMP could do it, but I don't know about the status of that
> piece of work. Amos, any ideas?

Introspection already missed qemu 2.0 when active commit was added; and
we're close enough to soft freeze for 2.1 that I'm guessing it will miss
2.1 as well :(

So yes, I'm experimenting with how to learn if active commit works by
seeing what error message differences I can trigger with minimum effort;
libvirt will cache what it learns so that it only has to ask once per
qemu binary/timestamp, then let the user know up front whether active
commit will work.  Since there are existing qemu versions that have
active commit but not introspection, I'm stuck using this harder probe
to avoid a false negative for those older qemu.  My other option is to
just wait for introspection, or even something intermediate like Jeff's
patch to make 'top' optional, and just declare qemu 2.0 active commit as
not working - but since it is only the special case of a 0-size file
(which is fairly unlikely for any real client use, and certainly
something I can avoid in the libvirt probing), it feels a bit harsh to
reject 2.0 just for this corner-case bug.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]