eRacks Systems Tech Blog

The Hypervisor We Left Out: KVM on Ubuntu, Since 2007

Last week we posted about IncusOS, the new immutable operating system built around Incus, and we named the hypervisors people compare it with: Proxmox, XCP-ng, ESXi. A reader could come away thinking those four are the menu. We left out the one we have recommended, installed and run ourselves since 2007. That is KVM, the Kernel-based Virtual Machine, on Ubuntu. This post is the correction, and the reasons.

KVM is the kernel, not a product

A hypervisor is the layer that lets one physical machine run several virtual machines (VMs), each with its own operating system. KVM is unusual among hypervisors because it is not a separate operating system you install under Linux. It is part of Linux. It arrived in kernel 2.6.20, released on 5 February 2007, as a driver for the hardware virtualization extensions in Intel and AMD processors, and it has shipped in every mainline kernel since. Ubuntu, Debian, Red Hat, SUSE and the rest carry it; QEMU provides the machine emulation around it. libvirt, with virsh and virt-manager, is the management layer most guides assume on top of that pair, and we will come back to it.

That placement matters more than any feature list. The virtualization code gets the same scrutiny, the same security updates and the same hardware enablement as the kernel it lives in. When a new processor generation lands, KVM support tends to land with it, in the same release. There is no second vendor to wait on and no second support contract.

The products you compare are mostly KVM underneath

This is the part the comparison lists hide. Proxmox VE runs its virtual machines on KVM and QEMU; its containers use LXC. Incus, the runtime that IncusOS exists to run, uses QEMU and KVM for its virtual machines as well. When people weigh Proxmox against IncusOS, they are choosing a management layer, an update model and a community. The hypervisor doing the work is the same kernel module in both cases. ESXi is the exception on that list: it brings its own kernel, and since the licensing changes of the last two years it is also the one people are most often asking us how to leave.

So the honest version of “which hypervisor” for most of our customers is “which management layer on top of KVM”. Proxmox gives you a web console, clustering and a large community. IncusOS gives you an appliance: an immutable image with A/B partitions for atomic updates and rollback, UEFI Secure Boot and TPM 2.0 measurements, disk encryption backed by the TPM, a stable channel that updates at least weekly and a testing channel that updates daily, and a Migration Manager for moving machines off VMware. Plain Ubuntu Server with KVM, libvirt and cockpit gives you the least opinionated option of the three: a general purpose Linux you already know how to administer, that also happens to be an excellent hypervisor host.

Why we default to Ubuntu plus KVM

We build custom Linux rackmount servers, and most of them leave here as virtualization hosts of one kind or another. Our default recommendation has been Ubuntu with KVM for a long time, for reasons that have not changed much:

• One system to know. The host is a normal Ubuntu Server. Storage (ZFS or LVM, your choice), networking (a bridge, or Open vSwitch when you need it), backups, monitoring and updates are the same tools you use everywhere else. Nothing about the hypervisor is a separate skill.
• Long term support with dates on it. Ubuntu LTS releases carry five years of standard support, ten with Ubuntu Pro. A virtualization host is exactly the kind of machine you want to leave alone for years.
• Hardware enablement on the kernel’s schedule. New CPUs, new NICs, new NVMe controllers: KVM support arrives with the kernel, and Ubuntu’s hardware enablement kernels bring it to the LTS release you are already on.
• No lock in and no license event. Everything in the stack is open source. There is no per socket fee, no feature tier and no vendor that can change the terms under you. The last two years of virtualization news have been a long argument for that point.
• The management layer is your choice, and it can change later. Cockpit or virt-manager if you like a console, Proxmox or Incus if you want a platform, or nothing but QEMU and a few scripts, which is what we run ourselves. The VM disk images are standard qcow2 or raw files. We have moved machines between all of these without reinstalling a guest.

A note on libvirt

Most KVM guides assume libvirt, so we should say where we stand. We have never liked it. It puts an XML document between you and every machine, and the XML sit-ups¹ that come with that obscure and complicate what QEMU is actually doing underneath. We prefer to talk to QEMU directly, through its monitor and console, and our own tooling does exactly that. virsh, libvirt’s command line, became somewhat useful years later, but it still drags libvirt’s baggage behind it, and by the time it did we had long since built what we needed. If you want libvirt on a machine we build, you get it, installed and tested. We will just not pretend to love it.

eVirt: what we run our own machines on

Because we have been doing this since the year KVM landed in the kernel, we ended up with our own small framework for it. We call it eVirt, and the current version is the fourth. It is how our own production web servers, mail servers and lab machines are defined and launched, and it has been in active use internally since 2007. We have not packaged it as a product. We would consider doing that if there is interest, and we can install it now on a consulting basis.

The idea is small on purpose. Each machine is a short YAML file kept next to the project it serves: how much CPU and memory, which disks and how large, which bridge it sits on, and its fixed address. One command turns that file into a running virtual machine: it fetches the Ubuntu cloud image, resizes the disk, seeds the first boot with cloud-init, attaches the network and starts it under KVM, speaking to QEMU’s own monitor rather than going through libvirt. Rebuilding a host is the same command run again, which is how we rehearse and then execute things like a production cutover: the new machine is one entry away, and the address moves in the file. The QEMU guest agent goes into the VMs where we want it; the rest run with no agent at all. Nothing proprietary lives in the image, so a machine built this way is an ordinary Ubuntu VM that any other tool can take over afterwards.

We mention eVirt for one reason: it is the shape of what KVM on Ubuntu makes possible. A tiny layer of automation on top of tools that are already in the distribution gets you reproducible infrastructure without adopting a platform. Plenty of shops arrive at something similar with Terraform providers, Ansible roles or cloud-init alone. The hypervisor underneath is the same.

What we install for customers

If you order a virtualization host from us and do not specify a platform, you get Ubuntu Server LTS with QEMU and KVM installed and tested, ZFS or LVM laid out for VM images, a bridge on the interfaces you name, and the management layer you ask for: libvirt with cockpit or virt-manager, Proxmox, Incus, IncusOS or XCP-ng. Ask about eVirt if you would rather have what we run ourselves. We have no stake in which one you pick; we build the hardware and the storage underneath it, and every one of these runs on hardware we ship today. The only combination we talk people out of is the one that comes with a license invoice they did not ask for.

Questions about a virtualization build, or about moving off a platform you no longer want to pay for? Write to us at info@eracks.com, or start with a quote request.

¹ “XML sit-ups” is a famous programming phrase coined around 2004 to 2005 by David Heinemeier Hansson (DHH), the well-known developer and entrepreneur who created Ruby on Rails. It headlined the framework’s original blurb: “Rails is a full-stack, open source web framework in Ruby for writing real-world applications with joy and less code than most frameworks spend doing XML sit-ups” (quoted in XML.com, August 2005). The target was the enterprise software of the day, J2EE and .NET above all, where you mapped databases, wired dependencies and configured every layer in massive, redundant, error-prone XML files before writing a line that did anything, with all the pointless parsing, generation and not-quite-valid states that XML as a configuration format brings. DHH was still using the phrase a decade on, recalling “the practice of 1000s of lines of XML configuration situps that were common at the time” in his 2016 Slashdot interview.

joe September 20th, 2026

Posted In: News, servers, Technology

Tags: eVirt, IncusOS, KVM, Proxmox, ubuntu, virtualization