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)
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