[[xen:xen]]

Xen

Xen ist eine ausgereifte Lösung um Betriebssysteme mit wenig Leistungsverlust (overhead) zu virtualisieren. Wichtige Distributionen wie Debian, Ubuntu und Suse haben es integriert.

Siehe auch: Vorteile von Virtualisierung.

Xen bietet Paravirtualisierung oder Vollvirtualisierung an.

Bei der Paravirtualisierung wird nicht komplett virtualisiert (wie z.B. bei vmware) sondern viele Befehle werden direkt ausgeführt. Das soll eine nahezu Verlustfreie Ausführung (nur wenige Prozent gegenüber deutlich spürbaren Verlusten bei vmware) bringen. Das Betriebssystem ist schon auf eine Virtualisierung angepasst, also muss nichts mehr simuliert werden.

Gast-Betriebssysteme lassen sich leicht und schnell auf einen anderen Server verschieben = live-migration. Die Ausfallzeit ist dabei minimal.

Außerdem unterstützt es suspend und resume von Gast-Betriebssystemen.

  • Warum müssen Gastsysteme (bei der Paravirtualisierung) angepasst sein?

Moderne Betriebssysteme erwarten auf Ring 0 des Prozessors zu arbeiten (wo jetzt Xen arbeitet bzw. überwacht), daher muss das Betriebssystem an Xen angepasst sein, da in jedem Fall eine abstrahierende Schicht zwischen der Hardware und den Gastsystemen (überwacht durch den Hypervisor) eingezogen wird. Nur wenn man aktuelle Hardware benutzt, genauer Prozessorerweiterungen, brauchen die laufenden Betriebssystem keine Anpassung, da diese Erweiterungen dann einen zweiten (weniger priviligierten) Ring 0 zur Verfügung stellen. Glücklicherweise sind aktuelle Prozessoren schon seit einiger Zeit mit diesen Erweiterung erhätlich. Allerdings erwartet ein unangepasstes Betriebssystem natürlich auch direkten Hardwarezugriff auf Netzwerkkarten, Festplatten usw. den ihm Xen nicht zur Verfügung stellt. Zur Lösung diese Problems greift Xen auf Treiber von Qemu zurück, dabei funktionieren aktuell aber Live-migration, Suspend und Resume nicht.

Wenn ein Hypervisor (mangels o.g. Prozessorerweiterungen) erforderlich ist, ist man aktuell als Gast auf Linux, FreeBSD oder Solaris beschränkt.

Mit den entsprechenden Prozessorerweiterungen ist es möglich mittels Vollvirtualisierung auch unangepasste Gäste (wie Windows) laufen zu lassen. Dabei werden die Treiber von Qemu benutzt. Wenn die CPU nicht geeignet ist, wird die Erstellung von von vollvirtualisierten Gästen mit der folgenden Fehlermeldung scheitern:

Error: HVM guest support is unavailable: is VT/AMD-V supported by your CPU and enabled in your BIOS?

Xen unterscheidet privilegierte (sog. Domäne-0) und unprivilegierte Domänen, d. h. virtuelle (Gast-)Systeme. Die Domäne-0 hat die volle Kontrolle über das System und die anderen Gast-Domänen. Deshalb sollte sie auch unbedingt abgesichert (=gehärtet) werden.

  • live-migration: das nahezu unterbrechungsfreie Verschieben von Gastsystemen
  • privilegierte (sog. Domäne-0 oder Dom0): Ein minimal-System zur Verwaltung der Gäste
  • suspend / resume: das Anhalten und Wiederaufnehmen von Gastsystemen
  • unprivilegierte Domänen (DomU), d. h. virtuelle (Gast-)Betriebbssysteme
  • Hypervisor: Überwachungsschicht von Xen, ein sog. Virtual Machine Monitor (VMM)

Bei der live-migration wird der Arbeitsspeicher kopiert, die Daten auf der Festplatte müssen in einer entsprechenden Speicheranbindung (shared storage) liegen. Das Kopieren der Festplattendaten würde zu lange dauern und damit zu einer merkbaren Ausfallzeit führen. Während der Migration ist das System zwischen 50 bis 100 ms nicht erreichbar.

Eine zweite Möglichkeit ist die offline-Migration, hier wird die DomU kurzzeitig angehalten und auf dem neuen Server wieder gestartet.

  1. eine live-migration momentan nicht über Kollisionsdomänen (über Router) hinweg möglich, da die virt. Maschinen ihre MAC-Adressen mitnehmen.
  2. Prozessor (32/64-Bit, Prozessorerweiterungen wie MMX) und Speichermodell (z.B. PAE) müssen identisch sein
  3. die Virtuellen Maschinen müssen auf einem Massenspeicher liegen, auf die auch beide physikalische Maschinen (schreibend!) zugreifen können müssen (z. B. ein NAS, SAN, NFS oder ein Network Block Device. Alternativ geht auch drbd 8.0.12 und Xen
  4. der Xend-relocation-Server bietet keine Authentifizierung, man kann nur die erlaubten Quellhosts über die Option xend-relocation-hosts-allow beschränken.

:!: Es muss auf dem Zielsystem genug Speicher vorhanden sein.

Hypervisor Xen 3.3.0 steht zum Download bereit

Die folgenden Probleme müssen aktuelle nicht mehr bestehen, da die Entwicklung von Xen sehr schnell vorran schreitet.

  • wichtige Überlegungen: sollen bestimmte VMs auf dem gleichen physikalischen Rechner laufen? (externe / interne Firewall?) Lösung: shype
  • Zugriff auf gleiche Ressourcen: (nicht Clusterfähige) Dateisysteme auf die gleichzeitig geschrieben wird
  • Trusted Computing geht nicht, Lösung ist vTPM also virtualisiertes TPM durch einen Cluster von TPM-Modulen
  • Es sind (bisher) keine Snapshots auf Xen-Ebene möglich (Lösung: LVM-Snapshots)
  • USB 2.0 ist nicht unterstützt (Stand 03/2007 könnte evtl. gefixt sein)
  • der Speicher des Images sollte von der VM nicht über Netzwerk angesprochen werden müssen, SAN o.ä. sind ok.
  • Hauptspeicher (der Gäste) kann nicht dynamisch zugeteilt werden. Die Dom-0 kann mit xm mem-set angepasst werden.
  • Trennung der Netzwerkfunktionen durch Custom Bridges
  • Device Driver Domain (nicht Xen paravirtualisiert eine einzelne Hardware sondern einer der Gäste, falls man im Treiber eine Kompromittierung der Dom0 befürchtet)
  • shype (s.u.)

Vortrag Xen-Sicherheit + Folien.

shype ist ein von IBM entwickeltes Mandatory Access Control -System, auch ACM).

shype erreicht eine Trennung von Reference Monitor und Access Control Policy und folgt der FLASK-Architektur (siehe IT-Sicherheit in verteilten Systemen - Kapitel 4: Sicherheitsarchitekturen und Sicherheitsinfrastrukturen).

Es ist standardmäßig nicht einkompiliert (kompilieren mit ACM_Security=yes) mit GUI: xensec_ezpolicy oder xensec_gen. Wenn Verzeichnis /etc/xen/acm-security/ existiert, ist das ACM bereits enthalten.

Paravirtualisierte Treiber für Windows sind bei XEN Enterprise dabei, für SLES gibt es diese optional zu kaufen.

  • angepasste Treiber für Windows: Novell (Virtual Machine Driver Pack) und XenSource (XenSource Windows Tools); nicht kostenlos erhältlich.
  • Physical-to-Virtual (P2V) Migration: Wandelt physikalisch vorhandene Server in eine virtuelle Maschine um.
  • Virtual Disk Migration Utility (V2V): Konvertiert VMWare-Images zu XVA (Xen Virtual Appliance)-Images

Ein mit Xen angepasstes Knoppix

Xenoppix started mit automatischer Hardware-erkennung und aktiviert dann ein Gast-Betriebssystem (Plan9, NetBSD oder Xenoppix selbst) über X11 und VNC-Fullscreen.
Der Gast kann als Server arbeiten, da er eine IP über externes DHCP bekommt.

http://unit.aist.go.jp/itri/knoppix/xen/index-en.html

EisXen ist eine spezielle Xen-Distribution, die eine schnelle Einrichtung eines Xen-Servers erlaubt.