Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...'

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, May 14, 2010 at 08:24:09AM -0500, Anthony Liguori wrote:
> On 05/13/2010 08:07 AM, Jes Sorensen wrote:
> >On 05/13/10 15:04, Cole Robinson wrote:
> >   
> >>On 05/13/2010 04:35 AM, Jes Sorensen wrote:
> >>     
> >>>On 05/12/10 22:48, Cole Robinson wrote:
> >>>I think rather than 1, it would be better to add a patch to libvirt to
> >>>catch both formats. I know Chris Lalancette already cooked up a patch
> >>>for this. Combined with the 2) patch I just posted, and 3) I think that
> >>>should take care of the problems.
> >>>       
> >>It doesn't solve the problem for existing libvirt installations. It's
> >>not uncommon for users to track just the latest kvm releases without
> >>upgrading libvirt: any future qemu or kvm release will break every
> >>version of libvirt that exists today. Given that unfortunate case, I
> >>still recommend reverting the 'PC' change at least for long enough for a
> >>few fixed libvirt releases to make it into the wild.
> >>     
> >But that is no different from what we have today. Users who update their
> >qemu and see issues with libvirt can also be asked to update libvirt. I
> >have already had several cases where I needed to do that anyway.
> >
> >I don't like reverting a change like this, just to schedule it to be
> >reapplied again later.
> >   
> 
> The problem is, we've been down this road many times before.  Every 
> time, the libvirt folks say they just need this one change for 
> compatibility and keep on using the help output.  I understand that 
> that's the easiest thing to do so we need to make it easier for them to 
> do the right thing (which probably means making it harder to do the 
> wrong thing :-)).
> 
> So I'm willing to apply this patch but only as part of a larger series 
> that eliminates the need for libvirt to parse help output.  The 
> important question is then, what information is libvirt getting from the 
> help output today.

The short answer is we extract:

 - QEMU version number
 - KVM version number (if present)
 - Probe for specific named arguments (-drive, -chardev, -device, 
   and many many more)
 - Probe for named flags (eg cache= option to -drive which appeared
   after the initial -drive arg did)

Things we use the QEMU/KVM version number for:

 - Track changes in syntax of an existing arg. eg -vnc changed
   syntax between 0.8.x and 0.9.0
 - Determine if we can use VNET_HDR flag
 - Which migration protocols are available (tcp, unix, exec, fd)
 - Whether we can use JSON mode monitor yet
 - Override use of -netdev - even though its detected in -help
   output for 0.12, we can't use it since there was no equivalent
   netdev_add command for hotplug. So we have to blacklist it till
   0.13

In the ideal world we'd never do anything based off version number,
everything would have some clear functional capability that could
be queried. We'd then only need to use version to blacklist features
we detect, but can't use for some reason.

If you want the gory details, the key method is qemudComputeCmdFlag()
in source code at line 1124:

  http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_conf.c;h=5fa8c0aa1867e1f67153d72c5b37ba09157c968e;hb=HEAD

This is where we detect each feature we care about in -help output


Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|