oVirt: Open Source Virtualization for the datacenter

oVirt is a complete Open Source virtualization solution based on Linux, Libvirt and KVM. It aims to be a VMware vSphere alternative. Let’s take a look at what it is and if this solution is right for your needs.

What is oVirt?

oVirt (open Virtual datacenter) is an open source project that aims to compete with VMware vSphere. It is the upstream project for Red Hat Virtualization (former Red Hat Enterprise Virtualization aka RHEV).

oVirt provides a complete virtualization solution built on QEMU/KVM, wrapped by Libvirt. With this software you can easily create a cluster of physical machines where you can run Virtual Machines on. oVirt essentially supports the same guest operating systems as QEMU/KVM.

You can use multiple storage backends simultaneously, including: GlusterFS, NFS, iSCSI, FC or even local (you may want to use this last one in very few cases). While networking virtualization is handled by OVN.

oVirt architecture primer

oVirt isn’t as complicated as it seems, but there are many moving parts in this solution and often times they are managed outside of oVirt. For starters you need to be concerned only with two entities:

• Nodes: are machines where the hypervirsor and the ovirt service (VSDM) runs on. Nodes can be based on CentOS, Fedora and provisioned manually; or you can use ovirt-node a custom-tailored distribution to run oVirt.
• Engine: is a machine that coordinates the cluster (much like vSphere vCenter). There can only be one engine instance in any cluster unless you have a high-availability Engine. You can’t install an Engine on a Node, but you can use a Self-hosted Engine, an Engine virtual machine running inside the cluster.

To get started you will need at least one node and one engine. Although you can get started with one node, the official documentation suggests a minimum of three nodes. In my experience setting up a one-node-cluster is daunting, although it has improved over time, and will generate many problems that a beginner system administrator may not be able to solve.

oVirt present and future

oVirt was initially developed by Qumranet and was called Solid ICE. Following Red Hat acquisition of Qumranet, Red Hat decided to change the name and continue the development of what would later become oVirt.

Up until recently oVirt has been plagued by a clunky, unresponsive web interface. This has scared most people away in the past, hence in version 4.2 the web UI has been completely rewritten to accommodate modern use.

Thanks to this we can draw a line between oVirt/RHV versions:

• prior to version 4.0: clunky interface, somewhat unstable, bad documentation.
• between 4.0 and 4.2: a major effort was put in creating new foundations for the project, the stability was greatly improved, documentation still lacking.
• 4.2 and above: a new modern web UI based on PatternFLY was introduced, the system is now much more usable and comparable to vSphere.

Although the oVirt documentation is still lacking in many ways, there is an ongoing effort to renew it and make it more standard. (Keep it up!)

oVirt major features/downsides

oVirt is packed with many great features, in particular it has:

Virtualization features

• an Engine that orchestrates a cluster.
• a “Data Warehouse” which collects and stores metrics of your cluster over time.
• the possibility to run the Engine as a virtualized appliance (much like vCenter Appliance).
• backups, snapshots, template versioning, live migration, high-availability VMs.
• support for SPICE and VNC consoles.
• support for quotas and pools for VMs.

Networking features

• support for virtual, isolated networks.
• virtual networks backed by OVN.
• vNIC profiles.

Storage features

• support for a wide range of storage backends:
  • GlusterFS
  • NFS
  • iSCSI
  • FC
  • POSIX-compliant FS
• It works best with GlusterFS.
• It can do thin/thick provisioning.
• uses the concept of “Storage Domain”, you can move your disks freely around them.
• storage quotas.
• needs a Storage Domain dedicated to ISOs.
• no easy way to upload ISOs.

Other remarkable features/downsides

• a lightweight OS (ovirt-node) with a great setup wizard can be used to install a cluster.
• Open Source Software backed by Red Hat.
• it runs on Linux: Fedora, CentOS.
• it can be difficult to run on one node only.
• dashboard only works if you have Data Warehouse.
• has a “VM Portal” for non-administrators to use.
• integrates well with Foreman/Satellite, ManageIQ/Red Hat CloudForms.

oVirt requirements and comparisons

There’s no perfect solution. But there are solutions that best fit certain scenarios.

Compared to vSphere

If you’re looking for a vSphere alternative, oVirt is for you. oVirt can easily scale to hundreds of nodes. Know that there is a paid version, RHV, that includes Red Hat support. If you decide to go for oVirt rather than RHV, be prepared to roll your own sleeves. Although oVirt is really maturing as a project, it is still more difficult to set up compared to vSphere and it still hasn’t got all the features vSphere has. On the other hand, ovirt-node (the custom-made node OS) will run on a wider variety of hardware without the need to tweak things. Hence it is easier to install oVirt on whiteboxes.

oVirt Engine and vCenter

oVirt Engine is heavy, just like vCenter, but it can grow quickly out of hand (written in Java). Know that a minimum of 4GB (without Data Warehouse) of RAM and a dual-core CPU are required. But to get the most out of oVirt you will need a quad-core CPU and 16GB of RAM. Of course if you’re willing to use the Self-hosted Engine those specs directly translate to virtual CPUs and virtual RAM: you will need at least one node capable of running the hosted-engine.

Compared to Proxmox

Proxmox is much easier to get started with and doesn’t require an additional machine (Engine) to run. It has a great web interface, but its automation capability is limited (no libvirt). Proxmox doesn’t have a “Data Warehouse” to collect statistics over time. Ceph isn’t really a first-class citizen in oVirt, although it is supported. Proxmox has a great Ceph integration. Network virtualization in Proxmox is still clunky. Template management in Proxmox isn’t really that useful.

Ending line: “How do you export a VM in Proxmox?” You can’t. You will have to ssh into an hypervisor to do so. Furthermore, the feature “isn’t planned at the moment“. And for me, that’s a huge red flag.

Compared to plain QEMU+KVM (optionally Libvirt)

QEMU+KVM is pretty difficult to use command-line-wise, even harder if you have a fleet of servers. That’s where Libvirt steps in, it is easier to create and manage Virtual Machines, Storage and Networks using it.

Libvirt also has a nice GUI: Virtual Machine Manager. But when it comes to automation, templates, migrations and advanced features like that, you will notice you need something more.

oVirt perfectly fits that gap, and it can even easily import instances from an existing Libvirt-based host. Although the gap will be filled, it will also become more complicated to manage your solution. Plain Libvirt+VMM is the easiest of the solutions proposed.

For homelabbers

Only hardcore, seasoned homelabbers may benefit from oVirt. If you are one of them, it will be worth your while. Especially if you decide to use ovirt-node.

If you’re an intermediate homelabber, you may still want to use Proxmox.

If you’re a newbie homelabber, I recommend you take a look at these articles before using Proxmox:

• What is a Virtual Machine?
• How to set up a Virtual machine on VirtualBox
• How to set up a Virtualization host using KVM on CentOS 7.*
• How to set up a Virtualization host using KVM on Ubuntu