Virtualisierung & Proxmox

VMware-Alternativen: So findest du die Plattform, die zu deiner IT passt

Für klassische VM-Landschaften ist Proxmox VE heute der pragmatischste Ausweg aus der Broadcom-Preispolitik. Wer SAP fährt oder harte Herstellerzertifizierungen braucht, landet bei RHEL mit KVM. Alles andere entscheidet sich an Storage, Backup und dem vorhandenen Know-how im Team.

5 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. 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

01 Workload-Profil: reine VMs oder VMs plus Container
02 Storage: SAN, lokal mit ZFS oder verteilt mit Ceph
03 Betriebsmodell: Herstellersupport oder Eigenbetrieb
04 Skills im Team und realistische Einarbeitungszeit
05 Werkzeugkette: Backup, Monitoring, Automatisierung
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.

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

Kriterium	Woran du es misst	Wo es die Auswahl kippt
Speicher	Vorhandenes SAN, benötigte IOPS, Bedarf an gleichzeitigem Zugriff	Wer Ceph nicht selbst betreiben will, braucht ein SAN mit LVM oder NFS als Unterbau
Hochverfügbarkeit	Fencing, Quorum, akzeptierte Ausfallzeit je Dienst	Zwei-Knoten-Aufbauten brauchen zwingend ein QDevice als dritte Stimme
Sicherung	Unterstützt eure Backupsoftware die Zielplattform ohne Agent?	Fehlende Plattformunterstützung erzwingt entweder Produktwechsel oder Agentenbetrieb
Zertifizierung	Herstellervorgaben für ERP, Datenbanken, Branchensoftware	Harte Supportmatrizen führen zu RHEL mit KVM statt zu einer Community-Plattform
Betriebsmodell	Wer betreibt, wer hat Rufbereitschaft, welches Können ist da?	Kubernetes-basierte Virtualisierung ohne laufenden Kubernetes-Betrieb ist ein Projektrisiko
Netz	VLAN-Konzept, verteilte Switches, Mikrosegmentierung	SDN-Funktionen lassen sich nicht eins zu eins übertragen und brauchen ein eigenes Konzept

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
apt install -y corosync-qdevice
pvecm qdevice setup 10.10.0.9

# Speicher pruefen, 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.

Schritt 3: Gastsysteme vorbereiten, noch unter VMware

Die meisten misslungenen Migrationen scheitern nicht am Kopiervorgang, sondern daran, dass der Gast das neue Blech nicht kennt. Diese Arbeit passiert vorher, im laufenden Betrieb.

Linux-Gast vorbereiten

# Sind die virtio-Treiber im initramfs?
lsinitrd | grep -E 'virtio_(blk|scsi|net)' || echo 'virtio fehlt im initramfs'

sudo dnf remove -y open-vm-tools && sudo dnf install -y qemu-guest-agent
# Debian/Ubuntu: sudo apt purge open-vm-tools && sudo apt install qemu-guest-agent

sudo dracut -fv --regenerate-all             # RHEL-Familie
sudo update-initramfs -u -k all              # Debian/Ubuntu

nmcli -f NAME,DEVICE,TYPE connection show
lsblk -o NAME,UUID,MOUNTPOINT

Der lsblk-Blick dient der Kontrolle, ob /etc/fstab auf UUIDs zeigt und nicht auf Gerätenamen. Alles, was auf /dev/sdX verweist, ist ein Kandidat für einen Bootfehler nach dem Plattformwechsel.

Vor dem ersten Kopiervorgang

Alle VMware-Snapshots vorher konsolidierenOffene Snapshot-Ketten werden beim Export entweder nicht mitgenommen oder blähen ihn massiv auf. Beides bemerkst du erst nach Stunden Kopierzeit.
Firmware notieren: BIOS oder UEFIEin UEFI-Gast braucht auf der Zielseite eine eigene EFI-Platte. Wird sie vergessen, bootet die migrierte VM schlicht nicht.
Bei Windows die virtio-Treiber vor der Migration installierenOhne passenden Speichertreiber startet Windows auf dem neuen Controller nicht und bleibt mit einem Bootfehler stehen. Nach der Migration ist das deutlich mühsamer zu reparieren.
Lizenzbindungen an MAC-Adresse oder UUID klärenManche Software bindet ihre Lizenz an Hardwaremerkmale, die sich beim Wechsel ändern. Das kostet sonst am Montagmorgen einen Supportfall beim Hersteller.
DHCP-Reservierungen und Monitoring auf neue Merkmale anpassenSonst ist die VM zwar migriert, aber im Netz und in der Überwachung nicht mehr dieselbe.

Schritt 4: Migrieren und sofort gegenprüfen

Für den eigentlichen Umzug gibt es drei Wege. Welchen du nimmst, hängt davon ab, ob du direkt an das vCenter kommst und wie viel Nacharbeit du dem Werkzeug überlassen willst.

Drei Wege in den neuen Cluster

# Weg A: Proxmox-Importassistent, Storage vom Typ ESXi anlegen und VM auswaehlen

# Weg B: OVF-Export uebernehmen
qm importovf 120 /mnt/export/app01.ovf local-lvm

# Weg C: Nur die Platte uebernehmen und die VM selbst zusammenbauen
qm importdisk 120 /mnt/export/app01-flat.vmdk local-lvm
qm set 120 --scsihw virtio-scsi-single --scsi0 local-lvm:vm-120-disk-0 \
       --boot order=scsi0 --agent enabled=1 --ostype l26

Weg C gibt dir die volle Kontrolle über Controller, Bootreihenfolge und Gerätetypen. Das ist genau dann Gold wert, wenn eine VM nach dem Import nicht startet und du wissen musst, woran es liegt.

Alternativ mit virt-v2v konvertieren

sudo dnf install -y virt-v2v virtio-win
virt-v2v -i ova /mnt/export/app01.ova -o libvirt -os default

virsh list --all
virsh dumpxml app01 | grep -E 'type=|driver'

virt-v2v passt die Bootkonfiguration an und spielt bei Windows-Gästen die virtio-Treiber ein. Dafür muss das Paket virtio-win auf dem Konvertierungshost liegen, sonst konvertiert das Werkzeug zwar, der Gast startet aber nicht.

Erste Kontrolle nach dem Start

qm start 120
# Konsole im Webinterface oeffnen, nicht auf SSH warten

# Im Gast
ip -br a
systemctl --failed
findmnt --verify
journalctl -b -p err
systemctl status qemu-guest-agent

findmnt --verify prüft /etc/fstab gegen die tatsächlich vorhandenen Geräte. Das fängt die Fälle ab, in denen die VM zwar hochkommt, aber ein Datenträger fehlt und der Dienst darauf still nichts findet.

Schritt 5: 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. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Migration von VMware zu Proxmox 3 Tage Präsenz oder Live-Online nächster Termin 21.09.2026 Garantietermin Zum Kurs Proxmox Grundkurs: KVM, LXC, Storage und Backup 3 Tage Präsenz nächster Termin 21.09.2026 Garantietermin Zum Kurs Proxmox Aufbaukurs: Cluster, Ceph & High Availability 2 Tage Präsenz nächster Termin 10.09.2026 Zum Kurs KubeVirt Schulung: Kubernetes-Virtualisierung 3 Tage Präsenz nächster Termin 14.09.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

Unverbindlich beraten lassen Alle Proxmox-Kurse ansehen

Gut zu wissen

Häufige Fragen zu VMware-Alternativen

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

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. Was du im direkten Vergleich nicht bekommst, sind Funktionen wie DRS-artiges automatisches Lastausgleichen im gleichen Reifegrad sowie das über Jahre gewachsene Ökosystem an zertifizierten Drittprodukten. 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 müssen die Initramfs die neuen 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.

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!

Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“

“

Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.

Rückmeldung aus dem Kurs „SUSE Linux Enterprise 15 High Availability Deployment – HAE311v15“

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

Weiterbildung & Beratung

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

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

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