VM in Hyper-V exportieren und auf einem anderen Host importieren


    Tags: ,

    Live Migration unter Hyper-VHyper-V bietet seit Windows Server 2008 R2 gleich zwei fortgeschrittene Techniken, um VMs zwischen Hosts umzuziehen. Es handelt sich dabei um die mit Windows Server 2008 eingeführte Quick Migration und die in R2 nachgelegte Live Migration. Daher scheint auf den ersten Blick kein Bedarf an einer manuellen Migration von VMs zwischen Hosts zu bestehen. Allerdings sind die Anforderungen für die beiden erstgenannten Verfahren recht hoch, so dass sie für kleinere Installationen nicht in Frage kommen.

    Die größten Hürden für die Quick und die unterbrechungsfreie Live Migration bestehen darin, dass sie ein Windows-Cluster und ein SAN voraussetzen. Die Clustering-Funktion ist aber beispielsweise in der Standard Edition von Windows Server 2008 R2 nicht enthalten und kleinere Firmen haben oft kein SAN. Zwar ließe sich ein Cluster auch mit dem kostenlosen Hyper-V Server 2008 R2 einrichten, aber diesem fehlt wie Server Core die grafische Shell und ist daher schwieriger zu administrieren.

    Nur manuelle Migration ohne Cluster

    In einer Konfiguration aus einzelnen Hosts, die nicht Knoten in einem Cluster sind, bleibt daher derzeit mit Windows-Bordmitteln nur die Möglichkeit, eine VM auf einem Server zu exportieren und sie anschließend wieder auf einem anderen zu importieren. Dieser Zustand soll sich mit Hyper-V 3.0 in Windows Server 2012 ändern, denn dort soll sogar eine Live Migration ohne Cluster und SAN möglich sein. Darüber hinaus lassen sich dann VMs mittels Replikation übertragen, zu diesem Zweck benötigt man heute noch Tools von Drittanbietern wie Double-Take Availability.

    Die Gründe, um VMs manuell umzuziehen, sind im Prinzip die gleichen wie für eine Quick oder Live Migration. Es kann etwa notwendig sein, einen Host zu Wartungsarbeiten herunterzufahren, so dass während dessen seine VMs auf einer anderen Maschine ausgeführt werden müssen. Darüber hinaus ließen sich durch einen Umzug bestimmte Server entlasten und die Workloads neu verteilen.

    Erhebliche Downtime

    Zu beachten ist bei einem manuellen Export und Import, dass er mit erheblichen Ausfallszeiten der betroffenen VMs verbunden ist. Diese beginnen damit, dass man eine VM nur exportieren kann, wenn diese ausgeschaltet ist. Hinzu kommt die Zeit für den Transfer der meist umfangreichen VHDs auf den neuen Host sowie der Boot-Vorgang am Bestimmungsort.

    Export und Import via Hyper-V-Manager

    Der Export einer VM erfolgt über den Hyper-V-Manager und funktioniert nur, wenn sie ausgeschaltet ist.Sowohl der Export als auch der Import erfolgen über den Hyper-V-Manager. Wenn man beim Quell-Rechner das Kontextmenü einer VM öffnet, dann findet sich dort der entsprechende Befehl. Seine Aufgabe besteht darin, die zu einer VM gehörenden Dateien unter einer Verzeichnis­struktur zusammen­zu­fassen. Normalerweise liegen die Metadaten (\ProgramData\Microsoft\­Windows\Hyper-V) getrennt von den VHDs ("\Users\Public\Documents\Hyper-V\Virtual hard disks"). Alle Konfigurations­daten werden beim Export in eine einzige XML-Datei mit der Endung .exp geschrieben.

    Migration über File-Share

    Der Import einer VM von einem Netzlaufwerk erfordert eine Anpassung der Zugriffsrechte, die auch den Ziel-Host berücksichtigen.

    Für den Transfer der Dateien bieten sich 2 Varianten an: entweder man exportiert sie in ein lokales Verzeichnis und von dort direkt zum Zielrechner, oder man wählt dafür den Umweg über eine Netzfreigabe. Das direkte Kopieren einer lokal exportierten VM ist einfacher, da die Konfiguration der Zugriffsrechte eines Netzlaufs für den Import recht kompliziert ist. Im letzten Schritt startet man im Hyper-V-Manager den Importvorgang.

    Standardmäßig klappt nur ein Import

    Um einen versehentlichen mehrfachen Import zu verhindern, löscht der Hyper-V-Manager nach der erfolgreichen Migration die .exp-Datei. Wenn man dies vermeiden möchte, weil man einen mehrfachen Import plant, dann setzt man das Häkchen unter Alle Dateien duplizieren, so dass der gleiche virtuelle Computer erneut importiert werden kann. In diesem Fall wird man auch die VM unter einer neuen ID importieren, wie es der zuständige Dialog anbietet.

    Migration zwischen AMD und Intel

    Nun sollte die VM im Hyper-V-Manager unter dem neuen Host sichtbar sein und sich starten lassen. Dabei treten in der Regel auch keine Probleme auf, wenn man VMs zwischen verschiedenen Prozessortypen, also etwa zwischen AMD und Intel umzieht. Eine Live Migration dagegen erfordert weitgehend identische Maschinen an beiden Enden, weil sie auch das Speicherabbild einer VM in das RAM des Ziel-Hosts überträgt.

    Bei heterogener Hardware kann nach dem Import jedoch eine erneute Aktivierung von Windows-Gästen anstehen. Probleme können auch auftreten, wenn die virtuellen Netzwerke der beteiligten Hosts verschieden konfiguriert sind, so dass hier eine Nachbearbeitung anfällt.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    2 Kommentare

    Christian sagt:
    19. Dezember 2013 - 15:20

    Danke für die Erklärung. Bin neu in Sachen Hyper-V und habe mittels Export/Import nun auch einige Fehler in Verbindung mit Snpashots, welche nicht gelöscht werden konnten, gelöst.

    julia sagt:
    27. Januar 2014 - 19:32

    Danke für die ausführliche Beschreibung. Ich habe bislang immer gedacht, dass es genügt, die VHD auf einen anderen Server zu kopieren und das wars.