Ende letzten Jahres war es so weit: Nach ausgiebigen Tests erschien die lang erwartete Xen-Version 3. Das Open-Source-Projekt der Universität Cambridge [1] hat sich zu einer der führenden Virtualisierungslösungen unter Linux entwickelt und wird von namhaften Firmen unterstützt, darunter Novell, Red Hat, HP, IBM, Intel und AMD. Dank sehr guter Performance bei geringen Kosten könnte es zum Katalysator der Virtualisierung unter Linux avancieren.

Gäste-Kontrolle

Rechner lassen sich auf verschiedene Weise virtualisieren (siehe auch Artikel "Server in Potenz" in diesem Heft). Die so genannte volle Virtualisierung emuliert Hardware durch Software. Dazu bildet sie die Chips eines Rechners, etwa CPU oder Tastaturcontroller, per Software nach. Besonders teuer dabei ist die Emulation der CPU, die jeden einzelnen Maschinenbefehl interpretieren muss. Denn selbst wenn sie nur Rechner derselben CPU-Architektur imitiert, der Maschinencode also nativ ausführbar ist, muss der Emulator alle Hardwarezugriffe abfangen und die Speicherbereiche der virtuellen Maschinen voreinander abschirmen. Das ist nötig, weil die Betriebssysteme dieser Maschinen nichts von ihrer virtuellen Umgebung wissen und in dem Glauben handeln, sie hätten die exklusive Verfügungsgewalt über Hardware, Memory und Filesysteme. Emulatoren, die in dieser Weise ihre Gäste kontrollieren, bezeichnet man auch als Hypervisor.

Eine Modifikation dieses Modells besteht darin, privilegierten virtuellen Maschinen die direkte Kommunikation mit der Hardware zu erlauben und die Zugriffe der anderen Instanzen an sie weiterzureichen. Auf diese Weise kommt der Hypervisor selbst mit wenigen Gerätetreibern aus. Man spricht von hybrider Virtualisierung.

Kann der Hypervisor nicht damit rechnen, dass ihn die CPU bei kritischen Instruktionen automaisch ins Spiel bringt - bei Intel und AMD werden das erst die künftigen Technologien Vanderpool beziehungsweise Pacifica ermöglichen -, dann muss er selbst auf seinen Einsatz achten. Das kostet allerdings erheblich Performance.

Der Verlust lässt sich aber zumindest teilweise wieder ausgleichen, wenn dem Hypervisor der zu überprüfenden Code mundgerecht aufbereitet wird. Allerdings hat auch diese Strategie, die man auch Paravirtualisierung nennt, einen Nachteil: Sie erfordert Änderungen am Kernel der Gastssysteme. Kein großes Problem für offene Betriebssysteme wie Linux oder xBSD, aber eine kaum überwindliche Hürde etwa für Windows.

Xen 3: Hybride Paravirtualisierung

Die Xen-Entwickler haben den Ansatz der Paravirtualisierung gewählt. Während die 1.x-Versionen mit eigenen Gerätetreibern ausgestattet waren, verfolgen die Entwickler seit Version 2 (Herbst 2004) das Ziel, den Hypervisor möglichst klein und sicher zu machen. Zugriff auf die Hardware haben nur privilegierte Domains - das ist der Xen-Terminus für virtuelle Maschinen. Dieses Vorgehen entspricht dem hybriden Modell.

Zudem hat die erste gebootete Domain 0 besondere Rechte; insbesondere das Recht, andere virtuelle Maschinen zu konfigurieren, zu starten oder auch wieder anzuhalten. Die Domain 0 fährt direkt nach dem Starten des Hypervisors hoch, ohne sie kann dieser auch nicht viel tun. Im Unterschied zur Domain 0 - kurz »»dom0«« - nennt man die unprivilegierten Maschinen »domU« (siehe Abbildung 1).

Abbildung 1: Der Xen-Hypervisor virtualisiert CPU und Speicher. Während die privilegierte Domain 0 Zugriff auf die gesamte verfügbare Hardware hat, stehen den anderen Domains nur virtuelle Geräte zur Verfügung.

Weil Entwickler die Gastbetriebssysteme für Xen erst vorbereiten müssen, sind nur bestimmte verfügbar. Außer Linux stehen Mini OS, mehrere BSD-Varianten sowie Plan 9 zur Auswahl. In allen Fällen ist nur der Betriebssystemkern von den Änderungen betroffen; die Anwendungsprogramme merken von der virtuellen Umgebung nichts. Auch Windows lässt sich paravirtualisieren, wie die Xen-Entwickler mit Unterstützung von Microsoft bereits demonstriert haben. Allerdings dürfen sie diese Version nicht in Umlauf bringen.

Xen beeindruckt mit überragender Performance. Während bei rechenintensiven Anwendungen die meisten Virtualisierungslösungen gut aussehen, zeigt sich bei Anwendungen mit vielen Systemaufrufen - in der Regel sind das Ein- und Ausgaben auf Festplatte oder Netzwerk - die wahre Qualität einer virtuellen Maschine. Hier kann Xen punkten. Der Overhead liegt beim Kompilieren des Kernels bei nur etwa zwei Prozent, bei Webbench über Gigabit-Ethernet immer noch bei weniger als zehn Prozent. Man muss schon die MTU verkleinern, um Xen mit Gigabit ins Schwitzen zu bringen. Damit hängt Xen VMware und User-Mode Linux deutlich ab, wie Benchmark-Ergebnisse zeigen [2].