A Virtual Machine within the OpenNebula system consists of:

• A capacity in terms memory and CPU
• A set of NICs attached to one or more virtual networks
• A set of disk images
• A state file (optional) or recovery file, that contains the memory image of a running VM plus some hypervisor specific information.

The above items, plus some additional VM attributes like the OS kernel and context information to be used inside the VM, are specified in a template file.

Virtual Machines are defined in an OpenNebula Template. Templates are stored in a repository to easily browse and instantiate VMs from them. To create a new Template you have to define 3 things

• Capacity & Name, how big will the VM be?

• Disks. Each disk is defined with a DISK attribute. A VM can use three types of disk:
  • Use a persistent Image changes to the disk image will persist after the VM is shutdown.
  • Use a non-persistent Image images are cloned, changes to the image will be lost.
  • Volatile disks are created on the fly on the target host. After the VM is shutdown the disk is disposed.

• Network Interfaces. Each network interface of a VM is defined with the NIC attribute.

The following example shows a VM Template file with a couple of disks and a network interface, also a VNC section was added.

NAME   = test-vm
MEMORY = 128 
CPU    = 1
 
DISK = [ IMAGE  = "Arch Linux" ]
DISK = [ TYPE     = swap,
         SIZE     = 1024 ]
 
NIC = [ NETWORK = "Public", NETWORK_UNAME="oneadmin" ]
 
GRAPHICS = [ 
  TYPE    = "vnc",
  LISTEN  = "0.0.0.0"]

Simple templates can be also created using the command line instead of creating a template file. The parameters to do this for onetemplate are:

A similar template as the previous example can be created with the following command:

<xterm> $ onetemplate create –name test-vm –memory 128 –cpu 1 –disk “Arch Linux” –nic Public </xterm>

You may want to add VNC access, input hw or change the default targets of the disks. Check the VM definition file for a complete reference

OpenNebula Templates are designed to be hypervisor-agnostic, but there are additional attributes that are supported for each hypervisor. Check the Xen, KVM and VMware configuration guides for more details

Volatile disks can not be saved as. Pre-register a DataBlock image if you need to attach arbitrary volumes to the VM

Users can manage the Template Repository using the command onetemplate, or the graphical interface Sunstone. For each user, the actual list of templates available are determined by the ownership and permissions of the templates.

You can use the onetemplate list command to check the available Templates in the system.

<xterm> $ onetemplate list a

ID USER     GROUP    NAME                         REGTIME
 0 oneadmin oneadmin template-0            09/27 09:37:00 
 1 oneuser  users    template-1            09/27 09:37:19 
 2 oneadmin oneadmin Ubuntu_server         09/27 09:37:42 

</xterm>

To get complete information about a Template, use onetemplate show.

Here is a view of templates tab in Sunstone:

Using onetemplate create, users can create new Templates for private or shared use. The onetemplate delete command allows the Template owner -or the OpenNebula administrator- to delete it from the repository.

For instance, if the previous example template is written in the vm-example.txt file:

<xterm> $ onetemplate create vm-example.txt ID: 6 </xterm>

You can also clone an existing Template, with the onetemplate clone command:

<xterm> $ onetemplate clone 6 new_template ID: 7 </xterm>

Via Sunstone, you can easily add templates using the provided wizards (or copy/pasting a template file) and delete them clicking on the delete button:

It is possible to update a template by using the onetemplate update. This will launch the editor defined in the variable EDITOR and let you edit the template.

<xterm> $ onetemplate update 3 </xterm>

The users can share their Templates with other users in their group, or with all the users in OpenNebula. See the Managing Permissions documentation for more information.

Let's see a quick example. To share the Template 0 with users in the group, the USE right bit for GROUP must be set with the chmod command:

<xterm> $ onetemplate show 0 … PERMISSIONS OWNER : um- GROUP : — OTHER : —

$ onetemplate chmod 0 640

$ onetemplate show 0 … PERMISSIONS OWNER : um- GROUP : u– OTHER : — </xterm>

The following command allows users in the same group USE and MANAGE the Template, and the rest of the users USE it:

<xterm> $ onetemplate chmod 0 664

$ onetemplate show 0 … PERMISSIONS OWNER : um- GROUP : um- OTHER : u– </xterm>

The onetemplate instantiate command accepts a Template ID or name, and creates a VM instance (you can define the number of instances using the –multiple num_of_instances option) from the given template.

<xterm> $ onetemplate instantiate 6 VM ID: 0

$ onevm list

  ID USER     GROUP    NAME         STAT CPU     MEM        HOSTNAME        TIME
   0 oneuser1 users    one-0        pend   0      0K                 00 00:00:16

</xterm>

You can also merge another template to the one being instantiated. The new attributes will be added, or will replace the ones fom the source template. This can be more convinient that cloning an existing template and updating it.

<xterm> $ cat /tmp/file MEMORY = 512 COMMENT = “This is a bigger instance”

$ onetemplate instantiate 6 /tmp/file VM ID: 1 </xterm>

The same options to create new templates can be used to be merged with an existing one. See the above table, or execute 'onetemplate instantiate –help' for a complete reference.

<xterm> $ onetemplate instantiate 6 –cpu 2 –memory 1024 VM ID: 2 </xterm>

The template merge functionality, combined with the restricted attibutes, can be used to allow users some degree of customization for predefined templates.

Let's say the administrator wants to provide base templates that the users can customize, but with some restrictions. Having the following restricted attributes in oned.conf:

VM_RESTRICTED_ATTR = "CPU"
VM_RESTRICTED_ATTR = "VPU"
VM_RESTRICTED_ATTR = "NIC"

And the following template:

CPU     = "1"
VCPU    = "1"
MEMORY  = "512"
DISK=[
  IMAGE_ID = "0" ]
NIC=[
  NETWORK_ID = "0" ]

Users can instantiate it customizing anything except the CPU, VCPU and NIC. To create a VM with different memory and disks: <xterm> $ onetemplate instantiate 0 –memory 1G –disk “Ubuntu 12.10” </xterm>

The merged attributes replace the existing ones. To add a new disk, the current one needs to be added also.

<xterm> $ onetemplate instantiate 0 –disk 0,“Ubuntu 12.10” </xterm>

The OpenNebula Scheduler will deploy automatically the VMs in one of the available Hosts, if they meet the requirements. The deployment can be forced by an administrator using the onevm deploy command.

Use onevm shutdown to shutdown a running VM.

Continue to the Managing Virtual Machine Instances Guide to learn more about the VM Life Cycle, and the available operations that can be performed.