De processor beslist of dit werkt

Je hebt een server met 64 GB geheugen en je wilt er tien dingen op laten draaien die elkaar niet mogen zien. Dat is het moment waarop je bij KVM uitkomt, meestal zonder dat je het doorhebt.

KVM staat voor Kernel-based Virtual Machine en het is geen programma dat je ergens neerzet. Het is een module in de Linux-kernel zelf. Laad je die module, dan is je kernel een hypervisor. Meer niet.

Dat is precies het verschil met alles wat er omheen bestaat. VMware ESXi is een besturingssysteem dat alleen virtualisatie doet. Xen begon als een aparte laag onder de kernel. KVM niet. Het lift mee op wat de kernel al doet: geheugenbeheer, procesplanning, scheduling, beveiliging. De kernel was er al, KVM gebruikt het.

Wat je daarvoor terugkrijgt is snelheid. Een VM onder KVM draait instructies direct op de processor, niet via een emulatielaag. Dat kan alleen als je processor meewerkt.

De processor beslist of dit werkt

KVM eist hardwarematige virtualisatie. Op Intel heet dat VT-x, op AMD SVM. Zonder dat kun je het vergeten, hoe nieuw je machine ook is.

Staat het niet aan in je BIOS of UEFI, dan start er niets. Check het voordat je verder leest:

``` grep -Eoc '(vmx|svm)' /proc/cpuinfo ```

Krijg je een nul, dan is het uit of je hardware ondersteunt het niet. Krijg je iets hogers, dan kun je door. Dit is geen detail dat je later oplost; het is de drempel.

Dit is ook het punt waarop je moet nadenken over wat je eigenlijk wilt. Wil je één testbak op je laptop, dan is VirtualBox of GNOME Boxes een prima keuze en hoef je dit artikel niet te lezen. Wil je tien productie-VM's op een server die maanden achter elkaar blijft draaien, dan is KVM de laag waar je op bouwt.

QEMU doet het zichtbare werk

KVM alleen kan geen VM opstarten die je kunt zien. Het versnelt de processor, maar een netwerkkaart, een schijf, een beeldscherm — die moet iemand verzinnen.

Dat iemand is QEMU. QEMU emuleert de apparaten, KVM versnelt de uitvoering. Samen zijn ze één ding. Je typt `qemu-system-x86_64 -enable-kvm` en je krijgt een VM die bijna native snelheid haalt.

De verwarring zit hier: mensen zeggen "KVM" en bedoelen "KVM plus QEMU plus libvirt". Zeg je alleen KVM, dan zeg je alleen de versneller. De rest is gereedschap eromheen.

En dat gereedschap is waar het in de praktijk om gaat. QEMU rechtstreeks aanroepen met vijftig command-line flags is te doen voor één VM. Voor tien wordt het een script dat niemand durft aan te raken.

libvirt maakt het beheersbaar

libvirt is een API en een set tools die tussen jou en QEMU staat. Je beschrijft een VM in XML, libvirt start hem op, houdt hem in de gaten en ruimt op als het misgaat.

Het kost je een extra laag om te leren. Je moet weten wat een domain is, waar de XML-bestanden staan, hoe `virsh` werkt. Maar zonder libvirt beheer je QEMU-processen met de hand, en dat is precies het soort werk dat je op zondagavond niet wilt doen.

Met libvirt ziet het er zo uit:

``` virsh list --all virsh start webserver-01 virsh shutdown webserver-01 ```

Dat is de hele interface voor dagelijks gebruik. De XML eronder raak je alleen aan als je iets verandert dat niet via `virsh` kan.

De prijs is de leercurve. libvirt heeft zijn eigen concepten en zijn eigen foutmeldingen, en die zijn niet altijd vriendelijk. Wie één VM wil, betaalt die prijs voor niets.

Wat je op een server neerzet

Op een echte server wil je meer dan een hypervisor. Je wilt een stack die je kunt beheren zonder er elke dag naar te kijken.

De gangbare combinatie is KVM plus libvirt plus een beheerscherm. Proxmox VE is de bekendste: Debian met KVM, een webinterface, clustering en backup ingebouwd. Het is open source, met een betaald abonnement voor de enterprise-repository. Je kunt het gratis draaien, maar dan trek je updates uit een testrepository. Dat is een keuze met een prijs.

OpenStack is het andere uiterste. Daar is KVM de onderliggende virtualisatielaag in een platform dat honderden VM's over tientallen nodes verdeelt. KVM zelf merk je daar niet meer. Het is infrastructuur onder infrastructuur.

Daartussen zit alles wat je zelf bouwt. Een RHEL-server met libvirt en een paar scripts. Een Ansible-rol die VM's uitrolt op basis van een template. Een monitoringstack die kijkt of de VM's nog ademen.

Elk van die keuzes kost iets. Proxmox geeft je een werkend geheel en neemt een deel van de controle weg. Zelf bouwen op libvirt geeft je precies wat je wilt en vraagt dat je het ook onderhoudt.

De desktop is een ander verhaal

Op je laptop wil je geen cluster. Je wilt een VM starten, iets testen, en hem weer weggooien.

GNOME Boxes doet dat. Het is een dunne laag over QEMU en KVM, gericht op mensen die geen XML willen zien. Je sleept een ISO erin, klikt door de installer, klaar.

Snowglobe is een nieuwere viewer die via DBus met draaiende QEMU-instanties praat. Het is geschreven door Bilal Elmoussaoui en staat onder GPL-3.0-or-later. Het ondersteunt toetsenbord, muis en multi-touch, en het oogt moderner dan wat er lang standaard was. Voor wie een losse viewer zoekt in plaats van een compleet beheerpakket is het de moeite van het bekijken waard.

Beide tools verbergen hoe KVM werkt. Dat is het punt. Tot het moment dat er iets misgaat en je alsnog in de QEMU-commandoregel duikt.

Wat Red Hat ermee deed

KVM begon in 2006 bij Qumranet, een Israëlisch bedrijf. Avi Kivity schreef de eerste versie en kondigde hem op 19 oktober 2006 aan op de Linux-kernelmailinglijst. In december van dat jaar kwam de code in de ontwikkelversie van de kernel, en op 5 februari 2007 zat KVM in de stabiele kernel 2.6.20.

Vanaf dat moment hoefde niemand meer een module te installeren. Zat je op een kernel die recent genoeg was en had je de juiste processor, dan werkte het.

In september 2008 kocht Red Hat Qumranet voor een bedrag dat rond de 107 miljoen dollar lag. Daarmee kwam de ontwikkeling in handen van een partij die er enterprise-producten omheen kon bouwen. RHEL kreeg KVM als virtualisatielaag, Red Hat Virtualization kwam erop, en de professionele ondersteuning die er eerst niet was, kwam er wel.

Dat is geen detail voor de geschiedenis. Het is de reden dat KVM vandaag in datacenters staat. Een project dat alleen door vrijwilligers wordt onderhouden, krijg je moeilijk door een inkoopprocedure. Een project met een supportcontract erachter wel.

KVM bleef wel open source. De code is voor iedereen, bijdragen van buiten Red Hat worden geaccepteerd, en de ontwikkeling loopt grotendeels in het openbaar. Dat is de mix die het draaiende houdt.

Waar het op neerkomt

KVM is geen product dat je kiest. Het is een laag die je gebruikt, vaak zonder erbij stil te staan. Draai je Proxmox, dan draai je KVM. Draai je OpenStack, dan draai je KVM. Draai je een VM in GNOME Boxes, dan draai je KVM.

De keuze zit niet in KVM zelf. Die zit in wat je eromheen bouwt. Wil je een beheerscherm en backups die werken zonder dat je ze zelf schrijft, dan is Proxmox de kortste weg en lever je wat vrijheid in. Wil je precies weten wat er op je server staat, dan bouw je op libvirt en onderhoud je het zelf. Wil je één testbak, dan is KVM waarschijnlijk overkill en is een eenvoudigere tool de betere keuze.

Wat je ook kiest, de onderlaag is hetzelfde. En die onderlaag zit in de kernel, niet in een doos die je installeert. Dat is het hele punt, en tegelijk het hele probleem: er is niets om aan te wijzen als het niet werkt.