On Tue, Oct 02, 2012 at 09:46:12AM +0200, Markus Armbruster wrote: > "Daniel P. Berrange" <berrange@xxxxxxxxxx> writes: > > > On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas Färber wrote: > >> Hello Jan, > >> > >> Am 01.10.2012 16:34, schrieb Jan Kiszka: > >> > If we built a target for a host that supports KVM in principle, set the > >> > default accelerator to KVM as well. This also means the start of QEMU > >> > will fail to start if KVM support turns out to be unavailable at > >> > runtime. > >> > >> From a distro point of view this of course means that we will build > >> against KVM and that the new KVM default will start to fail for users on > >> very old hardware. Can't we do a runtime check to select the default? > > > > NB, this is *not* only about old hardware. There are plenty of users who > > use QEMU inside VMs. One very common usage I know of is image building > > tools which are run inside Amazon VMs, using libguestfs & QEMU. > > > > IMHO, default to KVM, fallback to TCG is the most friendly default > > behaviour. > > Friendly perhaps, generating an infinite series of questions "why is my > guest slow as molasses?" certainly. > > And for each instance of the question, there's an unknown number of > users who give QEMU a quick try, screw up KVM unknowingly, observe the > glacial speed, and conclude it's crap. > That's why it should not fallback silently to TCG, but warn the user about that. On the other hand, on a machine without KVM support (which might just be because of local policy admin policy which doesn't provide access the /dev/kvm, nested virtualization, etc.), if QEMU fails to start (while previous versions were working), the user can conclude that QEMU is crap. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@xxxxxxxxxxx http://www.aurel32.net -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
