[Openstack-operators] Fwd: [openstack-dev] [nova] should we allow overcommit for a single VM?

Steve Gordon sgordon at redhat.com
Tue Aug 18 17:22:18 UTC 2015

Forwarding to openstack-operators as I think some operator feedback on expectations here would be useful.

----- Forwarded Message -----
> From: "Chris Friesen" <chris.friesen at windriver.com>
> To: openstack-dev at lists.openstack.org
> Sent: Tuesday, August 18, 2015 7:34:11 AM
> Subject: Re: [openstack-dev] [nova] should we allow overcommit for a single VM?
> On 08/18/2015 06:56 AM, Nikola Đipanov wrote:
> > On 08/17/2015 08:22 PM, Chris Friesen wrote:
> >> 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 would say that the "correct" behavior is what NUMA fitting logic does,
> > and that is to not allow instance to over-commit against itself, and we
> > should fix "normal" (non-NUMA) over-commit. Allowing the instance to
> > over-commit against itself does not make a lot of sense, however it is
> > not something that is likely to happen that often in real world usage -
> > I would imagine operators are unlikely to create flavors larger than
> > compute hosts.
> This is a good point, in any "real" deployment it likely won't be an issue.
> We
> only ran into it because we were testing on a minimal-sized compute node
> running
> in a VM on a designer box.
> > I am not sure that this has anything to do with the API thought. This is
> > mostly a Nova internal implementation detail. Any nova deployment can
> > fail to boot an instance for any number of reasons, and this does not
> > affect the API response of the actual boot request.
> Arguably it would be changing the behaviour of a boot request.  Currently it
> would pass the scheduler and boot up, and we're talking about making it fail
> the
> scheduler filter.  That's an externally-visible change in behaviour.  (But as
> you say it's unlikely that it will be hit in the real world.)
> Chris
> __________________________________________________________________________
> 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

Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

More information about the OpenStack-operators mailing list