The cluster nodes must have a working installation of KVM, that usually requires:

• CPU with VT extensions
• libvirt >= 0.4.0
• kvm kernel modules (kvm.ko, kvm-{intel,amd}.ko). Available from kernel 2.6.20 onwards.
• the qemu user-land tools

OpenNebula uses the libvirt interface to interact with KVM, so the following steps are required in the cluster nodes to get the KVM driver running:

• The remote hosts must have the libvirt daemon running.
• The user with access to these remotes hosts on behalf of OpenNebula (typically <oneadmin>) has to pertain to the <libvirtd> group in order to use the deaemon.

OpenNebula uses libvirt's migration capabilities. More precisely, it uses the TCP protocol offered by libvirt. In order to configure the physical nodes, the following files have to be modified:

• /etc/libvirt/libvirtd.conf : Uncomment “listen_tcp = 1”. Security configuration is left to the admin's choice, file is full of useful comments to achieve a correct configuration.

• /etc/default/libvirt-bin : add -l option to libvirtd_opts

The driver consists of the following files:

• $ONE_LOCATION/lib/mads/one_vmm_kvm : Shell script wrapper to the driver itself. Sets the environment and other bootstrap tasks.

• $ONE_LOCATION/lib/mads/one_vmm_kvm.rb : The actual KVM driver.

• $ONE_LOCATION/etc/vmm_kvm/vmm_kvmrc : environment setup and bootstrap instructions

• $ONE_LOCATION/etc/vmm_kvm/vmm_kvm.conf : set here default values for KVM domain definitions.

Note: If OpenNebula was installed in system wide mode these directories become /usr/lib/one/mads and /etc/one/, respectively. The rest of this guide refers to the $ONE_LOCATION paths (corresponding to self contained mode) and omits the equivalent system wide locations. More information on installation modes can be found here.

OpenNebula needs to know if it is going to use the KVM Driver. To achieve this, two lines have to be placed within $ONE_LOCATION/etc/oned.conf, one for the VM driver and other for the information (IM) driver:

    IM_MAD = [
        name       = "im_kvm",
        executable = "one_im_ssh",
        arguments  = "im_kvm/im_kvm.conf",
        default    = "im_kvm/im_kvm.conf" ]

    VM_MAD = [
        name       = "vmm_kvm",
        executable = "one_vmm_kvm",
        default    = "vmm_kvm/vmm_kvm.conf",
        type       = "kvm" ]

• The name of the driver needs to be provided at the time of adding a new host to OpenNebula.
• executable points to the path of the driver executable file. It can be an absolute path or relative to $ONE_LOCATION/lib/mads.
• The default points to the configuration file for the driver (see below). It can be an absolute path or relative to $ONE_LOCATION/etc.
• type identifies this driver as a KVM driver.

The driver uses two configuration files, by default placed in $ONE_LOCATION/etc/vmm_kvm:

• Defaults file, specified in the default attribute in the driver specification line in oned.conf, usually $ONE_LOCATION/etc/vmm_kvm/vmm_kvm.conf. This file is home for default values for domain definitions (in other words, for OpenNebula templates). For example, if the user wants to set a default value for CPU requirements for all of their KVM domain definitions, simply edit the $ONE_LOCATION/etc/vmm_kvm/vmm_kvm.conf file and set a

  CPU=0.6

into it. Now, when defining a VM to be sent to a KVM resource, the user has the choice of “forgetting” to set the CPU requirement, in which case it will default to 0.6.

It is generally a good idea to place defaults for the KVM-specific attributes, that is, attributes mandatory in the KVM driver that are not mandatory for other hypervisors. Non mandatory attributes for KVM but specific to them are also recommended to have a default.

• Run Commands file, the $ONE_LOCATION/etc/vmm_kvm/vmm_kvmrc file holds instructions to be executed before the actual driver load to perform specific tasks or to pass environmental variables to the driver. The syntax used for the former is plain shell script that will be evaluated before the driver execution. For the latter, the syntax is the familiar:

  ENVIRONMENT_VARIABLE=VALUE

The following are template attributes specific to KVM, please refer to the OpenNebula user guide for a complete list of the attributes supported to define a VM.

Specify the boot device to consider in the OS attribute, using BOOT. Valid values for BOOT are fd, hd, cdrom or network, that corresponds to the –boot [a|c|d|n] option of the kvm command, respectively. For example:

    OS=[ 
      KERNEL = /vmlinuz,
      BOOT   = hd]

In general you will not need to set the following attributes for you VMs, they are provided to let you fine tune the VM deployment with KVM.

• type, This attribute defines the type of the media to be exposed to the VM, possible values are: disk (default), cdrom or floppy. This attribute corresponds to the media option of the -driver argument of the kvm command.

• bus, specifies the type of disk device to emulate; possible values are driver specific, with typical values being ide, scsi or pflash. This attribute corresponds to the if option of the -driver argument of the kvm command.

• target, name for the tun device created for the VM. It corresponds to the ifname option of the '-net' argument of the kvm command.

• script, name of a shell script to be executed after creating the tun device for the VM. It corresponds to the script option of the '-net' argument of the kvm command.

• pae: Physical address extension mode allows 32-bit guests to address more than 4 GB of memory:
• acpi: useful for power management, for example, with KVM guests it is required for graceful shutdown to work.

Format and valid values:

    FEATURES=[
        pae={yes|no},   
        acpi={yes|no} ]

Both pae and acpi default values can be changed in $ONE_LOCATION/etc/vmm_kvm/vmm_kvm.conf

The raw attribute offers the end user the possibility of passing by attributes not known by OpenNebula to KVM. Basically, everything placed here will be written literally into the KVM deployment file (use libvirt xml format and semantics).

  RAW = [ type = "kvm", 
          data = '<console type="stdio"><target port="1"></console>' ]

In order to test the KVM driver, the following template can be instantiated with appropriate values and sent to a KVM resource:

NAME     = KVM-TEST
CPU      = 1
MEMORY   = 128
OS       = [kernel="/path-to-kernel",initrd="/path-to-initrd",boot=hd ]
DISK     = [source="/path-to-image-file",clone=yes,target=hda,readonly=no]
NIC      = [mac="xx.xx.xx.xx.xx.xx"]