Virtualisierung: Anforderungen an x86-Hardware

In den letzten Jahren ist die Rechenleistung im Server- und PC-Umfeld explosionsartig gestiegen. Um diese System-Performance effektiv zu nutzen, ist aktuell die Virtualisierungstechnologie das Mittel der Wahl. Neben der besseren Auslastung der Systeme, sinkt auch die Leistungsaufnahme in Bezug auf die Rechenperformance, was dazu beiträgt, die Betriebskosten der IT zu senken.

Allerdings hat im Jahr 1981, als IBM den ersten PC auf den Markt brachte, kaum jemand an diesen Virtualisierungs-Hype gedacht. Zwar konnten damals die dominierenden Mainframes mehrere Instanzen eines Betriebssystems in separaten virtuellen Maschinen bearbeiten – aber an eine solche rasante Entwicklung der aktuellen Server- und PC-Technologien dachte kaum jemand.

So konnte der erste PC mit MS-DOS nur ein Programm gleichzeitig auf einer physikalischen Hardware ausführen und dieses Anwendung gewährte noch dazu uneingeschränkten Zugriff auf alle Systemressourcen. Nach und nach entwickelten sich die x86-Systeme weiter und verrichten heute auch als ausgewachsene Server-Systme im Rechenzentrum ihre Dienste, so dass die Design-Entscheidungen von Anno dazumal auch noch x86-Server von heute kennzeichnen.

Obwohl der technische Fortschritt bei Prozessoren und Betriebssystemen, die Parallelverarbeitung von Anwendungen (Multitasking) deutlich vereinfacht und zu mehr Schutz vor Systemabstürzen führt, gilt bis heute noch das veraltete x86-Grundkonzept. Deshalb müssen die aktuellen Virtualisierungstechnologien und die dazugehörenden Hardware-Komponenten an das Virtualisierungsumfeld entsprechend angepasst werden.

Virtualisierungsfeindliche Prozessoren

Zu den größten Hürden der x86-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. Wenn sich mit dem Hypervisor (auch Virtual Machine Manager (VMM)) eine Softwareschicht zwischen Hardware und Gast-Betriebssysteme schiebt, dann muss dieser die Kontrolle über die CPU übernehmen und sie als gemeinsame Ressource für mehrere VMs verwalten.

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 VMM vorbehalten sind. Eine virtualisierte Umgebung muss deshalb dieses Verhalten der Gäste in den Griff bekommen.

Defizite durch aufwändige Hypervisor kompensieren

Bei Softwarelösungen existieren zwei Ansätze, um die Betriebssysteme in den virtuellen Maschinen (VM) 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üllte die Intel-Architektur bis zur Einführung der VT-Erweiterungen die formalen Virtualisierungsanforderungen nicht, die Popek und 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. Ein Beispiel dafür ist das Zusammenspiel von Xen und Linux, für das ein angepasster Kernel existiert. Aber auch VMware bietet seit 2006 mit VMI eine Programmierschnittstelle, über die Betriebssysteme direkt mit dem Hypervisor kommunizieren können. Microsoft reichte definierte für Hyper-V ein eigenes Interface für die Paravirtualisierung, verwendet dafür aber den Begriff "Enlightenment".

Neue Prozessoren erleichtern die Virtualisierung

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 physikalische 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 physikalischen Speicherort zu ermitteln.

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.

Virtualisierung – aber mit eingeschränkter Leistung

Trotz der deutlichen 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, 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.

I/O-Virtualisierung noch in der Entwicklung

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 möchten, 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 dabei 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 entsprechend 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 einrichten, 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.

Hardware-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 Performanceengpässen etwa damit, dass sie den direkten Zugriff einer VM auf eine I/O-Komponente erlauben. Ein Beispiel dafür ist VMwares "VMDirectPath", das allerdings Intels VT-d benötigt. Dieses Vorgehen hat indes auch Nachteile, weil jede VM eine eigene dedizierte Hardware benötigt und zudem die Migration auf andere physikalische Maschinen erschwert wird, wenn diese nicht identisch ausgestattet sind.

Fazit

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 virtualisierten Mainframe besteht auch darin, dass es bei diesem um die bessere Auslastung einer einzelnen Maschine ging. Die x86-Virtualisierung hingegen schließt mehrere oder viele physikalische 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 von VMs zwischen Hosts mit CPUs verschiedener Hersteller verhindert. Eine Lösung für solche gemischten Umgebungen ist noch nicht in Sicht. (ws/hal)

Dieser Artikel basiert auf einem Beitrag unserer Schwesterpublikation Computerwoche.