At OpenNebula Systems, we are working on an upcoming feature with the specific aim to simplify the management of VM templates that can be deployed on multiple clusters. When a VM template refers to disk images on datastores shared across different clusters, the VM template can be allocated in any of them. This also requires that the clusters share the network dependencies of the VM template, which may not always be the desired design.

In order to overcome this problem, this feature will implement an automatic selection process for the virtual networks of a VM template. The actual virtual network used by the VM will be selected among those available in the selected cluster using a similar algorithm to the one used to select system datastores or hosts. In this way, the very same VM template will be deployable on multiple clusters without requiring shared networks or any modification.

Quick Video: VM Templates – Automatic Network selection

Anticipated Changes on the CLI and XML-RPC API

The VM template includes a list of network interface controllers (NIC) attached to a virtual network. The definition of the NIC has been extended to include a new selection mode (automatic).

To create a new VM from CLI you can type a command like this:

onevm create --name <name> --cpu <cpu> --memory <memory> --nic auto

This command will create a VM with this NIC:

<NIC>
<NETWORK_MODE><![CDATA[auto]]></NETWORK_MODE>
<NIC_ID><![CDATA[0]]></NIC_ID>
</NIC>

The network selection mode is set by the new attribute NETWORK_MODE, which can be set to either MANUAL (current selection method) or AUTO. The new attribute is optional, and if not changed, it defaults to MANUAL. This way, existing templates do not need to be upgraded as the current interface is preserved.

The API call one.vm.deploy will accept a new template document as an extra parameter. And this new parameter will include the selected networks for those NICs using the automatic selection process.

Sunstone

From the Template section, we can define the NICs we want set to AUTO and those we do not.

Also, we can change a NIC from the Instantiate section.

You can learn how to derive your own network selection policies in the Scheduler guide.

The plan is for this capability to be included in the upcoming version 5.8, and we will likely backport it to version 5.6.x, as well.  If you have any questions or feedback, send us your input – either on our Developers’ Forum or leave a comment below.