<div dir="ltr">I would suspect that quite a lot fall into 1</div><div class="gmail_extra"><br><div class="gmail_quote">On 3 May 2016 at 16:33, David Medberry <span dir="ltr"><<a href="mailto:openstack@medberry.net" target="_blank">openstack@medberry.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 9:01 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Operators,<br>
<br>
One of the things that constantly puzzles me when reading the user<br>
survey results wrt hypervisor is the high number of respondants<br>
claiming to be using QEMU (as distinct from KVM).<br>
<br>
As a reminder, in Nova saying virt_type=qemu causes Nova to use<br>
plain QEMU with pure CPU emulation which is many many times slower<br>
to than native CPU performance, while virt_type=kvm causes Nova to<br>
use QEMU with KVM hardware CPU acceleration which is close to native<br>
performance.<br>
<br>
IOW, virt_type=qemu is not something you'd ever really want to use<br>
unless you had no other options due to the terrible performance it<br>
would show. The only reasons to use QEMU are if you need non-native<br>
architecture support (ie running arm/ppc on x86_64 host), or if you<br>
can't do KVM due to hardware restrictions (ie ancient hardware, or<br>
running compute hosts inside virtual machines)<br>
<br>
Despite this, in the 2016 survey 10% claimed to be using QEMU in<br>
production & 3% in PoC and dev, in 2014 it was even higher at 15%<br>
in prod & 12% in PoC and 28% in dev.<br>
<br>
Personally my gut feeling says that QEMU usage ought to be in very<br>
low single figures, so I'm curious as to the apparent anomoly.<br>
<br>
I can think of a few reasons<br>
<br>
1. Respondants are confused as to the difference between QEMU<br>
and KVM, so are saying QEMU, despite fact they are using KVM.<br>
<br>
2. Respondants are confused as to the difference between QEMU<br>
and KVM, so have mistakenly configured their nova hosts to<br>
use QEMU instead of KVM and suffering poor performance without<br>
realizing their mistake.<br>
<br>
3. There are more people than I expect who are running their<br>
cloud compute hosts inside virtual machines, and thus are<br>
unable to use KVM.<br>
<br>
4. There are more people than I expect who are providing cloud<br>
hosting for non-native architectures. eg ability to run an<br>
arm7/ppc guest image on an x86_64 host and so genuinely must<br>
use QEMU<br>
<br>
If items 1 / 2 are the cause, then by implication the user survey<br>
is likely under-reporting the (already huge) scale of the KVM usage.<br>
<br>
I can see 3. being a likely explanation for high usage of QEMU in a<br>
dev or PoC scenario, but it feels unlikely for a production deployment.<br>
<br>
While 4 is technically possible, Nova doesn't really do a very good<br>
job at mixed guest arch hosting - I'm pretty sure there are broken<br>
pieces waiting to bite people who try it.<br>
<br>
Does anyone have any thoughts on this topic ?<br>
<br>
Indeed, is there anyone here who genuinely use virt_type=qemu in a<br>
production deployment of OpenStack who might have other reasons that<br>
I've missed ?<br>
<br>
Regards,<br>
Daniel<br>
<span><font color="#888888">--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div>
<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">DataCentred Limited registered in England and Wales no. 05611763</span>