Virtualisierung ist eines der Themen der Stunde, verspricht sie doch tiefere Kosten durch Hardware-Konsolidierung und teilweise weniger Administrationsaufwand. Auch Linux schwimmt ganz vorne auf der Virtualisierungswelle mit und bietet etliche Werkzeuge, die eine Vielzahl verschiedener Virtualisierungstechniken für fast jeden Bedarf unterstützen.
Von Virtualisierung spricht man im Computerbereich, wenn die Ressourcen eines Computers aufgeteilt werden. Dies ist wenig präzise, und entsprechend viele verschiedene Ausprägungen von Virtualisierung existieren. Grundsätzlich kann man zwischen Software- und Hardware-Virtualisierung unterscheiden, bei der die Aufteilung der Computer-Ressourcen entweder ganz von einer Software oder auch von der Hardware wie bei Mainframes übernommen wird.
Da die x86-Plattform erst seit 2006 mit AMD-V und Intel VT erste zaghafte Ansätze für Hardware-Virtualisierung zeigt, steht die Software-Virtualisierung verständlicherweise im Mittelpunkt des Interesses. Sie kann man in drei verschiedene Klassen unterscheiden: Betriebssystem-Virtualisierung, System-Virtualisierung und Applikations-Virtualisierung. Letztere fällt ein bisschen aus dem Rahmen, da sie – wie der Name schon sagt – zur Virtualisierung einzelner Applikationen und nicht ganzer Betriebssysteme dient. Beispiele sind die JVM von Java oder Parrot von Perl 6.
Die wohl bekannteste Virtualisierungsart ist die System-Virtualisierung mit einem Virtual Machine Monitor, der auch Hypervisor genannt wird. Beim Virtual Machine Monitor handelt es sich um eine zusätzliche Ebene, die zwischen der Hardware und dem zu virtualisierenden System eingezogen wird. Diese Ebene kann direkt oberhalb der Hardware angesiedelt sein (Bare Metal Virtualization, z.B. Xen Enterprise oder Vmware ESX) oder zwischen dem Host-Betriebssystem und dem Gast-System.
Ihre Aufgabe besteht darin, die Ressourcen zu verwalten und die Hardware zu abstrahieren. Dazu werden meist bekannte Komponenten wie Intel-Chipsätze aus der Pentium-3-Ära oder IDE-Festplatten nachgebildet, womit sich auch alte Betriebssysteme betreiben lassen, die für aktuelle Hardware nicht über die nötigen Treiber verfügen. Man denke an Windows 95 oder OS/2. Allerdings wird selten die komplette Hardware virtualisiert. So bleiben beispielsweise Firewire- oder ISDN-Karten oftmals aussen vor.
Die einzelnen Ausprägungen der System-Virtualisierung unterscheiden sich in der Art, wie mit der CPU umgegangen wird.
Bei der Hardware-Emulation, auf die sich unter anderem Qemu und Bochs verstehen, werden nicht nur Laufwerke und andere Komponenten emuliert, sondern ein gesamter Computer inklusive Prozessor. Dies ermöglicht es, Betriebssysteme auch auf Plattformen zu betreiben, zu denen sie nicht kompatibel sind. Es kann so beispielsweise auf einer PowerPC-Maschine ein x86-OS virtualisiert werden. Allerdings führt die Emulation der CPU zu dramatischen Geschwindigkeitseinbussen, da die CPU-Instruktionen von der einen auf die andere Architektur übersetzt werden müssen.
Bei der Hardware-Virtualisierung (u.a. Vmware, Parallels Workstation) und Paravirtualisierung (Xen) wird im Gegensatz zur Hardware-Emulation direkt auf den Prozessor zugegriffen. Dies ist zwar schneller als die Emulation, doch müssen den Zugriffen enge Schranken gesetzt werden, sonst könnten sich die virtualisierten Betriebssysteme gegenseitig stören und den gesamten Rechner zum Absturz bringen.
Damit dies nicht passiert, nimmt der Virtual Machine Monitor die Privilegierungsstufen der x86-Prozessoren zu Hilfe. Diese schränken Prozesse auf bestimmte Befehle und Speicherbereiche ein und schotten sie damit voneinander ab. x86 kennt vier dieser Stufen, sogenannte Ringe. Sie sind von 0 bis 3 durchnumeriert, wobei Ring 0 (auch Supervisor Mode oder Kernel Mode genannt) die höchste Privilegierungsstufe darstellt. In Ring 0 operieren Betriebssystem und Treiber. Ring 3 bietet die niedrigste Privilegierung und wird für User-Space-Applikationen verwendet.
Wird ein Betriebssystem virtualisiert, sitzen der Wirt und der Virtual Machine Monitor im Ring 0, nicht aber das zu virtualisierende Betriebssystem. Dieses wird wie eine herkömmliche Applikation behandelt und in Ring 3 ausgeführt. Führt es in Ring 3 eine Operation aus, die nur Ring 0 erlaubt ist, löst dies eine Trap (Exception) aus. Diese Exception kann vom Virtual Machine Monitor abgefangen und dann von ihm emuliert werden, sodass der Wirt die Kontrolle über den Rechner nicht verliert.
Bei x86 funktioniert dies allerdings nicht immer, da einerseits nicht alle Schutzverletzungen Traps auslösen und andererseits einige Exceptions sich in den verschiedenen Ringen unterschiedlich verhalten. Dies gilt es zu beheben.
Bei der Hardware-Virtualisierung überwacht der Virtual Machine Monitor den ausgeführten Code permanent und ersetzt Befehle, die nicht wie erwartet funktionieren, durch Workarounds. Diese permanente Überwachung der auszuführenden Befehle kostet Performance, ermöglicht es aber, unmodifizierte Betriebssysteme auszuführen.
Das Ausführen unmodifizierter Betriebssysteme ist bei der Paravirtualisierung dagegen nicht möglich. Hier wird darauf verzichtet, den Code permanent zu überwachen, was die Ausführung der virtuellen Maschinen deutlich näher an die Originalgeschwindigkeit heranbringt. Im Falle von Xen werden die Betriebssystem-Kernel derart modifiziert, dass sie statt Ring-0-Operationen sogenannte Hypercalls ausführen. Mit diesen Hypercalls können die Betriebssysteme den Virtual Machine Monitor anweisen, an ihrer Statt die Ring-0-Operationen auszuführen.
Wer auf die Nachteile dieser Workarounds verzichten will, muss auf Prozessoren mit AMD-V oder Intel VT setzen. Diese «reparieren» zwar nicht den x86-Befehlssatz, führen aber statt dessen eine Art weiteren Ring mit maximaler Privilegierung ein. In diesem werden dann das Wirtssystem und der Virtual Machine Monitor ausgeführt, während der Gast mit Einschränkungen in dem von ihm benötigen Ring 0 arbeiten kann, ohne dabei die anderen Gäste und den Wirt zu stören.
Einen gänzlich anderen Weg als die System-Virtualisierung geht die Betriebssystem-Virtualisierung, die erst in den letzten Monaten dank Virtuozzo respektive OpenVZ richtig populär geworden ist, obwohl FreeBSD sie mit den Jails schon lange kennt. Bei der Betriebssystemvirtualisierung werden nicht andere Betriebssysteme (mit einem anderen Kernel) virtualisiert, sondern neue Instanzen (Laufzeitumgebungen) des Wirtssystems geladen, die sich alle denselben Kernel teilen. Entsprechend spricht man bei der Betriebssystemvirtualisierung auch von Partitionierung, die aber nicht mit der Partitionierung aus der Hardware-Virtualisierung verwechselt werden darf.
Da immer der gleiche Kernel und die Original-Hardware verwendet werden, geht abgesehen vom Overhead, der durch die Isolation der verschiedenen Umgebungen verursacht wird, nur wenig Geschwindigkeit verloren. Allerdings kann man mangels Hardware-Abstraktion weder Legacy-Systeme auf aktuellen Computern betreiben noch virtuelle Maschinen ohne weiteres auf andere Hardware verschieben. Der Aufgabenbereich der OS-Virtualisierung liegt entsprechend bei Multiuser-Umgebungen, die voneinander isoliert werden sollen, wie man es häufig beim Shared Hosting antrifft. Hier können mit der Betriebssystemvirtualisierung die Auswirkungen von Hacks und übermässiger Ressourcen-Benutzung erfolgreich eingedämmt werden. Es eignet sich aber auch zur Aufteilung von Administrationsverantwortung, da jeder virtuelle Server Root-Rechte für seine Umgebung erhält.
Auf Windows ist die Installation von Virtualisierungssoftware eine einfache Angelegenheit, da der Windows-Kernel nicht wie Linux alle paar Wochen in neuen Versionen erscheint und zudem stabile Binär-Interfaces bietet. Dies macht Virtualisierungssoftware die Interaktion mit dem Host-Betriebssystem, die unter anderem für die Abstraktion der Hardware nötig ist, relativ einfach. Allerdings schränkt dies auch im Falle der Paravirtualisierung, die auf gütige Mithilfe des Wirts- und Gastsystems angewiesen ist, die Möglichkeiten ein. Bei Linux hängt der Aufwand, der für die Installation getätigt werden muss, erheblich von der jeweiligen Virtualisierungslösung ab.
Grundsätzlich ist allen Virtualisierungslösungen (abgesehen von der Bare Metal Virtualization) gemein, dass sie auf Seite des Wirts von gewissen Kernel-Versionen mit spezifischen Konfigurationen abhängig sind. So gilt es zuerst zu prüfen, mit welchen Linux-Distributionen und -Kerneln sie kompatibel sind, und erst dann eine Distribution aus der Auswahl einzusetzen. Sonst kann es passieren, dass man mit einer Distribution und Virtualisierungssoftware dasitzt, die nicht zueinander passen. Grosse Ausnahme ist KVM (Kernel-based Virtual Machine for Linux), das seit Linux 2.6.20 fester Bestandteil des Kernels ist.
Bei proprietären Produkten wie denjenigen von Vmware und Parallels hat man gute Chancen mit den Enterprise-Distributionen von Novell und Red Hat, auch dank ihren langen Support-Zyklen.
Heikler sieht es dagegen bei Community-Distributionen wie OpenSuse, Fedora Core oder Debian aus. Sie werden zwar ab und zu auch unterstützt, meist aber nur in älteren Versionen. Dies kann bei Distributionen, die nur selten Sicherheits-Patches erhalten, kritisch werden. Ebenfalls geachtet werden muss auf die richtige Auswahl des Kernels.
In der Regel können nur die Standard-Kernel einer bestimmten Distribution verwendet werden. Andere Versionen oder selbst gebaute Kernel mit zusätzlichen Patches wie grsecurity oder SELinux vertragen sich schlecht bis gar nicht mit Virtualisierungssoftware. Die Installation der Produkte ist bei erfüllten Voraussetzungen dagegen recht unproblematisch: RPM- oder Debian-Pakete und Tarballs mit passenden Installationsscripts stehen zur Verfügung und sorgen sich sowohl um die Übersetzung der Kernel-Module als auch um deren Installation.
Bei Open-Source-Virtualisierungssoftware wie Xen und OpenVZ ist die Flexibilität generell grösser. Etliche Distributionen bringen mittlerweile angepasste Kernel mit, die ohne aufwändiges Patchen installiert werden können. Zusätzlich stellen die meisten Projekte präparierte Kernel bereit, und wer lieber selber Hand anlegen will, kann dies natürlich auch tun. Um die Kompatibilität mit anderen Kernel-Patches steht es allerdings auch hier meist schlecht, da die Modifikationen sowohl bei der Betriebssystem-Virtualisierung als auch bei der System-Virtualisierung invasiv sind.
Wie mit KVM verfahren und welche Erleichterung die generische Paravirtualisierungsschnittstelle paravirt_ops, die beide seit Version 2.6.20 Teil von Linux sind, auf die Inbetriebnahme von Virtualisierungssoftware haben wird, steht dagegen noch in den Sternen – zu neu sind beide Komponenten.
Ob Gastsysteme «einfach so» in Betrieb genommen werden können, hängt sowohl von der jeweiligen Virtualisierungsmethode als auch von der Hardware ab.
Während die Hardware-Virtualisierung und -Emulation keine Modifikation der Gäste verlangt, müssen bei der Paravirtualisierung die Kernel der Gastsysteme modifiziert werden. Bei Linux und BSD ist dies verhältnismässig einfach und angepasste Kernel sind für Xen erhältlich. Bei proprietären Systemen ist man dagegen von der Kooperation des Herstellers abhängig. Immerhin hat beispielsweise Novell bereits eine «xenifizierte» Version von Netware präsentiert, und auch Microsoft möchte die nächste Windows-Server-Generation auf Kompatibilität mit Xen trimmen.
Bei der Betriebssystemvirtualisierung entfällt diese Arbeit, da nur eine neue Instanz des Kernels des Wirts gestartet wird. Wer möchte, kann zwar andere Linux-Distributionen (allerdings ohne deren Kernel) in den Partitionen installieren, was aber wiederum Arbeit bedeutet. Diese wird aber mit sogenannten Templates, vorkonfigurierten Grundgerüsten der jeweiligen Distributionen, vereinfacht.
Software-Virtualisierungsprodukte für Linux als Wirtssystem
