Von VMware und Hyper-V zu Proxmox – der Hauptgrund für den Umstieg
Vorbereitung
SoftwareGuest-Tools der Altplattform entfernen, VirtIO-ISO bereitlegen
NetzwerkMAC-Adresse, VLAN, IP und DNS vorher dokumentieren
LizenzenProduktschlüssel und Aktivierungsstatus vor dem Umzug sichern
Guest-Tools der Altplattform entfernen (VMware Tools, Hyper-V-Integrationsdienste) – alte Tools führen nach dem Umzug sonst leicht zu Bluescreens oder falsch erkannter virtueller Hardware
Bei Windows zusätzlich vorab den Product Key sichern, z. B. mit wmic path softwarelicensingservice get OA3xOriginalProductKey für einen im BIOS/UEFI eingebetteten OEM-Key – nach der Migration ist dieser Key oft nicht mehr auslesbar
VirtIO-Treiber bereitlegen und, wo die Altplattform es zulässt, schon vor der Migration im Gastsystem einspielen
Netz, MAC-Adressen, VLAN, IP-Konfiguration, DNS-Einträge und Boot-Reihenfolge vorher dokumentieren – wichtig, weil DHCP-Reservierungen und Firewall-Regeln oft an die MAC-Adresse gebunden sind
Migration ist zu 90 % Vorbereitung und nur zu 10 % Knopfdruck. Wer die Reihenfolge umdreht, verbringt die Nacht mit Fehlersuche statt mit einem sauberen Umzug.
🎧 Block 1: Vorbereitung
VMware → Proxmox
Eingebauter ESXi-Import-Assistent (ab Proxmox VE 8.2): Zugangsdaten des ESXi-Hosts (oder vCenter) eingeben, Proxmox listet die VMs direkt auf und liest Festplatten sowie Konfiguration aus
Direkter Import vom ESXi-Host übers Netzwerk, ohne Umweg – deutlich weniger Handarbeit als in älteren Proxmox-Versionen, die zwingend einen OVF/OVA-Export voraussetzten
Alternativ: Import über OVF/OVA-Paket – sinnvoll bei sehr alten ESXi-Versionen ohne API-Zugriff oder wenn getrennt vom Quellsystem gearbeitet werden soll
Für Skript- oder Batch-Migrationen alternativ virt-v2v (aus libguestfs): konvertiert VMware- und Hyper-V-VMs inklusive Treiber-Anpassung im Gastsystem in einem Rutsch
Der Import ist der Umzugswagen, nicht das fertig eingerichtete neue Zuhause – Boot-Modus, VirtIO-Treiber und Guest Agent sind eigene Arbeitsschritte danach, dazu mehr in den folgenden Blöcken.
🎧 Block 2: VMware → Proxmox
Hyper-V → Proxmox
Kein so direkter Import-Assistent wie bei ESXi – der Kern der Arbeit ist die Konvertierung: Hyper-V speichert Disks als VHD/VHDX, Proxmox bevorzugt qcow2 oder raw
Werkzeug: qemu-img – derselbe Befehl wandelt auch das VMware-Format vmdk um, ein Universalübersetzer für praktisch alle gängigen vDisk-Formate
Guest-Betriebssystem so gut wie möglich vorab auf VirtIO vorbereiten, etwa durch frühzeitiges Einspielen der Treiber im Altsystem
Generation-2-Hyper-V-VMs booten per UEFI, Generation-1-VMs klassisch per BIOS – der Boot-Modus auf Proxmox muss zur Quelle passen, sonst startet die VM nicht
Dynamische VHDX-Disks (die mitwachsen) lassen sich genauso konvertieren wie fixe – qemu-img erkennt das Format automatisch, eine manuelle Umwandlung in Hyper-V vorher ist nicht nötig
Bei aktivem BitLocker auf der Quell-Disk vorher entschlüsseln oder den Wiederherstellungsschlüssel sichern – kopieren lässt sich die Disk zwar, ohne den ursprünglichen TPM-Schlüssel bleibt sie nach der Migration aber verschlossen.
🎧 Block 3: Hyper-V & qemu-img
vDisk-Konvertierung mit qemu-img
Grundbefehl: qemu-img convert -p -O qcow2 quelle.vmdk ziel.qcow2 – -p zeigt den Fortschritt, -O legt das Zielformat fest
Unterstützte Quellformate u. a. vmdk (VMware), vhd/vhdx (Hyper-V) und vdi (VirtualBox) – alle laufen über denselben Befehl auf qcow2 oder raw
Zielformat nach Storage wählen: raw für ZFS/LVM-thin (der Storage übernimmt selbst Thin-Provisioning und Snapshots), qcow2 für Verzeichnis-Storage (eigene Snapshot-Fähigkeit, etwas mehr Overhead als raw)
Nach der Konvertierung wird die Disk mit qm importdisk <vmid> ziel.qcow2 <storage> einer bereits angelegten, leeren VM-Hülle zugeordnet und im Hardware-Dialog als SCSI/VirtIO-Disk aktiviert
qcow2 bleibt sparse (nur genutzte Blöcke belegen Platz); raw ist das auf ZFS-Zvols durch deren Thin-Provisioning ebenfalls, auf klassischen Dateisystemen dagegen nicht automatisch
VirtIO-Treiber (Windows)
Ohne VirtIO: spürbar langsamerer Betrieb durch IDE/SATA-Emulation oder im ungünstigsten Fall gar kein Boot, wenn die Disk direkt als VirtIO-SCSI angesprochen wird
Treiber-ISO (offizielles VirtIO-Windows-Repository) als zweites CD-Laufwerk einbinden und die Treiber über den Geräte-Manager laden
Disk- (viostor/vioscsi), Netz- (NetKVM) und Balloon-Treiber (Balloon, für flexiblen Arbeitsspeicher) gehören zum Kern-Set, dazu qxl für Grafik und vioserial für die Guest-Agent-Kommunikation
Vor dem Umstieg auf VirtIO SCSI (oder anderen riskanten Migrationsschritten) einen Snapshot der VM anlegen – schnelle Absicherung, um bei Problemen sofort zurückzuspringen; kein Ersatz für ein Backup, da der Snapshot auf demselben Storage liegt wie die VM selbst
Henne-Ei-Problem: Windows kann nicht von einer VirtIO-SCSI-Disk booten, solange der Treiber dafür fehlt. Deshalb beim ersten Boot zunächst als emulierte SATA/IDE-Disk starten, den VirtIO-Treiber von der ISO installieren und erst danach in der VM-Hardware auf VirtIO SCSI umstellen und neu starten.
🎧 Block 4: VirtIO & Guest Agent
QEMU Guest Agent
Sauberes Herunterfahren direkt aus der Proxmox-Oberfläche, statt eines harten Ausschaltens, das bei laufenden Schreibvorgängen Datenverlust riskiert
Zeigt die IP-Adresse der VM in der GUI an – ohne Agent bleibt nur Raten oder ein Blick ins DHCP-Log
Sorgt für konsistente Backups durch kurzes Einfrieren des Dateisystems (Freeze) während des Snapshots – besonders wichtig bei Datenbank-VMs
Installation unter Windows über das VirtIO-Treiber-ISO (enthält den Installer qemu-ga-x86_64.msi), unter Linux meist als Paket qemu-guest-agent aus den Standard-Repositories
In der VM-Hardware muss die Option „QEMU Guest Agent" zusätzlich aktiviert werden – sonst wartet Proxmox beim Booten unnötig auf eine Antwort, die nie kommt, was den Start spürbar verzögert
UEFI/BIOS & TPM
Boot-Modus auf Proxmox muss zur Quelle passen: SeaBIOS für klassische BIOS-VMs, OVMF für UEFI – Hyper-V-Generation-2 und die meisten modernen VMware-VMs sind UEFI
Windows 11 benötigt zusätzlich ein virtuelles TPM 2.0, das Proxmox als eigenes Gerät (tpmstate0) bereitstellt – ohne TPM verweigert Windows 11 teils Updates oder startet gar nicht erst
Falscher Boot-Modus zeigt meist nur einen schwarzen Bildschirm ohne Fehlermeldung – nicht raten, sondern vorher prüfen, wie die Quell-VM tatsächlich gebootet hat
Bei OVMF zusätzlich eine kleine EFI-Disk (efidisk0) für die VM anlegen – dort liegen die UEFI-Variablen wie Boot-Reihenfolge; ohne diese Disk vergisst die VM ihre Boot-Konfiguration bei jedem Neustart
BitLocker-verschlüsselte Windows-Disks sind an das ursprüngliche TPM gebunden. Das neue virtuelle TPM in Proxmox ist ein anderes Gerät – vorher entschlüsseln oder den Wiederherstellungsschlüssel griffbereit halten, sonst hängt die VM beim Boot in der BitLocker-Wiederherstellung fest.
🎧 Block 5: UEFI/TPM & Reaktivierung
Windows-Reaktivierung
Geänderte virtuelle Hardware (CPU-ID, Mainboard-Kennung, Netzwerkkarte) lässt Windows glauben, es liefe auf einem neuen Rechner – eine Neuaktivierung wird dann fast immer verlangt
Digital-Entitlement-Aktivierungen (an das Microsoft-Konto gebunden) lassen sich meist per Online-Assistent oder erneutes Anmelden mit dem Microsoft-Konto reaktivieren; im BIOS der alten Hardware eingebrannte OEM-Keys gehen dagegen mit der virtuellen Hardware verloren
Windows- und Fachanwendungs-Lizenzen vorab prüfen – auch Branchensoftware bindet sich teils an Hardware-Merkmale wie Datenträger-Seriennummer, MAC-Adresse oder CPU-ID
Lizenzstatus vor der Migration dokumentieren (Produktschlüssel, Aktivierungsart, ggf. Kontobindung) – siehe Checkliste im Vorbereitungs-Block
Nichts ist unangenehmer, als beim Kunden vor Ort nach einem verlorenen Produktschlüssel zu suchen, während die Fachsoftware auf die Freischaltung wartet – das Lizenz-Inventar gehört fest in die Vorbereitungscheckliste.
USB-/Lizenz-Dongle
Dongle per USB-Passthrough direkt in die VM durchreichen – Proxmox kann USB-Geräte nach Port oder nach fester Vendor-/Produkt-ID durchreichen; die ID-Variante übersteht auch einen anderen USB-Port oder einen Hostwechsel
Oft entscheidend für KMU-Fachsoftware (Buchhaltung, Branchenlösungen, CAD) – ohne funktionierenden Dongle-Durchgriff ist eine Migration für diese Anwendungen schlicht nicht möglich
Alternativ: USB-über-Netzwerk-Lösungen mit kleinen Hardware-Adaptern, sinnvoll wenn der Dongle nicht direkt am Proxmox-Host, sondern z. B. an einem Arbeitsplatz steckt
Passthrough nach Vendor-/Produkt-ID in der VM-Hardware eintragen (z. B. usb0: host=1234:5678) statt nach Bus-/Port-Nummer – Port-Zuordnungen ändern sich gerne beim nächsten Hardware-Tausch
🎧 Block 6: Dongle, Konsole & Nachkontrolle
Konsole als Rettungsanker
noVNC (Standard, direkt im Browser) oder SPICE (mehr Komfort: Zwischenablage, dynamische Auflösung, benötigt einen kleinen Client) sind echte Hypervisor-Konsolen, keine Fernwartung innerhalb der VM
Zeigen BIOS/UEFI-Bildschirm, Bootvorgang und sogar den abgesicherten Modus, unabhängig davon, ob in der VM Netzwerk oder ein funktionierender Grafiktreiber vorhanden ist
Nach einem Treiberfehler ist man dadurch nie ausgesperrt, weil die Konsole auf Hypervisor-Ebene arbeitet und nicht von einem Dienst innerhalb der VM abhängt
Genau deshalb ist die Konsole der Rettungsanker beim VirtIO-Umstieg: Klappt der Wechsel auf VirtIO-SCSI nicht, zeigt die Konsole den Bluescreen oder die Fehlermeldung, während eine RDP- oder SSH-Verbindung in dem Moment schon tot wäre
Nachkontrolle
Netz prüfen: MAC-Adresse mit der Dokumentation aus der Vorbereitung abgleichen, VLAN-Zuordnung, IP-Adresse und DNS-Auflösung
Boot-Reihenfolge und alle Dienste kontrollieren – insbesondere automatisch startende Anwendungen, die nach dem Umzug tatsächlich wieder hochkommen müssen
Performance und Treiber final checken (VirtIO aktiv? Guest Agent meldet sich? Balloon-Treiber aktiv?), bevor „fertig" gemeldet wird
Backup-Job für die migrierte VM einrichten oder anpassen – eine frisch migrierte VM ohne eigenes Backup ist ein Restrisiko, das schnell vergessen wird
Migration endet nicht beim ersten erfolgreichen Login, sondern erst, wenn die komplette Checkliste grün ist – „bootet, passt schon" ist keine Endabnahme.
