Open Stack

I agree with the rationale here, and will be reviewing
https://review.openstack.org/#/c/215764/ accordingly.

Michael

On Mon, Aug 24, 2015 at 7:56 PM, Daniel P. Berrange <berrange at redhat.com>
wrote:

> 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
> :|
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150825/e14a8379/attachment.html>