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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list