This layer contains tools shipped with OpenNebula, such as the CLI or the scheduler, but also 3rd party tools that can be easily created using the XML-RPC interface or the OpenNebula client API.

A command line interface is provided with OpenNebula to manually manipulate the virtual infrastructure under OpenNebula. For more information about the CLI (command line interface) go here.

The Scheduler is an independent entity in the OpenNebula architecture, so it can be easily tailored or changed since it is decoupled from the rest of the components. It uses the XML-RPC interface provided by OpenNebula to invoke actions on virtual machines. The scheduler distributed with OpenNebula provides the following functionality:

• User-driven consolidation, the scheduler assigns VMs to those hosts that meets the capacity requirements of the VM (that can be adjusted to consolidate VMs).

• Matchmaking policy, to schedule a VM those resources that do not meet the requirements (boolean expression) are filtered out. Then a ranking process is made to select the best Host. This is done by applying the ranking expression defined in the VM template.

• The scheduler is built on a policy template, this template can be used to further tailor the Scheduler behavior.

The Haizea lease manager can also be used as a scheduling module in OpenNebula. Haizea allows OpenNebula to support advance reservation of resources and queuing of best effort requests (more generally, it allows you to lease your resources as VMs, with a variety of lease terms). The Haizea documentation includes a guide on how to use OpenNebula and Haizea to manage VMs on a cluster

The core consists of a set of components to control and monitor virtual machines and hosts. The core performs its actions (e.g. monitor a host, or cancel a VM) by invoking a suitable driver. The main functional components of OpenNebula core are:

• Request Manager, to handle client requests
• Virtual Machine Manager, to manage and monitor of VMs
• Virtual Network Manager, to manage virtual networks
• Host Manager, to manage and monitor physical resources
• Database, persistent storage for ONE data structures

The Request Manager exposes a XML-RPC Interface, and then depending on the invoked method a given component is called internally. The XML-RPC decouples most of the functionality in the OpenNebula core, from external components i.e. the Scheduler.

This component is responsible for the management and monitoring of VMs. The operations of the VM Manager are abstracted from the underlying hypervisor the use of plugable drivers.

The Transfer Manager (TM) is in charge of all the files transfers needed for the correct deployment of virtual machines. This includes the transfer of images to the cluster node selected for running the images' virtual machine, the transfer of the image from the cluster node to the image repository, the transfer of checkpoint files between cluster nodes for cold migrations or to the cluster front-end when the virtual machine is stopped, etc.

The Virtual Network Manager (VNM) is responsible for the handling of IP and MAC addresses, allowing the creation of virtual networks by keeping track of leases (a set form by one IP and one MAC valid on a particular network) and their association with virtual machines and the physical bridges the VM are using.

This component manages and monitors the physical hosts. Monitor and management actions are performed also through a suitable driver. The host monitoring infrastructure is flexible and can be extended to include any host attribute.

A persistent generic pool based on a SQLite3 backend is the core component of the OpenNebula internal data structures. This component provides OpenNebula with the scalability and reliability (in case of failure the state of OpenNebula is automatically recovered) needed in the management VMs.

Note that this information can be accessed through the SQLite3 interface to develop custom accounting applications.

OpenNebula has a set of pluggable modules to interact with specific middleware (e.g. virtualization hypervisor, file transfer mechanisms or information services), these modules are called Drivers. The communication between the core and the drivers is performed using a simple ASCII Protocol, which simplifies the development of new drivers. The ASCII Driver Protocol is like following:

• General format of a MAD message response:

ACTION RESULT ... INFO

where:

• ACTION: Describes the request to the Driver (e.g. DEPLOY) and it depends on the component (virtualization, monitoring or image management)
• RESULT: Describes the result of the performed action (SUCCESS or FAILURE)
• … (ellipsis): Custom message fields depending on the component
• INFO: Predefined field to provide additional information on the action performed

• Initialization and Finalization messages MUST be in the form:

INIT
FINALIZE