VMware nach Broadcom: bleiben, zahlen oder nach Proxmox umziehen

Seit Broadcom VMware übernommen hat, ist die Verlängerung kein Verwaltungsakt mehr, sondern eine Entscheidung. Wer eine Hand voll Hosts betreibt, steht vor derselben Frage wie ein Rechenzentrum: weiterzahlen, verhandeln oder umziehen. Dieser Beitrag ordnet die Lage ein und zeigt den Migrationsweg nach Proxmox VE so, wie er im Betrieb wirklich aussieht, inklusive der Schritte, an denen es klemmt.

Stand 18.08.2026

Lizenzbedingungen ändern sich schneller als Anleitungen. Alles unter „Was sich geändert hat“ ist der Stand zum genannten Datum und stammt aus Berichten Dritter, nicht aus einem eigenen Vertrag, vor jeder Entscheidung das eigene Angebot lesen. Der technische Teil ab „Der Umzug“ altert deutlich langsamer.

Was sich geändert hat#

Vier Punkte, die zusammen die Rechnung erklären:

Vorher	Jetzt
Dauerlizenz kaufen, Wartung optional	nur noch Abo, ohne Abo keine Patches
Preis pro Sockel	Preis pro Kern
beliebig kleine Käufe	Mindestabnahme pro CPU (verbreitet genannt: 16 Kerne), dazu Mindestbestellgrößen
Essentials/Essentials Plus für kleine Umgebungen	eingestellt

Die Umstellung von Sockel auf Kern ist der Punkt, der kleine Umgebungen am härtesten trifft. Zwei Hosts mit je zwei 32-Kern-CPUs sind plötzlich 128 lizenzierte Kerne, dieselbe Hardware, dieselbe Zahl an VMs.

Zu den Preissprüngen kursieren sehr unterschiedliche Zahlen: Gartner nennt typische Steigerungen im Bereich des Drei- bis Vierfachen, der europäische Cloud-Verband CISPE hat der EU-Kommission gegenüber Verlängerungsangebote mit weit höheren Faktoren gemeldet. Beides sind Fremdangaben über fremde Verträge. Die einzige Zahl, die für dich zählt, steht in deinem Angebot.

Kostenloses ESXi ist keine Planungsgrundlage

Die freie ESXi-Version war zwischenzeitlich gestrichen und kam später in abgespeckter Form zurück. Für einen Heimserver mag das reichen. Für alles, was jemand anders braucht, ist eine Grundlage, die schon einmal ohne Vorwarnung verschwunden ist, keine Grundlage.

Drei Wege, ehrlich gegeneinander#

Bleiben und zahlen. Richtig, wenn Werkzeuge im Einsatz sind, die es woanders nicht gibt (NSX, vSAN-Stretched-Cluster, DRS mit Regeln, die wirklich gebraucht werden), oder wenn Zertifizierungen den Hypervisor vorschreiben. Aufwand: null. Kosten: bekannt, aber steigend.

Verhandeln. Mehrjahresbindung senkt den Preis, ebenso ein Wechsel auf die kleinere Edition. Realistisch nur mit Alternative in der Hand, ein Angebot verhandelt sich schlechter, wenn beide Seiten wissen, dass du nicht weg kannst.

Umziehen. Proxmox VE ist der naheliegende Ausweg: KVM und LXC, Cluster, Hochverfügbarkeit, Snapshots, eigener Backup-Server. Die Software ist frei nutzbar; bezahlt wird optional das Enterprise-Repository mit Support. Was fehlt: der große Werkzeugkasten drumherum und das Ökosystem an Zertifizierungen.

Eine ehrliche Faustregel: Je mehr VMware-Spezialfunktionen im Einsatz sind, desto teurer der Umzug. Wer im Kern „VMs auf Hosts, Storage darunter, Backup daneben“ betreibt, kommt gut rüber. Wer NSX-Segmente, vSAN-Policies und eine Automatisierung auf vRealize gebaut hat, zieht nicht den Hypervisor um, sondern die halbe Betriebsführung.

Vorher: die Bestandsaufnahme, die man nicht überspringt#

Bevor irgendetwas kopiert wird, drei Listen. Ohne sie migriert man in die Dunkelheit.

# Auf einem ESXi-Host, per SSH: was läuft, wie groß, welcher Gast?
vim-cmd vmsvc/getallvms
esxcli storage filesystem list
esxcli network vswitch standard list

Welche VMs, welche Betriebssysteme, welche Plattengrößen. Alte Windows-Server und alles mit Treiber-Nähe (Dongles, Faxkarten, USB) getrennt notieren, das sind die Sorgenkinder.
Welche Netze. Jeder Portgroup-Name mit VLAN-ID. Auf der Proxmox-Seite wird daraus eine VLAN-fähige Bridge.
Wovon hängt was ab. Welche VM startet zuerst, welcher Dienst hält die Anmeldung, wo läuft die Datenbank. Diese Liste bestimmt die Reihenfolge der Umzugsfenster.

Der Umzug#

Proxmox bringt seit Version 8.2 einen Import-Assistenten mit, der ESXi direkt als Storage-Typ ansprechen kann. Er redet über die ESXi-API mit dem Host, kein vCenter nötig, kein Zwischenexport, keine externe Festplatte.

# Auf dem Proxmox-Host: ESXi als Import-Quelle einbinden
pvesm add esxi esxi-alt --server 10.0.0.10 --username root --skip-cert-verification 1
pvesm list esxi-alt

Danach steht die Quelle im Web-Interface unter Datacenter → Storage und zeigt die VMs des Hosts zum Import an. Getestet ist der Weg von ESXi 6.5 bis 8.0.

Gast vorher herunterfahren

Ein Import bei laufender VM liefert einen Zustand wie nach einem Stromausfall: das Dateisystem ist mitten im Schreiben eingefroren. Für einen Testlauf reicht das, für den Umzug nicht. Der verlässliche Ablauf ist: Gast in ESXi sauber herunterfahren, importieren, in Proxmox starten.

Der Import-Assistent kopiert die VM von ESXi nach Proxmox; die eigentliche Arbeit sind danach fünf Nacharbeiten an Treibern, Netznamen, Guest-Agent, EFI und MAC-Adresse. — Der Kopiervorgang ist der kurze Teil. Die fünf Punkte darunter sind der lange.

Was am Import wirklich hängen bleibt#

Der Kopiervorgang ist der einfache Teil. Diese fünf Punkte kosten die Zeit:

1. Windows startet nicht, schwarzer Bildschirm oder Bluescreen. Ursache ist fast immer der Plattencontroller: Windows kennt VirtIO-SCSI nicht und hat keinen Treiber dafür im Boot-Pfad. Zwei Wege:

# Weg A: erst auf SATA starten, Treiber im laufenden Windows nachinstallieren,
# dann auf VirtIO umstellen
qm set 100 --sata0 local-lvm:vm-100-disk-0
# ... virtio-win-ISO einhängen, Treiber installieren, herunterfahren ...
qm set 100 --delete sata0
qm set 100 --scsihw virtio-scsi-single --scsi0 local-lvm:vm-100-disk-0,discard=on,iothread=1

Weg B ist sauberer, wenn die Quelle noch läuft: VirtIO-Treiber schon unter VMware installieren, dann umziehen.

2. Linux findet sein Netz nicht. Die Netzwerkkarte heißt nach dem Umzug anders, typischerweise ens18 statt ens192. Konfigurationen, die den Namen fest nennen, greifen ins Leere.

# Im Gast, über die Proxmox-Konsole (das Netz ist ja weg):
ip -br link
# Namen in /etc/netplan/*.yaml bzw. /etc/network/interfaces korrigieren

3. VMware-Tools raus, Guest-Agent rein. Sonst meldet Proxmox keine IP, und ein sauberes Herunterfahren aus der Oberfläche funktioniert nicht.

# im Gast
apt purge open-vm-tools && apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent
# auf dem Host
qm set 100 --agent enabled=1

4. UEFI-Gäste brauchen eine EFI-Platte. Wer sie vergisst, sucht den Bootloader an der falschen Stelle. Windows 11 braucht zusätzlich ein TPM.

qm set 100 --bios ovmf --machine q35 --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1
qm set 100 --tpmstate0 local-lvm:1,version=v2.0

5. Die MAC-Adresse ändert sich. Damit ändert sich, was DHCP-Reservierungen, Firewall-Regeln und manche Softwarelizenz sehen. Wer die alte MAC übernehmen will, setzt sie ausdrücklich:

qm set 100 --net0 virtio=00:50:56:AA:BB:CC,bridge=vmbr0,tag=20

Das Netz darunter#

Ein VMware-Portgroup mit VLAN-Tag wird in Proxmox zu einer VLAN-fähigen Bridge. Einmal auf dem Host eingerichtet, danach nur noch tag= je VM:

# /etc/network/interfaces
auto vmbr0
iface vmbr0 inet static
    address 10.0.0.20/24
    gateway 10.0.0.1
    bridge-ports eno1
    bridge-vlan-aware yes
    bridge-vids 2-4094

Details zu Storage-Typ, Snapshots und den Einstellungen pro Platte stehen in Proxmox-Storage: welcher Typ wofür. Für mehrere Hosts lohnt vorher der Blick in Proxmox-Cluster aufbauen, Cluster-Beitritt vor dem Import ist deutlich angenehmer als danach.

Die Reihenfolge, die sich bewährt hat#

Einen Host frei räumen und Proxmox darauf installieren (Anleitung). Nicht den letzten.
Eine unwichtige VM importieren. Sie ist der Testlauf für alles oben.
Backup zuerst. Bevor die zweite VM umzieht, steht der Proxmox Backup Server und hat einmal erfolgreich zurückgespielt. Ein Umzug ohne getesteten Rückweg ist kein Umzug, sondern eine Wette.
In Wellen umziehen, nach der Abhängigkeitsliste. Nach jeder Welle einen Tag laufen lassen.
ESXi zuletzt abbauen und erst, wenn die letzte VM eine Woche unauffällig lief.

Zeitrahmen

Beratungshäuser nennen für Umgebungen um die 50 VMs Zeiträume von zwei bis vier Wochen nebenher. Das deckt sich mit dem, was der Ablauf oben nahelegt: Der Kopiervorgang ist Stunden, die Nacharbeit an Treibern, Netznamen und Startreihenfolgen ist der Rest. Plane nach VM-Typen, nicht nach Terabyte.

Häufige Fragen#

Kann ich live migrieren, ohne die VMs abzuschalten?#

Zwischen zwei Proxmox-Knoten ja. Von ESXi nach Proxmox nein, die Hypervisoren sprechen nicht dieselbe Sprache. Pro VM bleibt ein Neustartfenster. Wie lang, hängt an der Plattengröße und daran, ob Netz und Storage schnell sind.

Brauche ich vCenter für den Import?#

Nein. Der Assistent redet direkt mit dem ESXi-Host. Wer vCenter hat, kann es weiter nutzen, muss aber nicht.

Was wird aus meinen Veeam-Backups?#

Bestehende Sicherungen bleiben lesbar, solange die Software läuft. Für den laufenden Betrieb danach entscheidest du dich zwischen der Proxmox-Unterstützung deiner bisherigen Backup-Software und dem Proxmox Backup Server. Wichtig ist nur: eine Lösung, die getestet zurückspielt, nicht zwei, die beide halb eingerichtet sind.

Lohnt sich der Umzug bei zwei Hosts überhaupt?#

Genau dort am ehesten. Kleine Umgebungen haben selten die Spezialfunktionen, die den Umzug teuer machen, und tragen die Mindestabnahmen pro CPU am schlechtesten.

Ist Proxmox „unternehmenstauglich“?#

Die Frage zielt meist auf Support, nicht auf Technik. Technisch trägt Proxmox produktive Umgebungen seit Jahren. Wer einen Vertrag mit Reaktionszeit braucht, kauft das Enterprise-Abo, dann bleibt der Preisunterschied bestehen, nur eben deutlich kleiner.

Kurz gesagt#

Die Preisfrage entscheidet sich an Kernen pro CPU, nicht an der Zahl der VMs.
Vor allem anderen: drei Listen, VMs, Netze, Abhängigkeiten.
Der Import-Assistent ab Proxmox 8.2 ist der Standardweg; die Arbeit steckt danach in Treibern, Netznamen und Startreihenfolge.
Erst Backup, dann Umzug. Getestet zurückgespielt, nicht nur eingerichtet.
Den alten Host abbauen ist der letzte Schritt, nicht der vorletzte.