Im Möbelhaus gaukeln künstliche Bücherreihen belesene Behaglichkeit vor: Das ist Virtualisierung. Emulatoren bauen dagegen gleich ganze Häuserfassaden nach, um eine lebende Stadt zu suggerieren.

Wer den ganzen Tag am Linux-Computer arbeitet, freut sich nach getaner Arbeit auf ein kleines Spielchen zur Entspannung. Wem dann Linux-Klassiker wie Mahjongg oder Frozen Bubble nicht reichen, stößt schnell an die Grenzen eines freien Betriebssystems (Abbildung 1). Ähnlich beschränkt zeigt sich Linux beispielsweise auch beim Ausfüllen der Steuererklärung oder bei der Arbeit mit hochauflösenden Grafiken. Wer solches tun möchte, muss Linux verlassen, seinen Rechner neu starten und ein auf derselben Festplatte installiertes Windows booten. Da wäre es doch viel schöner, wenn man dasselbe System direkt von Linux aus starten könnte, ohne sein Lieblingsbetriebssystem verlassen zu müssen: wie eine Puppe in der Puppe bei den berühmten russischen Matroschkas.

So schön das klingt, so schwer ist es in der Praxis zu realisieren, denn beide Betriebssysteme unterscheiden sich recht drastisch voneinander. Wer als Betreiber von Linux mit einem anderen Betriebssystem arbeiten möchte, muss so tun, als sei Linux dieses andere Betriebssystem.

Abbildung 1: Der Ausgangspunkt: Auf einem herkömmlichen Computer startet zunächst ein Betriebssystem, wie beispielsweise Linux, das wiederum die Anwendungen startet und verwaltet.

Emulation: Wetteifern und nachahmen

Vor mehr als 40 Jahren, lange bevor es Linux gab, sah sich IBM schon einmal einem ganz ähnlichen Problem gegenüber: Das neue System/360 funktionierte vollkommen anders als der beliebte, aber in der Zwischenzeit veraltete 7070-Computer. Um potentiellen Kunden den Umstieg zu erleichtern, sollten sich die alten Anwendungen auch auf dem neuen System weiter nutzen lassen. Nach einigen Tests entschied sich IBM schließlich für die Idee ihres Ingenieurs Larry Moss, der eine Kombination aus Software und einer speziellen Hardwareerweiterung vorschlug: Einmal gestartet, überwachte die Kombi jeden Schritt der alten Anwendung und übersetzte deren Befehle bei Bedarf in die des neuen System/360. So verhielt sich der neue Computer exakt wie sein Vorgänger [1].

Dieses geschickte Täuschungsmanöver von Maschine zu Maschine versetzte die Käufer des neuen Modells in die Lage, ihre alten 7070-Anwendungen weiter zu nutzen. Da die Software einen fremden Computer nachahmte, bezeichnete Larry Moss seine Entwicklung als Emulator.

Moderne Emulatoren bilden einen kompletten Computer ausschließlich auf der Software-Ebene nach. Das gelingt mittlerweile so perfekt, dass man mit ihnen ein komplettes Gast-Betriebssystem samt der dafür entwickelten Anwendungen starten kann. Auf diese Weise erhält man einen virtuellen PC oder, allgemeiner: eine virtuelle Maschine (siehe Abbildung 2).

Abbildung 2: Wie bei einer Puppe-in-der-Puppe erzeugt ein Emulator einen PC im PC. Hier laufen Windows und Word in der Emulation. Beide Anwendungen haben dabei keinen Zugriff auf das darunter liegende Linux-System.

Beispiele für bekannte und kostenlose Emulatoren sind QEMU [2] und Bochs [3]. Wie Abbildung 3 zeigt, leiten sie einfach die Bildschirmausgabe in ihr eigenes Anwendungsfenster um. Das unter dem virtuellen PC installierte Betriebssystem glaubt dagegen, einen Standard-Monitor zu nutzen.

Abbildung 3: Der Emulator QEMU in Aktion: Der von ihm bereitgestellte virtuelle PC führt unter Suse Linux ein Ubuntu-Linux aus.

Ein Emulator bietet gleich mehrere Vorteile: Zunächst einmal lässt sich das in ihm laufende System recht einfach klonen. Da der Emulator einen ganzen PC als Software nachbaut, kann man dessen aktuellen Zustand leicht einfrieren, in einem Snapshot archivieren oder auf einem anderen Computer fortsetzen.

Da die simulierte Hardware sich nicht ändert, funktioniert dieser Transfer sogar unabhängig von der real existierenden Hardware. Auf diese Weise lassen sich neue Programme gefahrlos ausprobieren und testen: Sie speichern einfach den aktuellen Emulatorzustand, installieren die gewünschten Anwendung und stellen bei Nichtgefallen den alten Stand wieder her.

Neben solchen reinen Software-Lösungen gibt es auch Hardware-Emulatoren. Wie im Fall des historischen System/360 findet man aber auch Mischlösungen. Ein aktuelles Beispiel dafür bietet die Spielkonsole Playstation 3 von Sony. In der ersten Fassung enthielt sie noch eine Hardwarekomponente, mit der auch Playstation-2-Spiele auf der Konsole liefen. In der aktuellen europäischen Version übernimmt diese Aufgabe ein reiner Software-Emulator.

Dieses Beispiel zeigt ein weiteres Haupteinsatzgebiet von Emulatoren: Mit diesen Programmen erwecken Sie nicht mehr erhältliche Hard- und Software zu neuem Leben. So verrichten plötzlich etwa die gute, alte Buchhaltung aus DOS-Zeiten oder die legendäre WordPerfect-Textverarbeitung aus gleicher Epoche wieder ihre Dienste.

Im Fokus solcher Emulationen stehen besonders die Videospielkonsolen und Heimcomputer des vorigen Jahrhunderts. Fans bilden die alten Schätzchen bis aufs Bit genau in Software nach. Auf diese Weise kommen Klassiker wie Commodore Amiga [4], Atari ST [5] oder der C=64 [6] auf Linux-PCs wieder zu neuen Ehren (Abbildung 4).

Abbildung 4: Die Emulation UAE belebt die alte Hardware des Commodore Amiga. Hier läuft dessen grafische Oberfläche in einem Fenster unter Linux.

Emulatoren verursachen systembedingt aber auch Probleme: Da sie sämtliche Hardwarekomponenten des Computers möglichst exakt simulieren müssen, schlucken sie eine Menge Rechenleistung. Als Faustregel gilt: Je älter ein Betriebssystem, desto schneller lässt es sich in einem Emulator betreiben. Dagegen arbeitet ein blutjunges Ubuntu unter Qemu, als würde man es auf einem längst in die Jahre gekommenen Rechner betreiben.

Virtualisierung: So tun, als ob

Bei näherem Hinsehen entpuppt es sich allerdings als unsinnig, eine komplette Intel-CPU nachzubilden, wenn sie sowieso im Computer steckt: Stattdessen könnte man den Prozessor doch einfach direkt nutzen und bräuchte nur den Rest des gewünschten Zielsystems zu simulieren. Diese Idee lässt sich auf alle weiteren Komponenten ausdehnen: Man bildet nur noch die gerade notwendigen Teile der Hardware durch Software nach. In einem solchen Fall spricht man nicht mehr von einer Emulation, sondern von Virtualisierung.

Entfernt man aus einer Emulation einfach die Prozessorsimulation, spricht man von einer Hardware- oder Systemvirtualisierung. Qemu lässt sich beispielsweise mit der Erweiterung KQemu [2] auf diese Arbeitsweise ein, und auch das kommerzielle VMware [7] verzichtet auf die Nachbildung des Prozessors. Das so erzielte Plus an Geschwindigkeit bezahlt der Anwender allerdings mit einer Bindung an einen speziellen Prozessortyp. So funktionieren die beiden genannten Lösungen beispielsweise nicht ohne weiteres mit einem PowerPC.

Paravirtualisierung

Ein Emulator läuft zunächst als ganz normales Programm beispielsweise unter Linux oder Windows. Theoretisch ist es aber auch denkbar, das Wirtsbetriebssystem gleich ganz zu streichen. Dazu benötigt man eine spezielle Software, die direkt auf der Hardware aufsetzt. Solch ein Programm heißt Hypervisor oder Virtual Machine Monitor. Es kontrolliert unabhängig vom Betriebssystem alle auf dem Computer installierten Gastsysteme und sorgt für den reibungslosen Parallelbetrieb (Abbildung 5).

Abbildung 5: Das Xen-Projekt verwendet einen Hypervisor, der Aufrufe an einen speziellen Linux-Kernel weiterreicht.

In dieser Umgebung arbeiten die Gastsysteme nicht mehr direkt mit der Hardware zusammen, sondern melden ihre Wünsche dem Hypervisor. Möchte beispielsweise eines der gleichzeitig laufenden Linux-Systeme auf die Festplatte zugreifen, teilt es dies dem Hypervisor mit. Der führt nun den eigentlichen Zugriff aus und liefert das Ergebnis an das anfragende System zurück. Damit alle Guests mit dem Hypervisor kommunizieren können, bietet der eine einheitliche Schnittstelle zur realen Hardware, die auch andere Programme und Betriebssysteme nutzen können. Mit dieser als Paravirtualisierung bezeichneten Technik erreicht man gegenüber den bisher genannten Lösungen eine erstaunlich hohe Ausführungsgeschwindigkeit. Die Hersteller solcher Virtualisierungen sprechen von Bremswirkungen gegenüber “echter” Hardware in der Größenordnung von lediglich 0,5 bis 3 Prozent. Zu den bekanntesten Paravirtualisierungslösungen zählen das kostenlose Xen [8] und der kommerzielle ESX-Server von VMware [7].

Für Schwierigkeiten sorgt bei der Paravirtualisierung die Anforderung, dass jedes Gastsystem den Hypervisor kennen und nutzen muss: Dafür kommt man um eine entsprechende Modifikation des Betriebssystems nicht herum. Spätestens beim gut geschützten Windows steht man damit aber vor einem großen Problem. Dazu kommt, dass der Hypervisor nun selbst einige Betriebssystemaufgaben übernimmt. Beispielsweise muss er wissen, welche Grafikkarte im System steckt und wie man sie ansteuert.

Damit die Hypervisor-Entwickler angesichts dieser Aufgaben nicht im Anpassen von Treibern versinken, wählen sie in der Regel einen der beiden folgenden Auswege:

• Der Hypervisor des Xen-Projekts erklärt einfach eins der parallel laufenden Betriebssysteme zu seinem Lieblingsgast. Als Gegenleistung für diese Gunst nutzt er dessen Treiber. Greift also ein anderes Betriebssystem zum Beispiel auf ein Gerät an der USB-Schnittstelle zu, leitet der Hypervisor diesen Zugriff an das privilegierte Gast-Betriebsystem weiter (Abbildung 5).
• Der zweite Ansatz baut einen vorhandenen Linux-Kernel zum Hypervisor um – Linux bringt schon fast alles mit, was der Hypervisor benötigt, und ist zudem zugänglich für solche Umbauarbeiten. Dieses Verfahren verwendet beispielsweise das KVM-Projekt [9]: Es stellt ein Kernelmodul bereit, das den Linux-Kernel in einen Hypervisor verwandelt. Dieser startet dann mit Hilfe eines modifizierten Qemu-Emulators weitere Gastbetriebssysteme. In diesem Fall spricht man von einer kernelbasierten Virtualisierung.

Betriebssystem virtualisieren

Wer lediglich ein gerade laufendes Linux vervielfachen möchte, greift zur so genannten Betriebssystemvirtualisierung. Anders als in den anderen Virtualisierungsmöglichkeiten existiert auf dem realen PC nur noch ein einziges Betriebssystem. Dieses wird anhand von Vorlagen einfach geklont. Diese Vorlagen legen genau fest, wie die Konfiguration des neuen Klons auszusehen hat; so könnte der Administrator beispielsweise den Zugriff auf einen bestimmten Bereich der Festplatte einschränken.

Beim anschließenden Klon-Vorgang dupliziert die Virtualisierung in der Praxis meist nur die Systemumgebung. Unter der Haube gibt es damit weiterhin nur einen einzigen Linux-Kern, den alle gestarteten Programme nutzen – egal unter welchem Klon sie laufen (siehe Abbildung 6). Die Betriebssystemvirtualisierung sperrt lediglich die Anwendung in eine eigene Systemumgebung. Damit erhält man zwar ein sicher und schnell arbeitendes System; Programme aus anderen Betriebssystemen laufen auf diese Weise jedoch nicht.

Kostenlose Betriebssystemvirtualisierer sind beispielsweise der Linux-VServer [10] und OpenVZ [11], ein Open-Source-Ableger des kommerziellen Virtuozzo. Beide Varianten setzen einen modifizierten Linux-Kernel ein.

Abbildung 6: Bei der Betriebssystemvirtualisierung sperrt man die Anwendungen in eine eigene, abgeschottete Umgebung.

Applikationsvirtualisierung

Nicht in jedem Fall ist es nötig, eine ganze Systemumgebung zu klonen, um ein Programm von den anderen abzuschotten. Die Applikationsvirtualisierung schnürt für jede Anwendung ein Rundum-Sorglos-Paket, das genau das Notwendige für ihre Ausführung enthält. Dazu zählen beispielsweise Konfigurationsdateien, Bibliotheken oder Hilfsprogramme. Das entstehende Komplettpaket bezeichnet man als (virtuelle) Laufzeit-Umgebung.

Programme mit solchen Paketen muss man nicht einmal installieren. Alle in der Programmiersprache Java entwickelten Anwendungen fallen in diese Kategorie: Zu ihrer Ausführung benötigt man zwingend das Java Runtime Environment [12]. Aber auch ScummVM [13], das für die Reinkarnation alter Abenteuerspiele zuständig ist, arbeitet nach diesem Prinzip (Abbildung 7).

Abbildung 7: ScummVM erweckt alte Adventures wieder zum Leben, indem es ihnen alles zur Verfügung stellt, was sie benötigen – besonders einen Interpreter für Skripte.

Partial Virtualization

Um einen Spezialfall im Bereich der Virtualisierungstechniken handelt es sich bei der Partial Virtualization. Sie tut so, als sei eine Hardwarekomponente gleich mehrfach vorhanden. Sofern der Hauptspeicher darunter fällt, spricht man von Adress Space Virtualization. In diesem Fall glaubt jedes laufende Programm, den Speicher exklusiv für sich alleine zu haben. Alle anderen Prozesse bleiben folglich vor ihm verborgen.

Server-Virtualisierung

Anbieter von Internetservern sind besonders an Virtualisierungslösungen interessiert. Denn erst diese erlauben das so genannte Shared-Hosting, bei dem sich mehrere Kunden einen realen Internetserver teilen. Jeder dieser Kunden glaubt mit einigem Recht, er arbeitete auf seinem eigenen Server. Anbieter wiederum können mit dieser Technik Anfragen aus dem Internet besser auf ihre Server verteilen und – durch gemeinsame Hardwarenutzung – zudem die Betriebskosten senken.

Die dabei eingesetzten Virtualisierungslösungen arbeiten mit den bisher vorgestellten Konzepten, bieten in der Regel aber zusätzlich auf den Serverbetrieb zugeschnittene Leistungen, wie die angesprochene Lastverteilung oder spezielle Administrationsoberflächen. Beispiele für solche Produkte sind der VServer oder das bereits angesprochene OpenVZ. Beide Systeme setzen einen modifizierten Linux-Kernel ein, der dann die einzelnen Virtual Environments startet und kontrolliert.

Fazit

Sieht man einmal von den verwirrenden und häufig mehrdeutigen Modebegriffen ab, öffnet die Virtualisierung interessante Möglichkeiten: Verschiedene Betriebssysteme lassen sich gleichzeitig betreiben, kritische Anwendungen einsperren und neue Konfigurationen gefahrlos ausprobieren.

Für den privaten Desktop-PC dürften die Emulatoren von größtem Interesse sein: Dank spezieller Beschleunigungsmodule, die die Befehle direkt an den Prozessor durchreichen, lässt sich auch ein modernes Windows-System einigermaßen flott bedienen. Andere Emulatoren holen längst vergangene Legenden wie den Commodore 64 wieder ins Leben zurück.

Der Erfolg der derzeit modernen Paravirtualisierung steht und fällt maßgeblich mit der Unterstützung durch die Betriebssysteme. Hier kocht aber jeder Hypervisor-Hersteller sein eigenes Süppchen. So wird speziell Microsoft sein Windows – wenn überhaupt – ausschließlich für eigene Hypervisoren öffnen.

Auf großen Servern zuhause und in der Praxis etabliert sind die Technologien von OpenVZ und VServer. Für private Desktop-Rechner eignen sie sich weniger; schließlich fährt kaum jemand einen Heimserver mit mehreren Internetauftritten, nimmt zusätzlich in Kauf, dass nur ein Betriebssystem läuft und ist zudem bereit, sich in die etwas komplexe Konfiguration einzuarbeiten. Ein schneller Griff zu Qemu und Co. erledigt in der Regel das gleiche mit deutlich weniger Handgriffen.