Virtual Machine Manager Drivers 3.6
The component that deals with the hypervisor to create, manage and get information about virtual machine objects is called Virtual Machine Manager (VMM for short). This component has two parts. The first one resides in the core and holds most of the general functionality common to all the drivers (and some specific), the second is the driver that is the one able to translate basic VMM actions to the hypervisor.
There are two main drivers one_vmm_exec
and one_vmm_sh
. Both take commands from OpenNebula and execute a set of scripts for those actions, the main difference is that one_vmm_exec
executes the commands remotely (logging into the host where VM is being or is going to be executed) and one_vmm_sh
does the execution of the scripts in the frontend.
The driver takes some parameters, described here:
parameter | description |
---|---|
-r <num> | number of retries when executing an action |
-t <num | number of threads, i.e. number of actions done at the same time |
-l <actions> | (one_vmm_exec only) actions executed locally, command can be overridden for each action |
<driver_directory> | where in the remotes directory the driver can find the action scripts |
These are the actions valid in the -l parameter:
You can also provide an alternative script name for local execution, by default the script is called the same as the action, in this fashion action=script_name
. As an example:
-l migrate,poll=poll_ganglia,save
These arguments are specified in the oned.conf file, arguments
variable:
VM_MAD = [ name = "vmm_kvm", executable = "one_vmm_exec", arguments = "-t 15 -r 0 -l migrate,save kvm", default = "vmm_exec/vmm_exec_kvm.conf", type = "kvm" ]
Every action should have an executable program (mainly scripts) located in the remote dir (remotes/vmm/<driver_directory>
) that performs the desired action. These scripts receive some parameters (and in the case of DEPLOY
also STDIN) and give back the error message or information in some cases writing to STDOUT.
The basic actions the Virtual Machine Manager Driver should understand are these:
Action | Description |
---|---|
DEPLOY | Tells the hypervisor to create a new VM |
SHUTDOWN | Sends shutdown signal to a VM |
CANCEL | Destroys a VM |
SAVE | Saves the state of a VM (suspend) |
RESTORE | Restores a VM to a previous saved state |
MIGRATE | Performs live migration of a VM |
POLL | Gets information about a VM |
Monitoring actions for one_vmm_ssh
:
deployment_file
: where to write the deployment file. The body of this file is provided in STDIN.deploy_id
: VM identifier for the hypervisordeploy_id
: VM identifier for the hypervisordeploy_id
: VM identifier for the hypervisorfile
: file name where to save the statefile
: file name where to restore the VM fromdeploy_id
: VM identifier for the hypervisorhost
: host where to migrate the VMdeploy_id
: VM identifier for the hypervisor
one_vmm_sh
has the same script actions and meanings but an argument more that is the host where the action is going to be performed. This argument is always the first one. If you use -p
parameter in one_vmm_ssh
the poll action script is called with one more argument that is the host where the VM resides, also it is the same parameter.
POLL
is the action that gets monitoring info from the running VMs. The format it is supposed to give back information is a line with KEY=VALUE
pairs separated by spaces. Like this:
STATE=a USEDMEMORY=554632
The poll action can give back any information and it will be added to the VM information hold but there are some variables that should be given back as they are meaningful to OpenNebula:
Variable | Description |
---|---|
STATE | State of the VM (explained later) |
USEDCPU | Percentage of 1 CPU consumed (two fully consumed cpu is 200) |
USEDMEMORY | Memory consumption in kilobytes |
NETRX | Received bytes from the network |
NETTX | Sent bytes to the network |
STATE
is a single character that tells OpenNebula the status of the VM, the states are the ones in this table:
state | description |
---|---|
- | Detecting state error. The monitoring could be done, but it returned an unexpected output. |
a | Active. The VM is alive, but not necessary running. Could be blocked, booting, etc. |
p | Paused. Self-explanatory. |
e | Error. The VM crashed or somehow its deployment failed. |
d | Disappeared. The VM is not known by the hypervisor anymore. |
The deployment file is a text file written by OpenNebula core that holds the information of a VM. It is used when deploying a new VM. OpenNebula is able to generate three formats of deployment files:
If the target hypervisor is not xen nor libvirt/kvm the best format to use is xml as it holds more information than the two others. It has all the template information encoded as xml. This is an example:
<TEMPLATE> <CPU><![CDATA[1.0]]></CPU> <DISK> <DISK_ID><![CDATA[0]]></DISK_ID> <SOURCE><![CDATA[/home/user/vm.img]]></SOURCE> <TARGET><![CDATA[sda]]></TARGET> </DISK> <MEMORY><![CDATA[512]]></MEMORY> <NAME><![CDATA[test]]></NAME> <VMID><![CDATA[0]]></VMID> </TEMPLATE>
There are some information added by OpenNebula itself like the VMID and the DISK_ID
for each disk. DISK_ID
is very important as the disk images are previously manipulated by the TM
driver and the disk should be accessible at VM_DIR/VMID/images/disk.DISK_ID
.