Some years ago, Red Hat caused displeasure in the Linux community because the graphical administration tool for its own virtualization solution, RHEV, presupposed a Windows machine. This Microsoft legacy was a result of the 2008 Red Hat acquisition of the KVM hypervisor developed by Israeli KVM specialists Qumranet, along with what was at the time a nearly finished desktop virtualization product based on Windows.

Bye-Bye Windows

Although the Red Hat developers ported all the components of the management component, RHEV-M, from C# to Java in RHEV 3.0 [1], use of the Administrator Console for RHEV still officially required a Windows machine with Internet Explorer 7 or greater because the oVirt-based front end had still not mastered all of its predecessor's features.

Since Red Hat handed over oVirt to the community under the Apache Open Source license, development of the software has been continued under the umbrella of the oVirt project by SUSE, Canonical, Cisco, IBM, Intel, and others. Now, oVirt has the potential to do battle with commercial solutions by VMware, Citrix, and Microsoft as a powerful, free, alternative cloud management platform that is by no means capable of managing only Red Hat-based structures.

The oVirt project is based on many technologies developed by Red Hat with the kernel-based virtual machine (KVM) and the libvirt virtualization API. The first final and stable oVirt version (3.0) is contained as a technology preview in Red Hat's commercial virtualization solution RHEV 3.0 [1] that became available in January of this year.

RHEV Setup

An installation of RHEV for servers typically consists of a single (or multiple) hypervisor host (RHEV-H), a management system (RHEV-M) that manages either RHEV- or RHEL-based hypervisor systems, as well as a host for the administration console and PC (Windows or Linux) for the user portal. In addition, you would have one or more storage systems (SAN, iSCSI).

The respective minimum and recommended hardware requirements are listed on Red Hat's promotional page [2] when you download the evaluation version of RHEV 3. Red Hat suggests a minimal setup for test purposes that consists of an Enterprise Virtualization Manager Server (RHEV-M) with a local ISO domain and a hypervisor host. According to Red Hat, the former should be, if possible, a RHEL6 system with quad-core processor, 16GB of RAM, 50GB of local disk space, and a 1Gb NIC, which provides the ISO domain mentioned earlier.

As a client for the Admin Console, Red Hat recommends a Windows 7 system. This just leaves the mini-hypervisor, RHEV-H, for the virtualization host. This can be downloaded as a 172MB evaluation version from Red Hat, but it can also be, says Red Hat, RHEL 6 (and thus also CentOS 6) or Fedora 17. The hardware recommended by Red Hat is a dual-core server with 16GB of RAM, 50GB of memory, and a 1Gb NIC. However, the CPU must be a 64-bit system with a mandatory virtualization extension: either AMD-V or Intel VT.

In contrast to RHEV 2.2, RHEV 3 is no longer based on RHEL 5, but on RHEL 6, which offers a number of advantages KVM-wise. For example, guests can use up to 64 virtual CPU cores and up to 2TB of memory. Additionally, the RHEL6 kernel supports all current KVM technologies, such as KSM (kernel shared memory), VHostNet, transparent huge pages (THP), or X2APIC.

One further component is missing in the RHEV virtualization toolbox: "RHEV for Desktops," which is an add-on for RHEV server that supports a virtual desktop infrastructure (VDI). Communication between a client or thin client and a RHEV-virtualized desktop operating system is handled by the Spice protocol developed by Qumranet, which Red Hat has now improved so that, for example, users can run any USB 1.1/2.0 device on a client, with Spice passing it through to the remote virtualized desktop operating system.

Multi-Component Glue

The new oVirt version 3.1 [3] is available on the oVirt project homepage. The package contains the JBoss application server 7.0 as the foundation for the oVirt engine, the KVM hypervisor, an SDK written in Python, an admin and a user portal as web applications, and the components required to create the Libvirt VDSM nodes/host. Each oVirt node has its own hypervisor, its own storage pool, and its own disk images.

oVirt nodes communicate through a stack comprising libvirt and the oVirt host agent (VDSM) with the oVirt eEngine, which ultimately manages the array of computers. The virtual guest systems use oVirt guest agents written in Python to tell the oVirt engine, among other things, which IP address they use, what applications are installed on them, or how much memory they need.

Other components include the Java-based web interface for setting up, configuring, and managing hypervisors and guest systems; the user portal, with which users log on to the guest systems; and, finally, the REST API that lets your own programs or scripts tap into the oVirt engine. Additionally, a command-line interface is available. The back end of the oVirt engine stores all of the data and configurations in a PostgreSQL database and authenticates users via OpenLDAP or Active Directory. Independent of RHEV and Red Hat, oVirt aims to establish itself as a free alternative to VMware and Citrix for "orchestrating" cloud and virtualization environments.