Following Up on Events

The basic principle is, if an OpenNebula user wants to know about changes on a virtual machine, a host, the configured networks, users, groups, or images, they can add their own scripts to the execution sequence. You store your tools in the /var/lib/one/remotes/hooks directory (for Debian, /var/lib/opennebula/remotes/hooks).

To define the events for which you need a response, the cloud administrator identifies the triggering object and event in Table 1 or Table 2 and enters it in /etc/one/oned.conf. For example, Listing 1 registers the shell script from Listing 2 to measure VM uptimes.

01 VM_HOOK = [
02     name      = "vm_switchon",
03     on        = "RUNNING",
04     command   = "account.sh",
05     arguments = "on $ID" ]
06
07 VM_HOOK = [
08     name      = "vm_switchoff",
09     on        = "STOP",
10     command   = "account.sh",
11     arguments = "off $ID" ]
12 [...]

01 #!/bin/bash
02
03 ACCOUNTING=/var/log/one/accounting.log
04
05 case "$1" in
06     "on"|"off")
07         mode=$1
08         shift
09         ;;
10      *)
11         echo "$0 error: wrong mode." >&2
12         exit 1
13         ;;
14 esac
15
16 if [ "$1" = "" ]
17 then
18     echo "$0 error: ID missing." >&2
19 fi
20
21 id=$1
22 shift
23
24 echo "$id $(date +%s) $mode" >> $ACCOUNTING

The VM_HOOK construct can appear more than once in the configuration. The on parameter defines the event to which OpenNebula responds (Listing 1, lines 3 and 9). The command entries specify the script to be called; arguments defines a string containing its call parameters. As connoisseurs will immediately see from the syntax, the IaaS management system itself is written in Ruby, but in terms of scripting languages, admins have a choice.

The shell script in Listing 2 checks (lines 5 to 9) for a running VM and then (in line 24) records the Unix epoch timestamp, along with the VM ID, in a configurable logfile. With an Awk script that reads logfiles and parses values, you could easily discover the total uptime of each VM and pass the results on to billing software, a department, or a customer of the IaaS cloud, for example.

The $TEMPLATE Variable

The example passes parameters only in a very simple way. To discover more information about the affected resources, users can pass the content of the $TEMPLATE variable to the script. It uses a kind of XML dialect to store a wide variety of details about the VM, the network, or the storage system. To avoid having to line up the big guns in the form of an external XML parser, the developers provide a tool that divides the content into handy key-value pairs and filters the results. For example, the following bash snippet:

X=/var/lib/one/remotes/datastore/xpath.rb
mem=$($X -b $template HOST_SHARE/MAX_MEM)

returns the contents of the <HOST_SHARE><MAX_MEM> container below the root node. This is the field to which OpenNebula sends the value for total available memory on the virtualization host; Listing 3 shows an example with a number of values.

01 <HOST>
02   <ID>1</ID>
03   <NAME>one-sandbox</NAME>
04   <STATE>2</STATE>
05   <IM_MAD>kvm</IM_MAD>
06   <VM_MAD>qemu</VM_MAD>
07   <VN_MAD>dummy</VN_MAD>
08   <LAST_MON_TIME>1377716985</LAST_MON_TIME>
09   <CLUSTER_ID>-1</CLUSTER_ID>
10   <CLUSTER/>
11   <HOST_SHARE>
12     <DISK_USAGE>0</DISK_USAGE>
13     <MEM_USAGE>65536</MEM_USAGE>
14     <CPU_USAGE>10</CPU_USAGE>
15     <MAX_DISK>0</MAX_DISK>
16     <MAX_MEM>502568</MAX_MEM>
17     <MAX_CPU>100</MAX_CPU>
18     <FREE_DISK>0</FREE_DISK>
19     <FREE_MEM>259512</FREE_MEM>
20     <FREE_CPU>87</FREE_CPU>
21     <USED_DISK>0</USED_DISK>
22     <USED_MEM>243056</USED_MEM>
23     <USED_CPU>12</USED_CPU>
24     <RUNNING_VMS>1</RUNNING_VMS>
25   </HOST_SHARE>
26   <VMS>
27     <ID>16</ID>
28   </VMS>
29   <TEMPLATE>
30     <ARCH><![CDATA[x86_64]]></ARCH>
31     [...]
32   </TEMPLATE>
33 </HOST>

Monitoring as the Main Application

This simple interface provides a variety of options: If you are prepared to take a detour, in the form of polling logfiles or status files, you can tie in an existing availability monitoring system like Nagios or Zabbix. Alternatively, OpenNebula itself includes a simple performance monitoring system in the form of Ganglia [10] that lets the system administrator keep an eye on important system parameters, such as CPU load or free memory.

If you hook into the CREATE event of a VM, you can install the monitoring agent software via configuration management, or you can roll out a complete application using a continuous integration trigger. Puppet, Chef, and Jenkins offer interfaces for this, and administrators can control them using wget or curl.