Ringmodell des x86-Prozessors

Um eine solche Lösung zu verstehen ist die Kenntnis einiger Grundlagen der Architektur des x86-Prozessors nötig. An dieser Stelle wird die Bezeichnung x86 auch für x86_64-Prozessoren verwendet, da diese Abwärtskompatibel sind und die meisten dieser Annahmen daher für beide Architekturen gelten. Um nun das Konzept der Virtualisierung auf der x86-Architektur zu verstehen, ist es nötig die Zeit etwas zurückzudrehen.

Der 1982 veröffentlichte 80286er Prozessor führte ein vollkommen neues Konzept bei Intel-kompatiblen Prozessoren ein. Der Prozessor konnte nun in den sogenannten Protected Mode geschaltet werden. Neben einigen weiteren Neuerungen brachte dies die Möglichkeit mit sich, Programme in verschiedenen Ringen auszuführen. Diese Technologie ist auch unter dem Begriff Priority Levels (Prioritätsebenen) bekannt. Es sind insgesamt vier solcher Ringe vorhanden. Während Ring Null alle Befehle auf dem Prozessor ausführen kann, sind darüberliegende Ringe umso eingeschränkter in der Ausführung von Befehlen, desto höher Ihre Ziffer ist. Hierbei ist Ring Drei der restriktivste Ring.

Es ist den Ringen möglich mittels sogenannter Gates (Tore) miteinander zu kommunizieren. Somit ist es einem höhergelegenem Ring möglich die Ergebnisse privilegierter Operationen von einem darunterliegenden Ring anzufordern. Sollten die Privilegien des darunterliegenden Ringes unzureichend sein, so kann dieser die Anfrage wiederum an einen darunterliegenden Ring eskalieren. Dem jeweils privilegierterem Ring obliegt hierbei die Aufgabe die Anfragen zu validieren und autorisieren. Ist das mit positivem Ergebnis geschehen, so führt dieser die Befehle aus, oder eskaliert diese, und liefert anschließend das Ergebnis der Operation zurück.

Während es theoretisch also möglich ist vier Ringe auf x86-kompatibler Hardware zu nutzen benutzen die meisten Betriebssysteme lediglich zwei davon. Auch bei anderen Architekturen wird hierbei zwischen dem kernel mode und dem user mode unterschieden. Diese nutzen auf x86-kompatibler Hardware in der Regel Ring Null (kernel mode) und Ring Drei (user mode). Die Tatsache, dass die restlichen Ringe ungenutzt bleiben liegt darin begründet, das Betriebssystem portabel zu halten. Viele andere Architekturen, wie zum Beispiel RISC, verfügen lediglich über zwei dieser Prioritätsebenen. Es wäre zu aufwändig ein Betriebssystem, welches mehr als zwei Prioritätsebenen besitzt auf eine Architektur zu portieren, welche lediglich zwei unterstützt.

Paravirtualisierung

Wie bereits im Abschnitt namens Ringmodell des x86-Prozessors besprochen, sind alle Voraussetzungen für die Virtualisierung auf x86-kompatibler Hardware gegeben. Theoretisch sollte es möglich sein den Xen-Hypervisor in Ring Null, und mehrere Domains gleichzeitig in Ring Eins zu starten. Die user space-Programme der Domains würden dann unverändert in Ring Drei ablaufen. Da das Betriebssystem normalerweise den Ring Null für sich beansprucht muss es dahingehend modifiziert werden, nun ausschließlich Ring Eins für den kernel mode zu nutzen. Desweiteren muss es lernen privilegiertere Operationen in Ring Null anzufordern, da dort nun der Xen-Hypervisor residiert.

Ohne Zugriff auf den Quellcode ist dies jedoch kaum zu bewerkstelligen. Daher benutzen die Xen-Entwickler einen angepassten Linux Kernel. Dieser ist Quelloffen und hervorragend dokumentiert. Der Kernel wurde modifiziert, um in Ring Null als Hypervisor die Schnittstellen zur Verfügung zu stellen. Darüberhinaus kann dieser Kernel in einer domU gebootet werden. Es handelt sich dabei um einen eigenständigen Linux Kernel, der jedoch in Ring Eins der Prioritätsebenen residiert. Dort kommuniziert er über idealisierte Treiber mit dem Xen-Hypervisor und kann in seinem user space in Ring Drei unmodifizierte Programme ausführen.

Die entsprechenden Änderungen an Betriebssystemen vorzunehmen ist nicht sehr aufwändig. Tatsächlich gibt es bereits Anpassungen für verschiedene BSD-Derivate und OpenSolaris, damit diese in einer domU mittels Paravirtualisierung lauffähig sind. Desweiteren gibt es bereits eine angepasste Version von Plan9, die ebenfalls innerhalb einer domU betrieben werden kann. Closed Source Betriebssysteme, wie das bekannte Microsoft Windows können leider nicht durch die Open Source Community angepasst werden. Doch es gibt Gerüchte, dass Windows XP bereits portiert wurde. Doch die notwendigen Änderungen dürfen aufgrund eines NDA nicht öffentlich zugänglich gemacht werden.

Effizientere Hardwarenutzung

Viele Softwarehersteller binden den Support für Ihre Softwarelösung an ein bestimmtes Betriebssystem oder eine bestimmte Distribution. Normalerweise ist man daher gehalten einen weiteren Rechner zur Verfügung zu stellen, sofern man diese Voraussetzungen nicht erfüllt, oder man verzichtet auf den zugehörigen Support.

Mittels Virtualisierung ist es möglich auf einem Rechner alle gewünschten Applikationen zu installieren und die jeweiligen Vorraussetzungen, um den Support zu erhalten, zu erfüllen. Hierzu muss nicht in weitere Hardware investiert werden.

Migration / Konsolidierung

Oftmals kommt es vor, dass in Firmen noch Systeme verwendet werden, die nur noch von einer handvoll Benutzern verwendet wird. Dies geschieht häufig durch eine sanfte Migration auf ein neues System. Hierbei ist abzusehen, dass die Benutzerzahl kontinuierlich sinken wird. Solche Systeme laufen typischerweise auf älterer Hardware, deren Workload heutzutage von einem aktuellen Server mehrfach bearbeitet werden kann. Somit ist es möglich mehrere solcher Applikationen virtualisiert auf einem Server zusammenzufassen.

Im Rahmen einer solchen sanften Migration ist es durchaus auch denkbar, dass die Hardware, auf der die Applikation installiert wird, zu der migriert werden soll, bereits Virtualisiert wird. In diesem Falle kann sowohl die alte, als auch die neue Apllikation samt Betriebssystem auf dieser Hardware installiert werden. Hierbei geht man typischerweise davon aus, dass durch das Sinken der Benutzeranzahl der alten Applikation ein Anstieg der Benutzeranzahl auf dem neuen System hervorgerufen wird.

Testumgebungen

Bei kritischen Softwareupdates, oder Systemveränderungen ist es wünschenswert solche Veränderungen zu testen, bevor diese auf produktive Systeme gelangen. Ab einer gewissen Größe der IT-Landschaft, und je nachdem, wie weitreichend die Veränderungen sind, ist es insbesondere finanziell sehr aufwändig, eine Testumgebung mit Hardware nachzubilden. Sofern eine Abstraktion möglich ist, bietet es sich an, solche Testumgebungen als virtuelle Maschinen nachzubilden, und die Tests auf einem Bruchteil der ansonsten nötigen Hardware nachzubilden.

System I/O

Xen domains, die insbesondere die Festplatten fordern, können ein Xen System beeinträchtigen. Dieses Problem kann man durch Einsatz mehrerer Festplattencontroller und schnellerer Festplatten etwas hinauszögern, jedoch muss die dom0 die Umsetzung von Virtuellen Blockgeräten auf die existierende Hardware vornehmen. Wird der I/O-Scheduler zu stark belastet, so werden alle domains Zeit mit dem Warten auf Daten verbringen.

Es ist wichtig, im Hinterkopf zu behalten, dass selbst bei einem normalen Serversystem die Festplatten bereits in einigen Fällen einen limitierenden Faktor darstellen. Server, bei denen die Festplattenperformance bereits an Ihre Grenzen stößt, sind nicht zur Virtualisierung geeignet.

Grafiktreiber

Die einzige simple Möglichkeit eine grafische Oberfläche in einer domU zu nutzen ist die Verwendung eines Framebuffers, der zum Beispiel per VNC exportiert wird. Applikationen, die auf Grafikbeschleunigung angewiesen sind, und hiervon regen Gebrauch machen sind eher ungeeignet für eine domU.

Ein etwas komplizierterer Weg ist das explizite Zuweisen einer Grafikkarte an die domU.

Direkter Hardwarezugriff durch DomU's

Es ist möglich jede PCI Karte (einschließlich AGP und PCI-X) in eine DomU zu exportieren. Damit wird das Gerät ausschließlich von dieser verwendet und kann von dort über einen nativen Treiber genutzt werden.

Diese Lösung lässt sich natürlich nicht beliebig skalieren. Hier ist es abhängig vom Mainboard, wieviele Erweiterungskarten der Rechner aufnehmen kann.

Power Management

Am geeignetsten ist Xen für Server. Die fehlenden Power Management Funktionen sprechen gegen einen Einsatz auf Laptops. Es ist fraglich, ob Xen jemals Power Management unterstützen wird, da dies alles andere als trivial ist. Im "nicht Xen Universum" entscheided das Betriebssystem, ob es möglich ist, zum Beispiel eine Festplatte bei Nichtbegrauch zu stoppen. Dies ist in einer Virtualisieren Umgebung nur noch bedingt möglich, da das virtualisierte Blockgerät oftmals nur (Bestand-)Teil einer größeren Platte, oder gar eines Plattenverbundes ist. Daher müsste der Hypervisor entscheiden, ob es möglich ist eine Festplatte herunterzufahren. Dieser jedoch, kennt nicht den aktuellen Zustand seiner Gastbetriebssysteme.

Weitere Limitierungen

Es gibt weitere Limitierungen, die nicht nur auf Xen, sondern auch auf viele andere Betriebssysteme zutreffen. Jedoch glauben einige, dass diese mit Xen umgangen werden könnten, da Xen Hardware virtualisiert: