Migration von vmWare Server nach Xen

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
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.

Inventory- und Softwaremanagement für Windows… mit OpenSource!?

Die Fichtner-Gruppe ist ein Dienstleister für öffentliche- und private Infrastruktur. Die Spezialisten für Ver- und Entsorgungswirtschaft verfügen über weltweit mehr als 1.600 Mitarbeiter, welche sich international um die Planung, Beratung als auch Realisierung von Projekten kümmern.
Ein weltweit agierender Dienstleister dessen Mitarbeiter viel im Ausland tätig sind ist natürlich auf ein zuverlässiges Tool für Softwareverteilung angewiesen. Hier kommt OCS zum Einsatz. NETWAYS unterstützt die Fichtner Gruppe bei der Implementierung von OCS als Tool für Software Rollouts und GLPI als Oberfläche für Inventory jeglicher Art (Server, Clients, Drucker, Lizenzen, …).
Automatische Softwareverteilung im Intranet und Internet, automatisches Hard- und Softwareinventory und eine “schlanke” Clientinstallation sind nur ein paar der gewünschten Anforderungen die OCS erfüllt.
Da alle guten Dinge heut zu Tage nicht “3”, sondern “virtualisiert” sind, wurde der OCS- und GLPI Server in eine virtuelle Maschine auf einem VMware ESX Server installiert. So bleibt die Umgebung und deren Ressourcen skalierbar und dynamisch.
Wir wünschen der Fichtner Gruppe an dieser Stelle viel Spaß mit dem Tool und ein erleichtertes Arbeiten in der Zukunft und unterstützen die weitere Realisierung des Projekts natürlich gerne.

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

VMware via perl API und Nagios monitoren



Die Überwachung von VMware ESX Server mittels SNMP ist nicht die wahre Freude. Von Version zu Version ändern sich OIDs oder es kommen auf der selben OID andere Rückgabewerte.
Doch es gibt ja seit VMware ESX Server 2.x auch das Common Interface API. Eigentlich will man ja nur wissen ob es den VMs gut geht und wie die Lastsituation auf dem Wirt bzw. den Gastsystemen aussieht.
Für genau diesen Zweck gab es bisher keine für NETWAYS und unsere Kunden angemessene Lösung.
Wir haben jetzt auf der perl API aufbauend ein Plugin entwickelt, welches ohne größeren Aufwand den Zustand der VMs prüft. Nun ist es möglich sicherzustellen, dass bestimmte Gastsysteme laufen und gleichzeitig Graphen für CPU Last, Speicher- und Plattennutzung sowie weiterer Parameter zu erzeugen.
Um nur die Anzahl der laufenden VMs zu monitoren und sicherzustellen, dass alle Gastsysteme laufen, muss nicht extra jede Virtuelle Maschine im Monitoring konfiguriert werden, sondern es genügt mit unserem Plugin den globalen Status zu prüfen.
Darüber hinaus können aber auch pro VM Graphen für die verschiedenen Performancecounter erzeugt werden.
Wir veröffentlichen check_vmware3.pl wie immer unter der GPL auf NagiosExchange mit Dokumentation auf NagiosWiki.