On 05/24/2011 03:42 AM, Neil Wilson wrote:
On Tue, 2011-05-24 at 10:37 +0100, Daniel P. Berrange wrote:
> Use the libvirt that ships with RHEL6, or apply the RHEL6 specific
> patches manually when building an alternative libvirt for RHEL6.
> It isn't sustainable for upstream projects to deal with hacks for
> every crazy non-upstream change that distros make. If distros choose
> to change things in ways that diverge from upstream behaviour, then
> it is their job to maintain the fixes for other code which breaks
> as a result.
>
That still doesn't explain why the libvirt test system is checking the
'non-standard' versions of RHEL6 qemu then.
If something is directly observable in -help output, then we can key off
of it. But keying off of -spice in order to detect whether -netdev
works seems fishy - you should key off of direct features, rather than
special-casing knowledge that one orthogonal feature "implies" another.
Ultimately, the nicest fix might be to use the 'help' monitor command to
probe exactly which other monitor commands are available, to learn
whether the monitor supports netdev_add. But how do you probe the
monitor commands until you already started the qemu command line with
-netdev already in the command line? Another possible fix would be to
have some way for 'qemu -help' to output the list of supported monitor
commands, then get that backported into RHEL qemu. But right now, Dan's
advice of using the RHEL-specific libvirt patches when building libvirt
on RHEL, if you want to take full advantage of RHEL qemu, makes the most
sense to me.
Meanwhile, as to your question about the libvirt testsuit including RHEL
qemu -help output: that merely proves that libvirt is properly parsing
the available -help output, and not that libvirt is inferring any
special properties of RHEL qemu that were not directly advertised in -help.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org