Xen CPU credit scheduler

To my knowledge there is not such a scheduler available in OpenStack today. However the way the scheduler component has been designed allows anyone to implement and plug in whichever scheduling policing seen fit for the purpose.

You could have a look at the scheduler implementation here:

http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/files/head:/nova/scheduler/

The specific scheduler to use can be set via flags.

Eventually more and more scheduling algorithms will be added to Nova, with a process which I assumed will be governed by the use of blueprints.

Hope this help!

> Armando Migliaccio proposed the following answer:
> To my knowledge there is not such a scheduler available in OpenStack
> today. However the way the scheduler component has been designed allows
> anyone to implement and plug in whichever scheduling policing seen fit
> for the purpose.
>
> You could have a look at the scheduler implementation here:
>
> http://bazaar.launchpad.net/~hudson-
> openstack/nova/trunk/files/head:/nova/scheduler/

I think that Richard was referring to the dom0's ability to schedule
guests to consume host resources above their designated allotment,
which AFAIK, doesn't have to do with the Nova concept of a scheduler
node, which is the node that schedules tasks coming from the API node
to run on various compute/network workers.

So, I think that Richard wants to be able to use xm sched-credit from
within Nova's virt layer (see
http://wiki.xensource.com/xenwiki/CreditScheduler)

I think this could be added fairly easily. Looks like
/nova/virt/xenapi/vmops.py would be the place to get started...

-jay

Thanks Jay, yes that is exactly what I was referring to. The ability use the Xen credit scheduler would be a huge benefit.

Richard

The current code just leaves the scheduling parameters as their default, so all VMs can burst as far as their vCPU count will allow. It would be easy to allow you to configure this though.

How would you like to configure it? An obvious model would be that a given tenant (project) would have a weight, and all VMs belonging to that tenant would be configured with that weight. Alternatively, a given VM size (m1.small, etc) could have an associated weight, and therefore customers buying bigger VMs will get more CPU credit (over and above the fact that larger VMs are likely to have more vCPUs anyway). Or we could combine the two. Any thoughts?

We could take your thoughts here and turn them into a blueprint for a feature request. This is something that we could do pretty easily for the next release.