© 36clicks, 123RF

Wer Virtualisierung auf Linux betreibt, greift heute meist zu KVM, das seinen älteren Rivalen Xen weitgehend verdrängt hat. Zu Unrecht, denn Xen und KVM gehen Kopf an Kopf durchs Ziel.

[UCC:x-l-anfang-sys]Der Siegeszug [/UCC] der Virtualisierung scheint unaufhaltsam: Im Fahrwasser der Cloud ersetzen Unternehmen ihre konventionellen Setups immer häufiger durch virtuelle Maschinen – wahlweise auf einer selbst gehosteten Cloud oder bei einem der großen Public-Cloud-Anbieter. Virtualisierung hat sich als Betriebskonzept klar durchgesetzt.

Zudem oft genug in der Kombination mit Linux, denn in vielen Fällen laufen virtuelle Maschinen heute unter Linux – obwohl es mächtige und gut funktionierende Alternativen etwa in Form von Microsofts Hyper-V durchaus gibt. Selbst die Virtualisierungslösung, die sich unter Linux um den Betrieb der VMs kümmert, scheint festgelegt zu sein. Am häufigsten kommt die Kombination aus KVM [1] und Linux zum Einsatz. Als Duo sind sie scheinbar der Goldstandard.

Das war jedoch nicht immer so. In der Zeit vor KVM war ein anderer Ansatz dominant: Xen. Wer etwa 2004 unter Linux VMs betreiben wollte, kam um Xen [2] praktisch nicht herum. Die großen Hardwarehersteller waren auf den VM-Zug noch nicht aufgesprungen, potente CPUs etwa mit Sonderfeatures für den Betrieb virtueller Systeme existierten noch nicht. Unter diesen widrigen Umständen gelang es den Xen-Entwicklern seinerzeit, ihr Produkt für zuverlässige und performante Virtualisierung am Markt zu etablieren. Bis heute rühmt sich Xen beispielsweise, das Konzept der Paravirtualisierung unter Linux erfunden zu haben, gerade weil VM-Support auf der Hardware-Seite damals nicht vorhanden war.

Vergleicht man die Marktdurchdringung von Xen in den frühen Jahren mit jener von heute, da die Lösung eine untergeordnete Rolle spielt, drängt sich eine Frage auf: Was ist schiefgelaufen? Wie konnte KVM zum Quasi-Standard werden und Xen hinter sich lassen? Auf diese Frage und die Gründe, die Xen bis heute zur attraktiven KVM-Alternative machen, geht der folgende Artikel ein.

Stress mit dem Kernel

Xen unterscheidet sich von KVM in technischer Hinsicht ganz fundamental. Während die Gelehrten bis heute darüber streiten, ob KVM ein Mode-1-Hypervisor oder ein Mode-2-Hypervisor ist, ist diese Frage bei Xen schnell geklärt: Der eigentliche Hypervisor läuft direkt auf dem Host und gehört nicht zum Betriebssystem. Stattdessen bildet er die Basis, auf der das Betriebssystem als eines von vielen läuft. Als Bezeichnung für das OS hat sich in der Xen-Welt der Begriff »dom0« etabliert, die Abkürzung für Domain-0 (Abbildung 1).

Abbildung 1: Der Hypervisor läuft direkt auf der Hardware, der Kernel des Hostsystems ist selbst Gast und heißt »Domain-0«.

Der Betrieb als Mode-1-Hypervisor bringt viele Vorteile: Der Hypervisor allein verteilt die verfügbaren Ressourcen und entscheidet darüber, welche der vorhandenen Hardwarekomponenten zu welchem Zeitpunkt durch welche Domain des Setups benutzt werden darf. Genau das ist schließlich die Herausforderung bei der Verwaltung virtueller Maschinen: Nicht alle Ressourcen eines physischen Systems lassen sich exklusiv einem Gast zuweisen – CPU, RAM und andere Teile sind zwangsläufig zwischen allen laufenden Systemen aufzuteilen.

Bei Xen kommt hier auch die erwähnte Paravirtualisierung ins Spiel. Eines ihrer Merkmale ist, dass die virtuellen Betriebssysteme in den Gast-VMs wissen, dass sie virtualisiert sind. Der Hypervisor verfügt über eine standardisierte generische Schnittstelle, über die in der VM installierte, spezielle Gerätetreiber den direkten Zugriff auf einzelne Teile der Hardware erhalten.

Aus Sicht der Performance ist das sehr sinnvoll. Wenn der Hypervisor Hardware vollständig virtualisieren muss, wird er quasi zum Dolmetscher zwischen Host und Gast-VM. Der Overhead, der durch das Übersetzen zwischen den beiden Welten entsteht, ist gewaltig und wirkt sich besonders auf die erreichbare Performance negativ aus. Wenn das Übersetzen entfällt, sorgt dies für einen ordentlichen Leistungsschub. Und genau das war zu jener Zeit, als die ersten Xen-Versionen erschienen, bitter nötig.

Einerseits war die am Markt verfügbare Hardware damals generell nicht annähernd so leistungsfähig wie die Megahertz-Monster der Gegenwart und die etlichen Gigabyte RAM, die ihnen zur Verfügung stehen. Andererseits bot die verfügbare Hardware zur damaligen Zeit keine wie auch immer gearteten Features, um Virtualisierung durch die Hardware zu unterstützen. Intels Virtualization Technology (VT) oder AMDs Secure Virtual Machine (SVM) gab es damals noch nicht (Abbildung 2). Ein Hypervisor musste mit der ihm zur Verfügung stehenden Hardware also so effizient umgehen, wie es ihm nur irgendwie möglich war.

Abbildung 2: Moderne Prozessoren bieten besondere Virtualisierungsfeatures, die es noch nicht gab, als Xen sich bereits am Markt etabliert hatte.

Das Problem: Damit der Hypervisor die (Para-)Virtualisierung ausführen kann, muss natürlich zunächst die Kooperation zwischen dem Hypervisor und dem Kernel auf dem Host (beziehungsweise in der Domain-0) funktionieren. Heute ist das kein Problem mehr: Der Linux-Kernel bietet in Form der Pvops, also der Paravirt Operations Extension, mittlerweile eine eigene, standardisierte Schnittstelle für Paravirtualisierung. Ende der 1990er Jahre jedoch, als die Xen-Entwickler mit der Planung ihrer Software begannen, war von einer solchen Technik in Linux noch gar keine Rede.

Die Lösung dieses Problems lässt so manchem gestandenen Admin bis heute die Nackenhaare zu Berge stehen: Notgedrungen modifizierten die Xen-Entwickler den Linux-Kernel so, dass er anschließend zusammen mit ihrem Hypervisor benutzbar war.

Frankenstein lässt grüßen

Doch waren die für Xen notwendigen Modifikationen im offiziellen Linux-Kernel nicht integriert, nicht zuletzt weil Linus Torvalds gegen die Xen-Umsetzung der Paravirtualisierung immer wieder Bedenken anmeldete. Und weil die von Xen in Linux benötigten Veränderungen massiv waren, fiel es den Xen-Entwicklern mit der Zeit immer schwerer, aktuelle Linux-Neuerungen in ihren Linux-Kernel zu übernehmen.

Das Ergebnis dieses Problems ist den meisten Linux-Admins noch gut in Erinnerung: Während Linux selbst sich kontinuierlich und immer schneller weiterentwickelte, war man mit Xen lange auf Linux 2.6.18 festgenagelt, ohne die Aussicht auf Besserung. Red Hat und Suse hatten Xen seinerzeit längst in ihre Enterprise-Distributionen aufgenommen und waren entsprechend unglücklich, denn die unbedingte Notwendigkeit, für Xen einen besonderen und immer älter werdenden Kernel an die Kundschaft auszuliefern, entpuppte sich nach und nach als große Katastrophe.

Dann kam KVM

Im Verlauf des Jahres 2007 kristallisierte sich sukzessive heraus, dass das alte Xen-Entwicklungsmodell als gescheitert gelten musste. Aus anderer Richtung drohte der Lösung ebenfalls Ungemach: In Israel gründeten ein paar Entwickler 2007 – wohl auch als Reaktion auf das Xen-Debakel – die Firma Qumranet, die sich sofort an die Arbeit an einem eigenen Virtualisierer machte. Noch im selben Jahr erschienen erste Versionen der Kernel Virtual Machine (KVM) und zogen naturgemäß Interesse auf sich.

Der Clou: KVM war anfangs ein reiner Vollvirtualisierer, beherrschte also keine Paravirtualisierung. Weil es auch kein klassischer Mode-1-Virtualiserer ist, lässt es sich viel einfacher mit dem Linux-Kernel verheiraten: Dazu genügt es, wenn der Admin die für KVM benötigten Module in den Kernel lädt – eines für die Grundfunktionalität, eines für die dann bereits erfundenen CPU-spezifischen Virtualisierungsfeatures.

Weil Qumranet auch keine große Lust hatte, einen eigenen Emulator zu schreiben, modifizierte man kurzerhand die erprobte Lösung Qemu so, dass sie KVM nutzen kann. Weil sich in Sachen Performance bei der Hardware zwischenzeitlich einiges getan hatte, war die Kluft zur Paravirtualisierung immerhin nicht mehr ganz so riesig. Bei der Wahl zwischen einer praktisch unwartbaren Lösung auf Xen-Basis und einer etwas langsameren Lösung mit KVM entschieden sich viele Admins jetzt gerne für KVM.

KVM und Qumranet zogen schließlich so viel Interesse auf sich, dass Red Hat die Firma 2008 kurzerhand für 150 Millionen US-Dollar kaufte und die KVM-Entwicklung seitdem selbst weiterführte. Bald darauf fand sich KVM sowohl in RHEL als auch in SLES wieder, Debian und Ubuntu waren ohnehin längst auf den Zug aufgesprungen und unterstützen KVM ebenfalls.

Im Laufe der Zeit fanden die für den KVM-Betrieb nötigen Patches ihren Weg in Qemu, und unter Red Hats Führung übernahm Linus Torvalds schließlich auch KVM in den Kernel, das im Gegensatz zu Xen faktisch minimal–invasiv ist. Außerdem erweiterten die KVM-Entwickler unter Red Hats Ägide die Feature-Liste von KVM andauernd: Über die Virtio-Funktionen der Lösung lässt sich eine Paravirtualisierung heute auch mit KVM problemlos betreiben, und zwar ohne zusätzliche Kernelpatches. Denn als die KVM-Entwickler sich ernsthaft mit Paravirtualisierung beschäftigten, stand die Pvops-Funktionalität in Linux schon zur Verfügung.

Verkauf an Citrix

War Xen ursprünglich noch ein Forschungsprojekt gewesen, so hatten seine Erfinder rechtzeitig eine Firma gegründet, um Xen kommerziell zu vermarkten. Das Unternehmen hörte auf den Namen Xensource. Ob die Verantwortlichen den Verkauf von Xensource angesichts der damaligen Verhältnisse als “Notbremse” sahen, wird wohl ein Geheimnis bleiben. Fakt ist jedoch, dass seine Eigner Xensource 2007 für eine halbe Milliarde US-Dollar an Citrix verkauften.

Citrix stellte einerseits sofort klar, dass Xen quelloffene Software wie bisher bleiben würde. Andererseits machte man sich an die Arbeit, um Xen mit generischen Linux-Kerneln betreiben zu können. Namhafte Xen-Entwickler arbeiteten dafür an der Pvops-Implementation in Linux mit. Trotzdem erreichten die Entwickler das Ziel erst im März 2011: Linux 2.6.37 bot erstmals eine Möglichkeit, Xen 4 ohne weitere Anpassungen mit Linux zusammen zu betreiben.

Der Erfolg markiert einen weiteren Wendepunkt in der Xen-Geschichte: Erstmals war es nun möglich, Xen ohne größere Umbauten in andere Distributionen zu integrieren, sogar parallel zu KVM. Wie zur Belohnung nahmen viele Hersteller Xen wieder in ihre Distributionen auf und viele Systeme, die seit vielen Jahren auf alten Xen-Versionen mit alten Kerneln liefen, konnten ihre dringend benötigten Updates endlich erhalten.

Seither dürfen sich die Betreiber von Linux-Servern ausgesprochen glücklich schätzen: Sie haben die Wahl zwischen zwei Virtualisierungslösungen, die sich ihre Meriten bereits erworben haben und auf Augenhöhe konkurrieren. Welche Gründe sprechen dafür, Xen den Vorzug zu geben? Auf welchen Gebieten ist Xen besser als KVM und wo sind beide Lösungen gleichauf?

Die Mär von der komplizierten Installation

Ein unbestritten ausschlaggebendes Argument für die Wahl der Virtualisierung ist die Frage nach den verfügbaren Management-Werkzeugen. VMware war über viele Jahre hinweg die unangefochten führende Virtualisierungslösung, weil die Software eben nicht nur Virtualisierung bot, sondern auch Werkzeuge, um Virtualisierung sehr bequem zu verwalten.

Das geht schon bei der Frage nach der Installation los: KVM etwa ist seit Jahren Teil des Standardkernels, sodass es genügt, einen Qemu-Emulator mit KVM-Unterstützung zu installieren und die KVM-Module für den eigenen Prozessor in den Kernel zu laden. Weil ein passendes Qemu allen aktuellen Distributionen beiliegt, dauert es nur wenige Sekunden, eine frische Linux-Installation in einen KVM-Host zu verwandeln.

Viele Admins denken dagegen mit Schaudern an die Installation von Xen zurück. Doch in den vergangenen Jahren hat sich Xen essenziell weiterentwickelt. Unter Ubuntu beispielsweise genügt es, den Xen-Hypervisor in der jeweils aktuellen Version mittels »apt-get« zu installieren und das System neu zu starten (Abbildung 3). Selbst die Einträge für den Bootloader Grub aktualisieren die Xen-Pakete eigenständig.

Abbildung 3: In aktuellen Ubuntu-Versionen liegt der Xen-Hypervisor als ein fertiges Paket bei, das man einfach installieren kann.

Bei anderen Distributionen ist die Situation ähnlich: Unter Suse lässt sich Xen etwa per Yast installieren (Abbildungen 3 und 4) und auch Red-Hat-basierte Distributionen ebnen den Weg zu Xen in kurzer Zeit. In der Praxis verläuft die Installation von Xen heute also so komplikationslos wie jene von KVM. Offensichtliche Vorteile sind weder für die eine noch für die andere Lösung auszumachen.

Abbildung 4: Auch bei Open Suse gehört Xen zum Lieferumfang, sodass man das Paket per Yast installieren kann.

Das Management von VMs

Auch bei der Verwaltung der eigentlichen VMs unterscheiden sich Xen und KVM in der Handhabung kaum noch. Ursprünglich war Xen hier sogar besser als KVM aufgestellt: Das Xen-API erlaubte es, aus dem laufenden Hostsystem heraus direkt mit dem Hypervisor zu kommunizieren und ihm Anweisungen zu erteilen. Eine vergleichbare Funktionalität fehlte KVM, bis Red Hat auf den Plan trat: Weil man in Raleigh frühzeitig verstand, dass der Virtualisierer eben nicht alles ist, begann man mit der Entwicklung der Libvirt ([3], Abbildung 5).

Abbildung 5: Libvirt abstrahiert die Eigenschaften von KVM und Xen weg und bietet eine einheitliche Oberfläche.

Die Libvirt gilt heute als Quasi-Standard, wenn es um VM-Verwaltung auf Linux-Hosts geht. Denn sie bietet eine generische Abstraktionsebene, die im Hintergrund sowohl KVM als auch das Xen-API verwenden kann. Sobald im Hintergrund KVM oder Xen laufen, lassen sich per Libvirt auf der Kommandozeile virtuelle Maschinen auf exakt dieselbe Art und Weise anlegen, starten, stoppen oder auch wieder löschen.

Unterschiede in der Bedienung abstrahiert die Libvirt für Benutzer einfach weg. Zugegeben: KVM ist an dieser Stelle etwas eleganter als Xen. Denn für KVM legt Libvirt lediglich Konfigurationsdateien an und startet Qemu, das den Rest erledigt. Im Gegensatz dazu redet bei Xen ein API mit einem anderen. Weil der Admin davon aber nichts mitbekommt, ist das vernachlässigbar. Das Management, das Libvirt leistet, beschränkt sich übrigens nicht auf die Basics: Live-Migration etwa, die im modernen RZ-Betrieb unerlässlich ist, wickelt ebenfalls die Libvirt in weiten Teilen ab.

Wer nach Vergleichen von KVM und Xen im Netz sucht, findet dort häufig das Pro-Xen-Argument, dass KVM zu Live-Migration nicht in der Lage sei. Das ist nachweislich falsch: KVM wie Xen beherrschen mittlerweile die praktisch unterbrechungsfreie Live-Migration, wenn die Voraussetzungen stimmen – also die VM etwa auf einem Speichergerät liegt, das sowohl auf dem Quell- als auch auf dem Zielhost zur Verfügung steht.

Ressourcenverwaltung

Einen klaren Vorteil hat Xen, wenn es um die effiziente Verwaltung und vor allem um die Aufteilung der auf dem Hostsystem verfügbaren Ressourcen geht. Das liegt daran, dass Xen ein waschechter Mode-1-Hypervisor ist. Weil der Kernel des Host-Betriebssystems also als Domain-0 selbst unter den Fittichen des Xen-Hypervisors steht, nimmt er auf die Ressourcenverteilung keinen Einfluss. Tatsächlich lässt sich in Xen sogar festlegen, dass der Hostkernel Teile ganzer Komponenten gar nicht erst zu Gesicht bekommt, weil der Hypervisor sie vor ihm versteckt.

Anders bei KVM: KVM koordiniert im Kernel etwa den Zugriff auf RAM und CPU selbst. Der Hostkernel sieht immer die gesamte Hardware. Eine Amok laufende VM kann dadurch andere VMs stören. Das gilt sogar für direkt an eine VM durchgereichte Hardware. Wer also bei KVM etwa einzelnen VMs eigene NICs zur Verfügung stellt, hat nicht die Garantie, dass eine über diese NICs stattfindende Attacke nicht das Hostsystem und damit andere VMs beeinflusst.

In Xen ist das anders: Weil der Hypervisor die Hardware verwaltet, ist sicher, dass wirklich nur die jeweilige VM beeinflusst wird, der die NIC zugeordnet ist.

Native Hardware

Apropos durchgereichte Hardware: Regelmäßig kommt es vor, dass Admins einer VM eine spezielle Hardwarekomponente direkt und exklusiv zur Verfügung stellen wollen. Gerade in der jüngeren Vergangenheit haben sich etwa Grafikkarten als Rechenwerk etabliert und werden zweckentfremdet. Statt für aufwändige Grafiken nutzt man sie lieber etwa zum Mining von Bitcoins. Der Wunsch liegt nahe, eine solche Grafikkarte einer einzelnen VM zur Verfügung zu stellen.

Sowohl KVM als auch Xen beherrschen das Durchreichen von Hardware an VMs. Im Gast sieht das dann so aus, als sei die Karte tatsächlich in die VM eingebaut. Gibt es für das Gerät spezielle Treiber wie jene von AMD oder Nvidia, lassen sie sich sogar installieren.

Im RZ-Alltag verwenden Admins die Passthrough-Funktion im Netzwerkkontext häufig. Teure Netzwerkinfrastruktur wie 100-GBit/s-Hardware oder das mit sehr niedrigen Latenzen aufwartende Infiniband lassen sich so Kunden zur Verfügung stellen, die explizit dafür zahlen. Auch hier gilt, dass Xen beim Durchreichen etwas gründlicher zu Werke geht: Weist der Admin eine bestimmte Komponente einer VM zu, sieht der Hostkernel diese erst gar nicht – genauso wenig wie andere VMs.

Virtualisierung und Paravirtualisierung

Sowohl Xen als auch KVM sind in aktuellen Versionen in der Lage, virtuelle Systeme vollständig oder über den Umweg der Paravirtualisierung zu betreiben. Die Vollvirtualisierung ist bei KVM der Standard; erst wenn der Admin die zur VM gehörenden Netzwerkkarten und Storage Devices in den Virtio-Modus umschaltet, kommt der in den Genuss der Paravirtualisierung. Vorausgesetzt freilich, dass das Betriebssystem in der VM mit entsprechenden Treibern ausgestattet ist.

Immerhin: In Linux sind die Virtio-Treiber für Paravirtualisierung als Gast in KVM bereits seit etlichen Versionen fester Bestandteil des Linux-Kernels. Auch Windows spielt mit: Red Hat selbst bietet entsprechende Treiber an, die sogar signiert sind und nach ihrer Installation in Windows Virtio-Funktionalität bereitstellen.

Bei Xen funktioniert das Prinzip ähnlich: Xen unterscheidet zwischen HVM und PV, wobei HVM für Host Virtual Machine steht, im Xen-Sprech das Pendant zur Vollvirtualisierung. Wer Linux oder Windows als Gast in Xen mit Paravirtualisierung betreiben möchte, benötigt ebenfalls passende Treiber, die unter [4] zur Verfügung stehen. Zumindest für Windows, denn ebenso wie bei KVM gehören die PV-Treiber für Xen seit Jahren zum Linux-Kernel, sind also ab Werk vorhanden.

Performance-Aspekte

Beim Vergleich der beiden Virtualisierungslösungen spielt auch die Performance eine wichtige Rolle. Im Netz finden sich Hunderte Berichte, Dokumente und Blog-Einträge mit Benchmarks, die KVM und Xen vergleichen. Wie üblich gehen all diese Vergleiche jedoch von spezifischen Voraussetzungen aus, die kleinste Veränderung der dem Test zugrunde liegenden Parameter kann zu sehr großen Unterschieden bei den gemessenen Ergebnissen führen.

Es ist unter dem Strich praktisch nicht möglich, KVM oder Xen die bessere Performance zu unterstellen. Wer wissen möchte, ob im eigenen Einsatzszenario Xen oder KVM besser abschneiden, kommt um Tests nicht herum.

Die Frage der Zukunftssicherheit

Ein letztes Argument, das immer wieder für KVM und gegen Xen verwendet wird, ist die Zukunftssicherheit von Xen. Weil nicht wenige Admins Xen schon vor Jahren abgeschrieben haben, ist das Vertrauen in die Lösung vielerorts nicht mehr sehr groß. Tatsächlich gibt es aber kaum Gründe für die Annahme, dass Xen in absehbarer Zeit vom Markt verschwinden könnte. Denn inzwischen hat Citrix die Rechte an Xen wieder der Open-Source-Community übertragen. Heute ist Xen ein offizielles Projekt der Linux Foundation und steht damit sogar auf breiteren Füßen als KVM. Dort ist allein Red Hat bis heute der Motor.

Aktive Xen-Entwicklung findet noch immer statt. Erst Ende Juni dieses Jahres veröffentlichte Xen die Version 4.9, deren Fokus besonders die Aspekte Stabilität und Sicherheit sind. Immer wieder haben seine Entwickler Xen in den vergangenen Monaten und Jahren um Features erweitert, die es fit für den Einsatz in Rechenzentren machen.

Schon seit 2013 beherrscht es etwa den Umgang mit Open V-Switch, der in Clouds gerne für Software Defined Networking (SDN) zum Einsatz kommt. Die Mühe zahlt sich aus: In Open Stack ist Xen so gut auf Compute-Knoten zu nutzen wie KVM. Es ist also mit dem baldigen Verschwinden von Xen nicht zu rechnen. Die Lösung ist bei vielen Public Clouds weltweit im Einsatz und nach wie vor ist kommerzieller Support für die aktuellen Versionen zu bekommen.

Fazit

Klar ist: Die großen Unterschiede, die die Entscheidung zwischen KVM und Xen einst einfach machten, existieren heute nicht mehr. Beide Lösungen sind ausgereift und grundsätzlich geeignet zuverlässige Virtualisierung unter Linux anzubieten. Obgleich sich die Konzepte fundamental unterscheiden, lassen sich klare Vorteile höchstens in Sachen Hardwaretrennung für Xen ausmachen. Je nach Setup kann auch Performance das Zünglein an der Waage sein.

Weil Red Hat als Triebfeder hinter KVM steht und Xen mittlerweile von der Linux Foundation getragen wird, sind beide Ansätze zukunftssicher. Wer ein neues Virtualisierungssetup plant, sollte dem Reflex widerstehen und Xen als valide Option nicht von Anfang an ausschließen. Durchaus möglich nämlich, dass sich Xen als der geeignetere Kandidat entpuppt. Ausführliche Tests seien deshalb dringend angeraten.