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
signature.asc
Description: OpenPGP digital signature
