Proxmox vs. VMware: Migration anhand eines Praxisbeispiels

Seit der Broadcom-Übernahme von VMware ist Migration kein theoretisches Thema mehr — sondern für viele KMU bittere Notwendigkeit. Wir haben in den letzten 18 Monaten mehrere Migrationsprojekte begleitet; eines davon dient hier als anonymisierte Fallstudie. Der Kunde: ein produzierender Mittelständler, rund 80 Mitarbeiter, vSphere 7.0 mit zwei ESXi-Hosts und einem vCenter, klassischer FC-SAN-Storage. Die zu migrierende Last: 30 produktive VMs plus ein paar Test-Systeme.

Was am Ende dabei rauskommt, ist nicht “Proxmox ist besser als VMware” — sondern eine ehrliche Schritt-für-Schritt-Dokumentation. Wallclock-Zeiten geben wir als ungefähre Größenordnungen an, keine erfundenen Stoppuhr-Zahlen.

Ausgangslage

• Hardware: 2× Dell PowerEdge R740 (je 2× Xeon Gold 6230, 384 GB RAM), 1× Dell EMC Unity 380F (FC-SAN, all-NVMe)
• vSphere: 7.0 U3, klassische 3-Lizenz-Box (zwei Hosts plus vCenter)
• VMs: 30 produktiv, davon 6 Linux-Server (Webdienste, Datenbanken), 18 Windows-Server (Fileserver, AD, Exchange, ERP), 6 Windows-Clients (RDP-Hosts)
• Datenvolumen: rund 14 TB belegt, 22 TB provisioniert
• Backup: Veeam B&R 12 auf separates Synology NAS

Der Auslöser für die Migration: Die Broadcom-Lizenz-Verlängerung hätte gegenüber den bisherigen Kosten eine mehrfache Steigerung bedeutet — verbunden mit der Pflicht, auf die neue VMware Cloud Foundation umzusteigen. Das war für ein 80-Mann-Unternehmen schlicht unverhältnismäßig.

Zielarchitektur

Wir haben uns mit dem Kunden für folgendes Setup entschieden:

• 3× Proxmox VE 9.0 Nodes auf vorhandener Dell-Hardware (zwei bisherige ESXi-Hosts plus ein zusätzlicher Node aus dem Demo-Pool)
• Cluster mit Corosync-Quorum, HA aktiviert
• Storage: zunächst das bestehende Unity 380F direkt weiter als FC-SAN unter LVM-Thin, parallel Aufbau eines neuen TrueNAS R30 als ZFS-Storage für künftige Workloads
• Proxmox Backup Server auf separater Hardware, Replikation zum Synology-NAS als zweite Schiene
• PVE-Netzwerk: redundante 25-GbE-Anbindung, separates VLAN für Corosync, separates für Storage

Das war bewusst eine konservative Migration: keine gleichzeitige Storage-Umstellung, kein neues Backup-Tool, keine VM-Restrukturierung. Eins nach dem anderen.

Phase 1: Inventur

Eine Migration scheitert nicht an Proxmox — sondern an unentdeckten Abhängigkeiten. Wir haben deshalb vor jeder anderen Aktivität eine sehr detaillierte Inventur durchgeführt:

Aspekt	Erfasst
VM-Liste	Name, OS, vCPU, RAM, Disk-Größe, IP, MAC, VLAN
Snapshots	Anzahl, Alter, Zweck (oft “vergessen seit 2022”)
VM-Tools	VMware Tools installiert? Version?
Hardware-Versionen	VMX-Compat-Level (typisch 14–17)
Lizenzen	Pro VM: welche Software, welches Lizenzmodell (oft MAC-gebunden!)
Backup-Status	Letztes erfolgreiches Backup, Restore-Test ja/nein
Abhängigkeiten	DNS-, AD-, Datenbank-Abhängigkeiten

Allein dieser Schritt hat etwa zwei Arbeitstage gekostet — und uns vor mehreren bösen Überraschungen bewahrt. Drei der 30 VMs hatten Lizenzen, die an die VMware-UUID gebunden waren und beim Restore-Test als illegitim galten. Eine VM hatte 14 vergessene Snapshots aus einem Update-Versuch von 2022.

Phase 2: Lab-Test

Bevor produktive Daten irgendwohin wandern, haben wir auf einem dritten Proxmox-Node parallel zur Produktion das gesamte Verfahren mit zwei unkritischen Test-VMs durchgespielt:

1. Aktuelles Veeam-Backup der Test-VMs prüfen
2. Methode A: Veeam Instant Recovery auf Proxmox — Veeam Backup & Replication 12.2+ unterstützt PVE als Recovery-Target
3. Methode B: pve-vmware-import — Tool aus dem PVE-Paket, das direkt aus ESXi importiert
4. Methode C: OVF-Export → qm importovf — der klassische manuelle Pfad

Resultat: Methode A erwies sich als die schnellste und zuverlässigste, weil das Backup-Konsistenz-Sigel von Veeam erhalten bleibt und der Restore-Test gleich ein Funktionstest ist. Methode B funktioniert für einfache VMs, hatte aber Probleme mit dem Mapping mehrerer Disk-Controller. Methode C ist universell, aber pro VM mit deutlich mehr Handarbeit verbunden.

Phase 3: Pilot

Wir haben fünf VMs niedriger Priorität als Pilot ausgewählt — alle Linux, alle mit etablierter Backup-Praxis, alle ohne harte SLAs:

• 2× interne Web-Anwendungen
• 1× Test-Datenbank
• 1× CI/Build-Server
• 1× internes Monitoring (Grafana)

Migration in einem Wartungsfenster Samstagvormittag. Vorgehen:

1. Final Veeam-Backup
2. VM in vSphere heruntergefahren
3. Veeam-Instant-Recovery auf Proxmox-Node, neuer Disk-Storage am LVM-Thin
4. VMware Tools deinstallieren, QEMU Guest Agent installieren
5. Netzwerk-Bridge im PVE auf das richtige VLAN setzen
6. Hochfahren, Funktionstest
7. DNS/DHCP: ggf. neue MAC eintragen

Sechs Stunden später waren die fünf VMs sauber live. Über die Folgewoche haben wir laufend beobachtet — keine kritischen Probleme. Ein Detail kam später zum Vorschein: Der CI-Server hatte vor der Migration eine durchschnittliche Build-Zeit gehabt, die nach der Migration leicht zugenommen hat. Ursache: ZFS-Komprimierung auf dem neuen TrueNAS war noch nicht aktiv, später korrigiert.

Phase 4: Hauptmigration

Die verbleibenden 25 VMs haben wir auf zwei Wochenenden verteilt, gruppiert nach Abhängigkeit:

Wochenende 1: Infrastruktur-VMs

• Active Directory (beide DCs, einzeln nacheinander)
• DNS/DHCP, File-Cluster, Print-Server
• Backup-Proxy-VM (selbst-referenzieller Schritt, vorab Plan B besprochen)

Wochenende 2: Anwendungs-VMs

• ERP, Exchange, RDP-Hosts, Datenbank-Server

Wir haben pro Wochenende ein Wartungsfenster von Freitagabend bis Sonntagabend angesetzt und auf eine Cutover-Reihenfolge geachtet: Erst die Plattform-Dienste (AD, DNS), dann darauf aufbauend die Anwendungen. Größenordnung pro VM: 30–90 Minuten Wallclock je nach Größe und Restore-Geschwindigkeit. Genaue Stoppuhr-Zahlen sparen wir uns — sie sagen für andere Setups nichts aus.

Zwischen Wochenende 1 und 2 lief die Umgebung hybrid: einige Dienste auf Proxmox, andere noch auf VMware. Das geht über zwei, drei Tage, aber nicht über Wochen — die Komplexität wird sonst untragbar.

Phase 5: Cutover und Stilllegung

Nach dem zweiten Wochenende:

1. Letzte vollständige Veeam-Sicherung der gesamten alten Umgebung als Disaster-Rückfallnetz
2. vSphere für zwei Wochen “kalt halten” — Hosts heruntergefahren, vCenter offline, aber wiederherstellbar
3. Nach den zwei Wochen: vSphere-Daten archiviert, Hosts neu installiert (zwei davon werden zu PVE-Nodes umgewidmet, einer wird als kalte Reserve aufbewahrt)
4. Lizenzen: Broadcom-Vertrag offiziell zum Stichtag gekündigt

Stolpersteine (die ehrliche Liste)

VMware Tools rückstandsfrei deinstallieren

Wir hatten bei drei Windows-VMs Reste der VMware-Tools, die auch nach formaler Deinstallation noch in der Registry waren. Symptom: gelegentlich nach Reboot eine Sekunde lange Hänger beim Logon. Lösung: VMware Tools Cleaner-Skript von VMware vor dem Restore-Verfahren laufen lassen.

MAC-Adressen ändern sich

Bei der Migration bekommt jede VM eine neue MAC-Adresse. Das ist meistens irrelevant — außer:

• DHCP-Reservierungen müssen aktualisiert werden
• MAC-gebundene Software-Lizenzen müssen neu generiert werden
• Bridging-Filter im Netzwerk müssen erneuert werden
• Smart-Hosts und SMTP-Regeln, die auf MACs filtern (selten, aber gibt’s)

Wir empfehlen, die MAC explizit zu setzen — Proxmox erlaubt das pro Netzwerk-Interface. Wer die alte MAC weiter nutzen will, kann sie aus dem vSphere-Inventar übernehmen.

Storage-Latenz-Anpassung

Das alte vSphere hatte aggressive Storage I/O Control (SIOC) konfiguriert. In Proxmox läuft das per Default mit weniger Throttling. Effekt: Direkt nach der Migration ist eine VM, die viel I/O macht, gefühlt schneller — was andere VMs zeitweise ausbremst. Lösung: I/O-Limit pro VM in PVE setzen (qm set <id> --scsi0 ...,iops_rd=...,iops_wr=...).

TPM-Disks

Eine Windows 11-RDP-VM hatte ein virtuelles TPM. Die Migration funktioniert, aber Snapshots der TPM-Disk haben bis PVE 9.1 nicht zuverlässig funktioniert. Workaround: TPM-Disk auf einem separaten Speicher (NFS/SMB qcow2), Hauptdisks bleiben auf LVM-Thin. In PVE 9.1 ist der Snapshot-Bug für qcow2-TPM behoben — der iSCSI-Bug noch offen.

ESXi-Hardware-Version

Eine VM hatte VMX-Version 17 mit virtuellen Features (vPMU, GPU-Reservation), die in Proxmox so nicht 1:1 abbildbar sind. Mussten wir gesondert behandeln — am Ende über qm set mit angepasstem CPU-Typ und ohne die exotischen Features.

Backup-Lokationen

Veeam B&R schreibt im PVE-Modus etwas andere Metadaten. Wir hatten zunächst die alten Backup-Jobs auf neue Targets umgestellt — was rückwirkende Restores aus der alten Veeam-Library erschwert hätte. Besser: alte Library als Read-only behalten, neue parallel anlegen, Aufbewahrung versetzt auslaufen lassen.

Lehren

Was wir aus diesem Projekt mitnehmen:

1. Inventur ist die halbe Migration. Wer hier abkürzt, zahlt im Wartungsfenster doppelt.
2. Pilot mit fünf unkritischen VMs spart Nerven. Nicht direkt mit dem AD-Cluster anfangen.
3. Veeam Instant Recovery auf PVE ist der mit Abstand schnellste Pfad, wenn Veeam ohnehin im Einsatz ist.
4. VMware Tools restlos entfernen, sonst zickt Windows.
5. Storage-Komplexität nicht gleichzeitig umstellen. Erst Hypervisor, dann Storage, dann Backup. Niemals alles in einem Schritt.
6. Zwei Wochen Rückfall-Fenster sind günstige Versicherung — Hosts kalt halten, nicht sofort neu installieren.

Wenn Sie ein vergleichbares Projekt vor sich haben, beraten wir gerne — mit derselben ehrlichen Risikoeinschätzung wie hier dokumentiert. Eine Migration in der Größenordnung 30 VMs ist mit der richtigen Vorbereitung an drei Wochenenden inklusive Pilot machbar, ohne unkalkulierbares Risiko.

Verwandte Artikel:

• Von VMware zu Proxmox: Strukturierter Umstieg
• VMware-Lizenzumstellung: Proxmox als Alternative
• Proxmox VE 9.2 Release
• TrueNAS Proxmox-Plugin offiziell: NVMe/TCP

Quellen

• pve-vmware-import Dokumentation
• Veeam Backup & Replication 12.2 Release Notes (Proxmox-Support)
• VMware Tools Removal (KB 2015638)
• Proxmox VE Storage Best Practices