On Wed, 06/04 20:55, Eric Blake wrote: > 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. >
Thanks, I'll keep in mind the feature probing necessity in the future. Fam