Neue 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
NETWAYS Blog
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.
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!
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
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.