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. In general it could be necessary to transfer some of these image files to/from the execution host.
• 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 VM template file.

Each VM in OpenNebula is identified by an unique number, the <VID>. Also, the user can assign it a name in the VM template, the default name for each VM is one-<VID>.

The life-cycle of a virtual machine within the system includes the following stages (note that this is a simplified version):

• Pending (pend): By default a VM starts in the pending state, waiting for a resource to run on.

• Hold (hold): The owner has held the VM and it will not be scheduled until it is released.

• Prolog (prol): The system is transferring the VM files (disk images and the recovery file).

• Running (runn): The VM is running (note that this stage includes booting and shutting down phases). In this state, the virtualization driver will periodically monitor it.

• Migrate (migr): The VM is migrating from one resource to another. This can be a life migration or cold migration (the VM is saved and VM files are transferred to the new resource).

• Epilog (epil): In this phase the system clean ups the cluster node used to host the VM, and additionally disk images to be saved are copied back to the cluster front-end.

• Stopped (stop): The VM is stopped. VM state has been saved and it has been transferred back along with the disk images.

• Suspended (susp): Same as stopped, but the files are left in the remote resource to later restart the VM there (i.e. there is no need to re-schedule the VM).

• Failed (fail): The VM failed.

• Unknown (unknown): The VM couldn't be reached, it is in an unknown state.

• Done (done): The VM is done. VMs in this state wont be shown with “onevm list” but are kept in the database for accounting purposes.

In order to use OpenNebula, you need to set the following variables in your environment. You may want to place them, in the .bashrc of the <oneadmin> account for commodity:

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:

• Xen Adaptor
• KVM Adaptor
• VMware Adaptor

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.

For example, the following template defines a VM with 512MB of memory and one CPU. The VM has two disks: sda supported by an image file; and sdb (a swap partition). Only one NIC is defined with a predefined MAC address. In this case, between all the suitable hosts (those that meets CPU and MEMORY requirements, and also CPUSPEED > 1000 requirement), OpenNebula will pick the host with more free CPU.

#---------------------------------------
# VM definition example
#---------------------------------------

NAME = vm-example 

CPU    = 1
MEMORY = 512

# --- kernel & boot device ---

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

# --- 2 disks ---

DISK = [
  source   = "/local/xen/domains/etch/disk.img",
  target   = "sda",
  readonly = "no" ]

DISK = [
  type     = swap,
  size     = 1024,
  target   = "sdb",
  readonly = "no" ]

# --- 1 NIC ---

NIC = [ mac="00:ff:72:17:20:27"]

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

OpenNebula comes with a rich command line interface intended for users fond of consoles. There are commands to manage three basic aspects of OpenNebula: virtual machines, hosts and virtual networks.

A complete reference for these three commands can be found here. The following subsections show the basics of the available commands with simple usage examples.

This command enables virtual machine management. Actions offered are:

• create ( a VM in OpenNebula's VM pool )
• deploy (on a particular cluster node)
• shutdown
• livemigrate (the virtual machine is transferred between cluster nodes with no noticeable downtime)
• migration (machine gets stopped and resume elsewhere)
• hold
• release (from hold state)
• stop (virtual machine state is transferred back to OpenNebula for a possible reschedule)
• cancel
• suspend (virtual machine state is left in the cluster node for resuming)
• resume
• delete
• restart(resubmits the virtual machine after failure)
• list (outputs all the available VMs)
• show (outputs information for a specific VM)
• top (lists VMs continously)
• history (gets VMs history of execution on the cluster nodes)

Assuming we have a VM template called myVM.one describing a virtual machine. Then, we can allocate the VM in OpenNebula issuing a:

<xterm> $ onevm create myVM.one </xterm>

afterwards, the VM can be listed with the list option:

<xterm> $ onevm list

ID     USER     NAME STAT CPU     MEM        HOSTNAME        TIME
 0 oneadmin     myVM runn   0 2097152            ursa 00 00:00:07

</xterm>

and details about it can be obtained with show:

<xterm> $ onevm show myVM VIRTUAL MACHINE 0 INFORMATION ID : 0 NAME : myVM STATE : ACTIVE LCM_STATE : RUNNING START TIME : 07/16 16:19:38 END TIME : - DEPLOY ID: : one-0

VIRTUAL MACHINE TEMPLATE CPU=1 DISK=[

READONLY=no,
SOURCE=/local/xen/domains/etch/disk.img,
TARGET=sda ]

DISK=[

READONLY=no,
SIZE=1024,
TARGET=sdb,
TYPE=swap ]

MEMORY=512 NAME=vm-example NIC=[

MAC=00:ff:72:17:20:27 ]

OS=[

INITRD=/initrd.img,
KERNEL=/vmlinuz,
ROOT=sda ]

VMID=0 </xterm>

This command enables cluster nodes scouting. Actions offered are:

• show (details of a particular cluster node)
• list (lists nodes in the host pool)
• top (lists host continuously)

Assuming a cluster node called hosts01 running the XEN hypervisor and without shared folders, we can list the available nodes:

<xterm> $ onehost list HID NAME RVM TCPU FCPU ACPU TMEM FMEM STAT

 0 host01                      0    800    766    500 8387584 6157312   on

</xterm>

and retrieve more detailed information for this node using show:

<xterm> $ onehost show 0 HOST 0 INFORMATION ID : 0 NAME : host01 STATE : MONITORED IM_MAD : im_xen VM_MAD : vmm_xen TM_MAD : tm_ssh

HOST SHARES MAX MEM : 2093532 USED MEM (REAL) : 418287 USED MEM (ALLOCATED) : 364544 MAX CPU : 100 USED CPU (REAL) : 4 USED CPU (ALLOCATED) : 100 RUNNING VMS : 1

MONITORING INFORMATION CPUSPEED=2211 FREECPU=96 FREEMEMORY=1675245 HYPERVISOR=vmware MODELNAME=Sun Fire(TM) X2100 NETRX=2 NETTX=15 TOTALCPU=100 TOTALMEMORY=2093532 USEDCPU=4 USEDMEMORY=418287 </xterm>

This command enables the management of virtual networks. Actions offered are:

• create ( a virtual network in OpenNebula's VN pool )
• show (details of a particular virtual network)
• delete
• list (lists all the VNs in the VN pool)

Assuming a virtual network template called myVN.net, we can create the virtual network within OpenNebula issuing:

<xterm> $ onevnet create myVN.net </xterm>

and then list it using:

<xterm> $ onevnet list NID USER NAME TYPE BRIDGE #LEASES

 0 oneadmin myVN            Ranged   eth0       2

</xterm>

and obtain details about it with:

<xterm> $ onevnet show 0 IRTUAL NETWORK 0 INFORMATION ID: : 0 UID: : 0

VIRTUAL NETWORK TEMPLATE BRIDGE=eth0 NAME=myVN NETWORK_ADDRESS=86.0.0.0 NETWORK_SIZE=250 TYPE=RANGED

LEASES INFORMATION LEASE=[ IP=86.0.0.1, MAC=00:50:56:00:00:01, USED=1, VID=8 ] LEASE=[ IP=86.0.0.2, MAC=00:50:56:00:00:02, USED=1, VID=9 ] </xterm>

OpenNebula can be used to deploy different solutions for on-demand execution of services. We have prepared the following use cases to illustrate its functionality in typical computing scenarios:

• On-demand Scaling of Computing Clusters
• On-demand Infrastructure for Training
• Scaling out Computing Clusters to Amazon EC2
• Scaling out Web Servers to Amazon EC2