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

[Daniel P. Berrange]

On Fri, Mar 20, 2009 at 11:57:24AM +0100, Daniel Veillard wrote:
> 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.

I agree, this approach we're currently using has pretty much reached
the end of its practicality. In particular it is impossible to solve
the problem of figuring out whether a plain 'qemu' binary supports
kvm natively. To adress that, we'd actually need to run the binary
and probe its output. This would require pretty much re-writing this
entire capabilities setup logic from scratch. Similarly coping with
varying path locations is another problem we can't easily solve with
this current code.  

To address this I think we'd need to completely change the logic to
do something like

 - For each directory in $PATH
     For each emulator name in (qemu, qemu-system-x864, etc)
        If emulator exists
           run  $emulator -help

So this lets us build up a list of all available emulators and their
capabilities (eg, whether each supports qemu, kqemu, kvm).

>From that list, we can then populate the list of supported combinations
of guest, arch, domain type. 

If we honour $PATH, then it probably wouldn't be neccessary to add
config params for it.

>   But ACK, as is this solves the problem,

Ok, will commit it shortly.

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