Virtualisierung mit XEN
Prinzipiell gibt es bei Xen zwei unterschiedliche Domains: Die Domain 0 existiert immer und stellt den anderen, unprivilegierten Domains (Domain U (unprivileged, da kein direkter HW-Zugriff erfolgen kann) Betriebsmittel wie Speicher oder Platten zur Verfügung. In diesen Domains läft jeweils ein modifizierter Kernel der für die jeweilige Umgebung angepaßt wurde. Es ist aber auch möglich einen Kernel zu kompilieren, der gleichzeitig Support für beide Typen beinhaltet. Auf diese Weise ist es z.B. bei Open SuSE 10.1 gelöst, die als Basis für den folgenden Artikel diente.
Installieren von Xen
linux ~# apt-get install xen kernel-xen kernel-xen-nongpl oder: linux ~# smart install xen kernel-xen kernel-xen-nongpl
Um den Xen Kernel mit Linux zu booten kopiert man die bisherige Grub Konfigurationsdatei (/boot/grub/menu.lst) und editiert die original Konfigurationsdatei so das ein neuer Eintrag für Xen entsteht. Unter Open SuSE 10.1 kann dieser Schritt ausgelassen werden da die Einträge in die Grub Konfigurationsdatei bereits während der Installation von Xen erstellt werden.
color white/blue black/light-gray
default 0
timeout 8
gfxmenu (hd0,5)/boot/message
title SUSE LINUX 10.1
kernel (hd0,5)/boot/vmlinuz root=/dev/hda6
initrd (hd0,5)/boot/initrd
### Neuer Eintrag
title Xen
kernel (hd0,5)/boot/xen.gz dom0_mem=524288
module (hd0,5)/boot/vmlinuz-xen root=/dev/hda6
module (hd0,5)/boot/initrd-xen
xen.gz ist der Xen Kernel, die Option dom0_mem gibt den Speicherplatz (in kBytes) an, der für die Domain 0 reserviert wird. Der Wert sollte maximal die Größe des den gesamten physikalischen Speichers des Systems abzüglich 64 MByte (65536 kByte) für Xen selbst betragen.
Bei diesem Vorgehen ist zu beachten, dass die Domain 0 den gesamten verfügbaren Speicher für sich in Anspruch nimmt, d.h. für andere unprivilegierte Domains ist kein Speicher mehr verfügbar.
Im YaST von SuSE gibt es zwar einen Menüpunkt der das erstellen eine Virtuellen Maschine ermöglicht, allerdings werden wir in dieser Anleitung hauptsächlich auf die Erstellung einer Virtuellen Maschine von Hand eingehen. Um eine Virtuelle Maschine zu erstellen benötigen wir als erstes ein Festplattenimage welches wir uns mit den folgenden Kommandos erstellen:
linux ~# dd if=/dev/zero of=/xen/demo1/sda bs=1M count=1 seek=4095
Da wir ein richtiges Plattenimage erstellen wollen wird der Imagedatei nun eine loopback device zugewiesen das mittels fdisk wie jede normale festplatte partitioniert werden kann (z.B mit einer Swap- und einer /-Partition).
linux ~# losetup /dev/loop0 sda
linux ~# fdisk /dev/loop0
...
linux ~# fdisk -l /dev/loop0
Disk /dev/loop0: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/loop0p1 1 63 506016 82 Linux swap / Solaris
/dev/loop0p2 64 522 3686917+ 83 Linux
Nachdem das Festplattenimage erstellt wurde stellt sich die Frage wie man denn nun auf die einzelnen Partitionen zugreifen kann um sie für eine Installation in ein entsprechendes Verzeichnis zu mounten. Mit Hilfe des im Paket multipath-tools enthaltenen Tools kpartx ist dies über inen kleinen Umweg möglich. Diese Tool liest die Partitionstabelle des Block-Devices und erstellt für alle erkannten Partitionen entsprechende Geräte-Dateien unter /dev/mapper/:
linux ~# kpartx -a -p "-part" -v /dev/loop0 add map loop0-part1 : 0 1012032 linear /dev/loop0 63 add map loop0-part2 : 0 7373835 linear /dev/loop0 1012095
Mit diesen Partitionen kann man jetzt wie gewohnt arbeiten (z.B. Dateisysteme anlegen und diese anschließend mounten):
linux ~# mkreiserfs -f /dev/mapper/loop0-part1 ... linux ~# mount /dev/mapper/loop0-part1 /tmp/install
Die einfachste Variante ein so erstelltes Platten-Image mit einem passenden System zu füllen erfolgt über den YaST. Dort wählt man Software, Installation in Verzeichnis. Unter Zielverzeichnis gibt man den Pfad an unter dem man das /-Dateisystem des eben erstellten Images gemountet hat (in unserem Beispiel /tmp/install), Image erstellen auf nein setzen. Nachdem man die Software-Auswahl getroffen hat und das Zielverzeichnis für die Installation in ein Verzeichnis angegeben hat kann YaST mit der Arbeit beginnen und die gewünschten Pakete installieren. Am Ende dieses Schrittes existiert eine Linux Installation in einem Verzeichniss. Um letzten endes mit dem Image arbeiten zu können muss das Verzeichnis noch ungemountet und die Mappings, die kpartx angelegt hat entfernt werden.
linux ~# umount /tmp/install linux ~# kpartx -d -p "-part" -v /dev/loop0
Bevor diese Installation unter Xen gestartet wird muss noch die virtuelle Hardware festgelegt werden. Dazu zählen neben Hauptspeicher und Festplatten auch Netzwerkkarten. Die Konfiguration dazu wird im Verzeichnis /etc/xen/ abgelegt und hat in den meisten Fällen den Namen der darin definierten Domäne:
kernel = "/boot/vmlinuz-xen" ramdisk = "/boot/initrd-xen" memory = 128 name = "demo1" disk = [ "file:/xen/demo1/sda,sda1,w", "file:/xen/demo1/sda,sda2,w" ] root = "/dev/sda1 ro" extra = "usessh=1 3" nics = 1 vif = [ "mac=aa:00:00:48:12:4f, bridge=xenbr0" ] # dhcp = "dhcp"
Die Bridge xenbr0 wird dabei von Xen automatisch erzeugt, und die Standard-Netzwerkkarte eth0 ist Bestandteil dieser Bridge (wenn auch jetzt mit neuem Namen peth0):
linux ~# btctl show xenbr0 8000.feffffffffff no peth0
Die MAC-Adressen für Xen sollte man aus dem eigens dafür reservierten Bereich generieren (00:16:3e:xx:xx:xx).
Der Kernel bzw. die Ramdisk müssen alle Treiber enthalten, die von der virtuellen Maschine gebraucht werden, also z.B. den Treiber für Festplatten-Controller (z.B. ide-disk) oder Root-Filesystem (z.B. reiserfs). Bei SuSE kann man diese in /etc/sysconfig/kernel der Variable INITRD_MODULES hinzufügen, um danach mit mk_initrd bzw. bei neueren Versionen mit mkinitrd eine neue Initial Ramdisk zu erstellen.
Ein Link in /etc/xen/auto/ auf diese Dateien sorgt dafür dass der Dienst xendomains bei Reboots diese Domänen automatisch startet (sofern xendomains aktiviert ist).
Zum Testen startet man die Domain jedoch erstmal von Hand:
linux ~# xm create /etc/xen/demo1 Using config file "/etc/xen/demo1".
Wird dieser Aufruf mit der Fehlermeldung
Error: Error creating domain: (12, 'Cannot allocate memory')
beantwortet, so reicht der freie Speicher nicht mehr aus um die Anforderungen der Domain zu erfüllen. Um Speicher zwischen den einzelnen Domains dynamisch aufteilen zu können wurde in Xen 2.x das Balloon-Konzept eingeführt: Mit dessen Hilfe kann man den einzelnen Domains in der Summe mehr Hauptspeicher zuordnen, als real vorhanden ist. Ein Pseudo-Prozess balloon kann in jeder Domain Speicher für sich reservieren, in Wirklichkeit stellt er sie aber dem Xen System für andere Domains zur Verfügung.
Mit den folgenden Kommandos kann man sich die momentane Speicheraufteilung betrachten, anpassen und anschließend eine Domain neu starten:
linux ~# xm list Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 443 0 r---- 922.9 linux ~# xm balloon Domain-0 256 linux ~# xm list Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 256 0 r---- 923.5
Ab Version 3.x hat sich das etwas geändert, hier sieht der gleiche Ablauf so aus:
linux ~# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 443 1 r----- 922.9 linux ~# xm mem-set Domain-0 256 linux ~# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 256 1 r----- 923.5
Eine (vorkonfigurierte) virtuelle Maschine startet man dann mit
linux ~# xm create /etc/xen/demo1 Using config file "/etc/xen/demo1". Started domain demo1, console on port 9604 linux ~# xm list Name Id Mem(MB) CPU State Time(s) Console Domain-0 0 256 0 r---- 1077.4 demo1 6 64 1 r---- 2.3 9606 linux ~# xm consoles Dom Port Id Connection 4 9604 16 linux ~# xm console demo1 ************ REMOTE CONSOLE: CTRL-] TO QUIT ******** ... ************ REMOTE CONSOLE EXITED *****************
Man kann sich den letzten Schritt auch sparen indem man sich gleich beim Starten der virtuellen Maschine an die Console hängt:
linux ~# xm create /etc/xen/demo1 -c ...
Eine Konsole wird mit der Tastenkombination Ctrl-] geschlossen.
Domänen kann man nicht nur über die Konsole herunterfahren, sondern auch aus der Domain 0 heraus. Die Option shutdown entspricht dabei dem System-Kommando shutdown -h now, währen die Option destroy in ihren Auswirkungen dem physikalischen Ausschalten eines Rechners gleicht:
linux ~# xm shutdown demo1 linux ~# xm destroy demo1
Weitere Kommandos:
linux ~# xm save demo1 /xen/demo1.xen linux ~# xm restore /xen/demo1.xen linux ~# xm pause demo1 linux ~# xm migrate demo1 linux2.mydomain.de linux ~# xm migrate --live demo1 linux2.mydomain.de
Die meisten Probleme die beim Einrichten von Xen auftreten können
sind im 
Xensource Wiki
beschrieben. Weitere Links:
Vanderpool und Pacifica
Die neueste bzw. nächste Generation von CPUs der großen Hersteller werden mit Virtualisierungsfunktionen ausgeliefert. Bei Intel trägt diese den Codenamen Vanderpool, beim Konkurrenten AMD Pacifica. Mit Hilfe dieser Technik können dann auch unmodifizierte Gastsysteme unter Xen laufen. In der Dokumentation fehlen jedoch leider noch detailierte Hinweise darauf, wie man ein solche System konfiguriert. Im folgenden befinden sich zwei Konfigurationsdateien die es ermöglichen ein unmodifiziertes Windows unter Xen laufen zu lassen. Vorraussetzung hierfür ist ein Prozessor mit VT Technologie sowie Xen ab Version 3.0.2.
Hier die Konfigurationsdatei um die Installation von Windows einzuleiten in dem von CD gebootet wird:
import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 128
name = "winxp"
vif = [ 'type=ioemu, bridge=xenbr0' ]
disk = [ 'file:/tmp/install,ioemu:sda,w' ]
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
cdrom = '/dev/cdrom'
boot='d'
sdl=1
vnc=0
vncviewer=0
stdvga=0
serial='pty'
ne2000=0
audio=1
Um die Windowsinstallation zu booten muss bei boot die Option auf c gestellt werden um von dem Festplattenimage zu booten.
import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 128
name = "winxp"
vif = [ 'type=ioemu, bridge=xenbr0' ]
disk = [ 'file:/tmp/install,ioemu:sda,w' ]
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
cdrom = '/dev/cdrom'
boot='c'
sdl=1
vnc=0
vncviewer=0
stdvga=0
serial='pty'
ne2000=0
audio=1
Vor dem Erstellen der virtuellen Maschine sollte unbedingt geprüft werden, ob der zugewiesene Speicher auch frei ist. Ist dies nicht der Fall, bedanken sich ältere Versionen von Xen mit einem Crash der Domain0.
In der neuen Version 3.0.3 von Xen hat sich wieder einmal einiges an der Konfiguration geändert. So wurde z.B. die Angabe von CDROM und Festplatten-Laufwerken einheitlich gestaltet. Was unter 3.0.2 noch
... disk = [ 'file:/tmp/install,ioemu:sda,w' ] cdrom = '/dev/cdrom' ...
hieß, wir jetzt so geschrieben:
... disk = [ 'file:/tmp/install,ioemu:sda,w', 'phy:cdrom, hdc:cdrom, r' ] ...
zum Seitenanfang
Navigation ausblenden
