Definition: Xen-Hypervisor Xen, XenServer.og und Citrix

Die vier wichtigsten Hypervisoren im Virtualisierungsumfeld sind „VMware ESXi“, „Microsoft Hyper-V“, „Xen“ und „KVM“, wobei das initial im Jahr 2003 erschienene Xen mit Einführung der Paravirtualisierung seinerzeit einen technisch interessanten Weg einschlug, der gegenüber der Vollvirtualisierung mehr Performance versprach und das schwierige Problem der Ring-Priviligierung/Aliasing geschickt umging.

Anbieter zum Thema

Southern Tech GmbH

CITRIX Systems GmbH

Der Hypervisor Xen wurde als Open-Source-Projekt im Oktober 2003 auf dem 19. ACM Symposium on Operating Systems Principles der Öffentlichkeit präsentiert. Doch die Wurzeln von Xen reichen bis in die späten 90er Jahre und an die Universität Cambridge zurück. Hier entstand Xen ursprünglich im Rahmen des Forschungsprojekts „Xenoserver“. Xenoserver hatte zum Ziel, eine „öffentliche Infrastruktur“ für „Distributed Computing via WAN“ zur Verfügung zu stellen, das was man heute unter Cloud Computing versteht. Darum verwundet es auch kaum, dass Xen bei Amazon Web Services (AWS) und Rackspace zum Einsatz kommt.

Xen, Suse und Citrix

Nachdem die Xen-Entwickler mit XenSource ein kommerziell agierendes Unternehmen mit dem Ziel gegründet hatten, Xen als Industriestandard zu etablieren, war Xen viele Jahre ein nahezu konkurrenzloser Vorreiter. Das hatte allerdings zur Folge, dass sich mit beim parallel gepflegten Xen-Community-Projekt während dieser Zeit relativ wenig bewegte.

Insbesondere den Linux Kernel, Qemu und die Entwicklung um Red Red und KVM wurde lange vernachlässigt, so dass inzwischen der KVM-Hypervisor offizieller Bestandteil des Linux-Kernels wurde und nicht das ältere und ebenfalls eigentlich quelloffene Xen. Lediglich Suse pflegte von Beginn an eine Variante seiner Distribution, die auf den Xen-Hypervisor setzte.

Xen-Versionen

Mit der Übernahme von XenSource durch Citrix im Jahr 2007 wuchs die Xen-Community dann wieder, insbesondere seit Citrix sein XenServer-Management-Toolstack „Xap“ mit Xen.org wieder zurück an das Xen-Projekt übertragen hatte. Da der „XenServer“ von Citrix inzwischen ebenfalls frei verfügbar ist, besteht funktional im Grunde kein Unterschied, ob man das Produkt von Citrix oder xenserver.org bezieht.

Während ähnlich wie bei VMware die Produkt-Suite unter der Bezeichnung „XenServer“ firmiert (aktuell ist die Version 7.2) liegt der reine Xen-Hypervisor aktuell in Version 4.8 vor. Die Produkthistorie der 4´er – Version (4.9, 4.8,, 4.7, 4.6, 4.5, 4.4, 4,3, 4.2, 4.1) reicht zurück bis ins Jahr 2010 mit der Version 4.0. Davor gab es die Versionen 3.4, 3.3, 3.2, 3.1 und 3.0 (2005) sowie 2.0 (2004) und 1,0 (2003).

Die Xen-Technik

Technisch betrachtet war/ist der Xen-Hypervisor ein Virtual-Machine-Monitor (VMM), der zwischen Hardware und Betriebssystem eine Abstraktionsschicht stellt und im Gegensatz zur Vollvirtualisierung auf das Prinzip der Paravirtualisierung setzt, so dass ein Gastbetriebssystem, das unter Kontrolle des VMM laufen soll, angepasst werden muss und im Gegensatz zu ESXi über die Existenz des VMM Bescheid weiß. Im Unterschied zur Vollvirtualisierung al lá VMware, die den Einsatz unmodifizierter Gastbetriebssystemen erlaubt, wozu der ESXi-Hypervisor „problematische CPU“-¨ Instruktionen abfängt und emuliert (Trap and Emulator bzw. Binary-Translation), ist die von Xen eingesetzte Paravirtualisierung im Prinzip performanter.

Die IA-32-Architektur von Intel, für die Xen ja ursprünglich explizit entwickelt wurde, ist eigentlich nicht für Vollvirtualisierung ausgelegt, weshalb ESXi ja den beschriebenen Aufwand für Ring-Deprioviligierung und Ring-Aliasing treibt. Denn privilegierte Instruktionen können nur im privilegierten Modus (Ring 0) ausgeführt werden. Werden solche Instruktionen im unprivilegierten Anwendungs-Modus ausgeführt, wird ein Trap ausgelöst der vom Hypervisor abgefangen und „emuliert“ werden muss, etwa Zugriffe auf nur einmal vorhandene Hardware wie Timer, Memory Management Unit oder Interrupts.

Die X86-Architektur kennt 17 „kritische“ Befehle, die vom Hypervisor abgefangen und „emuliert“ werden müssen, da sie nicht virtualisierbar sind Bei einer vollvirtualisierten Prozessorarchitektur müssen allerdings sämtliche sensitiven Instruktionen laut Professor Medel Rosenblum auch privilegierte Instruktionen sein. Jedoch gibt es in der IA-32-Architektur einige sensitive Instruktionen die nicht privilegiert sind und auch als nicht kritische Instruktionen bezüglich der Virtualisierbarkeit bezeichnet werden. Es handelt sich um Instruktionen, die - werden sie in einer unprivilegierten Sicherheitsstufe ausgeführt - fehlschlagen, ohne einen Trap auszulosen und nicht vom VMM abgefangen werden.

Die Paravirtualisierung

Daher nutzt Xen Paravirtualisierung. Hierbei ist die bereitgestellte virtuelle Maschine der physischen Hardware nicht gleich in Bezug auf CPU und Memory, sondern nur „ähnlich“. Hierdurch ergeben sich zwar Performance-Gewinne im Vergleich zur Emulation/Vollvirtualisierung echter Hardware, diese sind aber mit dem Nachteil verbunden, dass ein Gastbetriebssystem bei Xen nicht unmodifiziert eingesetzt werden kann, wobei sich die Modifikation allerdings auf den Kernel des Gastes beschränkt, der Grund, warum Xen ursprünglich nur mit Linux verfügbar war.

Paravirtualisierung al lá Xen weist einige Besonderheiten auf: So ist die Trennung der Sicherheitsstufen zwischen Hypervisor, Gast-Kernel und Anwendung nicht so strikt wie bei VMware. Xen erlaubt nämlich mittels verschiedener Shared-Memory-Konzepte eine gewisse Aufweichung der strikten Trennung in vertikaler Richtung zwischen Hypervisor und Gast-Kernel, allerdings eine unmittelbare Abschottung der einzelnen Gastsysteme in horizontaler Richtung.

Hintergrund: Die IA-32 Architektur stellt bekanntlich vier Sicherheitsstufen (auch als Ringe bezeichnet) 0 bis 3 zur Verfügung, wobei Ring 0 die am höchsten privilegierte Sicherheitsstufe ist und Ring 3 die niedrigste Sicherheitsstufe, auf der Userspace-Anwendungen laufen. Der Kernel wird auf einem nativen IA-32-System stets in Ring 0 ausgeführt. Die Ringe 1 und 2 werden aus Portabilitätsgründen von den meisten Betriebssystemen nicht genutzt. Da aber Xen höher privilegiert sein muss, als die Kernel der Gastsysteme, die der Hypervisor ja voneinander abschotten muss, werden bei Xen die Gast-Kernel auf Ring 1 verschoben. Bei Xen spricht man auch nicht von virtuellen Maschinen oder Gastsystemen/Wirtssystem, sondern von „Domänen“.

Domänen in Xen

Virtuelle Maschinen für Gastsysteme heißen bei Xen also „Domänen“. Der allererste Gast läuft bei Xen stets in der Domäne „0“0 (Dom0), die eine gewisse Sonderstellung gegenüber den anderen Domänen aufweist. Diese heißen bei Xen DomUs (unprivilegierten Domänen). Die Dom0 wird auch als priviligierte Domäne bezeichnet und wird benötigt, weil Xen selbst im Gegensatz zu VMware keine Gerätetreiber oder Benutzerschnittstellen bereitstellt. Daher wird dem Betriebssystem in Dom0 Zugriff auf die dort vorhandenen Treiber und Benutzerschnittstellen von Xen erlaubt.

Somit ist auch die Treiberversorgung im Gegensatz zum monolithischen Kernel von VMware exzellent. In der Regel läuft hier ein Linux System, allerdings setzt Microsoft mit Hyper-V im Grunde die gleiche Technik auf Basis von Windows, was auf eine seit dem Jahr 2006 bestehende Kooperation von Xen und Microsoft zurück geht. Die wichtigste Aufgabe der Dom0 besteht aber im „Multiplexen“ der Gerätezugriffe aus den anderen Domänen und sich selbst. Daher dürfen auch aus Sicherheitsgründen nur so wenig wie möglich andere Dienste in der Dom0 ausgeführt werden.

Die Hardware Virtual Machines, HVMs

Seit 2006 nutzt allerdings auch der Xen-Hypervisor die CPU-gestützte Virtualisierung und läuft daher auch auf AMD64 oder IA-64 (Itanium)-Architekturen. Da sich nun - wie bei VMware aktuell auch - die CPU und die eigentliche Virtualisierung kümmert, laufen auf 64-Bit-Archituren nun auch unmodifizierte Gastsysteme, so dass sich unter Xen auch Windows-Gäste und unter Hyper-V Linux-Gäste einsetzen lassen.

Technisch basiert dies auf HVM (Hardware-Virtual-Machine), die Technik, die auch bei AWS zum Einsatz kommt. Seit die CPU-Hersteller Virtualisierungserweiterungen in ihre IA-32/AMD64-Prozessoren integrieren, kann also auch Xen unmodifizierte Betriebssysteme vollvirtualisiert betreiben. Bei so genannten HVMs läuft der Hypervisor dazu in einem noch hoher privilegierten Ring „-1“ und die Gast-Kernel im Ring 0. Allerdings besitzt ein unmodifiziertes Betriebssystem keine Unterstützung für Xens Split-Device-Treiber, weshalb Xen hier ausgewählte, vom Gast unterstützte Hardware- Komponenten genauso emuliert, wie das VMware tut.

Mit der hardwaregestützten Virtualisierung gleichen sich also die Hypervisoren vom VMware (ESXi) und Xen/Hyper-V technologisch betrachtet einander an. So sind zum Beispiel einige unter Xen einsetzbare Geräte wie eine NE2000-Netzwerkkarte nur auf diese Weise verfügbar, da deren Treiber-Quell-Code etwa aus dem QEMU-Projekt stammt, während VMware beispielsweise den Code zu einer E1000-Emulation mitbringt, für performantere Netzwerkkarten wie der synthetische VMXNET3 aber auf partielle Paravirtualisierung setzt.

Über den Autor

Thomas Drilling ist freier Autor und IT-Berater.

(ID:44784679)