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
Thilo Wening
Senior Consultant

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.

Virtualisierung stoppen!

Trotz der provokativem Überschrift werde ich einer der letzten sein, der dafür plädiert weniger zu virtualisieren – ganz im Gegenteil. In Zeiten von IaaS, PaaS, SaaS geht eigentlich nichts ohne Virtualsierung. Ob Vollvirtualsierung, Paravirtualisierung oder Container-based-Virtualisierung die Möglichkeiten sind nahezu grenzenlos, die aufsetzenden Frameworks unzählig.
In produktiven Umgebungen mit hoher und unterschiedlichster Workload und viel gemeinsam genutzten Infrastrukturkomponenten bzw. Ressourcen ist es deshalb umso wichtiger einzelne virtuelle Maschinen oder Container zu “stoppen” besser gesagt zu drosseln. Natürlich kann man mit mehr Hardware aufkeimende Engpässe entsprechend ausdehnen. Oft sind aber kleine und ungewollte Verhalten der Auslöser für querschießende Prozesse, die parallel ausgeführte Maschinen beeinflussen und somit die Qualität des generellen Services beeinflussen.
Drosseln kann man u.a. CPU Zeit, Memory, IO auf Blockdevices, IO auf NICs. Wie immer gibt es mehrere Möglichkeiten entsprechende Limits zu setzen. Pauschal lässt sich mit cgroups über die Virtualsierungstechnologien hinweg gut und effizient drosseln. Für KVM bzw. Qemu sind die eingebauten Features die effizientesten. Beim aktiven Drosseln muss der CPU des Hosts entsprechend arbeiten und ist laut IBM hier einen Tick effizienter bei Qemu-capped im Vergleich zu cgroup-capped.
KVM Prozesse können mit libvirt auch zur Laufzeit gedrosselt werden. Die Bandbreite der ersten Festplatte einer KVM-VM würde man mit Hilfe von virsh wie folgt auf 10MB/s und 50iops drosseln:
virsh blkdeviotune $virshid $name --live $total_bytes_sec $total_iops_sec
virsh blkdeviotune 123 vda --live 10240000 50

Das Cloud-Computing Framework OpenNebula wird in seiner nächsten Version ebenfalls Funktionen zur Drosselung bereitstellen.
Wem das alles zu umständlich ist, nutzt einfach das folgende funktionierende aber nicht ganz ernstgemeinte Command:
while true; do kill -STOP $ID; sleep 1; kill -CONT $ID; done

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sepp kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet zusammen mit Martin das Managed Services Team. Wenn er nicht gerade Server in MCollective einbindet, versucht er mit seinem Motorrad einen neuen Geschwindigkeitsrekord aufzustellen.

Reminder für das morgige Puppet-Webinar

puppet Ich möchte noch einmal die Gelegenheit nutzen und auf unser morgiges Puppet-Webinar zum Thema “Puppet: Provisionierung von VMware” aufmerksam machen. Das Webinar findet morgen um 10:30 Uhr statt. Die Registrierung erfolgt wie immer über unsere Webinar-Seite.
Da Virtualisierungslösungen mittlerweile in fast jeder IT-Landschaft eingesetzt werden, wollen wir aufzeigen wie man diese sinnvoll mit einem Configuration Management Tool wie Puppet kombinieren kann. Wer Puppet noch nicht kennt, dem empfehle ich unser Webinar-Archiv von der Open Source Variante von Puppet und der Puppet Enterprise Variante als kleine Vorbereitung.
Lennart und ich freuen uns bereits.
Bis morgen!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

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
Martin Schuster
Senior Systems Engineer

Martin gehört zu den Urgesteinen bei NETWAYS. Wenn keiner mehr weiss, warum irgendwas so ist, wie es ist, dann wird Martin gefragt. Er hat es dann eigentlich immer mal schon vor Jahren gesehen und kann Abhilfe schaffen :). 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 oder zieht einfach um und fängt von vorne...

Weekly Snap: From Python, KVM locking & Clonezilla tips, to OpenSUSE rwx³ & Helping Kids in Uganda

5 – 9 September was packed with posts from all corners of the office – Python tips from the development team, an introduction to Clonezilla from Managed Services, KVM cluster solutions from the consulting group topped off with an openSUSE event and a worthy cause in Uganda.
Bernd began by introducing the openSUSE Conference on 11 – 14 September at the Zentrifuge in Nuremberg. Under the theme rwx³ or Read, Write, Execute, the event boasts a varied program and a chance to meet members of the open source community from around the world. We too will contribute to a speech on “Scale Out Data Center Architecture” and are proud to support the openSUSE Conference as a gold sponsor, building on our cooperation with SUSE for the OSMC in November.
Marcus then shared a simple and fast method of creating and distributing file system images with Clonezilla. A combination of Drbl (WinRoll), ntfsclone, Part Clone, Partimage and dd under one configuration interface, Clonezilla can work with almost all file systems. With a Live CD, an existing system can be saved onto a local hard disk or network share like Samba, NFS and SSH. A restoration of the images on individual machines can also be done via the LiveCD, but for multiple machines the Clonezilla Server Edition is required. Marcus recommends the documentation on the project website, and a look at their Live System.
Thomas followed with his most recent solution for high availability and reliable locking in KVM clusters. With Libvirt’s Sanlock coupled with a dual-primary DRBD, he had a functional locking mechanism for the VM images on a GFS2. In addition, in combination with cLVM and a GFS2 based Sanlock he could send single logical volumes sitting on DRBD as virtual disks to the individual VMs. The end result was almost twice the throughput for sequential writes with an 80% latency reduction.
From the development team, Eric offered a couple different ways to filter lists in Python. Using “list comprehension” and the built-in “filter” function to generate “shallow copies”, he also gave a simple single line of code for those familiar with Python generators and iterators.
Lastly, Markus spread the word on a good cause – “Kindern eine Chance” an initiative to give orphans in Uganda a chance at a good future. Set up in 2008 by a handful of Austrians from Tirol, the private initiative has already helped 400 children around Zigoti, Uganda to regularly attend school. Proceeds go toward providing food, clean water, shelter and education for the orphans. Join us in sponsoring a child too- more information available at www.kinderneinechance.at or per email: kontakt@kinderneinechance.at.

KVM-Cluster: Hochverfügbarkeit und zuverlässiges Locking

Im Internet, in Büchern und einer Reihe von Fachartikeln findet sich umfangreiche Unterstützung für das Einrichten unterschiedlichster hochverfügbarer Linux-Cluster. Zur Zeit hoch im Kurs ist die Clusterlösung Pacemaker in Kombination mit Corosync/OpenAIS. Als Virtualisierungslösung mausert sich KVM (neben LXC) zum Produkt der Wahl. Und beides zusammen ergibt einen richtig schönen Cluster mit VMs, die “nach Belieben” von einem Rechner zum anderen wandern können. Oder auf Neudeutsch: eine “Private Cloud”.
Soweit nichts Neues, allerdings sind die meisten der vorgestellten Lösungen, die sich so finden, höchst riskant. Wer nämlich auf die Live-Migration nicht verzichten will, muss auf “Shared Storage” zurückgreifen. Dabei hat man die Wahl zwischen einer Lösung wie NFS (was man für VMs nicht unbedingt haben möchte), oder aber einem gemeinsamen Blockdevice (SAN, DRBD, iSCSI) mit einem Cluster-Filesystem wie GFS2 oder OCFS2. Bei vielen Knoten bieten sich Lustre, GlusterFS oder für wagemutige auch Ceph an – diese Lösungen lassen wir jetzt aber mal außen vor.

Soweit, so gut. Aber: QEMU/KVM betreibt keinerlei Locking für seine Disk Images. Das bedeutet, dass man sehr leicht versehentlich dasselbe Image zweimal gleichzeitig booten kann. So etwas hat katastrophale Auswirkungen, das Filesystem der VM wird schneller als einem lieb ist korrupt und ist zudem sehr bald kaum noch wiederherstellbar. Zwar kann man eine VM mit libvirt nicht zweimal gleichzeitig starten, wohl aber z.B. beim Clonen einer VM versehentlich dasselbe Image im XML-File stehen lassen. Genauso “tödlich” ist es, wenn in einem Cluster dieselbe VM auf zwei unterschiedlichen Knoten startet. Und spätestens in einer Split-Brain-Situation wird das früher oder später passieren.
Kürzlich konnte ich bei einem Kunden eine interessante Lösung hierfür implementieren. Libvirt bietet nämlich mittlerweile eine Schnittstelle für Lock-Manager an, und “sanlock” ist ein solcher. Damit gelang es nicht nur, auf einem GFS2 in Kombination mit mit einem Dual-Primary DRBD ein funktionierendes Locking für die VM-Images umzusetzen, sondern sogar in Kombination mit cLVM und GFS2-basiertem Sanlock auf dem DRBD sitzende einzelne Logical Volumes als virtuelle Disks den einzelnen VMs zuzuweisen.
Mit dem üblichen Minimal-Tuning für GFS2 bedeutete dies für die LVM-basierten VMs verglichen mit dem was wir in den GFS2-basierten messen konnten immer noch fast doppelten Durchsatz bei sequentiellem Schreiben und ein Fünftel der Latenzzeit!

Thomas Gelf
Thomas Gelf
Principal Consultant

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.

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
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Live von der OSDC: Virtual consolidated HA

linbitFlorian Haas ist Partnermanager bei der Firma Linbit, und Spezialist für Hochverfügbarkeitsumgebungen unter Verwendung von DRBD, XEN, KVM uvm.
Schwerpunkt seines Vortrages um 11:30 Uhr war die Verwendung von etablierten Open-Source-Lösungen in konsolidierten, heterogenen Umgebungen. Dabei ging er auf die aktuellen Entwicklungen im Bereich Heartbeat, OpenAIS und Pacemaker ein. Die Teilnehmer bekamen mit diesem hochklassigen Vortrag einen guten Überblick über die aktuellen Entwicklungen. Gerade Pacemaker, welches als Weiterentwicklung des Heartbeat CRM antielig bei Novell weiterentwickelt wird, verspricht interessante Ansätze für zukünftige Projekte. In den aktuellen Kernel-Versionen wird Heartbeat nach und nach mit den “neuen Namen” OpenIAS und Pacemaker als Weiterentwicklung ersetzt.
Da auch wir diese Technologien in unseren Projekten einsetzen, werden wir hier natürlich auch am Ball bleiben und regelmässig über Neuigkeiten bloggen.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.