Xen ist ein Hypervisor, also eine Software die den Betrieb mehrerer virtueller Maschinen auf einem physikalischen Computer erlaubt. Xen entstand an der Universität Cambridge und wird von dem Unternehmen XenSource weiterentwickelt. Xen wird unter Linux verwendet. Im Folgenden gibt es einige grundlegende Anleitungen zur Verwendung von Xen. Im folgenden werden verschiedene Befehle beschrieben. Da gewisse Parameter von Umgebung zu Umgebung abweichen können, sind diese in „< >“ eingeschlossen. Diese Parameter gilt es entsprechend zu ersetzen.

Xen ist unter SLES10 standardmäßig vorhanden. Falls es noch nicht installiert ist, kann in Yast2, unter der Sektion „Xen“, das entsprechende Softwarepaket installiert werden. Danach empfiehlt es sich den Bootloader neu zu konfigurieren. Im Bootloader sollten, nach der Installation von Xen, zwei neue Punkte verfügbar sein. Hier ist es sinnvoll den neuen Xen-Kernel unter dem Eintrag „Xen“ als Standard zu definieren. Nach einem Neustart, sollte sichergestellt werden, dass der Xen-Kernel gestartet wurde. Der Befehl

  uname –r

zeigt den verwendeten Kernel an. Hier sollte die Konsole „2.6.16.60-0.21-xen“ ausgeben. Die Versionsnummer kann natürlich abweichen, wichtig ist nur die „xen“ - Endung.

Beim Erststart des Xen Kernels muss in Yast2 der Punkt „Install Hypervisor and Tools“ aufgerufen werden. Danach sollten die Punkte „Create Virtual Machines“ und „Virtual Machine Manager“ verfügbar sein.

Es gibt zwei Möglichkeiten virtuelle Maschinen anzulegen. Entweder über die Konsole, oder über den Virtual Machine Manager. Da die grundlegende Erstellung einer Virtuellen Maschine in der Konsole sehr aufwändig ist und es zwischen den verschiedenen Betriebssystemen große Unterschiede in der Konfigurationsdatei gibt, ist es empfehlenswert den „Virtual Machine Manager“ zu benutzen. Der „Virtual Machine Manager“ kann über Yast aufgerufen werden. Um eine neue Maschine anlegen zu können, muss zunächst auf „localhost“ und dann auf „New“ geklickt werden. Der erste Schritt beschreibt allgemeine Informationen und kann mit „Forward“ abgeschlossen werden. Beim 2. Schritt ist zu entscheiden, ob ein OS installiert werden muss, oder ob eine Festplattendatei verwendet werden soll (Beispielsweise ein Backup einer alten Maschine, oder eine saubere Installation eines OS). Unabhängig davon was hier gewählt wird, muss als nächstes das Betriebssystem angegeben werden, das installiert werden soll bzw. installiert worden ist.

Der letzte Schritt sieht wie eine Zusammenfassung aus, ist aber die eigentliche Konfiguration:

Mit diesen Einstellungen würde die Installation nicht starten, da keine Installationsquelle ausgewählt wurde. Um das zu ändern, muss unter „Operating System Installation“ die Installationsquelle angegeben werden. Unter „Disks“ ist es möglich verschiedene Festplatteneinstellungen vorzunehmen. Etwa der Speicherort und die Größe der Datei. Beim Anlegen einer neuen Festplatte ist es auch möglich ein sogenanntes „Sparse Image File“ zu erstellen. Die Unterschiede zwischen „Sparse“ und „Preallocated“ sind unter 3.2.1 im Dokument erklärt. Weitere Einstellungen sollten selbsterklärend sein. Mit einem Klick auf OK wird die Maschine angelegt. Sie taucht dann im „Virtual Machine Manager“ mit einer eigenen ID auf. Der große Vorteil hierbei ist die komfortable und schnelle Erstellung der Virtuellen Maschinen. Der Hauptvorteil liegt aber in der Installation des Betriebssystems. Während man von Hand eigentlich zwei Konfigurationsdateien erstellen müsste (einmal für die Installation und einmal für den normalen Betrieb), nimmt der „Virtual Machine Manager“ diese Arbeit ab und startet die Installation komfortabel. Alle vom „Virtual Machine Manager“ erstellen Konfigurationsdateien sind unter

/etc/xen/vm/

zu finden. Die erstellten XML-Dateien sind dabei uninteressant.

Der xen-daemon verwaltet die virtuellen Maschinen. Grundsätzlich gibt es zwei Möglichkeiten eine erstellte Virtuelle Maschine zu starten:

xm create <Konfigurationsdatei>

Dieser Befehl startet die definierte Maschine ohne sie zur Datenbank des Daemons hinzuzufügen. Der Daemon kennt diese Maschine nur so lange, wie sie gestartet ist. Wird sie heruntergefahren, zeigt der Daemon diese Maschine auch nicht mehr an.

xm new <Konfigurationsdatei>

Dieser Befehl lässt den Daemon die definierte Konfigurationsdatei einlesen. Damit wird diese Virtuelle Maschine immer vom Daemon angezeigt, auch wenn sie ausgeschaltet ist. Wichtig: Der Daemon liest die Konfigurationsdatei bei einem Start nicht neu ein. Werden Änderungen in der Konfigurationsdatei vorgenommen, muss die Datei dem Daemon auch neu hinzugefügt werden:

xm delete <Maschinenname>
xm new <Konfigurationsdatei>

„xm delete“ löscht lediglich die Maschine des Daemons. Kein xm-Befehl löscht erstelle Konfigurationsdateien. Das Verhalten des Daemons ist jedoch nützlich und kann ausgenutzt werden um temporäre oder experimentelle Änderungen vorzunehmen. Wenn eine Maschine bereits dem Daemon hinzugefügt worden ist und eine experimentelle Änderung vorgenommen werden soll, empfiehlt es sich wie folgt vor zu gehen:

Zunächst muss die Virtuelle Maschine heruntergefahren werden. Anschließend werden die gewünschten Änderungen in der Konfigurationsdatei vorgenommen. Nun wird die Maschine gestartet:

xm create <Konfigurationsdatei>

Das birgt den großen Vorteil, dass die Konfigurationsdatei des Daemons nicht überschrieben wird. Wird die Maschine wieder heruntergefahren und mit dem Befehl

xm start <Maschinenname>

wieder gestartet, benutzt der Daemon die Konfigurationsdatei die ihm übergeben wurde und nicht die veränderte. Im Umkehrschluss bedeutet das aber auch, dass der Daemon Konfigurationsdateien nicht aktuell hält. Werden also über den „Virtual Machine Manager“ Änderungen vorgenommen, so wird nur die Datei des Daemons verändert, nicht aber die Konfigurationen in „/etc/xen/vm/“.

Eine Beispieldatei mit Erklärungen findet sich unter

  /etc/xen/examples/xmexample1

Die Konfigurationsdatei für eine Virtuelle Maschine könnte also so aussehen:

  name="new_vm"
  memory=512
  maxmem=512
  vcpus=2
  on_poweroff="destroy"
  on_reboot="restart"
  on_crash="restart"
  keymap="de"
  builder="linux"
  bootloader="/usr/bin/pygrub"
  disk=['file:/var/lib/xen/images/hdd,xvda,w']
  vif=[ 'bridge=br0', ]
  vfb=['type=vnc,vncunused=1']

Diese Kofigurationsdatei muss unter dem Pfad

/etc/xen/vm/<datei>

gespeichert werden. Es empfiehlt sich der Datei den gleichen Namen wie der Maschine zugeben. In diesem Fall also „new_vm“.

Zum Erstellen von Festplatten gibt es zwei Möglichkeiten. Ein sogenanntes „Sparse Image“ hat eine festgelegte Größe, wird aber dynamisch angelegt. Die Dateigröße wächst also mit dem Verbrauch bis zur festgelegten Größe an. Diese Methode sichert Speicherplatz, ist aber auch etwas langsamer als ein „Preallocated Image“. Bei solch einem Image wird die vorgegebene Größe sofort komplett verwendet. Dadurch dauert das erstellen des Images entsprechend länger, muss während dem Betrieb aber nicht mehr wachsen und ist dadurch schneller.

Erstellen eines „Sparse Image“

dd if=/dev/zero of=<dateipfad> bs=1M count=0 seek=<größe_in_mb>	

Erstellen eines „Preallocated Image“

dd if=/dev/zero of=file bs=1M count=size_in_mb

In der Konfigurationsdatei der Virtuellen Maschine muss der Parameter disk=[‘‘] angepasst werden. Der erste Parameter beschreibt die Art und den Ort des Mediums. Hier gibt es mehrere Möglichkeiten, im Folgenden sind zwei erklärt: Lokales Device einbinden:

phy:<dev>

Somit könnte eine Festplattenpartition oder ein Laufwerk eingebunden werden. Verwenden einer Festplattendatei oder eines Image:

file:<Pfad>

Hiermit können bereits erstellte Festplattendateien oder ISO-Images eingetragen werden. Mehr Möglichkeiten können im Virtual Manager eingelesen werden. Beim erstellen einer Festplatte gibt es eine DropDown-Liste „Protocol“ welche alle Möglichkeiten anzeigt.

Der zweite Parameter beschreibt den Namen der neuen Disk für die Virtuelle Maschine. „xvda“ kann durch beliebig andere Namen ausgetauscht werden. „xvd“ steht hierbei für „Xen Virtual Device“. Es empfiehlt sich jedoch auf die Linux Standards (hdX, sdX, …) zurückzugreifen. Der zweite Parameter beschreibt die Zugriffsart. Folgende Parameter sind möglich:

„r“	Nur Lesezugriff
„w“	Schreib-/ Lesezugriff
„w!“	Geteilter Schreib-/ Lesezugriff (shared image)

Beispiele zu den zwei Möglichkeiten:

disk=['file:/var/lib/xen/images/hdd,xvda,w', 'phy:/dev/sr0,xvdb,r‘]

Durch ein Komma getrennt können mehrere Disks definiert werden.

Auf Linux-Systemen können neue Laufwerke während des Betriebes hinzugefügt werden. Entweder über den „Virtual Machine Manager“ über „Details“ oder über die Konsole:

xm block-attach <dom-id> <dev> <dev-guest> <mode>

Beispiel:

xm block-attach 1 file:/mnt/data/hdd /dev/xvdb w

Die Syntax des Befehls ist also identisch mit der Syntax in der Konfigurationsdatei.

Hinweis:Es sollte auch hier beachtet werden, dass der Daemon dabei nur seine Konfigurationsdateien aktualisiert.

XEN stellt 2 Grundlegende Methoden zur Verfügung um einen Linux-VM zu starten. Zum einen gibt es die Möglichkeit das initrd und den Linux Kernel auf den DOM0 (XEN-Server) zu kopieren und in der Konfigurationsdatei die Pfade anzugeben. Ein Beispiel dazu:

name="new_vm"  
  kernel = "/etc/xen/vm/new_vm/vmlinuz-xen"    ###############
  ramdisk = "/etx/xen/vm/new_vm/initrd-xen"    ###############
  root = "/dev/xvda2"                          ###############
memory=512
maxmem=512
vcpus=2
on_poweroff="destroy"
on_reboot="restart"
on_crash="restart"
keymap="de"
builder="linux"
disk=['file:/mnt/data/sharedroot/shared,xvda,w!']
vif=[ 'bridge=br0', ]
vfb=['type=vnc,vncunused=1']

Die Zeile bootloader wurde entfernt und mit “###############” markierten Zeilen wurden hinzugefügt. Der root-Parameter beschreibt die Partition des Guests, auf der sich das root befindet.

Die zweite Möglichkeit ist der sogenannte „pygrub“-Bootloader. Dieser Bootloader greift lediglich auf die „menu.lst“ (gegebenenfalls manuell erstellen) des Guests zu und verwendet diese Einstellungen.

  name="new_vm"
  memory=512
  maxmem=512
  vcpus=2
  on_poweroff="destroy"
  on_reboot="restart"
  on_crash="restart"
  keymap="de"
  builder="linux"
  bootloader="/usr/bin/pygrub"
  disk=['file:/var/lib/xen/images/hdd,xvda,w']
  vif=[ 'bridge=br0', ]
  vfb=['type=vnc,vncunused=1']

Unter Suse gibt es noch eine Novellspezifische 3. Möglichkeit. Der sogenannte „domUloader“ benutzt vorgegebene Parameter um den VM zu starten. Auch hierzu ein Beispiel:

  name="new_vm"
  memory=512
  maxmem=512
  vcpus=2
  on_poweroff="destroy"
  on_reboot="restart"
  on_crash="restart"
  keymap="de"
  builder="linux"
  bootloader="/usr/lib/xen/boot/domUloader.py"
  bootargs="--entry=xvda1:/boot/vmlinuz-xen,/boot/initrd-xen"
  disk=['file:/mnt/data/sharedroot/shared,xvda,w!']
  vif=[ 'bridge=br0', ]
  vfb=['type=vnc,vncunused=1']

Zunächst wird die Konfigurationsdatei dem Daemon hinzugefügt:

xm new <dateiname>

Der Pfad muss nicht angegeben werden, es reicht der Dateiname. Virtuelle Maschinen die vom Daemon verwaltet werden können mit dem Befehl

xm start <name> [-c]

gestartet werden. Optional kann der Parameter c hinzugefügt werden, um sofort auf die neue Maschine zuzugreifen. In diesem Falle hat man auch Zugriff auf den Bootloader.

Live Migration beschreibt den Vorgang, eine virtuelle Maschine im laufenden Betrieb, von einem Hypervisor, zum anderen zu kopieren. Dafür sind logischerweise zwei Server nötig. Aus Performancegründen bietet es sich an, dass die Virtuellen Maschinen auf einem geteilten Storage gespeichert werden. Dies ist aber nicht zwingend notwendig. Um ein geteiltes Storage zu ermöglichen, wird ein bestimmtes Dateisystem benötigt (OCFS2 or NFS).

Das Network File System – abgekürzt NFS (auch: Network File Service) – ist ein von Sun Microsystems entwickeltes Protokoll, das den Zugriff auf Dateien über ein Netzwerk ermöglicht. Dabei werden die Dateien nicht wie z. B. bei FTP übertragen, sondern die Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen, als ob sie auf ihrer lokalen Festplatte abgespeichert wären. Die nachfolgende Installationsanleitung bezieht sich auf ein SLES10 System.

Bevor eine virtuelle Maschine migriert werden kann, müssen noch einige Vorbereitungen getroffen werden. Die Konfiguration des Xen-Servers muss abgeändert werden, da Live Migrationen aus Sicherheitsgründen standardmäßig deaktiviert sind. Die Konfigurationsdatei ist unter folgendem Pfad gespeichert:

/etc/xen/xend-config.sxp

Dort sind zwei Zeilen wichtig. Zum einen muss

(xend-relocation-server no)

auf „yes“ abgeändert werden. Zum anderen muss noch festgelegt werden, wer eine Verbindung zum Xend (Dom0) herstellen kann.

Das wird in folgender Zeile

(xend-relocation-hosts-allow XXX)

festgelegt. Beispiele sind in der Konfigurationsdatei vorhanden. Natürlich muss diese Datei auf beiden Servern abgeändert werden. Nach der Anpassung, kann mit folgendem Befehl eine Live-Migration durchgeführt werden:

xm migrate --live <domain_id> <target_host>

Beobachtet man nun den Virtual Machine Manager im <target_host>, sollte man erkennen können, dass dieser die Virtuelle Maschine angenommen hat, und den Arbeitsspeicher kopiert. Die Domain ID kann man im Virtual Machine Manager einsehen.

To install a vm on command line use:

xen-create-image --ui=text