Re: [Qemu-devel] [PATCH] kvm: Set default accelerator to "kvm" if the host supports it

[Aurelien Jarno]

On Tue, Oct 02, 2012 at 09:46:12AM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" <address@hidden> 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
address@hidden                 http://www.aurel32.net