[libvirt] PATCH: Be more flexible in emulator choice on x86 archs

[Daniel Veillard]

On Mon, Mar 16, 2009 at 06:03:59PM +0000, Daniel P. Berrange wrote:
> Currently we are pretty strict about what emulator binary we allow for
> QEMU guests on x86 arches. In particular, for arch+domain type combos:
> 
>  - i686+qemu must use 'qemu' binary
>  - x86_64+qemu must use 'qemu-system-x86_64' binary
>  - kvm must use 'qemu-kvm' or 'kvm' binaries
>  - i686+kvm on x86_64 host is not allowed
> 
> These restrictions are overkill because
> 
>  - i686+qemu could use 'qemu-system-x86_64' if '-cpu qemu32' is added
>  - i686+qemu could use 'qemu-kvm' if '-cpu qemu32 -no-kvm' is added
>  - x86_64+qemu could use 'qemu-kvm' if '-no-kvm' is added
>  - i686+kvm on x86_64 host can be used if '-cpu qemu32' is added
> 
> This patch makes QEMU driver more flexible in this way when setting up
> its capabilities information. It also makes it aware of the -no-kvm
> and -cpu flag, using them where required by the os type + arch + emulator
> combinations specified in the guest XML.
> 
> This should finally remove the confusion where a user in virt-manager
> selectrs 'i686' and then wonders why we've disallowed choice of 'kvm'.
> It also fixes 'virsh version' when only qemu-kvm is installed.
> 
> The matrix should now work thus:
> 
> 1. qemu, qemu-system-x86_64, qemu-kvm all available
> 
>      qemu+i686   => qemu
>      qemu+x86_64 => qemu-system-x86_64
>      kvm+i686    => qemu-kvm -cpu qemu32
>      kvm+x86_64  => qemu-kvm
> 
> 2. qemu, qemu-kvm available
> 
>      qemu+i686   => qemu
>      qemu+x86_64 => qemu-kvm -no-kvm
>      kvm+i686    => qemu-kvm -cpu qemu32
>      kvm+x86_64  => qemu-kvm
> 
> 3. qemu-system-x86_64, qemu-kvm available
> 
>      qemu+i686   => qemu-system-x86_64 -cpu qemu32
>      qemu+x86_64 => qemu-system-x86_64
>      kvm+i686    => qemu-kvm -cpu qemu32
>      kvm+x86_64  => qemu-kvm
> 
> 4. qemu-kvm available
> 
>      qemu+i686   => qemu-kvm -no-kvm -cpu qemu32
>      qemu+x86_64 => qemu-kvm -no-kvm
>      kvm+i686    => qemu-kvm -cpu qemu32
>      kvm+x86_64  => qemu-kvm
> 
> 
> The only real remaining problem is that we don't cope with scenario
> where the KVM enabled binary is called 'qemu-system-x64_64' instead
> of 'qemu-kvm' or 'kvm'.

  The confusion around this deserve a patch, and that sounds one way
to get this solved ... but I find the approach "here is a hard coded
path", then "oh we finally need to add a second hardcoded path" a bit
worrying. This also doesn't cope with the occasional troubles where
people have a binary outside of /usr/bin. Maybe some of this logic could
be reduced and relying on configuration data would allow a fully
flexible system (where the user can bite himself too, but heh), by
suggesting architecture emulation binary names (with the above as
the default) and a separate path list to lookup those binaries.
Or we could just allow symlinks to be set in /usr/local/bin
pointing to whatever the binaries names may be on that system or
something approaching.

  But ACK, as is this solves the problem,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/