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