A Preview of the New Scheduling Features in OpenNebula 4.0
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.
