Die Broadcom-Kostenfalle: VMware-Ausstieg und Proxmox-Migration für den CIO

Über zwei Jahrzehnte lang galt VMware vSphere in europäischen Rechenzentren als unumstößliches Fundament der betrieblichen IT-Infrastruktur. Generationen von Systemarchitekten bauten ihre Server-, Speicher- und Backup-Konzepte um den ESXi-Hypervisor und das zentrale vCenter herum auf. Mit der 61 Milliarden US-Dollar schweren Übernahme durch den Halbleiter- und Softwarekonzern Broadcom ist diese Ära der Verlässlichkeit jedoch abrupt zu Ende gegangen.

Innerhalb weniger Monate nach Abschluss der Akquisition vollzog das neue Management einen radikalen Strategiewechsel, der in seiner kaufmännischen Härte selbst erfahrene Einkaufsleiter überraschte. Sämtliche unbefristeten Kauflizenzen (Perpetual Licenses) sowie die dazugehörigen Wartungsverträge (SnS) wurden ersatzlos abgekündigt. Unternehmen stehen bei anstehenden Vertragsverlängerungen vor der Wahl, entweder in hochpreisige Abonnement-Pakete zu wechseln oder den Herstellersupport für ihre kritischen Systeme zu verlieren.

Für CIOs und IT-Verantwortliche im gehobenen Mittelstand sowie in der öffentlichen Verwaltung ist dadurch eine akute Zwangslage entstanden. Wo früher kalkulierbare Wartungssteigerungen von drei bis fünf Prozent pro Jahr üblich waren, liegen heute Angebote auf dem Tisch, die das Drei- bis Sechsfache des bisherigen Budgets aufrufen. Dieser Leitfaden beleuchtet die ökonomische und technische Mechanik hinter dem Umbau und zeigt, wie der geordnete Ausstieg auf Basis von Proxmox VE und Ceph gelingt.

Der Preis des Monopols: Wie Broadcom das Enterprise-Ökosystem umbaut

Um die Tragweite der aktuellen Preisrunde zu verstehen, lohnt ein Blick auf das Geschäftsmodell von Broadcom. Bereits bei früheren Großübernahmen wie Symantec oder CA Technologies verfolgte der Konzern eine strikte Fokussierung auf die weltweit umsatzstärksten Großkunden. Das Prinzip beruht darauf, komplexe Einzelprodukte einzustampfen, Entwicklungs- und Vertriebskosten drastisch zu senken und die verbleibende Kundenbasis mit maximaler Marge an umfassende Komplett-Suiten zu binden.

Im Fall von VMware trifft diese Konsolidierung den Markt an einer besonders empfindlichen Stelle. Die ehemals feingliedrigen Editionen wie vSphere Standard oder Enterprise Plus wurden zugunsten zweier dominanter Abonnements weitgehend zurückgedrängt: VMware vSphere Foundation (VVF) und VMware Cloud Foundation (VCF). Selbst Organisationen, die lediglich einen stabilen Hypervisor zur Server-Virtualisierung benötigen, müssen fortan umfangreiche Zusatzmodule für Software-Defined Networking (NSX), Speichervirtualisierung (vSAN) und Cloud-Management mitbezahlen.

Parallel dazu wurde die Berechnungsgrundlage fundamental verändert. Statt pro physischem Prozessorsockel abzurechnen, verlangt Broadcom nun Lizenzen pro einzelnem CPU-Kern, verbunden mit einer Mindestabnahme von 16 Kernen pro Prozessor. Wer in seinem Rechenzentrum moderne, energieeffiziente Dual-Socket-Server mit 32 oder 64 Kernen pro CPU betreibt, wird für diese Hardware-Konsolidierung nachträglich mit vervielfachten Softwaregebühren bestraft, während weite Teile des langjährigen Systemhaus-Channels ihre Partnerstufen verloren haben.

Diese Kombination aus erzwungener Paketierung, Core-Metrik und ausgedünntem Partnernetz hat das Vertrauensverhältnis zwischen Hersteller und Anwenderunternehmen nachhaltig beschädigt. Eine detaillierte Gegenüberstellung der konkreten Migrationsschritte auf technischer Ebene bietet unser vertiefender Praxisleitfaden zum VMware-Broadcom-Exit mit Proxmox VE und Ceph. Für den Vorstand stellt sich damit nicht mehr die Frage, ob eine Entflechtung stattfindet, sondern in welchem Zeitfenster sie vollzogen wird.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cloud-Exit-Strategie im Enterprise-Einsatz sowie zu Lift-and-Shift-Sanierung im Enterprise-Einsatz.

Technischer Deep-Dive: Proxmox VE 8.x, KVM und Multi-Master-Clustering

Bei der Suche nach einer tragfähigen Zielarchitektur fällt der Blick europäischer Infrastruktur-Teams vor allem auf Proxmox Virtual Environment (VE) der Wiener Proxmox Server Solutions GmbH. Anders als proprietäre Hypervisoren, die einen eigenen monolithischen Kernel pflegen, setzt Proxmox VE in der aktuellen Generation 8.x auf ein gehärtetes Debian GNU/Linux mit aktuellem Ubuntu-LTS-Kernel und dem im Linux-Kernel verankerten KVM-Hypervisor (Kernel-based Virtual Machine).

Dieser architektonische Ansatz bringt handfeste Vorteile für den Rechenzentrumsbetrieb. Da KVM zugleich das technische Rückgrat der weltweit größten Public-Cloud-Plattformen bildet, fließen Treiber-Optimierungen für moderne AMD-EPYC- und Intel-Xeon-Prozessoren, NVMe-Laufwerke und 100-GbE-Netzwerkkarten ohne Zeitverzug direkt in den Unterbau ein. Ergänzt wird die klassische Vollvirtualisierung durch Linux Containers (LXC), mit denen sich leichtgewichtige Infrastruktur-Dienste nahezu ohne Ressourcen-Overhead isoliert betreiben lassen.

Vom monolithischen vCenter zum verteilten Corosync-Quorum

Ein wesentlicher Unterschied zu VMware zeigt sich in der Steuerung des Clusters. Während eine vSphere-Umgebung zwingend auf die zentrale vCenter-Server-Appliance angewiesen ist, verzichtet Proxmox vollständig auf eine solche zentrale Verwaltungsinstanz. Stattdessen kommt das Proxmox Cluster File System (pmxcfs) zum Einsatz: eine datenbankgestützte Dateisystem-Schicht im Arbeitsspeicher, die sämtliche Konfigurationsdateien in Echtzeit über das Corosync-Konsensprotokoll auf alle Knoten repliziert.

Durch dieses Multi-Master-Design kann sich der Administrator per Web-GUI oder REST-API mit jedem beliebigen Host im Cluster verbinden und von dort aus die gesamte Serverlandschaft steuern. Fällt ein Knoten aus, greift ein hardwaregestütztes Watchdog-Fencing, das den betroffenen Host zuverlässig isoliert und die hochverfügbaren virtuellen Maschinen (HA) binnen Sekunden auf den verbleibenden Cluster-Knoten neu startet, ohne dass jemals ein Single Point of Failure in der Management-Ebene entsteht.

„Der Wechsel von VMware vSphere zu Proxmox VE ist kein technischer Kompromiss, sondern eine architektonische Modernisierung: Unternehmen ersetzen einen monolithischen Management-Stack und unkalkulierbare Core-Tarife durch ein verteiltes Quorum-Design und echte Quelloffenheit.“

Ebenso tiefgreifend ist die native Integration von Ceph als verteiltem Software-Defined Storage direkt in die Verwaltungsoberfläche und API von Proxmox VE. Ohne separate Speichermonopole oder Zusatzlizenzen lassen sich lokale Enterprise-NVMe-Laufwerke über die Cluster-Knoten hinweg zu einem selbstheilenden, fehlertoleranten Block- und Objektspeicher bündeln. Wie solche Speicher-Fabrics für höchste IOPS-Anforderungen dimensioniert werden, erläutern wir im Leitfaden zur Rechenzentrums-Autarkie mit Ceph und NVMe-over-Fabrics.

Nativer ESXi-Import, Backup-Integration und Windows-Lizenzmechanik

Lange Zeit galt der operative Aufwand für die Konvertierung hunderter virtueller Festplatten vom VMDK-Format nach QEMU/KVM als größte Hürde eines Hypervisor-Wechsels. Mit dem nativen ESXi-Import-Assistenten hat Proxmox diese Barriere beseitigt. Das Ziel-Cluster wird über einen lesenden API-Zugang direkt mit den bestehenden ESXi-Hosts oder dem vCenter verbunden und präsentiert deren Datastores unmittelbar im Proxmox-Storage-Baum.

Wählt das Betriebsteam eine virtuelle Maschine zur Übernahme aus, liest Proxmox die Hardware-Topologie (CPU-Zuweisung, RAM, VLAN-Tags, MAC-Adressen) automatisiert aus und startet die neue Instanz sofort auf dem KVM-Host, während die Festplattendaten im Hintergrund über eine FUSE-Schicht direkt vom ESXi-Speicher gestreamt und parallel auf das neue Ceph- oder ZFS-Volume geschrieben werden. Die effektive Ausfallzeit pro Workload schrumpft damit auf das kurze Herunterfahren und Starten während eines regulären Wartungsfensters.

Auch auf der Datensicherungs- und Lizenzseite haben sich die Rahmenbedingungen deutlich angenähert. Neben dem hauseigenen Proxmox Backup Server (PBS), der inkrementelle Sicherungen mittels QEMU Dirty-Bitmaps, globaler Deduplizierung und unveränderbaren WORM-Tresoren (Write Once, Read Many) bereitstellt, unterstützen mittlerweile auch etablierte Dritthersteller-Suiten wie Veeam Backup & Replication ab Version 12.2 den Proxmox-Hypervisor nativ ohne Agenten-Zwang.

Besondere Sorgfalt sollten Lizenzverantwortliche lediglich den bestehenden Microsoft-Windows-Server-Lizenzen widmen. Wo unter vSphere häufig Windows Server Datacenter-Lizenzen alle physischen Kerne eines Clusters abdecken, gilt dieselbe Regelung exakt identisch auch unter KVM und Proxmox VE. Wer hingegen einzelne Windows-VMs über Standard-Lizenzen ohne aktive Software Assurance betreibt, muss vor der Aktivierung automatischer Live-Migrationen prüfen, dass die 90-Tage-Zuweisungsregel für Host-Wechsel eingehalten wird.

Architektur- und Lizenzvergleich: VMware VCF versus Proxmox VE Enterprise

Für eine belastbare Entscheidungsvorlage im IT-Lenkungsausschuss müssen technische Leistungsmerkmale und kaufmännische Lizenzbedingungen gemeinsam betrachtet werden. Oft zeigt sich erst im direkten Vergleich, dass der funktionale Vorsprung, den VMware vor zehn Jahren besaß, im operativen Alltag von 90 Prozent aller Unternehmensrechenzentren kaum noch eine Rolle spielt.

Die nachfolgende Bloomberg-Radar-Matrix stellt das neue Broadcom-Abonnementmodell, den auslaufenden vSphere-Bestandsbetrieb und die Enterprise-Architektur von Proxmox VE 8.x anhand der fünf wichtigsten Entscheidungsdimensionen gegenüber:

Wie die Matrix verdeutlicht, verschiebt sich das Risiko-Nutzen-Verhältnis dramatisch. Während vSphere historisch durch ein riesiges Ökosystem zertifizierter Hardware-Appliances punktete, kehrt sich die proprietäre Kapselung unter den neuen Abonnement-Bedingungen in ein schwer kalkulierbares Bilanzrisiko um.

Demgegenüber vermeidet Proxmox VE jede künstliche Funktionsbeschneidung zwischen Lizenzstufen: Der gesamte Funktionsumfang von Live-Migration, High Availability, Software-Defined Networking (SDN mit VXLAN/EVPN) und Ceph-Storage ist in jeder Installation vollständig enthalten. Die Enterprise-Subscription regelt ausschließlich den Zugang zum getesteten Enterprise-Paket-Repository sowie die garantierten Reaktionszeiten des Entwickler-Supports.

Vollkostenrechnung über 60 Monate: Warum die Rechnung ab dem ersten Renewal kippt

Um die betriebswirtschaftliche Dimension für den Finanzvorstand (CFO) greifbar zu machen, betrachten wir eine repräsentative Referenzumgebung eines mittelständischen Industrie- oder Dienstleistungsunternehmens. Die Infrastruktur umfasst 30 physische Dual-Socket-Server (insgesamt 60 CPU-Sockel), bestückt mit jeweils zwei 32-Core-Prozessoren, was einer Gesamtkapazität von 1.920 physischen Prozessorkernen und rund 450 produktiven virtuellen Maschinen entspricht.

Unter dem neuen Broadcom-Lizenzmodell für VMware Cloud Foundation (VCF) fallen für 1.920 lizenzpflichtige Kerne im mehrjährigen Abonnement jährliche Gebühren von durchschnittlich 320 bis 350 Euro pro Core an. Selbst nach Abzug üblicher Volumenrabatte resultiert daraus eine jährliche OPEX-Belastung von rund 650.000 Euro. Über fünf Jahre (60 Monate) summieren sich allein die Software-Mietkosten auf 3,25 Millionen Euro ohne bleibenden Lizenzwert.

Stellt man exakt dieselbe Server-Farm auf Proxmox VE 8.x mit der höchsten Support-Stufe (Premium-Subscription inklusive unlimitiertem Support-Ticket-Volumen und direktem Hersteller-SLA) um, beträgt der Listenpreis rund 1.050 Euro pro physischem CPU-Sockel und Jahr. Da die Anzahl der Prozessorkerne bei Proxmox keinerlei Rolle spielt, belaufen sich die jährlichen Support-Kosten für alle 60 Sockel zusammen auf 63.000 Euro bzw. 315.000 Euro über fünf Jahre.

Inklusive eines einmaligen Projektbudgets von 150.000 Euro für Architekturplanung, Drei-Knoten-Migrationspuffer und Team-Zertifizierung liegen die Fünfjahresgesamtkosten bei lediglich 465.000 Euro. Das Unternehmen realisiert eine Netto-Einsparung von 2,78 Millionen Euro (über 85 Prozent Lizenzkostenreduktion) und amortisiert den Wechsel in unter vier Monaten. Weitere Details liefert unser 5-Jahres-TCO-Vergleich zwischen Rechenzentrums-Eigenbetrieb und Hyperscalern.

Die Make-or-Buy Sourcing-Weiche und regulatorische Resilienz unter DORA und NIS-2

Je nach Größe der internen Infrastruktur-Abteilung, bestehender Rechenzentrums-Strategie und der Anzahl der zu betreibenden Knoten hat sich in der Praxis eine klare Dreiteilung der Bereitstellungsmodelle herauskristallisiert. Entscheidend ist dabei, das Modell passend zur eigenen Betriebsreife zu wählen, statt alte Abhängigkeiten durch neue Intransparenz zu ersetzen.

Erstens (Eigenbetrieb mit Hersteller-Subscription): Unternehmen mit einem erfahrenen Linux- und Virtualisierungsteam (typischerweise zwischen 3 und 40 physischen Cluster-Knoten) betreiben Proxmox VE und Ceph in eigener Regie in ihren bestehenden Colocation-Racks oder im eigenen Serverraum. Die Absicherung erfolgt über offizielle Proxmox-Enterprise-Subscriptions, ergänzt durch klar abgegrenzte Architektur-Reviews spezialisierter Beratungshäuser während der Initialisierungsphase.

Zweitens (Föderierter Betrieb nach SCS-Standard): Große Konzerne, kommunale IT-Dienstleister und Organisationen mit mehr als 50 bis 500 Serverknoten, die vollautomatisierte Mandantenfähigkeit und Self-Service-APIs nach Public-Cloud-Muster benötigen, kombinieren KVM-Virtualisierung mit einer standardisierten Cloud-Orchestrierung. Hier bildet der Sovereign Cloud Stack (SCS) auf Basis von OpenStack, Ceph und Kubernetes das führende Referenzmodell für föderierte europäische Rechenzentren.

Drittens (Begleitete Migration durch Open-Source-Systemhäuser): Mittelständler mit schlanker IT-Mannschaft vergeben die Erstinstallation, das Netzwerk-Design für 25/100-GbE-Storage-Fabrics und den Managed-Betrieb an zertifizierte europäische Systemhäuser. Wichtig für den Einkauf ist hierbei die vertragliche Festlegung, dass sämtliche Konfigurationsskripte (Ansible, OpenTofu) und Administrator-Zugänge jederzeit im Eigentum des Auftraggebers verbleiben.

Über die reine Kostenseite hinaus zahlt diese Architektur direkt auf die verschärften europäischen Regulierungsanforderungen ein. Sowohl Artikel 28 der EU-Verordnung DORA (Digital Operational Resilience Act) für den Finanzsektor als auch die NIS-2-Richtlinie verlangen den belastbaren Nachweis, dass kritische IKT-Drittparteienrisiken und Anbieter-Konzentrationen aktiv begrenzt werden und geprüfte Ausstiegsszenarien vorliegen.

Mit einer unter der freien AGPLv3 lizenzierten Plattform eines europäischen Herstellers ohne US-Telemetrieabfluss erfüllen Unternehmen nicht nur den BSI IT-Grundschutz-Baustein SYS.1.5 (Virtualisierung) hinsichtlich Mandantentrennung, Zwei-Faktor-Authentifizierung (WebAuthn/TOTP) und feingranularer RBAC-Rechtevergabe, sondern beseitigen zugleich das Risiko einseitiger US-Export- oder Lizenzsperren.

Der 4-Phasen-Umsetzungsfahrplan: Ohne Betriebsunterbrechung aus dem Lock-in

Damit der Wechsel der Virtualisierungsschicht im laufenden Geschäftsbetrieb ohne Reibungsverluste gelingt, empfiehlt sich ein strukturiertes Vorgehen über sechs bis neun Monate. Der Schlüssel liegt darin, mindestens ein halbes Jahr vor dem Ablaufen bestehender VMware-Verträge mit der technischen Vorarbeit zu beginnen, um nicht unter Zeitdruck in eine erzwungene Vertragsverlängerung zu geraten.

Phase 1 (Monat 1 bis 2): Bestandsaufnahme, HCL-Audit und Lizenz-Triage

Am Anfang steht die vollständige Inventarisierung aller bestehenden ESXi-Hosts, vCenter-Abhängigkeiten, VLAN-Topologien und Backup-Schnittstellen. Parallel prüft das Infrastruktur-Team die vorhandene Server-Hardware (Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem) auf den Betrieb unter Debian/KVM und identifiziert freiwerdende Serverknoten, die als Initial-Hardware für den neuen Ziel-Cluster aus dem VMware-Verbund herausgelöst werden können.

Phase 2 (Monat 3 bis 4): Aufbau des Proxmox-Ceph-Pilotclusters und Backup-Kopplung

Auf mindestens drei physischen Serverknoten wird das neue Proxmox-VE-Cluster inklusive redundantem Corosync-Ringnetzwerk und dediziertem 25/100-GbE-Ceph-Storage-Pool in Betrieb genommen. Gleichzeitig erfolgt die Einrichtung des Proxmox Backup Servers (bzw. die Anbindung von Veeam 12.2) sowie ein systematischer Stresstest: Das Team simuliert den kompletten Strom- und Netzwerkausfall einzelner Knoten, um das automatische HA-Failover und die Ceph-Selbstheilung unter Last zu verifizieren.

Phase 3 (Monat 5 bis 6): Live-Import unkritischer Workloads und Betriebshandbuch

Über den integrierten ESXi-Import-Assistenten werden zunächst Entwicklungs-, Test- und Staging-Systeme im laufenden Betrieb nach Proxmox VE überführt. Bei Windows-Gastsystemen wird im Zuge des Wartungsfensters das zertifizierte VirtIO-Treiberpaket für optimale Netzwerk- und Storage-Performance eingespielt, während das Administratorenteam die neuen Abläufe für Monitoring, Provisionierung und Notfall-Wiederherstellung im Betriebshandbuch verankert.

Phase 4 (Monat 7 bis 12): Produktive Wellen-Migration und Rückbau der Altsysteme

In wöchentlichen Migrationswellen ziehen die produktiven Applikations- und Datenbank-Server auf das neue Cluster um. Jeder leergeräumte ESXi-Host wird anschließend frisch mit Proxmox VE installiert und nahtlos in den wachsenden KVM- und Ceph-Verbund aufgenommen, bis das letzte vCenter rechtzeitig vor dem Stichtag der Broadcom-Vertragsverlängerung abgeschaltet und außer Betrieb genommen werden kann.

Fünf Kontrollfragen für Vorstand und IT-Leitung zur VMware-Ablösung

1. Wie hoch fällt die reale Kostensteigerung im nächsten Verlängerungszyklus über 36 und 60 Monate aus?

Lassen Sie sich vom Einkauf nicht nur die Differenz des ersten Übergangsjahres vorlegen, sondern eine verbindliche Fünfjahres-Projektion auf Basis der real verbauten CPU-Kerne inklusive der erzwungenen VCF- und vSAN-Kapazitätslizenzen. Erst diese Gesamtsicht macht das tatsächliche finanzielle Klumpenrisiko gegenüber einer Sockel-basierten Open-Source-Subscription sichtbar.

2. Welche Applikationen oder Drittanbieter-Tools nutzen proprietäre vSphere-Schnittstellen?

Prüfen Sie frühzeitig, welche Sicherheits-, Monitoring- oder Backup-Werkzeuge direkt mit der vCenter-API kommunizieren, statt auf Betriebssystem- oder Standard-Protokollebene zu arbeiten. In fast allen Fällen stehen für Linux/KVM und die Proxmox-REST-API bereits native Konnektoren bereit, die jedoch vor dem produktiven Umzug im Pilotcluster getestet werden müssen.

3. Ist das interne Netzwerk für hyperkonvergenten Ceph-Storage ausreichend dimensioniert?

Wer im Zuge des VMware-Ausstiegs auch proprietäre SAN-Speichersysteme oder vSAN durch Ceph ablöst, benötigt zwingend ein dediziertes, verlustfreies Backend-Netzwerk mit mindestens 25 GbE (besser 100 GbE) und sauber konfigurierten Jumbo-Frames. Eine Trennung von Management-, Corosync- und Storage-Traffic auf separaten Netzwerkschnittstellen ist für niedrige Latenzen unerlässlich.

4. Wie werden Windows-Server-Lizenzen und SQL-Workloads während der Übergangsphase lizenziert?

Stellen Sie gemeinsam mit dem Lizenzmanagement sicher, dass auf den neuen Proxmox-KVM-Knoten ausreichend Windows Server Datacenter-Cores oder Lizenzmobilitätsrechte (Software Assurance) vorliegen, bevor automatische HA-Live-Migrationen aktiviert werden. Für relationale Datenbanken lohnt sich parallel die Prüfung, ob im Zuge der Migration auch teure proprietäre Datenbanklizenzen konsolidiert werden können.

5. Liegt die formale Kündigungsfrist der bestehenden VMware-Verträge vor dem Abschluss von Phase 3?

Rückwärtsterminierung entscheidet über Ihre Verhandlungsposition: Das Pilotcluster und die ersten erfolgreichen Testmigrationen müssen zwingend abgeschlossen sein, bevor die Kündigungsfrist des bestehenden Wartungsvertrags verstreicht. Nur wer technisch nachweisen kann, dass der Ausstieg läuft, entgeht dem Preisdiktat am Verhandlungstisch.

Strategisches Fazit: Vom Lizenzdiktat zur dauerhaften Infrastruktur-Autonomie

Die radikale Preis- und Lizenzpolitik von Broadcom hat in den Vorstandsetagen ein schmerzhaftes, aber heilsames Umdenken ausgelöst. Sie führt unmissverständlich vor Augen, wie schnell eine scheinbar alternativlose Standardsoftware zur existenziellen Kosten- und Abhängigkeitsfalle werden kann, wenn sich die Eigentümerstruktur eines US-Technologiekonzerns ändert.

Unternehmen, die diesen Wendepunkt nutzen, um ihre Virtualisierungs- und Speicherarchitektur konsequent auf offene Industriestandards wie Debian, KVM, Proxmox VE und Ceph umzustellen, lösen nicht nur ein akutes Budgetproblem. Sie senken ihre laufenden Infrastrukturkosten dauerhaft um über 75 Prozent, erfüllen die strengen Resilienzvorgaben von DORA und NIS-2 aus eigener Kraft und gewinnen die technologische Hoheit über ihr eigenes Rechenzentrum zurück.

Häufig gestellte Fragen (FAQ) zu VMware-Ausstieg und Proxmox VE