Op de Red Hat Summit 2008 verbaasde Red Hat vriend en vijand met de aankondiging dat het de Xen-hypervisor in Red Hat Enterprise Linux 5 op termijn zou gaan vervangen door KVM. Vlak daarna kocht het bedrijf voor 107 miljoen dollar het Israëlische Qumranet, de makers van KVM. Toen was het al duidelijk dat het Red Hat serieus was.

De recente Red Hat Enterprise Linux 5.4 release is de eerste die KVM bevat, maar ook Xen wordt nog jaren ondersteund, want Red Hat Enterprise Linux 5 heeft een lifecycle van zeven jaar en de eerste versie verscheen in maart 2007. Klanten kunnen nu dus één van de twee hypervisors kiezen en hebben tijd zat om beide uit te proberen en te vergelijken, al heeft Red Hat wel duidelijk gemaakt dat voor hen KVM de toekomst is.

We hoeven niet lang te zoeken naar de reden waarom Red Hat KVM verkiest. Over Xen had het geen controle meer, omdat maker XenSource in augustus 2007 door Citrix werd overgenomen. Citrix is van oudsher al een nauwe partner van Microsoft, evenals Novell, dat ook Xen gebruikt in SUSE Linux Enterprise. Mochten deze drie partners ooit besluiten om met Xen een richting uit te gaan die Red Hat niet wil (hoewel ook Red Hat in het Xen Advisory Board zit), dan zit het bedrijf goed vast. Met KVM heeft Red Hat het heel wat gemakkelijker om een hypervisor volgens de eigen wensen in het besturingssysteem en de beheertools te integreren.

Red Hat heeft bovendien heel wat ervaring met KVM. Zelfs voordat ze Qumranet opkochten, waren ze de grootste contributor aan de KVM-code. KVM zit sinds Fedora 7 (mei 2007) standaard in de distributie. Toen RHEL 5 in maart 2007 verscheen, was KVM echter nog maar een paar maanden oud en dus zeker niet volwassen genoeg als hypervisor.

The good

De vraag is natuurlijk waarom iemand KVM zou kiezen boven Xen. Die laatste heeft immers het voordeel dat ze al veel volwassener is. Toch heeft KVM één groot voordeel tegenover Xen dat het op heel wat vlakken gemakkelijker maakt in het gebruik: KVM is opgenomen in de standaard Linux-kernel tree. Xen wordt door de Linux-kernelontwikkelaars nog altijd niet beschouwd als van voldoende kwaliteit om rechtstreeks in de kernel opgenomen te worden, en hoe langer dat duurt, hoe moeilijker het wordt om Xen te implementeren boven Linux. Citrix onderhoudt nu bijvoorbeeld zijn Xen-code als een patch tegen de oude 2.6.18-kernel (die overigens ook in RHEL 5 zit). Elke Linux-distributie die Xen wil ondersteunen, moet ofwel deze oude kernel aanbieden of al deze patches forward-porten naar de recentere kernels (zoals 2.6.30). Xen maakt het Linux-distributeurs dus knap lastig.

KVM daarentegen zit altijd in de meest recente kernelversie, en laat distributies zoals Ubuntu, dat zich in recente versies meer op virtualisatie en cloud computing aan het focussen is, toe om standaard een hypervisor aan te beiden en toch een recente kernelversie te hebben (Ubuntu ondersteunt al even geen Xen meer omdat het geen mankracht heeft voor het porten). Dit betekent ook dat KVM automatisch profiteert van de beschikbaarheid van de nieuwste drivers in de Linux-kernel. En van zaken zoals good power management, bijvoorbeeld voor wie een hypervisor op zijn laptop wil draaien voor testdoeleinden. Met Xen haal je niet veel uren als je op je batterijvoeding werkt.

Dat KVM een standaard onderdeel van de Linux-kernel is, heeft nog een ander belangrijk gevolg: de meer dan drieduizend toepassingen die gecertificeerd zijn voor Red Hat Enterprise Linux zijn automatisch ook gecertificeerd om virtueel te draaien in Red Hats KVM. Ook beheertools, SELinux-beveiliging en Red Hat Network werken zowel in fysieke als virtuele omgevingen. De KVM-hypervisor in RHEL 5.4 ondersteunt als gastbesturingssystemen RHEL 3, 4 en 5, evenals Windows XP, Windows Server 2003 en Windows Server 2008. Bovendien is het eenvoudig om een fysieke RHEL-server te migreren naar een virtuele (onder KVM), omdat het exact dezelfde omgeving is en het enige verschil op de gastheer is het laden van twee kernelmodules (kvm en kvm_intel of kvm_amd).

Red Hat heeft ook een standalone KVM-hypervisor gepland, die later dit jaar moet uitkomen: Red Hat Enterprise Virtualization Hypervisor. Zowel RHEV-H als RHEL zijn gebaseerd op exact dezelfde KVM-code; het enige verschil is de code errond, toegespitst op hoe de gebruiker de hypervisor wil beheren. Bij RHEV-H zal dat slechts een uitgeklede versie van RHEL zijn die zo'n 100 MB groot is.

De migratie van Xen naar KVM zal overigens niet zo moeilijk zijn: Red Hat is jaren geleden gestart met de ontwikkeling van beheertools als libvirt (met command-line interface virsh), virt-manager (met tools als virt-install, virt-clone, virt-image en virt-viewer) en de webinterface oVirt, allemaal met de bedoeling om abstractie te maken van de specifieke hypervisor. De versies in RHEL 5.4 ondersteunen dan ook zowel Xen als KVM en voor beheerders verandert er niet veel: zij kunnen dezelfde beheertools blijven gebruiken.

Red Hat is ook migratietools aan het ontwikkelen om Xen-images om te zetten naar KVM-images, en met Xenner is het mogelijk om een Xen-kernel en lichtgewicht Xen-emulator in een KVM-gastomgeving te draaien, voor als je Xen-images op KVM wilt draaien. Gebruik je nu Xen en wil je op termijn naar KVM migreren, of tenminste die mogelijkheid hebben, dan kun je die migratie sterk vereenvoudigen door nu al zoveel mogelijk met deze agnostische tools te werken, in het bijzonder libvirt.

The bad

Toch heeft KVM nog een lange weg te gaan. Het heeft nog maar een miniem marktaandeel in de competitieve hypervisormarkt, waar het moet opboksen tegen drie grote spelers: VMware, Xen en Hyper-V. En terwijl die drie laatste al een groot ecosysteem hebben van third-party beheertools en supportdiensten, is dat bij KVM heel wat minder. En met de minieme of moeilijk te meten verschillen in performance en betrouwbaarheid zijn het de marktomstandigheden en ecosystemen waar potentiële gebruikers naar kijken.

Xen heeft bovendien heel wat machtige bedrijven achter zich. Niet alleen Citrix, maar ook Novell dat Xen als hypervisor gebruikt in SUSE Linux Enterprise, Oracle dat een eigen Xen-variant heeft met Oracle VM en het onlangs door Oracle overgenomen Sun dat een eigen Xen-variant heeft met xVM, die de hypervisor is in OpenSolaris.

Het is dan ook aan Red Hat om gebruik te maken van zijn ecosysteem van ISV's (independent software vendors) om KVM verder te verspreiden. Daarmee haalt het zich echter een dubbele taak op de hals: het heeft in de laatste jaren heel wat in Xen geïnvesteerd en moet de hypervisor nog jaren ondersteunen, zolang de supportperiode van RHEL 5 duurt. Bovendien hangt het voor zijn migratie naar KVM af van third-party ontwikkelaars van beheersoftware die nu ook KVM in hun software moeten ondersteunen. Gebeurt dat niet, dan blijven Red Hats klanten zeker bij Xen. Red Hats eigen virtualisatiebeheertools voor KVM komen later dit jaar uit.

Critici van KVM beweren bovendien dat Xen veiliger is dan KVM. Die laatste is immers eerder een type-2 hypervisor, die bovenop een besturingssysteem draait en waarin de gasten bepaalde onderdelen van de Linux-kernel delen (met risico op uitbuiting hiervan), terwijl Xen een type 1 hypervisor is, die rechtstreeks op de hardware draait en een scheiding tussen de verschillende gasten en de gastheer en gasten heeft. De Linux-kernel is bovendien groter dan de Xen-microkernel, waardoor de kans op fouten groter is. Daardoor is een KVM-installatie slechts zo veilig als de Linux-gastheer. Een kanttekening daarbij is echter dat Red Hat al jaren een voortrekkersrol speelt met SELinux-beveiliging in de distributie, en dat het in Fedora 11, dat de basis van Red Hat Enterprise Linux 6 zal vormen, die lijn ook doorgetrokken heeft: het isoleert verschillende virtuele gasten door middel van sVirt.

The undecided

Het wordt interessant om te zien wat Oracle gaat doen. Het bedrijf gebruikt immers in zijn Red Hat-kloon Oracle Enterprise Linux de hypervisor Xen (onder de naam Oracle VM), maar moet nu, omdat het een Red Hat-kloon is, ook volgen met ondersteuning van KVM. En Suns OpenSolaris heeft gekozen voor Xen, iets wat Oracle door de overname van Sun nu overgeërfd heeft. Gaat het beide hypervisors blijven ondersteunen? Of zal het resoluut voor Xen kiezen in OEL en zich daardoor differentiëren van RHEL?

En wat gaat Novell doen? KVM heeft in SUSE Linux Enterprise Server 11 zijn intrede gedaan als "technology preview", maar is nog niet ondersteund. Gaat het op termijn de plaats van Xen overnemen, net zoals nu bij Red Hat aan het gebeuren is? Of gokt het erop dat Red Hat klanten zal verliezen die de overstap van Xen naar KVM niet willen volgen en daarom naar een andere distributie (SUSE) overstappen? De tijd zal het uitwijzen.

Bron: Techworld