Open Stack

On Mon, Aug 17, 2015 at 01:22:28PM -0600, Chris Friesen wrote:
> 
> I tried bringing this up on the irc channel, but nobody took the bait.
> Hopefully this will generate some discussion.
> 
> I just filed bug 1485631.  Nikola suggested one way of handling it, but
> there are some complications that I thought I should highlight so we're all
> on the same page.
> 
> The basic question is, if a host has X CPUs in total for VMs, and a single
> instance wants X+1 vCPUs, should we allow it?  (Regardless of overcommit
> ratio.)  There is also an equivalent question for RAM.
> 
> Currently we have two different answers depending on whether numa topology
> is involved or not.  Should we change one of them to make it consistent with
> the other?  If so, a) which one should we change, and b) how would we do
> that given that it results in a user-visible behaviour change?  (Maybe a
> microversion, even though the actual API doesn't change, just whether the
> request passes the scheduler filter or not?)

I agree with Nikola, that the NUMA impl is the correct one. The existance
of overcommit is motivated by the idea that most users will not in fact
consume all the resources allocated to their VM all of the time and thus
on average you don't need to reserve 100% of resources for every single VM.
Users will usually be able to burst upto 100% of their allocation when
needed, if some portion of other users are mostly inactive.

If you allow a single VM to overcommit against itself though, this breaks
down. It is never possible for their single VM to burst to consume 100%
of the resources allocated to it, since the host if physically incapable
of providing that much resource.

On that basis, I think the correct behaviour is to consider overcommit
to be a factor that applies across a set of VMs only. Never allow a
single VM to overcommit against itself. Which is what the NUMA code
in libvirt currently implements. I think we should align the non-NUMA
codepath with this too.

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 :|