Proxmox vs. VMware | Proxmox vs. VMware
Ein Gastbeitrag der Pierro & Mai - IT for Business GmbH aus Ettlingen

Die strategische Neuausrichtung von Broadcom verändert die Rechenzentrums-Landschaft im Mittelstand grundlegend. Weil sich der Hersteller seit der Übernahme im November 2023 auf die weltweit größten Bestandskunden konzentriert, fallen mittelständische IT-Umgebungen bei Produktzuschnitt und Preisstruktur durch das Raster. Der Wegfall klassischer Kauflizenzen zugunsten von Abonnement-Modellen zwingt IT-Verantwortliche in eine neue Kostenrealität: Wo früher eine einmalige Investition plus Wartung stand, steht heute eine jährlich wiederkehrende Rechnung, deren Höhe der Anbieter diktiert.
Wer die Budgetplanung für die kommenden Jahre aufschiebt, geht ein betriebliches Risiko ein. Auslaufende Support-Verträge lassen sich nur verlängern, indem die Umgebung auf die neuen Kern-Metriken und Abo-Bundles umgestellt wird. Der Support für vSphere 7 ist im Oktober 2025 ausgelaufen, der 8er-Zweig folgt im Oktober 2027. Ein Hypervisor ohne Sicherheitsupdates ist in ISO-27001- oder NIS2-regulierten Umgebungen kein Betriebszustand, sondern ein Audit-Finding. Genau deshalb steht die Frage im Raum, ob Proxmox Virtual Environment (VE) die vSphere-Plattform im Mittelstand ablösen kann. Die Antwort erfordert einen Blick auf Lizenzmodell, Architektur, Storage, Netzwerk, Backup und den Migrationspfad.
Lizenzbeben: Abo-Zwang, Core-Metrik und wechselnde Spielregeln
Broadcom hat das VMware-Portfolio seit 2024 radikal eingedampft. Aus über 160 Produkt-Bundles wurden wenige Abo-Editionen: vSphere Standard (VVS), vSphere Enterprise Plus (VVP), vSphere Foundation (VVF) und als Vollpaket die VMware Cloud Foundation (VCF) mit vSAN, NSX, HCX und der VCF-Operations-Suite. Die auf Kleinstumgebungen zugeschnittene Essentials Plus Edition wurde im November 2024 eingestellt. Neue Lizenzen gibt es ausschließlich als Subscription mit Laufzeiten von einem, drei oder fünf Jahren. Den kostenlosen ESXi-Hypervisor strich Broadcom Anfang 2024 und führte ihn mit Version 8.0 Update 3e im April 2025 in aller Stille wieder ein. Für den Unternehmenseinsatz spielt er wegen fehlendem Support und fehlender Verwaltung trotzdem keine Rolle.
Die Abrechnung erfolgt pro CPU-Kern, wobei jede physische CPU mit mindestens 16 Kernen lizenziert werden muss. Da dieses Minimum unabhängig von der realen Hardware gilt, zahlst Du bei kleineren Prozessoren für Kerne, die physisch gar nicht existieren. Ein Rechenbeispiel: Ein Cluster aus drei Hosts mit jeweils zwei Prozessoren à 8 Kernen besitzt 48 physische Kerne, lizenziert werden müssen 96. Die Hälfte der bezahlten Kapazität ist Luft.
Wie volatil die Spielregeln sind, zeigte das Frühjahr 2025: Zum 10. April kündigte Broadcom über die Distribution eine Mindestbestellmenge von 72 Cores pro Order an, kassierte die Regel nach massivem Widerstand aus dem Channel aber wieder ein. Aktuell (Stand Mitte 2026) gilt wieder das 16-Core-Minimum pro CPU ohne zusätzliche Mindestbestellmenge. Geblieben ist die Reinstatement Fee: Wer sein Abonnement nicht zum Vertragsjahrestag verlängert, zahlt einen Strafaufschlag von 20 Prozent auf den Erstjahrespreis, rückwirkend und ohne Karenzfrist. Für die Budgetplanung ist diese Volatilität das eigentliche Warnsignal, denn wer nicht einmal 18 Monate im Voraus weiß, zu welchen Konditionen er verlängern darf, kann weder Budget noch Architektur verlässlich planen.
Bei den Preisen sind Listenwerte nur eine Orientierung, weil Broadcom stark rabattiert und regionale Preisbücher voneinander abweichen. Als Größenordnung für Mitte 2026: vSphere Standard liegt in der DACH-Distribution bei rund 70 bis 80 Euro pro Core und Jahr, VVF je nach Preisbuch zwischen etwa 135 und 190 US-Dollar, VCF bei rund 350 US-Dollar Liste pro Core und Jahr. Für Mehrjahresverträge mit vollem Bestands-Commit sind Nachlässe von 25 bis 45 Prozent auf die Liste dokumentiert. Wichtig für die Editionswahl: vSphere 9 erhalten nur VVF- und VCF-Kunden. Die Standard Edition bleibt auf dem 8er-Zweig, dessen genereller Support im Oktober 2027 endet. Wer heute VVS verlängert, kauft damit ein festes Ablaufdatum.
Der Markt reagiert deutlich. Über 90 Prozent der 10.000 größten Broadcom-Kunden sind auf VCF gewechselt, häufig mit mehr Modulen, als sie einsetzen. Der europäische Cloud-Verband CISPE dokumentiert Preissteigerungen von bis zu 1.500 Prozent bei Vertragsverlängerungen, der IT-Anwenderverband VOICE hat Beschwerde bei der EU-Kommission eingelegt und der Distributor Ingram Micro hat die Geschäftsbeziehung zu Broadcom beendet. Gartner erwartet, dass 70 Prozent der VMware-Enterprise-Kunden bis 2028 mindestens die Hälfte ihrer Workloads migrieren. Diese kaufmännische Verschiebung erfordert eine Überprüfung der Virtualisierungs-Strategie, bevor das nächste Renewal auf dem Tisch liegt.
Architektur: Monolithisches vCenter gegen dezentralen Multi-Master
Die Entscheidung zwischen VMware vSphere und Proxmox VE ist zuerst eine Frage der Systemarchitektur. VMware setzt auf den proprietären ESXi-Hypervisor, dessen Verwaltung in der vCenter Server Appliance (VCSA) gebündelt ist. In der Praxis führt die Standard-Installation der VCSA häufig zu Fehldimensionierung, weil Administratoren die großzügigen Sizing-Templates ungeprüft übernehmen. Auf kleineren Clustern blockiert das Management dadurch zweistellige Gigabyte-Mengen an Arbeitsspeicher, die den produktiven virtuellen Maschinen fehlen.
Fällt das vCenter aus, laufen die bestehenden VMs auf den ESXi-Hosts zwar ungestört weiter. Weil aber die gesamte Steuerungsebene an der Appliance hängt, sind administrative Eingriffe, DRS-Lastverteilung und API-gesteuerte Prozesse so lange blockiert, bis das Management wieder vollständig gestartet ist. Backup-Jobs, die über die vSphere-APIs laufen, stehen in dieser Zeit ebenfalls still.
Proxmox VE verfolgt mit seiner Basis auf Debian GNU/Linux (aktuell Debian 13 in der Version-9-Reihe, jüngstes Release ist 9.2 vom Mai 2026) einen dezentralen Ansatz. Der KVM-Hypervisor für vollständige Virtualisierung und die LXC-Technologie für schlanke Container sind direkt mit einem integrierten Web-Interface verknüpft. Jeder Knoten im Cluster agiert als vollwertiger Master: Die Cluster-Kommunikation läuft über das Corosync-Protokoll, die Konfiguration liegt im replizierten Cluster-Dateisystem pmxcfs, wodurch jeder Server permanent den Gesamtzustand der Umgebung kennt. Ein dedizierter Management-Server entfällt. Fällt ein Knoten aus, meldest Du Dich auf der Weboberfläche eines beliebigen verbleibenden Knotens an und behältst die volle Kontrolle. Zu beachten ist das Quorum-Prinzip: Ein Cluster braucht die Mehrheit seiner Stimmen, weshalb Zwei-Knoten-Setups ein externes QDevice als dritte Stimme benötigen, damit der überlebende Knoten nach einem Ausfall handlungsfähig bleibt.
Für Umgebungen mit mehreren Standorten schiebt Proxmox mit dem Datacenter Manager eine optionale Verwaltungsschicht über mehrere Cluster. Das Werkzeug befindet sich in aktiver Entwicklung und ist funktional noch kein vCenter-Ersatz, der Zugang ist in den Subscription-Stufen Standard und Premium enthalten.
Die Bare-Metal-Installation von Proxmox VE ist per ISO-Medium in rund zehn Minuten abgeschlossen. Dieser minimale Aufwand verleitet zu dem Trugschluss, das Gesamtsystem sei trivial. Die Grundinstallation macht in professionellen Umgebungen nur einen kleinen Teil der Arbeit aus, denn Proxmox VE wird als offener Werkzeugkasten geliefert: Netzwerktrennung, Cluster-Verbindungen und Speicher-Anbindungen musst Du selbst konzipieren und implementieren, weil kein Assistent diese Designentscheidungen abnimmt.
| Merkmal | VMware vSphere | Proxmox VE |
| Hypervisor | proprietärer ESXi (VMkernel) | KVM/QEMU auf Debian GNU/Linux |
| Container | Tanzu/VKS als Bundle-Bestandteil | LXC nativ integriert |
| Management | zentrale vCenter Server Appliance | Web-Interface auf jedem Knoten (Multi-Master) |
| Cluster-Kommunikation | vCenter-zentriert | Corosync mit Quorum, Konfiguration in pmxcfs |
| Ausfall des Managements | VMs laufen, Verwaltung, DRS und API blockiert | jeder verbleibende Knoten bleibt voll administrierbar |
| Skalierung je Host | branchenübliche Enterprise-Grenzen | 8.192 logische CPUs, bis 128 TiB RAM (Herstellerangabe) |
| API und Automatisierung | REST, SDKs, PowerCLI | REST-API, CLI (pvesh, qm, pct), Terraform und Ansible über Community-Provider |
| Quellcode | geschlossen | offen (AGPLv3), auditierbar |
Speicher: vSAN-Zertifizierung gegen Ceph-Architektur
Die Bereitstellung von hochverfügbarem, gemeinsamem Speicher trennt die Plattformen technisch am deutlichsten. VMware löst die Speicher-Virtualisierung über vSAN, das direkt in den VMkernel eingebettet ist. Dieses System verlangt Komponenten aus der offiziellen Hardware-Kompatibilitätsliste (HCL) beziehungsweise zertifizierte ReadyNodes. Lizenzseitig ist vSAN heute an die Bundles gekoppelt: VVF enthält ein Kontingent von 250 GiB pro lizenziertem Core, VCF ein TiB pro Core, zusätzlicher Bedarf wird per Add-on nachlizenziert. Die Speicherkosten wandern damit in dieselbe Core-Metrik wie der Hypervisor.
Proxmox VE setzt für hyperkonvergente Infrastrukturen auf das verteilte Speichersystem Ceph, das ohne Zusatzlizenz direkt aus der Weboberfläche installiert und verwaltet wird. Ceph speichert Daten als Objekte und verteilt sie über Object Storage Daemons (OSDs) auf die Datenträger des gesamten Clusters. Die Platzierung berechnet die CRUSH-Map mathematisch, wodurch ein zentraler Metadaten-Server entfällt, der unter Last zum Flaschenhals werden könnte. Monitor- und Manager-Dienste sichern den Cluster-Konsens ab.
Die Hardware-Anforderungen von Ceph sind strikt, auch wenn keine HCL existiert. Weil die synchrone Replikation jeden Schreibbefehl erst quittiert, wenn die Kopien geschrieben sind, brauchen die Datenträger einen integrierten Stromausfallschutz (Power Loss Protection). Consumer-SSDs ohne PLP verzögern die Quittierung massiv, die Latenz des gesamten Pools bricht ein und der Betrieb wird instabil. Ceph setzt außerdem voraus, dass RAID-Controller umgangen werden: Die Festplatten müssen über einen Host-Bus-Adapter im IT-Modus direkt an das Betriebssystem durchgereicht werden, damit die Selbstheilungs-Mechanismen von Ceph oder ZFS auf die physischen Geräte zugreifen können. Für das Replikationsnetz sind dedizierte, redundante Schnittstellen mit 10 bis 25 Gigabit Pflicht, physisch getrennt vom Nutzdatenverkehr. Drei Knoten sind das Minimum, ab vier Knoten hat der Cluster genug Reserve, um ausgefallene OSDs selbstständig neu zu verteilen.
Für kleinere Setups ohne Ceph-Ambitionen bietet Proxmox eine pragmatische Alternative: lokales ZFS mit asynchroner Storage-Replikation zwischen den Knoten. Das ersetzt kein Shared Storage, hält aber die Wiederanlaufzeiten kurz und die Hardware-Anforderungen niedrig. Für klassische SAN-Kunden relevant: Seit der Version-9-Reihe unterstützt Proxmox VE Snapshots auch auf Shared-LVM-Volumes über Fibre Channel oder iSCSI als Technology Preview, womit eine der letzten funktionalen Lücken gegenüber VMFS schrumpft.
| Kriterium | VMware vSAN | Ceph in Proxmox VE |
| Integration | im VMkernel, Verwaltung über vCenter | nativ in PVE, Verwaltung über Weboberfläche und CLI |
| Lizenzierung | Kontingent pro Core (VVF 250 GiB, VCF 1 TiB), Add-ons darüber | keine Zusatzlizenz, Open Source |
| Hardware | HCL und ReadyNodes zwingend | frei wählbar, aber Enterprise-SSDs mit PLP und HBA im IT-Modus nötig |
| Datenverteilung | Komponenten gemäß Storage Policy | Objekte über OSDs, Platzierung per CRUSH-Map ohne zentralen Metadaten-Server |
| Mindestgröße | 2 Knoten plus Witness oder 3 Knoten | 3 Knoten, sinnvoll ab 4 Knoten für Self-Healing-Reserve |
| Netzwerk | 10 GbE empfohlen bis gefordert | dedizierte, redundante 10 bis 25 GbE für das Ceph-Netz |
| Kapazitätslogik | Dedup und Kompression je Edition | Replikation (Faktor 3) oder Erasure Coding |
| Alternative für kleine Cluster | keine im Bundle | ZFS mit asynchroner Replikation |
Netzwerk: NSX gegen integriertes SDN
Die Segmentierung des Netzwerkverkehrs erfolgt bei VMware über NSX. Die Lösung bietet ausgereifte Mikrosegmentierung, erhöht aber die Komplexität der Infrastruktur, verlangt spezialisiertes Fachwissen und ist als eigenständiges Produkt nicht mehr erhältlich: NSX steckt im VCF-Bundle, weshalb Du für Mikrosegmentierung das teuerste Paket lizenzierst, selbst wenn Du den Rest der Suite nicht brauchst.
Proxmox VE bringt in den aktuellen Versionen ein vollständig integriertes Software-Defined Network mit. Damit lassen sich VLANs, VXLAN-Overlays und EVPN-Zonen mit BGP-Routing über die zentrale Weboberfläche definieren und clusterweit ausrollen, inklusive IPAM-Anbindung für die Adressverwaltung. Ergänzend arbeitet eine integrierte Firewall auf drei Ebenen (Datacenter, Host, einzelne VM), wodurch sich Mikrosegmentierung ohne Zusatzprodukt abbilden lässt. Das spart Investitionen in externe Netzwerk-Controller, verlagert die Verantwortung aber komplett auf das interne IT-Team, das die zugrundeliegenden Linux-Netzwerkstrukturen fehlerfrei konfigurieren muss. Wer BGP im Hypervisor spricht, braucht Routing-Wissen im Team, nicht nur im Netzwerk-Schrank.
Funktionsvergleich auf einen Blick
Funktional decken sich die Kernanforderungen des Mittelstands weitgehend, die Unterschiede stecken in der Tiefe der Automatisierung und im Ökosystem:
| Funktion | VMware vSphere | Proxmox VE |
| Live-Migration | vMotion, inklusive Storage vMotion | ja, inklusive Storage-Live-Migration |
| Automatische Lastverteilung | DRS mit laufendem Rebalancing (ab VVF/Enterprise Plus) | CRS-Scheduler mit Affinitätsregeln, platziert bei Start und Failover, kein permanentes Rebalancing |
| Hochverfügbarkeit | ja, vSphere HA | ja, HA-Manager mit Fencing über Quorum und Watchdog |
| Snapshots | ja | ja, seit Version 9 auch auf Shared-LVM als Technology Preview |
| Integriertes Backup | nicht enthalten, Drittanbieter über Storage-APIs | vzdump integriert plus Proxmox Backup Server |
| Container | Tanzu/VKS im Bundle | LXC nativ, parallel zu VMs |
| SDN | NSX, nur in VCF | integriert (VLAN, VXLAN, EVPN mit BGP) |
| Firewall | über NSX oder Drittanbieter | integriert auf Datacenter-, Host- und VM-Ebene |
| Gast-Betriebssysteme | breite offizielle Zertifizierungsmatrix | Windows, Linux und weitere, ohne formale Zertifizierungsmatrix |
| Lizenzmetrik | Abo pro Core, mindestens 16 je CPU | Software frei (AGPLv3), Support-Subscription pro Socket |
Lizenzmodell und Subscriptions bei Proxmox
Proxmox verfolgt ein konträres Wirtschaftsmodell. Die Software steht unter der AGPLv3 und ist im vollen Funktionsumfang kostenlos nutzbar, ohne Begrenzung von Kernen, VMs oder Cluster-Knoten. Bezahlt wird optional eine Support-Subscription, die pro physisch belegtem CPU-Socket und Jahr abgerechnet wird. Kerne und Arbeitsspeicher spielen für den Preis keine Rolle, wodurch moderne Prozessoren mit 64 oder 96 Kernen die Softwarekosten nicht eskalieren lassen. Genau diese Metrik dreht die Broadcom-Logik um: Je dichter Du konsolidierst, desto günstiger wird Proxmox relativ zur Kernanzahl.
| Stufe | Preis je Socket und Jahr (netto) | Support-Umfang | Reaktionszeit |
| Community | 120 € | kein Herstellersupport, Community-Forum | keine Zusage |
| Basic | 370 € | 3 Tickets pro Jahr | 1 Arbeitstag |
| Standard | 550 € | 10 Tickets pro Jahr, Remote-Support per SSH | 4 Stunden an Werktagen |
| Premium | 1.100 € | unlimitierte Tickets, Remote-Support per SSH, Offline-Aktivierung | 2 Stunden an Werktagen |
Alle Stufen schalten das Enterprise-Repository frei, ab Standard ist der Zugang zum Datacenter Manager enthalten. Innerhalb eines Clusters müssen alle Knoten dieselbe Stufe haben, damit Paketstände und Support-Anspruch konsistent bleiben.
Der Unterschied zwischen den Update-Kanälen entscheidet über die Betriebsstabilität. Proxmox liefert drei Repositories aus: Das Enterprise-Repository enthält die am intensivsten getesteten Pakete und ist der empfohlene Standard für Produktion. Das frei zugängliche No-Subscription-Repository erhält Updates früher und mit geringerer Testtiefe, weshalb es für Test- und Laborumgebungen gedacht ist. Das Test-Repository liefert Pakete direkt aus der Entwicklung. Wer geschäftskritische Systeme dauerhaft am No-Subscription-Kanal betreibt, macht seine Produktion zum Frühwarnsystem für Regressionen zwischen Debian-Basis, Kernel und QEMU-Laufzeit. Für den stabilen Betrieb gehört mindestens die Community-Subscription auf jeden produktiven Knoten, denn 120 Euro pro Socket sind billiger als ein einziger ungeplanter Cluster-Stillstand.
ROI konkret: Die Beispielrechnung
| Modell | Rechnung | Kosten pro Jahr (Größenordnung) |
| vSphere Standard (VVS) | 96 Cores × ca. 75 € | ca. 7.200 € |
| vSphere Foundation (VVF) | 96 Cores × ca. 150 € | ca. 14.400 € |
| VMware Cloud Foundation (VCF) | 96 Cores × ca. 315 € | über 30.000 € |
| Proxmox VE ohne Subscription | Lizenz 0 € | 0 € |
| Proxmox VE Standard | 6 Sockets × 550 € | 3.300 € |
| Proxmox VE Premium | 6 Sockets × 1.100 € | 6.600 € |
Hinzu kommt bei Proxmox optional ein Proxmox Backup Server mit eigener Subscription ab rund 560 Euro pro Jahr und Backup-Server. Selbst die Premium-Stufe inklusive PBS liegt damit unter dem günstigsten VMware-Einstieg, der außerdem weder vSAN noch SDN enthält und auf dem auslaufenden 8er-Zweig festhängt. Ein dokumentiertes Praxisbeispiel aus dem Mittelstand zeigt die Dynamik: Ein Kunde mit drei ESXi-Hosts zahlte 2023 rund 8.000 Euro pro Jahr für vSphere und vSAN, das Renewal 2025 lag bei über 30.000 Euro für dasselbe Setup.
Ehrlich gerechnet ist der ROI trotzdem keine reine Lizenz-Subtraktion. Auf der Sollseite stehen Migrationsdienstleistung oder interne Projekttage, Schulung des Teams (realistisch zwei bis fünf Tage pro Administrator), gegebenenfalls neue Backup-Hardware für den PBS und die Anpassung der Automatisierung. Weil die wiederkehrende Ersparnis bei mittleren Umgebungen im fünfstelligen Bereich pro Jahr liegt, amortisiert sich der Wechsel in typischen Projekten innerhalb von 12 bis 18 Monaten, bei anstehenden VCF-Renewals häufig schon im ersten Betriebsjahr. Danach wirkt die Ersparnis jedes Jahr aufs Neue, während die VMware-Seite mit jeder Verlängerung neu verhandelt werden muss.
Migration in der Praxis: Die Reihenfolge entscheidet
Die technische Umstellung virtueller Maschinen folgt einer festen Reihenfolge, weil Abweichungen direkt in Bluescreens enden. Zuerst entfernst Du die VMware Tools vollständig aus dem Gast-Betriebssystem, denn deren verbleibende Treiber verursachen unter KVM schwere Systemfehler. Bei Windows-VMs installierst Du vor dem Umzug die VirtIO-Treiber, damit das System nach dem Plattformwechsel Disk- und Netzwerkgeräte findet. Anschließend werden die virtuellen Festplatten vom VMDK-Format nach RAW oder QCOW2 konvertiert.
Proxmox nimmt Dir den Konvertierungsschritt in vielen Fällen ab: Seit Version 8.2 verbindet sich ein integrierter Import-Assistent über die API direkt mit ESXi-Hosts oder dem vCenter, listet die VMs auf und importiert sie inklusive Konfigurationsübernahme. Ein Live-Import startet die VM bereits, während die Daten im Hintergrund übertragen werden, was die Downtime pro Maschine auf Minuten drückt. UEFI-Boot, vTPM für Windows 11 und Server 2025 sowie feste MAC-Adressen für lizenzgebundene Anwendungen gehören vor dem Umzug auf die Checkliste, nicht danach.
Organisatorisch bewährt sich die Migration in Wellen: unkritische Systeme zuerst, geschäftskritische in geplanten Wartungsfenstern mit getestetem Rollback. Die alte Umgebung bleibt bis zur Abnahme parallel lauffähig, wodurch der Rückweg jederzeit offen ist. Eine saubere Bestandsaufnahme aller VMs, Storage-Anbindungen und Abhängigkeiten vor Projektstart entscheidet über den Verlauf, denn die technische Konvertierung ist Routine, das Übersehen einer Abhängigkeit nicht.
Ein Posten wird in Kalkulationen gern vergessen: Bestehende Automatisierungs-Skripte auf Basis von VMware PowerCLI sind unter Proxmox unbrauchbar. Sie müssen auf die Proxmox REST-API, auf Werkzeuge wie Terraform (über den Community-Provider) oder auf Ansible umgestellt werden. Wer viel automatisiert hat, plant diesen Umbau als eigenes Teilprojekt ein.
Backup neu denken: PBS und die Veeam-Frage
Das Backup-Konzept ändert sich beim Plattformwechsel mit. Der Proxmox Backup Server (PBS) arbeitet als eigenständige Instanz und beherrscht clientseitige Deduplizierung, inkrementelle Sicherungen auf Blockebene, authentifizierte Verschlüsselung und geplante Verify-Jobs gegen schleichende Datenkorruption. VMs lassen sich per Live-Restore direkt aus dem Backup starten, während die Wiederherstellung im Hintergrund läuft. Für den Ransomware-Schutz replizierst Du die Backup-Datastores über isolierte Sync-Jobs an einen entfernten PBS in einem separaten Brandabschnitt, ergänzt um Tape-Ausgabe oder Objektspeicher-Ziele mit Immutability für die letzte Verteidigungslinie der 3-2-1-Regel.
Die früher berechtigte Sorge, mit Proxmox den etablierten Backup-Hersteller zu verlieren, ist überholt. Veeam unterstützt Proxmox VE seit Backup & Replication 12.2 nativ und agentenlos, in der aktuellen Data Platform v13 deckt das Plug-in die PVE-Versionen 8.2 bis 9.1 ab, inklusive inkrementeller Sicherungen, Immutability und plattformübergreifender Wiederherstellung. Der Restore vorhandener VMware-Backups direkt nach Proxmox VE eröffnet sogar einen zweiten Migrationsweg über die Backup-Ebene. Die Integration erreicht allerdings noch nicht die Tiefe der jahrzehntelang gereiften vSphere-Anbindung: Veeam arbeitet mit Worker-Appliances statt einer nativen Backup-API, was in der Praxis Pflegeaufwand erzeugt, und Funktionen wie CDP fehlen für PVE. Wer heterogen bleibt oder Microsoft-365-Sicherung im selben Haus betreibt, fährt mit Veeam plus PVE trotzdem eine tragfähige Kombination. Reine Proxmox-Umgebungen decken mit dem PBS die Kernanforderungen ohne Zusatzlizenzkosten ab.
Funktionsvergleich auf einen Blick
Funktional decken sich die Kernanforderungen des Mittelstands weitgehend, die Unterschiede stecken in der Tiefe der Automatisierung und im Ökosystem:
| Funktion | VMware vSphere | Proxmox VE |
| Live-Migration | vMotion, inklusive Storage vMotion | ja, inklusive Storage-Live-Migration |
| Automatische Lastverteilung | DRS mit laufendem Rebalancing (ab VVF/Enterprise Plus) | CRS-Scheduler mit Affinitätsregeln, platziert bei Start und Failover, kein permanentes Rebalancing |
| Hochverfügbarkeit | ja, vSphere HA | ja, HA-Manager mit Fencing über Quorum und Watchdog |
| Snapshots | ja | ja, seit Version 9 auch auf Shared-LVM als Technology Preview |
| Integriertes Backup | nicht enthalten, Drittanbieter über Storage-APIs | vzdump integriert plus Proxmox Backup Server |
| Container | Tanzu/VKS im Bundle | LXC nativ, parallel zu VMs |
| SDN | NSX, nur in VCF | integriert (VLAN, VXLAN, EVPN mit BGP) |
| Firewall | über NSX oder Drittanbieter | integriert auf Datacenter-, Host- und VM-Ebene |
| Gast-Betriebssysteme | breite offizielle Zertifizierungsmatrix | Windows, Linux und weitere, ohne formale Zertifizierungsmatrix |
| Lizenzmetrik | Abo pro Core, mindestens 16 je CPU | Software frei (AGPLv3), Support-Subscription pro Socket |
Lizenzmodell und Subscriptions bei Proxmox
Proxmox verfolgt ein konträres Wirtschaftsmodell. Die Software steht unter der AGPLv3 und ist im vollen Funktionsumfang kostenlos nutzbar, ohne Begrenzung von Kernen, VMs oder Cluster-Knoten. Bezahlt wird optional eine Support-Subscription, die pro physisch belegtem CPU-Socket und Jahr abgerechnet wird. Kerne und Arbeitsspeicher spielen für den Preis keine Rolle, wodurch moderne Prozessoren mit 64 oder 96 Kernen die Softwarekosten nicht eskalieren lassen. Genau diese Metrik dreht die Broadcom-Logik um: Je dichter Du konsolidierst, desto günstiger wird Proxmox relativ zur Kernanzahl.
| Stufe | Preis je Socket und Jahr (netto) | Support-Umfang | Reaktionszeit |
| Community | 120 € | kein Herstellersupport, Community-Forum | keine Zusage |
| Basic | 370 € | 3 Tickets pro Jahr | 1 Arbeitstag |
| Standard | 550 € | 10 Tickets pro Jahr, Remote-Support per SSH | 4 Stunden an Werktagen |
| Premium | 1.100 € | unlimitierte Tickets, Remote-Support per SSH, Offline-Aktivierung | 2 Stunden an Werktagen |
Alle Stufen schalten das Enterprise-Repository frei, ab Standard ist der Zugang zum Datacenter Manager enthalten. Innerhalb eines Clusters müssen alle Knoten dieselbe Stufe haben, damit Paketstände und Support-Anspruch konsistent bleiben.
Der Unterschied zwischen den Update-Kanälen entscheidet über die Betriebsstabilität. Proxmox liefert drei Repositories aus: Das Enterprise-Repository enthält die am intensivsten getesteten Pakete und ist der empfohlene Standard für Produktion. Das frei zugängliche No-Subscription-Repository erhält Updates früher und mit geringerer Testtiefe, weshalb es für Test- und Laborumgebungen gedacht ist. Das Test-Repository liefert Pakete direkt aus der Entwicklung. Wer geschäftskritische Systeme dauerhaft am No-Subscription-Kanal betreibt, macht seine Produktion zum Frühwarnsystem für Regressionen zwischen Debian-Basis, Kernel und QEMU-Laufzeit. Für den stabilen Betrieb gehört mindestens die Community-Subscription auf jeden produktiven Knoten, denn 120 Euro pro Socket sind billiger als ein einziger ungeplanter Cluster-Stillstand.
ROI konkret: Die Beispielrechnung
Zurück zum Cluster aus drei Hosts mit je zwei Prozessoren à 8 Kernen: 48 physische Kerne, 96 lizenzpflichtige Kerne bei VMware, 6 Sockets bei Proxmox. Die folgende Tabelle rechnet mit Listen-Größenordnungen Stand Mitte 2026, netto, ohne individuell verhandelte Rabatte:
| Modell | Rechnung | Kosten pro Jahr (Größenordnung) |
| vSphere Standard (VVS) | 96 Cores × ca. 75 € | ca. 7.200 € |
| vSphere Foundation (VVF) | 96 Cores × ca. 150 € | ca. 14.400 € |
| VMware Cloud Foundation (VCF) | 96 Cores × ca. 315 € | über 30.000 € |
| Proxmox VE ohne Subscription | Lizenz 0 € | 0 € |
| Proxmox VE Standard | 6 Sockets × 550 € | 3.300 € |
| Proxmox VE Premium | 6 Sockets × 1.100 € | 6.600 € |
Hinzu kommt bei Proxmox optional ein Proxmox Backup Server mit eigener Subscription ab rund 560 Euro pro Jahr und Backup-Server. Selbst die Premium-Stufe inklusive PBS liegt damit unter dem günstigsten VMware-Einstieg, der außerdem weder vSAN noch SDN enthält und auf dem auslaufenden 8er-Zweig festhängt. Ein dokumentiertes Praxisbeispiel aus dem Mittelstand zeigt die Dynamik: Ein Kunde mit drei ESXi-Hosts zahlte 2023 rund 8.000 Euro pro Jahr für vSphere und vSAN, das Renewal 2025 lag bei über 30.000 Euro für dasselbe Setup.
Ehrlich gerechnet ist der ROI trotzdem keine reine Lizenz-Subtraktion. Auf der Sollseite stehen Migrationsdienstleistung oder interne Projekttage, Schulung des Teams (realistisch zwei bis fünf Tage pro Administrator), gegebenenfalls neue Backup-Hardware für den PBS und die Anpassung der Automatisierung. Weil die wiederkehrende Ersparnis bei mittleren Umgebungen im fünfstelligen Bereich pro Jahr liegt, amortisiert sich der Wechsel in typischen Projekten innerhalb von 12 bis 18 Monaten, bei anstehenden VCF-Renewals häufig schon im ersten Betriebsjahr. Danach wirkt die Ersparnis jedes Jahr aufs Neue, während die VMware-Seite mit jeder Verlängerung neu verhandelt werden muss.
Migration in der Praxis: Die Reihenfolge entscheidet
Die technische Umstellung virtueller Maschinen folgt einer festen Reihenfolge, weil Abweichungen direkt in Bluescreens enden. Zuerst entfernst Du die VMware Tools vollständig aus dem Gast-Betriebssystem, denn deren verbleibende Treiber verursachen unter KVM schwere Systemfehler. Bei Windows-VMs installierst Du vor dem Umzug die VirtIO-Treiber, damit das System nach dem Plattformwechsel Disk- und Netzwerkgeräte findet. Anschließend werden die virtuellen Festplatten vom VMDK-Format nach RAW oder QCOW2 konvertiert.
Proxmox nimmt Dir den Konvertierungsschritt in vielen Fällen ab: Seit Version 8.2 verbindet sich ein integrierter Import-Assistent über die API direkt mit ESXi-Hosts oder dem vCenter, listet die VMs auf und importiert sie inklusive Konfigurationsübernahme. Ein Live-Import startet die VM bereits, während die Daten im Hintergrund übertragen werden, was die Downtime pro Maschine auf Minuten drückt. UEFI-Boot, vTPM für Windows 11 und Server 2025 sowie feste MAC-Adressen für lizenzgebundene Anwendungen gehören vor dem Umzug auf die Checkliste, nicht danach.
Organisatorisch bewährt sich die Migration in Wellen: unkritische Systeme zuerst, geschäftskritische in geplanten Wartungsfenstern mit getestetem Rollback. Die alte Umgebung bleibt bis zur Abnahme parallel lauffähig, wodurch der Rückweg jederzeit offen ist. Eine saubere Bestandsaufnahme aller VMs, Storage-Anbindungen und Abhängigkeiten vor Projektstart entscheidet über den Verlauf, denn die technische Konvertierung ist Routine, das Übersehen einer Abhängigkeit nicht.
Ein Posten wird in Kalkulationen gern vergessen: Bestehende Automatisierungs-Skripte auf Basis von VMware PowerCLI sind unter Proxmox unbrauchbar. Sie müssen auf die Proxmox REST-API, auf Werkzeuge wie Terraform (über den Community-Provider) oder auf Ansible umgestellt werden. Wer viel automatisiert hat, plant diesen Umbau als eigenes Teilprojekt ein.
Backup neu denken: PBS und die Veeam-Frage
Das Backup-Konzept ändert sich beim Plattformwechsel mit. Der Proxmox Backup Server (PBS) arbeitet als eigenständige Instanz und beherrscht clientseitige Deduplizierung, inkrementelle Sicherungen auf Blockebene, authentifizierte Verschlüsselung und geplante Verify-Jobs gegen schleichende Datenkorruption. VMs lassen sich per Live-Restore direkt aus dem Backup starten, während die Wiederherstellung im Hintergrund läuft. Für den Ransomware-Schutz replizierst Du die Backup-Datastores über isolierte Sync-Jobs an einen entfernten PBS in einem separaten Brandabschnitt, ergänzt um Tape-Ausgabe oder Objektspeicher-Ziele mit Immutability für die letzte Verteidigungslinie der 3-2-1-Regel.
Die früher berechtigte Sorge, mit Proxmox den etablierten Backup-Hersteller zu verlieren, ist überholt. Veeam unterstützt Proxmox VE seit Backup & Replication 12.2 nativ und agentenlos, in der aktuellen Data Platform v13 deckt das Plug-in die PVE-Versionen 8.2 bis 9.1 ab, inklusive inkrementeller Sicherungen, Immutability und plattformübergreifender Wiederherstellung. Der Restore vorhandener VMware-Backups direkt nach Proxmox VE eröffnet sogar einen zweiten Migrationsweg über die Backup-Ebene. Die Integration erreicht allerdings noch nicht die Tiefe der jahrzehntelang gereiften vSphere-Anbindung: Veeam arbeitet mit Worker-Appliances statt einer nativen Backup-API, was in der Praxis Pflegeaufwand erzeugt, und Funktionen wie CDP fehlen für PVE. Wer heterogen bleibt oder Microsoft-365-Sicherung im selben Haus betreibt, fährt mit Veeam plus PVE trotzdem eine tragfähige Kombination. Reine Proxmox-Umgebungen decken mit dem PBS die Kernanforderungen ohne Zusatzlizenzkosten ab.
Entscheidungsmatrix: Wann welches Lager
| Ausgangslage | Einordnung |
| Branchensoftware nur auf vSphere zertifiziert | VMware halten oder Teilmigration, Zertifizierungslage jährlich neu prüfen |
| NSX-Mikrosegmentierung produktiv im Einsatz | VCF bleibt gesetzt, Konditionen mit dokumentierten Alternativen verhandeln |
| Renewal steht an, Standard-Workloads auf 3 bis 10 Hosts | Proxmox VE ernsthaft prüfen, Amortisation meist binnen 12 bis 18 Monaten |
| Greenfield im Mittelstand | Proxmox VE mit Ceph oder ZFS als erster Kandidat |
| VDI mit Horizon | Horizon gehört seit dem Verkauf an KKR zu Omnissa, die Hypervisor-Frage stellt sich davon getrennt |
| Team ohne Linux-Erfahrung | Wechsel nur mit Schulungsbudget oder externem Partner planen |
Fazit
Das Verharren auf der VMware-Plattform bietet weiterhin den Vorteil eines ausgereiften, weltweit standardisierten Ökosystems mit breitem Drittanbieter-Support, formalen Hersteller-Zertifizierungen und einer Automatisierungstiefe, die über zwei Jahrzehnte gewachsen ist. Für Umgebungen mit zertifizierungspflichtiger Branchensoftware oder produktiver NSX-Mikrosegmentierung bleibt vSphere die rationale Wahl. Die Core-Lizenzierung mit 16er-Minimum, die Bundle-Pflicht und die seit 2024 mehrfach geänderten Vertragsbedingungen schränken den finanziellen und planerischen Spielraum im Mittelstand jedoch massiv ein. Wer heute unterschreibt, kauft eine Wette darauf, dass die Konditionen beim nächsten Jahrestag noch gelten.
Proxmox VE hat sich zur ernstzunehmenden Enterprise-Alternative entwickelt, weil die Socket-basierte Subscription kalkulierbar bleibt, der Funktionsumfang die typischen Mittelstands-Workloads abdeckt und die Backup-Frage durch PBS und die native Veeam-Unterstützung beantwortet ist. Der Wechsel ist trotzdem kein Software-Update, sondern eine Weichenstellung: Ceph verlangt diszipliniertes Hardware-Design mit PLP-SSDs und dediziertem Netz, das SDN verlangt Linux- und Routing-Wissen, die Automatisierung muss von PowerCLI auf REST-API, Terraform oder Ansible portiert werden. Der Erfolg einer Migration hängt direkt davon ab, ob Dein Team bereit ist, Management-Routinen abzulegen und sich Linux-Infrastrukturwissen anzueignen, oder ob ein Partner diesen Aufbau begleitet. Wer den Schritt strukturiert plant, mit Bestandsaufnahme, Wellen-Migration und getestetem Rollback, sichert sich eine belastbare und kosteneffiziente Plattform, deren Betriebskosten Du selbst kontrollierst und nicht der Lizenzgeber.
Pierro & Mai IT for Business
Die Pierro & Mai IT for Business GmbH mit Sitz in Ettlingen bei Karlsruhe ist seit 2010 der IT-Partner für den gehobenen Mittelstand in Baden-Württemberg und im DACH-Raum.
in Schwerpunkt des Teams um die geschäftsführenden Gesellschafter Tobias Mai und Torsten Pierro liegt in der herstellerunabhängigen Beratung, Wirtschaftlichkeits-Analyse und technischen Durchführung von Hypervisor-Migrationen, von der Bestandsaufnahme über die verlustfreie VM- und Storage-Migration zu Proxmox VE, Hyper-V oder Nutanix bis zur Betriebsübergabe an das interne Team.
Für den strukturierten Ausstieg aus der Broadcom-Kostenfalle stellt das Unternehmen eine kostenlose VMware-Exit-Checkliste bereit.

Pierro & Mai IT for Business GmbH | Hildastr. 13 | 76275 Ettlingen Deutschland
Telefon: 07243 3488960 | Mail: projektpower@it-for.business | Web: www.it-for.business
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Kommentar hinterlassen
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.