Mainframes konnten es schon lange, dank Xen 3 beherrscht es nun auch der PC: Auf einer Hardware laufen viele virtuelle Rechner verschiedener Betriebssysteme. Wie das gelingt, welche Probleme zu lösen sind und wozu das alles gut ist, erklärt dieser Beitrag.

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].

Maschinenumzug

Seit Version 2 bietet Xen die Möglichkeit, virtuelle Maschinen (außer Domain 0) von einer physischen Maschine auf eine andere umziehen zu lassen. Den Speicherinhalt der virtuellen Maschinen überträgt Xen über das Netzwerk – wobei diese lediglich am Ende ganz kurz anhalten müssen, um die letzten veränderten Speicherseiten zu kopieren. Die Xen-Entwickler haben dies mit Webservern unter Last und auch Videostreamern demonstriert. Dabei sind Unterbrechungen in der Größenordung von einer Zehntelsekunde typisch.

Mit der Version 3 vom Dezember 2005 erreichte Xen einen wichtigen Meilenstein: Die Entwickler präsentierten nicht nur viele neue Features (siehe Kasten “Neuerungen in Xen 3”), sie froren auch die Schnittstelle zwischen den paravirtualisierten Betriebssystemen und dem Hypervisor ein. So fällt in Zukunft die Arbeit zur Paravirtualisierung des Betriebssystemkerns nur einmal an und weitere Portierungen von Betriebssystemen, beispielsweise von Netware, sind zu erwarten.

Wer mit Xen beginnen möchte, kommt am einfachsten mit einer existierenden Linux-Installation zum Ziel, die er in eine Xen-»dom0« konvertiert. In einem zweiten Schritt kann man dann weitere Domains aufsetzen, um zusätzliche Aufgaben zu erledigen oder Dienste in eigene Domains zu verlagern.

Einstieg in Xen

Der erste Schritt zur Konvertierung ist die Installation des Hypervisors und der Tools. Das genaue Vorgehen richtet sich nach der verwendeten Distribution. Bei Suse Linux 10.0 heißen die entsprechenden Pakete etwa »xen«, »kernel-xen« und »xen-tools«. Möglicherweise sind weitere Xen-Pakete vorhanden, die man installieren sollte. So ist beispielsweise in Suse Linux die Dokumentation in eigene Pakete ausgelagert. Wenn die Pakete älter sind als Dezember 2005, empfiehlt es sich in jedem Fall, nach Updates Ausschau zu halten, da sich die Stabilität inzwischen deutlich verbessert hat.

Sind die Pakete installiert, sollte man einen zusätzlichen Bootloader-Eintrag für Xen anlegen. So lässt sich beim Booten entscheiden, ob die Maschine einen nativen Kernel oder den Xen-Hypervisor mit »dom0«-Kernel laden soll. Der Bootloader-Eintrag für Grub kann so aussehen:

title XEN
root (hdX,Y)
kernel /xen.gz XEN-Parameter
module /vmlinuz-xen Kernelparameter
module /initrd-xen

Im Beispiel steht »(hd X,Y)« für die Partition mit dem »/boot«-Verzeichnis. Wie der Kernel akzeptiert auch Xen Parameter – so setzt man etwa mit »»dom0«_mem=XXX« die Größe des Arbeitsspeichers in »dom0« fest (in KByte). Ist nichts eingegeben, bekommt »dom0« zunächst den gesamten Arbeitsspeicher zugeschlagen. Mit »lapic« kann man einen APIC-Interruptcontroller einschalten, der vom Bios deaktiviert wurde – dies kann Interruptprobleme beheben.

Ist alles so weit vorbereitet, kann der Rechner nun den Hypervisor und den »dom0«- statt des nativen Kernels laden. In der Regel verläuft das unspektakulär: Der Bootvorgang sieht ganz normal aus und auf den ersten Blick ist das Linux-System unverändert. Wer genauer hinschaut, sieht, dass der Hypervisor einige Initialiserungsmeldungen ausgibt. Wenn der Distributor normalerweise einen grafischen Bootvorgang (Bootsplash) aktiviert hat, ist dieser nun nicht aktiv – stattdessen ist man mit dem freundlichen VGA-Textmodus konfrontiert.

Treiberprobleme

Der Grund für den Textmodus liegt darin, dass der Vesa-Framebuffer-Treiber unter Xen nicht funktioniert. Da der Hypervisor den Kernel im Protected Mode des Prozessors startet, kann der Kernel nicht die Real-Modus-Routinen des VGA-Bios aufrufen, um den Bildschirmmodus einzustellen.

Es gibt weitere Hardwaretreiber, die die Zusammenarbeit unter Xen verweigern. Dazu zählen einzelne Wireless-Treiber sowie die proprietären 3D-Treiber von Nvidia und ATI – die freien Treiber funktionieren. Weiterhin gibt es Probleme mit ISA-Karten, die DMA-Transfers benutzen. Ursache ist oft eine fehlerhafte Umsetzung von physischen in so genannte Maschinenadressen, die in manchen Fällen nicht der Hypervisor, sondern der Treiber leisten muss. Portabel programmierte Gerätetreiber haben damit kein Problem.

Wenn Probleme mit Hardwaretreibern auftreten, funktioniert im besten Fall der Treiber nicht – im schlimmsten Fall stürzt der »dom0«-Kernel ab. Passiert Letzteres nützt die Virtualisierung leider nichts, da der Hypervisor ohne den »dom0«-Kernel hilflos ist – er hat ja keine eigenen Treiber für Tastatur oder Bildschirm, über die man dann eventuell Debugversuche unternehmen könnte.

Kommt es zu einem solchen Absturz, ist es das Einfachste, den schuldigen Treiber zu deaktivieren – in der Regel wird das der letzte sein, von dem man Meldungen zu Gesicht bekam. Die häufigste Ursache ist ein 3D-Treiber für X11 – hier hilft es, einfach im Textmodus zu starten.

Ging alles gut, läuft nun ein Linux System in der »dom0«, welches sich von einem nativen System kaum unterscheidet. Dies ist der Idealfall: Alles funktioniert wie gehabt. Bei genauem Hinschauen sieht man, dass etwa 50 MByte weniger Speicher verfügbar sind, die sich Xen beim Start reserviert.

Die Init-Skripte sollten beim Booten der »dom0« auch Xend gestartet haben. Das ist ein Daemon, der die Kontrolle über andere virtuelle Maschinen innehat. Wenn er läuft, kann man als Root über das »xm«-Tool Informationen über virtuelle Maschinen abfragen, neue virtuelle Maschinen starten, existierende anhalten, migrieren, zerstören und so weiter. Xend ermöglicht auch die Kontrolle über die Menge Arbeitsspeicher, die virtuelle Maschinen zugeordnet bekommen, sowie deren CPU-Priorität.

Einen Überblick über die grundlegenden »xm«-Befehle liefert »xm help«. Informationen über die laufende Xen-Version kann man mit »xm info« erhalten. »dm dmesg« listet die Bootmeldungen des Hypervisors. Der Befehl »xm list« kommt häufig zum Einsatz: Er zeigt eine Liste der laufenden virtuellen Maschinen sowie deren Speicherbelegung an. Ein Beispiel ist im Listing 1 zu sehen.

01 root@tpkurt:~ [0]# xm list
02 Name          ID Mem(MiB) VCPUs State  Time(s)
03 Domain-0      0      364     1 r-----   421.3
04 iSCSI0        1      128     2 ------   111.5

Virtuelle Maschinen

Die Xend-Konfiguration steuert die Konfigurationsdatei »/etc/xen/xend-config.sxp«. Die Netzwerkeinstellungen dort sind normalerweise auf Bridging voreingestellt. »dom0« nutzt dabei eine Linux-Bridge in. Diese Bridge »xenbr0« leitet dabei einfach Netzwerkpakete, die ein Interface einspeist, an alle anderen Netzwerkinterfaces weiter.

Die Einstellung wird dadurch komplizierter, dass Xen die Netzwerkinterfaces beim Starten umbenennt. Aus dem Interface »eth0« wird »peth0«. Die Hardware-(MAC-)Adresse und die IP-Adresse kopiert Xen auf das Interface »veth0« und benennt es in »eth0« um. »veth0« ist intern mit »vif0.0« verbunden, welches an der Bridge hängt, ebenso wie »peth0«. Pakete von Anwendungen in »dom0« gehen über das neue (virtuelle) »veth0« über »vif0.0« an die Bridge »xenbr0« und von dort über das physikalische Interface »peth0« aufs Netzwerkkabel.

Warum die komplizierten Einstellungen? Sobald weitere Domains starten, koppeln einfach weitere virtuelle Interfaces an die Bridge an und haben damit so-

wohl Zugang zum echten Netzwerk als auch zur »dom0«. Abbildung 2 veranschaulicht diese Einstellungen.

Abbildung 2: Die Geräte »(v)ethX« und »vif0.X« sind intern wie eine Pipe verbunden. Der Hypervisor Xen transferiert Pakete vom »eth0« der »domU«s an das Gerät »vifU.0«, welches auch mit der Bridge »xenbr0« verbunden ist. Dadurch kommen Pakete der »domU« sowohl aufs Netzwerkkabel (über »peth0«) als auch in andere Domains.

Bridging ist relativ kompliziert – Xen lässt sich auch so einstellen, dass das Umbenennen der Netzwerkinterfaces entfällt und keine Bridge entsteht, indem man etwa Routing benutzt. Dies ist auch ratsam, wenn ein WLAN-Interface im Spiel ist – Ethernet-Pakete kann man nicht einfach über eine Bridge als WLAN-Pakete versenden, weil die Formate unterschiedlich sind.

In Abbildung 2 ist bereits eine weitere Domain eingezeichnet, die jetzt auch praktisch starten soll. Da ein eigener Kernel gebootet wird, benötigt der auch ein eigenes Dateisystem. Um an ein solches zu gelangen, kommen mehrere Wege in Frage:

• Wiederbenutzung einer existierenden Installation. Der Admin
  sollte lediglich den paravirtualisierten Kernel nachinstallieren,
  sodass er auch passende Module zum Kernel laden kann – dann
  lässt sich eine vorhandene Linux-Partition unter Xen
  booten.
• Herunterladen eines existierenden Image. Solche Images lassen
  sich über das Xen-Wiki finden, andere bietet [4] an.
• Installation auf eine eigene Partition oder in ein Verzeichnis,
  in dem »kernel-xen« anschließend den Kernel
  austauscht und die Installation so in eine Xen.Installation
  verwandelt.
• Distributionsspezifische Installationsmethoden, beispielsweise
  das Yast-Modul, über welches sich Xen installieren
  lässt.

Die Dateisystemimages sollten immer nur eine virtuellen Maschine gleichzeitig benutzen, sonst droht Datenkorruption, genau wie dies bei echten Maschinen der Fall wäre.

Einstellungssachen

Die Konfiguration der virtuellen Maschine ist relativ einfach (siehe Listing 2). Bei Xen finden sich unter »/etc/xen« einige exemplarische Konfigurationsdateien, die durch Kommentare gut dokumentiert sind. Die Beispieldatei konfiguriert zunächst Kernel und Initrd (optional). Diese Dateien lädt der Bootprozess beim Starten der »domU« aus dem »dom0«-Dateisystem; dies kann ein Problem sein, auf das später noch eingegangen wird.

01  # Kernel and initrd to be loaded
02  kernel = "/boot/vmlinuz-2.6.13-15.8-xen"
03  ramdisk = "/boot/initrd-2.6.13-15.8-xen"
04  memory = 128
05  # Name, virtual CPUs, virtual network and hard disks
06  name = "iSCSI1"
07  #vcpus = 2
08  vif = [ 'mac=aa:cc:10:00:00:a1, bridge=xenbr0' ]
09  disk = [ 'phy:VG_new/LV_iSCSI1,hda1,w']
10  # Parameters to pass to VM
11  dhcp = "dhcp"
12  hostname = "iSCSI1"
13  root = "/dev/hda1 ro"
14  # extra = ""

Die virtuelle Maschine reserviert 128 MByte Arbeitsspeicher und richtet ein virtuelles Netzwerkinterface mit der angegeben MAC-Addresse ein, welches sich an die Bridge »xenbr0« hängt. Die logische Partition »/dev/VG_new/LV_iSCSI1« verwandelt sich in die Platte »hda1« der virtuellen Maschine. Als Bootparameter übergibt die Konfiguration »root=« an die virtuelle Maschine, die iSCSI1 getauft wird.

Statt eines Netzwerkgeräts ließen sich auch mehrere einrichten. Das Gleiche gilt für die Festplattenpartitionen. Es ist weiterhin möglich, statt einer Partition eine ganze Festplatte zu emulieren; die Partition dahinter muss dann eine Partitionstabelle enthalten. Mit der Angabe von »file:« ist es auch möglich, Dateisystemabbilder als Partitionen oder Festplattenabbilder als ganze Festplatten an die virtuelle Maschine zu exportieren.

Hotplug virtuell

Startet die virtuelle Maschine, aktiviert Hotplug die Geräte. »Dom0« erhält je ein Event für das Netzwerk und die Festplatte. Das Event gehört zum Subsystem Xen-Backend und hat den Kernelnamen »vif*« fürs Netzwerk beziehungsweise »vbd*« für die Festplatte. Udev sollte daraufhin die richtigen Skripte in »/etc/xen/scripts/« aufrufen. Sobald die Skripte erfolgreich waren und das Gerät in der Xenstore-Datenbank auftaucht, wird in der »domU« ein Hotplug-Event ausgelöst, der das Gerät dann dort sichtbar macht, genau wie mit echter Hardware beim Booten.

Hotplug ist einer der Stolpersteine eines erfolgreichen Xen-Einsatzes: Ältere Distributionen benutzen den alten Hotplug-Mechanismus statt Udev. In diesem Fall kommt statt »/etc/udev/rules.d/40-xen.rules« das File »/etc/hotplug/xen-backend.agent« zum Einsatz. Wenn Hotplug nicht richtig konfiguriert ist, wird eine entsprechende Fehlermeldung generiert. Wurde die Xen-Version mit der Distribution mitgeliefert, sollten solche Probleme aber ausgeschlosssen sein.

Mit »xm create -c Konfigdatei« startet die virtuelle Maschine. Die Option -c bewirkt, dass sich eine virtuelle Konsole mit der virtuellen Maschine verbindet, sodass man beim Booten die Messages verfolgen kann. Mit [Ctrl] +[]] kann man das Terminal wieder von der VM trennen, mit »xm console« erneut verbinden.Mit einiger Wahrscheinlichkeit schlägt das Booten aber mit der Meldung fehl, dass kein Speicher vorhanden sei. Die »dom0« hat beim Booten nämlich den gesamten Speicher reserviert.

Man kann nun entweder den Speicher von »dom0« verkleinern oder Xend so einstellen, dass er dies automatisch tut. Ersteres lässt sich durch »xm mem-set 0 XXX« bewerkstelligen, während Letzteres durch die Einstellung »dom0-min-mem« in »/etc/xen/xend-config.sxp« geschieht. Ist diese Hürde erst mal glücklich überwunden, sollte sich die »domU« booten lassen.

Es bietet sich an, nun mit dem Tool »xm« auf Entdeckungsreise zu gehen. Die virtuelle Maschine lässt sich anhalten, abspeichern, wieder starten, Speichergröße und CPU-Priorität lassen sich ändern und vieles mehr.

Optimierung der »domU«

Wer bis hierher gefolgt ist, kann nun eine Xen-»domU« im Textmodus booten. Dabei fallen ein paar fehlgeschlagene Systemskripte auf: Alles, was direkt auf die Hardware zugreifen möchte, schlägt fehl, beispielsweise das Laden von hardwarespezifischen Kernelmodulen oder auch der Zugriff auf die CMOS-Uhr.

In der Regel kann man die verantwortlichen Skripte einfach deaktivieren. Der Hardwarezugriff macht keinen Sinn und die Uhrzeit in den virtuellen Maschinen ist automatisch mit der physikalischen synchronisiert.

Xen grafisch

Für einen grafischen Desktop startet man am einfachsten Xvnc, statt eines normalen X-Servers »Xvnc«. Dies gelingt etwa durch folgenden Eintrag in »/etc/X11/xdm/Xservers«:

local /usr/X11R6/bin/Xvnc -brU -geometry 960x720 -depth 24 -rfbwait 120000U -rfbauth /root/.vnc/passwd -rfbport 5900U -httpd /usr/share/vnc/classes

Dieser Eintrag startet den virtuellen X-Server mit 24 Bit Farbtiefe und einer Auflösung von 960 mal 720 Pixeln. Der Server lauscht an Port 5900, wo ihn VNC-Viewer-Clients kontatkiert können. Dabei fragt er zum Schutz das zuvor durch »vncpasswd« gesetzte Password ab. Abbildung 3 zeigt einen Screenshot einer solchen Maschine mit VNC.

Abbildung 3: Screenshot einer virtuellen Maschine mit XVNC. Eingeloggt als Root läuft ein Yast-Online-Update, um die virtuelle Maschine mit den aktuellen Sicherheitsupdates zu versorgen.

Migration

Virtuelle Maschinen von einer physikalischen Maschine auf eine andere zu migrieren ist eine sehr nützliche Möglichkeit von Xen. Dadurch ist es etwa möglich, geplante Hardwarepflege zu betreiben, oder auch einfach einen überlasteten Server zu entlasten und einen bestimmten Service auf eine neue Maschine zu verlagern. Andere Nutzungsmöglichkeiten sind Test- und Entwicklungsumgebungen, Netzwerk- und Cluster-Simulation oder aus Sicherheitsgründen separierte Ausführungsumgebungen.

Die virtuelle Maschine muss vor und nach der Migration auf ihr Dateisystem zugreifen können. Wenn die Maschine nicht in einer RAM-Disk lebt, braucht sie dafür ein Netzwerkdateisystem oder einen Netzwerkspeicher. Als Netzwerkdateisystem kommt NFS in Frage. Im Serverbereich wird häufig ein Netzwerkspeicher über Fibre-Channel zur Verfügung stehen. Günstigere Alternative sind iSCSI oder auch ENBD.

Fazit

Xen 3 bringt vielfältige Möglichkeiten für die Virtualisierung, die bislang nur Mainframes vorbehalten waren, auf den PC. Noch erfordert die Installation bei den meisten Distributionen etwas Handarbeit. Sobald die Integration aber noch weiter fortschreitet, ist zu erwarten, dass sich die Virtualisierung aufgrund der überzeugenden Einsatzmöglichkeiten und zahlreichen Vorteile auf breiter Front durchsetzt. (jcb)