Migration virtueller Maschinen

Lin Yan, 123RF

Wandervogel

Für die Verwaltung von virtuellen Systemlandschaften kommt in vielen Datacentern immer noch vSphere vom Platzhirsch VMware zum Einsatz. Mit oVirt steht jedoch eine ausgewachsene Open-Source-Alternative zur Verfügung. Auch die Migration der virtuellen Systeme stellt mittlerweile kein Hexenwerk mehr dar.
Termine planen, Nachrichten austauschen, Kundendaten verwalten, am besten auch vom Smartphone aus. Das alles und noch viel mehr sollen moderne ... (mehr)

Das Management-Framework oVirt [1] ist für die Verwaltung von virtuellen Maschinen auf Basis des KVM-Hypervisors ausgelegt ( Abbildung 1 ). Mitte September ist die Version 3.3.0 erschienen, die eine Menge Features enthält, sodass das Framework mittlerweile eine ernste Alternative auch für eingefleischte VMware-Administratoren sein sollte. Zu den wichtigsten Features zählen sicherlich:

  • Live-Migration virtueller Systeme
  • Storage-Live-Migration
  • Online-Snapshots von virtuellen Systemen
  • Umfangreiche RESTful-API zur Automatisierung von Aufgaben
  • Support für iSCSI-, FCoE-, NFS- und Gluster-Backend-Speicher
Abbildung 1: oVirt ist auf die Verwaltung von virtuellen Maschinen auf KVM-Basis ausgelegt.

Eine Quick-Start-Anleitung zur Konfiguration der Software befindet sich unter [2] . An dieser Stelle soll es darum gehen, bestehende virtuelle Maschinen auf die neue KVM-basierte Umgebung zu migrieren.

Virtuelle Maschinen verfügen immer über eine entsprechende Datei, in der das System näher spezifiziert ist. In VMware-Umgebungen ist das die VMX-Datei einer Maschine, in Libvirt-basierten Umgebungen handelt es sich um eine XML-Datei, die das System beschreibt. Die dort enthaltenen Informationen werden dann jeweils in die Datenbank des Management-Systems geladen und stehen dort jedem Host zur Verfügung. Möchte man nun Systeme aus einer Virtualisierungsumgebung in eine andere migrieren, so müssen beide natürlich die Beschreibung der zu migrierenden Systeme lesen und verstehen können. Aus diesem Grunde wurde das Open Virtual Machine Format (OVF) eingeführt. OVF wurde im Jahre 2011 als offizieller ISO-Standard anerkannt und unterstützt eine Vielzahl von Virtualisierungslösungen, beispielsweise Red Hat Enterprise Virtualization, VMware, Linux z/VM und auch VirtualBox. OVF wird auch gerne dazu genutzt, Software-Appliances als virtuelle Systeme zu verteilen.

Sollen Systeme aus einer bestehenden VMware-Umgebung in die neu aufgebaute oVirt-Umgebung umgezogen werden, so besteht eine Möglichkeit darin, die Systeme aus der alten Umgebung zu exportieren und in ein OVF-Archiv zu verpacken und dann in der neuen Umgebung zu importieren. VMware beherrscht das Exportieren aus vSphere heraus, bietet mit dem OVF-Tool aber auch ein Kommandozeilen-Interface an, mit dem sich der Export automatisieren lässt.

Nicht lückenlos

An dieser Stelle könnte man meinen, alles ist gut und wir sind ja fast fertig. Leider ging es aber bisher nur um eine Seite der Medaille. Versucht man nun nämlich das OVF-Archiv in die oVirt-Umgebung zu importieren, so schlägt das fehl. Das Tool »engine-image-uploader« verweigert seinen Dienst. Der Import in eine VMware-Umgebung klappt jedoch reibungslos.

In der OVF-Definition steht zwar beschrieben, wie eine virtuelle Maschine in dem Archiv zu definieren ist, es gibt allerdings keinerlei Aussage darüber, welches Disk-Format zu verwenden ist. Das Format muss also kompatibel sein mit dem, was der Hypervisor in der Zielumgebung unterstützt. Leider unterstützt oVirt zwar QCOW und RAW, nicht aber das von VMware verwendete VMDK-Format. Was also tun? Anstatt nun lange am Archiv herumzubasteln, um das Disk-Format zu konvertieren, kann man auf eine alternative Lösung zurückgreifen.

Seit einiger Zeit existiert das Tool »virt-v2v« . Dieses ist in der Lage, Maschinen zwischen verschiedenen Umgebungen zu migrieren und das erzeugte OVF-Archiv so anzupassen, dass ein Import in der gewünschten Zielumgebung reibungslos funktioniert. Allerdings kommt es noch besser: Das Tool führt nicht nur einen einfachen Import der virtuellen Maschine durch, stattdessen injiziert es der zu migrierenden Maschine auch noch VirtIO-Treiber, um die bestmögliche Performance in der Ziel-Umgebung zu gewährleisten.

Das Tool »virt-v2v« lässt sich aus dem Standard-Software-Repository eines aktuellen Fedora- oder Red-Hat-Enterprise-Linux-Systems installieren. Vor der eigentlichen Migration sind allerdings einige Voraussetzungen zu erfüllen, etwa auf oVirt-Seite eine NFS-basierte Export-Domäne, die während der Migration das OVF-Archiv aufnimmt. Von hier aus lässt sich die migrierte Maschine dann in einen beliebigen Cluster innerhalb der oVirt-Datacenter schieben.

Ein weiterer wichtiger Punkt betrifft die Netzwerk-Konfiguration. In der oVirt-Umgebung sind entweder die gleichen Netze wie in der VMware-Umgebung anzulegen oder ein Mapping für die notwendigen Netze einzurichten. Das Mapping erfolgt in der Datei »/etc/virt-v2v.conf« . Ist beispielsweise das Netz »vm-infra« auf der VMware-Seite vorhanden und soll dieses mit dem Netz »ovirt-infra« in der neuen Umgebung verknüpft werden, so ist hierfür die folgende Option in der Konfigurationsdatei zu definieren. Das äußere Netz bezieht sich auf die alte, das innere auf die neue Umgebung:

<network type='bridge' name='vm-infra'>
  <network type='network' name='ovirt-infra'/>
</network>

Damit die notwendigen Pakete, also die VirtIO-Treiber inklusive der eventuellen Abhängigkeiten, während der Migration in die Maschine injiziert werden können, sind diese im einfachsten Fall auf dem System zur Verfügung zu stellen, von dem das Migrationstool »virt-v2v« aufgerufen wird. Überlicherweise handelt es sich hierbei um den Ordner »/var/lib/virt-v2v/software/« , allerdings lässt sich in der Datei »/var/lib/virt-v2v/virt-v2v.db« auch ein alternativer Ordner im Tag »path-root« definieren. In der »virt-v2v.db« -Datei werden auch sämtliche Software-Pakete aufgeführt, die während der Migration injiziert werden. Welche das sind, ist natürlich vom Betriebssystem und dessen Version abhängig. Das Beispiel in Listing 1 verdeutlicht dies für ein RHEL5-System. Wird dieses auf die oVirt-Umgebung migriert, so müssen die im Tag »dep name« vorhandenen Pakete installiert sein, damit die Installation der VirtIO-Treiber funktioniert. Ist dies nicht der Fall, so werden die fehlenden Pakete zuerst installiert – entweder aus dem Dateisystem des Migrationshosts oder online aus dem Red Hat Network, wenn die Maschine dort denn registriert ist.

Listing 1

Konfiguration

 

Treiber, die nicht für den Boot-Vorgang der Maschine benötigt werden, lassen sich auch zu einem späteren Zeitpunkt einbinden. Hier ist es dann auch möglich, ein ISO-Image mit den benötigten Treibern an die Maschine anzuhängen und die Treiber von dort zu installieren.

Vorsicht: Treiber

Zum Abschluss sollte man noch darauf achten, dass man ein aktuelles Backup der zu migrierenden Maschinen hat und dass sich keine VMware-spezifische Software mehr auf den Systemen befindet. Ich habe schon öfters erlebt, dass Maschinen nicht korrekt starten, wenn vor der Migration die VMware-Tools nicht entfernt wurden.

Der eigentliche Migrationsvorgang lässt sich dann mit dem folgenden Kommando anstoßen. Dieses ist im Idealfall auf einem dedizierten Migrationshost aufzurufen:

virt-v2v -ic esx://esx.example.com/?no_verify=1 -o rhev -os storage.example.com:/ovirt-exportdomain --network ovirt-infra vm-name

Die Option »-ic« gibt hier den ESX-Host an, von dem die Maschine migriert werden soll. Alternativ könnte hier auch ein Xen- oder KVM-Host stehen. Die Angabe von »no_verify=1« sorgt dafür, dass auch ungültige X.509-Zertifikate (beispielsweise selbstsignierte) vom Tool »virt-v2v« akzeptiert werden. Mittels »-o« wird die Zielumgebung spezifiziert. Die Angabe »rhev« bezieht sich hier auf das Enterprise-Produkt Red Hat Enterprise Virtualization; oVirt stellt dessen Upstream-Variante dar. Die Storage-Domäne, in die das OVF-Archiv importiert wird, bekommt das Tool mittels der Option »-os« übergeben. Das Netzwerk sollte das sein, für welches in der Konfigurationsdatei ein Mapping eingerichtet wurde und schließlich wird die zu migrierende Maschine als letztes Argument übergeben.

Zur Authentifizierung auf dem ESX-Host kann der Benutzername und das Passwort interaktiv übergeben werden. Für die Migration mehrerer Systeme bietet es sich allerdings an, die Account-Daten für den Zeitraum der Migration in der Datei »$HOME/.netrc« zu speichern. Sie hat folgendes Format:

machine esx.example.com login root password redhat

Hat die Migration der Maschine funktioniert, taucht sie schließlich innerhalb der oVirt-Export-Domäne auf und lässt sich über das webbasierte Management-Tool in einen der vorhandenen oVirt-Cluster importieren. Nach einem Neustart der migrierten Maschine in der neuen Umgebung sollte sichergestellt werden, dass sie wie erwartet funktioniert. Erst dann kann man guten Gewissens die Maschine auf der alten Umgebung löschen und auch das OVF-Archiv aus der oVirt-Export-Domäne entfernen.

Für die Migration von sehr vielen Systemen skaliert die hier vorgestellte Methode natürlich nicht sonderlich gut. Hier bietet es sich an, eine Lösung auf Basis von »virt-v2v« in Kombination mit der RESTful-API des oVirt-Managers zu entwickeln. Das oVirt-Wiki zeigt einige Beispiele dafür, wie eine Kombination aus Kommandozeilen-Tools (hier das Tool virt-v2v) zusammen mit der RESTful-API des oVirt-Managers aussehen könnte. Bleibt zum Schluss nur noch, viel Spaß bei der Migration der virtuellen Maschinen auf die offene Management-Plattform oVirt zu wünschen.

Der Autor

Thorsten Scherf arbeitet als Principal Consultant für Red Hat EMEA. Er ist oft als Vortragender auf Konferenzen anzutreffen. Wenn ihm neben der Arbeit und Familie noch Zeit bleibt, nimmt er gerne an Marathonläufen teil.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

oVirt 3.3 unterstützt OpenStack

In der neuesten Version findet das Management-Tool oVirt auch Anschluss an die Cloud.

Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023