Xen war ein Forschungsprojekt der Universität Cambridge. Das erste öffentliche Release wurde 2003 vorgestellt.

Das von Xen verwendete Virtualisierungsverfahren nennt sich "Paravirtualisierung". Dies bedeutet, dass das Guest-Betriebssystem modifiziert werden muss, um auf dem Host zu laufen. D.h. unter Linux benötigt man einen Xen-Kernel.

• Vorteile: sehr gute Performance
• Nachteile: da man einen speziellen Kernel benötigt, muss man Zugang zum Sourcecode des Betriebssystems haben. Für den Betrieb von Linux-Systemen ist das natürlich kein echtes Problem.

Neuere Linux-Kernel sind bereits Xen-kompatibel.

Die neuen Intel- und AMD-Prozessoren enthalten spezielle Befehle für die Virtualisierung (Intel-VT und AMD-V), so dass auf neuerer Hardware auch proprietäre und unmodifizierte Betriebssysteme wie Microsoft Windows virtualisiert werden können.

XenServer

Xen wurde 2007 für die Kleinigkeit von 500 Mio. USD an die Firma Citrix verkauft, die es unter dem Namen XenServer weiterentwickelt. Das aktuelle Release 5.5 ist kostenlos, man kann jedoch weitere Zusatzmodule und Support kaufen.

Xen oder VMWare?

Die Entscheidung, für die neuen Server XenServer 5.5 einzusetzen, hat drei Gründe:

• die gedownloadete Installations-CD funktionierte auf Anhieb.
• es gibt eine schöne Administrationssoftware
• XenServer hat für Citrix durchaus kommerzielle Aspekte; ich hoffe, dass es deswegen regelmäßig Bugfixes und neue Releases geben wird.

Installation auf dem Hetzner EQ 6 Server

Netzwerk-Installation

Es ist nicht ganz einfach, XenServer über das Rescue-System zu installieren. Mit folgendem Trick funktioniert es für XenServer 5.5 (mit einigen manuellen Eingriffen auch für XenServer 5.6):

• Inhalt der XenServer Installations-CD + Config-Datei auf WebServer installieren
• Ein beliebiges Linux mit Hilfe des Rescue-Systems installieren
• Kernel von XenServer Installations-CD installieren
• per grub menu.lst dem neuen Kernel die URL auf o.a. Webserver mitteilen

Der bootende XenServer-Kernel installiert dann das XenServer Grundsystem automatisch. Nach zwei, drei Minuten Wartezeit sollte man sich auf dem fertigen XenServer einloggen können.

Weitere Details hier:

• XenServer 5.6 FP1 unattended installation.
• http://wiki.hetzner.de/index.php/Xenserver_5.5:_Automatische_Installation,_sw_raid1,_lokale_ISO_library (man braucht nur den ersten Teil)

Alternativ:

Installation von CD

XenServer kann auch direkt von der CD installiert werden. Dies ist auch die einzige Möglichkeit, XenServer 5.6 zu installieren, da obige Methode nicht für 5.6. funktioniert. Man muss Hetzner den Downloadlink auf das ISO-Image zusenden, und der Support schließt dann für ein paar Stunden ein Remote-Modul und ein CD-Laufwerk an. Über ein Java-Applet kann man dann den Server von CD booten und alle Tastatureingaben remote durchführen. Dieser Service kostet € 25,- .

Während der Installation wird man nach einer optionalen Linux-CD gefragt. Diesen Punkt kann man überspringen, da man den Inhalt der CD bei Bedarf manuell nachinstallieren kann (iso-image nach /var/tmp kopieren, als filesystem mounten und das Installationsskript ausführen). Auf der Linux-CD ist ein für XenServer angepasstes Debian 4.0 enthalten, die XenServer-Standardinstallation enthält aber auch ein Template, um Debian 5.0 über's Netz zu installieren.

Die Installation enthält keine weiteren Überraschungen. Man benötigt die üblichen Daten wie Hostname, IP-Adressen usw. und kann angeben, ob man eine oder beide Platten als Repository konfigurieren möchte. Leider ist es nicht möglich, RAID zu konfigurieren. Ich habe hier nur die erste Platte (sda) ausgewählt: 1500 GByte reichen erstmal und evtl. konfiguriere ich später RAID1 manuell hinzu, oder nutze die zweite Platte für ein Backup. Bei Bedarf kann man nachträglich auch die zweite Platte ins Repository dazunehmen.

Nach dem Neustart wird die XenServer Console im Java-Applet des Remote-Moduls angezeigt, mit der sich der XenServer administrieren lässt. Die Console kann man natürlich auch (mit xsconsole) in einer ssh-Sitzung ausführen; es ist nicht erforderlich, das Remote-Modul ständig angeschlossen zu haben.

Am bequemsten lässt es sich jedoch mit dem XenCenter (ebenfalls kostenlos) arbeiten. Mit Hilfe dieser Windows-Software kann man über Templates verschiedene Linux- oder Windows-Distributionen installieren, "virtual machine" (VM) starten oder stoppen, kopieren, Snapshots erstellen, Boot-CDs einbinden und vieles andere mehr.

Netzwerkkonfiguration

Bevor es soweit ist, müssen jedoch noch Änderungen an der Netzwerkkonfiguration vorgenommen werden. Wenn man ohne weitere Konfigurationen eine neue virtual machine anlegt, wird man feststellen, dass die VM keinerlei Netzwerkverbindungen nach draußen bekommt. Das liegt daran, dass das Routing seitens des Rechenzentrumsbetreibers an die MAC-Adresse des Servers gekoppelt ist. Pakete, die nicht die richtige MAC-Adresse haben, werden nicht weitergeleitet, selbst wenn sie von der korrekten IP-Adresse kommen. Die virtual machines haben jedoch ein virtuelles Netzwerkinterface, was eine andere MAC-Adresse hat.

Damit es trotzdem klappt, braucht man den Server nur als Router betreiben. Alle Pakete werden dann von den virtual machines zunächst an den Server gesendet, der sie dann ihrerseits an den Router des Rechenzentrums weiterleitet, diesmal aber mit der physischen MAC-Adresse des Servers.

Host als Router konfigurieren

Der XenServer wird durch Änderungen in der Datei /etc/sysctl.conf als Router konfiguriert (die ersten paar Zeilen bis einschließlich net.ipv4.ip_forward = 0 durch die folgenden ersetzen):

# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

# Controls proxy arp
net.ipv4.conf.default.proxy_arp = 1

# Turn off redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
net.ipv4.conf.xenbr0.send_redirects = 0

Die Einstellungen sind nun nach jedem Neustart aktiv. Sie lassen sich aber auch ohne Neustart direkt mit dem sysctl -p Befehl anwenden:

# sysctl -p
net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
net.ipv4.conf.xenbr0.send_redirects = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
kernel.sysrq = 1
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 4294967295
kernel.shmall = 268435456
vm.dirty_ratio = 5
kernel.printk = 4 4 1 4

Die zweite nötige Änderung ist, die Firewall des Hosts abzuschalten. Den folgenden Befehl eingeben, "Security Level: disabled" auswählen und mit "OK" bestätigen.

# system-config-securitylevel-tui

Diese Einstellung ist ebenfalls dauerhaft und muss nach dem nächsten Neustart nicht wiederholt werden.

Konfiguration der zusätzlichen IP-Adressen

Ein Hetzner EQ x-Server hat vier eigene IP-Adressen, die alle im selben Subnetz liegen. Man braucht nun nichts weiter zu tun, als bei der Einrichtung der virtual machines die erste dieser Adressen (d.h. die IP-Adresse des Hosts) als Gateway anzugeben. Durch die Konfiguration als Router wird der Host alle von den Guests ankommenden Pakete an das RZ-Gateway weiterreichen.

Konfiguration einer Failover IP-Adresse

Eine Failover IP-Adresse ist eine Adresse, die auf einen beliebigen anderen physischen Hetzner-Server geschaltet werden kann.

Konfiguration eines zusätzlichen Subnetzes

In der Standardkonfiguration kann man also drei virtual machines gleichzeitig betreiben. Das ist nicht gerade viel, aber man hat die Möglichkeit, weitere IP-Adressen dazuzubestellen (das kostet einmalig € 49,- für max 30 IP-Adressen und monatlich € 15,- für das FlexiPack (Stand Sept. 2009)). Bei den älteren Hetzner-Servern DS X000 gibt es immerhin ein 29'er Subnetz mit 6 verwendbaren IP-Adressen kostenlos dazu.

Für ein zusätzliches Subnetz gilt im wesentlichen dasselbe wie oben. Eine IP-Adresse des Subnetzes fungiert als Gateway, die anderen kann man für die Guests verwenden.

Damit der Host auch weiß, dass er die packets aus dem Subnetz routen soll, weisen wir dem xenbr0-Interface die erste IP-Adresse aus dem Subnetz (hier xx.yy.177.160/27) zu:

# ip addr add xx.yy.177.161/27 dev xenbr0

Routing zu benachbarten Servern

Falls man mehrere Server gleichzeitig bestellt hat, die übereinander im Rack stehen und aufeinanderfolgende IP-Adressen haben, wird man feststellen, dass kein Ping oder ssh-Zugang zu den benachbarten Systemen möglich ist. Dies liegt daran, dass normalerweise alle Systeme im selben Subnetz ohne Gateway erreichbar sein sollten, aber bei Hetzner ist das aus Sicherheitsgründen nicht möglich. Die benachbarten Server sind nur über's Hetzner-Gateway zu erreichen. Die Routing-Konfiguration sieht so aus:

route add -net xx.yy.44.64 netmask 255.255.255.192 gw xx.yy.44.65 xenbr0

xx.yy.44.65 ist in diesem Fall die IP-Adresse des Hetzner-Gateways, um die IP-Adresse des gesamten Subnetzes zu erhalten, zieht man einfach 1 ab, was xx.yy.44.64 ergibt.

Diese beiden Befehle müssen nach jedem Neustart des Hosts ausgeführt werden, sonst bekommen die virtual machines keine Verbindung in die große weite Internet-Welt.

Konfigurationsbeispiel

Dem Server wurden seitens des Rechenzentrums folgende IP-Adressen zugewiesen: xx.yy.44.76, xx.yy.44.105, xx.yy.44.108 und xx.yy.44.110. Diese Adressen liegen alle im selben Subnetz xx.yy.44.64/26. Das für dieses Subnetz zuständige Gateway hat die Adresse xx.yy.44.65.

Die XenServer virtual machines bekommen also die IP-Adressen xx.yy.44.105, xx.yy.44.108 und xx.yy.44.110, als zuständiges Gateway wird xx.yy.44.76 eingetragen.

Das dazubestellte Subnetz mit 32 Adressen ist xx.yy.177.160/27 . Die erste und die letzte IP-Adresse sind nicht nutzbar, da es sich um die Subnetz- bzw. die Broadcast-Adresse handelt. Die IP-Adresse xx.yy.177.161 fungiert als Gateway, es stehen also 29 IP-Adressen für die Guests zur Verfügung: xx.yy.177.162 - xx.yy.177.191. Das Gateway für Guests in diesem Adressbereich ist xx.yy.177.161.

XenServer Updates installieren

Auf der Citrix Website gibt es einige wenige (z.Zt. 3) Patches, die man installieren sollte.
http://support.citrix.com/article/CTX124027

Zusätzliche Installations-CDs einbinden

Um Windows Server oder manche Linux-Distributionen zu installieren, ist zwingend eine Installations-CD erforderlich. Dazu lädt man die CDs bzw. DVDs in ein Verzeichnis hoch und gibt dieses als NFS-Share frei.

Ein NFS-Server lässt sich mit jeder Linux-Distribution in wenigen Minuten konfigurieren. Wie's gemacht wird, steht in dem Artikel NFS Server konfigurieren. Prinzipiell kann man die CDs auch direkt in den XenServer hochladen, der hat aber nur begrenzte Speicherkapazität zur Verfügung. Man kann übrigens auch eine eigene virtual machine mit entsprechend Plattenplatz einrichten und auf dieser den NFS Server konfigurieren.

Linux virtual machine auf XenServer installieren

XenServer 5.5 enthält zahlreiche Templates, mit denen man eine aktuelle Linux-Distribution installieren kann, unter anderem auch Debian, CentOS, Oracle Enterprise Linux, RedHat Enterprise und SuSE Enterprise Linux. Die Templates enthalten die optimalen Basiskonfigurationen, es ist aber auch möglich, eine beliebige andere Distribution wie z.B. Ubuntu direkt von CD zu installieren. Bei einem Root Server muss man dazu das ISO-Image der CD hochladen und kann es dann als virtuelles CD-/DVD-Laufwerk ansprechen.

Citrix GPG Key installieren

Falls auf einem Debian-System eine Fehlermeldung bzgl. eines fehlenden GPG-Keys auftritt:

W: GPG error: http://updates.vmd.citrix.com lenny Release: The following signatures couldn't be verified
because the public key is not available: NO_PUBKEY 841D6D8DFE3F8BB2
W: You may want to run apt-get update to correct these problems

dann sollte man folgendes Kommando ausführen:

# wget -q http://updates.vmd.citrix.com/XenServer/5.5.0/GPG-KEY -O- | apt-key add -
OK