0800 71 20000
Kontakt
...
Virtualisierung & Proxmox

VMware-Alternativen: Proxmox, KubeVirt, Nutanix und XCP-ng

Für klassische VM-Landschaften ist Proxmox VE der pragmatischste Ausweg aus der Broadcom-Preispolitik. Wer SAP fährt oder harte Herstellerzertifizierungen braucht, landet bei RHEL mit KVM.

4 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Zwei Administratoren planen im Serverraum eine Migration
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Plattformfrage gerade jetzt auf dem Tisch liegt

Der Auslöser ist selten technisch. In den meisten Häusern kommt der Anstoß aus dem Einkauf, weil das nächste Renewal ein anderes Bündel, eine andere Mindestmenge oder eine andere Metrik mitbringt als der alte Vertrag. Seit der Übernahme durch Broadcom gibt es VMware nur noch im Abonnement, gebündelt als VMware Cloud Foundation oder vSphere Foundation und lizenziert nach physischen Kernen, mindestens 16 je CPU. Danach fängt die IT an zu rechnen, und zwar nicht nur mit Lizenzkosten, sondern mit Migrationsaufwand, Betriebsrisiko und dem Wissen, das im Team vorhanden ist. Genau in dieser Reihenfolge sollte die Entscheidung auch fallen.

Technisch geht es um mehr als einen Hypervisor-Tausch. vSphere ist bei den meisten der Ankerpunkt für Storage-Anbindung, Netzwerksegmentierung, Backup, Monitoring und Automatisierung. Wer nur den Hypervisor ersetzt, verschiebt das Problem in die Werkzeugkette: Das Backup-Produkt muss den neuen Stack unterstützen, die vCenter-API in den Skripten fällt weg, und Snapshot- sowie HA-Verhalten funktionieren anders als gewohnt. Bei Proxmox VE etwa hängt Hochverfügbarkeit an Corosync-Quorum und Shared Storage, bei KubeVirt liegen Live-Migration und Storage-Verhalten in den Händen von CSI-Treibern und StorageClasses.

Die typischen Fehler sind gut dokumentiert. Ein Proof of Concept auf drei Testmaschinen ohne echte Last, ohne Backup-Restore und ohne Ausfalltest sagt fast nichts über den Produktivbetrieb aus. Ebenso häufig wird der Schulungsaufwand unterschätzt: Ein Team, das zehn Jahre lang vCenter bedient hat, braucht Zeit für Ceph, für Cluster-Quorum oder für kubectl, und diese Zeit gehört in den Projektplan. Und es lohnt sich, die ehrliche Nullvariante mitzurechnen, nämlich bei VMware zu bleiben und den Vertrag neu zu verhandeln. Manchmal ist das die günstigste Option, gemessen an den Gesamtkosten über drei Jahre.

Miniatur-Szene: ein physischer Server links, virtuelle Maschinen als schwebende Würfel rechts, dazwischen eine Brücke
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Sechs Kriterien für die Plattformentscheidung

  1. 01 Workload-Profil: reine VMs oder VMs plus Container
  2. 02 Storage: SAN, lokal mit ZFS oder verteilt mit Ceph
  3. 03 Betriebsmodell: Herstellersupport oder Eigenbetrieb
  4. 04 Skills im Team und realistische Einarbeitungszeit
  5. 05 Werkzeugkette: Backup, Monitoring, Automatisierung
  6. 06 Gesamtkosten über drei Jahre inklusive Migration
Was du mitnimmst

Die Kandidaten und wofür sie taugen

Es gibt keine Plattform, die für alle passt. Sinnvoll ist die Zuordnung entlang deiner Workloads, deines Storage-Konzepts und der Frage, welches Know-how du aufbauen willst. So ordnen wir die Optionen ein.

Proxmox VE

Die naheliegendste Wahl, wenn du klassische VMs weiterbetreiben willst und Open Source ohne Lizenzbindung bevorzugst. KVM und LXC unter einer Weboberfläche, Cluster über Corosync, wahlweise ZFS lokal oder Ceph als verteilter Storage, integriertes Backup über den Proxmox Backup Server. Der ESXi-Import-Assistent holt VMs direkt vom laufenden vSphere. Rechne mit echtem Lernaufwand bei Ceph und bei der Quorum-Planung, denn dort entstehen die meisten Betriebsprobleme.

KubeVirt und OpenShift Virtualization

Interessant, wenn Kubernetes bei dir ohnehin schon Plattform ist und VMs und Container in derselben Control Plane laufen sollen. VMs werden zu Custom Resources, Netzwerk kommt über CNI und Multus, Storage über CSI. Der Preis dafür ist ein deutlich größerer Konzeptsprung: Dein Team braucht Kubernetes-Kompetenz, bevor es Virtualisierung darauf betreibt. Ohne bestehende Cluster-Erfahrung ist das kein Ein-Jahres-Projekt.

Nutanix AHV

Der kommerzielle Weg mit dem geringsten Bruch im Betriebsmodell. Hyperkonvergent, Hypervisor und Storage aus einer Hand, Verwaltung über Prism, definierter Herstellersupport. Du tauschst Lizenzkosten nicht gegen null, sondern gegen einen anderen Vertrag, bekommst dafür aber ein fertiges Betriebskonzept statt Eigenbau.

XCP-ng und Hyper-V

XCP-ng ist der Xen-basierte Weg mit Xen Orchestra als Verwaltung und passt gut zu überschaubaren Umgebungen mit klarem VM-Fokus. Hyper-V lohnt die Prüfung vor allem dort, wo Windows Server samt Lizenzen und Active Directory ohnehin das Rückgrat bilden und Failover Clustering bereits beherrscht wird.

Der Weg dorthin

Belastbar wird die Entscheidung erst mit einer Inventur: Anzahl und Größe der VMs, Storage-Protokolle, VLAN- und Firewall-Abhängigkeiten, Snapshot- und Backup-Ketten, alles was per vCenter-API automatisiert ist, und Appliances von Drittherstellern samt deren Support-Matrix. Danach folgen ein Pilot mit echter Last, ein getesteter Restore und erst dann der Cutover in Wellen.

Qualifizierung als Teil des Projekts

Bei cmt findest du zu jedem dieser Wege den passenden Kurs, vom Proxmox Grundkurs über den Proxmox Aufbaukurs mit Cluster, Ceph und High Availability bis zum Seminar Migration von VMware zu Proxmox. Für den Kubernetes-Pfad gibt es die KubeVirt Schulung sowie DO180 und DO280 für OpenShift. Alle Kurse laufen wahlweise Live-Online oder in Präsenz.

Tutorial

Von der Bestandsaufnahme bis zur ersten migrierten VM

Dieser Teil geht den Weg durch, den ein Plattformwechsel im Betrieb tatsächlich nimmt: Anforderungen messbar machen, Pilotcluster aufbauen, Gastsysteme vorbereiten, migrieren, absichern. Die Beispiele nutzen Proxmox VE als Ziel, weil dort die meisten Projekte landen. Der Ablauf gilt genauso für RHEL mit KVM, nur die Befehle heißen anders.

01

Schritt 1: Bestand aufnehmen und Kriterien festlegen

Vor jedem Produktvergleich steht die Frage, was die eigene Landschaft überhaupt braucht. Diese Zahlen holst du dir direkt aus dem vCenter, nicht aus der Erinnerung.

Inventar aus dem vCenter ziehen
export GOVC_URL='https://vcenter.intern.example/sdk'
export GOVC_USERNAME='ro-user@vsphere.local'
export GOVC_INSECURE=1

govc find / -type m | wc -l                 # Anzahl VMs
govc ls /DC/vm
govc vm.info app01
govc device.info -vm app01                  # Controller, Netzkarten, Platten
govc datastore.info                         # Belegung je Datastore

Interessant sind vier Werte je VM: Firmware, also BIOS oder UEFI, der Plattencontroller, der Netzadaptertyp und ob noch Snapshots offen sind. Genau diese vier bestimmen später den Migrationsaufwand.

Sechs Kriterien, die die Plattformwahl entscheiden

KriteriumWoran du es misstWo es die Auswahl kippt
SpeicherVorhandenes SAN, benötigte IOPS, Bedarf an gleichzeitigem ZugriffWer Ceph nicht selbst betreiben will, braucht ein SAN mit LVM oder NFS als Unterbau
HochverfügbarkeitFencing, Quorum, akzeptierte Ausfallzeit je DienstZwei-Knoten-Aufbauten brauchen zwingend ein QDevice als dritte Stimme
SicherungUnterstützt eure Backupsoftware die Zielplattform ohne Agent?Fehlende Plattformunterstützung erzwingt entweder Produktwechsel oder Agentenbetrieb
ZertifizierungHerstellervorgaben für ERP, Datenbanken, BranchensoftwareHarte Supportmatrizen führen zu einer Plattform mit Herstellerfreigabe, etwa RHEL mit KVM, OpenShift Virtualization oder Nutanix AHV
BetriebsmodellWer betreibt, wer hat Rufbereitschaft, welches Können ist da?Kubernetes-basierte Virtualisierung ohne laufenden Kubernetes-Betrieb ist ein Projektrisiko
NetzVLAN-Konzept, verteilte Switches, MikrosegmentierungSDN-Funktionen lassen sich nicht eins zu eins übertragen und brauchen ein eigenes Konzept
02

Schritt 2: Pilotcluster aufbauen und belasten

Der Pilot ist kein Proof of Concept auf einem Laptop, sondern der spätere Produktivcluster im Kleinen. Was du hier falsch auslegst, schleppst du mit.

Cluster prüfen und Quorum absichern
pvecm status
pvecm nodes
grep -A 6 'totem' /etc/pve/corosync.conf     # welche Links nutzt Corosync?

# Zwei-Knoten-Cluster: dritte Stimme ohne dritten Server
# auf dem externen Host: apt install -y corosync-qnetd
apt install -y corosync-qdevice              # auf allen Cluster-Nodes
pvecm qdevice setup 10.10.0.9

# Speicher prüfen, bevor VMs darauf landen
pvesm status

Corosync braucht niedrige Latenz, keine Bandbreite. Trage einen zweiten Link als Ring nach, damit ein einzelner Switchausfall nicht sofort das Quorum kostet.

Vier Entscheidungen im Pilot

  • Beim Speicher entscheidest du früh: verteiltes Ceph mit mindestens drei Knoten und eigenem, schnellem Netz, oder klassisches SAN mit LVM. Beides funktioniert, aber der Betriebsaufwand ist ein völlig anderer.
  • Netzwerk zuerst, VMs später. Bridges, VLANs und Bonding gehören auf allen Knoten identisch konfiguriert, sonst scheitert die Livemigration ausgerechnet im Ernstfall.
  • Sicherung und Rückspielen gehören in den Pilot, nicht in die Betriebsphase. Ein Cluster ohne getesteten Restore ist nicht produktionsreif.
  • Ein Knoten wird im Pilot absichtlich hart abgeschaltet. Was dann passiert, ist die Antwort auf alle Fragen zur Hochverfügbarkeit.
03

Schritt 3: Gäste vorbereiten und in Wellen migrieren

Der eigentliche Umzug ist der kleinste Teil des Projekts. Entscheidend ist, dass die Gastsysteme vorbereitet sind, solange sie noch unter VMware laufen.

Vier Punkte, die vor dem ersten Kopiervorgang erledigt sind

  • VMware-Snapshots konsolidieren. Offene Snapshot-Ketten verlangsamen den Import erheblich oder blähen den Export auf.
  • Firmware notieren. Ein UEFI-Gast braucht auf der Zielseite eine EFI-Disk, sonst bootet er nicht.
  • Treiber vorher einspielen. Linux-Gäste brauchen virtio in der initramfs, Windows-Gäste die virtio-win-Treiber, bevor sie umziehen.
  • Netzkonfiguration an die MAC-Adresse binden. Der Schnittstellenname ändert sich mit dem Plattformwechsel, eine statische IP am alten Namen ist danach weg.

Wie die Gastvorbereitung, der ESXi-Import-Assistent, der Weg über OVF oder virt-v2v und die Reparatur einer Windows-VM mit INACCESSIBLE_BOOT_DEVICE im Einzelnen aussehen, zeigt der Migrationsablauf von VMware zu Proxmox VE Schritt für Schritt. Führt dein Weg zu KubeVirt, läuft die Vorbereitung gleich, nur der Import über CDI ist anders, siehe VMs auf Kubernetes mit KubeVirt.

04

Schritt 4: Betrieb absichern, bevor die alte Umgebung abgeschaltet wird

Die migrierte VM läuft, das Projekt ist damit nicht fertig. Erst Sicherung, Hochverfügbarkeit und ein definierter Rückfallweg machen daraus einen Betriebszustand.

Sicherung einrichten und Rückweg testen
vzdump 120 --storage local --mode snapshot --compress zstd
proxmox-backup-client list --repository backup@pbs@pbs01.intern.example:tank

# Restore in eine neue VMID, ohne das Original anzufassen
qmrestore /var/lib/vz/dump/vzdump-qemu-120-*.vma.zst 999 --storage local-lvm
qm start 999

Ein Restore in eine freie VMID ist der einzige Test, der zählt. Er läuft ohne Risiko für das Original und beweist, dass Sicherung, Speicher und Netzkonfiguration zusammenpassen.

Abnahmekriterien für den Produktivbetrieb

  • Alte VM mindestens ein Wartungsfenster lang ausgeschaltet aufhebenDas ist der billigste Rückfallweg überhaupt. Wer sofort löscht, tauscht ein paar Gigabyte gegen ein Risiko.
  • Hochverfügbarkeitsgruppen und Fencing testen, nicht nur konfigurierenFencing, das im Ernstfall nicht auslöst, führt zu doppelt laufenden VMs auf gemeinsamem Speicher. Der Datenverlust daraus ist nicht reparabel.
  • Überwachung auf die neue Plattform umstellenAlte Prüfungen laufen sonst gegen Objekte, die es nicht mehr gibt, und melden grün, weil sie nichts finden.
  • Livemigration zwischen allen Knoten einmal durchspielenDas deckt Unterschiede in CPU-Flags, Bridgenamen und Speicherzugriff auf, und zwar bevor du die Migration im Notfall brauchst.
  • Betriebsdokumentation und Berechtigungen nachziehenNeue Plattform bedeutet neue Rollen, neue Anmeldung, neue Notfallzugänge. Ohne das ist der Cluster technisch fertig und organisatorisch nicht übernommen.
Passende Kurse

Kurse zu VMware-Alternativen bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Du buchst sie in Präsenz oder Live-Online, auf Wunsch kommen sie auch als Inhouse-Schulung zu deinem Team.

Migration von VMware zu Proxmox 3 Tage Präsenz nächster Termin 09.12.2026 Zum Kurs Proxmox Grundkurs: KVM, LXC, Storage und Backup 3 Tage Präsenz nächster Termin 07.12.2026 Zum Kurs Proxmox Aufbaukurs: Cluster, Ceph & High Availability 2 Tage Präsenz nächster Termin 14.01.2027 Zum Kurs KubeVirt Schulung: Kubernetes-Virtualisierung 3 Tage Präsenz nächster Termin 14.12.2026 Zum Kurs DO180 Red Hat OpenShift Administration I: Operating a Production Cluster 4 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs Nutanix Enterprise Cloud Administration (ECA) 7.5 (EDU-C-ADM75-NTC) 4 Tage Präsenz nächster Termin 16.11.2026 Garantietermin Zum Kurs Hyper-V und System Center VMM - Alles für Administratoren 3 Tage Präsenz nächster Termin 16.11.2026 Garantietermin Zum Kurs

Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle Linux-Schulungen mit Terminen.

Unverbindlich beraten lassen Alle Proxmox-Kurse ansehen
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest LPI Essentials Quiz Teste dein Wissen zu Linux-Grundlagen mit unserem LPI Essentials Quiz. Finde heraus, welche Schulungen zu dir passen. Quiz starten Wissenstest LPIC-1 Quiz Teste dein Wissen für die LPIC-1 Prüfungen 101 und 102: Shell, Prozesse, Dateisysteme, Netzwerk und Sicherheit. Quiz starten
Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
Gut zu wissen

Häufige Fragen zu VMware-Alternativen

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

Frag uns direkt
Ist Proxmox VE ein vollwertiger vSphere-Ersatz?
Für klassische VM-Landschaften ja, wenn du Cluster, Storage und Backup sauber planst. Proxmox VE bringt Live-Migration, Hochverfügbarkeit über Corosync-Quorum, Ceph als verteilten Storage und mit dem Proxmox Backup Server eine eigene Sicherungslösung mit. Einen dynamischen Lastausgleich ähnlich DRS gibt es erst seit Proxmox VE 9.2 und nur für HA-verwaltete Gäste, und das über Jahre gewachsene Ökosystem an zertifizierten Drittprodukten ist deutlich kleiner. Prüfe deshalb vor der Entscheidung die Support-Matrix deiner Backup- und Monitoring-Werkzeuge.
Wann lohnt sich KubeVirt statt eines klassischen Hypervisors?
KubeVirt lohnt sich, wenn du Kubernetes bereits produktiv betreibst und deine Anwendungen ohnehin in Richtung Container wandern. Dann laufen VMs und Container unter derselben Control Plane, mit einheitlichem RBAC, GitOps und Monitoring. Wenn du dagegen heute ausschließlich VMs betreibst und niemand im Team Cluster-Erfahrung hat, baust du dir mit KubeVirt zwei Lernkurven gleichzeitig auf. In dem Fall ist ein klassischer Hypervisor der ruhigere Weg.
Wie lange dauert eine Migration von VMware weg?
Das hängt fast vollständig von der Anzahl der VMs, den Storage-Abhängigkeiten und den Wartungsfenstern ab, nicht vom Werkzeug. Der eigentliche VM-Transfer über den ESXi-Import-Assistenten oder über OVF ist der schnellste Teil. Zeit fressen die Inventur, der Umbau von Netzwerk und Storage, die Umstellung des Backups, das Entfernen der VMware Tools zugunsten der neuen Gasttreiber und das Nachziehen aller Skripte, die bisher gegen die vCenter-API liefen. Plane in Wellen mit klar definierten Rückwegen statt eines Stichtags für alles.
Kann ich meine bestehenden VMs einfach übernehmen?
In der Regel ja, denn die virtuelle Hardware wird beim Import umgestellt und das Gastsystem bleibt bestehen. Achte auf drei Punkte: Bei Linux-Gästen muss die initramfs die virtio-Treiber enthalten, bei Windows-Gästen brauchst du die virtio-Treiber vor dem Umzug, und Geräte, die an eine bestimmte Hardware oder an einen Dongle gebunden sind, brauchen eine eigene Lösung. Auch Lizenzen von Drittherstellern, die an Hardware-Merkmale gekoppelt sind, solltest du vorher prüfen.
Was, wenn wir bei VMware bleiben wollen?
Das ist eine legitime Entscheidung, besonders bei tiefer Integration in NSX, vSAN oder zertifizierte Fachanwendungen. Wichtig ist, dass die Entscheidung auf einer gerechneten Grundlage steht: Stelle die Verlängerungskosten den vollständigen Migrationskosten inklusive Personalaufwand und Risiko gegenüber. Selbst wenn du bleibst, lohnt sich der Aufbau von Know-how zu einer zweiten Plattform, weil er deine Verhandlungsposition und deine Handlungsfähigkeit verbessert.

Quellen

Zuletzt geprüft am 05. Oktober 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Virtualisierung & Proxmox Von VMware zu Proxmox VE migrieren: Ablauf und Fallstricke Weiterlesen Virtualisierung & Proxmox Proxmox-Cluster aufbauen: Quorum, Corosync-Netz und Ceph Weiterlesen Container & Kubernetes VMs auf Kubernetes betreiben: wann KubeVirt trägt Weiterlesen Virtualisierung & Proxmox Ceph einrichten: OSDs, MONs, CRUSH-Map und Placement Groups Weiterlesen

Passt thematisch dazu

Wenn hinter dem Wechsel vor allem der Wunsch steckt, nicht wieder von einem Hersteller abhängig zu sein, hilft die nüchterne Rechnung für den Parallelbetrieb bei zwei Anbietern .

Bevor du den KubeVirt-Weg wählst, lohnt die Entscheidungshilfe, ob Kubernetes für euch überhaupt trägt , denn ohne produktiven Cluster wird aus der Virtualisierungsfrage eine Plattformfrage.

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

Plattform gewählt, jetzt das Team dahinter aufbauen

Wenn du weißt, wohin die Reise geht, bringen wir dein Team auf den Stand. Zu Proxmox VE bieten wir Grund- und Aufbaukurs sowie ein eigenes Seminar zur Migration von VMware zu Proxmox, für den Kubernetes-Weg die KubeVirt Schulung und die OpenShift-Kurse DO180 und DO280. Wer zu Nutanix oder Hyper-V wechselt, findet die Kurse Nutanix Enterprise Cloud Administration und Hyper-V und System Center VMM. Bist du bei der Auswahl noch unentschieden, sprich uns an: Wir schauen uns deine Ausgangslage gemeinsam an und sagen dir ehrlich, welcher Weg zu deinem Team passt.

Beratung anfragen 0800 71 20000