NETWAYS Blog

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

Christoph Niemann

Senior Consultant

---

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

Lies mehr von Christoph und triff unser Team