Managing Virtual Machines 4.0
This guide follows the Creating Virtual Machines guide.
Once a Template is instantiated to a Virtual Machine, there are a number of operations that can be performed using the onevm
command.
The life-cycle of a Virtual Machine within OpenNebula includes the following stages:
Short state | State | Meaning |
---|---|---|
pend | Pending | By default a VM starts in the pending state, waiting for a resource to run on. It will stay in this state until the scheduler decides to deploy it, or the user deploys it using the onevm deploy command. |
hold | Hold | The owner has held the VM and it will not be scheduled until it is released. It can be, however, deployed manually. |
prol | Prolog | The system is transferring the VM files (disk images and the recovery file) to the host in which the virtual machine will be running. |
boot | Boot | OpenNebula is waiting for the hypervisor to create the VM. |
runn | Running | The VM is running (note that this stage includes the internal virtualized machine booting and shutting down phases). In this state, the virtualization driver will periodically monitor it. |
migr | Migrate | 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). |
hotp | Hotplug | A disk attach/detach, nic attach/detach operation is in process. |
snap | Snapshot | A system snapshot is being taken. |
save | Save | The system is saving the VM files after a migration, stop or suspend operation. |
epil | Epilog | In this phase the system cleans up the Host used to virtualize the VM, and additionally disk images to be saved are copied back to the front-end. |
shut | Shutdown | OpenNebula has sent the VM the shutdown ACPI signal, and is waiting for it to complete the shutdown process. 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 | Stopped | The VM is stopped. VM state has been saved and it has been transferred back along with the disk images to the front-end. |
susp | Suspended | Same as stopped, but the files are left in the host to later restart the VM there (i.e. there is no need to re-schedule the VM). |
poff | PowerOff | Same as suspended, but no checkpoint file is gnerated. Note that the files are left in the host to later restart the VM there. |
fail | Failed | The VM failed. |
unkn | Unknown | The VM couldn't be reached, it is in an unknown state. |
done | Done | The VM is done. VMs in this state won't be shown with “onevm list” but are kept in the database for accounting purposes. You can still get their information with the onevm show command. |
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. Please note that VMs can be created directly on hold, using 'onetemplate instantiate --hold' or 'onevm create --hold'.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. Think of delete as kill -9 for a process, an so it should be only used when the VM is not responding to other actions. Note that the result of some actions are indeed not checked in this mode.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.Note: By default, the above operations do not check the target host capacity. You can use the -e (–enforce) option to be sure that the host capacity is not overcommitted.
Troubleshooting:
restart
: Forces the hypervisor boot action of a VM stuck in UNKNOWN or BOOT state.You can take a snapshot of a VM disk to preserve or backup its state at a given point of time. There are two types of disk snapshots in OpenNebula:
The onevm disk-snapshot
command can be run while the VM is RUNNING, POWEROFF or SUSPENDED. See the Image guide for specific examples of the saveas command.
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>
You can also hotplug network interfaces to a RUNNING VM. Simply, specify the network where the new interface should be attach to, for example:
<xterm> $ onevm show 2
VIRTUAL MACHINE 2 INFORMATION ID : 2 NAME : centos-server USER : ruben GROUP : oneadmin STATE : ACTIVE LCM_STATE : RUNNING RESCHED : No HOST : cloud01
…
VM NICS ID NETWORK VLAN BRIDGE IP MAC 0 net_172 no vbr0 172.16.0.201 02:00:ac:10:0
VIRTUAL MACHINE HISTORY SEQ HOST REASON START TIME PROLOG_TIME
0 cloud01 none 03/07 11:37:40 0d 00h02m14s 0d 00h00m00s
…
$ onevm attachnic 2 –network net_172 </xterm>
After the operation you should see two NICs 0 and 1: <xterm> $ onevm show 2 VIRTUAL MACHINE 2 INFORMATION ID : 2 NAME : centos-server USER : ruben GROUP : oneadmin
…
VM NICS ID NETWORK VLAN BRIDGE IP MAC 0 net_172 no vbr0 172.16.0.201 02:00:ac:10:00:c9
fe80::400:acff:fe10:c9
1 net_172 no vbr0 172.16.0.202 02:00:ac:10:00:ca
fe80::400:acff:fe10:ca
…
</xterm>
Also, you can detach a NIC by its ID. If you want to detach interface 1 (MAC=02:00:ac:10:00:ca), just: <xterm>
onevm detachnic 2 1
</xterm>
You can create, delete and restore snapshots for running VMs. A snapshot will contain the current disks and memory state.
RUNNING
state. If the state changes (stop, migrate, etc…) the snapshots will be lost.<xterm> $ onevm snapshot-create 4 “just in case”
$ onevm show 4 … SNAPSHOTS
ID TIME NAME HYPERVISOR_ID 0 02/21 16:05 just in case onesnap-0
$ onevm snapshot-revert 4 0 –verbose VM 4: snapshot reverted </xterm>
Please take into consideration the following limitations:
You may re-size the capacity assigned to a Virtual Machine in terms of the virtual CPUs, memory and CPU allocated. VM re-sizing can be done when the VM is not ACTIVE, an so in any of the following states: PENDING, HOLD, FAILED and specially in POWEROFF.
If you have created a Virtual Machine and you need more resources, the following procedure is recommended:
Note that using this procedure the VM will preserve any resource assigned by OpenNebula (e.g. IP leases)
The following is an example of the previous procedure from the command line (the Sunstone equivalent is straight forward): <xterm» onevm poweroff web_vm
onevm resize web_vm –memory 2G –vcpu 2
onevm restart web_vm
</xterm>
Most of the onevm commands accept the '--schedule' option, allowing users to delay the actions until the given date and time.
Here is an usage example:
<xterm> $ onevm suspend 0 –schedule “09/20” VM 0: suspend scheduled at 2013-09-20 00:00:00 +0200
$ onevm resume 0 –schedule “09/23 14:15” VM 0: resume scheduled at 2013-09-23 14:15:00 +0200
$ onevm show 0 VIRTUAL MACHINE 0 INFORMATION ID : 0 NAME : one-0
[…]
SCHEDULED ACTIONS ID ACTION SCHEDULED DONE MESSAGE 0 suspend 09/20 00:00 - 1 resume 09/23 14:15 - </xterm>
These actions can be deleted or edited using the 'onevm update' command. The time attributes use Unix time internally.
<xterm> $ onevm update 0
SCHED_ACTION=[
ACTION="suspend", ID="0", TIME="1379628000" ]
SCHED_ACTION=[
ACTION="resume", ID="1", TIME="1379938500" ]
</xterm>
These are the commands that can be scheduled:
shutdown
delete
hold
release
stop
cancel
suspend
resume
restart
resubmit
reboot
reset
poweroff
snapshot-create
Custom tags can be associated to a VM to store metadata related to this specific VM instance. To add custom attributes simply use the onevm update
command.
<xterm> $ onevm show 0 …
VIRTUAL MACHINE TEMPLATE … VMID=“0”
$ onevm update 0 ROOT_GENERATED_PASSWORD=“1234” ~ ~
$onevm show 0 …
VIRTUAL MACHINE TEMPLATE … VMID=“0”
USER TEMPLATE ROOT_GENERATED_PASSWORD=“1234”
</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.
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:
onevm create
command.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.