Applikationen, Servicedienste und Middleware, die auf viele Systeme mit unterschiedlicher Hardware verteilt sind, können mit Hilfe der Systemvirtualisierung auf eine physikalische Maschine migriert und kostengünstig auf virtuellen Servern gehostet werden. Ein mögliches Szenario in der Softwareentwicklung wäre etwa der parallele Betrieb von Entwicklungs-, Test-, Qualitätssicherungs- und Schulungssystemen auf einem physikalischen Server. Kapital- und Betriebskosten für Hardware reduzieren sich so auf eine Maschine. Administration und Backup werden durch Zentralisierung vereinfacht und durch die dynamische Zuweisung von Ressourcen entsteht eine skalierbare Infrastruktur, die sich dem Bedarf der einzelnen Systeme jederzeit anpassen lässt.

Mit Xen steht eine freie Softwarelösung für die Systemvirtualisierung zur Verfügung, basierend auf Linux und x86-Hardware. Als Open-Source-Projekt an der Universität Cambridge [1] gestartet, wird Xen inzwischen von namhaften Firmen wie Intel, AMD, HP, IBM, Red Hat und Novell/Suse unterstützt. Die aktuelle Version 3 enthält einige Neuerungen wie Virtual-SMP für Gastbetriebssysteme und dynamische Aufteilung von Gastsystemen auf vorhandene Prozessoren. Durch die Nutzung der neuen Prozessor-Technologien Vanderpool von Intel und Pacifica von AMD können jetzt auch Gäste ohne spezielle Anpassung für Xen betrieben werden (z. B. Microsoft Windows). Um den von den Xen-Entwicklern gewählten Ansatz der hybriden Paravirtualisierung im Vergleich zu anderen Virtualisierungstechniken besser einschätzen zu können, zunächst ein paar grundsätzliche Betrachtungen.

Direkter Hardwarezugriff versus Emulation

Die Virtualisierung von (Betriebs-)Systemen erfolgt durch die Abkopplung von der zu Grunde liegenden Soft- beziehungsweise Hardware mit der Einführung einer weiteren Abstraktionsschicht. Man erhält dadurch eine logische Sicht auf vorhandene Ressourcen der Wirtshardware wie Prozessor, Arbeitsspeicher und Ein-/Ausgabegeräte und kann diese Ressourcen mehreren Gastsystemen zur Verfügung stellen. Die Abstraktionsschicht kann in Form von Hardware ausgeführt werden. Typischerweise wird diese Aufgabe jedoch von einer Software gelöst, indem eine Art rudimentäres Betriebssystem die abstrahierende Schicht zwischen Hardware und Gastsystemen bildet. Diese Softwareabstraktionsschicht wird als Virtual Machine Monitor (VMM) oder Hypervisor bezeichnet. Mit Hilfe des VMM lassen sich komplette Rechnerarchitekturen nachbilden, indem sämtliche Hardware inklusive Prozessor und Chipsatz emuliert werden. So kann man auf einer Hardware Systeme betreiben, die nicht für diese Rechnerarchitektur entworfen wurden (z. B. PowerPC-Mac als Gast auf physikalischer x86-Hardware). Diese vollständige Emulation ist aber für den professionellen Einsatz zu langsam, da die Umsetzung von Maschinenbefehlen und Registern viel zu aufwendig ist.

Virtualisierungslösungen wie Xen, die nur für Gastsysteme derselben Prozessorarchitektur wie die physikalische Maschine konzipiert sind, können direkt auf Prozessor und Hauptspeicher der Wirtshardware zugreifen. Hier werden die Maschinenbefehle der Gäste nativ ausgeführt. Die „teure“ Emulation beschränkt sich auf Peripheriegeräte (NIC, Disk- und andere Controller). Der Overhead durch die Virtualisierung kann so reduziert werden.

Die Gastsysteme sind sich ihrer virtuellen Umgebung nicht bewusst, sodass der VMM, jetzt in der Funktion des Oberaufsehers (Hypervisor), weiterhin jeden Hardwarezugriff abfangen und im Zusammenspiel mit den anderen Gastsystemen koordinieren muss. Zusätzlich sind die Speicherbereiche der virtuellen Server voneinander abzuschirmen.

Unterschiedliche Virtualisierungskonzepte

Als bekannte Emulatoren, die das Konzept der vollständigen Nachbildung von Rechnerhardware umsetzen, sind Qemu und Bochs zu nennen. Emulatoren, deren Gastsysteme die gleichen Maschinenbefehle wie die Wirtshardware verwenden, können in weitere Kategorien unterteilt werden:

Hybride Paravirtualisierung mit Xen

Werden Zugriffe der Gäste auf Peripheriegeräte (z. B. NIC, Disk) über ein privilegiertes Gastsystem, dem der direkte Zugriff auf die Wirtshardware erlaubt ist, weitergeleitet, spricht man von hybrider Virtualisierung. Seit Version 2 verfolgen die Xen-Entwickler dieses Modell, bei dem der VMM schlank und sicher ist und mit wenigen Gerätetreibern auskommt. Wie bereits oben erläutert, erzeugt das Abfangen und Prüfen aller Maschinenbefehle durch den VMM einen erheblichen Overhead. Xen reduziert diesen Overhead durch spezielle Aufbereitung des zu prüfenden Codes für den VMM und optimiert die Speicherverwaltung der Gäste, was allerdings Änderungen am Kernel der Gastbetriebssysteme erfordert. Diese Anpassung der Gastbetriebssysteme wird als Paravirtualisierung bezeichnet. Anwendungsprogramme innerhalb der Gastsysteme merken von dieser Modifizierung nichts. Xen ist somit die Umsetzung einer hardwarenahen, hybriden Paravirtualisierung.

Der Xen Virtual Machine Monitor (Hypervisor) setzt direkt auf der Hardware auf und virtualisiert CPU und RAM. Die privilegierte Domain 0 hat Zugriff auf die restliche Hardware und beherbergt Kontroll- und Steuersoftware. Die User Domänen erhalten mit virtuellen Geräten über die Domain 0 Zugriff auf die Hardware.

Wie im Schaubild zur System-Architektur dargestellt, läuft der VMM, der bei Xen ausschließlich als Hypervisor bezeichnet wird, direkt auf der Hardware und virtualisiert CPU und Hauptspeicher für die Gäste. Der Hypervisor ist bei Xen 3 ein modifizierter Linuxkernel 2.6. Das privilegierte Gastsystem, dem der direkte Hardwarezugriff erlaubt ist, wird in der Xen-Terminologie als Domain 0 oder dom0 bezeichnet. Die Domain 0, deren Betriebssystem in der Regel ein modifiziertes Linux ist, stellt den anderen Gastsystemen (Xen-Term.: User Domain oder domU) Gerätetreiber für den Zugriff auf Peripheriegeräte zur Verfügung und wird zum Starten, Stoppen und Verwalten der User Domains genutzt.

Xen in der Praxis

Im ersten Schritt wird eine bestehende Linux-Installation in den Xen Hypervisor und die Domain 0 konvertiert. Dafür stehen bei den Linux-Distributionen von Red Hat und Novell/Suse Binärpakete bereit. Xen kann aber auch aus den Sourcen komplett neu übersetzt und so in jede beliebige Linux-Distribution eingebunden werden. Beschreibungen mit Download-Quellen und genauer Anleitung sind mittlerweile für fast alle gängigen Distributionen vorhanden. Stehen die Kernel des Hypervisors und der Domain 0 zur Verfügung, ist noch die Konfiguration des Bootloaders anzupassen. Anschließend ist Xen für den ersten Start bereit. Dabei wird statt des nativen Kernels der Hypervisor und gleich danach die Domain 0 geladen. Nach dem erfolgreichen Booten muss der eigentliche Xen-Daemon (xend) gestartet werden, der die Kontrolle der User Domains übernimmt.

Im zweiten Schritt können jetzt User-Domains auf virtuellen Festplatten (Xen-Term.: VBD, Virtual Block Device) installiert werden. Als Medium für VBDs sind Imagedateien, eigenständige Partitionen, Netzwerkdateisysteme (NFS, CIFS), entfernte Blockgeräte (Fibre Channel, iSCSI), Netzwerkblockgeräte (NBD, GNBD) und Clusterdateisysteme (GFS, OCFS, PeerFS) möglich. Gebootet werden neue Linux-User-Domains mit dem bei der Installation von Xen mitgelieferten, bereits paravirtualiserten XenU-Kernel. Notwendige Informationen wie Angaben über Kernel, VBD, RAM, NIC und Namen der User Domain werden beim Starten mit Hilfe einer Konfigurationsdatei übergeben. Mit dem Kommandozeilentool „xm“ lässt sich Xen nahezu vollständig administrieren. Einen Überblick über die möglichen Optionen erhält man mit „xen help“ (Expertenmodus: „xen help –long“). „xm list“ zeigt alle aktiven Domains mit ID und RAM. Mit „xm create /etc/xen/domU1.cfg“ wird eine User-Domain gestartet und deren Konfigurationsdatei übergeben. Das Kommando „xentop“ überwacht CPU-, Speicher- und I/O-Auslastung aller laufenden Domains einschließlich Domain 0.

Technische Daten und Gastbetriebssysteme

Xen 3 kann bis zu 32 physikalische Prozessoren mit SMP nutzen und diese über VirtualSMP auch den Gastsystemen zur Verfügung stellen. Der maximale VirtualRAM für Gastsysteme entspricht dem nutzbaren Hauptspeicher der Domain 0. CPU, RAM, NIC- und Disk-I/O können der Domain 0 und den User Domains nach Erfordernis und zum Teil auch dynamisch (im laufenden Betrieb) zugeteilt werden. Sämtliche Hardware, die das Betriebssystem der Domain 0 unterstützt, steht für Xen zur Verfügung. Den User Domains stehen als virtuelle Hardware NIC, SCSI, IDE, Parallel, Seriell und USB zur Verfügung. Die maximale Anzahl aktiver Gäste ist lediglich durch die vorhandenen Ressourcen wie CPU und RAM begrenzt.

Xen 3 unterstützt auch x86/64-Bit-Hardware und ermöglicht das Betreiben von 32- und 64-Bit-Gastbetriebssystemen. Eine Mischumgebung aus 32/64-Bit ist jedoch nicht möglich. Wird Xen mit PAE36-Support übersetzt, ist bei 32-Bit-Hardware der Zugriff auf bis zu 64 Gigabyte RAM möglich. Für Linux (Kernel 2.6), NetBSD, FreeBSD, NetWare, Opensolaris, Mini OS und Plan 9 sind Portierungen für den Betrieb als User Domains vorhanden.

Windows XP wurde von den Xen-Entwicklern ebenfalls erfolgreich paravirtualisiert (mit Erlaubnis von Microsoft, jedoch ohne Veröffentlichung der modifizierten Version). Unmodifiziert ist der Betrieb von Windows als Xen-Gast nur auf Prozessoren möglich, die eine spezielle „Virtualization Technology“ (VT) implementieren. Dabei wird die Virtualisierung bereits auf Prozessorebene durch eine neue Form von CPU-Operationen, den Virtual Machine Extensions (VMX) unterstützt. Der VMM agiert im VMX-Root-Modus und besitzt volle Kontrolle über Prozessor und sämtliche Hardware. Die Gastbetriebssysteme arbeiten im VMX-Non-Root-Modus. Entsprechende Prozessoren stehen mittlerweile von Intel (Vanderpool) und AMD (Pacifica) zur Verfügung.

Livemigration

Bei der Livemigration können Gastbetriebssysteme im laufenden Betrieb von einem Xen-Server auf einen anderen umziehen. Die Gesamtdauer der Migration beträgt 30 bis 60 Sekunden, die eigentliche Ausfallzeit ist dabei kleiner als eine Sekunde und wird so von Anwendern nicht bemerkt. Betriebsunterbrechungen wegen Wartungsarbeiten oder Austausch von Hardware können so vermieden werden. Die Migration erfolgt über das Netzwerk durch iterativen Transfer des Hauptspeicherinhalts. Die virtuelle Festplatte des zu migrierenden Gasts muss sich im gemeinsamen Speicher der beiden Xen-Server befinden. Mögliche Medien für den gemeinsamen Speicher sind entfernte Blockgeräte, Netzwerk- oder Cluster-Dateisysteme. Durch diese Eigenschaft hebt sich Xen von vielen anderen Virtualisierungslösungen ab. Nur die kostenpflichtigen Produkte ESX Server von VMware und Virtuozzo von SWsoft bieten ebenfalls die Möglichkeit der Livemigration.

Management und Support

Für das Management von Xen mit grafischen Benutzerwerkzeugen gibt es einige vielversprechende Ansätze, die nach aktuellem Stand allerdings noch nicht für einen produktiven Einsatz geeignet sind [2]. Mit den mitgelieferten Kommandozeilentools von Xen können jedoch alle erforderlichen Verwaltungsaufgaben erledigt werden. Support leistet wie bei allen aktiven Open-Source-Projekten die Gemeinschaft der Entwickler und Anwender über Community-Plattformen und Newsgroups [3]. Das Unternehmen XenSource [4] wird mit XenEnterprise ein kostenpflichtiges Gesamtpaket inklusive Support für den professionellen Einsatz von Xen anbieten.

Fazit und Ausblick

Xen 3 ist eine ausgereifte und stabile Open-Source-Softwarelösung für den Betrieb von virtuellen Servern auf x86-Hardware. Mögliche Gastsysteme sind Linux, xBSD, NetWare, Opensolaris, Mini OS, Plan 9 und, auf Prozessoren mit Vanderpool- beziehungsweise Pacificatechnologie, auch unmodifizierte Betriebssysteme wie Microsoft Windows. Xen unterstützt auch weitere Hardware-Architekturen: In der aktuellen Version ist IA64 (Itanium) bereits umgesetzt und die Implementierung für die PowerPC-Architektur soll bald folgen. Mit dem gewählten Ansatz der hybriden Paravirtualisierung kann Xen durch hervorragende Performance überzeugen. Die Leistungseinbußen liegen bei maximal fünf Prozent im Vergleich von virtuellem zu nativem Betrieb.

Für Installation und Administration sind gute Linuxkenntnisse erforderlich. In Punkto Management mit grafischen Tools und Dokumentation gibt es noch einige Defizite gegenüber vergleichbaren proprietären Virtualisierungslösungen.

Die aktuellen Enterprise Linux-Distributionen von Red Hat (RHEL5, angekündigt für 12/2006) und Novell/Suse (SLES10, bereits verfügbar) werden mit integriertem Xen ausgeliefert, Microsoft wird in der Virtualisierungslösung seiner nächsten Servergeneration (Longhorn) auch den Betrieb von Xen-Gastsystemen ermöglichen. Die Schnittstellen zum Hypervisor wurden von den Xen-Entwicklern eingefroren, sodass Portierungen von weiteren Betriebssystemen erfolgen werden. Xen wird mittels der generischen Schnittstelle „paravit_ops“ in den offiziellen Linux-Kernel 2.6 integriert. Mit der weiteren Unterstützung durch namhafte Firmen (Intel, AMD, HP, IBM, Red Hat, Novell/Suse) und der Zusammenarbeit der weltweiten Community kann Xen zum Katalysator der Virtualisierung unter Linux werden.