VMware hypervisors of the ESX family (3.x, 4.x and 5.0) are fully, out-of-the box supported by the latest versions of OpenNebula(3.0+). If you have a server farm based on any of the ESX versions, then you can make use of OpenNebula to better manage your physical (and virtual) resources in order to build a private cloud and provide virtualized environments. OpenNebula is the most powerful open-source alternative to VMware datacenter and cloud suite, delivering enterprise-class functionality, stability and scalability with broader platform support and integration capabilities.
So, what can you do with OpenNebula to improve the experience managing your VMware hypervisors? A little taste in the following bullets:
- Manage multiple storage backends. You can have multiple storage sources (datastores) serving the same host, or you can group your hosts in clusters served by different storage servers. For instance, you can have the “Fast deployment” cluster and the “Better I/O” cluster, the former served by a shared filesystem and the latter by a ssh based datastore. Scheduling policies can be adjusted per VM to better use your resources.
- Manage virtual networks. OpenNebula ships with network drivers that allows for an automatic management of VMware port groups. In this fashion isolated, VLAN based virtual networks can be managed through OpenNebula and operated by VMware hypervisors.
- Virtual Machine (VM) lifecycle management. All the states of the VMs can be manipulated from OpenNebula: submit, stop, resume, cancel, shutdown, restart.
- Powerful GUI. Sunstone provides a window to both your physical (ESX farm) and virtual infrastructures. VMware resources can be managed through a web browser. Hello, Linux!
- Complete private cloud API. Manage your physical and virtual resources through OpenNebula rich native API. Script your tasks to automate everyday operations.
- Access your virtual resources running on top of ESX hypervisors through public cloud APIs: Amazon EC2 (de facto standard) and OCCI (de jure standard).
- Offer access to their virtual resources to your end users via a neat GUI: OpenNebula Self-service.
- Cloudbursting. Offload your services’ peak demands to a public cloud provider.
- Enjoy multi-tenancy on your virtual resources. Use Virtual Data Centers (VDCs) to isolate your computing resources to be used by members of different entities. Manage multiple OpenNebula instances in a centralized dashboard: oZones GUI.
- Role based user management. Manage permissions of your users regarding physical and virtual resources. Fine tune permissions using Access Control Lists.
- External authorization modules. Use your in-house LDAP or Active Directory user base to authorize virtual resources. No need to replicate this information in OpenNebula, it will pull the information for you.
Thus, OpenNebula is a good choice to manage ESX servers, and comes with many other goodies. For instance, it is compatible (simultaneously) with servers using other virtualization platforms, like for instance XEN and/or KVM. Also, you will be using a flexible platform that fits into your environment, and an open solution (so avoiding vendor lock-in), based on standards and interoperable with other private and public clouds.
Claiming VMWare support in OpenNebula borders on fraud. Your own “Sandbox” image for VMWare has internal evidence that the the included image was hacked in by hand after onevm created it wrong. The documentation appears to be aspirational, as it describes syntax that does not work. It is very easy to end up with VM’s that OpenNebula thinks are in “BOOT” state forever, even though VMWare denies knowledge and the datastore directory for the VM only has *.vmdk files in it (i.e. not the essential .vmx)
We’ve received several comments from users, and it tends to be positive feedback. I’m saying this because we are pretty sure that the Sandbox works as expected, having being tried by us and also other people. Let us know where the documentation has syntax errors, please redirect your findings regarding errors and other comments to the users mailing list so we can discuss them.
A few years later and I agree with the previous poster. It is extremely difficult getting this product working with the VMware type. Perhaps users with vCenter have better luck. But if you’re willing to pay that much for vCenter then don’t invest time in OpenNebula. The vmware drivers are commented out to begin with and require a hardcoded password in one of the config files. Then the products attempts to make data disks on the remote machine at locations at locations that don’t exist.
It’s incredibly frustrating.
The ESX drivers of OpenNebula have indeed limitations, like the hardcoded password which is important depending on the environment. We are shifting our attention to interact purely with vCenter, which OpenNebula complements since the former is a infrastructure virtualization tool and the latter is a cloud management platform.
The issue with the creation of data disks in locations that do not exist is most likely a configuration issue. We are happy to help in the context of the community to hunt down this misconfiguration, please use the OpenNebula forum to explain the problem you are experiencing.