Die grundsätzliche Funktionsweise der Virtualisierung

Offenheit

Wie Sie gesehen haben, ist eine virtuelle Maschine ein Programm im Status eines Anwendungsprogramms. Dieses Programm kann man natürlich schreiben, wie man möchte, also kann es nicht nur ein bestimmtes Betriebssystem nachbilden, sondern unterschiedliche. Da das alles Anwendungsprogramme sind, können sie natürlich wie gewöhnliche Anwendungsprogramme koexistieren, siehe Abbildung 4.

Natürlich ist das zu schön, um wirklich wahr zu sein. Die Hersteller von Betriebssystemen waren in den vergangenen Jahrzehnten enorm fleißig darin, unmittelbare Durchgriffe des Betriebssystems auf reale Befehle der physikalischen Prozessoren zu erlauben. Die Offenheit im Rahmen der Virtualisierung ist auch heute davon abhängig, inwieweit die durch die VM-Programme nachgebildeten Betriebssysteme in ihrem Leben als „echte“ Betriebssysteme die HAL durchlöchert haben. Im Rahmen der VM-Programmierung kann man manche dieser Löcher zurückbilden, aber nicht immer alle. Es ergibt sich dann das Problem, wie man mit diesen unmittelbaren Durchgriffen umgeht, aber dazu später mehr.

Kommen wir zunächst zu anderen Aspekten. Das VM-Programm ist ja eigentlich nichts weiter als ein Anwendungsprogramm, also kann es auch rein theoretisch mit anderen Anwendungsprogrammen koexistieren. Wird das so realisiert, spricht man von einer gehosteten Lösung, siehe Abbildung 5.

Bei Versuchen hat sich gezeigt, dass das keine gute Lösung ist. Virtuelle Maschinen und normale Anwendungsprogramme behindern sich gegenseitig, weil sich das Profil, mit dem eine virtuelle Maschine einen physischen Rechner beschäftigt, doch sehr von dem einer normalen Anwendung unterscheidet. Der Durchbruch der Virtualisierung mit modernen Konzepten basiert auf der Einführung eines so genannten Hypervisors.

Der Hypervisor

Da wir eben so schön tief in die Funktionen eines Betriebssystems eingestiegen sind, lässt sich der Hypervisor, der vielen als unverständliche Komponente erscheint, von der man eigentlich nur weiß, dass sie orange ist, leicht erklären:

Der Hypervisor ist ein spezialisierter Scheduler. Das von ihm erzeugte System der Elementarprozesse ist auf die Unterstützung der Laufzeitumgebungen der virtuellen Maschinen optimiert. Er unterstützt ausschließlich virtuelle Maschinen.

Wir haben gesehen, dass ein normaler Scheduler anwendungsunterstützende und systemunterstützende Elementarprozesse erzeugt. Das macht der Hypervisor auch, aber er erzeugt diese zwei Arten Elementarprozesse in Gruppen, und zwar eine Gruppe für jede virtuelle Maschine. Das wäre weiter nicht aufregend, aber die dadurch entstehende zweistufige Verwaltungsstruktur für Elementarprozesse ist wesentlich flexibler als die bei einem gewöhnlichen Scheduler übliche flache Organisation.

Stehen dem Hypervisor mehrere Prozessoren oder Cores zur Verfügung, kann er dieses System dazu nutzen, die Gruppen sehr elegant auf die parallel arbeitenden Cores abzubilden. Hierfür kann er verschiedene Strategien anwenden und sogar mischen. Die Elementarprozesse zweier virtueller Maschinen haben nichts miteinander zu tun und erfüllen so die notwendige Voraussetzung für die Parallelisierung.

Auch für einen Hypervisor benötigen wir eine Steuerung. Also gibt es auf einem entsprechenden System noch eine Service-Konsole, an die weitere Funktionen, wie z.B. Clustering-Services angegliedert werden können. Das sehen wir in Bild 6.

Frühe Hypervisor-Varianten haben sich für die Realisierung ihrer Funktionen noch der vorhandenen Scheduler bedient, wie das in der Abb. 6 noch zu sehen ist. Das führt aber nicht zu der gewünschten Leistung, weil z.B. die Bildung der Prozessgruppen für die virtuellen Maschinen und andere Funktionen dazu führen, dass bei Beibehaltung des alten Schedulers nicht nur durch den Hypervisor wieder eine neue Schicht eingeführt wird, sondern auch keine wirkliche Eleganz bei der zweistufigen Prozessverwaltung erreicht werden konnte.

Konsequenterweise ersetzt der Hypervisor in modernen Systemen die alte Struktur aus Scheduler und Elementarprozessen vollständig. Damit wird er zum neuen zentralen Element in einer Systemumgebung, die die Virtualisierung unterstützt.

Normale Anwendungen können jetzt ausschließlich auf virtuellen Maschinen laufen und nicht mehr auf dem alten Scheduler-System. Lediglich für die Unterstützung der Steuerungsfunktionen muss ein kleiner Rest vom alten System bewahrt bleiben.

Der Hypervisor profitiert natürlich davon, dass er eine in hohem Grade standardisierte Umgebung unterstützen kann, die ausschließlich durch die für die virtuellen Maschinen notwendigen Laufzeitumgebungen gebildet wird. Die Gesamtkonstruktion sehen wir in Bild 7 am Beispiel VMware.

Weitere bekannte Hersteller von Virtualisierungssoftware sind Citrix und Microsoft.

Es gibt eine Reihe grundsätzlicher Konstruktionsalternativen für Virtualisierungssoftware. Sie haben einen unmittelbaren Einfluss auf die Leistung. Betreiber haben normalerweise vor allem ein Interesse an einer schnellen Transaktionsverarbeitung. Wir werden in der nächsten Folge zeigen, dass virtualisierte Systeme hier unabhängig von ihrer Grundkonstruktion einen massiven Vorteil gegenüber konventionellen Betriebssystemen haben.