You can manage your virtual machines using the onevm command or Sunstone. In Sunstone, you can easily instantiate currently defined templates by clicking “New” on the Virtual Machines tab. A dialog will allow you to name the VM and choose the number of instances you want to create:

The life-cycle of a Virtual Machine within OpenNebula includes the following stages:

Note that this is a simplified version. If you are a developer you may want to take a look at the complete diagram referenced in the xml-rpc api page):

The following sections show the basics of the onevm command with simple usage examples. A complete reference for these commands can be found here.

Read the Creating Virtual Machines guide for more information on how to manage and instantiate VM Templates.

Read the complete reference for Virtual Machine templates.

Assuming we have a VM Template registered called vm-example with ID 6, then we can instantiate the VM issuing a:

<xterm> $ onetemplate list

ID USER     GROUP    NAME                         REGTIME
 6 oneadmin oneadmin vm_example            09/28 06:44:07

$ onetemplate instantiate vm-example –name my_vm VM ID: 0 </xterm>

afterwards, the VM can be listed with the onevm list command. You can also use the onevm top command to list VMs continuously.

<xterm> $ onevm list

  ID USER     GROUP    NAME         STAT CPU     MEM        HOSTNAME        TIME
   0 oneadmin oneadmin my_vm        pend   0      0K                 00 00:00:03

</xterm>

After a Scheduling cycle, the VM will be automatically deployed. But the deployment can also be forced by oneadmin using onevm deploy:

<xterm> $ onehost list

ID NAME               RVM   TCPU   FCPU   ACPU   TMEM   FMEM   AMEM   STAT
 2 testbed              0    800    800    800    16G    16G    16G     on

$ onevm deploy 0 2

$ onevm list

  ID USER     GROUP    NAME         STAT CPU     MEM        HOSTNAME        TIME
   0 oneadmin oneadmin my_vm        runn   0      0K         testbed 00 00:02:40

</xterm>

and details about it can be obtained with show:

<xterm> $ onevm show 0 VIRTUAL MACHINE 0 INFORMATION ID : 0 NAME : my_vm USER : oneadmin GROUP : oneadmin STATE : ACTIVE LCM_STATE : RUNNING START TIME : 04/14 09:00:24 END TIME : - DEPLOY ID: : one-0

PERMISSIONS OWNER : um- GROUP : — OTHER : —

VIRTUAL MACHINE MONITORING NET_TX : 13.05 NET_RX : 0 USED MEMORY : 512 USED CPU : 0

VIRTUAL MACHINE TEMPLATE …

VIRTUAL MACHINE HISTORY SEQ HOSTNAME REASON START TIME PTIME

 0         testbed   none  09/28 06:48:18 00 00:07:23 00 00:00:00

</xterm>

Once the VM is created, you can manage it with the following onevm commands:

• hold: Sets the VM to hold state. The scheduler will not deploy VMs in the hold state, but the administrator can use the onevm deploy command to force a deployment.
• release: Releases a VM from hold state, setting it to pending.
• shutdown: Gracefully shuts down a running VM, sending the ACPI signal. If after a timeout period the VM does not disappear, OpenNebula will assume that the guest OS ignored the ACPI signal and the VM state will be changed to running, instead of done.
• stop: The Virtual Machine complete state (disks and memory checkpoint) is transferred back to the front-end. When a stopped VM is resumed, it is be moved to the pending state, and the scheduler will choose where to re-deploy it.
• cancel: The running VM is immediately destroyed. Use this action instead of “shutdown” when the VM doesn't have ACPI support, or when it has become irresponsive. The difference with the “delete” action is that the persistent Images are saved back to the datastore.
• suspend: same as stop but the Virtual Machine state is left in the Host for resuming. When a suspended VM is resumed, it is immediately deployed in the same Host (restoring the state of the VM, when it was suspended).
• poweroff: same as suspended, but no checkpoint (VM state file) is generated. When a VM is poweroff it can be restarted to immediately boot it in the same Host.
• resume: Resumes the execution of a stopped or suspended VM.
• delete: The running VM is immediately destroyed. Using this action instead of “cancel” will set the Images meant to be saved in error state.
• reboot: Gracefully reboots a running VM, sending the ACPI signal.
• reset: Resets a running VM ('hard' reboot).
• resubmit: Resubmits a VM to PENDING state. This operation can be use to re-deploy a fresh copy of the same VM, while preserving its assigned resources (e.g. leased IP addresses) and history (e.g. accounting statistics) as opposed to instantiate a VM template.

There are some onevm commands operations meant for the cloud administrators:

Scheduling:

• resched: Sets the reschedule flag for the VM. The Scheduler will migrate (or livemigrate, depending on the Scheduler configuration) the VM in the next monitorization cycle to a Host that better matches the requirements and rank restrictions. Read more in the Scheduler documentation.
• unresched: Clears the reschedule flag for the VM, canceling the rescheduling operation.

Deployment:

• deploy: Starts an existing VM in a specific Host.
• livemigrate: The Virtual Machine is transferred between Hosts with no noticeable downtime. This action requires a shared file system storage.
• migrate: The VM gets stopped and resumed in the target host.

Troubleshooting:

• restart: Forces the hypervisor boot action of a VM stuck in UNKNOWN or BOOT state.

Disks can be volatile, in which case the files will be deleted when the VM is shut down, or use a persistent or non-persistent Image. When using a registered Image, the disk can be set to be saved to the Datastore as a new Image. The onevm saveas command can be while the VM is running, for example:

<xterm> $ onevm saveas one-5 0 “Customized Ubuntu” </xterm>

Read more in the Image guide.

New disks can be hot-plugged to running VMs with the onevm attachdisk and detachdisk commands. For example, to attach to a running VM the Image named “storage”:

<xterm> $ onevm attachdisk one-5 –image storage </xterm>

To detach a disk from a running VM, find the disk ID of the Image you want to detach using the onevm show command, and then simply execute onevm detach vm_id disk_id:

<xterm> $ onevm show one-5 … DISK=[

DISK_ID="1",

…

]

…

$ onevm detachdisk one-5 1 </xterm>

OpenNebula comes with an advanced ACL rules permission mechanism intended for administrators, but each VM object has also implicit permissions that can be managed by the VM owner. To share a VM instance with other users, to allow them to list and show its information, use the onevm chmod command:

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

$ onevm chmod 0 640

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

Administrators can also change the VM's group and owner with the chgrp and chown commands.

• Although the default way to create a VM instance is to register a Template and then instantiate it, VMs can be created directly from a template file using the onevm create command.
• When a VM reaches the done state, it disappears from the onevm list output, but the VM is still in the database and can be retrieved with the onevm show command.
• OpenNebula comes with an accounting tool that reports resource usage data.
• The monitoring information, shown with nice graphs in Sunstone, can be retrieved using the XML-RPC methods one.vm.monitoring and one.vmpool.monitoring.