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

Matt Jarvis matt.jarvis at datacentred.co.uk
Tue May 3 15:43:29 UTC 2016


I would suspect that quite a lot fall into 1

On 3 May 2016 at 16:33, David Medberry <openstack at medberry.net> wrote:

> The only reason I can think of is that they are doing nested VMs and don't
> have the right nesting flag enabled in their base flag.
>
> On Tue, May 3, 2016 at 9:01 AM, 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
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

-- 
DataCentred Limited registered in England and Wales no. 05611763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160503/4f803d03/attachment.html>


More information about the OpenStack-operators mailing list