Blog Article:

A Preview of the New Scheduling Features in OpenNebula 4.0

Carlos Martín

Feb 20, 2013

We are working hard developing new features and overall improvements for OpenNebula 4.0. Before the new Sunstone eye-candy is revealed and steals all the attention, we wanted to share some of the other features, those small pieces that won’t wow anyone, but combined together make OpenNebula the best option when it comes to integration capabilities.

In this post I will focus on the Scheduler related features.

Schedule any action, not only deployments

We have added a '--schedule' option to most of the VM life-cycle commands. Users can schedule one or more VM actions to be executed at a certain date and time, for example:

$ onevm shutdown 0 --schedule "05/25 17:45"
VM 0: shutdown scheduled at 2013-05-25 17:45:00 +0200

$ onevm cancel 0 --schedule "05/25 18:00"
VM 0: cancel scheduled at 2013-05-25 18:00:00 +0200

$ onevm show 0
SCHEDULED ACTIONS
ID ACTION        SCHEDULED         DONE MESSAGE
 0 shutdown    05/25 17:45            -
 1 cancel      05/25 18:00            -

These actions can be edited or deleted updating the VM template (another new feature that you will see in 4.0).

$ onevm update 0

SCHED_ACTION=[
  ACTION="shutdown",
  ID="0",
  TIME="1369496700" ]
SCHED_ACTION=[
  ACTION="cancel",
  ID="1",
  TIME="1369497600" ]

Placement expressions improvements

We have also improved the requirements and rank expressions making them more useful. Until now you could choose to deploy VMs in a certain cluster, using the following expression:

SCHED_REQUIREMENTS = "CLUSTER = production"

But now you can also use variables from the Host’s Cluster template. Let’s say you have the following scenario:

$ onehost list
  ID NAME            CLUSTER   RVM      ALLOCATED_CPU      ALLOCATED_MEM STAT
   1 host01          cluster_a   0       0 / 200 (0%)     0K / 3.6G (0%) on
   2 host02          cluster_a   0       0 / 200 (0%)     0K / 3.6G (0%) on
   3 host03          cluster_b   0       0 / 200 (0%)     0K / 3.6G (0%) on    

$ onecluster show cluster_a
CLUSTER TEMPLATE
QOS="GOLD"

$ onecluster show cluster_b
CLUSTER TEMPLATE
QOS="SILVER"

You can now use these expressions:

SCHED_REQUIREMENTS = "QOS = GOLD"

SCHED_REQUIREMENTS = "QOS != GOLD & HYPERVISOR = kvm"

If you use the ruby, java or xml-rpc APIs you will be familiar with the XML representation of the resources. The variable names used in rank and requirements expressions can be child elements of HOST, HOST/HOST_SHARE or HOST/TEMPLATE. From now on, you can also use XPath to have more control over the element used:

SCHED_RANK="/HOST/HOST_SHARE/FREE_CPU"
SCHED_REQUIREMENTS="/HOST/TEMPLATE/CUSTOM_VAR != 5"

Scheduler decisions explained

By default, regular users can’t see the Hosts or open the Scheduler log file, and when their VMs can’t be deployed it may look like something is broken. In the next version, the scheduler will add a message to the VM templates to let users know if there are any problems:

$ onevm show 4
USER TEMPLATE
SCHED_MESSAGE="Wed Feb 20 11:43:55 2013 : No hosts enabled to run VMs"

$ onevm show 5
USER TEMPLATE
SCHED_MESSAGE="Wed Feb 20 11:52:11 2013 : No host meets the SCHED_REQUIREMENTS expression"
SCHED_REQUIREMENTS="FREE_CPU > 100 & FREE_CPU < 50"

Basic affinity

There is a new special variable that provides basic VM affinity functionality. Let’s see a sample use case: we want to create two identical VMs, and they should run on the same Host. In OpenNebula 4.0 you can create VMs directly on hold, so the scheduler won’t deploy them until you decide to release them:

$ onetemplate instantiate 0 --multiple 2 --hold
VM ID: 2
VM ID: 3

Now that we have the IDs, we can update one of the VM’s scheduler requirements.

$ onevm update 3
SCHED_REQUIREMENTS="CURRENT_VMS = 2"

$ onevm release 2,3

The scheduler will deploy first VM 2, and in the following cycle VM 3 in the same Host. This, of course, has some limitations because the scheduler will treat each VM individually, instead of as a group. If you need more advanced VM group management, give a try to the AppFlow component.

As always, we welcome any feedback. In fact, most of these changes are requests made by the community, I invite you to join our mailing lists and our development portal if you haven’t yet.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *