Virtualisierung soll viele Probleme lösen. Es soll die Server besser auslasten und bei einem Ausfall der Hardware dafür sorgen, dass man ohne große Probleme die Maschine wieder ans laufen bekommt. Solange man bei einer Virtualisierungslösung bleibt, gibt es auch relativ wenig Probleme. Sollte man sich aber dazu entschließen zu wechseln, muss man einiges beachten.

Diese Woche haben wir die Migration von vmWare Server 2.0.2 nach XEN 4.0 durchgeführt. Dabei sind mehrere Dinge zu beachten. Zuerst muss man auf der vmWare Seite einiges Vorbereiten:

vmWare

Das erste, was man kontrollieren muss, ist ob das .vmdk Image aus einem monolithischen Block besteht, oder ob es in mehrere sparse files aufgeteilt ist. Dies sind in der Regel 2GB große Dateien mit Zahlen hinter der .vmdk Endung. Im ersten Fall muss man nichts weiter tun, im zweiten Fall bringt vmWare Server ein tool namens vmware-vdiskmanager mit, mit dem man diese konviertieren kann. Der Befehl hierfür lautet

vmware-vdiskmanager -r image.vmdk -t 0 image-flat.vmdk

Anschließend kann man das Image auf den Xen Server kopieren.

XEN

Da Xen mit .vmdk images nicht direkt umgehen kann, muss man es erst einmal ins raw Format konvertieren.

qemu-img convert -f vmdk image-flat.vmdk -O raw image.img

Nun muss man sich entscheiden ob man die Maschine vollvirtualisiert betreiben möchte, was für Windows die einzige Möglichkeit ist, oder ob man auch einen für Xen Angepassten Kernel zur Verfügung hat und damit auch Paravirtualisierung nutzen kann, was deutlich performanter ist. Am einfachsten ist es, wenn man diesen schon installiert hat, als die Maschine noch unter vmWare lief, es geht aber auch noch im Nachhinein. Hierzu muss man das image mounten, per chroot in das Verzeichnis wechseln und den Kernel hinzufügen.

fdisk -lu image.img   //zeigt die Partitionen des Images an.
 
kpartx -a image.img   //mapt die Partitionen des images nach /dev/mapper/loop . . .
 
mount /dev/mapper/loop2p1 /mnt // mountet die erste Partition des images nach /mnt
 
mount -t proc proc /mnt/proc/         //proc dazu mounten
 
mount -t sysfs sys /mnt/sys         // sys dazu mounten
 
mount --bind /dev /mnt/dev          // /dev dazu mounten
 
chroot /mnt           // nach/mnt als root Verzeichnis wechseln

Ab hier kann man mit den Mitteln des Betriebsystems (je nachdem ob die virtuelle Maschine Debian, RedHat, Suse oder sonst etwas ist) einen neuen kernel nachinstallieren. Am Beispiel Debian:

apt-get install linux-image-2.6.32-5-xen-amd64 linux-modules-2.6.32-5-xen-amd64

Den Kernel und die ramdisk braucht man später auch außerhalb des Images, daher sollte man ihn sich z.B. nach /boot/xen kopieren

exit // beendet chroot
 
cp /mnt/boot/vmlinuz-2.6.32-5-xen-amd64 /boot/xen
 
cp /mnt/boot/initrd.img-2.6.32-5-xen-amd64 /boot/xen

Anschließend noch alles wieder unmounten und die kpartx mappings löschen

umount /mnt/proc
 
umount /mnt/sys
 
umount /mnt/dev
 
umount /mnt
 
kpartx -d image.img

Xen Konfiguration

Jetzt ist das image vorbereitet und man muss bloß noch eine funktionierende Konfiguration anlegen. Das hier abgebildete Beispiel könnte dabei als Vorlage dienen.

# image.cfg
 
memory = 1024
 
vcpus = 1
 
name = 'image'
 
vif = [ 'bridge=xenbr1,vifname=image' ]
 
disk = [ 'file:/xen/image.img,sda,w']
 
on_poweroff = 'destroy'
 
on_reboot   = 'restart'
 
on_crash    = 'destroy'
 
kernel = '/boot/xen/vmlinuz-2.6.26-2-xen-amd64'
 
ramdisk = '/boot/xen/initrd.img-2.6.26-2-xen-amd64'
 
root= '/dev/sda1'
 
extra = "xencons=tty "

Achtung: ohne den letzten Eintrag hat man keine Konsole unter XEN

Eine Alternative zum booten unter Angabe von kernel und ramdisk ist die Benutzung von pygrub als bootmanager. Hierbei zieht sich pygrub den Kernel und die Ramdisk vor dem booten aus dem image und benutzt ihn einfach. Man bekommt am Anfang ein Auswahlmenü ähnlich wie bei grub. Um pygrub zu benutzen ersetzt man die Einträge kernel, ramdisk und root durch

bootloader="/usr/bin/pygrub"

Achtung: pygrub funktioniert nicht mit grub2!

Xen virtuelle Maschine starten

xm create -c image.cfg // startet die Maschine
 
xm list // zeigt laufende Maschinen
 
xm shutdown image // fährt die Maschine herunter
 
xm destroy image // beendet die Maschine hart (als würde man den Strom ziehen)
 
xm help // zeigt die übrigen Kommandos

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinander gesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

• More Posts (10)