Vor einigen Tagen habe ich zusammen mit unserem IT-Dienstleister eine komplette VMware Umgebung zu Hyper-V migriert. Ich muss sagen, der Hyper-V Server ist Microsoft mit Windows Server 2012 einfach nur gelungen. Besonders die Live-Migration. Aber dazu später mehr.
Vorgaben:
Ein VMware Cluster mit drei Hosts und etwa 18 Maschinen sollte auf ein Hyper-V Cluster migriert werden. Es waren gemischte Linux und Windows-VMs in diversen Versionen vorhanden. Das älteste Linux war ein Suse 6.4 – und das war auch die einzige VM die wir nicht migrieren konnten. Nicht weil wir nicht dazu in der Lage waren, sondern einfach weil es einen Aufwand bedeutet hätte, der einfach nur unwirtschaftlich gewesen wäre. Es gibt in dem Netzwerk einen zweiten VMware Cluster, der nicht migriert wurde, Also haben wir einige Maschinen, bei denen es sich nicht gelohnt hätte sie zu migrieren, einfach auf den anderen Cluster verschoben. Die besagte Linux-VM und auch noch eine alte Windows-2000 Maschine. Die Win2000 Maschine sollte ohnehin abgeschaltet werden, allerdings läuft darauf noch ein kleines Script, das erst noch migriert werden muss.
Donnerstag Abend ging es los. Zuerst habe ich den dritten und Hardwaretechnisch aktuellsten VMware Server „leer geräumt“ d.h. die darauf gelagerten Virtuellen Maschinen auf die beiden anderen verteilt. Dadurch war der Server dann „leer“ und ich konnte ihn am Freitag mit Windows Server 2012 neu aufsetzen. Das war unser zweiter Hyper-V Host. Der erste war schon eine Woche vorher geliefert worden. Nach der Installation von Windows Server 2012 habe ich beide Server in die vorhandene Domäneninfrastruktur aufgenommen, und „freigegeben“ danach ging es los.
Während unser IT-Dienstleister das Hyper-V Cluster mit zentraler Storage aufgebaut hat, habe ich begonnen die einzelnen Virtuellen Maschinen zu konvertieren. Hierzu gibt es mehrere Möglichkeiten. Zum einen das Programm „WinImage“ (kostenpflichtig) zum anderen das Gratis-Tool „Disk2VHD“ und die „Acronis-Variante“. Alle drei Varianten haben Vor- und Nachteile.
Variante 1 – WinImage
WinImage konvertiert die vorhandenen VMDK Datei in ein VHD Image. Die Maschine ist dabei ausgeschaltet und das konvertierte Image kann schon beim konvertieren direkt auf den neuen Speicher geschoben werden. Da die virtuelle Maschine dabei offline ist, kann – sofern das Original-Image nicht beschädigt ist – in der Regel nur sehr wenig schief gehen. Wer schon mit einem VMware Cluster gearbeitet hat, der erkennt auf Anhieb das Problem. Man muss die zu migrierende Maschine erst vom VMware Server laden – und das kostet gerade bei großen Maschinen viel Zeit. Ein weiterer Nachteil ist, das WinImage nur VMDK, IMA und VHD Dateien Konvertieren kann. Wer von einer anderen Virtualisierungslösung kommt (Virtualbox, XEN, Proxmox) der kommt mit diesem Programm nicht weit. Allerdings kann ich WinImage trotzdem nur empfehlen. Da man damit sehr gut in die unterstützen Image-Formate hineinsehen kann, und Daten heraus laden kann (Auch ISO). Dafür kostet Winimage allerdings auch ein paar Münzen (30$ Standard und 60$ Pro Version). Vor dem Konvertieren mit WinImage fragt das Programm ob man eine dynamisch wachsende, oder eine fest zugewiesene VHD erstellen möchte. Dadurch lassen sich auch vorher fest zugewiesene VMDK Dateien „verkleinern“. Auch wenn das Ergebnis nicht Optimal ist, lässt sich damit zumindest ein bisschen Speicher gewinnen. Dadurch das WinImage die ausgeschaltete Maschine konvertiert, kann man die Quell-VM vorbereiten. Sprich: VMware Tools deinstallieren, etwaige Treiber löschen.
Variante 2 – Disk2VHD
Das andere Programm das ich getestet habe ist „Disk2VHD“. Das Microsoft Tool ist mit gerade mal knappen 700kb sehr klein und lässt sich zur Not auch als Disketten-Image in die virtuelle Umgebung bringen. Zuerst einige Einschränkungen: Mit „Disk2VHD“ lassen sich nur Windows-Systeme konvertieren. Allerdings lassen dich nicht nur Virtuelle Systeme konvertieren, sondern auch physikalische Rechner damit in Virtuelle umwandeln. Disk2VHD „kopiert“ die vorhandene Festplatte in eine VHD Datei. Allerdings muss Disk2VHD dazu auf der zu konvertierenden Maschine gestartet werden und diese muss dazu logischerweise in Betrieb sein. Das ist gerade bei kritischen Systemen (Datenbanken, Zeiterfassungssysteme usw) sehr kritisch, da die konvertierte Maschine ohne den Arbeisspeicherinhalt konvertiert wird. D.h. alle im Ram befindlichen Inhalte sind verloren. Außerdem ist der erste Start der neuen VM mit der konvertierten Festplatte ein „ungeplanter Neustart“ d.h. Die Virtuelle Umgebung verhält sich so als wäre sie ohne ein geregeltes Herunterfahren einfach „abgeschaltet“ worden. Gerade bei Datenbanken kann das zu Problemen führen. Daher rate ich vorher alle kritischen Anwendungen abzuschalten bzw. die Dienste herunterzufahren. Die Vorteile sind allerdings nicht unbedeutend. Die erzeugte VHD kann überall gespeichert werden, auf die die zu konvertierende Umgebung Zugriff hat. Also auch im Netzwerk. Man muss die VM nicht erst herunterladen und spart damit auch erheblich an Zeit. Disk2VHD kann auch aus fest zugewiesenen VMDKs dynamische VHDs erzeugen. Allerdings benötigt Disk2VHD die VMware Tools und die kann man nicht mehr auf normalen Weg aus der konvertierten VHD entfernen.
Variante 3 – Acronis
Die letzte Variante ist bei weitem die sicherste, aber auch die Zeitaufwändigste. Allerdings lassen sich damit auch beinahe alle Betriebssysteme von beinahe allen Virtualisierungslösungen in beinahe alle Umgebungen migrieren. Es ist also sozusagen eine „Universallösung“. Die Rede ist von Acronis. Zuerst muss man mit einer Boot-CD von Acronis zu Quell-Maschine starten und von CD booten. Danach sichert man die komplette Maschine und speichert das Ganze auf einem Ziel, auf das beide virtuelle Maschinen Zugriff haben. Dabei ist Acronis das einzige getestete Tool das sogar auf FTP Server sichern kann. Nachdem die Maschine kopiert ist, startet man die neue virtuelle Umgebung, bootet abermals von der Acronis-CD und stellt das gesicherte Image wieder her. Dabei kann man eine komplett neue Umgebung benutzen (und auch auf physikalische PCs wiederherstellen). Ich bezeichne Acronis als die „sauberste“ Lösung, da man bei einer neu erstellten, dynamischen VHD das kleinste Ergebnis erhält. Acronis kann aus fast jeder Umgebung in fast jede kompartible Umgebung konvertieren. Allerdings ist das, wie oben erwähnt, auch die zeitaufwendigste Variante. Acronis konvertiert das heruntergefahrene System. Dadurch kann man auch hier das System gut vorbereiten. Sprich VMware Tools und eventuelle Treiber löschen oder deinstallieren. Es gibt auch die Möglichkeit das Acronis-Image direkt zu VHD zu konvertieren, allerdings habe ich diese Lösung nicht ausprobiert.
Nachdem alle Maschinen konvertiert waren, galt es die Probleme zu beheben. Die „Feinjustierung“ durchzuführen. Da die konvertierten VMs alle eine komplett neue virtuelle Hardware bekommen haben, waren natürlich auch alle MAC-Adressen der Netzwerkkarten erneuert worden. Unter den Einstellungen kann man bei „Netzwerkkarte“ die MAC-Adresse manuell zuweisen. Dazu muss man unter VMware die MAC-Adresse auslesen.
Nach installation der Integrationstools von VMware auf allen 2003 und XP-VMs (2008 und neuer ist nicht nötig) musste ich nur noch die VMware-Dienste auf „Dekativiert“ stellen und schon waren die neuen VMs auf Hyper-V einsatzbereit. Ledinglich die Debian-Maschinen bereiteten einige Probleme. Durch die neue virtuelle Hardware hatten diese Maschinen auch eine neue Netzwerkkarte bekommen und diese war nicht konfiguriert. Die neue Netzwerkkarte wurde als „eth1“ eingebunden und, da es keinen Eintrag in der /etc/network/interfaces gab, auch nicht konfiguriert. Um Problemen vorzubeugen und nur noch eine „primäre“ Netzwerkkarten zu haben, habe ich die Konfigurationsdatei 70-persistent-net.rules im Ordner /etc/udev/rules.d bearbeitet. Nun hatten alle Vms ihre zugehörigen IPs. Die Migration war komplett.
Die Vorteile von Hyper-V sind bisher einfach nur überwältigend. Vom finanziellen Aspekt einmal abgesehen. Die Live-Migration ist absolut genial. Ich kann eine VM auswählen und auf einen anderen Host per Live-Migration verschieben. Wenn ich das mit einem TerminalServer mache, auf dem etliche User eingeloggt sind, bekommen die das nicht mit. Das verschieben auf ein anderen Host im Cluster Funktioniert im laufenden Betrieb ohne Unterbrechung. Lediglich ein anpingen des Servers während der Migration verrät mir das der Host gerade verschoben wird. Aber dazu muss ich wirklich aufpassen, denn es geht nur ein einziger Ping verloren.
