© Dmitriy Shironosov, 123RF.com

Die beiden Platzhirsche in Sachen Virtualisierung auf Linux sind zweifellos KVM und Xen. Beide Projekte haben eine bewegte Geschichte hinter sich – am Anfang lag Xen vorne, dann holte KVM auf, doch entgegen allen Erwartungen ist auch Xen noch nicht tot. Unter der Libvirt sind nun beide vereint.

“Gefahren warten nur auf jene, die nicht auf das Leben reagieren”, sagte einst Michael Gorbatschow zu Erich Honecker, später medial begradigt und berühmt geworden als “Wer zu spät kommt, den bestraft das Leben”. Auch im Bereich der Virtualisierung passt das historische Zitat. Gerade das älteste Linux-Virtualisierungsprojekt kann ein Lied davon singen, was freien Softwareprojekten droht, die nicht mit der Zeit gehen: Weil es lange Zeit unmöglich war, Xen mit einem neueren Kernel als 2.6.32 zu nutzen, konnte KVM zum dominierenden Hypervisor für Linux werden, Xen wäre beinahe in der Versenkung verschwunden.

Anfänge der Virtualisierung

Klar, Virtualisierung fängt nicht erst mit KVM [1] und Xen [2] an: Seit Jahrzehnten “partitioniert” IBM die Ressourcen seiner Mainframes. Aber das war auch Hardware im teuren Unternehmenssegment, oft mit Preisen im sechsstelligen Dollar-Bereich. Damit das heutige Szenario der massenhaft verbreiteten Virtualisierung entstehen konnte, war eine andere Entwicklung innerhalb der IT von essenzieller Bedeutung: Computer wurden in den letzten Jahren immer leistungsfähiger und billiger.

Noch vor 15 Jahren war es kein Problem, einen damals aktuellen Rechner auszulasten. Leistungsreserven waren kaum vorhanden. Gab es bei neuer Hardware doch mal welche, sorgten die Entwickler der Anwendungen üblicherweise dafür, dass die Reserven schneller weg waren, als Hardwarehersteller neue Technik liefern konnten.

Heute? Leistung satt!

Heute lassen sich selbst Entry-Level-Server von der Stange mit gängigen Applikationen wie einfachen Webservern kaum auslasten. Der Leerlauf wurde Programm, Admins mussten ihn billigend in Kauf nehmen. Doch ungenutzte oder nicht ausgelastete Hardware ist totes Kapital, ein Dorn im Auge der Controller. Da war es kein Geniestreich, mehrere Systeme auf der gleichen Hardware laufen zu lassen, um die vorhandenen Ressourcen optimal auszunutzen.

Das erste Unternehmen, das sich mit einer entsprechenden Lösung auf den Markt wagte, war VMware: 1999 stellten die Amerikaner eine zunächst auf Desktops ausgerichtete Virtualisierungslösung vor, die mit Servern noch gar nichts am Hut hatte, sondern es vielmehr erlaubte, Desktopsysteme unter Windows zu virtualisieren.

Ring frei!

Nur wenig später begann der große Linux-Hype. IBM schaltete Fernsehspots für das freie System, auf Servern gewann Linux zunehmend an Boden. Und schließlich brachte wiederum VMware im Jahre 2001 den ersten GSX-Server auf den Markt, ein speziell auf Server ausgerichtetes Virtualisierungssystem.

Von da an entwickelte sich Virtualisierung von einer belächelten Nische zu dem, was man damals für die Zukunft im Servermarkt hielt. Wie sich in der Zwischenzeit herausstellte, war diese Annahme nicht ganz falsch, nur in der FOSS-Welt herrschte da lange Zeit tote Hose. Alles, was zwischenzeitlich von VMware kam, war proprietäre Closed-Source-Software.

2003: Xensource

Die ersten zaghaften Entwicklungen hin zu einem quelloffenen Hypervisor kamen unter Linux erst 2003 auf: Vor ziemlich genau zehn Jahren veröffentlichte die Firma Xensource die erste Version von Xen, eines neuartigen Hypervisors für Linux unter der GPL. Keir Fraser, Steven Hand und Ian Pratt waren die Entwickler, die im Computerlabor der Universität von Cambridge (England) den Grundstein für eine freie Virtualisierungslösung gelegt haben.

Die Funktionalität der ersten Xen-Versionen war jedoch noch sehr eingeschränkt und konnte kaum mit VMware mithalten. Außerdem richtete sich Xen zu diesem Zeitpunkt noch an Desktop-User, nicht an Server-Admins. Dabei war der technische Unterbau der Software durchaus ordentlich: Bereits in den ersten öffentlich zugänglichen Versionen setzte Xen auf Paravirtualisierung, also auf das Prinzip, bei dem das virtualisierte System weiß, dass es virtualisiert ist, und über entsprechende Treiber unmittelbar auf die Hardware des Hosts zurückgreift.

Im Gegensatz zur Vollvirtualisierung bringt das den Vorteil, dass das Betriebssystem auf dem Host – in Xen-Sprech die »dom0« – nicht die komplette Kommunikation zwischen dem Gast-OS und der Hardware des Host-Betriebssystems übersetzen muss, was einen Performancevorteil ausmachen kann.

Gemischt-, Voll- oder Paravirtualisierung

Vollvirtualisierung baut tatsächlich einen kompletten PC nach. Die Mischform aus Para- und Vollvirtualisierung ist heute Standard: Man emuliert einen kompletten PC, gibt diesem aber über spezielle, paravirtualisierte Treiber wiederum Zugriff auf die Hardware des Hosts.

Ende 2005 erschien Xen in der wegweisenden Version 3.0, die wichtige Neuerungen wie die Unterstützung für die Virtualisierungssysteme der Hersteller Intel (VT-D) und AMD (SVM) mitbrachte und somit endlich für den Enterprise-Einsatz bereit war (Abbildung 1). Eine Zeit lang hielten die Xen-Entwickler ihre Patches für Linux aktuell und es gab sogar Bestrebungen, Xen fix in den Kernel zu integrieren.

Doch dann brach sich ein Disput Bahn, der die Szene in Atem hielt: Die Kernelversion 2.6.23 erschien im September 2006 und brachte zum ersten Mal ein natives Interface für paravirtualisierte Anwendungen mit, die so genannten Paravirtualized Ops (»paravirt-ops« , [3]).Die unterschieden sich jedoch deutlich von der Art und Weise, wie Xen bis dahin Virtualisierung umgesetzt hatte. Ein beachtlicher Umbau stand also ins Haus, und der ließ lange auf sich warten.

Auf Jahre hinaus hatten Admins nur die Wahl zwischen einem veralteten Kernel (2.6.18) oder aktueller Hardware. Dieser Zeitraum hinterließ bei vielen Admins, aber auch im Xen-Projekt selbst, sehr unangenehme Erinnerungen und bewegte nicht wenige Experten zur Suche nach Alternativen.

Abbildung 1: Auch KVM kann die in aktuellen CPUs verbauten, Hardware-spezifischen VT-D- oder SVM-Technologien im Hostkernel ansprechen.

Auftritt KVM

So blieb Xen nicht lange allein. Im Mai 2005 hatte der Israeli Avi Kivity die Firma Qumranet gegründet und entwickelte still und leise einen neuen Hypervisor für Linux. Anders als die Xen-Entwickler tat er das in enger Kooperation mit den Kernelentwicklern, 2006 gab er seine Patches beispielsweise über die Kernel-Mailingliste weiter [4] und achtete stets darauf, den Code für die Integration in Linux vorzubereiten.

Kivitys Mühen fanden ihre Belohnung darin, dass Linus Torvalds KVM offiziell in den Kernel 2.6.20 aufnahm, der Anfang 2007 erschien. 2008 krönte sich Kivity selbst, indem er und seine Partner Qumranet an die roten Hüte verkauften. Red Hat sah in Qumranet ein Unternehmen, das gut zu den frisch verabschiedeten Virtualisierungsplänen aus Raleigh passte [5].

Der Schritt überraschte dennoch wenig, denn KVM war zu diesem Zeitpunkt bereits auf einem Siegeszug, der bis heute anhält: Zum ersten Mal in der Linux-Geschichte ließ sich mit dem Vanilla-Kernel Virtualisierung betreiben. Ein externes Patch wie bei Xen war nicht länger nötig, sodass die Wartungshürden für KVM viel niedriger waren als für Xen.

Obendrein war es verhältnismäßig leicht, KVM auf den aktuellen Stand der Technik zu bringen: Was bei Xen stets das Neukompilieren des Kernels mit entsprechenden Reboots erforderte, ließ sich mit KVM durch das Entfernen des aktuellen Kernelmoduls aus dem Kernel und dem Laden des zuvor gebauten, neuen Moduls erreichen (Abbildung 2).

Heute gehört KVM zum Inventar jeder Distribution. Das Fedora-Projekt bietet auf seiner Website sogar paravirtualisierte Treiber für die Netzwerk- und Storage-Anbindung [6] an, mit denen die VM auch bei vollvirtualisierten Systemen mehr Performance aus dem System kitzelt als mit den Standardtreibern.

Abbildung 2: Anders als Xen setzte KVM nie das aufwändige Patchen des Kernels auf dem Host voraus, sondern kam in Form eines ladbaren Kernelmoduls daher.

Citrix steigt ein

Das starke Engagement von Red Hat für KVM sorgte auch dafür, dass Xen in der Virtualisierungswelt eine immer kleiner werdende Rolle spielte. Doch wer die Virtualisierungslösung bereits für tot gehalten hatte, wurde in den folgenden Jahren eines Besseren belehrt. Denn auch Xensource fand 2007 einen neuen Besitzer: Citrix.

Die Firma, die sich in der IT vor allem durch proprietäre Terminalserver und Virtual-Desktop-Infrastruktur-Anwendungen (VDI) einen Namen gemacht hat, schlug zu, erwarb den Hersteller von Xen und verfolgte fortan mit Xen Server (siehe den Artikel in der Sysadmin-Rubrik) als Virtualisierungsprodukt für Server und dem Xen Desktop eine ganz eigene Agenda.

Dass es dennoch so lange dauerte, bis Xen einen weiteren Schritt in seiner Entwicklung hinlegte, lag auch an Citrix, das eigene Prioritäten vor den technischen Fortschritt setzte. Erst in den letzten Jahren nahm die Aktivität rund um Xen wieder zu: Die Version 4.0, die im April 2010 erschien, bot erstmals volle Unterstützung für die Paravirtualization Ops des Linux-Kernels sowohl für Dom-0- wie auch für Dom-U-Systeme. So lassen sich endlich auch aktuelle Kernel mit Xen ohne Probleme betreiben. 2011 schaffte es Xen in den Mainline-Kernel.

Die Entwicklung gewinnt zunehmend an Fahrt, bei Redaktionsschluss war die aktuelle Xen-Version 4.3 veröffentlicht und die Planungen für Xen 4.4 hatten begonnen. Im April 2013 übergab Citrix schließlich die Entwicklung von Xen selbst an die Linux Foundation, die damit nun als offizieller Pate des Projekts agiert. Mit der Version 6.2 ihres Xen Servers gaben die Amerikaner schließlich das komplette Managementprodukt als Open-Source-Software frei.

Red Hats Libvirt

Von vielem, was Xen und KVM unter der Haube machen, bekommen Admins heute gar nichts mehr mit – und da mag manch geplagter Früheinsteiger ausrufen: “Gott sei Dank!” Nach sieben Jahren Entwicklung gab Maintainer Daniel Berrange am 2. November 2012 den finalen Status der Libvirt-Version 1.0.0 [7] bekannt [8], die sich schon länger als einheitliches Frontend für die Verwaltung von Hypervisoren und Cloudrechnern (Hosts und Gäste) anbot (Abbildung 3).

Vor nicht allzu langer Zeit war das noch ein großes Problem gewesen: Gerade die Steuerung virtueller Gäste wurde bei KVM und Xen praktisch ohne jede Gemeinsamkeit implementiert. Beide Systeme nutzten grundlegend andere Befehle. Die Libvirt abstrahiert nun die Funktionen für die Hypervisoren und stellt sie über eine Administrationsschnittstelle zur Verfügung – wahlweise als API, als Shell in Form von Virsh [9] oder im Qt- oder GTK-GUI des Virt-Managers (Abbildung 4, [10]).

Der Bedarf für eine einheitliche Benutzeroberfläche war groß, das Projekt wuchs schnell, wie die Animation der ersten sieben Jahre zeigt [11]. Das dürfte maßgeblich zum Erfolg der Virtualisierung auf Linux beigetragen haben. Heute greifen auch Cloudmanager wie Open Stack (oder auch Xen Server) auf die Libvirt zu und abstrahieren selbst diese Zwischenschicht für den Admin.

Abbildung 3: Die Libvirt hat in den vergangenen Jahren stark dazu beigetragen, Virtualisierung auf Linux marktreif zu machen. Die Konfiguration landet dabei in XML-Dateien.

Abbildung 4: Red Hats Virt-Manager gibt dem Anwender ein GUI, das sich nicht hinter proprietären Alternativen zu verstecken braucht und neben Xen und KVM auch die Linux-Container administrieren kann.