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 :|