Dank Libvirt-Toolkit wildert KVM auch unter den Gäste-Images der Mitbewerber. Der Newcomer KVM, überhaupt erst seit 2007 am Start, ist den etablierten Mitbewerbern wie VMware und Xen technologisch inzwischen dicht auf den Fersen.

© Gerti G., Photocase.com

Ein Grundproblem jeder Virtualisierung sind die gleichzeitigen Zugriffsversuche verschiedener virtueller Maschinen auf Hardware, die nur exklusiv verwendbar ist. Für dieses Problem gibt es gleich mehrere Lösungsansätze. So verwendet etwa VMwares ESX-Server [1] dafür eine Methode, die auch als "Full Virtualisation with Binary Translation" bekannt ist. Im privilegierten Ring 0 (siehe Kasten "Herrschaft über die Hardware") läuft dabei ein so genannter Virtual Machine Monitor (VMM), während sich die Gastsysteme komplett im nicht privilegierten Ring 3 wiederfinden.

Herrschaft über die Hardware

Das generelle Problem bei der Virtualisierung mit mehreren Betriebssysteminstanzen, die voneinander nichts wissen, zeigt sich im Kleinen bereits innerhalb eines Betriebssystems mit mehreren Prozessen. Wollen mehrere davon direkt auf dieselbe Hardware zugreifen, führt das zwangsläufig zu Konflikten und ist deshalb zu verhindern. Damit das Betriebssystem nun entscheiden kann, welchen Prozessen es Vorrang bei Hardwarezugriffen einräumen soll, teilt es sie in Klassen ein, die man in Anlehnung an eine entsprechende bildliche Darstellung auch als Ringe bezeichnet (Abbildung 1). Abbildung 1: Ringstruktur in der x86-Architektur. Je nachdem, in welchem Ring ein Prozess läuft, hat dieser entweder komplette oder eingeschränkte CPU-Ressourcen zur Verfügung. Linux auf der x86-Rechnerarchitektur benutzt üblicherweise nur zwei dieser vier Privilegierungsebenen, Ring 0 und Ring 3. Im erstgenannten Ring 0 - man nennt ihn auch den Kernelspace - steht einem Prozess der komplette CPU-Befehlssatz zur Verfügung. Im Ring 3 - dem Userspace - ist dagegen ein direkter Zugriff auf die Hardware nicht möglich. Benötigt eine Userspace-Anwendung Zugriff auf ein Hardwaregerät, so muss sie den Umweg über einen Systemcall nehmen. Dabei findet ein Kontextwechsel statt und der Userspace-Prozess gibt die Kontrolle über die CPU an den Kernel ab, der den Ring 0 benutzt. Der Kernel führt dann den gewünschten privilegierten Zugriff durch und übergibt die Kontrolle über die CPU wieder an die Userspace-Applikation. Würde es ein Prozess aus Ring 3 versuchen, eine privilegierte Ring-0-Instruktion zu verwenden, würde er dadurch eine CPU-Exception auslösen und in der Folge abstürzen. Er ist also immer auf den Umweg über die Systemcalls angewiesen. Eine Übersicht aller zur Verfügung stehenden Systemcalls enthält die gleichnamige Manpage.

Führt ein solches Gastsystem nun einen privilegierten Befehl aus, von dem es gar nicht weiß, dass er ihm jetzt nicht mehr erlaubt ist, dann endet das in einem General Protection Fault. Diesen Fehler fängt nun aber der VMM im Ring 0 ab und münzt ihn in einen privilegierten VMM-Zugriff um. Das Ergebnis gibt er dann wieder zurück an das Gastsystem im Ring 3.

Der ganze Vorgang findet im Virtualisierungsmodus statt und verursacht in jedem Fall einen gewissen Overhead. Nicht privilegierte Zugriffe auf die CPU, beispielsweise von Applikationen, die im Usermode laufen, lassen sich dagegen verlustfrei unmittelbar ausführen (Direct Execution). Dieser Ansatz virtualisiert zwar die CPU, aber keine I/O-Geräte, die er nur emuliert. Dafür greift er auf Treiber des VMM-Kernels zurück. Das hat jedoch den entscheidenden Nachteil, dass sich auch nur jene Geräte ansprechen lassen, für die der VMM-Kernel einen Treiber zur Verfügung stellt.

Xen bietet zwei andere Verfahren zur Virtualisierung an. Die erste Variante bezeichnet man ebenfalls als Full Virtualisation. Allerdings benötigt der Virtual Machine Monitor, der unter Xen auch Hypervisor heißt, dafür eine CPU, die ihn speziell unterstützt [2]. Deswegen spricht man bei dieser Spielart auch von "Hardware Assisted Full Virtualisation". Ob die CPU diesen Virtualisierungssupport anbietet, lässt sich leicht mit dem folgenden Befehl rausbekommen:

grep --color -e svm -e vmx /proc/cpuinfo

Selbstverständlich ist ebenfalls sicherzustellen, dass die Funktion im Bios nicht deaktiviert ist.

Bei Xen kümmert sich die CPU ums Virtuelle

Anders als im Beispiel mit dem Virtual Machine Monitor von VMwares ESX-Server muss der Xen-Hypervisor keine Befehlsaufrufe aktiv abfangen. In seinem Fall kümmert sich nämlich die CPU selbst darum, die Aufrufe zu virtualisieren. Aktuelle Prozessoren mit dem nötigen Virtualisierungssupport kennen hierfür einen so genannten Root Mode und einen Non-Root Mode.

Beginnt eine Gastmaschine im Non-Root Mode eine privilegierte Aktion, so fängt der Prozessor diese Anweisung ab und schickt sie an den Hypervisor (siehe Abbildung 2). Der führt den Befehl nun im so genannten Root Mode stellvertretend für das Gastsystem aus und wechselt danach wieder in den Non-Root-Modus. Dieses Verfahren ist wesentlich performanter, da der Hypervisor nicht jede Aktion der Gastmaschine aktiv überprüfen muss, um bei privilegierten Aktionen eventuell einzugreifen.

Abbildung 2: Xen arbeitet mit einem dedizierten Hypervisor, der unmittelbar auf der Hardware aufsetzt, und einem privilegierten Managementsystem.

Mit Hilfe einer modifizierten Qemu-Anwendung (»qemu-dm«) findet auch hier eine Emulation diverser I/O-Geräte statt. So sieht eine Xen-virtuelle Maschine beispielsweise immer eine RTL8139-Netzwerkkarte und eine Cirrus-Logic-VGA-Grafikkarte. Eine Übersicht der emulierten Hardware listet die Manpage von Qemu auf. Die Emulation hat natürlich einen gewissen Performanceverlust zur Folge. Abhilfe versprechen paravirtualisierte Treiber, die der Beitrag weiter unten vorstellt.

Seine volle Leistungsstärke spielt Xen allerdings erst mit der so genannten Paravirtualisation aus. "Para" bedeutet in diesem Zusammenhang so viel wie "miteinander". Dafür ist - anders als bei der Full Virtualisation - der Betriebssystem-Kernel des Gastsystems um Hypercalls zu erweitern. Bei diesen Hypercalls handelt es sich um eine Art Software-Trap für privilegierte Anweisungen der Gastsysteme an den Hypervisor. Sie sind vergleichbar mit Systemcalls, die der Userspace an den Kernel sendet.

Zweiteilige Treiber

Im Fall von Xen kommen bei der Paravirtualisierung in den virtuellen Maschinen Frontend-Treiber zum Einsatz, die jeweils mit Hilfe eines korrespondierenden Backend-Treibers in einem privilegierten System die Hardware direkt ansprechen.

Die nötige Kommunikation zwischen Front- und Backend findet über einen Event Channel statt. Dabei handelt es sich einfach um einen gemeinsam genutzten Speicherbereich.

Das erwähnte privilegierte System heißt in der Xen-Terminologie Domain 0 und ist ein reguläres Linux-System mit einem modifizierten Kernel, der im CPU-Ring 1 läuft. Es setzt direkt auf dem Hypervisor auf und ist in der Lage, alle Hardwaregeräte anzusprechen, die ein normales Linux-System ansprechen kann. Das heißt also auch, man kann auf alle Linux-Treiber zurückgreifen. Dadurch lässt sich eine sehr große Anzahl an Geräten unterstützen. Den Zugriff auf die CPU und den Arbeitsspeicher steuert der Hypervisor direkt. Da bei dieser Technologie weder Geräte zu emulieren noch irgendwelche Befehle umzuschreiben sind, laufen die virtuellen Gastsysteme mit nahezu nativer Performance.

Die paravirtualisierten Treiber, die bei der Full Virtualisation zum Einsatz kommen, sind auf bestimmte Subsysteme ausgerichtet, üblicherweise Block- und Netzwerk-I/O, die direkt mit dem Hypervisor kommunizieren können. Somit entfällt die lästige Emulation für diese Subsysteme, was eine wesentlich bessere Performance zur Folge hat. Diese paravirtualisierten Treiber gibt es nicht nur für Linux-Systeme, mittlerweile stehen auch Treiber für Windows-Maschinen zur Verfügung.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Dank Libvirt-Toolkit wildert KVM auch unter den Gäste-Images der Mitbewerber. Der Newcomer KVM, überhaupt erst seit 2007 am Start, ist den etablierten Mitbewerbern wie VMware und Xen technologisch inzwischen dicht auf den Fersen.