1.5 Wie funktioniert eine virtuelle Maschine?

Eine virtuelle Maschine ist lediglich ein Prozess, der innerhalb eines Betriebssystems abläuft. Dies hört sich vielleicht simpel an, es trifft die Sache allerdings im Kern. Um Ihnen diese Thematik näher zu bringen, sei das folgende Beispiel angeführt:

Angenommen Sie haben einen physikalischen Server mit zwei Prozessoren und 4 GB Hauptspeicher. Dieser Server läuft unter Microsoft Windows 2000 Server. Nun legen Sie eine CD mit der Virtualisierungssoftware ein und starten die Installationsroutine. Diese Installationsroutine installiert die Virtualisierungssoftware, virtuelle Netzwerkkarten und Administrationswerkzeuge. Nach einem Neustart ist die Basis komplett installiert. Bis hierher ist von Virtualisierung höchstens bei den Netzwerkkarten etwas zu sehen. Doch jetzt wird es interessant!

Sie öffnen das Administrationswerkzeug, klicken auf »neue virtuelle Maschine« und erhalten ein Menü, über das Sie die komplette Hardware der virtuellen Maschine einrichten können. Hier wird es nun spannend, denn es kann die Größe des Arbeitsspeichers der virtuellen Maschine und deren Festplatte bestimmt werden. Diese Festplatte wird als Datei im normalen Dateisystem des physikalischen Servers abgelegt.

Jetzt veranlassen Sie die virtuelle Maschine zum Start. Was sie sehen, ist ein Computer im Computer. In einem normalen Windows-Fenster startet ein neuer Rechner, und zwar angefangen mit dem BIOS! Sie können nun eine Betriebssystem-CD über das Administrationstool der Virtualisierungssoftware in das CD-ROM-Laufwerk der virtuellen Maschine einlegen und ein Betriebssystem installieren. Dieses Betriebssystem läuft vollkommen unabhängig von Ihrem Wirt-System. Dies ist einer der wichtigsten Aspekte: Es existieren getrennte Systeme, und allein Sie entscheiden, ob eine virtuelle Maschine das Hostsystem oder andere virtuelle Maschinen über das virtuelle Netzwerk sehen darf oder nicht. Sie haben die komplette Verwaltung auf dem Wirt-System in der Hand. Niemand, der Zugang zu einer virtuellen Maschine hat, kommt aus derselben heraus, wenn Sie es nicht einrichten. Überaus wichtig ist auch die Tatsache, dass Änderungen an einer virtuellen Maschine niemals Änderungen am Wirt bewirken können.

Ein weiterer wichtiger Vorteil ist die immer gleiche Hardware der virtuellen Maschine. Diese Hardware kann nur durch die Version der Virtualisierungssoftware auf dem Wirt-System beeinflusst werden. Die Treiberunterstützung in der virtuellen Maschine ist dadurch immer gewährleistet. Man kann die virtuelle Maschine an sich wegen der Standardisierung der Hardware fast mit einer Spielekonsole vergleichen. Bei immer gleicher Hardware werden durch Treiberkonflikte verursachte Probleme natürlich minimiert.

Doch wie funktioniert dies technisch?

Da ich im Laufe des Buches detailliert auf die Techniken der drei großen Virtualisierungsprodukte am Markt eingehen werde, beschreibe ich hier nur grob beispielhaft die Funktionalität.

Mit Ausnahme des VMware ESX Servers (dieser bringt sein Wirt-Betriebssystem selbst mit) müssen Sie vor dem Einsatz der eigentlichen Virtualisierungsprodukte ein Betriebssystem auf dem Wirt installieren. Begründet liegt dies darin, dass die Treiberunterstützung und damit die Ansteuerung der physikalischen Hardware über das Wirt-Betriebssystem läuft und die Virtualisierung darauf aufsetzt. Diese Virtualisierungsschicht stellt die virtuellen Geräte wie Prozessor, Hauptspeicher, Grafikkarte oder SCSI-Kontroller für die virtuellen Maschinen bereit. Das darunter liegende Betriebssystem kennt diese virtuellen Geräte nicht!

Für jede virtuelle Maschine werden bei der Einrichtung eine Konfigurationsdatei und eine Festplattendatei im Dateisystem des Wirt-Systems abgelegt. Ausnahmen sind natürlich jene virtuellen Maschinen, denen ein direkter Festplattenzugriff auf physikalische Platten gewährt werden soll, oder aber solche, die gar keine Festplatten besitzen.

Zudem wird meist eine Datei für das BIOS (CMOS) der virtuellen Maschine hinterlegt, falls dort Änderungen vorgenommen wurden. Schwer vorstellbar, aber da ein kompletter Rechner virtualisiert wird, existiert für das virtuelle System ein BIOS, in dem auch Einstellungen vorgenommen werden können. Dazu gehören z. B. die Uhrzeit und die Bootreihenfolge, wobei die Uhrzeit sich allerdings als problematisch herausstellt. Da eine virtuelle Maschine über kein batteriegepuffertes CMOS verfügt, kann in ausgeschaltetem Zustand die Uhrzeit nicht automatisch aktualisiert werden. Daher ist es sinnlos, diese Einstellung im BIOS zu korrigieren, es sollten dafür Virtualisierungstools oder Netzwerkzeitprotokolle genutzt werden.

Um eine lückenlose Protokollierung über den Status der virtuellen Maschine zu bekommen, wird meist noch eine Protokolldatei für jede virtuelle Maschine auf dem Wirt-System hinterlegt.

Wenn Sie nun die virtuelle Maschine starten, wird ein so genannter »VMM« (Virtual Machine Monitor) mitgestartet, der die virtuelle Maschine komplett überwacht und Zugriffe an das physikalische System weiterreicht. Läuft die virtuelle Maschine erst einmal, gibt es verschiedene Zugriffsmöglichkeiten aus ihr heraus hin zum physikalischen System. Das sind z. B. Prozessor- oder Hauptspeicheranfragen. All diese Abfragen werden über die VMM sehr schnell abgearbeitet, so dass nur ein minimaler Virtualisierungoverhead für das virtuelle System entsteht. Dieser Virtualisierungsoverhead ist der Teil der physikalischen Systemleistung, der durch die Virtualisierung verloren geht.

Hier gibt es allerdings Unterschiede von Produkt zu Produkt, daher sei hier beispielhaft die Technik von VMware GSX oder Microsoft Virtual Server geschildert. Hier werden Prozessor- und Hauptspeicheranfragen durch den VMM direkt an die Physik weitergereicht. Festplatten- und Netzwerkzugriffe jedoch laufen erst noch durch die Virtualisierungssoftware und werden dann durch das Betriebsystem der physikalischen Maschine ausgeführt. Als großer Vorteil erweist sich dabei die breite Hardwareunterstützung, da die zur Verfügung stehenden Hardwaretreiber durch das Wirt-Betriebssystem und nicht durch die Virtualisierungssoftware begrenzt wird. In Abbildung 1.1 ist ein solcher Vorgang grafisch dargestellt.

Der Ablauf in Abbildung 1.1 geht wie folgt vor sich:

• VM1 greift auf die Festplatte zu, dadurch wird der Zugriff durch den »Virtual Machine Monitor« geschleust und durchläuft danach die VMware-Applikationsschicht innerhalb des Wirt-Betriebssystems. Dadurch kommt es zu einem geringen Virtualisierungsoverhead, was nur einen geringen Geschwindigkeitsverlust bedeutet.

• VM2 greift auf den Prozessor zu und kann dadurch vom Virtual Machine Monitor direkt an die physikalische Hardware durchgereicht werden.

• VM3 greift auf den Hauptspeicher zu und wird daher ebenfalls vom Virtual Machine Monitor direkt zur Physik weitergeleitet.

Abbildung 1.1 Funktionsübersicht VMware GSX

Das Produkt VMware ESX ist nicht auf diese zweite Schicht des Wirt-Betriebssystems angewiesen, sondern alle Anfragen an die Physik durchlaufen nur den so genannten »VMkernel«. Dies wird durch ein entsprechend angepasstes Konstrukt aus Wirt-Betriebssystem und Virtualisierungssoftware ermöglicht. Doch dazu später mehr. Der große Vorteil ist hier natürlich die deutlich höhere Geschwindigkeit, mit der die virtuellen Maschinen auf die physikalische Hardware zugreifen können, da kaum Komponenten beteiligt sind und damit weniger Ressourcen auf diesem Weg verschwendet werden. Darüber hinaus können die Ressourcen granular innerhalb der Virtualisierungsschicht kontrolliert und vor allem reguliert werden. Dadurch ist es problemlos möglich, eine virtuelle Maschine in Ihrer Leistung einzuschränken. Es wird eine deutlich geringere Hardwareunterstützung in Kauf genommen, um den virtuellen Kernel so klein und leistungsfähig wie möglich zu halten.

An Abbildung 1.2 sehen Sie, dass die virtuellen Maschinen direkt mit der Virtualisierungsschicht kommunizieren, die ihrerseits wiederum direkt auf die physikalische Hardware zugreift. Das Wirt-Betriebssystem wird in diesem Falle komplett übergangen.

Abbildung 1.2 Vorgang der Virtualisierung unter VMware ESX

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.