Weg von VMware: Ein Open-Source-Playbook ohne Anbieterbindung

Seit Broadcom die Übernahme von VMware abgeschlossen hat, hat sich die Rechnung für den Betrieb virtualisierter Infrastruktur verändert. Unbefristete Lizenzen sind verschwunden, das Portfolio wurde auf eine Handvoll Abo-Bundles zusammengestrichen, und die Preisgestaltung ist auf ein Modell pro Core umgestellt worden. Verlängerungsangebote fielen vielerorts 2- bis 5-mal höher aus als das, was Teams zuvor gezahlt haben. Für viele CTOs und Architekten in ganz Europa lautet die Frage nicht mehr „Sollten wir uns Alternativen ansehen”, sondern „Wohin wechseln wir, und in welcher Reihenfolge”.

Das hier ist ein Playbook, kein Verkaufsgespräch. Wir sind eine Engineering-Beratung, kein Cloud-Anbieter, daher haben wir keine Plattform, auf die wir Sie drängen müssten. Ziel ist es, Ihnen die Konzepte, die offenen Standards und eine ehrliche Übersicht der Optionen an die Hand zu geben, damit Sie eine Entscheidung treffen können, die zu Ihrem Stack passt.

Warum Teams VMware verlassen

Die Beweggründe sind über die Organisationen hinweg, mit denen wir sprechen, durchweg dieselben:

• Kosten. Die Lizenzierung pro Core bestraft Hosts mit hoher Dichte. Ein Server mit zwei Sockeln und zwei 16-Core-CPUs, der früher zwei CPU-Lizenzen benötigte, zählt nun als 64 Cores. In Kombination mit der Bundle-Konsolidierung landen viele Verlängerungen weit über den bisherigen Ausgaben.
• Bündelung. vSphere, vSAN, NSX und die Aria-Suite sind nun in große Abonnements wie VMware Cloud Foundation (VCF) und vSphere Foundation (VVF) verpackt. Wenn Sie nur vSphere genutzt haben, zahlen Sie womöglich für Funktionen, die Sie nie einsetzen.
• Lock-in und Support-Ende-Druck. vSphere 7 erreichte im Oktober 2025 das Ende des allgemeinen Supports, und für vSphere 8 ist Oktober 2027 vorgesehen. Unbefristete Lizenzen laufen weiter, doch ohne Patches und Support tickt die Uhr ganz real.
• Ökosystem-Störungen. Änderungen an Partner- und Cloud-Service-Provider-Programmen (das VCSP-Modell wurde Anfang 2026 auf „nur auf Einladung” umgestellt) haben einige Managed-Hosting-Beziehungen in Neuverhandlungen gezwungen.

Nichts davon bedeutet, dass Sie nächstes Quartal alles herausreißen müssen. Es bedeutet, dass Sie Ihre Optionen kennen und einen glaubwürdigen Ausstiegspfad haben sollten.

Es gibt keinen einzelnen VMware-Ersatz

Das ist der wichtigste Punkt im gesamten Playbook. VMware hat Compute-Virtualisierung, Storage (vSAN), Networking (NSX) und Management (vCenter, Aria) in einem einzigen Stack gebündelt. Kein Open-Source-Projekt ersetzt all das mit einem einzelnen Produkt. Der richtige Schritt ist, Optionen auf Workloads abzubilden, mit offenen Standards voranzugehen (KVM, QEMU, libvirt, Ceph, OVN/Open vSwitch, die OCI- und Kubernetes-APIs) und Werkzeuge zu wählen, die zu jeder Schicht passen.

Hier ist die grobe Landschaft, gruppiert danach, wo jede Option ihre Stärken hat. Betrachten Sie diese als repräsentativ, nicht als vollständig, und nicht als Empfehlung für ein Werkzeug gegenüber einem anderen.

VM-zentrierte Plattformen (am nächsten an einer vCenter-artigen Erfahrung)

• Proxmox VE - KVM plus LXC, mit integriertem Clustering, Live-Migration und Ceph-Integration. Starke Passung für KMU bis Mid-Market und unkomplizierte On-Prem-Virtualisierung, bei der Einfachheit zählt.
• oVirt - das Upstream-Projekt der früheren Red Hat Virtualization. Inzwischen community-gepflegt, nachdem sich Red Hat zurückgezogen hat, und Grundlage für Produkte wie Oracle Linux Virtualization Manager. Ein vertrautes Datacenter-/Cluster-/Host-Modell für Teams, die die Struktur von vCenter mochten.
• Harvester - SUSEs Open-Source-Plattform für Hyperkonvergenz, aufgebaut auf Kubernetes, KubeVirt und Longhorn. Bietet eine VM-zentrierte Oberfläche, sitzt aber auf cloud-nativer Technik darunter.

Private-Cloud-Plattformen (IaaS mit Mandantenfähigkeit und Self-Service)

• OpenStack - die leistungsfähigste und modularste Option, mit separaten Projekten für Compute (Nova), Networking (Neutron, typischerweise OVN), Storage (Cinder, Swift) und Identity (Keystone). Hervorragend in großem Maßstab, aber ehrlich gesagt komplex und lohnt sich nur mit einem versierten Operations-Team.
• Apache CloudStack - ein integriertes, meinungsstarkes IaaS, das schneller aufzusetzen ist als OpenStack, mit Multi-Hypervisor-Unterstützung und ausgereiftem Networking. Beliebt bei Service-Providern und Telcos.
• OpenNebula - leichtgewichtig und pragmatisch, gut geeignet für Edge, Hybrid und kleine bis mittlere Private Clouds, in denen Sie Orchestrierung ohne das operative Gewicht von OpenStack wollen.

Kubernetes-native Wege

Wenn Ihre Roadmap bereits cloud-nativ ist, können Sie VMs und Container auf einer einzigen Control Plane zusammenführen:

• KubeVirt - betreibt VMs als Kubernetes-Ressourcen. Es ist ein CNCF-Projekt (Ende 2025 im Graduation-Review) mit wachsender Anwenderbasis und die Engine hinter mehreren kommerziellen Virtualisierungsprodukten.
• Cluster API - deklaratives Provisioning und Lifecycle-Management für Kubernetes-Cluster, oft kombiniert mit KubeVirt oder Bare Metal für ein Cluster-as-a-Service-Modell.

Für die Massenmigration von VMs in die Kubernetes-Welt verbindet sich das Open-Source-Projekt Forklift (Grundlage von Red Hats Migration Toolkit for Virtualization) mit vCenter, inventarisiert VMs, konvertiert Disks und führt Cold- oder Warm-Migrationen durch.

Wie Sie auswählen

Gehen Sie von Ihren Workloads und Ihrem Team aus, nicht von einer Produkt-Shortlist. Ein paar Fragen, die die guten Passungen verlässlich von den schmerzhaften trennen:

• Was betreiben Sie eigentlich? Überwiegend langlebige Windows- und Linux-VMs? Dann ist eine VM-zentrierte Plattform der Weg des geringsten Widerstands. Containerisieren Sie bereits? Ein Kubernetes-nativer Weg könnte zwei Stacks zu einem zusammenführen.
• Brauchen Sie Mandantenfähigkeit und Self-Service? Falls ja, sind Sie im Private-Cloud-Bereich (OpenStack, CloudStack, OpenNebula) und nicht bei einem Single-Tenant-Hypervisor-Manager.
• Wie reif ist Ihr Betrieb? Die Leistungsfähigkeit von OpenStack geht mit realen Day-2-Kosten einher. Seien Sie ehrlich, ob Sie die Fähigkeiten haben - oder einstellen, oder auslagern werden -, um es zu betreiben.
• Welche VMware-Funktionen sind tragend? vMotion, HA, DRS, vSAN, NSX-Mikrosegmentierung und Site Recovery Manager haben alle Open-Source-Äquivalente, doch sie lassen sich selten eins zu eins abbilden. Inventarisieren Sie die Funktionen, von denen Sie wirklich abhängen, nicht die, die Sie lizenziert haben.
• Storage- und Networking-Realität. Die meisten Open-Source-Wege stützen sich auf Ceph für Storage und OVN/Open vSwitch für Networking. Ihr bestehendes SAN, Ihre Fabric und Ihre Segmentierungsrichtlinien benötigen ein bewusstes Design, kein Copy-and-paste.

Ein phasenweiser Migrationsansatz

Migrationen scheitern, wenn sie als einmaliger Cutover behandelt werden. Sequenzieren Sie die Arbeit und reduzieren Sie das Risiko an jedem Gate.

1. Bewerten

Erstellen Sie ein vollständiges Inventar: VMs, Abhängigkeiten, Storage-Layout, Netzwerk- und Sicherheitsrichtlinien sowie die Lizenz-Exposition samt Terminen. Bewerten Sie jeden Workload nach Downtime-Toleranz, Komplexität und Compliance-Sensibilität. Das Ergebnis ist ein priorisiertes Migrations-Backlog, keine Tabelle, die veraltet.

2. Entwerfen

Wählen Sie die Zielplattform(en) pro Workload-Gruppe und entwerfen Sie die Storage- und Netzwerkarchitektur explizit. Hier bilden Sie NSX-Richtlinien auf OVN-Security-Groups ab, vSAN auf Ceph und DRS-artige Platzierung auf Ihren neuen Scheduler. Legen Sie hier auch die Migrationsmechanik fest: Cold- vs. Warm-Migration, Tooling und Rollback.

3. Pilotieren

Setzen Sie das Ziel in einem Labor auf und migrieren Sie 10-20 % der produktionsäquivalenten Workloads. Messen Sie die Performance-Parität, validieren Sie das HA-Failover, testen Sie Backup und Restore und erproben Sie Ihre Sicherheitsrichtlinien. Ein zwei- bis vierwöchiger Pilot bringt die Überraschungen zutage, solange sie noch günstig sind.

4. Migrieren

Verschieben Sie in Wellen, nach Risiko sequenziert, und halten Sie die Produktionsauswirkung pro Welle klein (eine Obergrenze von 10-15 % ist eine sinnvolle Faustregel). Beginnen Sie mit zustandslosen Dev-/Test-Systemen, dann den Web-Tiers, dann den Datenbanken und geschäftskritischen Systemen. Behalten Sie die alte Umgebung als Rollback-Ziel, bis jede Welle validiert ist.

5. Betreiben

Eine neue Plattform braucht neue Runbooks, Monitoring, Patching-Kadenz, Kapazitätsplanung und DR-Verfahren. Planen Sie den Wissenstransfer ein, damit das Team den Day-2-Betrieb selbst übernimmt, statt auf unbestimmte Zeit von demjenigen abzuhängen, der die Migration durchgeführt hat.

Fallstricke, um die Sie herumplanen sollten

• Das 10-%-Problem. Eine kleine Gruppe von Anwendungen, die nur auf VMware laufen, verursacht den Großteil des Migrationswiderstands. Identifizieren Sie sie früh; sie diktieren Ihren Zeitplan.
• Networking ist schwieriger als Compute. vSwitches, Port-Gruppen und NSX-Richtlinien lassen sich nicht direkt übertragen. VLAN-Unstimmigkeiten und das Neuerstellen von Richtlinien sind eine der häufigsten Ursachen für verlängerte Downtime.
• DR-Tests dauern Monate, nicht Wochen. Entdecken Sie das nicht erst kurz vor dem Go-Live. Binden Sie Compliance- und DR-Stakeholder schon in der Designphase ein.
• Day-2 unterschätzen. Die Lizenz, die Sie kündigen, wird durch operative Verantwortung ersetzt. Budgetieren Sie für Skills, Automatisierung und Observability.
• Tool-Monogamie. Widerstehen Sie dem Drang, sich für alles auf eine Plattform festzulegen, bevor der Pilot sie bewährt hat. Gemischte Landschaften sind normal und oft optimal.

Der EU-Souveränitätsvorteil

Für europäische Organisationen, und für deutsche im Besonderen, ist diese Migration auch eine Souveränitätschance. Open-Source-Infrastruktur auf in der EU gehosteter Kapazität zu betreiben, entfernt zwei Ebenen externer Abhängigkeit auf einmal: Die Software wird nicht von der Roadmap oder Preisgestaltung eines einzelnen ausländischen Anbieters kontrolliert, und die Daten bleiben unter EU-Jurisdiktion. Genau diese Kombination - Open Source plus EU-Datenhaltung - ist das, worauf die Rahmenwerke hinter dem jüngsten deutsch-französischen Vorstoß zur digitalen Souveränität und die Cloud-Souveränitätsbemühungen der Europäischen Kommission abzielen.

Der strategische Punkt heißt Verhandlungsmacht. Offene Standards bedeuten, dass Ihre Workloads portabel bleiben, dass Sie aus einer Position der Wahlfreiheit statt der Abhängigkeit verhandeln und dass Ihre Compliance-Aufstellung (DSGVO, branchenspezifische Datenregeln) eingebaut statt nachträglich angeschraubt ist. Souveränität ist hier eine Fähigkeit, für die Sie gestalten, kein Häkchen auf einer Checkliste.

FAQ

Ist Proxmox ein echter Ersatz für VMware?

Für VM-zentrierte Umgebungen: ja. Proxmox VE deckt Clustering, Live-Migration, HA und Ceph-gestützten Storage ab. Es ist kein vollständiges Private-Cloud-IaaS, wenn Sie also mandantenfähigen Self-Service brauchen, sehen Sie sich stattdessen OpenStack, CloudStack oder OpenNebula an.

Proxmox vs. VMware - was ist der größte praktische Unterschied?

Architektur und Ökosystem. VMware bietet einen eng integrierten Single-Vendor-Stack; Proxmox setzt offene Komponenten zusammen (KVM, LXC, Ceph). Sie tauschen Anbieterintegration und Enterprise-Supportverträge gegen Kostenkontrolle, keine Lizenzierung pro Core und keinen Lock-in.

Wie lange dauert eine VMware-Migration?

Es hängt von der Größe der Landschaft und dem Anteil reiner VMware-Workloads ab, doch denken Sie in Quartalen, nicht in Wochen. Ein phasenweiser Plan mit echtem Pilot und wellenbasiertem Cutover hält Risiko und Downtime im Zaum.

Müssen wir alles auf einmal von VMware wegbewegen?

Nein. Unbefristete Lizenzen laufen ohne Support weiter, was Zeit verschafft. Die meisten Teams migrieren in Wellen und behalten während des Übergangs einen schrumpfenden VMware-Fußabdruck.

Können VMs und Container auf einer Plattform laufen?

Ja. KubeVirt betreibt VMs als Kubernetes-Objekte und lässt Sie beide auf einer einzigen Control Plane zusammenführen. Das passt zu Teams, die bereits in cloud-native Operations investiert haben.

Wo Rapid Solutions ins Bild passt

Wir sind eine herstellerneutrale Engineering-Beratung mit Büros in Amsterdam und Dubai. Wir verkaufen keine Plattform, daher richtet sich unsere Empfehlung nach Ihren Workloads, Ihrem Team und Ihren Compliance-Anforderungen - nicht danach, womit wir Geld verdienen müssen. Wir unterstützen bei der Bewertung, dem Zieldesign, dem Pilot, der wellenbasierten Migration und dem Day-2-Betriebsmodell, durchgängig mit einem Open-Source-First- und Sovereign-by-Design-Ansatz.

Wenn Sie vor einer VMware-Verlängerung stehen oder einen Ausstieg planen, kontaktieren Sie Rapid Solutions, und wir helfen Ihnen, einen Migrationspfad zu bauen, der zu dem Stack passt, den Sie tatsächlich betreiben.