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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list