Xen-installation

Hinweis in eigener Sache

Ich bedanke mich vielmals bei der freundlichen Unterstützung meiner Firma, Linup-Front GmbH, welche es mir ermöglicht hat, diese Anleitung in dieser Ausführlichkeit zu schreiben, und die sie damit de facto bezahlt hat. :-)

Des weiteren bedanke ich mich vielmals für die zahlreichen Schreiber da draußen, für ihre Ideen, HowTos und Co, und davon insbesondere den Autoren des Buches Xen - Virtualisierung unter Linux, dessen Werk viele offene Fragen beantwortet hat. Ich empfehle jedem, der sich mit Xen beschäftigen will oder muss, sich es ins Regal zu stellen, da es noch tiefer in Xen eintaucht, als dass ich es hier zu schreiben vermag.

Sollten Fragen aufkommen oder Teile unverständlich sein, kann dies dem Wiki Prinzip entsprechend selbst korrigiert werden. Wer sich nicht persönlich daran traut, oder keinen Wiki Account erstellen möchte, kann mir einfach Bescheid geben, unter der Adresse denny<PUNKT>schierz<AT>linupfront<PUNKT>de oder über die Jabber Adresse devil@jhell.org.

Alte Anleitung

Wer nach wie vor die alte Xen Anleitung lesen möchte, der wird diese nun hier finden. Die neue Anleitung geht tiefer in die Materie und ist nicht nur auf copy-and-paste ausgelegt, sondern es muss auch ein wenig gelesen werden :-)

Aufteilung

Aufgrund der Länge habe ich die Anleitung nun aufgeteilt. Am Ende der jeweiligen Seite findet sich einen Link zur nachfolgenden Seite.

• Startseite
• Seite 2
• Seite 3
• Seite 4
• Seite 5

Überblick

Seit die Prozessoren enorm an Geschwindigkeit zugelegt haben, und mit ihnen die Größe des Arbeitsspeichers, befanden wir uns zunehmend in der Situation, dass die Computer einen Großteil ihres Daseins im Wartemodus verbringen, wartend auf Eingaben seitens ihres Herren.

Um dieser doch recht absurden Situation entgegen zu wirken, kamen Menschen auf die Idee, auf einem physischen Rechner mehrere Instanzen eines Betriebssystems parallel auszuführen. Diese Idee an sich ist nicht neu, wird sie doch jedem Informatikstudenten bekannt sein.

Dabei gibt es unterschiedliche Techniken, für die Realisierung. Viele der Großanbieter wie IBM bieten seit langer Zeit schon eine Virtualisierung auf Hardware Ebene an.

Das Problem, wenn man es denn als solches sehen möchte, sind unter anderem die Preise, die auch eine gute gefüllte Portokasse eines kleinen bis mittelständischen Unternehmens schrumpfen lassen. Doch in ihrer Leistung und Funktionsumfang, bieten sie nach wie vor mehr, als ihre Software Kollegen.

Vorab: Ein Ring sie knechtet

Um die zugrunde liegenden Techniken zu verstehen, ist ein kurzer Ausflug in die CPU Welt von Nöten.

Jeder Prozessor verfügt über mehrere Sicherheitsstufen (Domains genannt) um Prozesse davon abzuhalten, sich gegenseitig zu beeinflussen oder gar gezielt zu manipulieren. Diese Stufen werden als Ringe symbolisiert und halten die Prozesse in ihrem erlaubten Kontext.Die nebenstehende Grafik verdeutlicht dies.

Ring Darstellung der CPU

Von diesen Ringen gibt es vier an der Zahl. Der innerste Ring (genannt supervisor mode Ring 0) verfügt über alle Rechte der CPU. Nach Außen hin (Ring 1,2,3) werden diese Rechte weiter eingeschränkt. Wikipedia schreibt dazu:

80286-kompatible Prozessoren unterscheiden vier Privilegierungsstufen: Ring 0, 1, 2 und 3. Dabei stellt Ring 0, genannt supervisor mode, die höchste Privilegierungsstufe dar, die bis zur Stufe 3 immer weiter eingeschränkt wird. Um Prozesse in einem geschützten Bereich (Ring > 0) ablaufen zu lassen, wird der physikalische Arbeitsspeicher in virtuelle Speicherseiten aufgeteilt. Zu jeder Speicherseite existiert eine Tabelle, in der unter anderem gespeichert ist, in welchem Level (Ring) der Programmcode, der innerhalb dieser Speicherseite gespeichert ist, ausgeführt wird. Diese Auswertung nimmt die MMU meist extern vor. Mit der Einführung des AMD64-Opcodes, den auch Intel für seine 64-Bit-Prozessoren übernommen hat, existiert im Speicherseitendeskriptor ein Flag (NX -- No eXecution), das eine Unterscheidung zwischen Daten und Programmcode ermöglicht, um so Sicherheitslücken durch Pufferüberläufen vorzubeugen. Der Pufferüberlauf wird zwar nicht direkt verhindert, Programmcode in Datenseiten kann dabei aber nicht zur Ausführung gebracht werden.

Die Paravirtualisierung betreffend, läuft der Hypervisor im Ring 0 ab, während der Wirt und der Gast im Ring 1 laufen. Die normalen Anwender- Programme laufen wie gewohnt im Ring 3.

Die Techniken

Auf Ebene der Betriebssysteme sind unterschiedliche Verfahren im Einsatz, die je nach Technik unterschiedlich komplex ausfallen können und dementsprechend auf die Performance Einfluss nehmen.

Derzeit werden folgende Techniken unterschieden:

• Systemvirtualisierung mittels Virtual Machine Monitor (VMM)

Mit dieser Technik wird ein fast vollständiger PC emuliert. Dies bedeutet, er hat je nach Konfiguration: Laufwerke, SCSI Controller, Soundkarten, Grafikkarten und natürlich Arbeitsspeicher. Die CPU wird in Teilen ebenfalls emuliert, denn der Wirt behält die Exklusivrechte über die Einheit (Ring 0 -> Siehe Erklärung Ringe) und somit muss der Gast sich mit einer im Funktionsumfang beschränkten CPU zufrieden geben (Ring 3). Dabei gehen in der Regel die erweiterten Fähigkeiten wie SMP, ET64 etc. verloren. Daher beinhaltet dies auch gleichzeitig die Wahl der Architektur. Denn da keine CPU vollständig emuliert wird, ist die Virtualisierung auf eine Architektur beschränkt (z.B. x86). Diese Problematik kann mit den heutigen Generationen der CPUs von Intel und AMD umgangen werden. Siehe Hardware Virtualisierung

Die Abbildung 1 zeigt den Aufbau einer solchen Technik auf. Dabei sind die Schichten jeweils gut zu erkennen

(Abb. 1) Aufbau einer VMM basierten Technik

Die unterste Ebene (blau dargestellt) bildet die physische Hardware ab, auf der ein reguläres Betriebssystem arbeitet (hier in grün). Die graue Schicht symbolisiert den Virtual Machine Monitor, kontrolliert die Ressourcen und stellt die emulierte Hardware für die Gäste bereit (wieder in Blau). Die Betriebssysteme bemerken keinen Unterschied und glauben die vollständige Kontrolle über einen physischen Rechner zu besitzen.

Der Vorteil dieser Technik liegt in der Unabhängigkeit des Gastsystems. Es spielt nahezu keine Rolle, welches Betriebssystem (passend zur Architektur des Wirts) innerhalb eines Virtuellen Rechners installiert wird. Dank eigenem Bios und Chipsatz benötigt der Gast nur Treiber für diese Komponenten.

Um die Geschwindigkeit zu erhöhen, liefern die Hersteller des Virtualisierungsssoftware meist noch eigenen Treiber mit, die im Gastssystem installiert werden (sollten). Sie ermöglichen eine höhere Grafikkarten Auflösung und schnelleren Datentransfer über das Netzwerk sowie Festplatten.

Der Nachteil liegt in der ressourcenbindenden Emulation der virtuellen Hardware. Durch sie geht Leistung verloren, die weder dem Wirt, noch dem Gast zur Verfügung stehen und beeinträchtigen so die Gesamtperformance.

Bekannte Bespiele für diese Technik sind unter anderem Vmware-Workstation, Server (nicht ESX) und Player oder auch Microsofts VirtualPC.

• Hardware-Emulation

Der Name dieser Technik ist Programm. Mittels dieser Technik wird die vollständige Hardware emuliert, und zwar incl. eines Prozessors. Der Vorteil liegt deutlich auf der Hand: es lassen sich Betriebssysteme installieren, abseits der Architektur des Wirts. So zum Beispiel auf einer Intel CPU eine PPC.

Ein nicht unerhebliches Problem der Hardware Emulation tritt dann zu Tage, wenn eine aktuelle Architektur emuliert werden soll. Um bei dem PPC/i386 Beispiel zu bleiben, so vermag man zwar ein Windows2000> auf einem PPC Apple Computer (die mit dem angebissenen Apfel) zu installieren, doch nutzen sollten es nur Menschen, mit sehr viel Zeit ;-)

Anders sieht es bei älteren Architekturen aus: Ein C64, ein älterer Amiga oder auch ein Atari können durchaus ihre native Geschwindigkeit oder sogar um ein vielfaches darüber hinaus erreichen. Oftmals müssen künstliche Bremsen eingebaut werden, sodass Pacman bei dem Druck auf Start nicht bereits zu Ende ist.

Die bekanntesten Vertreter um Intel Prozessoren zu emulieren, sind Bochs und QEmu. Insbesondere QEmu nimmt innerhalb des Xen-Projektes eine besondere Stellung ein, da Teile aus dem QEmu Projekt genutzt werden, um einige Hardware Bauteile zu emulieren, wenn die Hardware-Virtualisierung (s. u.) verwendet wird.

• Paravirtualisierung

Bei der Paravirtualisierung wird eine Schicht zwischen das Wirts- System und dem Gast eingeschoben.

Einzelne Systemaufrufe des Gastes, die direkt auf die privilegierte Hardware (Speicher/CPU) zugreifen wollen, werden direkt an die Zwischenschicht geleitet, welche auch Hypervisor genannt wird.

Die Grafik (Abb. 2)

Abb.2 Paravirtualisierung mit Hypervisorschicht

rechts zeigt, wie sich diese Technik bildlich darstellt. In der untersten Ebene findet sich die physikalische Hardware, ohne die auch die beste Virtualisierungssoftware nicht arbeiten kann. Dann folgt die Hypervisorschicht, die die Hardware vom Wirt und vom Gast kontrolliert, der Wirt diese Schicht jedoch steuern kann.

Ein Nachteil der sich daraus ergibt, liegt in der Anpassung des Gastes und des Wirtes für die Hypervisor Schnittstelle. Denn der Hypervisor wird noch vor dem eigentlichen Betriebssystemkern geladen, um so möglichst hardwarenah agieren zu können.

Zwar stellt dies bei OpenSource Systemen wie Linux (Kernel Patch) und *BSD kein Problem dar, doch bei Systemen wie Windows eher schwierig.

Nicht unerwähnt sollte bleiben, das Microsoft und Xen-Source bereits vor einiger Zeit zusammen gearbeitet haben (und es auch noch tun), um Windows innerhalb von Xen als Gast einsetzen zu können.

Die nötigen Erweiterungen und Anpassungen sind jedoch ( aus unerfindlichen Gründen ;-) ..) nie veröffentlicht worden. Mittels der neuen CPU Technologie von Intel und AMD, spielt dies jedoch keine wirkliche Rolle mehr.

Die Performance bei einer solchen Lösung kommt dem Nahe, was auf einer regulären Hardware erreicht werden kann. Eine Ausnahme bildet das I/O, exklusiver Zugriff ist auch hier nicht zu toppen.

Zu den bekanntesten Paravirtualisierungs- Programmen gehören Xen, Vmware ESX, UserModelinux und in Teilen Virtuozzo. All diese laufen jedoch fast nur auf IA32/64 Systemen. Xen hat derzeit noch eine PPC Variante auf dem Band, doch wird nur die 970 PPC unterstützt.

User-Mode-Linux ist Bestandteil des Linux-Kernels und ermöglicht das Betreiben von virtuellen Linux Rechner innerhalb des Wirts. Dabei ist der Kernel des virtuellen Linux nur ein weiterer normaler Prozess im Wirt.

Der Kernel und die Prozesse des Gastes laufen dabei in einem separaten Adress- Speicher im Wirts-Kernel, sodass ein Gast keinen Zugriff auf die Prozesse seines Wirts hat.

Wie der Name schon andeutet, funktioniert diese Technik ausschließlich mit Linux.

Virtuozzo geht einen leicht anderen Weg bei der Paravirtualisierung. Statt jedem virtuellen System einen eigenen Kernel zur Verfügung zu stellen, nutzt Virtuozzo den vom Wirt (Multiplexing).

Dies bringt einen nicht zu verachtenden Vorteil bei der Ausführungsgeschwindigkeit, da einiges an Overhead eingespart wird.

Multiplexing kann sich auch als Nachteil erweisen, da kein eigener Kernel für den Gast zur Verfügung steht.

Wenn als Linux Systemkernel ein 2.6.20.2 verwendet wird, muss auch der Gast mit diesem Vorlieb nehmen. Dies gilt für Windows basierte Systeme. Auf einem Windows 2003 Server kann als Gast nur ein Windows 2003 verwendet werden.

• Hardware-Virtualisierung

Bei der Hardware Virtualisierung werden Teile der physischen Hardware an den Gast durchgereicht (z.B. CPU). Dies bedingt, wie bei der Systemvirtualisierung, auch die gleiche Architektur des Prozessors auf dem Gast.

(Abb.3)Intels Vanderpool Technik mit Xen

Was den Prozessor betrifft, so hat die x86 Welt einen Schritt näher an so genannte Mainframes gemacht und ermöglicht ebenfalls Virtualisierung innerhalb des CPU-Kerns.

Neue Prozessoren von Intel (Vanderpool - IVT) und AMD (Pacifica - AMD-V) ermöglichen jedem Gast den vollständigen Zugriff auf die CPU (Ring0) und können damit die volle Geschwindigkeit und Erweiterungen (MMX, ET64, 3DNow) ausnutzen. Doch der Wirt behält nach wie vor die Fäden in der Hand.

Damit ergeben sich interessante Möglichkeiten, denn während bei der Paravirtualisierung der Quellcode des Betriebssystems vorliegen muss, kann dies hier entfallen. Das nebenstehende Bild von Intel (Abb. 3) visualisiert den Aufbau einer solchen Technik. Sämtliche Anfragen bezüglich der CPU können 1:1 durchgereicht werden. Damit lässt sich auch ein Windows-Betriebssystem als Gast nutzen, selbst wenn der Wirt unter einem anderen System läuft.

Diese Erweiterungen werden noch nicht von allen Virtualisierungs- Programmen genutzt. Xen 3.0, qemu, Vmware-Workstation in der Version 6 und Microsoft Virtual-PC, unterstützen diese Funktionen. Die Ausführungsgeschwindigkeit der Gäste bei dieser Lösung, kommt an eine native Maschine sehr nah heran. Dies beinhaltet selbstverständlich nicht den Durchsatz von Datenströmen (I/O). Der wird wohl letzten Endes immer den Flaschenhals bilden.

Zu Xen 3.0 sei erwähnt, dass die Ausführungsgeschwindigkeit nur in der Theorie optimal ist. Leider muss sich Xen noch diverser Krücken bedienen, die in Form von emulierter Hardware zu Tage treten. Dadurch wird der eigentliche Performance Vorteil durch die Hardware-Virtualisierung wieder verpulvert. Auch ist die Stabilität noch nicht ausgereift, sofern den Hilferufen auf der Mailingliste Glauben geschenkt werden darf.

Der Autor dieser Anleitung mag sich gern eines besseren belehren lassen ;-)

Sinnvolle Virtualisierung

Szenarien

Die Frage, wo die Virtualisierung zum Einsatz kommen kann, sind vielfältig. Da wären zum Beispiel:

• Verschiedene Server auf eine einzelne Hardware konsolidieren
• Hardwareunabhängigkeit (Alte Software auf neue Hardware wie z.B. Windows NT4.0 Applikationen)
• Unterschiedliche Betriebssystem-Konfigurationen (z.B für Simulationen und Tests)
• Kernel Entwicklung (Sandkasten-Prinzip)
• Schädlingsanalyse (ebenfalls Sandkasten-Prinzip)
• Clustersysteme und Lastenverteilung
• Entwicklung von neuen Betriebssystemen
• Neue Möglichkeiten für Produkte (Web-/Mailprovider)

Abseits der verschiedenen Techniken, haben sie ein gemeinsames Ziel: Konsolidierung von physischen Rechnern und bessere Ausnutzung von vorhandenen Ressourcen. So verlockend dies auch sein mag, sollten immer die Vor- und Nachteile im Auge behalten werden:

• Vorteile:
  • Effizientere Ausnutzung von Hardware
  • Geringe Kosten für Strom bspw. Klimaanlagen etc.
  • Geringere Administrationskosten, da neue Instanzen mittels Vorlagen in Sekunden aufgezogen werden können.
  • Einfache Zuteilung von Hardware wie RAM, CPU und Festplattenspeicher
  • "Einfache" Migration von virtuellen Maschinen auf leistungsfähige Hardware
  • Aufbau von virtuellen Netzen innerhalb mehrerer Instanzen auf einer Hardware (DMZ etc.)
  • ...

Doch neben den Vorteilen, sind die Nachteile nicht von der Hand zu weisen:

• Nachteile
  • I/O lastige Programme laufen langsamer, da sie sich die Bandbreite der Busse (PCI/x) teilen müssen
  • Fällt ein physischer Server aus, fallen n virtuelle Instanzen aus (SPoF: Single Point of Failure)
  • Unter Umständen nicht für kritische Anwendungen von Unternehmen geeignet (bspw. Warenwirtschaftssysteme), da die Software Hersteller gerne einen Support ablehnen bis der Fehler auf einem realen System reproduziert wurde.
  • Hotplug Hardware bevorzugt, da bei einem Hardwareausfall alle Instanzen herunter gefahren werden müssen, sofern diese nicht lebend auf eine andere Hardware umgezogen werden können (od. Failover)
  • ...

Die Regel lautet: Was kostet es die Firma, wenn ein physischer Rechner mit virtuellen Hosts ausfällt und die Arbeit nicht schnell genug von anderen aufgefangen werden kann.

Xen Einleitung

Historie

Xen selbst war einst ein Teil aus dem Projekt XenoServers, entwickelt von der Research Group der Universität von Cambridge Computer Laboratory, mit der finanziellen Unterstützung von UK-EPSRC.

Ziel von XenoServers war es eine öffentliche Infrastruktur für verteiltes Rechnen zu bieten. Xen selbst war daraus ein Teil des Konzeptes, um auf einem physischen Rechner mehrere Betriebssysteme mit unterschiedlichen Applikationen laufen zu lassen, die untereinander abgeschottet sind.

Mit der Zeit ist Xen so gewachsen, dass daraus ein eigenes Projekt mit Firma XenSource entstand, welche mittlerweile von Citrix gekauft wurde. Daraus ergeben sich die Möglichkeiten zu erforschen, welches die besten Techniken für die Virtualisierung von z.B. der CPU, Arbeitsspeicher, Block orientierte Geräte wie Festplatten, und natürlich Netzwerke, sind.

Projekt Mitglieder, die Xen unterstützen sind unter anderem: XenSource, Intel, IBM, AMD, Novell und RedHat; mit stetig wachsender Mitgliederliste.

Hardware Unterstützung

Wer Xen einsetzen möchte, benötigt als erstes eine CPU Architektur, die x86 kompatibel ist. Dabei lässt sich nicht jede x beliebige CPU einsetzen, sondern sie muss mindestens einem P6 entsprechen. Das sind unter anderem ab Pentium Pro, Celeron, AMD Athlon und Konsorten.

Prozessoren mit der Hyperthreading Erweiterung und auch "echte" SMP Prozessoren werden selbstverständlich ebenfalls unterstützt. Portierungen für IA64 und PPC sind in der Entwicklung.

Da das Hauptaugenmerk auf IA32/IA64 liegt, ist der PPC Zweig aus dem Betastadium bisher noch nicht herausgekommen. Auch wird nur eine einzige CPU unterstützt, welche die 970 betrifft. Der aktuelle Fortschritt der PPC Variante kann hier eingesehen werden.

Abgesehen vom Prozessor läuft Xen an sich ansonsten unter jeder Hardware, da das Wirtsystem die eigentliche Arbeit erledigt und somit auch die Hardware unterstützen muss. Die eigentliche Arbeit von Xen besteht darin die virtuelle CPU zu starten, das Interrupt Routing einzurichten und die PCI Geräte aufzuzählen. Die Geräte im Gastsystem arbeiten wie gewohnt und bedürfen keiner Anpassung.

Der Linux Kernel, den Xen verwendet, bringt alle Treiber mit die von Nöten sein könnten. Sollte doch mal ein Treiber fehlen, so kann dies über den normalen Weg der Kernel-Konfiguration im Quellpaket von Xen nachgeholt werden.

Wer dies tun möchte (oder muss), findet im ausgepackten Quellcode Verzeichnis von Xen eine entsprechende INSTALL und README Datei mit detaillierten Anweisungen, wie ein Linux Kernel für Xen angepasst werden kann.

Die Anpassung unterscheidet sich im Großen und Ganzen nicht von einer normalen Linux Kernel Konfiguration.

Struktur von Xen

Ein Xen basiertes System hat mehrere Ebenen. Dabei ist die unterste, und damit privilegierteste, Xen selbst.

Jede virtuelle Instanz läuft in einer sicheren Umgebung. In der Xen-Terminologie wird sie Domain genannt. Diese werden von Xen so verwaltet, dass die CPU-Core Zeit möglichst effektiv auf alle virtuellen Maschinen verteilt wird.

Die erste Domain, Domain-0, wird automatisch mit dem Systemstart initialisiert, ausgeführt und verfügt über spezielle Verwaltungsprivilegien. Domain 0 erstellt andere (unprivilegierte) Domains und verwaltet deren virtuellen Geräte. Des weiteren führt sie auch administrative Arbeiten aus, wie z.B. das Einfrieren und Wiederbeleben oder auch Migrieren von virtuellen Maschinen.

Mit der Domain-0 läuft auch der Prozess xend der das System verwaltet. Xend bietet die Schnittstellen, um sich z.B. mit einer Konsole der virtuellen Maschine (VM) zu verbinden und ist auch für das Verwalten weiterer Domains zuständig. Einfache Befehle können mittels einer HTTP- Schnittstelle abgegeben, die von entsprechenden Kommandozeilen-Programmen ausgeführt werden.

Jede weitere Domain wird Domain U genannt und verfügt nur über eingeschränkte Rechte. Dabei kann ein angepasster und reduzierter Kernel zum Einsatz kommen, aber auch der selbe Kernel, den das Xen-Wirtssystem benutzt.

Nachfolgend noch einmal eine Auflistung der Xen Anwendungen:

• xm dient als Frontend zur Verwaltung. Über dieses Kommando werden neue Domains erzeugt und verwaltet
• xend verwaltet die Domains und führt Anweisungen aus, die vom Kommandowerkzeug xm kommen
• xenstore stellt eine Datenbank zur Verfügung, über die die Konfigurationsdaten verwaltet werden.
• xenbus bildet die Schnittstelle zwischen der Datenbank xenstore der Dom0 und allen Gästen. Mittels diesem Bus kann man gezielt Aktionen auslösen, wenn sich bestimmte Parameter ändern.

Was Xen 3.x bietet

• In der Version 3 bietet Xen folgende Möglichkeiten:
  • Bis zu 32 Prozessoren innerhalb eines Gast Systems, welche aus einer Core CPU generiert werden können (wichtig für eine SMP Server Konsolidierung)
  • Mittels PAE-Unterstützung auf 32-Bit Systemen kann mehr Ram alloziert werden, als dies normal möglich wäre. Diese Option sollte ab mehr als 1GB> Ram genutzt werden.
  • x86/64 Unterstützung (Intel EM64T, AMD Opteron)
  • Dank Intels Vanderpool und AMDs Pacifica können unmodifizierte Betriebssysteme eingesetzt werden
  • Verbesserte Management Tools
  • Verbesserte ACPI-Unterstützung
  • AGP/DRM/Framebuffer Grafik
  • Live Migration von Gästen
  • ...

Zwei Wege zum Ziel

Wie im ersten Abschnitt bereits erläutert, kann Xen auf zwei Varianten arbeiten:

• Paravirtualisierung: Wenn Linux als Gastsystem zum Einsatz kommt, muss dessen Kernel (und auch der des Wirts) einen Patch erhalten, um die notwendige Zwischenschicht einzubauen, damit die Systembefehle, die an die Hardware gerichtet sind, direkt an den Hypervisor weitergeleitet werden können.

Damit wird derzeit auch automatisch die Kernel Version vorgegeben. Das bedeutet: wer Xen einsetzen möchte, muss vorab prüfen, ob der von Xen unterstützte Linux Kernel auch die notwendigen Treiber (Module) beinhaltet, die für das System benötigt werden, wie z.B. Fiberchannel Karten für SAN etc.

Es ist zu hoffen, dass Xen bald in den offiziellen Kernel eingegliedert wird und sich diese Problematik entschärft.

Da das Gastsystem angepasst werden muss, scheiden Systeme aus, deren Quellcode für Normalsterbliche nicht einsehbar ist.

• Hardware Virtualisierung

Diese Technik bietet CPU seitig noch bessere Performance, denn die Zwischenschicht für den Hypervisor kann in großen Teilen entfallen. Die CPU Adressierung wird nun nicht mehr von Xen gesteuert, sondern das übernimmt die CPU selbst. Um dies zu können, müssen sowohl das Mainboard, Bios, und natürlich die CPU selber, die entsprechenden Voraussetzungen mit sich bringen.

Vor dem Kauf sind daher entsprechende Recherchen angesagt.

Zuvor sollte nicht unerwähnt bleiben, dass zwar die Zwischenschicht (Hypervisor) auf ein Minimum beschränkt werden kann, allerdings betrifft dies nur im Großen den Prozessoranteil. Um jedoch mit der restlichen Außenwelt kommunizieren zu können, muss unter Xen 3.0 wieder Hardware emuliert werden. Daher hat das Xen Projekt aus dem QEmu Projekt die entsprechenden Teile entnommen und in das Xen Projekt integriert.

Dies führt wiederum dazu, dass durch die notwendige Emulation wieder Leistungseinbußen hingenommen werden müssen. Daher lohnt sich dies derzeit nur bei Systemen, die nicht angepasst werden können, also deren Quelltext nicht frei einsehbar und modifizierbar ist.

Schematischer Aufbau

• Um den Aufbau besser zu verdeutlichen, sei der Blick auf das unten stehende Bild gerichtet.

Das Bild zeigt den schematischen Aufbau von Xen auf

• Der grün eingefärbte Bereich, spiegelt den Ablauf wieder, wenn Xen als Para- Virtualisierer arbeitet, während er im blauen Bereich als Hardware- Virtualisierer funktioniert. Die gelbe Zwischenschicht kann in diesem Fall fast entfallen.

---

Weiter zur Seite 2