nicole - stock.adobe.com
VMware-VMs nach Hyper-V mit Windows Admin Center migrieren
Mit der VM Conversion Extension im Windows Admin Center migrieren Unternehmen VMware-VMs agentenfrei, automatisiert und mit geringem Zeitaufwand direkt nach Hyper-V.
Microsoft hat mit der Erweiterung VM Conversion für das Windows Admin Center ein Werkzeug vorgestellt, das die Migration von VMware-VMs auf Hyper-V vereinfacht. Die Erweiterung steht als Public Preview bereit, ist kostenlos und arbeitet agentenfrei. Sie richtet sich an Unternehmen, die VMware ablösen und auf Windows Server mit Hyper-V umsteigen wollen, ohne zusätzliche Appliances oder komplexe Zusatztools bereitstellen zu müssen.
Installation und Systemvoraussetzungen
Die Erweiterung erfordert Windows Admin Center ab Version 2410 mit Gateway v2, Buildnummer 2.4.12.10. Auf dem System, auf dem Windows Admin Center ausgeführt wird, sind mehrere Komponenten zwingend erforderlich.
Zuerst muss PowerCLI installiert werden:
Install-Module -Name VMware.PowerCLIDas Modul muss funktionieren und ein Verbindungstest zu vCenter ist sinnvoll:
Get-Module -Name VMware.PowerCLI -ListAvailable
Connect-VIServer -Server "<vCenterFQDN_or_IP>" -User "<username>" -Password "<password>" -ForceDarüber hinaus ist das Microsoft Visual C++ Redistributable in den Versionen 2013 und den aktuellen Releases notwendig. Zusätzlich muss das VMware Virtual Disk Development Kit (VDDK) in der Version 8.0.3 installiert werden. Andere Versionen werden nicht unterstützt. Die Dateien sind nach dem Entpacken in das Verzeichnis zu kopieren:
C:\Program Files\WindowsAdminCenter\Service\VDDK
Die Hyper-V-Rolle muss auf dem Zielsystem aktiviert sein. Weitere Voraussetzungen auf der VMware-Seite bestehen nicht, vCenter oder ESXi-Hosts lassen sich ohne zusätzliche Software anbinden.
Das Tool unterstützt Windows Server 2025, 2022 (inklusive Azure Edition), 2019, 2016 und 2012 R2 sowie Windows 10/11. Auf Linux-Seite werden Ubuntu 20.04 und 24.04, Debian 11 und 12, Alma Linux, CentOS sowie Red Hat Enterprise Linux 9.0 unterstützt. Linux-VMs müssen vor der Migration mit Hyper-V-Treibern ausgestattet sein, für ältere Systeme mit den Linux Integration Services v4.3.
Installation der Erweiterung im Admin Center
Die Installation erfolgt vollständig im Windows Admin Center. Über das Zahnrad-Symbol in der Oberfläche gelangen Administratoren in die Einstellungen und dort in den Bereich Extensions. Auf der Registerkarte Available Extensions lässt sich VM Conversion (Preview) auswählen und installieren. Danach steht das Tool in der linken Navigationsleiste unter Erweiterungen zur Verfügung.
Beim ersten Start der Erweiterung ist eine Verbindung zu einem vCenter-Server erforderlich. Hierfür müssen FQDN, Benutzername und Kennwort angegeben werden. Das Tool unterstützt auch mehrere vCenter-Endpunkte, sodass ein Wechsel zwischen verschiedenen Umgebungen möglich ist.
Die Erweiterung erkennt alle virtuellen Maschinen in der Umgebung agentenfrei und ohne Appliances. Bis zu zehn VMs lassen sich in einem Durchgang auswählen. Eine Gruppierung kann nach Anwendung, Cluster, Geschäftseinheit oder Rack erfolgen, was eine strukturierte Migration komplexer Umgebungen erleichtert.
Synchronisation mit Prechecks
Vor der Synchronisation prüft das Tool, ob alle Voraussetzungen erfüllt sind. Es darf keine Snapshots auf den Quell-VMs geben, das Ziel muss über ausreichend Speicher und vCPU-Kapazität verfügen, der angegebene Zieldatenträgerpfad muss gültig sein und Changed Block Tracking aktiv sein. Auch die korrekte Installation von PowerCLI, den Visual C++ Redistributables und dem VDDK wird kontrolliert.
Der Ablauf startet in der Benutzeroberfläche im Menü VM Conversion (Preview). Dort lassen sich bis zu zehn VMs markieren. Im Synchronisationsfenster ist der Speicherpfad für die VHDX-Dateien anzugeben. Der Ablauf umfasst die Schritte Precheck, Snapshot-Erstellung, vollständige Initialkopie und abschließende Synchronisation.
Migration und Cutover
Vor der eigentlichen Migration führt das Tool erneut Prüfungen durch. Es kontrolliert die vCPU-Kapazität, prüft, ob auf dem Ziel-Host nicht bereits eine VM mit gleichem Namen existiert, und ob die Hyper-V-Rolle aktiv ist. Zudem wird sichergestellt, dass die synchronisierte VHDX-Datei vorhanden ist.
Die Migration erfolgt dann in mehreren Schritten: Delta-Replikation der Änderungen, Herunterfahren der Quell-VM, finale Synchronisation und Import auf dem Hyper-V-Host. Der Vorgang erfordert eine durchgehende aktive Browsersitzung. Schließt sich die Sitzung oder läuft ein Timeout ab, kann der Prozess ins Stocken geraten.
Das Tool erkennt statische IPs und überträgt diese auf den Ziel-Host. Dafür werden VM-Zugangsdaten abgefragt und Skripte ausgeführt. Sollte die Übernahme fehlschlagen, kann das bereitgestellte Skript zur Vorbereitung verwendet werden:
.\Prepare-MigratedVM.ps1 -StaticIPMigration -VerboseWährend der Migration werden Speicherparameter standardmäßig als statisch gesetzt, auch wenn die Quell-VM dynamischen Speicher genutzt hat. Wer nach der Übertragung dynamischen Speicher aktivieren will, muss die VM in Windows Admin Center oder dem Hyper-V Manager ausschalten, die Speichereinstellungen anpassen und die VM erneut starten.
Virtuelle Festplatten werden immer als dynamisch erweiterbare VHDX-Dateien angelegt. Um diese in feste Größen zu konvertieren, ist folgender Befehl auszuführen:
Convert-VHD -Path "C:\VMs\MyDisk.vhdx" -DestinationPath "C:\VMs\MyDisk_Fixed.vhdx" -VHDType FixedBIOS-GUID und Identität
Die BIOS-GUID (Globally Unique Identifier) einer VM wird beim Transfer nicht übernommen. In Szenarien, in denen Lizenzierungen oder Identitätsprüfungen von diesem Wert abhängen, muss die GUID angepasst werden. Microsoft stellt ein PowerShell-Skript zur Verfügung, das die GUID ändert:
.\Update-VMBiosInfo.ps1 -VMName "VM_Name" -BiosGuid "{423A2700-F96D-561B-B421-C3088111A97B}"Zu beachten ist, dass die Seriennummernformate von VMware und Hyper-V unterschiedlich sind. Auch nach Anpassung der GUID können Abweichungen bestehen, die Lizenzierungsmechanismen betreffen.
Protokollierung und Troubleshooting
Bei Problemen stehen mehrere Ebenen der Protokollierung zur Verfügung. Fehler lassen sich in der Browser-Konsole unter More Tools\Developer Tools\Console nachvollziehen. Auf dem Windows-Admin-Center-Server findet sich ein eigener Event-Log-Bereich unter Applications and Services Logs/WindowsAdminCenter. Die spezifischen Logs der Erweiterung liegen in:
C:\ProgramFiles\WindowsAdminCenter\Service\VMConversion_log.txtKommt es zu hängenden Migrationen nach einem Timeout oder zu Abbrüchen, können die Statusdateien auf dem Gateway-Server gelöscht werden:
C:\Program Files\Windows Admin Center\Service\migrationStatus.json
C:\Program Files\Windows Admin Center\Service\syncStatus.jsonIst auf dem Ziel-Host bereits eine fehlerhafte VM angelegt, muss diese vor einem erneuten Versuch manuell entfernt werden. Eine direkte Abbruchfunktion bietet das Tool nicht. Als Workaround empfiehlt Microsoft, den Windows Admin Center zu stoppen, neu zu starten und anschließend die Statusdateien zu löschen, damit laufende Threads freigegeben werden.
Bekannte Einschränkungen
Nicht unterstützt werden Migrationen von VMs, die auf VMware vSAN betrieben werden, sowie Migrationen nach Azure Local. Für Cloud-Szenarien ist Azure Migrate vorgesehen. Die Erweiterung steht zudem nur im lokalen Windows Admin Center zur Verfügung und nicht in der Azure-Portal-Integration.
Die Entfernung von VMware Tools erfolgt nicht immer automatisch. In manchen Fällen müssen sie manuell deinstalliert werden. Auch die Funktion Resync zwischen initialer Replikation und Delta-Synchronisation ist nicht verfügbar.
