Next version of OpenNebula -4.10- is going to be a special release. It will be the first release that will be able to automatically import an existing infrastructure. This will become a reality with the new vCenter drivers and the auto import feature of Clusters and Virtual Machines from a vCenter installation.

The concept of the vCenter drivers is akin to the hybrid cloud approach in the sense that OpenNebula will delegate a number of aspects to vCenter, instead of pursuing the management of almost every aspect as it traditionally does with the three supported hypervisors, XEN, KVM and VMware ESX. These aspects are the storage management, scheduling among ESX hosts -both of which are left to VMware DRS component, although the OpenNebula scheduler still choses the vCenter cluster where the VM should be instantiated in- and network management. OpenNebula will use pre defined Virtual Machine Templates existing in the vCenter set up to launch Virtual Machines, very much like it does in its hybrid drivers to access Amazon EC2, IBM SoftLayer and Microsoft Azure, although offering much more features like for instance VNC support and more lifecycle actions supported (in fact, all of them except migrate).

OpenNebula vCenter Integration Architecture

This upcoming OpenNebula integration will leverage vCenter advanced features such as vMotion, HA or DRS scheduling provided by the VMware vSphere product family. On top of it, OpenNebula will expose a multi-tenant, cloud-like provisioning layer, offering virtual data centers, datacenter federation or hybrid cloud computing to connect in-house vCenter infrastructures with public clouds. In this manner, adopters will take a definitive step toward liberating their stack from vendor lock-in.

 The Technical View 

The VMware vCenter drivers enable OpenNebula to access one or more vCenter servers that manages one or more ESX Clusters. Each ESX Cluster is presented in OpenNebula as an aggregated hypervisor, i.e. as an OpenNebula host. Note that OpenNebula scheduling decisions are therefore made at ESX Cluster level, vCenter then uses the DRS component to select the actual ESX host and Datastore to deploy the Virtual Machine.

As the above figure shows, OpenNebula components see two hosts where each represents a cluster in a vCenter. You can further group these hosts into OpenNebula clusters to build complex resource providers for your user groups and virtual data centers in OpenNebula.

Virtual Machines are deployed from vCenter VM Templates. There is a one-to-one relationship between each VMware VM Template and the equivalent OpenNebula Template. Users will then instantiate the OpenNebula Templates where you can easily build from any provisioning strategy (e.g. access control, quota…). Therefore there is no need to convert your current Virtual Machines or import/export them through any process; once ready just save them as VM Templates in vCenter. After a VM Template is cloned and booted into a vCenter Cluster it can access VMware advanced features and it can be managed through the OpenNebula provisioning portal or through vCenter (e.g. to move the VM to another datastore or migrate it to another ESX). OpenNebula will poll vCenter to detect these changes and update its internal representation accordingly.

Check out the following screencast to see how easy it is to import an existing vCenter infrastructure into OpenNebula (use full screen and the higher resolution settings for optimal view).

 The Enterprise View

These drivers are oriented to companies willing to keep VMware management tools, procedures and workflows. For these companies, throwing away VMware and retooling the entire stack is not the answer. However, as they consider moving beyond virtualization toward private cloud computing, they can choose to either invest more in VMware, or proceed on a strategically rewarding path of open.

So stay tuned for the upcoming OpenNebula 4.10 for a new standard for easiness, efficiency and robustness in the cloud computing paradigm.