Plan B

oVirt

Some administrators might be more familiar with oVirt (Figure 2) under the name of its commercial variant, because oVirt is the open source foundation of Red Hat Enterprise Virtualization (RHEV; Figure 3).

Figure 2: oVirt is Red Hat's virtualization manager, offering many features that can also be found in OpenStack. © Red Hat

Figure 3: Those who need an option with support rely on oVirt's commercial distribution RHEV. © Red Hat

Red Hat continues to be one of the most active OpenStack developers and thus one of the few companies that still have a commercial OpenStack distribution in its portfolio – Red Hat OpenStack Platform. However, RHOP is hardly likely to compete with its sibling RHEV internally, which means that oVirt is a plain vanilla virtualization solution for small environments, although the feature set is quite impressive.

The linchpin of the product is a controller node that runs all oVirt basic services. Red Hat fans have a clear advantage because oVirt is only available in packages for RHEL 8 and CentOS Stream 8. However, it will run on AlmaLinux 8 and Rocky Linux 8. After installing the basic components, you first need to assign disk space to the new oVirt instance – with a cornucopia of options from which to choose, including NFS, GlusterFS, Fibre Channel, and other POSIX-compatible filesystems.

Ceph is interestingly missing from the list of storage drivers for oVirt, which is surprising because Ceph has long established itself as a rock-solid solution for scalable storage, even outside of OpenStack. Unlike OpenStack, Ceph can be set up and ready for operation in a fully automated manner in a fairly short time. Unlike OpenStack, Ceph causes very little overhead in everyday administration and takes care of most of its problems itself to boot.

If you dig deeper into the documentation, you will find out how Red Hat imagines the Ceph connection in oVirt, and you will end up with – surprise – an OpenStack component. As you know, the service responsible for storage in OpenStack is named Cinder. It can run quite well without the rest of the OpenStack components, essentially communicating with the storage back ends in the background to create volumes. Cinder then outputs their paths to requesting instances such as oVirt.

If you combine oVirt and Ceph, you also get a little piece of OpenStack, but the overhead involved in using the cinderlib driver in oVirt doesn't even begin to compare with the complexity of the connection in OpenStack itself.

Many Features

In addition to the controller, the administrator of an oVirt installation also provisions any number of virtualization hosts (i.e., the actual compute nodes). The nodes communicate with their controller through a controller agent process and thus know what they have to do. The reward for this effort is a small but fine virtualization solution that can even be extended to include a rudimentary kind of self-service over a Lightweight Directory Access Protocol (LDAP) connection. However, oVirt does not envisage complex virtual network setups. On the one hand, this facilitates troubleshooting; on the other hand, it drastically reduces the number of possible sources of error.

oVirt also integrates a feature that many admins miss in OpenStack right out of the box. The data warehouse writes metrics data with thousands of values in the background and makes them directly available in oVirt through interfaces, which makes it far easier to connect to monitoring or trending systems. An oVirt exporter can even export data from oVirt's data warehouse in a format suitable for Prometheus [1].

In terms of everyday functionality, oVirt leaves little to be desired. Ready-made operating system images can be defined in this way, and it is possible to create snapshots of existing VMs, making backup and restore operations far easier. All told, oVirt is a very powerful OpenStack alternative, especially for small setups. Admins who just need virtualization should keep that in mind.

DIY Cluster: Linux-HA

It may be down to my nostalgic feelings that I've even mentioned the virtualization cluster archetype; however, it could also be because a setup of this type is the easiest and fastest way to set up a few highly available VMs as quickly as possible.

Considering the complexity of solutions like OpenStack and even oVirt, the Linux-HA (high availability) stack is definitely not the most complex product under the sun. Additionally, Red Hat has put a great deal of work into getting the former horrors of Heartbeat 2 and its successor Pacemaker under control in recent years. Today, hacking XML files is just as superfluous as memorizing cryptic shell commands to feed the cluster with the resources you want it to manage.

At the same time, the Linux-HA stack and all its components are more or less available wherever you look. Red Hat (RHEL) and SUSE Linux Enterprise (SLES) distribute it in the form of an add-on, and matching packages are also included with Ubuntu and Debian. In other words: If you have three systems running a popular Linux distribution, you can quickly get a Pacemaker cluster up and running. Countless how-tos online now explain how this works in great detail.

Pacemaker has probably not been used for any task as regularly over the past 15 years as it has been for running virtual instances. The VirtualDomain resource agent has long since proved its value and is now generally thought of as being reliable and stable. Connecting external storage services such as Ceph is almost easier in a setup of this type than with oVirt. You just need to enter the path to your RADOS block device (RBD) in the libvirt definition of the respective instance, and you are ready to go.

On top of that, Pacemaker handles at least basic balancing of resources easily. For example, a three-node cluster can be made to distribute three VMs evenly across the three servers. You can even have a Pacemaker instance shut down should a server fail. Although this method is not a comprehensive placement strategy, like those that exist in OpenStack or oVirt, it is often good enough for small environments.

In this scenario, however, administrators do have to do without many goodies, such as self-service over a web user interface (UI) or virtual networking by SDN. Colorful wizards for setting up new instances are also missing; in fact, the package does not even include image management. If you need any of these features, you are undoubtedly better off with oVirt or Proxmox, but if you really only want to virtualize a few VMs, Pacemaker will get you there quickly. Today, Pacemaker even has automation modules (e.g., Ansible) that let you handle tasks completely automatically.