Virtual data center management with oVirt 3.4

In the world of virtualization, there's little doubt that cloud computing gets the lion's share of attention. Made popular by public services offered by Amazon and the OpenStack cloud platform, cloud computing remains an attractive option for many IT managers looking to consolidate their physical hardware and get their applications deployed as efficiently as possible.

But cloud may not always be the best answer. IT departments can tap into the benefits of virtualization without undergoing the sometimes-painful migration to cloud computing. Another answer lies in the realm of technology known as virtual data center management.

The short way of describing virtual data center management is "cloud computing without the elasticity." This may seem overly simplified, until you realize that all cloud computing is—and has ever been—a tool set to manage the deployment and maintenance of virtual machines. What makes cloud "cloud" are the additional features that enable developers and system administrators to spin up additional virtual machines in an automated way, usually based on demands from the applications themselves. This is the baseline description of elasticity, and elasticity is the secret sauce of cloud.

There are lots of instances of IT shops migrating their systems to public or private cloud platforms and proudly reporting that they are "in the cloud." If the applications and services that are running on these cloud systems are indeed taking full advantage of the automation and elasticity cloud affords, then they are accurate in their self-descriptions. But if they are not using elasticity, then essentially what they have created is a virtual data center.

This leads to the first big questions that should be answered: why go to the bother of setting up and deploying a cloud platform when you aren't going to use it properly? Why not use a virtual data center platform that has everything you need and is much easier to install and configure?

The virtual data center landscape

In the open-source arena, there are several tools that fit this description: XenServer, a CentOS-based distribution that uses XAPI as the core technology to manage virtual machines; Ganeti, Google's cluster-management platform that's designed to handle both KVM and Xen virtual machines; and Proxmox Virtual Environment, a Debian-based distro that's dedicated to KVM virtual machine and container management.

There are also proprietary systems out there: the ones that comes up the most are VMware vSphere and virtual machine management with Microsoft's HyperV. They are decent tools, but you will be paying quite a bit to keep your licenses for those platforms going.

Then there is oVirt, the virtual data center management platform that is the upstream for the Red Hat Enterprise Virtualization (RHEV) product and Wind River Open Virtualization.

oVirt is the very definition of a virtual data center management platform, enabling users to manage their virtual machines by coordinating those machines at whatever level they choose. Whole data centers of virtual machines can be managed, as well as clusters, virtual networks, physical hosts, and virtual machines ... right down to the individual disks being used. Management can be done either through the administrator web portal, or via the command-line interface, REST API, or the oVirt software development kit.

With all of these features, it is surprising to many in the oVirt community that it isn't more widely discussed. The user base is strong (since those who use oVirt typically are very loyal), but not as broad as one would think. But oVirt has started to gain much more attention in recent months, which is a nice change from its closed-source origins when it was a virtual unknown in the data center ecosystem.

The secret origin of oVirt

Seven years ago, oVirt started as a humble little virtual machine manager written in Python by developers at the Israeli firm Qumranet. This was the component that would eventually become oVirt Node, a minimal hypervisor host that can still be run independently from the rest of the oVirt platform today.

The rest of the oVirt components, however, were created with the purpose of developing a virtual data center platform that would run on Windows—not Linux. The oVirt Engine, which acts as the control center for the oVirt environment, was originally written in C# as a .NET application. Two years later, when Red Hat acquired Qumranet in late 2008, this was exactly the technology Red Hat gained: a fairly mature virtual data center management platform that happened to be proprietary and would initially only run on Windows.

This was not exactly an intuitive move by the world's biggest Linux company. But Red Hat did not let that situation linger. Even when it released RHEV 2.2 in 2010, the RHEV-Manager (the commercial counterpart to oVirt Engine) was a C# application that only worked on Windows, and the console was an ActiveX browser extension. From the end of 2008 to the end of 2011, oVirt never saw a lot of traction, from either developers or users.

That's because, even as there was an RHEV 2.x product on the market, there never was an "oVirt 2"—there was only the RHEV 2.0 series that was for a while proprietary. Until 2011, oVirt would essentially disappear, entering a chrysalis where it would ultimately metamorphose from a .NET-based closed-source application to one that was open source and written in Java.

And while those two years would prove to be a good thing for oVirt, it was not without cost: two years off the radar of the open-source community that would turn to other tools to get things done with their virtual machines.

The release of oVirt 3.0 in 2011, and the subsequent downstream release of RHEV 3.0 in early 2012, marked a huge transition from closed to open source, and re-introduced a very capable virtual data center manager to the open-source ecosystem. Since that time, oVirt has done a lot of catching up in the virtual data center arena and its latest releases are doing a lot to bring people on board.

Welcome to oVirt 3.4

Earlier this year, the latest major release of oVirt, 3.4, debuted with a slew of new features that are all designed to make it easier for users to configure oVirt and lower the barrier to entry for getting started with it.

One of the cooler features is the self-hosted engine, which will enable the oVirt engine to be run as a virtual machine on the host it manages. Hosted engine will solve the basic chicken-and-the egg problem of having your oVirt engine tied to a single machine that's never able to be migrated. Now, if needed, virtual machine administrators can migrate the VM on which the engine is installed to another host, which greatly helps with fault tolerance.

Thanks to efforts from IBM and its El Dorado Research Center in Brazil, oVirt 3.4 has PowerPC-64 support, which gives oVirt a cross-architecture capability not found in competing virtualization platforms.

In older versions, you could use lots of different kinds of storage in oVirt, but a single oVirt data center was always locked into a specific sort of shared storage. In 3.4, data center storage is either local or shared across a network, and shared-storage data centers can include multiple types of storage domains. This enables VMs that need to access several virtual disks to allocate these disks on different storage domains, such as NFS, iSCSI, or Fibre Channel.

Network configuration was also simplified in oVirt 3.4, particularly with multi-host network configuration. That enables the administrator to modify a network already provisioned by the hosts and to apply those network changes to all of the hosts within the data center that the network is assigned to. This not only reduces the number of steps required to reflect a logical network definition change, it also reduces the risk of having a host's network configuration not be synchronized with the logical network definition.

Building on the scheduler features that were introduced in oVirt 3.3, the 3.4 release capitalizes on the scheduler to apply affinity (and anti-affinity) rules to VMs that will manually dictate scenarios in which those VMs should run together on the same hypervisor, or separately on different hypervisor hosts. Power-saving rules can also be added to the scheduler, as well.

Scheduling improvements have also been added to oVirt Manager, which has the capability to flag individual VMs for high availability. In the event of a host failure, these VMs are rebooted on an alternate hypervisor host. In earlier versions, it was possible that the resultant utilization of a cluster during a host failure may either not be allowed or could cause a notable performance degradation when HA VMs are rebooted. The new HA VM Reservations feature in oVirt 3.4 serve as a mechanism to ensure that appropriate capacity exists within a cluster for HA VMs in the event the host on which they currently reside does unexpectedly fail.

Wrapping up

In the last year, the oVirt community has seen a steady growth in vitality. Its mailing list and IRC traffic is growing and the numbers on download traffic are seeing an upward trend as well. The community is also seeing more variety in the use cases deployed in production environments. The wallflower days of oVirt are definitely coming to an end, as people discover there's a free and open platform available to manage virtual machines at any scale.

[ Brian Proffitt works for Red Hat as the Community Manager for oVirt and co-Community Lead for Project Atomic. ]