[openstack-dev] CPU reservation/entitlement in Nova

heut2008 heut2008 at gmail.com
Mon Jan 14 06:42:35 UTC 2013

There is already a similar blueprint about limit instance resource usage

my option is expose the cpu_share and cpu_period to user ,so it can be more
flexable to implement variable policy.
this BP contains cpu and block IO usage control through cgroup and
 bandwidth control through traffic control.

2013/1/14 Alex Glikson <GLIKSON at il.ibm.com>

> Dear all,
> We have started working on implementation of CPU reservation/entitlement
> mechanism in Nova (
> https://blueprints.launchpad.net/nova/+spec/cpu-entitlement).
> The idea is to allow associating explicit CPU allocation guarantees, in a
> more flexible way than it is done today in CoreFilter -- the user/admin
> will be able to define different CPU allocation guarantees for different
> instances. The approach we are taking is to use extra_specs of instance
> types to indicate the desired level of CPU allocation guarantees per vCPU
> (e.g., low=25% of a physical CPU, normal=50%, high=100%), which would apply
> to all instances created from the corresponding type. This fits nicely the
> resource model of most of the hypervisors, which have support for CPU
> guarantees built-in. For KVM, we are implementing the allocation guarantees
> using cpu shares in cgroups (by controlling the cpu shares of each instance
> and the total amount of shares allocated on a host). You can find more
> details in the wiki page linked from the blueprint.
> Would appreciate thoughts whether the approach we are taking makes sense,
> or any other feedback.
> Thanks!
> Alex
> --
> Alex Glikson
> IBM Research
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Yaguang Tang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130114/d5d74137/attachment.html>

More information about the OpenStack-dev mailing list