Von VMware zu Proxmox: Warum wir den Hypervisor gewechselt haben

Nach der Broadcom-Übernahme von VMware stellte sich für viele Betreiber dieselbe Frage wie bei uns: weiter steigende Lizenzkosten und Paketbündel hinnehmen — oder die Virtualisierung selbst in die Hand nehmen? Wir haben uns für Proxmox VE entschieden. Hier die Gründe, der konkrete Migrationspfad und die Stolpersteine.

Warum Proxmox

Proxmox VE ist eine vollständige Server-Virtualisierungsplattform auf Basis von KVM und LXC, mit Clustering und Hochverfügbarkeit out of the box — Open Source, ohne Lizenzfallen.

• Kostenstruktur: Support-Subscription statt Core-basierter Lizenzierung. Kein Aufschlag pro Sockel, pro Core oder pro vCPU.
• Datenhoheit: läuft auf eigener Hardware, kein Vendor-Lock-in.
• Flexibilität: KVM-VMs und LXC-Container nebeneinander, ZFS, integrierte Replikation und ein offenes Storage-Modell.
• Bedienbarkeit: Web-UI, REST-API und CLI (qm, pct) greifen ineinander — Automatisierung ohne zusätzliche Lizenzprodukte.

Zwei Migrationswege

Es gibt zwei praxistaugliche Pfade — die Wahl hängt davon ab, ob die Quell-VMs während der Migration laufen dürfen und wie viele es sind.

1. Nativer ESXi-Import (seit Proxmox VE 8.2). Proxmox bindet den ESXi-Host als Storage ein und liest die VMDKs direkt aus. Ideal für überschaubare Bestände.
2. Restore über Veeam Backup & Replication. Aktuelle Veeam-Versionen können VMware-Backups direkt auf Proxmox VE zurückspielen — praktisch, wenn ohnehin Veeam im Einsatz ist oder ein sauberer Backup-Restore als Migrationsweg gewünscht ist.

Für sehr grosse, komplexe vSphere-Landschaften stösst der native Importer noch an Grenzen — dann lohnt sich ein gestaffeltes Vorgehen oder der Weg über das Backup.

Der native ESXi-Import — Schritt für Schritt

1. Bestandsaufnahme — VMs, Abhängigkeiten, Netzwerk-VLANs, Storage-Bedarf. Erst inventarisieren, dann migrieren.
2. ESXi als Storage einbinden — unter Datacenter → Storage → Add → ESXi, mit Host und Zugangsdaten (Zertifikatsprüfung ggf. überspringen). Proxmox listet anschliessend die VMs samt Disks.
3. Import-Assistent — Ziel-Storage und Disk-Format (raw/qcow2) wählen, als Controller VirtIO SCSI single setzen, Netzwerkmodell auf VirtIO (paravirtualisiert).
4. Testmigration einzelner unkritischer VMs. Die Quell-VM für einen konsistenten Stand vorher herunterfahren.
5. Cutover in Wartungsfenstern, mit Rollback-Pfad — die VMware-VM bleibt bis zur Abnahme unangetastet.

Nach dem Import gehören QEMU Guest Agent installiert und discard (TRIM) sowie iothread auf der Disk aktiviert.

Windows-VMs: der häufigste Stolperstein

Linux-Gäste bringen VirtIO meist im Kernel mit. Windows nicht — und genau hier scheitern die meisten Migrationen mit einem „Inaccessible Boot Device"-Bluescreen. Der Grund: Die VM bootet plötzlich von einem VirtIO-SCSI-Controller, für den Windows noch keinen Treiber geladen hat.

Die Reihenfolge, die zuverlässig funktioniert:

1. Noch unter VMware: VirtIO-Treiber (virtio-win-ISO) installieren und VMware Tools deinstallieren.
2. Beim Import die Boot-Disk zunächst an einem SATA-Controller belassen, in Windows die VirtIO-Treiber sicher laden, dann auf VirtIO SCSI single umstellen — der Controller mit dem geringsten Overhead und dem höchsten Durchsatz unter Proxmox.
3. Firmware beachten: BIOS vs. UEFI/OVMF muss zur Quell-VM passen, sonst bleibt der Bildschirm schwarz.

Netzwerk und Cutover

Die MAC-Adresse der VMware-VM übernehmen, damit DHCP-Reservierungen und Firewall-Regeln weiter greifen. VLAN-Tags am Proxmox-Bridge-Interface sauber abbilden. Erst nach erfolgreichem Funktionstest die alte VM endgültig abschalten.

Was wir gelernt haben

Der Hypervisor-Wechsel war der einfache Teil. Die eigentliche Reise begann beim Storage — von Ceph über Vitastor bis DRBD. Und eine tragfähige Backup-Strategie nach 3-2-1 gehört von Tag eins dazu, nicht erst danach.

Wer von VMware wegmigriert, gewinnt Kontrolle zurück — zahlt aber mit Lernaufwand beim Storage- und HA-Design. Für uns hat sich der Tausch gelohnt.