Hardware-Zugriffe Grenzen der Virtualisierung
Während Virtualisierungsumgebungen die Befehle des Gastbetriebssystems an CPUs und Speicher mit geringen Geschwindigkeitseinbußen übersetzen können, ist dies bei anderen Hardware-Komponenten nicht so einfach. Der direkte Hardware-Zugriff ist verwehrt, denn auf Geräte wie Soundkarten, ISDN-Karten, Netzwerkkarten, Controller und Chipsätze hat bereits das Host-System exklusiven Zugriff. Eine gleichzeitige, konkurrierende Verwendung durch ein weiteres Betriebssystem könnten Standardkomponenten gar nicht verarbeiten. Virtualisierungsumgebungen begnügen sich deshalb damit, per Software Geräte wie Chipsatz, Controller, Netzwerkkarte und Grafikchip zu emulieren. Lediglich die KVM (Kernel Virtual Machine) von Linux kann momentan PCI-Geräte direkt an virtuelle Maschinen weitergeben, sofern diese nicht auch schon das Host-System verwendet.
Einigen Virtualisierungsumgebungen wie Vmware Workstation und Virtualbox gelingt es, über ihre Treiber eine Schnittstelle zum physikalischen Grafikchip zu schaffen, wobei die Grafikleistung nicht für aufwendige Spiele reicht. Nur Microsofts Hyper-V für Server kann mit der Technik "RemoteFX" den Grafikchip einer separaten Grafikkarte direkt für eine virtuelle Maschine verfügbar machen.
Virtualisierung mit und ohne Betriebssystem
Es gibt verschiedene Techniken, um Gastbetriebssysteme auf einem Rechner in virtuellen Umgebungen zu starten. Bei diesen Techniken unterscheidet man meist danach, auf welcher Ebene die Abstraktionsschicht angesiedelt ist, auf der die Virtualisierung vonstatten geht. Die unterschiedlichen Methoden liefern je nach angestrebtem Einsatzzweck, beispielsweise auf Desktops, Servern und für den Zugriff über das Netzwerk, die beste Leistung bei niedrigem Verwaltungsaufwand.
Typ-2-Hypervisor: Setzt eine Virtualisierungsumgebung als Startbasis ein ausgewachsenes Betriebssystem voraus, dann spricht man von einem Typ-2-Hypervisor. Generell handelt es sich bei einem Hypervisor, auch "Virtual Machine Monitor" genannt, um jene Verwaltungs-Software, die die Kontrolle über die virtuellen Maschinen hat, diese starten und anhalten kann und Ressourcen zuweist. Beispiele für den Typ 2 liefern etwa die verbreiteten Virtualisierungs-Tools für den Desktop Vmware Player/Workstation, Oracle Virtualbox wie auch Microsoft Virtual-PC.
Typ-1-Hypervisor: Läuft der Hypervisor direkt auf der Hardware und ersetzt dabei das Betriebssystem, handelt es sich um einen Typ-1-Hypervisor. Diese Virtualisierungsumgebungen werden beim Einsatz auf Servern und in Rechenzentren auf Computern bevorzugt, die sowieso nur virtuelle Maschinen beherbergen sollen - dann allerdings gleich dutzendweise. Beispiele dafür sind Vmware ESX/ESXi, Oracle VM Server und Citrix Xenserver.
Mischformen: Hyper-V von Microsofts Serverbetriebssystemen und die Technik KVM des Linux-Kernels sind Mischformen. Die Virtualisierungsfunktionen sind hier Teil des Betriebssystems selbst oder werden wie bei Linux direkt als Kernel-Modul geladen. Das Betriebssystem kann sich so selbst virtualisieren und mehrere unabhängige Instanzen starten.
Prozessoren: Ringe regeln Privilegien
Ganz gleich, welche Methode der Virtualisierung zum Einsatz kommt, eins ist allen gemeinsam: Einige Befehle, die das Gastsystem an die CPU sendet, müssen über die Virtualisierungsschicht abgefangen werden. Der Grund liegt im Design der x86-CPUs von Intel und AMD. Lediglich das zuerst gestartete Betriebssystem darf privilegierte CPU-Instruktionen verwenden, die später gestarteten Anwendungen dagegen nicht. Schließlich soll das Betriebssystem die Kontrolle darüber behalten, was Anwendungen anstellen. Der privilegierte Zugriff findet im "Ring 0" der CPU statt, auch "Kernel-Mode" genannt. Dieser Ring umfasst den direkten Zugriff auf Interrupts und Speicher.
Die Ringe darüber, Ring 1, 2 und 3, gehören alle zum "User-Mode". Betriebssystemtreiber dürfen zum Beispiel in Ring 1 und 2 arbeiten. Normale Programme im Betriebssystem arbeiten nur ab Ring 3. Ein Problem dieser historisch bedingten Prozessoreinteilung ist, dass die Virtualisierungs-Software zwar als Programm im Ring 3 läuft, dort aber Gastbetriebssysteme ausführen muss. Dies ist allerdings nicht ohne Weiteres möglich, weil Betriebssysteme stets Code enthalten, der nur im Ring 0 funktioniert. Die prozessornahen Assembler-Befehle "CLI" (Clear Interrupts) und "STI" (Set Interrupts) zur Interrupt-Steuerung laufen beispielsweise in den höheren Ringen des User-Modes nicht und der Prozessor verweigert deren Ausführung. Da ein Betriebssystem wie Windows oder der Linux-Kernel in der Annahme programmiert ist, dass es auf Ring 0 läuft, funktioniert es außerhalb des Kernel-Modes überhaupt nicht.
Der Hypervisor übersetzt Systemanfragen
Damit die virtuellen Systeme trotzdem laufen, bedienen sich Virtualisierungsumgebungen eines Tricks: Jeder Befehl einer virtuellen Maschine wird vom Hypervisor analysiert und die Befehle werden bei Bedarf umgebaut, damit sie im Ring 3 ausgeführt werden. Frühe Virtualisierungsprogramme erledigten dies noch ausschließlich über Software und waren gut damit beschäftigt, das Gastsystem stabil zu halten, was auch nicht immer gelang. VMs in den Zeiten der Vmware Workstation 3.x waren langsam und ressourcenhungrig.
Mit aktuellen Hypervisoren stellen Geschwindigkeit und Stabilität kein Problem mehr dar - allerdings müssen die Software-Hersteller von Virtualisierungslösungen für neue Windows-Versionen immer wieder Updates bereitstellen, damit diese als Gast laufen. Auf einer alten Version von Virtualbox läuft zum Beispiel Windows 8/8.1 nicht zufriedenstellend. Das liegt daran, dass Betriebssysteme verschiedene Anpassungen verlangen, damit Befehle für den Ring 0 auch im Ring 3 laufen. Bei Virtualbox und Vmware müssen Sie daher immer den Typ des Gastsystems angeben, wenn Sie einen neuen virtuellen PC erstellen. Sie müssen etwa vorgeben, um welche Windows-Version es sich handelt und ob das System für die 32-Bit- oder 64-Bit-Plattform vorliegt. Nach diesen Angaben entscheidet der Hypervisor, welche Prozessorbefehle übersetzt werden müssen.
