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 <berra...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
