Plattform nach VMware: OpenStack, Proxmox, Hyper-V und KubeVirt im Vergleich
Plattform nach VMware: OpenStack, Proxmox, Hyper-V und KubeVirt im Vergleich
Wer VMware verlässt, ersetzt mehr als einen Hypervisor. Für die meisten Teams war vSphere ein ganzes Paket: vCenter, vMotion, DRS, HA, die Anbindung der Datensicherung, das Monitoring-Plugin, ein Hersteller für Supportfälle und viele Jahre Routine. Keine Alternative bildet das eins zu eins ab. Jede ersetzt einen Teil davon gut, einen anderen schlechter und manches gar nicht.
Eine Vorbemerkung, damit Sie diesen Text einordnen können: Wir betreiben SUSE Virtualization als Managed Service, und unser Migrationswerkzeug FCS Beam migriert von vSphere auf mehrere der hier besprochenen Plattformen. Wir haben also Interessen. Deshalb steht bei jeder Plattform auch, wofür sie nicht taugt, bei unserer eigenen eingeschlossen.
Der Anlass ist bekannt. Broadcom hat die Übernahme von VMware am 22. November 2023 abgeschlossen. Seit dem 11. Dezember 2023 verkauft Broadcom keine unbefristeten VMware-Lizenzen mehr. Das Angebot läuft seither über Abonnements und wenige Pakete, vor allem VMware Cloud Foundation und vSphere Foundation. Was das für Ihren Vertrag bedeutet, wissen Sie besser als wir. Hier geht es nur noch um die Frage, wohin.
Die Kurzfassung
Falls Sie nur diesen Abschnitt lesen:
- Überschaubare Umgebung, Linux-Team, keine Mandanten: Proxmox VE.
- Windows-Haus, alle Hosts ohnehin mit Datacenter lizenziert: Hyper-V.
- Kubernetes läuft schon oder kommt sicher: SUSE Virtualization oder OpenShift Virtualization, je nachdem, was im Haus ist.
- Viele Mandanten, Self-Service per API, eigenes Plattformteam: OpenStack.
- Ein Hersteller für Hardware und Software, bewusst gewählt: Nutanix AHV.
- Kein Team, das eine Plattform bei einer Störung selbst eingrenzen kann: betreiben lassen.
Der Rest des Artikels begründet diese Zuordnung und nennt die Fälle, in denen sie nicht stimmt.
Vier Fragen vor jedem Feature-Vergleich
Die Feature-Listen der Hersteller ähneln sich mehr als die Plattformen im Betrieb. Wichtiger sind vier Fragen.
Wer betreibt die Plattform, und was kann dieses Team heute? Das ist das am meisten unterschätzte Kriterium. Eine Plattform, die Ihr Team bei einer Störung nicht selbst eingrenzen kann, ist die falsche, egal wie gut sie im Vergleich abschneidet. Ein Linux-Team, ein Windows-Team und ein Kubernetes-Team kommen hier zu unterschiedlichen Antworten, und alle drei haben recht.
Brauchen Sie Mandanten und Self-Service? Sollen Fachbereiche oder Kunden selbst VMs anlegen, mit Kontingenten, eigenen Netzen und einer API, dann brauchen Sie eine Cloud-Plattform. Legen zwei Administratoren die VMs für alle an, brauchen Sie das nicht und sollten es auch nicht mitbetreiben.
Was passiert mit dem Speicher? Ein vorhandenes SAN weiter zu nutzen ist etwas anderes, als auf verteilten Speicher wie Ceph oder Longhorn umzusteigen. Wer bisher ein Storage-Array hatte und künftig Ceph betreibt, lernt ein zweites Fachgebiet dazu.
Welche Datensicherung und welches Monitoring sollen bleiben? Fragen Sie Ihren Backup-Hersteller konkret, ob er VMs auf genau dieser Plattform und Version als VMs sichert und ob er einzelne Dateien daraus zurückholen kann. Ein „wird unterstützt“ auf einer Folie reicht nicht.
Die Optionen im Überblick
| Plattform | Passt gut, wenn … | Passt schlecht, wenn … | Betriebsaufwand | Kostenmodell |
|---|---|---|---|---|
| Proxmox VE | überschaubare Cluster, Linux-Team, einfacher Einstieg | viele Mandanten mit Self-Service und Kontingenten | niedrig bis mittel, mit Ceph mittel | Open Source, Subskription je CPU-Sockel und Jahr für Enterprise-Repository und Support |
| Microsoft Hyper-V | Windows-lastige Umgebung, Datacenter-Lizenzen vorhanden | überwiegend Linux oder Ziel ist weniger Herstellerabhängigkeit | mittel, Verwaltung auf mehrere Werkzeuge verteilt | Windows Server je Kern, Datacenter mit unbegrenzt vielen VMs |
| OpenStack (Kolla-Ansible) | viele Mandanten, Self-Service, API zuerst, große Umgebungen | kleines Team, wenige Hosts | hoch, eigenes Plattformteam nötig | Software frei, Kosten stecken im Personal oder in einer kommerziellen Distribution |
| SUSE Virtualization | Kubernetes-Wissen vorhanden, VMs und Container zusammen | kein Kubernetes im Team | mittel bis hoch | Open Source (Harvester), Support als Subskription bei SUSE |
| OpenShift Virtualization | OpenShift ist im Haus schon Standard | OpenShift nur für VMs einführen | hoch | Red-Hat-Subskription, eigene Edition nur für VMs |
| Nutanix AHV | integriertes System aus einer Hand gewünscht | Ziel ist Herstellerunabhängigkeit | niedrig bis mittel | nur mit Nutanix-Cloud-Infrastructure-Lizenz |
| XCP-ng | Bedienung ähnlich vCenter gewünscht, kleines Budget | Werkzeuge aus der KVM-Welt gefordert | niedrig bis mittel | Open Source (GPLv2), Support-Abos von Vates |
| Managed (privat oder Public Cloud) | Betrieb soll nicht im eigenen Team liegen | volle Kontrolle über Hardware und Update-Zeitpunkte nötig | im eigenen Haus gering | laufende Gebühr, Ausstieg vertraglich klären |
Die Spalte Betriebsaufwand ist unsere Einschätzung für ein Team, das bisher vSphere betrieben hat.
Proxmox VE
Proxmox VE ist eine Debian-basierte Plattform mit KVM für VMs und LXC für Container, verwaltet über eine Weboberfläche, mit Ceph und ZFS als eingebauten Speicheroptionen. Seit Frühjahr 2024 bringt sie einen Import-Assistenten für VMs direkt aus ESXi mit. Die Software ist Open Source. Für das stabile Enterprise-Repository und Support gibt es Subskriptionen, abgerechnet je belegtem CPU-Sockel und Jahr. Alle Stufen haben denselben Funktionsumfang und unterscheiden sich im Support.
Das Ökosystem ist gewachsen. Neben dem hauseigenen Proxmox Backup Server unterstützt Veeam Proxmox VE seit Version 12.2 vom August 2024. Und es geht längst nicht nur um kleine Installationen. Die Stanford University hat nach eigenen Angaben rund 1.500 VMs von VMware auf Proxmox umgezogen und dabei mehr als 60 Server in sechs eigenständige Cluster aufgeteilt. Wer viele Hosts hat, plant also eher mit mehreren Clustern als mit einem großen.
Wo es knirscht, ist die Mandantenfähigkeit. Proxmox kennt Benutzer, Rollen und Ressourcen-Pools, aber kein Projektmodell mit Kontingenten und Self-Service in der Tiefe, die OpenStack mitbringt. Und Ceph ist in Proxmox gut integriert, bleibt aber Ceph. Es braucht ein eigenes, ausreichend dimensioniertes Netz und jemanden, der weiß, was bei einem ausgefallenen OSD oder einem vollen Pool passiert.
Für viele Mittelständler ist Proxmox VE die Plattform mit dem besten Verhältnis von Aufwand zu Ergebnis. Wir würden sie nicht wählen, wenn Abteilungen oder Kunden selbst VMs bestellen sollen, mit Kontingenten und eigenen Netzen pro Mandant.
Microsoft Hyper-V
Hyper-V steckt in Windows Server. Lizenziert wird Windows Server je Kern, und laut Microsoft erlaubt die Standard Edition zwei VMs je Lizenz, die Datacenter Edition unbegrenzt viele. Wer seine Hosts ohnehin mit Datacenter lizenziert, weil darauf viele Windows-VMs laufen, hat den Hypervisor also schon bezahlt. Das ist das stärkste Argument für Hyper-V, und in Windows-lastigen Umgebungen ist es ein gutes.
Dazu kommt Vertrautheit. Ein Team, das Active Directory, Windows-Cluster und PowerShell beherrscht, fühlt sich in Hyper-V eher zu Hause als in Ceph oder Kubernetes. Veeam und andere große Backup-Hersteller unterstützen Hyper-V seit vielen Jahren.
Dagegen spricht die verteilte Verwaltung. Hyper-V-Manager, Clusterverwaltung, Windows Admin Center und für größere Umgebungen der separat lizenzierte System Center Virtual Machine Manager teilen sich die Aufgaben, die in VMware ein vCenter erledigt hat. Ein Linux-Team wird damit selten glücklich.
Hyper-V ist eine schlechte Wahl, wenn der eigentliche Grund für den Wechsel die Abhängigkeit von einem Hersteller war. Sie tauschen dann Broadcom gegen Microsoft, und beim nächsten Wechsel des Lizenzmodells stehen Sie wieder am selben Punkt. Für Umgebungen, die überwiegend Linux betreiben, würden wir Hyper-V ebenfalls nicht wählen.
OpenStack, betrieben mit Kolla-Ansible
OpenStack ist eher ein Baukasten für eine eigene Cloud als ein Ersatz für vCenter. Nova für Compute, Neutron für Netze, Cinder für Block-Speicher, Glance für Images, Keystone für Identitäten und Projekte, dazu viele optionale Dienste. Seine Stärken liegen dort, wo Proxmox und Hyper-V schwach sind: Projekte mit Kontingenten, Self-Service über Weboberfläche und API, eigene Netze pro Mandant, Automatisierung etwa mit Terraform.
Kolla-Ansible liefert dafür Container und Werkzeuge, mit denen sich OpenStack reproduzierbar ausrollen und aktualisieren lässt. OpenStack erscheint im Halbjahrestakt, zuletzt 2026.2 „Hibiscus“ am 30. September 2026. Ausgewählte Releases sind als SLURP markiert und erlauben Upgrades, bei denen ein Release übersprungen wird. Ein Upgrade pro Jahr ist damit machbar, bleibt aber jedes Mal ein kleines Projekt.
Der Preis ist der Betrieb. Neutron verlangt echtes Netzwerkwissen, und wer eine Störung im Overlay-Netz suchen muss, sollte wissen, wo er anfängt. Ein automatischer Neustart von VMs nach einem Host-Ausfall, wie ihn vSphere HA liefert, ist nicht eingebaut, dafür gibt es ein Zusatzprojekt (Masakari). Die Auswahl an Backup-Werkzeugen, die OpenStack-Instanzen samt Volumes sichern und wiederherstellen, ist kleiner als bei vSphere oder Hyper-V. Fragen Sie dort besonders genau nach.
Wir würden OpenStack niemandem empfehlen, der dafür nicht dauerhaft mindestens zwei Leute abstellen kann. Für eine Handvoll Hosts ist es zu viel Plattform. Für einen Anbieter oder eine große Organisation mit vielen Projekten setzt es den Self-Service-Gedanken dagegen am konsequentesten um.
KubeVirt: SUSE Virtualization und OpenShift Virtualization
KubeVirt bringt VMs in Kubernetes. Eine VM ist dort ein Kubernetes-Objekt, ihr Speicher kommt über die Speicherschnittstelle des Clusters, ihr Netz über dessen Netzwerk-Plugins. Zwei Plattformen bauen darauf auf und richten sich ausdrücklich an VMware-Umsteiger.
SUSE Virtualization ist der neue Name von Harvester, gebaut auf Kubernetes, KubeVirt und Longhorn als verteiltem Speicher. Das Open-Source-Projekt heißt weiterhin Harvester, SUSE bietet Support für die kommerzielle Variante. Red Hat liefert OpenShift Virtualization als Teil von OpenShift und seit Januar 2025 mit der OpenShift Virtualization Engine eine Edition nur für VMs, samt Migration Toolkit for Virtualization.
Der Vorteil zeigt sich, wenn Kubernetes ohnehin im Haus ist. VMs und Container teilen sich Netz, Speicher, Rechteverwaltung und Werkzeuge, und VMs lassen sich genauso deklarativ und per Git verwalten wie Anwendungen.
Der Nachteil liegt eine Ebene tiefer. Unter jeder VM liegt ein Kubernetes-Cluster. Ein Problem, das sich als hängende VM zeigt, kann in der Speicherschicht, im Netz-Plugin oder in einem Operator liegen. Wer das nicht eingrenzen kann, steht bei einer Störung vor einer Plattform, die eigentlich nur VMs betreiben sollte. Updates folgen dem Rhythmus von Kubernetes und seinen Komponenten. Auch hier gilt die Frage an den Backup-Hersteller, und zwar sehr konkret: Sichert er VMs als VMs, oder sieht er nur Kubernetes-Objekte?
Wir betreiben SUSE Virtualization für unsere Kunden, Kubernetes-Betrieb gehört bei uns ohnehin zum Alltag. Für ein Team, das bisher nur vSphere kennt und selbst betreiben will, wäre es trotzdem nicht unsere erste Empfehlung. Dann eher Proxmox VE, oder SUSE Virtualization als Managed Service, bei dem jemand anderes die Kubernetes-Schicht betreibt.
Für OpenShift Virtualization gilt Ähnliches. Steht OpenShift schon im Rechenzentrum, liegt es nahe. Nur für VMs würden wir OpenShift nicht einführen. Die VM-Edition ändert das Lizenzmodell, der Unterbau bleibt derselbe.
Nutanix AHV und XCP-ng
Nutanix AHV wird nicht einzeln verkauft, sondern kommt mit der Lizenz für Nutanix Cloud Infrastructure. Nutanix ist historisch hyperkonvergent, inzwischen kann AHV aber auch externen Speicher ausgewählter Partner nutzen. Für den Umzug gibt es mit Nutanix Move ein kostenloses Werkzeug. AHV passt, wenn Sie ein integriertes System aus einer Hand wollen und das bewusst entscheiden. Lautet Ihre Lehre aus den letzten Jahren, nie wieder alles von einem Hersteller zu beziehen, passt es nicht.
XCP-ng basiert auf dem Xen-Hypervisor, steht unter GPLv2 und wird von der französischen Firma Vates entwickelt, die auch Support-Abos verkauft. Verwaltet wird es mit Xen Orchestra, das eine Datensicherung und einen Import direkt von ESXi-Hosts mitbringt. Das Bedienmodell erinnert von allen Optionen am ehesten an vCenter. Der Haken: Xen ist ein anderer Hypervisor als KVM, auf dem Proxmox VE, die KubeVirt-Plattformen, Nutanix AHV und OpenStack in der Regel aufbauen. Wissen und Werkzeuge aus dieser Welt lassen sich nur begrenzt mitnehmen.
Selbst betreiben oder betreiben lassen
Oft ist die Frage, wer die Plattform betreibt, wichtiger als die Plattform selbst. Ein Team von zwei Administratoren, das bisher vSphere betreut hat, wird mit keiner der Optionen oben auf Anhieb so sicher sein wie mit dem System, das es seit Jahren kennt. Die Lernkurve kostet Zeit, und sie fällt in die Phase, in der zugleich migriert wird.
Betreiben lassen heißt: Ein Anbieter kümmert sich um Hosts, Hypervisor, Updates und Störungen, Sie kümmern sich um Ihre VMs. Sie geben dafür Kontrolle ab, etwa über Hardware und den Zeitpunkt von Updates, und Sie gehen eine neue Abhängigkeit ein. Wer VMware wegen einer Abhängigkeit verlässt, sollte jeden Managed-Anbieter deshalb zuerst fragen, wie man wieder herauskommt: in welchem Format sich die VMs exportieren lassen, mit welchem Werkzeug und zu welchen Kosten. Das gilt ausdrücklich auch für uns.
Wir bieten Managed SUSE Virtualization auf dedizierten Hosts an. Ob sich das gegenüber Ihrem jetzigen Betrieb rechnet, können Sie im Kostenvergleich VMware On-Prem gegen Managed SUSE Virtualization mit Ihren eigenen Zahlen durchspielen.
Und die Public Cloud? Für VMs mit gleichmäßiger Dauerlast halten wir einen Hyperscaler selten für die günstigste Lösung. Für stark schwankende Last und zeitlich begrenzte Umgebungen sieht das anders aus.
Der Migrationsweg gehört zur Entscheidung
Fast jede Plattform bringt einen eigenen Weg aus VMware mit: Proxmox den ESXi-Import, Nutanix das Werkzeug Move, Red Hat das Migration Toolkit for Virtualization, Xen Orchestra seinen Import. Jedes dieser Werkzeuge kennt ein Ziel. Wie gut es Ihre schwierigen VMs umzieht, zeigt nur ein Pilot mit echten Maschinen. Wie man den aufsetzt, beschreiben wir im Artikel über Migrationsstrategien beim VMware-Exit.
Unser Werkzeug FCS Beam migriert von VMware vSphere auf SUSE Virtualization, OpenStack, Proxmox VE, Microsoft Hyper-V und KVM/libvirt. In den Quell-VMs wird dafür nichts installiert. FCS Beam passt das Gastbetriebssystem automatisch an die Zielplattform an, also Treiber, Bootloader und Netzwerkkonfiguration, für die RHEL-, Debian- und SUSE-Familie unter Linux sowie für Windows Server 2016 bis 2025. Die Daten laufen direkt von der Quelle ins Ziel. OpenShift Virtualization, Nutanix AHV und XCP-ng sind keine Ziele von FCS Beam, dort nehmen Sie die Werkzeuge der jeweiligen Plattform.
Den Umzug an eigenen VMs ausprobieren. Auf der FCS-Beam-Seite sehen Sie, wie eine Migration abläuft und was Sie mitbringen müssen. FCS Beam lässt sich 14 Tage kostenlos mit bis zu 10 VMs testen, zum Beispiel an genau den VMs, die Ihnen bei der Plattformwahl die meisten Sorgen machen.
