Virtualisierung von Betriebssystemen
VMware Architektur
Details zur Virtualisierung von Hardware
Da VMware keine detaillierten Informationen zur Funktionsweise der Virtualisierung gibt, werden im Folgenden die Virtualisierungsdetails des Open Source Projektes Plex86 erläutert. Dieses Projekt, früher unter dem Namen FreeMware bekannt, geht bei der Virtualisierung einen ganz ähnlichen Weg.
Aus der Funktionsweise von Plex86 ist die generelle Vorgehensweise zur Virtualisierung von Hardware erkennbar. Aus diesem Grund werden die Mechanismen anhand dieses Open Source Projektes erkläret. Es kann aber nicht garantiert werden, dass alle Mechanismen mit denen von VMware verwendeten identisch sind.
Virtualisierung der CPU
Die Prozessoren der Intelarchitektur sind, wie eingangs erwähnt, nicht für die Virtualisierung vorbereitet. Die aktuellen Prozessoren der Intelarchitektur unterscheiden 4 Privilegstufen, die als Ring 0, Ring 1, Ring 2 und Ring 3 bezeichnet werden. Die wichtigsten Ringe sind dabei Ring 0, der auch als Kernel Mode bezeichnet wird, und der Ring 3, dem User-Mode. In der Regel wird das Betriebssystem im Kernel Mode und die Anwendungssoftware im User Mode ausgeführt. Der Grund dafür sind die mit den Privilegstufen verbundenen Rechte zur Ausführung von Befehlen.
Die Befehle sind grundsätzlich in privilegierte und nicht privilegierte Befehle zu unterscheiden. Privilegierte Befehle dürfen nur im Kernel Mode - Privilegstufe 0 - ausgeführt werden, sonst wird von der CPU eine Ausnahme ausgelöst.
|
|
Abb.6 Privilegstufenverteilung ohne Virtualisierung |
Abb.7 Privilegstufenverteilung mit Virtualisierung |
Bei der Virtualisierung der CPU benötigt der "Virtual Machine Monitor" als Wirt die höchste Privilegstufe, um die Ausführung mehrerer Virtueller Maschinen zu organisieren. Der VMM wird daher im Ring 0 ausgeführt, während die Gast-Betriebssysteme im Ring 1 ausgeführt werden. Bei der Virtualisierung der CPU sind aber nicht nur die privilegierten Befehle problematisch, sondern es gibt einige nicht privilegierte Befehle, deren Verhalten von der Privilegstufe abhängig ist.
Für den "Virtual Machine Monitor" gibt es 2 Klassen von Befehlen:
- Unkritische Befehle
- nicht privilegierte Befehle
- Kritische Befehle
- privilegierte Befehle
- nicht privilegierte Befehle mit variablem Verhalten
Aufgrund der Ausführung der Gast-Betriebssysteme im Ring 1 müssen die kritischen Befehle abgefangen werden. Bei einer Weiterleitung an die CPU würden diese eine Ausnahme auslösen.
Ein Beispiel für einen kritischen Befehl ist das Laden des Page Directory Base Register (PDBR). Wenn dieser Befehl nicht vom Virtual Machine Monitor abgefangen wird, erlangt das Gast-Betriebssystem die Kontrolle über den Hauptspeicher und dieser ist dann nicht mehr für den VMM kontrollierbar.
Damit die kritischen Befehle abgefangen werden können, müssen die zuerst identifiziert werden. Dies geschieht mit Hilfe des Prescan, oder auch "Scan Before Execution", genannten Verfahrens. Es überprüft den auszuführenden Code nach kritischen Befehlen. Bei bedingten Sprüngen wird jeder mögliche Weg verfolgt. Falls das Ziel des Sprungs während des Prescans noch nicht feststeht, dann wird dessen Ausführung softwaremäßig emuliert.
Wenn ein kritischer Befehl gefunden wird, dann wird dieser durch einen Softwarebreakpoint ersetzt und somit die Ausführung des Prescans abgebrochen. Weitere wichtige Abbruchkriterien für das Prescan Verfahren sind das Erreichen von schon einmal gescanntem Code, das Verlassen einer Speicherseite oder das Erreichen der maximalen Suchtiefe.
Virtualisierung des Speichers
Im Gegensatz zur Virtualisierung der CPU ist die Virtualisierung des Hauptspeichers wesentlich einfacher, da dieser in der Intelarchitektur dafür vorgesehen ist. Durch die Mechanismen Segmentierung und Paging ist die Virtualisierung des Hauptspeichers effizient möglich. Bei der Virtualisierung des Hauptspeichers muss darauf geachtet werden, dass das Gast-Betriebssystem keinen Zugriff auf die Speicher Descriptor Tabellen bekommt. Diese Tabellen sind für die Virtualisierung des Hauptspeichers zuständig. Sie enthalten die Zuordnung der virtuellen Adressen auf die physikalischen Adressen. Wenn Gast- und Wirt-Betriebssystem gleichzeitig Zugriff auf diese Tabellen erhalten, ist kein sicherer Betrieb mehr möglich.
Damit kein gleichzeitiger Zugriff auf die Speicher Descriptor Tabellen auftritt, wird ein neuer Adressraum eingeführt, der in Form einer eigenen Schicht die physikalischen Adressen virtualisiert. Die Adressraum-Umwandlung erfolgt bei der Seitenübersetzung über eine Indirektschicht.
Virtualisierung der Ein- und Ausgabe
Die Virtualisierung der Ein- und Ausgabe erfolgt über spezielle Pseudotreiber, dem so genannten VMX-Treiber. Er wird bei der Host-Guest-Architektur in das Betriebssystem eingebunden und bei der Standalone-Architektur sind diese Treiber schon im Kernel implementiert.
Durch diese Treiber ist es dem VMM möglich virtuelle Geräte von vorhanden physischen Geräten einer Virtuellen Maschine zur Verfügung zu stellen. Ebenfalls ist es möglich und manchmal auch sinnvoll einer Virtuellen Maschine Direktzugriff auf bestimmte Geräte zu geben.
Die Virtuelle Maschine kommuniziert mit der virtuellen Hardware, die durch den VMM über den VMX-Treiber zur Verfügung gestellt wird. Wird der VMX Treiber durch Aktionen der Virtuellen Maschine dazu veranlasst, die physische Hardware anzusteuern, erhält die VMware Anwendung Anweisung über den Betriebsystem Treiber mit der Hardware zu kommunizieren.