Drei Wege um virtuelle Maschinen zu migrieren

OpenNebulaConf Grafiken 09Neue Storage-Lösungen sprießen wie Tulpen im Frühling aus dem Boden. Jede einzelne ist flexibler, schlanker und hochverfügbarer.
Da kommt meine Cloud ins Spiel, die eigentlich gut läuft aber so ein schnelleres Storage ist eine willkommene Abwechslung.

So ein neues Storage ist schnell aufgesetzt, was uns dann aber vor eine neue Aufgabe stellt,
denn unsere VMs laufen… nur nicht auf unserem hippen Storage.

Nun gibt es diverse Methoden um eine virtuelle Maschine in ein neues Image bzw. neues Storage zu transferieren.

Da haben wir zum einen die altbewährte Methode, mit dem Urgestein aller blockorientierten Kopiervorgänge dd.
Dazu muss die virtuelle Maschine komplett ausgeschaltet sein. Da sich der Zustand der VMs nicht mehr ändert, kann man beruhigt die VM kopieren.

dd if=/path/to/input/file of=/path/to/output/file bs=4096

Zum anderen die Methode ein qcow2 Image in ein Blockdevice zu schreiben.
In Worten gesagt: das Image wird mit “qemu-img convert” in Raw umgewandelt und danach mit dd auf das neue Blockdevice kopiert. (Auch hier sollte die VM nicht mehr laufen!)

qemu-img convert -p -f qcow2 -O raw /path/to/input/file /path/to/outputfile.raw && dd if=/path/to/outputfile.raw of=/path/of/device bs=4M

Da die beiden genannten Arten eine lange Downtime benötigen, sind sie nur für VMs geeignet die nicht zeitkritisch sind.

Ein UNIX System kann mit guten Kenntnissen, mit relativ kurzer Ausfallszeit migriert werden. Ein hilfreiches Werkzeug dabei ist Rsync.

Leider kann ich hierzu kein fixes Beispiel vorzeigen, da die einzelnen Schritte von System zu System unterschiedlich ausfallen.

Die essentiellen Schritte sind:

1. Neues Device in der VM mounten und das gewünschte Filesystem erstellen.
2. Systemverzeichnisse auf dem neuen Device erstellen.
3. Das komplette System mit Rsync auf das neue Device kopieren. Hier muss man natürlich etwas aufpassen und Verzeichnisse wie /proc oder ggf. /mnt exkludieren. Auch auf bind Mounts sollte man achten, damit man Daten nicht ausversehen doppelt kopiert.
4. Die grub.cfg natürlich im neuen /boot Pfad aktualisieren. (grub-install und update-grub sind hierfür hilfreich)
5. Das “alte Device” als read-only einbinden und die neue fstab anpassen.
6. Und last but not least, einen weiteren Rsync in dem die restlichen Files auf das neue Image übertragen werden. (auch hier bitte das Exkludieren von wichtigen Pfaden nicht vergessen. z.B.: /etc/fstab oder auch /boot !!)

Der Vorteil hierbei ist: die Downtime erstreckt sich dabei nur über den zweiten Rsync, bei dem die Festplatte im “read-only” Modus ist.

Habt Ihr weitere coole Möglichkeiten einen VM zu migrieren?
Dann dürft ihr euch in den Kommentaren dazu äußern.

Oder seid Ihr interessiert an dem Thema Cloud und alles was damit zu tun hat? Dann besucht uns einfach auf der OpenNebula Conf 2014

Thilo Wening

Autor: Thilo Wening

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Entfernung der XEN PV Treiber unter Windows

Wir sind gerade dabei unsere virtuelle Umgebung von XEN auf KVM umzustellen. Eigentlich keine große Sache, bis auf die Tatsache das auf unseren Windows Servern überall die XEN PV Treiber installiert sind und somit die Windows VMs unter KVM immer in einen Blue Screen booten.

Windows Fehlermeldung: 0x00007b

Damit die Server unter KVM booten, müssen also diese XEN PV Treiber richtig entfernt werden. Das benötigte etwas mehr Aufwand als nur “Treiber deinstallieren”:

  • Im Geräte Manager / Laufwerke die XEN PV Treiber deinstallieren und keinen Reboot durchgeführt.
  •  Unter Systemsteurung / Programme die XEN PV Treiber deinstallieren.
  • Die Verzeichnise der XEN PV Treiber löschen: “%ProgramFiles%\Xen PV Drivers” und  “%SystemRoot%\system32\drivers\xen*
  • Und in der Registry alle Einträge entfernen:

HKLM\SYSTEM\CurrentControlSet\Services\XenConfig
HKLM\SYSTEM\CurrentControlSet\Services\XenHide
HKLM\SYSTEM\CurrentControlSet\Services\XenNet
HKLM\SYSTEM\CurrentControlSet\Services\XenPCI
HKLM\SYSTEM\CurrentControlSet\Services\XenStub
HKLM\SYSTEM\CurrentControlSet\Services\XenVbd
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E97D-E325-11CE-BFC1-08002BE10318}

Danach den Server unter XEN neu starten, damit Windows wieder seine QEMU Treiber installiert. Danach bootet die VM unter KVM ohne Probleme.

Martin Schuster

Autor: Martin Schuster

Martin gehört zu den Urgesteinen bei NETWAYS und leitet zusammen mit Sebastian das Managed Services Team. Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren.

Nein, ich will keine ausgewachsenen VMs. Meistens.

Heutzutage wird alles virtualisiert – und das ist auch gut so. Als großer Freund der Virtualisierung stecke ich am liebsten jeden Dienst in seinen eigenen Container. In einen Container, aber nicht in eine ausgewachsene VM. Hypervisor wie KVM, XEN und VMware sind für viele Anforderungen ein enormer Oberhead. Um in die meisten Vorzüge der Virtualisierung zu kommen, man braucht keinen virtualisierten Kernel mit virtualisierter Hardware – es gibt auch weitaus schlankere Werkzeuge hierzu.

BSD nennt das Konzept Jails, unter Solaris sind es Zones – und auch unter Linux existiert Vergleichbares schon lange. Wegbereiter waren das von mir über Jahre intensiv genutzte Linux-vServer, sowie OpenVZ und andere. Allen gemein war, dass sie einen entsprechend gepatchten Kernel benötigten – eine Voraussetzung, die sich aufgrund entsprechender Policies nicht überall umsetzen lässt.

Capabilities, Namespaces, CGroups und andere Mechanismen im Kernel ebneten den Weg zum offiziellen Ersatz für genannte Kernel-Patches: die Linux-Container , kurz LXC genannt. Seit 2.6.29 Bestandteil des Upstream-Kernels wird LXC so langsam erwachsen, die anfängliche Lernkurve ist aber immer noch recht steil.

Container haben keinen direkten Hardware-Zugriff: nicht auf Blockdevices, nicht aufs Netzwerk und auch nicht auf den Arbeitsspeicher. Auch haben entsprechende Gäste keinen eigenen Kernel, man kann sie vereinfacht als bessere chroot-Umgebung mit voneinander isolierten Prozessen betrachten. Genau darin liegt aber der Charm dieser Lösung: virtuelle Server zeigen kaum Performance-Unterschiede zu auf dem Host selbst laufenden Prozessen, und ein einziger Kernel kümmert sich um den virtuellen Speicher. Dadurch lassen sich weit mehr virtuelle Server als z.B. mit einem ausgewachsenen VMware betreiben.

Die Beschränkung auf einen Kernel ist gar nicht so schwerwiegend wie es vielleicht klingen mag: man kann z.B. problemlos ein 32bit RHEL als Gast auf einem aktuellen 64bit Debian betreiben. Nicht möglicht ist natürlich der virtualisierte Einsatz von anderen Betriebssystemen wie Windows in so einem Container. Solange man aber nur Linux-Systeme virtualisiert ist LXC allemal einen Versuch wert. Noch viel mehr Freude macht es, wenn man dazu schon mal ein paar erste Gehversuche mit BTRFS wagt.

Da aktuelle Distributionen LXC meist schon mitbringen, bleibt mir nur noch, gutes Gelingen und viel Spaß zu wünschen!

Thomas Gelf

Autor: Thomas Gelf

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Migration von vmWare Server nach Xen

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

Autor: Christoph Niemann

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.

Monitoring virtualisierter Umgebungen

In der aktuellen Ausgabe des Admin-Magazins ist dieses mal ein Beitrag von uns zu finden. Unter dem Titel “Monitoring virtualisierter Umgebungen” geht der Artikel auf die Überwachung der gebräuchlichsten Virtualisierungslösungen ein. Neben den Klassikern wie VMware, XEN und KVM werden auch Lösungen für Containersysteme wie OpenVZ oder Solaris Zones betrachtet.

Nagios und Icinga bietet hier aufgrund der großartigen Community eine Vielzahl an Plugins und Überwachungsmöglichkeiten. Der Artikel hilft bei Auswahl und Einsatz und gibt einen Einblick über die zugrundeliegenden Mechanismen. Das Magazin sei, unabhängig von diesem Artikel, all denjenigen ans Herz gelegt, die im heterogenen Rechenzentrumsumfeld aktiv sind.

Edit: Habe gerade gesehen, dass man den Artikel hier sogar kostenlos lesen kann.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

OSDC-Ticker: Scaling und Virtualisierung

Auch der zweite Tage der OSDC bietet den Teilnehmern ein abwechslungsreiches Programm.

Am Morgen startete Jens Mücke von Xing und mit einem guten Überblick der vorhandenen Herausforderungen und Problemlösungen in den letzten Jahren. Als größte Social Business Plattform Europas schenkt Xing neben Verfügbarkeit vor allem Performance und deren Messbarkeit viel Beachtung. Gerade das Monitoring der Public-Twitter-Timeline zur Identifizierung externer Fehlerbilder ist besonders spannend und wird bei Xing in einem RRD-Tool gegraphed. Die Geschwindigkeit von Twitter ist so selbst als Ergänzung zum Monitoring ungeschlagen.

Ralph Dehner von B1-Systems brachte in einem sehr anschaulichen Vortrag die Zuhörer auf den aktuellen Stand zum Thema KVM und Pacemaker. Unter Verwendung dieser Komponenten lassen sich hochverfügbare Virtualisierungscluster aufbauen und steuern um einen reibungslosen Ablauf in kritischen Umgebungen sicherzustellen.

Virtualisierung und Hochverfügbarkeit sind wie immer ein großer Magnet bei Open Source Konferenzen und werden auch bei unser Konferenz mit Themen wie openQRM und OpenVZ-Containervirtualisierung abgerundet.

Am Nachmittag warten noch einige spannende Vorträge auf uns bevor die Teilnehmer am Abend die Heimreise antreten.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.