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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/