OpenNebula internal architecture can be divided into three layers:

• Tools, management tools developed using the interface provided by the OpenNebula Core.
• Core, the main virtual machine and host management components.
• Drivers, to plug-in different virtualization technologies into the core.

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 ONE client API.

A command line interface is provided with OpenNebula to manually manipulate the virtual infrastructure under ONE. 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 ONE to invoke actions on virtual machines. The scheduler distributed in the Technology Preview 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 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
• 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.

More information about the XML-RPC methods and parameters can be found here.

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.

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 attribute (see the Install and Configuration Guide for more details.

A persistent generic pool based on a SQLite3 backend is the core component of the OpenNebula internal data structures. This component provides ONE 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 Middleware Access Drivers (MAD). The communication between the core and the drivers is performed using a simple ASCII Protocol, which simplifies the development of new drivers. The ASCII MAD Protocol is like following:

• General format of a MAD message response:

ACTION RESULT ... INFO

where:

• ACTION: Describes the request to the MAD (e.g. POLL). Depends on the component
• 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