Mit der Power heutiger Computer wissen die meisten Programme nicht viel anzufangen. Da bietet es sich an, mehrere Betriebssysteme auf einem Rechner zu starten. Das spart in Rechenzentren Geld für Hardware und den Anwendern lästiges Rebooten. Die Lösung Xen virtualisiert PCs extrem effizient.

Die Virtualisierung von Ressourcen auf PCs wird immer beliebter. Sowohl Rechenzentren als auch ISPs, Webhoster, Kernelentwickler und Desktop-Anwender nutzen Software wie VMware und User Mode Linux (UML). Mit diesen Anwendungen starten Benutzer parallel mehrere Betriebssysteme auf ein und demselben Rechner.

Auf diese Weise testen Kernelentwickler den gerade geschriebenen Code, ohne lange zu warten, bis der Rechner neu gestartet ist, und Rechenzentren sparen Hardware, indem Sie einfach mehrere Betriebssysteme auf einem Computer laufen lassen.

Das neueste Mitglied in der Riege der Virtualisierer ist das von der Systems Research Group der Universität Cambridge in England stammende Xen [1], auch Virtual Machine Monitor (VMM) genannt. Xen stammt ursprünglich aus dem Xenoserver-Projekt [2] derselben Universität, dessen Ziel es ist, eine offene Infrastruktur für verteiltes Rechnen in Weitverkehrsnetzen zu bauen.

Die GPL-Software Xen ist daher geschichtlich eng mit dem Grid Computing verwandt [3]. Dort stellt sich das Problem einer heterogenen Infrastruktur. Benutzer der Grids wünschen sich Umgebungen, die für ihre Programme verwendbar sind. Mit Xen vereinheitlichen Grid-Admins die Infrastruktur. Der Einsatzbereich hat sich jedoch weit über den ursprünglichen Zweck hinaus entwickelt. Der Kasten “Use Cases” beschreibt die Szenarien genauer.

Virtual Tux

Xen unterscheidet zwischen einer privilegierten Instanz (Domain 0, Dom 0 oder Xen 0) und den anderen, unprivilegierten Instanzen (Xenu, Domu). In der aktuellen Version 2 überlässt Xen die meisten Details der Hardware-Unterstützung dem in der Domain 0 laufenden Betriebssystem. Xen wartet somit unter Linux mit fast der gleichen Hardware-Unterstützung auf wie Linux selber. Nicht unterstützt werden derzeit noch APM und ACPI, was den Einsatz auf Laptops einschränkt. In der Domain 0 ist es möglich, die Kontrolle über einzelne Geräte dediziert an andere Instanzen zu übergeben. So weist der Admin etwa einer unprivilegierten Domain eine eigene physikalische Netzwerkkarte zu.

Abbildung 1 zeigt vereinfacht die Xen-Architektur im Überblick. Xen virtualisiert nicht so vollständig, wie es von Mainframes bekannt ist. Das liegt vor allem an der x86-Plattform, die keine entsprechenden Mechanismen enthält. Eine komplette Virtualisierung würde einiges an Performance kosten. Das Xen-Team hat sich daher dazu entschlossen, den performanteren Weg zu gehen und die Gastbetriebssysteme zu modifizieren, sodass die privilegierten Zugriffe über eine entsprechende Schnittstelle im Wirtssystem führen.

Abbildung 1: Bei Xen greifen alle Gast-Betriebssysteme über eine privilegierte Domain (Domain 0) auf die Hardware zu. Dazu ist es nötig, die Gastsysteme zu modifizieren. Der Virtual Machine Monitor überwacht alle Ressourcen.

Dieses Vorgehen nennen die Entwickler Paravirtualisierung. Der Nachteil ist, dass die Quellcodes aller Gäste zur Verfügung stehen und die Entwickler sie anpassen müssen. Der schwierigste Fall ist hierbei das Speichermanagement. Da sich die CPUs von x86-Systemen selbst um die Verwaltung der Speicherseiten kümmern (Hardware Managed Translation lookaside Buffer), hat Xen keinen Einfluss auf das Memory Management. Xen müsste mit sehr aufwändigen Mechanismen dafür sorgen, dass der Prozessor den von mehreren Betriebssystemen parallel genutzten Speicher nicht durcheinander wirft.

Der Trick, den die Entwickler daher anwenden (und ein Vorteil der Paravirtualisierung) ist, die Speicherverwaltung den Gastsystemen zu überlassen. Sie melden jede Reservierung von Seiten (Pages) an den VMM, sodass sich nichts in die Quere kommt. Details zu dieser und weiteren Techniken liefert [4].

Bei der Virtualisierung der CPU bricht Xen mit der üblichen Vorgehensweise, das Betriebssystem als privilegierteste Software im Computer anzusehen. Denn zwischen Hardware und Gastsystemen befindet sich der VMM (bei Xen auch Hypervisor genannt). Das ist problematisch, da die meisten Hardware-Architekturen nur zwei verschiedene Ebenen von Privilegien erlauben, eine für das OS und eine für Applikationen.

Hier ist x86 vorteilhaft, weil insgesamt vier so genannte Ringe verfügbar sind. Der Hypervisor läuft als einziger Prozess in Ring 0, die Gäste in Ring 1 und deren Applikationen in Ring 3. Die Gäste haben also keinen Zugriff auf bestimmte privilegierte Instruktionen der CPU. Versuche fängt der VMM ab.

Für die Kommunikation mit Geräten stellt Xen eigene Treiber zur Verfügung. Sie tun nichts weiter, als die Zugriffe zu validieren und sie eventuell an das eigentliche Device (etwa eine Festplattenpartition) weiterzureichen.

Gerätepark

In dem oben genannten Paper [4] findet sich der Hinweis, dass die Programmierer zur Anpassung von Linux an Xen lediglich 2995 Zeilen Code geändert oder hinzugefügt haben (ausgenommen Treibercode). Diese Aussage bezieht sich zwar noch auf eine ältere Version, zeigt aber, dass die Portierung auf Xen keinen übermäßigen Aufwand erfordert. Mittelfristig bleibt auch zu hoffen, dass Xen als Standardkomponente in den Linux-Kernel Eingang findet, wie es bei User Mode Linux bereits der Fall ist.

Neben Linux gibt es bereits Ports von NetBSD und FreeBSD auf Xen. Auch an der Portierung von Windows hat das Projekt gearbeitet, aus bekannten Gründen ist der Sourcecode nicht erhältlich, Binaries auch nicht. In näherer Zukunft soll dennoch eine transparente Unterstützung von Windows XP und 2003 Server mit Hilfe künftiger Intel- und AMD-Prozessoren möglich sein (Stichwort Vanderpool und Pacifica); zu den Xen-Unterstützern gehört unter anderem Microsoft Research.

Gegenwärtig arbeiten die Programmierer intensiv an einer Portierung auf AMDs x86_64- und Intels IA64-Architekturen. In der Version 3 hofft das Team auch ARM- oder PPC-Rechner zu unterstützen. Hilfe dabei nehmen die Entwickler immer gerne an.

Xen installieren

Die Installation der Xen-Komponenten ist unkompliziert. Der erste Hersteller, der Xen in seine Distribution aufgenommen hat, ist Suse mit Version 9.3 der Professional Edition (Abbildung 2). Der von den Autoren getestete Release-Kandidat 3 enthält Xen 2.0.5c. Ein Yast-Modul hilft dabei, Installationen für unprivilegierte Domains durchzuführen. Für Suse 9.2 gibt es ebenfalls Pakete [5].

Abbildung 2: Suse 9.3 startet als Domu standardmäßig im Runlevel 4. Den nutzt Suse normalerweise nicht, was Anpassungen der Runlevel in solchen Domains erleichtert, die auch gelegentlich ohne Virtualisierung booten sollen.

Anwender anderer Distributionen finden unter [1] ein Binary-Tarball mit einem Installationsskript, das alle Systemabhängigkeiten überprüft. Lediglich die Grub-Konfiguration (Lilo funktioniert mangels Multiboot-Unterstützung nicht) müssen Anwender von Hand durchführen, um die Xen-0-Domain zu booten.

Das Benutzerhandbuch [1] liefert allerlei nützliche Hinweise rund um die Konfiguration. Zur Fehlersuche während des Bootvorgangs empfiehlt es sich, die Kerneloption »noreboot« zu aktivieren, damit bei einer Kernelpanic das System nicht gleich wieder neu startet.

Zum Start von Gastinstanzen ist neben dem Xenu-Kernel eine Linux- oder BSD-Installation erforderlich. Xen unterstützt dafür die folgenden Medien:

• Dateisystem in einer Imagedatei
• Dateisystem in einer eigenständigen Partition
• Dateisystem auf einem LVM-Volume
• Via NFS importiertes Dateisystem
• Dateisystem auf einem I-SCSI-Device
• Dateisystem auf einem Network Block Device (NBD) oder Global
  Network Block Device (GNBD)

Vor allem in Clustern empfehlen sich die letzten beiden Optionen, wenn die virtuellen Instanzen zwischen den Computern des Clusters migriert werden. Hier ist es erforderlich, dass der Zugriff auf das Dateisystem unabhängig von dem Knoten ist, auf dem die Xenu-Instanz tatsächlich läuft. Um Speicherplatz auf dem Hostsystem einzusparen, liegt es nahe, »/opt« und »/usr« read-only via NFS zu importieren.

Der Versuch, eine Imagedatei über NFS zu verwenden, funktionierte im Test zunächst. Der Praxisbetrieb scheiterte jedoch daran, dass der Dom-0-Speicher nicht ausreichte. Das ist laut Aussage der Programmierer aber ein bekanntes Problem mit Linux bei gleichzeitiger Verwendung von NFS und Loopback.

Netzwerk in Domus

Die Netzwerkeinrichtung für Xenu-Domains erfolgt fast automatisch. Beim Start des Xen-Daemon »xend«, der die Instanzen verwaltet, startet das benötigte Bridged Network. Über die Konfigurationsdatei jeder Domain legt der Admin die virtuellen Interfaces für den Gast fest. Die MAC-Adresse wählt Xen zufällig aus einer statischen Liste aus.

Unter der getesteten Suse 9.3 erkannte Yast im Gastsystem zwar keine Netzwerkkarte, mit »ifup-dhcp ethN« startete aber stets ein Interface mit zugewiesener IP. Somit ist jede Instanz eines Xen-Systems übers Netz erreichbar, als liefe sie auf einem eigenen PC.

Statt einer kompletten Distribution bietet sich als Testsystem übrigens TTY Linux [6] an. Es ist nur wenige MByte groß und stellt die Basisfunktionalität für erste Tests bereit. Skripte helfen das System an die Bedürfnisse anzupassen.

Wandernder Desktop

Für die Verwaltung der Gastinstanzen enthält Xen das Programm »xm«. Zu seinen Fähigkeiten gehört, den Arbeitsspeicher einer Domain während ihrer Laufzeit zu verringern oder die CPU, auf der eine Domain läuft, zu wechseln. Die Optionen »save«, »restore«, »pause« und »unpause« dienen zum Speichern und Laden einer laufenden Instanz sowie zum Einfrieren und Auftauen.

Sehr nützlich ist die Möglichkeit, Gastsysteme von einem Host auf einen anderen zu übertragen, was sogar im laufenden Betrieb einwandfrei funktioniert. Während der Migration bleiben die Netzwerkverbindungen erhalten, damit auch bestehende Logins zu der migrierten Maschine. Nach einer Migration bestehen keinerlei weitere Verbindungen zu der Maschine, auf der das Gastsystem ursprünglich lief. Admins dürfen sie dann auch herunterfahren. Nutzt man die »–life«-Option von »xm«, beschränkt sich die Zeit, in der das System steht, auf Sekundenbruchteile.

Einziger Wermutstropfen ist die Tatsache, dass das Dateisystem des Gastsystems weiterhin erhalten bleiben muss. Es kommen also ausschließlich netzwerkbasierte Dateiysteme wie NFS, GPFS oder entsprechende Blockdevices wie NBD, GNBD oder I-SCSI in Frage.

Kampf der Giganten

Essenzielles Kriterium bei der Auswahl einer Virtualisierungstechnik ist die Performance. Von Interesse ist also, wie viel länger eine Aufgabe dauert, wenn sie statt mehrmals auf einem einzigen System jeweils einmal in einer von mehreren Xenu-Domains läuft. Als Referenz-Technik stand während der Benchmarks UML Pate. Die Tests erfolgten auf fünf Computer mit folgender Hardware:

• Dual Pentium III (Coppermine) 700 MHz, 256 KByte Cache
• 1 GByte RAM
• 40-GByte-IDE-HDD
• 100-MBit/s-Netzwerk

Um auch Werte für Ein-Prozessor-Systeme zu erhalten, haben die Tester einen der Rechner mit einem Xen-0-Kernel betrieben, der die zweite CPU erst beim Start weiterer Xen-Instanzen nutzt.

Zum Einsatz kam durchweg ein Kernel der 2.6.11-Serie, mit Ausnahme des Basiskernels von UML. Hier leistete Version 2.6.7 mit SKAS-Patch ihre Dienste. Dieses Patch beschleunigt die Ausführung von UML, daher erscheint es fair, hier wie auch für Xen einen optimierten Kernel zu installieren. Weiter gehende Optimierungen haben die Autoren jedoch nicht vorgenommen.

Für die Beurteilung der CPU-Geschwindigkeit kam der Benchmark “Four in a Row” von Freebench.org [9] zum Einsatz. Er spielt das Spiel “Vier gewinnt” mit einer Rekursionstiefe von neun auf einem sechs mal fünf großen Feld. Den Speicherdurchsatz maß PCompress, ebenfalls von Freebench.org. Er nutzt im Wesentlichen die Glibc-Funktionen »qsort«, »memcmp« und »memcpy«.

Den Durchsatz der Festplatten ermittelte »dd«. Gemessen haben die Autoren, wie lange es dauert, das erste GByte von einer Partition jedes untersuchten Systems einzulesen. Die Messungen für die Bandbreite des Netzwerks hat T- Bench ausgeführt. Es bestimmt dafür die Durchsatzrate zwischen dem Client und einem TBench-Server. Hier haben die Tester die Bandbreite ermittelt, die für alle virtuellen Instanzen nach außerhalb des Wirtssystems zur Verfügung stand.

Der abschließende Anwendungsbenchmark kompilierte einen Linux-Kernel 2.6.11. Hierbei kam grundsätzlich die Make-Option »-j 4« zum Einsatz, um die SMP-Fähigkeiten voll auszuschöpfen. Als Ergebnis galt jeweils die Zeit, die ein Benchmark benötigte. Sämtliche Werte sind stets in Relation zu dem Referenzsystem angegeben. Zum Vergleich eines Benchmarks, der auf beispielsweise vier virtuellen Instanzen lief, wurde derselbe Benchmark auf dem Referenzsystem ebenfalls viermal gestartet.

Das Linux-Magazin bedankt sich an dieser Stelle beim Forschungszentrum Karlsruhe, insbesondere bei den Leitern und Mitarbeitern des Instituts für Wissenschaftliches Rechnen für ihre tatkräftige Unterstützung.

Xen ist schnell

Four in a Row (Abbildung 3) zeigt keine deutlichen Unterschiede zwischen den verschiedenen Systemen. Der Einbruch der Xen-0-Domain bei mehr als einem Prozess erklärt sich dadurch, dass Xen nur eine CPU pro Instanz unterstützt. Dementsprechend steht den Xenu-Instanzen die volle Leistung beider Prozessoren zur Verfügung, sobald mehr als eine aktiv ist. UML und Xen sind hier fast gleichauf. Ein ähnliches Bild ergibt sich für das speicherintensive PCompress (Abbildung 4). User Mode Linux büßt knapp zehn Prozent ein, Xenu weniger als fünf. Die Xen-0-Domain ist auch hier wieder nur halb so schnell wie das Referenzsystem.

Abbildung 3: Bei dem CPU-lastigen Spiel “Four in a Row” sind kaum Auswirkungen der Virtualisierung zu erkennen. Die Abweichungen von Xen 0 bei den Mehr-Prozess-Balken ist dadurch zu erklären, dass Xen 0 bei nur einer laufenden Instanz auch nur eine CPU nutzt. UML und Xenu zeigen kaum Unterschiede.

Abbildung 3: Bei dem CPU-lastigen Spiel “Four in a Row” sind kaum Auswirkungen der Virtualisierung zu erkennen. Die Abweichungen von Xen 0 bei den Mehr-Prozess-Balken ist dadurch zu erklären, dass Xen 0 bei nur einer laufenden Instanz auch nur eine CPU nutzt. UML und Xenu zeigen kaum Unterschiede.

Beim Netzwerkdurchsatz (Abbildung 5) lässt Xenu User Mode Linux hinter sich. In dem Graphen sind die Durchsatzmessungen insgesamt dargestellt. Er zeigt also nicht die Leistung jeder einzelnen Instanz, sondern die aggregierte Leistung aller Gastsysteme zusammen. Dadurch lässt sich einfacher erkennen, wie gut das virtuelle System skaliert. Die ausgehende Netzwerkverbindung ist auf dem Stand-alone-PC selbst bei drei laufenden Prozessen nicht völlig gesättigt. User Mode Linux ist jedoch schon bei zwei Prozessen am Ende und bringt insgesamt nur etwa 60 Prozent der Leistung der anderen Systeme. Xenu hingegen liegt nur etwa zehn Prozent gegenüber dem Referenzsystem zurück.

Abbildung 5: Der Netzwerkdurchsatz zeigt deutliche Einbußen bei User Mode Linux. Das Referenzsystem ist offenbar mit nur einem Prozess nicht ausgelastet, UML erreicht bereits ab zwei Prozessen seine Grenze von 60 Prozent der Referenz. Hier punktet Xenu klar mit nur etwa zehn Prozent Verlust.

Der lesende Zugriff auf die Festplatte fördert erstaunliche Ergebnisse zutage (Abbildung 6). Er zeigt, dass die erreichbare Durchsatzrate in den Xenu-Domains stark davon abhängt, in welcher Art das Dateisystem zur Verfügung steht, als Partition oder als Imagedatei. Während Zugriffe auf ein Image meist mit weniger als zehn Prozent Einbußen laufen, sind Zugriffe auf Dateisysteme, die direkt auf einer Festplattenpartition liegen, nur etwa halb so schnell.

Abbildung 6: Mit »dd« haben die Tester den Festplattendurchsatz gemessen. Erstaunlich ist, dass Xenu mit Imagedateien sehr viel besser zurechtkommt als mit direkten Partitionszugriffen. UML zeigt das gleiche Phänomen, jedoch nicht so ausgeprägt. Aber auch aus diesem Wettkampf geht Xenu als Sieger hervor.

UML zeigt zwar den gleichen Effekt, jedoch lange nicht so dramatisch. Mit Imagedateien erreicht UML noch eine Durchsatzrate von etwa 70 Prozent eines nicht-virtuellen Systems. Die Performance von Xenu bricht auch hier um weniger als zehn Prozent ein. Außerdem soll ab Version 2.0.6 die Festplattendurchsatzrate von Xen in einer Partition mindestens so groß sein wie die im Image, vermutlich sogar eher größer.

Einen Kernel kompilieren gibt Anhaltspunkte dafür, wie sich das System unter hoher Gesamtlast verhält (siehe Abbildung 7). Bei einem Prozess ist zu sehen, dass auch die Xenu-Domains mit nur einer CPU laufen. Ansonsten kompilieren die Xenu-Domains den Kernel fast genauso schnell wie das Referenzsystem, höchstens zehn Prozent langsamer. Die Performance von User Mode Linux bricht unter Last auf weniger als fünfzig Prozent des optimalen Werts ein.

Abbildung 7: Xenu kompiliert auch den Kernel mit hoher Geschwindigkeit. UML hält nicht annähernd mit. Bei einem Prozess zeigt sich deutlich, dass die Xenu-Domains auf nur einer CPU arbeiten.

Fazit

Den Ergebnissen der Tests ist zu entnehmen, dass Xen robust, performant und plattformübergreifend einfach einzusetzen ist. Insbesondere die direkte Integration in eine Linux-Distribution macht Xen zumindest für erfahrene Benutzer problemlos. Aber auch die manuelle Installation, etwa unter Debian, erweist sich als nicht schwierig. Anders als User Mode Linux ist Xen jedoch noch nicht direkt in den Standardkernel integriert, ein solcher Schritt wäre mittelfristig wünschenswert. Bei Problemen fällt sehr positiv die kurze Antwortzeit der Xen-Maintainer und der zugehörigen Mailinglisten auf.

Direkte SMP-Unterstützung sollte bald verfügbar sein, in dem Sinne, dass auch Gastbetriebssysteme zwei Prozessoren sehen. Selbst native, unmodifizierte Betriebssysteme sind möglich, wenn die Hersteller ihre Prozessoren mit entsprechenden Funktionen ausgestattet haben. Für den kommerziellen Einsatz von Xen spricht, dass es seit Anfang dieses Jahres mit der Firma Xen Source [10] Support und Professional Services gibt. Deren Ziel ist es, Dienstleistungen in den USA und Europa anzubieten. (mwe)