Seite wählen

NETWAYS Blog

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
Manager Consulting

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
CEO Managed Services

Sebastian 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 das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord 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
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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 an.

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.