<div dir="ltr">I agree with the rationale here, and will be reviewing <a href="https://review.openstack.org/#/c/215764/">https://review.openstack.org/#/c/215764/</a> accordingly.<div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 7:56 PM, 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"><span class="">On Mon, Aug 17, 2015 at 01:22:28PM -0600, Chris Friesen wrote:<br>
><br>
> I tried bringing this up on the irc channel, but nobody took the bait.<br>
> Hopefully this will generate some discussion.<br>
><br>
> I just filed bug 1485631.  Nikola suggested one way of handling it, but<br>
> there are some complications that I thought I should highlight so we're all<br>
> on the same page.<br>
><br>
> The basic question is, if a host has X CPUs in total for VMs, and a single<br>
> instance wants X+1 vCPUs, should we allow it?  (Regardless of overcommit<br>
> ratio.)  There is also an equivalent question for RAM.<br>
><br>
> Currently we have two different answers depending on whether numa topology<br>
> is involved or not.  Should we change one of them to make it consistent with<br>
> the other?  If so, a) which one should we change, and b) how would we do<br>
> that given that it results in a user-visible behaviour change?  (Maybe a<br>
> microversion, even though the actual API doesn't change, just whether the<br>
> request passes the scheduler filter or not?)<br>
<br>
</span>I agree with Nikola, that the NUMA impl is the correct one. The existance<br>
of overcommit is motivated by the idea that most users will not in fact<br>
consume all the resources allocated to their VM all of the time and thus<br>
on average you don't need to reserve 100% of resources for every single VM.<br>
Users will usually be able to burst upto 100% of their allocation when<br>
needed, if some portion of other users are mostly inactive.<br>
<br>
If you allow a single VM to overcommit against itself though, this breaks<br>
down. It is never possible for their single VM to burst to consume 100%<br>
of the resources allocated to it, since the host if physically incapable<br>
of providing that much resource.<br>
<br>
On that basis, I think the correct behaviour is to consider overcommit<br>
to be a factor that applies across a set of VMs only. Never allow a<br>
single VM to overcommit against itself. Which is what the NUMA code<br>
in libvirt currently implements. I think we should align the non-NUMA<br>
codepath with this too.<br>
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><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>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Rackspace Australia</div>
</div>