Creating Virtual Machines 3.0

In OpenNebula the Virtual Machines are defined with Template definition files. This guide explains how to describe the wanted-to-be-ran Virtual Machine, and how users typically interact with the system.

The Template Repository system allows OpenNebula administrators and users to register Virtual Machine definitions in the system, to be instantiated later as Virtual Machine instances. These Templates can be instantiated several times, and also shared with other users.

inlinetoc

Virtual Machine Model

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.

What Is a Template

An OpenNebula Template is a Virtual Machine definition. These definitions are stored in a Template repository, which can be seen as a text template files storage with owner and privileges management, as well as the option to share Templates publishing them.

OpenNebula Templates are designed to be hypervisor-agnostic, but still there are some peculiarities to be taken into account, and mandatory attributes change depending on the target hypervisor. Hypervisor specific information for this attributes can be found in the drivers configuration guides:

OpenNebula has been designed to be easily extended, so any attribute name can be defined for later use in any OpenNebula module. There are some pre-defined attributes, though.

Please check the Virtual Machine definition file reference for details on all the sections.

A VM Template Example

For example, the following template defines a VM with 512MB of memory and one CPU. The VM has three disks:

  • An OS Image previously registered in the Image Repository.
  • A DATABLOCK Image called “Testing results”.
  • And a swap partition. This disk is not using any Image from the repository; an empty file will be generated instead.

Only one NIC is defined, attached to a Virtual Network.

The context section will generate a CDROM with the files specified, that will be run at startup. Please read the contextualization guide if you want to learn more about this feature.

In this case, between all the suitable Hosts (those that meet CPU and MEMORY requirements, and also CPUSPEED > 1000 requirement), OpenNebula will pick the Host with more free CPU.

<xterm> $ oneimage list m

ID USER     GROUP    NAME            SIZE TYPE          REGTIME PUB PER STAT  RVMS
 3 oneadmin oneadmin Debian 6.0       10G   OS   09/27 06:24:55 Yes  No  rdy     0
 5 oneadmin oneadmin Testing results  35G   DB   09/27 06:44:00  No  No  rdy     0

$ onevnet list a

ID USER     GROUP    NAME              TYPE BRIDGE PUB  LEASES
 2 oneadmin oneadmin Public               F   vbr1 Yes       3
 3 oneadmin oneadmin Red LAN              R   vbr0  No       2
 6 oneuser  users    Private lab 3        F   vbr2  No       0

$ cat vm-example.txt #————————————— # VM definition example #—————————————

NAME = vm-example

CPU = 1 MEMORY = 512

# — kernel & boot device —

OS = [

kernel   = "/vmlinuz",
initrd   = "/initrd.img",
root     = "sda" ]

# — 3 disks —

DISK = [ IMAGE_ID = 3 ]

DISK = [ IMAGE_ID = 5 ]

DISK = [

type     = swap,
size     = 1024,
readonly = "no" ]

# — 1 NIC —

NIC = [ NETWORK_ID = 3 ]

# — Placement options —

REQUIREMENTS = “CPUSPEED > 1000” RANK = FREECPU

# — Contextualization —

CONTEXT = [

files     = "/service/init.sh /service/certificates /service/service.conf"  ]

</xterm>

The disks will be mounted as sda for the OS, sdb for the generated context CDROM, sdd for the swap disk, and sde for the “Testing results”. This assignment schema is fully documented in the Virtual Machine template reference.

:!: Note that you can add as many DISK and NIC attributes as you need

Managing Templates

Users can manage the Template Repository using the command onetemplate, or the graphical interface Sunstone.

Listing Available 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 PUB
 0 oneadmin oneadmin template-0            09/27 09:37:00  No
 1 oneuser  users    template-1            09/27 09:37:19  No
 2 oneadmin oneadmin Ubuntu_server         09/27 09:37:42 Yes

</xterm>

To get complete information about a Template, use onetemplate show, or list Templates continuously with onetemplate top.

Here is a view of templates tab in Sunstone:

Adding and Deleting Templates

Using onetemplate create, users can create new Templates for private or public 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>

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:

Updating a template

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>

In Sunstone you can select a template and update it easily as well:

Publishing Templates

Use the onetemplate publish and onetemplate unpublish commands to make your Templates public, allowing any user to instantiate them.

<xterm> $ onetemplate publish -v 6 VMTEMPLATE 6: published </xterm>

In Sunstone simply select the template(s) and click the Publish or Unpublish buttons.

Instantiating Templates

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>

Instantation can be done through Sunstone by selecting one or several templates and pressing the “Instantiate” button.

The OpenNebula Scheduler will deploy automatically the VMs in one of the available Hosts, if they meet the requirements. The deployment can be forced 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.