Die Firma Hetzner bietet seit geraumer Zeit bei ihren Rootservern ein zusätzliches IP-Subnetz an, was im Preis enthalten ist. Damit ist es ohne weiteren Aufpreis möglich, auf einem physischen Rootserver mehrere virtuelle Instanzen laufen zu lassen. Bei den dafür benötigten Virtualisierungssoftware hat man (sofern sie vom Betriebssystem unterstützt wird) freie Wahl, allerdings gibt es deutliche Unterschiede in der Performance und im Preis. Für den (semi-)professionellen Einsatz bieten sich daher fast nur Xen und OpenVZ an. Letzteres ist jedoch ungeeignet, falls in den Gästen unterschiedliche Betriebssysteme zum Einsatz kommen sollen. Daher fiel die Wahl letztlich auf Xen.

Im Hetzner-Wiki existieren zwar schon einige Einträge zu Xen, allerdings noch kein komplettes Tutorial für (Open)SuSE, weswegen ich es für angebracht hielt, die bei der Einrichtung auftretenden Probleme und ihre Lösung einmal schriftlich zu fixieren.

In diesem Beispiel gehe ich von einem Rootserver aus, der die IP-Adresse 55.44.33.22 erhalten hat und einem zusätzlichen Subnetz mit den nutzbaren IP-Adressen 11.22.33.40-11.22.33.45. Diese sind jeweils an die eigenen Adressen anzupassen.

Die Grundinstallation

Für die Installation gehe ich von einer Neuinstallation aus, da hier die benötigte Partitionierung und Systeminstallation direkt wie gewünscht eingerichtet werden kann. Alternativ kann natürlich auch ein bereits installiertes System “xenifiziert” werden. Da hier jedoch standardmäßig die erste Festplatte belegt ist muss man den Platz anders einteilen, oder statt dem hier verwendeten LVM-Setup Containerdateien benutzen.
Die einzelnen Schritte der Installation möchte ich nicht erneut erläutern, dafür gibt es jede Menge Tutorials im Netz.
Hier aber noch einmal eine Übersicht der wichtigsten Schritte:

  • Im Hetzner-Robot startet man eine VNC-Installation (hier SuSE 10.3). Bei mehr als 3 GB RAM sollte man hier 64Bit wählen, ansonsten kann man auch die 32Bit-Variante nutzen. Anschließend findet man auf der Seite ein Install-Passwort, was man sich besser kurz notiert.
  • Der Server muss nun neu gestartet werden: Entweder über das Reset-Interface im Robot oder (sofern man noch einen Root-Zugang hat) per reboot. Der Server startet nun neu und holt sich beim Booten per DHCP das Installationsimage.
  • Nun benötigt man einen VNC-Client (unter Linux standard, unter Windows etwa per TightVNC). Nach ein paar Minuten sollte der Server via VNC erreichbar sein. Man erreicht ihn dann unter vnc:/55.44.33.22:1
  • Bei der Partitionierung sollte man auf genug Platz für die virtuelle Maschinen achten. Eine Möglichkeit besteht etwa dadrin, je eine Swap- und Root-Partition als primäre Partition zu erstellen und den Rest der Festplatte(n) mit LVM zu nutzen.
  • In der Softwareauswahl sollte man in jedem Fall die folgenden Pakete anwählen: kernel-xen, xen, xen-libs,xen-tools
  • Die Bootloaderkonfiguration muss den MBR-Code überschreiben, falls vorher noch kein Grub auf dem Rechner installiert war. Das sollte man auf jeden Fall machen.
  • Nach fertiger Installation muss man sicherstellen, dass auch Xen gebootet wird. Dafür editiert man die Datei /boot/grub/menu.lst und achtet darauf, dass die Option default auf die Abschnittsnummer des Xen-Abschnitts gesetzt wird. Die Nummerierung fängt übrigens bei 0 an.
  • Jetzt bootet man den Server neu (reboot) und meldet sich als Root an. Ein uname -r zeigt an, welcher Kernel gestartet wurde. Hier sollte etwas mit xen erscheinen, also bspw.  2.6.22.13-0.3-xen

Das Netzwerk vorbereiten

Nachdem die Standardinstallation erfolgreich beendet wurde muss das Netzwerk konfiguriert werden.
Leider erlaubt Hetzner das in Xen standardmäßig verwendete Bridged-Setup nicht. Hierbei würde jeder virtuelle Gast eine eigene MAC-Adresse erhalten und die physische Netzwerkkarte würde im Promiscious-Mode für alle Xen-Domänen (inkl. Dom0) Pakete verarbeiten.
Die von Hetzner favorisierte Methode ist das Routed-Setup, bei dem die Dom0 als Router fungiert und die Pakete der DomUs rein- und rausroutet.
Leider verliert man bei diesem Ansatz eine IP-Adresse und kann damit weniger virtuelle Instanzen betreiben.
Die Funktionsweise lässt sich in etwa so beschreiben: Die Dom0 benutzt eine der IP-Adressen (hier 11.22.33.40), um auf einem internen Xen-Netz mit den DomUs zu kommunizieren. Diese erhalten jeweils eine der Adressen aus dem Zusatzsubnet (also 11.22.33.41-11.22.33.45) und routen ihre gesamten Pakete über die Dom0.
Dafür muss man der Dom0 beibringen, dass sie IP-Traffic routet und zusätzlich die Brücke zwischen Dom0 und DomU einrichten.
Fangen wir erstmal mit der Routing-Konfiguration an. Dazu öffnet man die Datei /etc/sysctl.conf mit einem Texteditor:

vi /etc/sysctl.conf

Hier fügt man dann die beiden folgenden Zeilen ein:

net.ipv4.ip_forward=1
net.ipv4.conf.default_proxy_arp=1

Als nächstes konfiguriert man das Netzwerk-Setup von Xen von Bridged auf Routet-Mode. Dazu muss man die Datei /etc/xen/xend-config.sxp bearbeiten und folgende Zeilen ein- bzw auskommentieren:

#(network-script network-bridge)
#(vif-script vif-bridge)
(network-script network-route)
(vif-script     vif-route)

Damit ist der Xen-Daemon angewiesen, DomU-Netzwerke mit seinem internen Xen-Netz zu verbinden anstatt sie direkt nach aussen zu bridgen.

Zu guter Letzt müssen wir noch einen wichtigen Schritt erledigen: Damit die Dom0 auch mit dem Xen-Netz kommunizieren kann, braucht sie ein neues (virtuelles) Ethernet-Interface.
Dazu benutzt man einfach das dummy-Kernelmodul. Zu Testzwecken kann man erstmal die folgenden Zeilen in einer Root-Shell eintippen:

modprobe dummy
ifconfig dummy0 11.22.33.40 up

Damit hat man das dummy-Module geladen und ihm anschließend die IP des Xen-Netz-Routers zugewiesen.
Um die Änderungen permanent zu machen bemüht man am besten wieder YaST und erstellt damit ein neues Netzwerk-Interface. Dem weist man dann einerseits das dummy-Modul als Treiber zu und andrerseits die obige IP. Damit sollten die Einstellungen dann auch einen Neustart der Dom0 überdauern.

Damit ist das Setup der Dom0 fast fertig, bleibt nur noch der Neustart des Xen-Daemon (oder alternativ des gesamten Servers), damit die Netzwer-Änderungen übernommen werden:

/etc/init.d/xend restart

Jetzt ist die Dom0 inkl. Netzwerkanbindung eingerichtet und wir können uns dem spannenden Teil zuwenden: Die Installation neuer Gäste! :)

Einrichten der Gäste

Hat man das obige Setup durchlaufen ist es jetzt an der Zeit, die Gäste (DomUs) anzulegen. Da Xen in SuSE schon länger enthalten ist gibt es für deren Installation bereits vernünftig funktionierende Tools (in YaST), allerdings ist immer noch Handarbeit angelegt.
Zunächst sollten wir die zukünftige Root-Partition der DomU mounten. Ist sie wie oben angegeben als LVM-Volume vorhanden und partitioniert macht das folgender Befehl (wobei xen1 die LVM-Group und root der Volume-Name darstellt):

mount /dev/xen1/root /mnt

Jetzt startet man das YaST2-Module “Installation in Verzeichnis”. Das erledigt die Grundschritte der normalen Installation: Auswahl und Installtion von Software. Die Paketauswahl sollte man seinen Bedürfnissen anpassen, alternativ kann man das auch später erledigen.
Hinweis: Man sollte die Option “YaST und SuSEconfig nach dem ersten Systemstart ausführen” auf ja setzen, ansonsten muss man sich um die Basiseinrichtung komplett selbst kümmern.

Leider macht der Dirinstaller von YaST noch nicht alles automatisch, weswegen wir folgende Befehle manuell nachholen müssen. Bitte nur die Befehle ohne führende # eintippen, die sind Kommentare:

#Ins gemountete Verzeichnis wechseln:
cd /mnt
#Alle für den Bootvorgang wichtigen Dateien kopieren
cp /boot/*xen* ./boot
#Die Module für den aktuellen Kernel kopieren (UNBEDINGT HINWEISE BEACHTEN!)
cp -ax /lib/modules/`uname -r` ./lib/modules
#Die Root- und Swappartition eintragen
echo -e "/dev/hda1  swap  swap  defaults  0 0 \n /dev/hda2  /  ext3  acl,user_xattr   1 1" > ./etc/fstab
#mtab entfernen
rm -f ./etc/mtab
#inittab konfigurieren
sed -ie "s/^[2-6]:/#\\0/" ./etc/inittab
#Terminal-Problem beheben (Xen 3.0.4+)
sed -ie "s/\(^1:.*\)tty1/\1xvc0/" ./etc/inittab
echo "xvc0" >> ./etc/securetty

Hat man alles installiert, dann löst man die Laufwerkseinbindung des Root-Images mittels

umount /mnt

Nun wird es Zeit, die DomU in Xen zu konfigurieren. Dazu generiert man unter /etc/xen/vm eine Datei mit dem Namen der DomU und öffnet die mit einem Texteditor. Also bspw. so:

vi /etc/xen/vm/test

Diese Datei kontrolliert, was die DomU für Hardware erhält, wo ihre Festplatten liegen und (ganz wichtig) mit welchem Kernel sie gestartet werden soll. Das folgende Listing zeigt eine Beispielkonfiguration und erklärt kurz die genutzten Optionen.

#  -*- mode: python; -*-

#Name der DomU
name="test"
#RAM der DomU (in MB)
memory=1224
#Der Kernel. Kann für SuSE so gelassen werden
kernel="/boot/vmlinuz-xen"
ramdisk="/boot/initrd-xen"
#Von welcher virtuellen Platte soll die DomU booten?
root="/dev/hda2"
#Nur bis Runlevel 3 booten und das Terminalproblem beheben
extra="3 console=xvc0"
#Die virtuellen Festplatten: hda1 ist swap und hda2 ist root. Dabei bedeutet phy dass die Festplatte als normales Blockdevice existiert
disk=['phy:/dev/xen1/swap,hda1,w','phy:/dev/xen1/root,hda2,w']
#Das Netzwerk wird deroutet. ip ist die Adresse, die die DomU erhalten soll (aus dem Subnetz)
#mac muss unbedingt auf der MAC-Adresse der physischen Karte stehen
vif=['ip=11.22.33.41,mac=00:11:22:33:44:55']

Übrigens: Falls man möchte, kann die DomU auch bei jedem Serverneustart automatisch mitgestartet werden. Damit sichert man insbesondere bei Stromausfällen, dass die DomU nicht gestoppt bleibt. Dazu verlinkt man die Konfigurationsdatei einfach nach /etc/xen/auto:

ln -s /etc/xen/vm/test /etc/xen/auto/test

Und jetzt ist es soweit: Wir können die virtuelle Maschine starten. Dazu (und für viele weitere Xen-Operationen) benutzt man das Kommando xm. Zunächst starten wir die Maschine und schauen uns die Ausgabe (also das der DomU zugeordnete Terminal) direkt an.Das geht so:

xm create test -c

Jetzt sollte der Startvorgang der DomU wie bei einem physischen Rechner zu sehen sein und nach einiger Zeit sollte YaST austauchen (zur Erinnerung: Wir haben ja beim Dirinstall darum gebeten, dass YaST nach dem ersten Start ausgeführt wird). Die restlichen Einstellungen erledigt man nach eigenem Gutdünken.
Hinweis: An mindestens einer Stelle erhält man Fehlermeldungen im Zusammenhang mit Netzwerk. Das liegt daran, dass die DomU noch keine vernünftige Netzwerkkonfiguration erhalten hat und deswegen nicht auf die Software-Repositories zugreifen kann. In diesem Fall immer Überspringen o.ä. benutzen!

Ist das Basis-Setup durchgelaufen wird man (hoffentlich) mit einem Login-Screen belohnt. Hier meldet man sich erstmal als root an (mit dem gerade gesetzen Passwort der DomU, nicht der Dom0) und konfiguriert das Netzwerk:

yast2 lan

Dort sollte man einen Adapter namens “Xen Virtual Ethernet Card” vorfinden, den man nun mit folgenden (jeweils angepassten Werten) konfiguriert:

Konfigurationsart: "Statisch zugewiesene IP-Adresse"
IP-Adresse: "11.22.33.41" (ANPASSEN!)
Subnetz-Maske: "255.255.255.248"

Ein Klick auf weiter bringt einen wieder zurück zur Übersicht. Jetzt wählt man zuerst den Registerreiter “Hostname / DNS” und gibt folgende Werte ein (sind derzeit aktuelle):

Nameserver1: "213.133.98.98"
Nameserver2: "213.133.99.99"
Nameserver3: "213.133.100.100"
Hostname/Domänenname: Optional

Jetzt wechselt man weiter zum Tab “Routing” und gibt dort die Routing-Adresse aus dem Subnetz ein. In unserem Fall ist das also die 11.22.33.40.

Wichtig: In den meisten Fällen muss man an dieser Stelle noch die Checksummen-Kontrolle deaktivieren. Sonst kommt es evtl. zu schlechter Netzwerk-Performance. Da dieses Problem aber nicht immer gegeben ist habe ich es in die Hinweise integriert.

Schlußwort & Hinweise

Damit sind wir nun am Ende der Installation der ersten DomU. Ich hoffe es hat alles soweit geklappt, falls Fehler im Howto vorhanden  oder bestimmte Dinge unklar formuliert sind bitte ich um eine kurze Meldung.
An dieser Stelle möchte ich aber noch ein paar wichtige Hinweise geben:

  • Kernel: Der verwendete SuSE-Kernel ist sowohl für Dom0 als auch DomU gedacht. Das erspart einem natürlich den Aufwand, mehrere Kernelversionen verwalten zu müssen. Allerdings muss man bei Kernelupdates unbedingt darauf achten, dass man in den DomUs die Kernel mit aktualisiert. Ansonsten findet Xen bspw. das Modules-Verzeichnis des neuen Kernels nicht in der DomU und kann diese deswegen nicht starten. Dann muss man erst wieder umständlich die virtuelle Root-Partition mounten und die Module manuell hineinkopieren. Deswegen mein Tipp: Immer erst die DomUs updaten, bevor man die Dom0 aktualisiert.
  • Dom0: Im besten Fall sollte auf der Dom0 kein Server-Dienst ausser den von Xen benötigten laufen. Allgemein reicht dafür eine sehr geringe Ausstattung (256MB RAM max.). Die Funktionalität sollte man aus Sicherheitsgründen besser in die DomUs verlagern.
  • DomU-Netzwerk: Teilweise kommt es bei diesem Setup in Xen zu Netzwerkproblemen, die sich durch langsame oder fehlerhafte Verbindungen auszeichen. Ein Beispiel: Beim Laden einer Website von einem Webserver in der DomU vergehen Minuten oder man muss sogar die Seite neu laden, bevor sie angezeigt wird.
    Bei mir hat sich das Problem durch Ausschalten der Checksums mit folgendem Befehl erledigt:

    ethtool -K eth0 tx off

    Wenn sich durch diese Einstellung tatsächlich eine Verbesserung auftritt (in den meisten Fällen sollte das so sein), dann sollte man die Änderungen permanent machen.
    Dazu bearbeitet man die Datei /etc/sysconfig/network/ifcfg-eth0 (dies gilt für SUSE 10.3-Gäste mit einem Netzwerk-Interface, sonst anpassen) und ändert folgende Zeile:

    ETHTOOL_OPTIONS='-K eth0 tx off"

    (Sollte die Zeile vorher nicht leer gewesen sein entsprechend anhängen. eth0 ggf. anpassen!)

  • Eintrag in sysctl.conf: Ich habe den Hinweis bekommen, dass das Eintragen von net.ipv4.* nicht nötig ist, weil das network-router Skript diese Optionen automatisch setzt. Da ich das bisher nicht testen konnte setze ich das als Hinweis dazu.
  • VM-Installation mit YaST: In YaST gibt es zwar auch die Möglichkeit, eine Konfiguration einer DomU vorzunehmen, allerdings habe ich dazu den Hinweis bekommen, dass das in diesem Setup nicht funktioniert, weil YaST defaultmäßig immer das bridged-Setup nutzt und keiner Änderungen zulässt.
  • Starten mit domUloader.py: Noch ein Hinweis in einer Zuschrift: Man kann in der Xen-Config auch das Skript domUloader.py als Bootloader benutzen, indem  man die folgenden beiden Einträge statt Kernel und Ramdisk nutzt: 
    bootloader = '/usr/lib/xen/boot/domUloader.py'
bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen'

    Das domUloader.py-Skript extrahiert den Kernel aus der DomU und sorgt somit für fehlende Versionskonflikte.
    Auch diesen Hinweis habe ich leider noch nicht testen können, aber fehlen darf er ebenfalls nicht. Danke an den Autor!