The first steps with OpenNebula are towards the realization of a private cloud. A private cloud does not expose any API, and every resource is used for internal purposes only. When cloud resources are available, whether exclusively or not, to third-party users through a predefined set of APIs, it is named a public cloud. When you use external resources to improve your cloud, or you expose to third-party users your own local resources or both, it is called a hybrid cloud.
Starting with the private cloud, we can identify a set of features, as follows:
User management: It is possible to configure multiple users, who will have access only to their own instances, the ability to account for used resources, and with limits enforced by quota
VM Image management: Every disk image is registered and managed by a centralized image catalog
Virtual Network management: It is possible to define multiple networks bonded to different physical interfaces, with either static or dynamic IP address assignment
Virtual Machine management: Every machine has its own set of characteristics (for example, CPU, memory, disk storage, and virtual network) and can be launched under every available hypervisor of our cluster
Service management: A group of virtual machines can be grouped for being deployed together at boot time, and every virtual machine can be configured at boot time, without the need to assign different disk images for similar machines
Infrastructure management: The physical hosts can be managed alone or grouped on independent clusters, and it is useful when you have a heterogeneous environment
Storage management: The support for most common storage solutions is found in data centers such as FibreChannel, iSCSI and shared storage such as Network Attached Storage (NAS) with specific support for optimal disk image management
Information management: Every host and every virtual machine is actively monitored every few seconds, and it is already available in integration with standard monitoring tools such as Ganglia
Scheduling: Virtual machines are deployed on host nodes following specific user requirements and resource-aware policies, such as packing, striping, or load-aware
User interface: It includes the command-line tools available for managing every aspect of OpenNebula (for example, cluster status, virtual machines status, image repository, and so on)
Operations center: Most of the information and tasks available from the command line are available on web interfaces browsable with any modern web browser on any operating system (even Android smartphones or tablets)
For a Hybrid cloud, which uses both local and remote resources, the two main features available are as follows:
Cloud-bursting: It is the ability to add computing resources to your local infrastructure, using external resources, in order to meet peak demands or implement high-availability/disaster recovery strategies. This is essential for having a flexible and reliable infrastructure.
Federation: It is the ability to combine together different clusters, dislocated in different physical positions, enabling higher levels of scalability and reliability.
For a Public cloud, the main feature is exposing the cloud resources to externals with one or more standard interfaces, such as the cloud interfaces that enable the reachability of cloud resources, in a secure way, to external users, with OCCI and EC2 standard API interfaces.
As in any other open source project, OpenNebula does not reinvent the wheel and makes efficient use of existing open source technologies for its foundations.
The first adopted OpenNebula hypervisor is Xen (http://www.xen.org/). It has been a unique leading open source virtualization technology for many years. Today, it is still one of the most advanced virtualization platforms, maintained by over 50 vendors, including AMD, Cisco, Dell, Fujitsu, HP, IBM, Intel, Novell, Red Hat, Samsung, and Citrix.
Besides its use as a hypervisor in OpenNebula, Xen is also used standalone by many Internet hosting companies such as Amazon EC2, Linode, and Rackspace Cloud. It was originally distributed as a Linux patchset, but is nowadays included in main GNU/Linux distributions such as SuSe, RedHat, and Debian.
Xen is composed of the following three modules:
Hypervisor: The core component responsible for scheduling and executing all the virtual machine instances currently running.
Dom0: It is a privileged virtual machine running the base system and having direct hardware access. It is used to manage all the other deprivileged instances.
DomU: An unprivileged virtual machine running on the hypervisor and having access only to virtual resources exposed by Dom0.
Before the introduction of specific Intel/AMD CPU support for virtualization, Xen used a form of virtualization known as paravirtualization, meaning that virtual machines required a modified operating system if they were to run well with negligible virtualization overhead.
Without specific Xen support it was not possible to execute arbitrary operating systems as virtual machines.
Nowadays, with the help of specific CPUs' virtualization support, the guest operating system does not need any modification to run. Hence, it is possible to run any Linux, Windows, *BSD, or Solaris version with good performance.
After the Xen dominance in the past, the Kernel-based Virtual Machine (KVM) has grabbed more attention from the public in recent years (http://www.linux-kvm.org/). It has been directly integrated into the mainline kernel sources from release 2.6.20 of February 2007 and has been readily available in every GNU/Linux distribution from that point on.
KVM was being initially developed by a techie start-up, Quramnet, bought in 2008 by RedHat, and is now actively maintained by Linux developers all around the world.
The KVM design is another interesting point, because KVM by itself is only an interface available to user space programs that can be called through the /dev/kvm special system file. For similar reasons, another open source project has been ported to support the KVM interface in gaining a full virtualization environment, QEMU.
Quick Emulator (QEMU), which can be accessed at http://wiki.qemu.org/, is a famous CPU emulator developed by Fabrice Bellard (one of the most surprising open source developers in the world). It has also laid the foundation for many other virtualization platforms, such as Xen and VirtualBox.
Over time, we have been introduced to the QEMU features. It includes support for the most common hardware devices, such as serial port, network card, PCI-ATA interface, USB controller and so on. Now, it has quickly become one of the first user space virtual machine emulators.
Thanks to the virtualization hardware support implemented by both Intel and AMD on their CPUs, the QEMU project forked in KVM to natively support those hardware extensions.
As in Xen, KVM supports paravirtualization thanks to the implementation of VirtIO devices. Instead of emulating real hardware like standard QEMU does, special devices using an API for virtual I/O result in better performances. Thus, the objective to provide a standardized set of hardware for every hypervisor is fulfilled. VirtIO devices are supported natively by recent Linux releases, and their downloadable drivers are available even for Windows. The usage of VirtIO for storage and network devices is strongly suggested.
Finally, the latest abstraction layer in a KVM/XEN virtualization stack is Libvirt (http://libvirt.org/). Libvirt is a collection of software, developed by RedHat, which provides an API interface for any major programming language that should be used for the following:
VM management: To control the complete life cycle of a virtual machine, including monitoring and migration.
Remote machine support: To reach and control remote hosts with a simple SSH tunnel or a more advanced SSL protocol.
Storage management: To create disk images in various formats, management of LVM groups, raw devices, and iSCSI.
Network interfaces management: To set up new bridges, VLANs, and bond devices. Automatically manage iptables for Network Address Translation (NAT) virtual machines.
In recent releases, Libvirt has included support for the major hypervisors available, becoming the de facto standard tool for managing virtual machine instances.
Finally, OpenNebula includes support for a range of VMware hypervisor versions (http://www.vmware.com/products/datacenter-virtualization/), that including the following:
VMware ESXi: It is a free (not open source) hypervisor, the simplest of the whole family, and natively includes only a command-line interface, and runs on its own kernel (not on Linux, as Xen/KVM do). Hence, the hardware support is pretty limited or highly optimized, depending on how you see it.
VMware ESX: It was the mainline product before ESXi. It includes a Java web interface, and it is available under commercial license only.
VMware Server: It is a free (not open source) hypervisor, available for installation on Linux and Windows; it includes a Java web interface such as ESX, but with fewer features.
VMware hypervisors historically offer better performance and are better integrated with Windows virtual machines. However, nowadays there is practically no relevant difference from the other two open source hypervisors. Maybe, in some environments, VMware hypervisors are required due to strict software certification licenses, which are not so easy to circumvent in Enterprise software.
We will mainly take into consideration VMware ESXi because of its Xen-/KVM-like architecture than the other two VMware products considered independently. However, keep in mind that the infrastructure used by OpenNebula is common.
Note
Remember that VMware ESXi does not have out-of-the-box support for every kind of hardware that Xen/KVM has, thanks to the Linux kernel. Hence, you should check the online VMware compatibility guide at http://www.vmware.com/resources/compatibility/search.php or ask your hardware supplier before buying new hardware, otherwise you may not even be able to install it.