- Viele Unternehmen suchen wegen der hohen Lizenzkosten von VMware und der jüngsten Veränderungen nach Alternativen
- Mehrere kleine und mittelgroße IT-Teams prüfen einen Wechsel zu Open-Source-Virtualisierungslösungen wie Proxmox VE und oVirt
- Häufig wird auch eine Migration zu anderen Hypervisoren wie KVM, Xen oder Hyper-V in Betracht gezogen
- Bei realen Migrationen bereiten vor allem Methoden zur Datenübertragung und die Kompatibilität mit bestehenden Workflows Sorgen
- In der Community wird intensiv über Kosten-/Leistungsanalysen bei der Migration großer Infrastrukturen und Umsetzungsstrategien diskutiert
Hintergrund der Suche nach VMware-Alternativen
- Viele Unternehmen sehen sich derzeit mit Änderungen an den VMware-Lizenzmodellen und steigenden Kosten konfrontiert
- Dadurch beschleunigt sich die Suche nach Lösungen, die bestehende VMware-Infrastrukturen ersetzen können
Wichtige alternative Virtualisierungsplattformen
- Proxmox VE: Eine Open-Source-Virtualisierungslösung, die wegen der komfortablen webbasierten Verwaltung und des aktiven Community-Supports von vielen kleinen und mittelgroßen Organisationen in Betracht gezogen wird
- oVirt: Eine auf Red Hat basierende Enterprise-Virtualisierungslösung auf Grundlage von KVM mit Funktionen für Skalierbarkeit und Automatisierung
- Xen: Ein Open-Source-Hypervisor, der seit Langem für Stabilität und Leistung bekannt ist und auch von wichtigen kommerziellen Anbietern unterstützt wird
- Hyper-V: Die Lösung von Microsoft, die sich gut in Microsoft-Infrastrukturen einfügt und besonders für Windows-Umgebungen geeignet ist
Migrationsthemen und Diskussionen
- Beim tatsächlichen Umstieg treten praktische Herausforderungen auf, etwa bei der Übertragung bestehender VM-Daten, der Kompatibilität von Netzwerk und Storage sowie der Neuschreibung von Automatisierungsskripten
- In den meisten Fällen werden Prüfverfahren über Benchmarks, Testmigrationen und kleine Pilotprojekte durchgeführt
Meinungen aus Community und von Fachleuten
- Viele Nutzer bevorzugen einen schrittweisen Ansatz, bei dem zunächst nur ein Teil der Services migriert wird
- Zudem werden vielfältige Erfahrungen und Ratschläge zu den jeweiligen Stärken und Schwächen der Lösungen hinsichtlich Leistung, Stabilität und Skalierbarkeit geteilt
Fazit und strategischer Ansatz
- Verschiedene Alternativlösungen werden bereits praktisch eingesetzt, um die Abhängigkeit von VMware zu verringern
- Je nach Größe und Komplexität der Infrastruktur, Budget und IT-Know-how einer Organisation wird die Notwendigkeit einer maßgeschneiderten Migrationsstrategie betont
1 Kommentare
Hacker-News-Meinung
Die 5-Jahres-ELA unserer Institution für VMware ist von 1,5 Mio. US-Dollar auf 12 Mio. US-Dollar hochgeschnellt; ich arbeite im Hochschulbereich.
Eine Hyper-V-Umgebung wurde vor ein paar Monaten aufgebaut und ist bereits in unserem Microsoft-ELA enthalten, sodass wir das Geld stattdessen für besseren Support ausgeben konnten.
Es gibt ein separates Team, das sich ausschließlich um „genAI stuff“ kümmert.
Vor etwa drei Wochen haben wir mit der VM-Migration begonnen und ungefähr 500 von 3.500 Maschinen umgestellt.
Die HPC-Umgebung für forschungsunterstützte Projekte wird auf Bare Metal verlagert, und die VM-Umstellung dient für temporäres HPC und allgemeine Infrastruktur.
Einige große Applikationsserver wie SAP Hana könnten auf VMware bleiben, falls SAP Hyper-V nicht unterstützt.
Dieser Sommer war wirklich hart, aber am Ende haben wir es geschafft.
„Wenn Sie ein Global-2000-Unternehmen sind, will VMware Ihr Geschäft — wenn nicht, interessiert es sich nicht wirklich für Sie.“
Verwandter Artikel
In meinem Umfeld unter Freunden aus dem SME-Bereich ist das gerade ein heißes Thema.
Aus schwedischer Perspektive sind die wichtigsten Anbieter HPE und Nutanix.
Ich halte es für eine geniale Entscheidung von HPE, mehrere Hypervisor-Backends zu unterstützen und ein eigenes Frontend darüberzusetzen; das ist der einzige Weg nach vorn.
In meinem aktuellen Job nutzen wir Proxmox und sind sehr zufrieden.
Aus Sicht von jemandem mit VMware-Erfahrung denke ich, dass die meisten Unternehmen recht problemlos durch Proxmox ersetzt werden können.
Die Einführung von Proxmox verläuft langsamer, weil es kein Enterprise-SLA gibt; sobald es einen Enterprise-Vertrag gibt, spielt der Preis kaum eine Rolle.
Persönlich würde ich gern sehen, dass sich KubeVirt oder Openshift+KubeVirt stärker verbreiten; es wirkt geradezu genial, eine Hypervisor-Laufzeit an die ohnehin weit verbreitete kubernetes API anzuhängen.
Ich mache mir Sorgen, dass Proxmox diese Chance verpassen könnte.
Es war in einer einzigartigen Position, VMWare zu ersetzen, aber das Unternehmen wirkt klein und konservativ und scheint nicht den Ehrgeiz zu haben, global groß zu expandieren.
Was der Proxmox-Premiumvertrag umfasst:
Zugang zum Enterprise-Repository, vollständiger Funktionsumfang, Support über das Kundenportal, unbegrenzte Support-Tickets, Antwort innerhalb von 2 Stunden, Remote-SSH-Support und Aktivierung des Offline-Subscription-Keys.
Es ist wirklich schade, dass SAN und ISCSI nicht unterstützt werden.
Ich mag diese Art von Setup und würde sie gern weiter nutzen.
Ich habe vorgeschlagen, auf Bare-Metal-Openshift umzusteigen, aber wegen fehlender Funktionen gab es Widerstand.
Am Ende fiel die Entscheidung für HPE.
Ich denke, Openshift+KubeVirt ist wirklich gut positioniert, um in diesen Markt vorzustoßen.
In mehreren Bereichen, in denen ich gearbeitet habe, wird Openshift stark genutzt, daher ist es eine natürliche Erweiterung.
Ich hatte die Bündelungsstärke von MSFT bei Hyper-V vergessen, aber das wird in diesem Thread oft erwähnt.
Broadcom hat die Preise so stark erhöht, dass wir zu proxmox wechseln.
Mehrere Leute im IT-Team hatten zu Hause bereits Erfahrungen mit proxmox, und als die Kosten für das Beibehalten von Broadcoms VMWare deutlich höher wurden als das Risiko eines gescheiterten Migrationsprojekts, haben wir ohne Zögern die Umstellung beschlossen.
Wir haben einen Teil der Farm migriert und per A/B-Test verglichen, die Ergebnisse waren gut, und wir dürften die vollständige Umstellung vor der nächsten Broadcom-Zahlung abschließen können.
Broadcom hat uns geholfen, die Entscheidung schneller zu treffen.
Für mich persönlich sind Broadcom und Oracle die beiden Unternehmen, mit denen ich „niemals freiwillig Geschäfte mache“; bemerkenswert, dass Broadcom inzwischen auf Oracles Niveau angekommen ist.
Oracle will wenigstens zahlende Kunden, Broadcom scheint an Kunden an sich gar nicht interessiert zu sein.
Ich arbeite bei einem MSP und betreue hauptsächlich KMU-Kunden.
Nach Broadcoms Übernahme von vmware sind die Lizenzkosten massiv gestiegen; dieses Jahr ging es wegen der Mindestanzahl an Kernen auf bis zu 20.000 US-Dollar pro Jahr hoch, und vermutlich wird es weiter steigen.
Wenn man noch bestehende unbefristete (Perpetual-)Lizenzen hat, kann man durch Trennung des Management-VLANs vom Internet noch ein paar Jahre durchhalten, aber ohne Patches fällt man irgendwann bei internen Audits durch.
Bei verlängerbaren Lizenzen kann man nach Ablauf nicht einmal mehr VMs einschalten; nach einem Neustart bleiben sie aus.
Etwa die Hälfte wird auf Hyper-V migriert, und die meisten nutzen ohnehin schon Windows-Server.
Es gibt einige Unterschiede, aber Hyper-V bietet alle benötigten Funktionen, und die Lizenz ist bereits enthalten.
Veeam macht Migrationen zwischen VMs einfach, daher nutzen Kunden es oft auch für Backups.
Ein beachtlicher Teil migriert nach Azure oder in andere Hosting-Umgebungen; wenn es keine zentralen LOB-Systeme wie einen Dateiserver in der Zentrale gibt, ist der Umzug ziemlich einfach.
Einige wechseln zu nutanix oder bauen es aus.
Aus Sicht von Server-/Entwicklerteams hatten wir mit allerlei Instabilitäten zu kämpfen, etwa seltsamem VM-Verhalten oder enttäuschender Performance, und andere Systemverantwortliche hatten ähnliche Probleme.
Irgendetwas hat sich innerhalb kurzer Zeit entscheidend verändert, und letztlich führte das zum Weggang.
Was im upstream Linux unterstützt wird, ist ein libvirtd-basierter Stack, daher sollte man sich auch diese Richtung ansehen.
Manche nutzen proxmox nur wegen der UI, um Zertifizierungsanforderungen zu erfüllen, und viele meiner Kunden sind stattdessen zu cockpit dashboard oder kubernetes gewechselt.
Das hängt von Größe und Provisioning-Anforderungen ab.
cockpit ist mein Favorit, weil es leicht einzurichten ist, eignet sich aber nicht für Cluster-Größen und hat den Nachteil, dass man Web-UI und mehrere cockpit-server-Daemons separat aufsetzen muss.
Proxmox ist alt und Perl-basiert, aber brauchbar; beim Storage-Clustering braucht man eine Dateisystem-Schicht wie ceph, was etwas mühsam ist.
Es gibt auch Openshift, aber wegen der Sorge vor IBM-/RedHat-Abhängigkeit schrecken kleine und mittlere Unternehmen davor zurück.
cockpit, proxmox, Erläuterung zu cockpit machines
Ich arbeite bei einem Block-Storage-Anbieter und beobachte eine Vielzahl KVM-basierter Cloud-Management-Plattformen, zu denen von VMware weg migriert wird.
Kunden wechseln zu OpenNebula, CloudStack, Proxmox, OpenStack, HP VME, Oracle Virtualization und sogar zu selbstgebauten Lösungen.
Der wichtigste gemeinsame Nenner ist der Fokus auf ein Storage-Backend, das nicht an einen bestimmten Hypervisor gebunden ist und vorhersagbare Hochleistung liefert.
Der Vorteil des KVM-Ökosystems besteht darin, dass man frei die für die Aufgabe besten Tools wählen kann und sich diese Freiheit bis in die Storage-Schicht hinein erstreckt.
Eine gute softwaredefinierte Block-Storage-Lösung erleichtert den Wechsel von VMware durch Funktionen wie Datenmigration und Disaster Recovery.
KVM-Lösungen gewinnen definitiv an Schwung.
Microsoft scheint am meisten davon zu profitieren.
Es ist traurig, dass Unternehmen erst von Closed-Source-Software verbrannt werden und dann denselben Weg noch einmal gehen.
Auch bei Nutanix explodiert die Nachfrage.
Zum Glück verzeichnen Alternativen wie Proxmox und Xcp-ng ebenfalls rekordverdächtige Adoptionsraten.
Ich bin an einem Teil des Apache-CloudStack-Projekts beteiligt, und auch dieser Dienst erlebt einen beispiellosen Nachfrageschub.
Der KVM-Hypervisor ist de facto zum Standard geworden, und dank des Tools virt-v2v ist die Migration von vmware-Gastsystemen einfach geworden.
Bei PriorCo habe ich damals um 2023/2024 herum die Optionen in einer Präsentation zusammengefasst.
Wir schlugen drei Wege vor: bei vmware bleiben, zu Apache Cloudstack migrieren oder zu Nutanix migrieren, aber am Ende fiel die Entscheidung, die verbleibende Infrastruktur per Lift-and-Shift zu AWS zu verlagern.
Wenn ich verantwortlich gewesen wäre, wäre Cloudstack passender gewesen; wir hatten die Fähigkeiten dafür und hätten uns aus der Abhängigkeit lösen können.
Nutanix stand nur wegen seines technischen Portfolios auf der Liste, aber Profitabilität, Finanzstruktur und der Fokus auf SaaS ließen befürchten, dass man letztlich in dieselben Probleme wie bei vmware geraten könnte.
Es gibt verschiedene Optionen auf Basis von KVM/QEMU oder OpenStack; Virtuozzo war ebenfalls beeindruckend, aber als Gesamtpaket etwas unbefriedigend.
Oxide war wegen seiner Einfachheit und Integration attraktiv, aber intern gab es nicht genug Nachfrage nach einem Produkt eines jungen Startups.
Microsoft und Oracle wurden wegen Kosten und Lizenzierungsaufwand ausgeschlossen, und IBM/Openshift ebenfalls, weil unsere Private Cloud zu 100 % aus VMs bestand und nur etwa 20 % des gesamten Produktbestands containerisiert werden konnten.
Der wichtigste Rat ist, die Eigenschaften der aktuellen Workloads genau zu verstehen und danach die passende Option auszuwählen.
Alle betonen K8s und Container, aber in Umgebungen, die überwiegend aus VMs bestehen, sind diese Optionen meist kaum sinnvoll.
<i>„VMware's in court again. Customer relationships rarely go this wrong“</i> (190 Kommentare, 2025)
Verwandter Link
<i>„Proxmox VE: Import Wizard for Migrating VMware ESXi VMs“</i> (100 Kommentare, 2024)
Verwandter Link
Ich fordere vor allem bei Corporate-IT-Teams mit Nachdruck, alternative Tools oder Workflows zuzulassen.
Tatsächlich ist genau das das größte Hindernis.
Unser Team hat genug DevOps-Kompetenz, um auch Container oder die Paketierung von Entwicklungsumgebungen umzusetzen, aber das Corporate-Security-Team wiederholt auf unsere Gesprächsanfragen nur „Verstoß gegen die Richtlinie“.
Diese Erfahrung habe ich nicht nur an einem Ort gemacht, sondern wiederholt auch in guten Engineering-/Software-Unternehmen.
Bei mir ist es genau dasselbe, und es ist wirklich frustrierend.
Das Cybersecurity-Team hat alles in der Hand, interessiert sich aber kaum für DevOps oder Prozessmanagement und verfügt dort auch nicht über viel Fachwissen.
Am Ende prallt man im Gespräch an einer menschlichen Firewall ab und bekommt immer nur ein „Nein“.
Organisatorisch fragen sich alle, warum sich nichts verbessert.
Probleme mit dem Vertrauen in Drittanbieter sind kein Witz.
Wer soll schon seine eigentliche Arbeit unterbrechen, um einen neuen Kernanbieter zu auditieren?
Auch unser Team kann mit DevOps-Know-how Container und die Paketierung von Entwicklungsumgebungen umsetzen.
Bei meinem Arbeitgeber sind wir ohne Kubernetes voll auf Container gegangen, und die Ergebnisse waren sehr gut.
Es ist wirklich schade, dass es gegen solche Ansätze so viel Widerstand gibt, und ich hoffe, dass es am Ende gut ausgeht.