Re: [libvirt] PATCH: Be more flexible in emulator choice on x86 archs

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.

From that list, we can then populate the list of supported combinations

But ACK, as is this solves the problem,