VMware zu Proxmox migrieren – Ablauf und Fallstricke

Viele Unternehmen betreiben ihre virtuellen Server seit Jahren auf VMware ESXi beziehungsweise VMware vSphere.

Darauf laufen beispielsweise:

• Domain Controller
• Terminalserver
• Dateiserver
• SQL Server
• ERP-Systeme
• Linux-Server
• Webserver
• Managementsysteme
• virtuelle Firewalls

Wer seine bestehende VMware-Umgebung ablösen möchte, findet mit Proxmox VE eine interessante Virtualisierungsplattform.

Die Migration sollte allerdings nicht nach dem Prinzip:

VM exportieren → Proxmox installieren → VM importieren → fertig

durchgeführt werden.

Zwischen VMware und Proxmox unterscheiden sich unter anderem:

• virtuelle Hardware
• Festplattencontroller
• Netzwerkkarten
• Gasttreiber
• Storage
• virtuelle Switches
• Backup
• Hochverfügbarkeit
• Cluster
• Snapshots
• Netzwerkdesign

Eine schlecht vorbereitete Migration kann deshalb dazu führen, dass eine virtuelle Maschine nach dem Import:

• nicht startet
• keine Festplatte erkennt
• kein Netzwerk besitzt
• ihre bisherige IP-Adresse verliert
• Windows nicht mehr aktiviert ist
• Anwendungen nicht funktionieren
• erheblich langsamer läuft

In diesem Artikel zeigen wir deshalb, wie Unternehmen VMware zu Proxmox migrieren können, welche Migrationswege zur Verfügung stehen und welche Fallstricke vor der Abschaltung der VMware-Infrastruktur berücksichtigt werden sollten.

Kann man VMware zu Proxmox migrieren?

Ja.

Bestehende virtuelle Maschinen aus VMware ESXi können auf Proxmox VE migriert werden.

Proxmox unterstützt inzwischen sogar einen integrierten Import von VMware ESXi.

Alternativ stehen weitere Möglichkeiten zur Verfügung:

• ESXi Import Wizard
• OVF-/OVA-Export und Import
• VMDK-Import
• Backup und Restore
• Neuinstallation einzelner Systeme
• manuelle Datenmigration

Welche Methode am sinnvollsten ist, hängt von der vorhandenen VMware-Umgebung ab.

Welche VMware-Systeme können migriert werden?

Typische Kandidaten sind:

Windows Server

beispielsweise:

• Windows Server 2016
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Linux-Server

beispielsweise:

• Debian
• Ubuntu
• Rocky Linux
• AlmaLinux
• andere unterstützte Distributionen

Virtuelle Appliances

Hier muss genauer geprüft werden.

Hersteller können ihre Appliance möglicherweise nur für bestimmte Hypervisoren freigeben.

Eine technisch erfolgreiche Migration bedeutet deshalb nicht automatisch, dass der Hersteller den Betrieb auf Proxmox unterstützt.

Nicht jede VM sollte einfach migriert werden

Vor der Migration sollte jede virtuelle Maschine einzeln bewertet werden.

Beispielsweise:

DC01

→ migrieren

FILE01

→ migrieren

RDS01

→ migrieren

alte Test-VM

→ löschen

Legacy-Appliance

→ Kompatibilität prüfen

veralteter Windows Server

→ möglicherweise neu aufbauen

Eine VMware-Migration ist eine gute Gelegenheit, die bestehende Umgebung aufzuräumen.

Schritt 1: VMware-Umgebung vollständig inventarisieren

Bevor Proxmox installiert wird, sollte die bestehende Umgebung dokumentiert werden.

Mindestens:

• ESXi Hosts
• vCenter
• virtuelle Maschinen
• Betriebssysteme
• vCPU
• RAM
• virtuelle Festplatten
• verwendeter Storage
• VLANs
• Port Groups
• virtuelle Switches
• IP-Adressen
• MAC-Adressen
• Snapshots
• Passthrough-Geräte
• vTPM
• Backups
• Abhängigkeiten
• Anwendungen

Gerade die Abhängigkeiten werden häufig unterschätzt.

Anwendungsabhängigkeiten dokumentieren

Beispielsweise:

RDS01

↓

SQL01

↓

DC01

↓

FILE01

Wenn SQL01 nach der Migration nicht erreichbar ist, funktioniert möglicherweise die gesamte Fachanwendung auf RDS01 nicht.

Deshalb muss nicht nur geprüft werden:

Startet die VM?

Sondern:

Funktioniert der gesamte Dienst anschließend?

Schritt 2: Alte und unnötige VMs aussortieren

Eine seit fünf Jahren ausgeschaltete Test-VM muss nicht unbedingt auf die neue Plattform migriert werden.

Vor der Migration sollten deshalb:

• veraltete VMs
• Testsysteme
• alte Templates
• nicht mehr benötigte Appliances
• verwaiste virtuelle Festplatten

identifiziert werden.

Das reduziert:

• Migrationsdauer
• Storagebedarf
• Backupvolumen
• Komplexität

Schritt 3: VMware-Snapshots prüfen

Vor einer Migration sollten vorhandene Snapshots geprüft werden.

Alte VMware-Snapshots können nicht nur Storage und Performance beeinflussen, sondern auch den Import erheblich verlangsamen.

Proxmox weist beim ESXi-Importer ausdrücklich darauf hin, dass VMs mit vorhandenen Snapshots deutlich langsamer importiert werden können.

Snapshots sollten deshalb nicht einfach jahrelang als vermeintliches Backup bestehen bleiben.

Vor der Migration muss geprüft werden, welche Snapshots noch benötigt werden und welche sauber konsolidiert werden können.

Schritt 4: Backup vor der Migration erstellen

Vor jeder produktiven Migration sollte ein aktuelles Backup vorhanden sein.

Nicht nur:

VMware Snapshot

sondern:

echtes Backup.

Das Backup sollte im Idealfall unabhängig von der zu migrierenden Plattform gespeichert sein.

Zusätzlich sollte geprüft werden:

• Backup erfolgreich?
• letzte Sicherung aktuell?
• Restore möglich?
• Datenbank konsistent?
• Wiederherstellungszugang vorhanden?

Eine Migration ohne getesteten Rückweg ist unnötig riskant.

Schritt 5: Rollback-Plan erstellen

Für jede produktive VM sollte vorher definiert werden:

Wann gilt die Migration als fehlgeschlagen?

Beispielsweise:

• VM startet nicht
• Anwendung funktioniert nicht
• Netzwerk nicht erreichbar
• Datenbank fehlerhaft
• Performance unbrauchbar

Dann muss klar sein:

Wie kommen wir zurück?

Ein einfacher Rollback kann beispielsweise bedeuten:

1. Proxmox-VM ausschalten
2. Netzwerkverbindung der Proxmox-VM entfernen
3. ursprüngliche VMware-VM wieder einschalten
4. Netzwerk prüfen
5. Dienste prüfen

Das funktioniert allerdings nur sauber, solange nach der Umschaltung keine neuen produktiven Daten ausschließlich auf der Proxmox-VM entstanden sind.

Warum der Rollback nach Produktivstart schwieriger wird

Angenommen:

08:00 Uhr

VMware-VM wird abgeschaltet.

08:15 Uhr

Proxmox-VM startet.

09:00 Uhr

Mitarbeiter arbeiten wieder.

11:00 Uhr

schwerwiegender Fehler entdeckt.

Dann wurden möglicherweise bereits drei Stunden neue:

• Dateien
• E-Mails
• Datenbankeinträge
• ERP-Buchungen

auf dem neuen System erzeugt.

Einfach die alte VMware-VM wieder einzuschalten würde diese Änderungen verlieren.

Deshalb sollte die Abnahme unmittelbar nach der Migration erfolgen.

Schritt 6: Proxmox-Zielumgebung planen

Die Zielplattform sollte bereits vor der ersten produktiven VM vollständig geplant sein.

Dazu gehören:

• Proxmox Nodes
• Cluster
• CPU
• RAM
• Storage
• Netzwerk
• VLANs
• Backup
• Management
• Hochverfügbarkeit
• Monitoring

Die Migration sollte nicht gleichzeitig zum Experiment werden, wie die neue Infrastruktur grundsätzlich aufgebaut werden soll.

Ein Proxmox Host oder Cluster?

Bei kleinen Umgebungen kann ein einzelner Proxmox-Host ausreichen.

Beispielsweise:

PVE01

↓

5 VMs

Bei höheren Anforderungen können mehrere Nodes verwendet werden.

Beispielsweise:

PVE01

PVE02

PVE03

↓

Proxmox Cluster

Ob zusätzlich High Availability sinnvoll ist, hängt von Storage- und Verfügbarkeitsanforderungen ab.

Schritt 7: Storage planen

VMware verwendet möglicherweise:

• lokales VMFS
• SAN
• NFS
• iSCSI
• vSAN

Proxmox kann unter anderem mit unterschiedlichen lokalen und zentralen Storage-Konzepten betrieben werden.

Beispielsweise:

• ZFS
• LVM-thin
• Ceph
• NFS
• iSCSI
• weitere Storage-Backends

Die richtige Wahl hängt von der Umgebung ab.

VMware vSAN besonders beachten

Beim direkten ESXi-Import gibt es eine wichtige Einschränkung:

Virtuelle Festplatten, die direkt auf VMware vSAN liegen, können laut Proxmox-Dokumentation nicht einfach über den ESXi-Importer importiert werden.

Als möglicher Workaround kann die VM beziehungsweise deren virtuelle Festplatte zunächst auf einen anderen unterstützten VMware-Datastore verschoben werden.

Unternehmen mit vSAN sollten diesen Punkt deshalb sehr früh im Projekt prüfen.

Schritt 8: Netzwerkstruktur übertragen

VMware verwendet möglicherweise:

• vSwitches
• Distributed Switches
• Port Groups
• VLAN IDs

Proxmox verwendet unter anderem:

• Linux Bridges
• VLAN-aware Bridges
• Linux Bonding
• Proxmox SDN

Die VMware-Netzwerkkonfiguration lässt sich deshalb nicht einfach gedankenlos eins zu eins übertragen.

Beispiel VMware

Port Group:

SERVER-VLAN

VLAN:

20

Beispiel Proxmox

Bridge:

vmbr0

VLAN-aware:

Yes

VM:

VLAN Tag:

20

Das Ergebnis kann funktional dasselbe sein, die Konfiguration ist aber anders aufgebaut.

VLANs vor der ersten VM testen

Bevor produktive Server migriert werden, sollten die benötigten VLANs bereits auf Proxmox funktionieren.

Testen:

• Management
• Servernetz
• DMZ
• Backupnetz
• Storage
• Internetzugang
• Routing
• Firewall

Nicht erst während der Migration des Domain Controllers feststellen, dass VLAN 20 am Switchport fehlt.

Schritt 9: VMware Distributed Switches dokumentieren

Besonders bei größeren vSphere-Umgebungen können Distributed Switches eingesetzt werden.

Dabei müssen unter anderem dokumentiert werden:

• Port Groups
• VLANs
• Uplinks
• LACP
• MTU
• NIC Teaming
• Failover
• spezielle Policies

Diese Logik muss anschließend passend auf Proxmox umgesetzt werden.

Schritt 10: CPU-Kompatibilität planen

Proxmox kann unterschiedliche virtuelle CPU-Typen verwenden.

Für maximale Performance kann beispielsweise:

host

interessant sein.

Damit werden viele CPU-Funktionen des physischen Hosts direkt an die VM weitergegeben.

Das kann jedoch die Migration zwischen unterschiedlichen Proxmox-Nodes einschränken.

Bei einem Cluster mit unterschiedlichen CPU-Generationen kann deshalb ein kompatibler generischer CPU-Typ sinnvoller sein.

Die CPU-Konfiguration sollte deshalb bereits bei der Clusterplanung berücksichtigt werden.

Schritt 11: BIOS oder UEFI dokumentieren

Vor der Migration muss geprüft werden, wie die VMware-VM startet.

Legacy BIOS

In Proxmox typischerweise:

SeaBIOS

UEFI

In Proxmox:

OVMF

Wird die falsche Firmware gewählt, kann die VM nach dem Import möglicherweise nicht starten.

UEFI-VM benötigt EFI-Disk

Bei einer UEFI-VM sollte in Proxmox zusätzlich eine EFI-Disk eingerichtet werden.

Darauf werden die UEFI-Variablen gespeichert.

In bestimmten Fällen muss außerdem der korrekte Boot-Eintrag innerhalb der UEFI-Firmware wiederhergestellt werden.

Schritt 12: Secure Boot prüfen

Bei modernen Windows-Servern kann Secure Boot verwendet werden.

Vor der Migration sollte dokumentiert werden:

• UEFI aktiv?
• Secure Boot aktiv?
• TPM vorhanden?
• BitLocker aktiv?

Diese Funktionen können die Migration beeinflussen.

Schritt 13: vTPM und BitLocker besonders beachten

Eine der wichtigsten Stolperfallen sind virtuelle TPMs.

Proxmox weist ausdrücklich darauf hin, dass der vTPM-Zustand derzeit nicht einfach von VMware zu Proxmox migriert werden kann.

Wird innerhalb der VM beispielsweise BitLocker verwendet und der Schlüssel über das virtuelle TPM geschützt, kann dies nach der Migration zu Problemen führen.

Vorher müssen deshalb:

• BitLocker-Status
• Recovery Keys
• vTPM
• Verschlüsselung

geprüft werden.

Ohne verfügbaren Recovery Key kann daraus ein ernstes Problem werden.

Schritt 14: Verschlüsselte VMware-VMs prüfen

Auch verschlüsselte virtuelle Festplatten benötigen besondere Aufmerksamkeit.

Proxmox weist darauf hin, dass verschlüsselte VMware-VM-Disks nicht direkt importiert werden können.

Die entsprechende Verschlüsselung beziehungsweise Storage Policy muss gegebenenfalls auf VMware-Seite vorher entfernt werden.

Das sollte lange vor dem eigentlichen Wartungsfenster getestet werden.

Schritt 15: VMware Tools vor der Migration berücksichtigen

In VMware-VMs sind normalerweise:

VMware Tools

beziehungsweise unter Linux häufig:

open-vm-tools

installiert.

Nach der Migration werden diese VMware-spezifischen Komponenten nicht mehr benötigt.

Proxmox empfiehlt, hypervisorspezifische Guest Tools des alten Hypervisors möglichst bereits vor der Migration zu entfernen.

Gerade bei Windows ist das wichtig.

VMware Tools besser vor der Migration deinstallieren

Broadcom dokumentiert ebenfalls, dass VMware Tools nach der Migration auf einen Fremd-Hypervisor unter Umständen nicht mehr sauber deinstalliert werden können.

Der Grund:

Der VMware-Tools-Installer erkennt, dass das System nicht mehr auf einem VMware-Hypervisor läuft.

Deshalb sollte die Deinstallation möglichst erfolgen, solange die VM noch auf ESXi läuft.

Aber nicht unvorbereitet VMware Tools entfernen

Bei produktiven Systemen gilt trotzdem:

Nicht einfach morgens VMware Tools von allen Servern deinstallieren.

Vorher:

• Backup
• Wartungsfenster
• VM-Konfiguration dokumentieren
• Netzwerkkonfiguration dokumentieren
• Testmigration durchführen

Bei manchen Systemen kann eine Änderung der Guest Tools Auswirkungen auf Treiber oder Backupsoftware haben.

Schritt 16: VirtIO-Treiber bei Windows vorbereiten

Einer der wichtigsten technischen Punkte bei Windows-VMs ist:

VirtIO.

Proxmox verwendet für performante virtuelle Hardware typischerweise VirtIO.

Beispielsweise:

Netzwerk

VirtIO

Festplatten

VirtIO SCSI

Windows besitzt diese Treiber jedoch nicht in jeder Installation automatisch.

Wer die VM direkt auf VirtIO umstellt, bevor der entsprechende Treiber vorhanden ist, riskiert:

INACCESSIBLE_BOOT_DEVICE

beziehungsweise einen nicht startenden Server.

VirtIO-Treiber vor der Migration installieren

Bei Windows-Servern sollte deshalb vorbereitet werden:

• VirtIO-Treiber
• Storage-Treiber
• Netzwerk-Treiber

Die Treiber können über das VirtIO-Windows-Treiberpaket beziehungsweise die entsprechende ISO bereitgestellt werden.

Wichtig ist, dass der benötigte Storage-Treiber tatsächlich vom Betriebssystem geladen werden kann, bevor die Bootdisk endgültig auf VirtIO SCSI umgestellt wird.

Sichere Zwischenlösung: SATA

Wenn eine Windows-VM nach dem Import den VirtIO-SCSI-Treiber noch nicht besitzt, kann die Bootdisk zunächst beispielsweise über:

SATA

angebunden werden.

Windows kann damit häufig starten.

Anschließend werden die VirtIO-Treiber eingerichtet und die virtuelle Hardware kontrolliert umgestellt.

Das ist meist besser, als unmittelbar vor dem produktiven Start eine nicht bootfähige VM zu erzeugen.

Schritt 17: QEMU Guest Agent installieren

Nach der Migration sollte innerhalb der VM der:

QEMU Guest Agent

installiert werden.

Er verbessert die Kommunikation zwischen Proxmox und Gastbetriebssystem.

Dadurch können unter anderem Funktionen rund um:

• Shutdown
• IP-Informationen
• Backup
• Guest-Kommunikation

verbessert werden.

Proxmox empfiehlt die Installation des QEMU Guest Agent in virtuellen Maschinen.

VMware Tools und QEMU Guest Agent nicht verwechseln

Vorher:

VMware ESXi

↓

VMware Tools

Nachher:

Proxmox VE

↓

VirtIO-Treiber + QEMU Guest Agent

Die Komponenten erfüllen teilweise ähnliche Integrationsaufgaben, gehören aber zu unterschiedlichen Virtualisierungsplattformen.

Schritt 18: Netzwerkkonfiguration innerhalb der VM dokumentieren

Ein häufiger Fehler bei Windows:

Die VM besitzt auf VMware eine virtuelle Netzwerkkarte.

Beispielsweise:

VMXNET3

Nach der Migration erhält sie:

VirtIO Network Device

Windows betrachtet diese als neue Netzwerkkarte.

Die bisherige statische IP-Adresse hängt möglicherweise noch an der nicht mehr sichtbaren alten VMware-NIC.

Statische IP-Adressen vorher dokumentieren

Vor der Migration notieren:

• IP-Adresse
• Subnetzmaske
• Gateway
• DNS
• VLAN
• MAC-Adresse

Beispielsweise:

IP

192.168.20.10

Subnetz

255.255.255.0

Gateway

192.168.20.1

DNS

192.168.20.11

Damit kann die Konfiguration nach der Migration schnell wiederhergestellt werden.

Windows meldet: IP-Adresse bereits verwendet

Nach dem Austausch der virtuellen Netzwerkkarte kann Windows melden, dass die gewünschte statische IP bereits einer anderen Netzwerkkarte zugewiesen ist.

Der Grund ist häufig die alte, nicht mehr sichtbare VMware-Netzwerkkarte.

Diese muss gegebenenfalls bereinigt werden.

Proxmox empfiehlt deshalb bei Windows-VMs ausdrücklich, statische Netzwerkkonfigurationen vor der Migration zu berücksichtigen.

MAC-Adresse beibehalten oder ändern?

In bestimmten Umgebungen ist die MAC-Adresse relevant.

Beispielsweise bei:

• DHCP Reservations
• Firewallregeln
• Lizenzierungen
• Monitoring
• NAC

Dann kann die bisherige MAC-Adresse gegebenenfalls auch auf der neuen Proxmox-Netzwerkkarte verwendet werden.

Alternativ müssen die abhängigen Systeme angepasst werden.

Schritt 19: Direkten ESXi-Import vorbereiten

Aktuelle Proxmox-Versionen besitzen einen integrierten Importmechanismus für VMware ESXi.

Dazu wird in Proxmox eine ESXi-Importquelle hinzugefügt.

Sinngemäß:

Datacenter

↓

Storage

↓

Add

↓

ESXi

Anschließend werden:

• ESXi Host beziehungsweise Adresse
• Zugangsdaten
• Zertifikat

konfiguriert.

Danach können die auf ESXi vorhandenen VMs innerhalb der Proxmox-Oberfläche angezeigt und importiert werden.

Direkt mit ESXi oder über vCenter?

Der Import kann grundsätzlich auch über vCenter erfolgen.

Proxmox weist allerdings darauf hin, dass der Import über vCenter erheblich langsamer sein kann.

Wenn möglich, kann deshalb eine direkte Verbindung zum jeweiligen ESXi-Host sinnvoller sein.

Schritt 20: Test-VM zuerst importieren

Nicht mit:

Domain Controller

oder:

ERP-Produktivserver

beginnen.

Besser:

eine unkritische Test-VM.

Damit kann geprüft werden:

• ESXi-Verbindung
• Importgeschwindigkeit
• Storage
• VirtIO
• Netzwerk
• VLAN
• BIOS/UEFI
• QEMU Guest Agent
• Backup

Erst wenn dieser Ablauf funktioniert, sollte eine produktive VM migriert werden.

Schritt 21: Ziel-Storage auswählen

Beim Import muss definiert werden, wo die virtuellen Festplatten landen.

Beispielsweise:

• local-lvm
• ZFS
• Ceph
• NFS
• SAN

Bei mehreren Disks können gegebenenfalls unterschiedliche Ziel-Storage-Systeme gewählt werden.

Vorher sollte ausreichend freie Kapazität vorhanden sein.

Thin Provisioning beachten

VMware und Proxmox können Storage unterschiedlich behandeln.

Eine beispielsweise nominell:

2 TB große VMDK

belegt möglicherweise tatsächlich nur:

600 GB.

Beim Import muss geprüft werden:

• virtuelle Größe
• tatsächlich belegter Speicher
• Ziel-Storage
• Thin Provisioning
• Dateiformat
• verfügbare Kapazität

Nicht nur auf die Größe der VMware-Datastore-Anzeige verlassen.

Schritt 22: Zielnetzwerk auswählen

Beim Import wird die VMware-Netzwerkkarte einer Proxmox-Bridge zugeordnet.

Beispielsweise:

VMware:

Server-Netz

↓

Proxmox:

vmbr0

VLAN:

20

Bei VMs mit mehreren Netzwerkkarten muss jede Schnittstelle korrekt zugeordnet werden.

Schritt 23: VM herunterfahren

Für die eigentliche konsistente Migration sollte die VMware-VM heruntergefahren werden.

Proxmox weist beim automatischen Import ebenfalls darauf hin, die Quell-VM vor der eigentlichen Migration auszuschalten.

Damit wird verhindert, dass sich die virtuelle Festplatte während der Migration verändert.

Schritt 24: Live Import – weniger Downtime

Proxmox unterstützt inzwischen auch:

Live Import.

Der Begriff kann etwas missverständlich sein.

Die VMware-VM läuft dabei nicht einfach gleichzeitig weiter.

Die Quell-VM auf ESXi wird weiterhin ausgeschaltet.

Proxmox priorisiert beim Import jedoch die Daten, die für den laufenden Gast benötigt werden.

Dadurch kann die Proxmox-VM bereits gestartet werden, während weitere Daten im Hintergrund übertragen werden.

Vorteil von Live Import

Angenommen:

VM:

2 TB

Übertragung:

mehrere Stunden

Bei einem normalen Import wäre der Dienst während der gesamten Übertragung offline.

Beim Live Import kann die VM unter geeigneten Bedingungen früher auf Proxmox gestartet werden.

Die restlichen Daten werden anschließend weiter übertragen.

Damit kann die tatsächliche Dienstunterbrechung erheblich reduziert werden.

Live Import hat Risiken

Proxmox weist ausdrücklich darauf hin:

Wenn der Live Import fehlschlägt, können die seit Beginn des Imports auf der neuen VM geschriebenen Daten verloren gehen.

Deshalb:

• vorher testen
• zuverlässiges Netzwerk
• zuverlässiger Storage
• Backup
• klarer Rollback-Plan

Live Import sollte nicht das erste Verfahren sein, das man am wichtigsten Produktivserver ausprobiert.

Schritt 25: Importierte VM noch nicht sofort produktiv schalten

Nach dem Import zunächst:

• Netzwerk gegebenenfalls trennen
• VM starten
• Konsole verwenden

Dann prüfen:

• Bootet das Betriebssystem?
• Storage erkannt?
• Fehler im Event Log?
• Treiber vorhanden?
• Dienste gestartet?
• Anwendungen vorhanden?

Erst anschließend das produktive Netzwerk aktivieren.

Doppelte IP-Adresse vermeiden

Ganz wichtig:

Niemals gleichzeitig:

VMware-VM

und:

Proxmox-Kopie

mit derselben IP-Adresse im gleichen Netzwerk betreiben.

Sonst entstehen:

• IP-Konflikte
• ARP-Probleme
• Dateninkonsistenzen
• möglicherweise Domainprobleme

Bei Tests sollte die migrierte VM zunächst in einem isolierten Netzwerk gestartet werden.

Schritt 26: Virtuelle Hardware optimieren

Nach erfolgreichem ersten Start kann die VM auf Proxmox optimiert werden.

Typische Zielkonfiguration:

CPU

passender CPU-Typ

Storage Controller

VirtIO SCSI Single

Disk

SCSI

Network

VirtIO

QEMU Guest Agent

aktiv

Ballooning

je nach Umgebung aktiv

Discard

bei geeignetem Storage aktiv

IO Thread

je nach Storagekonfiguration

Proxmox nennt VirtIO und VirtIO SCSI ausdrücklich als bevorzugte performante virtuelle Hardware.

Nicht alles gleichzeitig ändern

Bei produktiven Servern würde ich die Änderungen schrittweise durchführen.

Beispielsweise:

1. VM importieren
2. VM bootfähig bekommen
3. Netzwerk prüfen
4. VirtIO-Treiber prüfen
5. Disk Controller umstellen
6. Netzwerkadapter umstellen
7. QEMU Guest Agent installieren
8. Performance testen

Dadurch ist bei einem Fehler klarer, welche Änderung ihn verursacht hat.

Schritt 27: Windows-Aktivierung prüfen

Nach einem Hypervisorwechsel kann Windows eine erhebliche Änderung der virtuellen Hardware erkennen.

Deshalb sollte nach der Migration geprüft werden:

Windows aktiviert?

Je nach Lizenzmodell kann eine erneute Aktivierung erforderlich sein.

Das Gleiche gilt für Anwendungen, die ihre Lizenz an:

• Hardware-ID
• MAC-Adresse
• CPU
• virtuelle Hardware

binden.

Schritt 28: Softwarelizenzen prüfen

Besonders kritisch:

• ERP
• Warenwirtschaft
• CAD
• SQL-Anwendungen
• Backupsoftware
• Branchenanwendungen
• Telefonanlagen
• virtuelle Appliances

Manche Hersteller erkennen die neue virtuelle Hardware als neues System.

Deshalb sollte vor der Migration geklärt werden:

Bleibt die Lizenz gültig?

Nicht erst am Montagmorgen feststellen, dass die Warenwirtschaft einen neuen Lizenzschlüssel benötigt.

Schritt 29: Domain Controller besonders vorsichtig migrieren

Domain Controller sind grundsätzlich virtualisierbar.

Bei der Migration sollte aber besonders sauber gearbeitet werden.

Prüfen:

• Active Directory
• DNS
• Replikation
• SYSVOL
• Zeit
• Netzwerk
• Event Logs

Wenn mehrere Domain Controller vorhanden sind, würde ich nicht alle gleichzeitig migrieren.

Besser:

DC01 migrieren

↓

prüfen

↓

DC02 migrieren

So bleibt während des Projekts ein funktionierender Domain Controller auf der bestehenden Plattform verfügbar.

Schritt 30: Datenbankserver prüfen

Bei SQL- beziehungsweise Datenbankservern reicht es nicht, dass Windows startet.

Zusätzlich testen:

• Datenbankdienst
• Datenbankkonsistenz
• Anwendung
• Performance
• Storage-Latenz
• Backup
• Netzwerk

Datenbankserver reagieren teilweise besonders empfindlich auf Storage-Performance.

Schritt 31: Terminalserver prüfen

Bei RDS-Systemen testen:

• RDP
• Benutzeranmeldung
• Profile
• FSLogix
• Microsoft 365
• Outlook
• Drucker
• Netzlaufwerke
• Fachanwendungen
• RDS Licensing

Auch hier kann die geänderte virtuelle Hardware Auswirkungen auf Anwendungen und Lizenzen haben.

Schritt 32: Linux-VMs prüfen

Linux besitzt VirtIO-Unterstützung häufig bereits im Kernel.

Trotzdem sollte geprüft werden:

• VirtIO-Treiber
• initramfs
• Netzwerkinterface
• Gerätenamen
• Bootloader
• fstab
• QEMU Guest Agent

Proxmox weist darauf hin, dass bei bestimmten Linux-Systemen VirtIO-Treiber vor der Migration in das initramfs aufgenommen werden müssen.

Netzwerkinterface kann sich unter Linux ändern

Eine VMware-VM verwendet möglicherweise:

ens192

Nach der Migration erscheint die Netzwerkkarte beispielsweise als:

ens18

Ist die Netzwerkkonfiguration fest auf:

ens192

eingetragen, besitzt der Server anschließend möglicherweise kein Netzwerk.

Deshalb muss die Netzwerkkonfiguration geprüft werden.

Schritt 33: OVF/OVA als Alternative

Falls der direkte ESXi-Importer nicht verwendet werden kann, kann eine VM beispielsweise als:

• OVF
• OVA

exportiert werden.

Proxmox kann OVF/OVA importieren.

Für OVF steht unter anderem:

qm importovf

zur Verfügung.

Das Verfahren ist insbesondere interessant, wenn kein direkter Zugriff auf den ESXi-Host möglich ist.

Schritt 34: VMDK manuell importieren

Auch vorhandene VMware-VMDK-Dateien können in eine neu angelegte Proxmox-VM importiert werden.

Der grundsätzliche Ablauf:

VMDK bereitstellen

↓

VM in Proxmox erstellen

↓

Disk importieren

↓

Disk an VM anbinden

↓

Boot konfigurieren

↓

Treiber anpassen

Diese Methode bietet viel Kontrolle, erfordert aber mehr manuelle Arbeit.

Schritt 35: Backup-Software nach der Migration anpassen

VMware-Backups funktionieren nicht automatisch weiter.

Eine Backupsoftware, die bisher:

vCenter / ESXi

gesichert hat, muss nach der Migration:

Proxmox VE

unterstützen.

Alternativ kann beispielsweise:

Proxmox Backup Server

eingesetzt werden.

Vor Abschaltung von VMware sollte die neue Backupstrategie bereits funktionieren.

Proxmox Backup Server einplanen

Proxmox Backup Server bietet eine enge Integration mit Proxmox VE.

Damit können virtuelle Maschinen und Container gesichert werden.

Zu den Funktionen gehören unter anderem:

• inkrementelle Sicherungen
• Deduplizierung
• Komprimierung
• Verschlüsselung
• Pruning
• Verifikation

Für eine neue Proxmox-Infrastruktur sollte das Backup deshalb von Anfang an Bestandteil der Architektur sein.

Backup vor VMware-Abschaltung testen

Nach der Migration:

1. Backup einer Proxmox-VM erstellen
2. Restore durchführen
3. VM starten
4. Anwendung testen

Erst dann weiß man, ob die neue Sicherungsstrategie tatsächlich funktioniert.

Schritt 36: Monitoring umstellen

Bisherige Monitoring-Systeme überwachen möglicherweise:

• ESXi
• vCenter
• VMware Tools

Nach der Migration müssen neue Checks eingerichtet werden.

Beispielsweise:

• Proxmox Nodes
• Cluster
• Storage
• ZFS
• Ceph
• Backup
• VMs
• QEMU Guest Agent
• SMART
• Netzwerk

Monitoring sollte Bestandteil der Migration sein und nicht erst Monate später ergänzt werden.

Schritt 37: Hochverfügbarkeit neu planen

VMware HA beziehungsweise DRS lassen sich nicht einfach als Konfiguration nach Proxmox übernehmen.

Die entsprechende Architektur muss neu aufgebaut werden.

Dazu gehören beispielsweise:

• Proxmox Cluster
• Quorum
• Storage
• HA Groups beziehungsweise HA-Regeln
• Netzwerkredundanz
• Fencing
• Backup

Die Funktionsweise ist nicht identisch zu VMware.

VMware HA und Proxmox HA nicht eins zu eins gleichsetzen

Beide Plattformen können hochverfügbare Virtualisierungsumgebungen bereitstellen.

Die Architektur und Funktionsweise unterscheiden sich jedoch.

Eine VMware-Konfiguration sollte deshalb nicht blind kopiert werden.

Stattdessen sollte die Zielarchitektur anhand der Anforderungen neu geplant werden.

Schritt 38: vMotion und Proxmox Live Migration

VMware verwendet:

vMotion

Proxmox bietet:

Live Migration

Damit können laufende VMs zwischen Cluster-Nodes verschoben werden.

Die Voraussetzungen hängen unter anderem von:

• Storage
• CPU-Kompatibilität
• Netzwerk
• Cluster

ab.

Wer bisher intensiv vMotion nutzt, sollte die entsprechenden Proxmox-Szenarien vor der Migration testen.

Schritt 39: Performance vergleichen

Nach der Migration sollten Messwerte verglichen werden.

Beispielsweise:

• CPU
• RAM
• Storage-Latenz
• IOPS
• Netzwerk
• Anmeldezeit
• Datenbankperformance
• Backupdauer

Subjektive Aussagen wie:

„Fühlt sich ungefähr gleich schnell an.“

reichen bei geschäftskritischen Systemen nicht immer aus.

Schritt 40: VMware nicht sofort abschalten

Nach erfolgreicher Migration würde ich die VMware-Infrastruktur nicht unmittelbar löschen.

Besser:

Proxmox produktiv

↓

mehrere Tage kontrollieren

↓

Backups prüfen

↓

Monitoring prüfen

↓

Anwendungen abnehmen

↓

erst danach VMware endgültig außer Betrieb nehmen

Dabei dürfen die alten VMware-VMs natürlich nicht versehentlich parallel produktiv gestartet werden.

Reihenfolge einer VMware-zu-Proxmox-Migration

Eine mögliche Reihenfolge:

Phase 1 – Analyse

• VMware inventarisieren
• VMs bewerten
• Anwendungen dokumentieren
• Abhängigkeiten erfassen
• Netzwerk dokumentieren
• Storage dokumentieren

Phase 2 – Proxmox aufbauen

• Hosts installieren
• Cluster konfigurieren
• Storage einrichten
• Netzwerk einrichten
• VLANs testen
• Backup einrichten
• Monitoring einrichten

Phase 3 – Testmigration

• unkritische VM
• Import testen
• VirtIO testen
• Netzwerk testen
• Backup testen
• Restore testen

Phase 4 – Vorbereitung Produktivsysteme

• Backup
• VMware Tools
• VirtIO-Treiber
• IP-Konfiguration
• BIOS/UEFI
• TPM/BitLocker
• Lizenzen
• Wartungsfenster
• Rollback

Phase 5 – Migration

• Dienste stoppen
• VM herunterfahren
• importieren
• starten
• Treiber prüfen
• Netzwerk konfigurieren
• Dienste testen

Phase 6 – Abnahme

• Anwendungen
• Benutzer
• Performance
• Backup
• Monitoring
• Security

Phase 7 – VMware abschalten

Erst nach erfolgreicher Abnahme.

Beispiel: Kleine VMware-Umgebung migrieren

Ausgangssituation:

ESXi01

mit:

• DC01
• FILE01
• RDS01
• SQL01
• APP01

Ziel:

PVE01

und:

PBS01

Eine mögliche Reihenfolge:

1. APP01

unkritisch – Testmigration

2. FILE01

Dateizugriffe prüfen

3. SQL01

Datenbank und Anwendung prüfen

4. RDS01

Benutzer und Anwendungen testen

5. DC01

Active Directory und DNS abschließend migrieren

Die konkrete Reihenfolge hängt jedoch von den tatsächlichen Abhängigkeiten ab.

Beispiel: VMware-Cluster zu Proxmox-Cluster

Ausgang:

3 × ESXi

↓

vCenter

↓

Shared Storage

Ziel:

3 × Proxmox VE

↓

Proxmox Cluster

↓

passendes Shared- beziehungsweise Distributed-Storage-Konzept

↓

Proxmox Backup Server

Hier sollte vor der ersten produktiven Migration bereits getestet sein:

• Quorum
• Clusterkommunikation
• Storage
• Live Migration
• HA
• Netzwerkredundanz
• Backup
• Restore

Wie viel Downtime entsteht bei der Migration?

Das hängt hauptsächlich ab von:

• Größe der VM
• Storage
• Netzwerkgeschwindigkeit
• Migrationsverfahren
• Anzahl der Disks
• Snapshots
• Importmethode

Eine kleine VM mit 100 GB kann relativ schnell übertragen sein.

Eine VM mit mehreren Terabyte benötigt möglicherweise erheblich länger.

Deshalb sollte die tatsächliche Übertragungsrate vorher getestet werden.

Live Import kann Downtime reduzieren

Bei geeigneten Umgebungen kann Proxmox Live Import die Dienstunterbrechung deutlich reduzieren.

Trotzdem entsteht eine gewisse Downtime, da die VMware-VM für die Migration ausgeschaltet wird.

Es handelt sich also nicht um eine klassische vollständig unterbrechungsfreie Live Migration zwischen VMware und Proxmox.

Migration mit 1 Gbit/s oder 10 Gbit/s?

Bei großen Datenmengen wird die Netzwerkanbindung schnell zum Flaschenhals.

Theoretisch bietet:

1 Gbit/s

etwa:

125 MB/s

brutto.

In der Praxis liegt die nutzbare Übertragungsrate darunter.

Bei mehreren Terabyte kann eine Migration deshalb viele Stunden dauern.

Eine schnelle Verbindung zwischen:

ESXi

und:

Proxmox

kann die Migrationszeit erheblich reduzieren.

Snapshots können den Import verlangsamen

Eine weitere häufige Ursache für unerwartet lange Migrationen sind VMware-Snapshots.

Deshalb vor dem Wartungsfenster prüfen und nach Möglichkeit bereinigen.

Nicht erst während der Migration feststellen, dass eine VM zehn alte Snapshots besitzt.

Die häufigsten Fallstricke bei VMware zu Proxmox

1. VMware Tools nicht vorher berücksichtigt

Nach der Migration lassen sie sich möglicherweise schwieriger entfernen.

2. VirtIO-Treiber fehlen

Windows erkennt die Bootdisk oder Netzwerkkarte nicht.

3. Falsches BIOS

VMware verwendet UEFI, Proxmox wurde mit SeaBIOS konfiguriert.

Die VM bootet nicht.

4. vTPM vergessen

BitLocker beziehungsweise andere TPM-abhängige Funktionen verursachen Probleme.

5. Recovery Key fehlt

Die verschlüsselte Windows-VM lässt sich nicht mehr entsperren.

6. Statische IP nicht dokumentiert

Nach der Migration fehlt das Netzwerk.

7. Alte virtuelle NIC blockiert IP-Adresse

Windows meldet die Adresse als bereits vergeben.

8. VLAN falsch zugeordnet

VM startet, ist aber nicht erreichbar.

9. VMware- und Proxmox-VM gleichzeitig online

Doppelte IP beziehungsweise Dateninkonsistenz.

10. Anwendungslizenz hängt an Hardware-ID

Anwendung verlangt nach der Migration eine erneute Aktivierung.

11. Hersteller unterstützt Proxmox nicht

Technisch funktioniert die VM, der Hersteller verweigert aber möglicherweise Support.

12. vSAN nicht berücksichtigt

Direkter ESXi-Import funktioniert für die dort liegenden Disks nicht wie erwartet.

13. Verschlüsselte VMDK

Import nicht möglich, solange die VMware-Verschlüsselung besteht.

14. Snapshots

Import dauert erheblich länger.

15. Backup erst nach der Migration geplant

VMs laufen auf Proxmox, besitzen aber keine funktionierende Sicherung.

16. Kein Rollback-Plan

Beim ersten Problem beginnt die Improvisation.

17. Alle VMs gleichzeitig migriert

Fehler lassen sich schwer eingrenzen.

18. Alle Domain Controller gleichzeitig migriert

Unnötiges Risiko für Active Directory und DNS.

19. Performance nicht getestet

Produktivsystem läuft, ist aber deutlich langsamer.

20. VMware zu früh gelöscht

Wichtiger Rückfallweg ist verloren.

VMware zu Proxmox migrieren – Best Practices

Erst analysieren, dann migrieren

Keine Migration ohne vollständige Bestandsaufnahme.

Test-VM zuerst

Den gesamten Ablauf an einer unkritischen VM durchführen.

Backup vor jeder produktiven VM

Nicht nur Snapshot.

VirtIO vorbereiten

Insbesondere bei Windows.

VMware Tools vorher behandeln

Wenn möglich noch auf VMware sauber entfernen.

Netzwerk dokumentieren

IP, Gateway, DNS, VLAN und MAC.

UEFI und TPM prüfen

Besonders bei modernen Windows-Systemen.

Recovery Keys sichern

Vor allem bei BitLocker.

Anwendungssupport prüfen

Nicht jede virtuelle Appliance unterstützt KVM beziehungsweise Proxmox offiziell.

Migration einzeln durchführen

VM für VM.

Direkt danach testen

Nicht erst am nächsten Morgen.

Backup sofort einrichten

Neue Plattform ohne Backup ist kein fertiges Projekt.

Monitoring umstellen

Proxmox muss genauso überwacht werden wie vorher VMware.

VMware zunächst erhalten

Bis die neue Umgebung vollständig abgenommen wurde.

Wann sollte man eine VM lieber neu installieren?

Nicht jede VM sollte konvertiert werden.

Ein Neuaufbau kann sinnvoller sein bei:

• sehr altem Betriebssystem
• beschädigtem System
• vielen Altlasten
• problematischen Treibern
• veralteter Partitionsstruktur
• unnötiger Software
• Architekturwechsel

Beispielsweise kann ein zehn Jahre alter Windows Server möglicherweise besser durch einen neuen:

Windows Server 2025

ersetzt werden, statt das komplette Altsystem auf die neue Plattform mitzunehmen.

Migration oder Neuaufbau?

Eine gute VMware-Ablösung besteht häufig aus einer Mischung.

Beispielsweise:

DC01

neu installieren und replizieren

FILE01

Daten migrieren

RDS01

neu als Windows Server 2025 aufbauen

SQL01

bestehende VM migrieren

Linux-Webserver

VM direkt importieren

Damit werden Altlasten nicht unnötig in die neue Umgebung übernommen.

Wie lange dauert eine VMware-zu-Proxmox-Migration?

Das hängt weniger von der Anzahl der VMs als von deren Komplexität ab.

Fünf einfache Linux-VMs können leichter sein als ein einzelner geschäftskritischer Windows-Server mit:

• SQL
• USB-Dongle
• Hardware-ID-Lizenz
• mehreren VLANs
• BitLocker
• 4 TB Daten

Deshalb sollte eine Migration immer anhand der tatsächlichen Systeme geplant werden.

Checkliste: VMware zu Proxmox migrieren

VMware analysieren

• ESXi Hosts
• vCenter
• VMs
• Betriebssysteme
• CPU
• RAM
• Disks
• Snapshots
• vSAN
• Verschlüsselung
• vTPM
• Passthrough

Netzwerk

• vSwitches
• Distributed Switches
• Port Groups
• VLANs
• IP-Adressen
• Gateways
• DNS
• MAC-Adressen
• MTU
• LACP

Anwendungen

• Herstellerfreigabe
• Lizenzierung
• Hardwarebindung
• Abhängigkeiten
• Datenbanken
• Service Accounts

Proxmox vorbereiten

• Nodes
• Cluster
• Storage
• Bridges
• VLANs
• CPU-Typ
• Backup
• Monitoring

Windows-VM vorbereiten

• Backup
• VMware Tools
• VirtIO-Treiber
• statische IP dokumentieren
• UEFI prüfen
• Secure Boot prüfen
• BitLocker prüfen
• Recovery Key sichern
• vTPM prüfen

Migration

• Wartungsfenster
• Benutzer informieren
• Anwendungen stoppen
• VM herunterfahren
• Import starten
• Storage zuweisen
• Netzwerk zuweisen
• VM starten

Nach der Migration

• Boot
• VirtIO
• Netzwerk
• QEMU Guest Agent
• Windows-Aktivierung
• Anwendungslizenzen
• Dienste
• Event Logs
• Performance
• Backup
• Monitoring

Abnahme

• Benutzer testen
• Anwendung testen
• Backup testen
• Restore testen
• Performance prüfen
• Dokumentation aktualisieren

VMware außer Betrieb nehmen

Erst wenn Proxmox vollständig produktiv und abgenommen ist.

Fazit: VMware zu Proxmox migrieren

Eine Migration von VMware zu Proxmox VE ist heute deutlich komfortabler als noch vor einigen Jahren.

Der integrierte ESXi-Importer kann viele virtuelle Maschinen direkt aus VMware übernehmen.

Trotzdem bleibt die Migration ein Infrastrukturprojekt.

Die größten Risiken liegen häufig nicht beim eigentlichen Kopieren der virtuellen Festplatte, sondern bei:

• VirtIO-Treibern
• Netzwerk
• VLANs
• UEFI
• vTPM
• BitLocker
• Anwendungslizenzen
• Storage
• Backup
• Herstellerfreigaben

Eine erfolgreiche Migration sollte deshalb nach dem Prinzip erfolgen:

Inventarisieren

↓

Zielarchitektur planen

↓

Backup erstellen

↓

Testmigration

↓

Produktiv-VM einzeln migrieren

↓

Anwendung testen

↓

Backup und Monitoring prüfen

↓

VMware erst später abschalten

Wer diese Reihenfolge einhält, kann das Risiko deutlich reduzieren und gleichzeitig verhindern, dass alte VMware-Altlasten ungeprüft in die neue Proxmox-Umgebung übernommen werden.

VMware zu Proxmox migrieren lassen

Sie möchten VMware ESXi beziehungsweise vSphere ablösen und Ihre virtuellen Server auf Proxmox VE migrieren?

Unetifi unterstützt kleine und mittelständische Unternehmen bei der Planung und Migration von VMware zu Proxmox.

Dazu können unter anderem gehören:

• Analyse der bestehenden VMware-Umgebung
• VMware ESXi
• vCenter
• Bestandsaufnahme der VMs
• Planung der Proxmox-Infrastruktur
• Proxmox VE Installation
• Cluster
• Storage
• ZFS
• Ceph
• Netzwerk
• VLANs
• Migration von Windows Servern
• Migration von Linux-Servern
• VirtIO
• QEMU Guest Agent
• Backup
• Proxmox Backup Server
• Monitoring
• Firewall
• Dokumentation
• laufende Wartung

Dabei wird nicht nur eine virtuelle Festplatte von VMware nach Proxmox kopiert.

Vor der Migration werden:

• Abhängigkeiten
• Netzwerk
• Storage
• Betriebssysteme
• Anwendungen
• Lizenzen
• Backup
• Wiederherstellung

betrachtet.

So entsteht eine Proxmox-Umgebung, die nicht nur unmittelbar nach der Migration funktioniert, sondern anschließend auch sauber betrieben, gesichert und erweitert werden kann.

Häufig gestellte Fragen zur Migration von VMware zu Proxmox

Kann man VMware ESXi zu Proxmox migrieren?

Ja. Proxmox VE unterstützt den Import virtueller Maschinen aus VMware ESXi. Zusätzlich können VMs beispielsweise über OVF/OVA oder den manuellen Import virtueller Festplatten migriert werden.

Kann Proxmox VMware VMs direkt importieren?

Ja. Aktuelle Proxmox-Versionen besitzen einen integrierten ESXi-Importer. Dabei kann ein ESXi-System als Importquelle eingebunden und eine vorhandene VM über die Proxmox-Oberfläche importiert werden.

Kann man über vCenter importieren?

Grundsätzlich ist auch ein Import über vCenter möglich. Proxmox weist allerdings darauf hin, dass dies die Importgeschwindigkeit deutlich reduzieren kann. Wenn möglich, kann eine direkte Verbindung zum ESXi-Host sinnvoller sein.

Kann ich eine VMware-VM ohne Downtime nach Proxmox migrieren?

Eine vollständig unterbrechungsfreie Migration zwischen ESXi und Proxmox sollte nicht vorausgesetzt werden. Auch beim Proxmox Live Import wird die Quell-VM auf ESXi ausgeschaltet. Die Ziel-VM kann jedoch bereits während des noch laufenden Datenimports gestartet werden, wodurch sich die Dienstunterbrechung reduzieren lässt.

Was ist Proxmox Live Import?

Beim Live Import werden zunächst die für den laufenden Gast benötigten Daten priorisiert übertragen. Die VM kann dadurch auf Proxmox gestartet werden, während weitere Daten im Hintergrund importiert werden.

Kann ich eine VMware-VM mit vSAN direkt importieren?

Beim integrierten ESXi-Import gibt es Einschränkungen für VMs beziehungsweise Disks auf VMware vSAN. Proxmox nennt als möglichen Workaround, die virtuelle Festplatte zunächst auf einen anderen Datastore zu verschieben.

Kann eine verschlüsselte VMware-VM importiert werden?

Verschlüsselte virtuelle VMware-Disks können nicht einfach direkt importiert werden. Die Verschlüsselung beziehungsweise entsprechende Storage Policy muss gegebenenfalls vorher auf VMware-Seite entfernt werden.

Was passiert mit VMware Tools nach der Migration?

VMware Tools werden auf Proxmox nicht mehr benötigt. Proxmox und Broadcom empfehlen, hypervisorspezifische VMware-Komponenten möglichst vor der Migration zu entfernen, da die Deinstallation nach dem Wechsel auf einen Fremd-Hypervisor problematisch sein kann.

Welche Treiber braucht Windows auf Proxmox?

Für eine performante Windows-VM werden typischerweise VirtIO-Treiber für Storage und Netzwerk verwendet. Diese sollten möglichst bereits vor beziehungsweise während der Migration vorbereitet werden.

Warum startet Windows nach der Migration nicht?

Häufige Ursachen sind ein fehlender VirtIO-Storage-Treiber, falscher Festplattenbus, falsche BIOS-/UEFI-Konfiguration oder Probleme mit Verschlüsselung beziehungsweise vTPM.

Was ist der QEMU Guest Agent?

Der QEMU Guest Agent verbessert die Kommunikation zwischen Proxmox und dem Gastbetriebssystem. Er sollte nach erfolgreicher Migration innerhalb der VM installiert und in der VM-Konfiguration aktiviert werden.

Bleibt die IP-Adresse bei der Migration erhalten?

Die IP-Adresse kann weiterhin verwendet werden. Windows erkennt die neue virtuelle Netzwerkkarte jedoch möglicherweise als neues Gerät. Die bisherige statische IP-Konfiguration muss deshalb gegebenenfalls erneut gesetzt werden.

Kann ich die MAC-Adresse einer VMware-VM übernehmen?

In bestimmten Fällen kann dies sinnvoll sein, beispielsweise bei DHCP-Reservierungen oder MAC-abhängigen Systemen. Alternativ müssen die entsprechenden Abhängigkeiten auf die neue MAC-Adresse angepasst werden.

Kann ich Domain Controller von VMware zu Proxmox migrieren?

Grundsätzlich ja. Bei mehreren Domain Controllern sollten diese jedoch nicht alle gleichzeitig migriert werden. Active Directory, DNS, Replikation und Zeitdienst sollten nach jeder Migration geprüft werden.

Kann ich Windows Server 2025 von VMware zu Proxmox migrieren?

Ja, sofern die VM und die eingesetzten Anwendungen mit der Zielumgebung kompatibel sind. Besonders VirtIO-Treiber, UEFI, TPM beziehungsweise BitLocker, Netzwerk und Anwendungslizenzierung sollten vorab geprüft werden.

Kann ich eine VMDK in Proxmox importieren?

Ja. VMware-VMDK-Dateien können manuell in eine Proxmox-VM importiert werden. Anschließend müssen VM-Hardware, Bootreihenfolge, Controller und Netzwerk passend konfiguriert werden.

Kann Proxmox OVF und OVA importieren?

Ja. Proxmox unterstützt den Import von OVF/OVA. Für OVF steht unter anderem qm importovf zur Verfügung.

Sollte ich jede VMware-VM migrieren?

Nein. Bei alten oder stark belasteten Systemen kann ein Neuaufbau sinnvoller sein. Eine Migration ist eine gute Gelegenheit, veraltete Server, Testsysteme und unnötige Altlasten auszusortieren.

Brauche ich nach der Migration ein neues Backup?

Ja. Eine bisher auf VMware beziehungsweise vCenter ausgerichtete Backupstrategie muss für Proxmox angepasst werden. Beispielsweise kann Proxmox Backup Server eingesetzt werden.

Wann kann VMware nach der Migration abgeschaltet werden?

Erst wenn alle produktiven VMs abgenommen wurden, Anwendungen funktionieren, Backup und Restore getestet wurden und Monitoring eingerichtet ist. Die alten VMware-VMs sollten während dieser Übergangsphase ausgeschaltet bleiben, damit keine doppelten produktiven Systeme entstehen.