OpenNebula is an open-source cloud computing toolkit for managing heterogeneous distributed data center infrastructures.

The OpenNebula toolkit manages a data center's virtual infrastructure to build private, public and hybrid IaaS (Infrastructure as a Service) clouds. OpenNebula orchestrates storage, network, virtualization, monitoring, and security[1] technologies to deploy multi-tier services (e.g. compute clusters[2][3]) as virtual machines on distributed infrastructures, combining both data center resources and remote cloud resources, according to allocation policies. According to the European Commission's report about the future of cloud computing from a group of experts "... only few cloud dedicated research projects in the widest sense have been initiated most prominent amongst them probably OpenNebula ...".[4] The toolkit includes features for integration, management, scalability, security and accounting. It also emphasizes standardization,interoperability and portability, providing cloud users and administrators with a choice of several cloud interfaces (EC2 Query, OGFOCCI and vCloud) and hypervisors (Xen, KVM and VMware), and a flexible architecture that can accommodate multiple hardware and software combinations in a data center.[5] OpenNebula was a mentoring organization in Google Summer of Code 2010.[6] OpenNebula is sponsored by C12G.

OpenNebula

2.0 Architecture

The OpenNebula internal architecture can be divided into three layers: Tools, management tools developed using the interfaces provided by the OpenNebula Core. Core, the main virtual machine, storage, virtual network and host management components. Drivers, to plug-in different virtualization, storage and monitoring technologies and Cloud services into the core.

Tools
This layer contains tools distributed with OpenNebula, such as the CLI, the scheduler, the libvirt API implementation or the Cloud RESTful interfaces, and also 3rd party tools that can be easily created using the XML-RPC interface or the newOpenNebula Cloud API.

Command Line Interface

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

Scheduler
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 allows the definition of several resource and load aware policies. 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 OpenNebulaand Haizea to manage VMs on a cluster

OpenNebula Core
The core consists of a set of components to control and monitor virtual machines, virtual networks, storage 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 Transfer Manager, to manage VM images Virtual Network Manager, to manage virtual networks Host Manager, to manage and monitor physical resources Database, persistent storage for ONE data structures

Request Manager
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.

Virtual Machine Manager

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.

Transfer Manager
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.

Virtual Network Manager

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.

Host Manager
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.

Database
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 ofOpenNebula is automatically recovered) needed in the management VMs. Note that this information can be accessed through the SQLite3 interface to develop custom accounting applications.

Drivers
OpenNebula has a set of pluggable modules to interact with specific middleware (e.g. virtualization hypervisor, cloud services, file transfer mechanisms or information services), these adaptors are called Drivers.

A couple of months have passed since the release of OpenNebula 2.2 (Cats Eye) and we have been quite active since then. The next release of OpenNebula is getting in shape fast and a significant amount of new features are already in the repository. Lets start reviewing the not-so-glamorous new features. One of the main themes for the next release is database refactoring. The new DB backend of OpenNebula features a schema free (document-oriented) implementation of the data model on top of a SQL DB. This will give us enough flexibility to easily extend the attributes and resources

managed by OpenNebula at no performance cost. Also, the next release includes DB versioning and a tool to upgrade from previous versions of OpenNebula. Another important area of work has been networking. We have evolved the network manager component to provide out-of-the-box integration with typical VLAN technologies. In particular, youll be able to choose from 802.1Q VLAN tagging, Open vSwitch and simple isolation based on ebtables filters. Youll also be able to set up simple firewalling rules for each VM specifying black/white TCP/UDP port settings. The next release will also feature important improvements in VM management. Virtual Machine templates can now be stored in OpenNebula so you can easily instantiate pre-defined configurations, and share them with other users. This new VM Template pool along with the existing Network and Image will give users and administrators a very flexible and simple way to define and instantiate virtual infrastructures. We have also re-factored the Image Repository to adopt a pluggable architecture that can integrate any storage backend, with a filesystem-based repository provided in the next release. The Image Repository can be now further integrated with external catalogs. The next release will also showcase a preview of this hybrid cloud storage, that integrates Amazon S3 and OpenNebula, to download, contextualize and integrate S3 images in your local Image Repository. Sunstone has also received some attention from the team, being extended to accommodate all the new features and some rough edges have been polished. We have also added support for plug-ins, enabling the easy customization of the control panel. There is also a couple of new specific features for the interface: VNC access to VM instances through the web browser using noVNC; and graphical information about the health of your cloud. And last but not least, the multi-tenancy support for OpenNebula has been considerably improved with the addition of groups and access control lists (ACLs). This will provide great flexibility to share resources among users and to define user roles. Grounded in this new functionality, youll be also able to experiment with the new Virtual Data Center (VDC) manager. Using a muti-tier architectureyoull be able to aggregate multiple OpenNebulas (zones) and define within them multiple, isolated VDCs. Finally as you my have noticed from the title, there are so many new features (as well as changes in the database and internal APIs) that we have decided to upgrade the major versioning number of OpenNebula to 3. The changes in the public APIs are minimal and we expect that current applications will run without modifications on top of OpenNebula 3.0. OpenNebula 3.0 also includes contributions from several members of our community, such as CERN, FermiLab, and Harvard Universitys SEAS. A beta version of OpenNebula 3.0 (codename Iris) will be ready for testing by the end of June and its stable release is scheduled on July 20th. As usual, OpenNebula releases are named after a Nebula. The Iris Nebula (NGC 7023, Caldwell 4) is a reflection nebula in the constellation of Cepheus. We will appreciate your feedback on these new features. Thanks!

Scalable Architecture and APIs 3.0

OpenNebula has been designed to be easily adapted to any infrastructure and easily extended with new components. The result is a modular system that can implement a variety of Cloud architectures and can interface with multiple datacenter services. In this document we will review the main interfaces of OpenNebula (see figure 1 for an overview), their use and give pointers to additional documentation for each one. We have classified the interfaces in two categories: end-user cloud and system interfaces. Cloud interfaces are primary used to develop tools targeted to the end-user, and they provide a high level abstraction of the functionality provided by the Cloud. On the other hand, the system interfaces expose

the full functionality of OpenNebula and are mainly used to adapt and tune the behavior of OpenNebula to the target infrastructure.

Figure 1: OpenNebula Interfaces

1. Cloud Interfaces
Cloud interfaces enable you to manage virtual machines, networks and images through a simple and easy-to-use RESTAPI. The Cloud interfaces hide most of the complexity of a Cloud and are specially suited for end-users. OpenNebula implements two different interfaces, namely: EC2-Query API. OpenNebula implements the functionality offered by the Amazons EC2 API, mainly those related to virtual machine management. In this way, you can use any EC2 Query tool to access your OpenNebula Cloud. OCCI-OGF. This web service enables you to launch and manage virtual machines in your OpenNebula installation using the latest draft of the OGF OCCI API specification.

Use the cloud interface if you are developing portals, tools or specialized solutions for end-users. You can find more information at EC2-Query reference, and OCCI reference guides.

2. System Interfaces

2.1. The OpenNebula XML-RPC Interface

The XML-RPC interface is the primary interface for OpenNebula, and it exposes all the functionality to interface theOpenNebula daemon. Through the XML-RPC interface you can control and manage any OpenNebula resource, including virtual machines, networks, images, users, hosts and clusters. Use the XML-RPC interface if you are developing specialized libraries for Cloud applications or you need a low-level interface with the OpenNebula core. You can find more information at XML-RPC reference guide.

2.2. The OpenNebula Cloud API (OCA)

The OpenNebula Cloud API provides a simplified and convenient way to interface the OpenNebula core. The OCA interfaces exposes the same functionality as that of the XMLRPC interface. OpenNebula includes two language bindings for OCA: Ruby and JAVA. Use the OCA interface if you are developing advanced IaaS tools that need full access to the OpenNebula functionality. You can find more information at OCA-Ruby reference guide and the OCA-JAVA reference guide.

2.3. The OpenNebula Drivers Interfaces

The interactions between OpenNebula and the Cloud infrastructure are performed by specific drivers each one addressing a particular area: Storage. The OpenNebula core issue abstract storage operations (e.g. clone or delete) that are implemented by specific programs that can be replaced or modified to interface special storage backends and file-systems. Virtualization. The interactions with the hypervisors are also implemented with custom programs to boot, stop or migrate a virtual machine. This allows you to specialize each VM operation so to perform custom operations. Monitoring. Monitoring information is also gathered by external probes. You can add additional probes to include custom monitoring metrics that can be later used to allocate virtual machines or for accounting purposes Authorization. OpenNebula can be also configured to use an external program to authorize and authenticate user requests. In this way, you can implement any access policy to Cloud resources.

Use the driver interfaces if you need OpenNebula to interface any specific storage, virtualization, monitoring or authorization system already deployed in your datacenter or to tune the behavior of the standard OpenNebula drivers. You can find more information at the storage system, the information system and the Authorization system guides.

2.4. The OpenNebula DataBase

OpenNebula saves its state and lots of accounting information in a persistent data-base. OpenNebula can use MySQL or SQLite database that can be easily interfaced with any of DB tool. Use the OpenNebula DB if you need to generate custom accounting or billing reports. You can find more information at the database schema page.