Zu den größten Hürden der PC-Virtualisierung gehörte über Jahre das Privilegienmodell der Intel-Architektur. Typischerweise dürfen nur zentrale Komponenten des Betriebssystems direkt auf die Hardware zugreifen, sie laufen auf der Stufe 0 ("Ring 0"). Am wenigsten Rechte besitzen dagegen die Anwendungen, für die der so genannte User Mode ("Ring 3") vorgesehen ist (siehe Grafik). Wenn sich mit dem Hypervisor eine Virtualisierungssoftware zwischen Hardware und Gast-Betriebssysteme schiebt, dann muss diese die Kontrolle über die CPU übernehmen und sie als gemeinsame Ressource für mehrere virtuelle Maschinen (VMs) verwalten.
Unkooperative Betriebssysteme
Allerdings erkennen herkömmliche x86-Betriebssysteme nicht, dass sie nur auf virtueller Hardware laufen, und versuchen weiterhin, mit Hilfe von Ring-0-Instruktionen privilegierte Operationen auszuführen, die nun dem Virtual Machine Manager (VMM, auch Hypervisor) vorbehalten sind. Eine virtualisierte Umgebung muss deshalb dieses Verhalten der Gäste in den Griff bekommen.
Die beiden führenden x86-Chiphersteller Intel und AMD erweiterten ihre neueren Prozessoren um Techniken (AMD-V und Intel VT), die Virtualisierung auf Hardwareebene unterstützen und damit den Hypervisor entlasten. Dazu gehört eine Neuordnung des Privilegiensystems, das mit dem "VMX Root mode" eine weitere Ebene mit maximaler Rechteausstattung einzieht, die dem Hypervisor vorbehalten bleibt. Unmodifizierte Gastsysteme können damit wie gewohnt im Ring 0 operieren und müssen nicht mehr von Virtualisierungssoftware reglementiert werden.
Die Virtualisierungsunterstützung auf Chipebene beschränkt sich nicht auf die Behebung dieses Legacy-Problems, sondern nimmt dem Hypervisor noch weitere Aufgaben ab. Dazu zählt auch die Speicherverwaltung, bei der die Memory Management Unit (MMU) eine zentrale Rolle spielt. Dieser Baustein, der Bestandteil moderner Prozessoren ist, dient der Übersetzung von virtuellen in physische Adressen.
Hilfe bei der Speicherverwaltung
"Virtuell" bezieht sich hier nicht auf die Partitionierung ganzer Maschinen, sondern darauf, dass Software unabhängig vom tatsächlich vorhandenen Arbeitsspeicher ein linearer virtueller Adressraum zur Verfügung gestellt wird. In Wirklichkeit unterteilt sich dieser in zahlreiche Speicherseiten, die unter Umständen sogar in einer Auslagerungsdatei auf der Festplatte abgelegt sein können. Mit Hilfe der MMU kann ein Betriebssystem die Daten von ihrem realen Speicherort holen, auch wenn es selbst nur die virtuelle Adresse dafür kennt.
In virtualisierten Systemen kann es der Hypervisor nicht zulassen, dass Gastsysteme direkt mit der MMU kommunizieren, weil sie sich sonst gegenseitig die Speicherverwaltung torpedieren würden. Daher simuliert er für jede VM eine eigene Nachschlagetabelle für Speicheradressen, und konsultiert bei Anfragen selbst die MMU, um den physischen Speicherort zu ermitteln.
Entlastung des Hypervisors
AMD-V implementierte mit "Nested Paging" eine solche Technik auf Hardwareebene, so dass der VMM auf neueren Maschinen von dieser Aufgabe entlastet wird. Intel zog in der kürzlich vorgestellten Xeon-5500-Familie ("Nehalem") mit "Extended Page Tables" nach, so dass Gastsysteme wie gewohnt ihre eigenen Speichertabellen lesen und schreiben können. Beide Hersteller unterstützen die Virtualisierung zusätzlich mit Features, die es insgesamt leichter machen, den Zustand einer virtuellen Maschine zu speichern und zu verwalten, so dass etwa der Kontextwechsel mit möglichst geringen Verlusten vonstatten geht.
Trotz der Fortschritte in der Prozessortechnik bleibt noch Raum für Verbesserungen. So vereinfacht die Hardwareunterstützung für Virtualisierung zwar die Hypervisor-Entwicklung. Damit können Xen und Hyper-V, die keine aufwändige Binärübersetzung wie VMware bieten (siehe Kasten), mit Hilfe der neuen Erweiterungen unmodifizierte Gast-Betriebssysteme ausführen.
Allerdings ist die erste Generation der Virtualisierungserweiterungen nicht allzu leistungsfähig, so dass beispielsweise Microsoft unter Hyper-V ein paravirtualisiertes Windows nutzt, um Teile der Speicherverwaltung effizienter über den Hypervisor abwickeln zu können.
VMware, das die ursprünglich entwickelte Binärübersetzung weiterhin anbietet, aber auf neueren CPUs auch die Virtualisierungserweiterungen der Prozessoren nutzen kann, stellte in einem Benchmarktest fest, dass die reine Softwarelösung bei vielen Aufgaben schneller war als die von der Hardware unterstützte Variante.
Ein- und Ausgabe als nächster Schritt
Mit der Virtualisierung von Ein- und Ausgabeoperationen (I/O) steht der Umbau der x86-Plattform vor einer weiteren großen Aufgabe. Bis dato regelt der Hypervisor den Zugriff auf Geräte wie Netzwerkadapter (NIC) oder Massenspeicher. Wenn mehrere Gastsysteme über das Netz kommunizieren, dann kann nicht jedes von ihnen beliebig Daten in die Adressbereiche schreiben, die für die Interaktion mit dem NIC genutzt werden (Ports oder DMA). Sie würden sich in kürzester Zeit in die Quere kommen und falsche Informationen übermitteln.
Die gängigsten Hypervisor verfolgen derzeit zwei verschiedene Ansätze, um die Kommunikation über Ein- und Ausgabegeräte zu regeln. VMware ESX sieht vor, dass Anbieter von PC-Komponenten eigene Treiber für den Hypervisor entwickeln, durch die der Zugriff aus allen Gastsystemen erfolgt. Hyper-V und XenServer dagegen leiten alle Zugriffe aus den VMs durch ein privilegiertes Service-Betriebssystem, das in einer eigenen Partition läuft. Damit der Datentransfer direkt und schnell mit dem Hypervisor abgewickelt werden kann, kommen im Gastsystem bei beiden Modellen bevorzugt paravirtualisierte Treiber zum Einsatz ("synthetische Treiber" im Microsoft-Jargon).
Die Hersteller von CPUs können ihre Unterstützung auch auf I/O ausweiten, indem sie etwa DMA-Puffer nach dem Muster von Nested Pages so virtualisieren, dass sie von allen VMs direkt angesprochen werden könnten. Dieses Ziel verfolgen Intel mit VT-d (erstmals in Nehalem umgesetzt) und AMD mit IOMMU.
Vielfalt als Bremse
Allerdings bleibt die wichtigste Aufgabe dann immer noch bei den Anbietern der betreffenden Komponenten, weil diese die parallelen Anfragen in ihren Bauteilen entgegennehmen, sortieren und verarbeiten müssten. Damit würden sie ebenfalls den Hypervisor entlasten und die Ausführungsgeschwindigkeit verbessern. Angesichts der zahlreichen Komponenten für Intel-Rechner lässt sich absehen, dass eine solche Umstellung länger dauern dürfte.
In der Zwischenzeit behelfen sich die Hersteller von Virtualisierungssoftware bei Performance-Engpässen etwa damit, dass sie den direkten Zugriff einer VM auf eine I/O-Komponente erlauben. Ein Beispiel dafür ist VMwares "VMDirectPath", das Intels VT-d voraussetzt. Dabei benötigt jedoch jede VM eine eigene dedizierte Hardware, und zudem wird die Migration von VMs auf andere physische Maschinen erschwert, wenn diese nicht identisch ausgestattet sind.
Neue Hardware will neue Software
Im Fall der Virtualisierungsunterstützung zeichnet sich eine Transformation von Standardhardware ab, die noch mehrere Jahre dauern wird. Die Anbieter von Virtualisierungssoftware können die neuen Features von CPUs und anderen Komponenten nur von Version zu Version integrieren. Mit der Anschaffung neuer Maschinen muss auch bald die Software nachgezogen werden, weil ein veralteter Hypervisor die Möglichkeiten moderner Hardware nicht ausreizen kann. Eine weitergehende RZ-Automatisierung wird zudem eine halbwegs homogene Infrastruktur voraussetzen, besonders auf der Ebene des VMM.
Ein wesentlicher Unterschied zum Mainframe, der als Pionier der Virtualisierung gilt, besteht darin, dass es bei diesem um die bessere Auslastung einer einzelnen Maschine ging. Die x86-Virtualisierung hingegen schließt mehrere oder viele physische Systeme zu einem großen Computer-Pool zusammen, in dem diese harmonieren müssen. Das scheitert jedoch an der Inkompatibilität zwischen AMD und Intel-Prozessoren, die eine Live Migration zwischen Hosts mit CPUs verschiedener Hersteller verhindert. Eine Lösung für solche gemischten Umgebungen ist noch nicht in Sicht.
Software kompensiert CPU-Mängel
Bei Softwarelösungen existieren zwei Ansätze, um die Betriebssysteme in den VMs zu zähmen. Der erste stuft die Gastsysteme auf den üblicherweise ungenutzten Ring 1 herunter ("Depriviligierung"), so dass der Hypervisor in Ring 0 die Steuerungshoheit über die Hardware behält. Allerdings lassen sich bei herkömmlichen x86-Prozessoren 17 privilegierte Instruktionen im User Mode ausführen, ohne dass sie dabei eine Ausnahme ("Trap") provozieren. Ein Hypervisor kann daher einen solchen Aufruf nicht erkennen und den Rechtekonflikt nicht lösen. Deshalb erfüllen die Intel-Prozessoren ohne VT-Erweiterungen die formalen Virtualisierungsanforderungen nicht, die Gerald Popek und Robert Goldberg bereits 1974 formuliert hatten.
Abhilfe schafft ein Verfahren namens binäre Übersetzung ("Binary Translation"), bei der ein Hypervisor die Anweisungen der Gastsysteme überwacht, Ring-0-Instruktionen abfängt und die privilegierten Operationen simuliert. Diesen Ansatz verfolgt VMware mit ESX.
Ein alternatives Vorgehen besteht darin, Gast-Betriebssysteme für die Nutzung in VMs anzupassen, so dass sie nicht mehr davon ausgehen, auf blanker Hardware zu laufen. Stattdessen kommunizieren sie über Schnittstellen mit dem Hypervisor ("Hypercalls") und vermeiden damit den Übersetzungsaufwand. Dieser Ansatz wird als Paravirtualisierung bezeichnet und führt in der Regel zu einer hohen Ausführungsgeschwindigkeit. Er eignet sich jedoch nur für Betriebssysteme, bei denen der Quellcode zugänglich ist und modifiziert werden kann.