Warum IT-Teams VMware zu Proxmox migrieren
Die Entscheidung, VMware zu Proxmox zu migrieren, ergibt sich aus einem grundlegenden Wandel der wirtschaftlichen Rahmenbedingungen und der Offenheit der Plattformen am Markt.
Hohe VMware-Abonnementkosten und Nachteile durch Herstellerbindung
Nach der Übernahme durch Broadcom stehen Unternehmen vor drei zentralen betrieblichen Belastungen:
- Abschaffung dauerhafter Lizenzen: Langfristige Standardinvestitionen wurden unvermittelt auf kostenintensive obligatorische Abonnementmodelle umgestellt.
- Aggressive Produktbündelung: Eigenständige, essentielle Hypervisor-Funktionen wurden zu kostenpflichtigen Unternehmenspaketen zusammengefasst, sodass Unternehmen für nicht benötigte Zusatzsoftware zahlen müssen.
- Exponentiell steigende Gesamtbetriebskosten: Diese kommerziellen Umstrukturierungen ließen die Gesamtbetriebskosten (TCO) über ein tragbares Niveau steigen – die Diversifizierung der Plattformen wurde zu einer dringenden betrieblichen Notwendigkeit.
Laut der offiziellen Proxmox VE-Dokumentation bieten die integrierten Migrationswerkzeuge für viele Anwendungsfälle eine kostenlose Alternative.
Kernarchitektonische Unterschiede zwischen VMware ESXi und Proxmox VE
- VMware ESXi / vSphere: Basiert auf einem proprietären monolithischen Kernel (VMkernel). Erweiterte Funktionen wie Cluster, verteiltes Netzwerk und softwaredefinierter Speicher (vSAN) sind nur mit teuren Premium-Lizenzen verfügbar.
- Proxmox VE (PVE): Direkt auf dem stabilen Hauptzweig von Debian Linux aufgebaut. Es kombiniert nativ KVM für Bare-Metal-Hypervisor-Leistung mit LXC für extrem leichtgewichtige Container. Unternehmenscluster, ZFS und verteilter Ceph-Speicher sind ab Werk vollständig funktionsfähig – ohne Lizenzgebühren.
VMware im Vergleich zu Proxmox: Kostenvergleich (2026)
Abgesehen von den Lizenzen fällt der Unterschied der Gesamtbetriebskosten über fünf Jahre enorm aus, wenn man Support, Schulungen und Hardware-Austauschzyklen berücksichtigt.
| Kostenpunkt |
VMware vSphere Standard (pro Sockel) |
Proxmox VE Abonnement (pro Sockel) |
| Basis-Lizenz (jährlich) |
950 – 1.200 US-Dollar |
0 US-Dollar (Community) / 200 US-Dollar (Basis-Support) |
| Produktionssupport (jährlich) |
Im Abonnement enthalten |
600 US-Dollar (Enterprise-Support) |
| vSAN / Ceph Speicherlizenz |
Zusätzlich über 2.000 US-Dollar pro Knoten |
Inbegriffen (Ceph) |
| Schulungen & Zertifizierungen |
3.000 – 5.000 US-Dollar pro Administrator |
Kostenlose Online-Ressourcen + Community |
| Geschätzte Gesamtkosten über 5 Jahre (10-Knoten-Cluster) |
180.000 – 220.000 US-Dollar |
45.000 – 60.000 US-Dollar |
* Preise variieren je Region und Mengenrabatt. Das Proxmox-Abonnement beinhaltet den Zugriff auf das Enterprise-Repository sowie Support mit vereinbartem Servicelevel.
Voraussetzungen vor der Migration von VMware zu Proxmox
Für eine reibungslose Migration müssen Administratoren diese wichtigen Vorprüfungen durchführen:
- Aktualisierung von VMware Tools: Stellen Sie sicher, dass VMware Tools auf der Quell-VM in der aktuellsten Version installiert ist. Nach abgeschlossener Migration deinstallieren Sie VMware Tools und ersetzen es durch VirtIO-Treiber sowie den QEMU-Gastagenten.
- Dokumentation der Netzwerktopologie: Notieren Sie alle statischen IP-Adressen, Subnetze, Gateways und MAC-Adressen, um eine nahtlose Netzwerkzuordnung bei geänderten Schnittstellennamen nach der Migration sicherzustellen.
- Zusammenführen von VM-Snapshots: Übernehmen und löschen Sie alle aktiven Snapshots in vSphere, um Delta-Dateien zusammenzuführen. Dadurch werden Festplattenbeschädigungen und Fehler beim Import-Assistenten verhindert.
- Durchführung einer unabhängigen Sicherung: Erstellen Sie eine vollständige unveränderliche Sicherung der Produktionsdaten getrennt vom Migrationswerkzeug, um bei Bedarf einen sofortigen Rollback zu ermöglichen.
Kompatibilitätscheckliste vor der Migration
✅ CPU-Kompatibilität: Stellen Sie sicher, dass die CPU des Proxmox-Hosts dieselben Befehlssätze (beispielsweise AVX, SSE) unterstützt wie der ursprüngliche VMware-Host. Überprüfen Sie dies mit dem Befehl qm showcmd <VM_ID> --pretty .
✅ Speichercontroller: Prüfen Sie, ob die Quell-VM SCSI-Controller (wie LSI Logic SAS) nutzt. Proxmox ordnet diese standardmäßig VirtIO-SCSI zu – vergewissern Sie sich, dass das Gastbetriebssystem passende Treiber mitbringt.
✅ Netzwerkschnittstelle: VMwares VMXNET3 wird von Proxmox nicht nativ erkannt. Planen Sie während der Migration einen Austausch gegen VirtIO oder E1000 ein.
✅ UEFI/BIOS-Modus: Der Import-Assistent behält den Boot-Modus bei. Bei manueller OVF-Verwendung stellen Sie sicher, dass die BIOS-Einstellung der Ziel-VM mit der Quelle übereinstimmt (UEFI oder Legacy).
Methode 1: Nutzung des nativen Proxmox VE ESXi-Import-Assistenten (empfohlen)
Proxmox VE verfügt über ein integriertes grafisches Werkzeug, das per API direkt eine Verbindung zu vCenter oder ESXi herstellt und Daten ohne manuelle Festplattenexporte überträgt.
Schritt 1: Herstellen der Verbindung zur VMware-Infrastruktur
Navigieren Sie in der Proxmox-Weboberfläche zu Rechenzentrum – Speicher – Hinzufügen – ESXi . Dadurch wird eine aktive API-Verbindung aufgebaut; in diesem Schritt werden keine Daten auf VMware verschoben oder verändert.
Schritt 2: Authentifizieren der Verbindung
Geben Sie die IP/FQDN des ESXi/vCenter-Servers, Benutzername und Passwort ein – Aktivieren Sie Zertifikatsprüfung überspringen (bei selbst signierten Zertifikaten) – Klicken Sie auf Hinzufügen.
Schritt 3: Auffinden der Ziel-VMs
Klicken Sie auf den neu hinzugefügten ESXi-Speicherknoten im linken Menübaum, um die aktuelle VM-Bestandsliste anzuzeigen.
Schritt 4: Zuordnen von Ressourcen und Zielkonfigurationen
Wählen Sie die Ziel-VM aus – Klicken Sie oben im Menü auf Importieren – Wählen Sie Ihren Ziel-Speicherpool (ZFS, Ceph oder LVM-Thin) – Legen Sie die Ziel-Netzwerkbrücke fest.
Schritt 5: Ausführen der Konvertierung
Klicken Sie abschließend auf die Schaltfläche Importieren . Proxmox streamt nun die VMDK-Daten über das Netzwerk und wandelt sie im Hintergrund in native QCOW2-/RAW-Festplattenformate um.
- ★Tipp:
- Der Import-Assistent unterstützt serielle Stapelverarbeitung. Sie können mehrere VMs auswählen, diese werden nacheinander zur Einfuhr eingereiht. Jede VM erfordert während der Datenübertragung ein eigenes Ausfallfenster.
Methode 2: Manuelle V2V-Migration per OVF/OVA-Export (optimal für abgetrennte Netzwerke)
Wenn abgeschottete Netzwerke oder strenge Firewall-Regeln eine direkte API-Kommunikation zwischen den Hypervisoren verhindern, ist der manuelle Export im Open Virtualization Format (OVF) die sicherste Alternative.
Schritt 1: Export der Vorlage aus vSphere
Fahren Sie die Quell-VM herunter – Rechtsklick auf die VM – Wählen Sie Vorlage – Klicken Sie auf OVF-Vorlage exportieren – Laden Sie die Dateien .ovf und .vmdk auf Ihren lokalen Rechner herunter.
Schritt 2: Übertragen der Dateien auf den Proxmox-Knoten
Öffnen Sie einen SCP- oder WinSCP-Client – Verbinden Sie sich mit Ihrem Proxmox VE-Knoten – Laden Sie alle heruntergeladenen Dateien direkt in ein temporäres Verzeichnis hoch (beispielsweise /var/lib/vz/images/).
Schritt 3: Zugriff auf die Proxmox-Befehlszeile
Stellen Sie eine SSH-Verbindung zum Proxmox VE-Knoten her oder öffnen Sie die Shell über die Proxmox-Weboberfläche.
Schritt 4: Ausführen des Befehls zum Import und zur Festplattenumwandlung
Führen Sie den nativen Befehl qm importovf aus, um die VM zu erstellen und das Festplattenformat umzuwandeln. Prüfen Sie Ihre Proxmox-Version mit pveversion -v – ältere Versionen nutzen den Parameter --format, neuere Releases hingegen --disk-format.
# Für Proxmox VE 8.0 und neuer:
qm importovf <vm_id> /pfad/zur/exportierten.ovf <speicherpool> --disk-format qcow2
# Beispiel: Bereitstellen der VM-ID 101 auf dem local-zfs-Pool
qm importovf 101 /var/lib/vz/images/server.ovf local-zfs --disk-format qcow2
Hauptnachteile nativer Kaltmigrationen
Obwohl die hypervisoreigenen Werkzeuge kostenlos sind, bringen sie erhebliche technische Einschränkungen mit sich, die die Migration von Unternehmensinfrastrukturen erschweren:
- Strenge Netzwerkanforderungen: Es ist eine direkte, ungeteilte API- und Port-Verbindung zwischen VMware- und Proxmox-Hosts erforderlich, die in sicheren Netzwerken oft blockiert wird.
- Zwingende Ausfallzeit im Produktivbetrieb: Die ursprüngliche VMware-VM muss während langer Netzwerkübertragungen vollständig heruntergefahren werden, um Datenkonsistenz zu gewährleisten.
- Keine fortsetzbare Synchronisation: Es fehlt eine Funktion zum Prüfpunkts-Neustart bei Netzwerkunterbrechungen; jeder Verbindungsabbruch erfordert einen vollständigen Neustart der Festplattenkopie von 0 %.
- Keine automatisierte Treiberinjektion: Das Gastbetriebssystem erhält keine automatische Anpassung der Speichercontroller. Dies führt beim ersten Start häufig zu Boot-Schleifen oder Bluescreens.
- Schlechte Skalierbarkeit für Unternehmen: Es gibt keine zentralisierte Automatisierung; Administratoren müssen jede VM einzeln manuell konfigurieren und migrieren.
Ausfallfreie Unternehmensmigration mit i2Migration
Um die Grenzen nativer Kaltübertragungen zu umgehen, nutzen Unternehmensumgebungen i2Migration. Durch die Installation eines leichtgewichtigen Replikationsagenten direkt im Gastbetriebssystem einer laufenden VMware-VM ermöglicht die Plattform eine nahtlose blockbasierte Synchronisation nach Proxmox VE ohne Betriebsunterbrechungen.
- Hypervisor-unabhängig: Läuft innerhalb des Gastbetriebssystems und umgeht komplexe Hypervisor-Ebenen. Es sind keine übergreifenden vCenter-Vertrauensstellungen, Netzwerkberechtigungen oder übereinstimmende CPU-Grundeinstellungen erforderlich.
- Kontinuierliche bytegenaue Synchronisation: Die Quell-VM bleibt während der Datenübertragung online. Echtzeit-Schreibvorgänge werden permanent gespiegelt, sodass der endgültige Wechsel nur wenige Sekunden dauert.
- WAN-optimiert & fortsetzbar: Integrierte Kompression, Deduplizierung und Prüfpunkts-Neustart sorgen für stabile Übertragungen über entfernte oder bandbreitenarme Netzwerke.
- Automatisierte Treiberinjektion: Es übernimmt die Umwandlung von VMDK nach QCOW2/RAW und injiziert vor dem Wechsel dynamisch VirtIO-Treiber, um Bluescreens oder Boot-Fehler zu vermeiden.
- Stapel-Orchestrierung & Rollback: Unterstützt automatisierte Zeitpläne für hunderte VMs gleichzeitig, während die ursprüngliche VMware-VM als sofortige Ausweichmöglichkeit unverändert erhalten bleibt.
Auswahl der passenden Migrationsmethode
| Kriterium |
Nativer Proxmox-Import / OVF |
Agentenbasiert (i2Migration) |
| Einsatzbereich |
Test-, Entwicklungs- und nicht-produktive VMs |
Geschäftskritische Produktionsworkloads |
| Ausfallzeit |
Kaltausfall (Minuten bis Stunden) |
Nahezu keine Ausfallzeit (Sekunden) |
| Netzwerkanforderungen |
Direkt, geringe Latenz |
WAN-optimiert, unterstützt Proxys |
| Treiberinjektion |
Manuell |
Automatisiert |
| Kosten |
Kostenlos |
Kauf-Lizenz |
Optimierungen nach der Migration & Leistungsbenchmarks
Nach abgeschlossener VM-Migration von VMware zu Proxmox führen Sie diese kurzen Konfigurationen durch, um die native paravirtualisierte Leistung freizuschalten:
- Aktualisierung des Speicherbusses (VirtIO SCSI): Ändern Sie den Festplattenbustyp der VM im Hardware-Bereich von altem IDE/SATA auf VirtIO SCSI. Dadurch sinkt die CPU-Last drastisch und der E/A-Durchsatz steigt maximal an.
- Installation von VirtIO-Treibern (nur Windows) – sicheres Vorgehen:
⚠️ Wichtig für Windows-VMs: Bevor Sie zu VirtIO SCSI wechseln, booten Sie die VM einmal mit SATA- oder IDE-Festplattenbus. Installieren Sie die VirtIO-Treiber in diesem sicheren Modus, fahren Sie anschließend herunter, stellen Sie den Bustyp wieder auf VirtIO SCSI um und starten Sie neu. Dadurch wird der Bluescreen „Inaccessible Boot Device“ verhindert.
Nach dem Wechsel hängen Sie die offizielle stabile VirtIO-Win-ISO an das virtuelle CD-Laufwerk an, öffnen Sie den Windows-Geräte-Manager und aktualisieren alle markierten Controller (Speicher, Ethernet, PCI), indem Sie auf die ISO verweisen.
- Aktivierung des QEMU-Gastagenten: Installieren Sie den Agent-Dienst (
sudo apt/dnf install qemu-guest-agent unter Linux oder Ausführung von virtio-win-guest-agent.exe unter Windows). Aktivieren Sie anschließend im Reiter „Optionen“ der VM die Einstellung QEMU-Gastagent – Aktiviert , um sauberes ACPI-Herunterfahren und korrekte IP-Anzeigen sicherzustellen.
- Neuzuordnung der Netzwerkschnittstellen: Ersetzen Sie veraltete Netzwerkschnittstellen durch das leistungsstarke paravirtualisierte VirtIO-Netzwerkgerät. Weisen Sie anschließend im Gastbetriebssystem die dokumentierten statischen IP-Adressen der neu erkannten Netzwerkkarte zu.
Leistungsbenchmark: VMware im Vergleich zu Proxmox (nach Optimierung)
| Messwert |
VMware ESXi (Standardeinstellungen) |
Proxmox VE (mit VirtIO optimiert) |
| Festplatten-IOPS (4K Zufallslesevorgänge) |
ca. 25.000 |
ca. 28.000 |
| Netzwerkdurchsatz (Gbit/s) |
9,8 |
10,2 |
| CPU-Last (VM im Leerlauf) |
ca. 2–3 % |
ca. 1–2 % |
* Ergebnisse basieren auf internen Tests mit identischer Hardware (2 × Xeon Gold, NVMe-Speicher). Die tatsächliche Leistung hängt von der jeweiligen Workload ab.
Rollback-Plan: Was tun, wenn die Migration fehlschlägt?
❌ Warnung:
✅ Vor dem Produktivwechsel: Bei einem Synchronisationsfehler beheben Sie einfach das Problem (Netzwerk/Treiber) und setzen den Vorgang fort – die Quell-VM bleibt unverändert.
✅ Innerhalb von 24 Stunden nach dem Wechsel: Fahren Sie die Proxmox-VM herunter und starten Sie die ursprüngliche VMware-VM neu. Aktualisieren Sie bei Bedarf DNS-/ARP-Caches. Dies ist das sicherste Rollback-Fenster.
✅ Nach mehr als 24 Stunden: Wenn viele Änderungen angefallen sind, nutzen Sie die Rücksynchronisierungsfunktion von i2Migration (falls aktiviert), um Daten von Proxmox zurück nach VMware zu synchronisieren – oder stellen Sie die vor der Migration erstellte unabhängige Sicherung wieder her.
Häufig gestellte Fragen zur Migration von VMware zu Proxmox
Kann ich VMware kostenlos zu Proxmox migrieren?
Ja, Proxmox VE verfügt über einen nativen ESXi-Import-Assistenten, der vollständig kostenlos ist. Er eignet sich für nicht-produktive VMs mit geplanten Ausfallfenstern. Für ausfallfreie Produktionsmigrationen empfehlen Sie agentenbasierte Werkzeuge wie i2Migration.
Ist eine Live-Migration von VMware zu Proxmox ohne Ausfallzeit möglich?
Nur mit agentenbasierten Werkzeugen. Die nativen Proxmox-Werkzeuge erfordern ein kaltes Herunterfahren oder kurze Unterbrechungen. Echte ausfallfreie Replikation erfordert eine Gastagent-Lösung wie i2Migration, um die VM bis zum nur wenige Sekunden dauernden endgültigen Wechsel aktiv zu halten.
Was passiert mit VMware Tools nach der Migration?
Nach abgeschlossener Migration sollten Sie VMware Tools deinstallieren und durch VirtIO-Treiber sowie den QEMU-Gastagenten ersetzen. Nicht entfernte veraltete VMware-Tools-Dienste können Boot-Schleifen oder Treiberkonflikte auslösen.
Unterstützt der Proxmox-Import-Assistent Massenstapel-Migrationen?
Ja, jede VM benötigt jedoch ein eigenes Ausfallfenster. Der Assistent erlaubt die Auswahl mehrerer VMs und reiht die Importe nacheinander ein, sodass Sie die Migration stufenweise durchführen können. Für Produktivumgebungen empfehlen wir zuerst nicht kritische VMs zu migrieren, um den Ablauf zu prüfen.
Wie behebe ich den Windows-Bluescreen „Inaccessible Boot Device“?
Booten Sie mit legacy-Emulation, um den Treiber einzuspielen: Ändern Sie in Proxmox den Festplattenbustyp der VM auf SATA oder IDE und starten Sie die VM. Installieren Sie unter Windows das stabile Proxmox-VirtIO-Treiberpaket. Fahren Sie herunter, stellen Sie den Bustyp wieder auf VirtIO SCSI um und starten Sie neu.
Fazit
Die Migration von VMware ESXi zu Proxmox VE ist eine äußerst wirkungsvolle Maßnahme, um stark steigende Lizenzgebühren abzuschaffen und die Eigenverantwortung für die Infrastruktur zurückzuerlangen. Für unkritische Umgebungen mit flexiblen Wartungsfenstern bieten die nativen agentenfreien Werkzeuge einen direkten, kostenlosen Übergang.
Für Unternehmensumgebungen mit hochverfügbaren Workloads empfehlen Sie ein gestuftes V2V-Vorgehen: Erstellen Sie zunächst produktionsreife Proxmox-Cluster, validieren Sie kleine unkritische VMs per hypervisoreigenem Import und setzen Sie anschließend das agentenbasierte i2Migration ein, um zentrale Produktionsworkloads ohne Geschäftsunterbrechungen zu migrieren.
Von:
