24.2 Xen-Philosophie 

Um die technische Basis von Xen in seiner Gesamtheit zu verstehen, ist es überaus hilfreich, sich die Prinzipien dieser Virtualisierungslösung näher anzusehen. Prinzipiell haben wir es bei der Philosophie von Xen mit zwei Dogmen zu tun, auf die ich im Folgenden näher eingehen werde.
24.2.1 Grundlegende Trennung 

Xen vollzieht eine grundlegende Trennung zwischen den Richtlinien, den sogenannten Policys, und den eigentlichen Mechanismen, wie der Zugriff geregelt wird. Es ist wichtig für das Verständnis, dass der Xen-Hypervisor zwar die Mechanismen für den Hardwarezugriff bereitstellt, die Rechte dazu aber bei den Gästen liegen.
Hypervisor: Ein Hypervisor oder Virtual Machine Monitor (VMM) ist eine Virtualisierungssoftware, die eine Umgebung für virtuelle Maschinen schafft. Es werden zwei Arten von Hypervisoren unterschieden: Typ 1 läuft ohne weitere Software direkt auf der Hardware, Typ 2 setzt auf ein vollwertiges Betriebssystem auf. Der Begriff kann sinngemäß als Aufseher übersetzt werden (Hyper, griech. für »über« und Visor, lat. für »der Sehende«). |
Genauso unterstützt Xen keine Geräte direkt, sondern gibt den Gästen einen Mechanismus an die Hand, durch den sie Zugriff auf die reale Hardware erhalten. Dadurch ist es möglich, dass die Xen-Gäste vorhandene Treiber für die Geräte nutzen. Wenn mehrere virtuelle Maschinen gleichzeitigen Zugriff auf ein Gerät benötigen, stellt der Hypervisor lediglich eine Art der Speicherverwaltung zur Verfügung – den Mechanismus.
24.2.2 Weniger ist mehr 

Im Gegensatz zu den meisten anderen Softwareprojekten versucht Xen bei jeder neuen Veröffentlichung weniger zu tun als bei der vorherigen. Der Grund besteht darin, dass Xen als ein sehr sensibler Teil Ihres Systems fungiert. Es hat sogar mehr Privilegien als das Betriebssystem und dementsprechend auch mehr Risiken.
Um das zu verstehen, müssen Sie sich vor Augen halten, dass
- ein Programmfehler eventuell nur Auswirkungen auf die Daten dieses Programmes hat,
- ein Fehler im Betriebssystem aber das ganze System lahmlegt und schließlich
- ein Fehler in Xen Auswirkungen auf alle virtuellen Maschinen hat.
So schlank wie möglich
Daher ist es nachvollziehbar, dass der Xen-Code so schlank wie möglich sein darf. Es ist damit die berechtigte Hoffnung verbunden, dass ein schlanker Code generell weniger Fehler enthält. Der Xen-Kernel enthält übrigens ungefähr 40.000 Zeilen. Verglichen mit einem klassischen Linux-Kernel (Version 2.6 hat ungefähr 5,9 Millionen Zeilen) ist ein Xen-Kernel äußerst schlank.
Ein Beispiel des Prinzips »Weniger ist mehr« ist das Bridging und Routing von Netzwerkgeräten. Ich werde auf diese Techniken später in den Abschnitten »Bridged Network«, und »Routed Network« näher eingehen. In der ersten Version von Xen waren diese Techniken noch fester Bestandteil des Hypervisors. In der Folgezeit stellte sich allerdings heraus, dass neue Implementierungen in den Betriebssystemen das Routing und Bridging effizient übernehmen konnten, und so wurden beim Übergang zu Xen 2.0 diese in den Host (Domain 0) verlagert.
Die Verlagerung von Funktionen in Domain 0, also den Host, oder das Zurückgreifen auf dessen Tools hat einen weiteren gewichtigen Aspekt, den Sie nicht außer Acht lassen sollten. Jeder Administrator (und auch jeder »Normalsterbliche«) hat nur eine begrenzte Zeit zur Verfügung. Da ist es von Vorteil, wenn er nicht beständig den Umgang mit neuen Programmen erlernen muss. Stellen Sie sich nur einmal vor, wie es wäre, wenn Xen seine eigene Definition der iptables hätte.