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:

These are the actions valid in the -l parameter:

• deploy
• shutdown
• cancel
• save
• restore
• migrate
• poll

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:

Monitoring actions for one_vmm_ssh:

• DEPLOY : Tells the hypervisor to create a new VM
  • Arguments
    • deployment_file: where to write the deployment file. The body of this file is provided in STDIN.
  • Response
    • Success: The VM identifier for the hypervisor
    • Failure: Error message

• SHUTDOWN : Sends shutdown signal to a VM
  • Arguments
    • deploy_id: VM identifier for the hypervisor
  • Response
    • Success: -
    • Failure: Error message

• CANCEL : Destroys a VM
  • Arguments
    • deploy_id: VM identifier for the hypervisor
  • Response
    • Success: -
    • Failure: Error message

• SAVE : Saves the state of a VM (suspend)
  • Arguments
    • deploy_id: VM identifier for the hypervisor
    • file: file name where to save the state
  • Response
    • Success: -
    • Failure: Error message

• RESTORE : Restores a VM to a previous saved state
  • Arguments
    • file: file name where to restore the VM from
  • Response
    • Success: -
    • Failure: Error message

• MIGRATE : Performs live migration of a VM
  • Arguments
    • deploy_id: VM identifier for the hypervisor
    • host: host where to migrate the VM
  • Response
    • Success: -
    • Failure: Error message

• POLL : Gets information about a VM
  • Arguments
    • deploy_id: VM identifier for the hypervisor
  • Response
    • Success: Monitoring data (described in next section)
    • Failure: Error message

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:

STATE is a single character that tells OpenNebula the status of the VM, the states are the ones in this table:

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:

• xen: deployment file suitable to be used with xen tools
• kvm: libvirt format used to create kvm VMs
• xml: xml representation of the VM

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.