[Openstack-operators] User Survey usage of QEMU (as opposed to KVM) ?

Sergio Cuellar Valdes scuellarv at kionetworks.com
Tue May 3 19:27:00 UTC 2016

On 3 May 2016 at 10:01, Daniel P. Berrange <berrange at redhat.com> wrote:

> Hello Operators,
> One of the things that constantly puzzles me when reading the user
> survey results wrt hypervisor is the high number of respondants
> claiming to be using QEMU (as distinct from KVM).
> As a reminder, in Nova saying virt_type=qemu causes Nova to use
> plain QEMU with pure CPU emulation which is many many times slower
> to than native CPU performance, while virt_type=kvm causes Nova to
> use QEMU with KVM hardware CPU acceleration which is close to native
> performance.
> IOW, virt_type=qemu is not something you'd ever really want to use
> unless you had no other options due to the terrible performance it
> would show. The only reasons to use QEMU are if you need non-native
> architecture support (ie running arm/ppc on x86_64 host), or if you
> can't do KVM due to hardware restrictions (ie ancient hardware, or
> running compute hosts inside virtual machines)
> Despite this, in the 2016 survey 10% claimed to be using QEMU in
> production & 3% in PoC and dev, in 2014 it was even higher at 15%
> in prod & 12% in PoC and 28% in dev.
> Personally my gut feeling says that QEMU usage ought to be in very
> low single figures, so I'm curious as to the apparent anomoly.
> I can think of a few reasons
>  1. Respondants are confused as to the difference between QEMU
>     and KVM, so are saying QEMU, despite fact they are using KVM.
>  2. Respondants are confused as to the difference between QEMU
>     and KVM, so have mistakenly configured their nova hosts to
>     use QEMU instead of KVM and suffering poor performance without
>     realizing their mistake.
>  3. There are more people than I expect who are running their
>     cloud compute hosts inside virtual machines, and thus are
>     unable to use KVM.
>  4. There are more people than I expect who are providing cloud
>     hosting for non-native architectures. eg ability to run an
>     arm7/ppc guest image on an x86_64 host and so genuinely must
>     use QEMU
> If items 1 / 2 are the cause, then by implication the user survey
> is likely under-reporting the (already huge) scale of the KVM usage.
> I can see 3. being a likely explanation for high usage of QEMU in a
> dev or PoC scenario, but it feels unlikely for a production deployment.
> While 4 is technically possible, Nova doesn't really do a very good
> job at mixed guest arch hosting - I'm pretty sure there are broken
> pieces waiting to bite people who try it.
> Does anyone have any thoughts on this topic ?
> Indeed, is there anyone here who genuinely use virt_type=qemu in a
> production deployment of OpenStack who might have other reasons that
> I've missed ?
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc
> :|
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

​Hi everybody,

I'm confused too about the use of KVM or QEMU In the computes the
file​/etc/nova/nova-compute.conf has:


The output of:

nova hypervisor-show <id> | grep hypervisor_type


hypervisor_type           | QEMU

The virsh dumpxml of the instances shows:

<domain type='kvm' id='44'>

​But according to ​this document [1], it is using QEMU emulator instead of
KVM, because it is not using /usr/bin/qemu-kvm

So I really don't know if it's using KVM or QEMU.

[1] https://libvirt.org/drvqemu.html

Sergio Cuéllar​

* Sergio Cuéllar │DevOps Engineer*
 Mexico City Phone (52) 55 8503 2600 ext. 4335
 Mobile: 5544844298
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160503/fef034f5/attachment-0001.html>

More information about the OpenStack-operators mailing list