Seit Broadcom VMware übernommen hat, steht in vielen Serverräumen dieselbe Frage im Raum: bleiben oder wechseln. Proxmox vs ESXi ist dadurch von einer Homelab-Debatte zu einer Budgetfrage geworden, die Geschäftsführungen beschäftigt.
Die kurze Antwort: Proxmox VE ist ein vollständiger, quelloffener Hypervisor, der ohne Lizenzkosten produktiv laufen kann und pro CPU-Sockel bezahlt wird; ESXi ist Teil eines kommerziellen Stacks, der pro Kern lizenziert wird, ein Bestellminimum kennt und dessen Preise nicht öffentlich stehen. Technisch sind beide ausgereift. Der Unterschied liegt weniger im Hypervisor als im Ökosystem drumherum — und in der Frage, wie viel Betriebswissen im eigenen Haus liegt.
Dieser Artikel vergleicht beide Plattformen anhand von Dingen, die wir selbst gemessen haben: Preise am Erscheinungstag direkt von der Herstellerseite, Paketarchive heruntergeladen und ausgezählt, das Migrationswerkzeug ausgepackt und im Quelltext gelesen. Wo wir etwas nicht messen konnten, steht das ausdrücklich dabei, statt eine Zahl aus einem anderen Blog zu übernehmen.
Proxmox vs ESXi: die Antwort in acht Sätzen
- Proxmox VE ist eine Debian-basierte Virtualisierungsplattform mit KVM für VMs und LXC für Container, veröffentlicht unter der AGPLv3.
- ESXi ist ein proprietärer Typ-1-Hypervisor und heute nur noch als Teil größerer VMware-Bundles erhältlich.
- Proxmox rechnet pro belegtem CPU-Sockel, VMware pro Kern — zwei verschiedene Maßeinheiten, die sich nicht direkt vergleichen lassen.
- Proxmox VE lässt sich ohne jede Subskription produktiv betreiben; die Subskription kauft Support und ein getestetes Update-Repository, keine Funktionen.
- Bei VMware gibt es seit 2025 ein Bestellminimum von 72 Kernen — das trifft kleine Installationen unverhältnismäßig hart.
- Beide bieten Live-Migration, Hochverfügbarkeit und Cluster; Proxmox bringt Backup und Software-defined Storage ohne Aufpreis mit.
- Der Wechsel ist deutlich einfacher geworden: Proxmox liefert einen eingebauten ESXi-Import-Assistenten mit.
- ESXi bleibt sinnvoll, wenn ein großes vSphere-Ökosystem, spezielle Zertifizierungen oder Drittanbieter-Software daran hängen.
Was die beiden Plattformen technisch überhaupt sind
Der Vergleich hinkt an einer Stelle, die selten benannt wird: ESXi und Proxmox VE liegen nicht auf derselben Ebene.
ESXi ist der reine Hypervisor. Alles, was den Betrieb im Rechenzentrum ausmacht — zentrale Verwaltung, vMotion, DRS, Hochverfügbarkeit — kommt über vCenter Server und die darüberliegenden Bundles dazu. Ein einzelner ESXi-Host ohne vCenter ist ein nützliches, aber deutlich beschnittenes Werkzeug.
Proxmox VE ist dagegen eine komplette Plattform in einem Paket. Cluster, Weboberfläche, HA-Manager, Firewall, Backup-Integration und Storage-Anbindung stecken in derselben Installation. Es gibt keine zusätzliche Verwaltungs-Appliance, die man erst aufsetzen und dann selbst hochverfügbar machen muss. Die Weboberfläche läuft auf jedem Knoten und zeigt den gesamten Cluster.
Das hat eine Konsequenz, die im Alltag zählt: Bei Proxmox gibt es keinen zentralen Ausfallpunkt in der Verwaltung. Fällt ein Knoten aus, bedient man den Cluster über einen anderen. Bei vSphere ist vCenter ein eigener Dienst, der selbst abgesichert werden will.
Unter der Haube nutzt Proxmox KVM, also den Hypervisor im Linux-Kernel, zusammen mit QEMU für die Gerätesimulation. Das ist dieselbe Technik, auf der ein großer Teil der öffentlichen Cloud läuft. Ein Detail am Rande, das wir auf unserem eigenen Server nachgesehen haben: systemd-detect-virt meldet dort kvm — unsere Hetzner-VPS laufen selbst auf genau diesem Stack.
Container als zweite Betriebsart
Ein Unterschied, der in reinen Hypervisor-Vergleichen untergeht: Proxmox verwaltet neben vollwertigen VMs auch LXC-Container. Das sind keine Docker-Container für einzelne Anwendungen, sondern Systemcontainer — sie verhalten sich wie schlanke Linux-Maschinen, teilen sich aber den Kernel des Hosts.
Praktisch heißt das: Ein kleiner Dienst, der als VM 1 GB RAM allein für das Gastbetriebssystem verbraucht, läuft als Container mit einem Bruchteil davon. Wer viele kleine Linux-Dienste betreibt, bekommt hier deutlich mehr Dichte auf dieselbe Hardware. ESXi kennt diese Betriebsart nicht; dort ist jede Arbeitslast eine vollständige VM.
Lizenzmodell und Kosten: zwei Einheiten, die nicht vergleichbar sind
Hier liegt der eigentliche Grund, warum dieses Thema gerade überall diskutiert wird. Wir haben die Preise am Tag der Veröffentlichung direkt bei Proxmox geladen und ausgelesen, statt sie aus Vergleichsartikeln zu übernehmen.
Die Proxmox-Preise, gemessen an der Quelle
| Stufe | Preis pro Jahr | Einheit | Support-Tickets | Reaktionszeit |
|---|---|---|---|---|
| Community | 120 € | pro CPU-Sockel | keine (Forum) | — |
| Basic | 370 € | pro CPU-Sockel | 3 pro Jahr | 1 Arbeitstag |
| Standard | 550 € | pro CPU-Sockel | 10 pro Jahr | 4 Stunden* |
| Premium | 1.100 € | pro CPU-Sockel | unbegrenzt | 2 Stunden* |
Der entscheidende Satz steht in Proxmox’ eigener FAQ und wird in Vergleichen oft übersehen: „Die Anzahl der CPU-Kerne hat keinen Einfluss auf den Preis.” Und ebenso wörtlich: „Sind Funktionen von Proxmox VE je nach Subskriptionsstufe eingeschränkt? Nein.” Hochverfügbarkeit, Live-Migration, Clustering, Backup, Software-defined Storage — alles ist in jeder Stufe enthalten, auch in der günstigsten. Bezahlt wird der Support-Anspruch und das getestete Update-Repository.
Eine Einschränkung, die man kennen sollte: In einem Cluster müssen alle belegten Sockel aller Server abgedeckt sein, und alle Knoten müssen dieselbe Stufe nutzen. Man kann also nicht einen Knoten mit Premium und drei mit Community betreiben.
Was die Subskription technisch wirklich ändert
Diese Frage lässt sich nicht diskutieren, sondern messen. Wir haben beide Paketquellen direkt angefragt:
curl -sI https://enterprise.proxmox.com/debian/pve/dists/trixie/InRelease # → 401
curl -sI http://download.proxmox.com/debian/pve/dists/trixie/InRelease # → 200Das Enterprise-Repository antwortet ohne gültigen Schlüssel mit HTTP 401, das No-Subscription-Repository mit HTTP 200. Genau das ist der Unterschied in der Praxis: Ohne Subskription bekommt man Updates aus einem Kanal, der weniger lange getestet wurde. Die Software ist dieselbe.
Aus dem No-Subscription-Repo für Proxmox VE 9 (Debian 13 „trixie”) haben wir den Paketindex gezogen und ausgezählt: 601 eindeutige Pakete, darunter 327 aus der proxmox-*-Familie und 25 Ceph-Pakete, zusammen 18,7 GB.
⚠️ Eine Zahl, die fast falsch in diesen Artikel gewandert wäre. Mein erster Auszählungslauf meldete 1.945 Pakete. Das klang plausibel und wäre ohne Gegenprüfung so stehen geblieben. Tatsächlich zählte ich
Package:-Zeilen — und ein Repository führt mehrere Versionen desselben Pakets nebeneinander. Alleinpve-managersteht dort 65-mal. Die ehrliche Zahl ist 601. Ein Index listet Versionen, keine Programme; wer Zeilen zählt, misst Archivtiefe und nennt sie Funktionsumfang.
Die VMware-Seite: und warum hier keine Preistabelle steht
Für VMware können wir keine gemessene Tabelle liefern — und das ist selbst ein Befund.
Wir haben es versucht. Die Produktseite zu vSphere liefert zwar HTTP 200, enthält aber im ausgelieferten HTML kein einziges Vorkommen von „per core”, „Foundation”, „price” oder „Pricing”; der sichtbare Text besteht aus 44 Zeichen, alles Weitere wird nachgeladen. Die Downloadbereiche bei Broadcom leiten auf eine Login-Seite um:
support.broadcom.com/group/ecx/productdownloads
→ support.broadcom.com/c/portal/login?redirect=...Zum Vergleich derselbe Test bei Proxmox: Das Installations-ISO liefert HTTP 200 ohne Anmeldung, der komplette Quelltext liegt unter git.proxmox.com offen (157 Repositories), und die Preisseite ist eine normale öffentliche Webseite.
Was in Marktberichten und Händlerangaben kursiert, sind Listenpreise von 150 bis 190 US-Dollar pro Kern und Jahr für vSphere Foundation, dazu ein Bestellminimum von 72 Kernen pro Bestellung und Produkt. Wir geben diese Zahlen ausdrücklich als unbelegt durch eine Primärquelle weiter. Sie stammen aus Berichten von Händlern und Kunden, nicht von einer öffentlichen Preisliste — und sie widersprechen sich untereinander.
🔑 Der eigentliche Unterschied ist an dieser Stelle nicht die Höhe des Preises, sondern seine Auffindbarkeit. Bei einer Plattform kann ich den Jahresbeitrag in 30 Sekunden selbst nachlesen und diesen Artikel mit einer Quelle belegen. Bei der anderen brauche ich ein Vertriebsgespräch, um überhaupt zu erfahren, worüber wir reden. Für die Budgetplanung ist das ein handfester Unterschied — unabhängig davon, welche Zahl am Ende herauskommt.
Eine Beispielrechnung — und warum sie mit Vorsicht zu lesen ist
Nehmen wir eine typische kleine Produktivumgebung: drei Hosts mit je zwei CPU-Sockeln à 32 Kernen, also 6 Sockel und 192 Kerne.
| Variante | Rechnung | Kosten pro Jahr |
|---|---|---|
| Proxmox VE ohne Subskription | — | 0 € |
| Proxmox VE Community | 6 × 120 € | 720 € |
| Proxmox VE Basic | 6 × 370 € | 2.220 € |
| Proxmox VE Standard | 6 × 550 € | 3.300 € |
| Proxmox VE Premium | 6 × 1.100 € | 6.600 € |
| VMware, falls 150 USD/Kern zuträfe | 192 × 150 USD | ca. 28.800 USD |
| VMware, falls 190 USD/Kern zuträfe | 192 × 190 USD | ca. 36.480 USD |
Die Größenordnung ist der Punkt, nicht die Nachkommastelle. Und das 72-Kern-Minimum trifft kleine Häuser am härtesten: Wer nur zwei Hosts mit je 16 Kernen betreibt, nutzt 32 Kerne und bezahlt trotzdem 72. Mehr als die Hälfte der Rechnung entfällt dann auf Kerne, die es gar nicht gibt.
Cluster, Quorum und Hochverfügbarkeit
Hier wird oft zu schnell „beide können HA” gesagt. Die Mechanik dahinter unterscheidet sich, und die Details entscheiden, ob es im Ernstfall funktioniert.
Proxmox nutzt Corosync für die Cluster-Kommunikation und einen eigenen HA-Manager mit Watchdog-basiertem Fencing. Kein Pacemaker, keine externen Werkzeuge. Aus dem Administrationshandbuch, das wir dafür im Volltext ausgewertet haben (Corosync wird dort 169-mal erwähnt, Quorum 71-mal):
„If you are interested in High Availability, you need to have at least three nodes for reliable quorum.”
Drei Knoten sind das Minimum für verlässliche Hochverfügbarkeit — nicht zwei. Das ist keine Proxmox-Eigenheit, sondern Mathematik: Zwei Knoten können bei einer Netzwerktrennung nicht entscheiden, wer weiterlaufen darf. Für Zwei-Knoten-Aufbauten gibt es ein QDevice als dritte Stimme.
Der Fall, in dem mehr Redundanz weniger Sicherheit bedeutet
Genau zu diesem QDevice steht im Handbuch eine Warnung, die man leicht überliest — und die die Intuition auf den Kopf stellt:
„In a cluster with 15 nodes, 7 could fail before the cluster becomes inquorate. But, if a QDevice is configured here and it itself fails, no single node of the 15 may fail.”
In Worten: In einem 15-Knoten-Cluster ohne QDevice dürfen sieben Knoten ausfallen. Mit QDevice — wenn dieses selbst ausfällt — darf kein einziger Knoten mehr ausfallen. Das Bauteil, das die Verfügbarkeit erhöhen sollte, wird zum Engpass.
🔑 Das ist die wichtigste Betriebslehre dieses Artikels, und sie gilt für jede Plattform: Eine Komponente, die als Tiebreaker hinzugefügt wird, verlagert den Ausfallpunkt, statt ihn zu beseitigen. Bei kleinen Clustern ist ein QDevice eine gute Idee, bei großen ein Risiko — und die Grenze dazwischen steht in keinem Marketingdokument.
Ein zweites Detail aus derselben Quelle, das im Betrieb zählt: Die Zeit für den Aufbau einer neuen Cluster-Mitgliedschaft nach einem Knotenausfall muss unter 45 Sekunden bleiben, weil der Watchdog-Timeout bei 60 Sekunden zuschlägt. Wer Corosync über ein Netz laufen lässt, das mit Storage-Verkehr geteilt wird, riskiert genau das. Die Empfehlung im Handbuch ist deshalb eindeutig: eigenes physisches Netz für Corosync, und ausdrücklich kein gemeinsames Netz mit dem Storage.
Was vSphere an dieser Stelle voraushat
Ehrlicherweise: einiges, und zwar vor allem bei Größe und Automatik.
DRS (Distributed Resource Scheduler) verteilt Lasten automatisch über den Cluster und ist seit vielen Jahren im Feld erprobt. Proxmox hat mit dem dynamischen HA-Balancer inzwischen ein Gegenstück — im Paketindex von Proxmox VE 9.2 finden sich Optionen wie ha-auto-rebalance mit wählbaren Bewertungsverfahren (bruteforce oder topsis) —, aber das ist jung im Vergleich zu DRS.
Ähnliches gilt für die zentrale Verwaltung sehr vieler Standorte. Proxmox adressiert das mit dem Datacenter Manager, der in allen Subskriptionsstufen enthalten ist. Er ist ein neueres Produkt als vCenter, und wer Dutzende Cluster über mehrere Rechenzentren fährt, sollte das vorher prüfen statt es anzunehmen.
Storage: der größte praktische Unterschied
Proxmox bringt Ceph direkt mit — verteilter, replizierter Storage über die Cluster-Knoten hinweg, ohne SAN und ohne Zusatzlizenz. Im Paketindex haben wir dazu 25 Ceph-Pakete in der Version 19.2.6-pve4 gefunden, von Proxmox selbst gebaut und gepflegt.
Dazu kommt ZFS als lokales Dateisystem mit Prüfsummen, Snapshots und eingebauter Replikation zwischen Knoten. Wer keinen Ceph-Cluster bauen will, bekommt mit ZFS-Replikation eine einfache Notfallvorsorge: Ein Knoten spiegelt seine VMs in festen Abständen auf einen anderen.
Eine Warnung aus der offiziellen Dokumentation, die regelmäßig ignoriert wird und teuer endet:
„Neither ZFS nor Ceph are compatible with a hardware RAID controller.”
Wer einen RAID-Controller im Server hat und ZFS oder Ceph nutzen will, muss die Platten direkt durchreichen. Ein Hardware-RAID unter ZFS ist keine zusätzliche Sicherheit, sondern nimmt dem Dateisystem genau die Kontrolle weg, aus der seine Garantien stammen.
Bei VMware ist das Gegenstück vSAN — technisch ausgereift, aber ein weiteres, separat lizenziertes Produkt, das nach Kapazität abgerechnet wird. Der strukturelle Unterschied ist also nicht „kann es das”, sondern: bei Proxmox ist verteilter Storage Teil der Plattform, bei VMware ein zusätzlicher Posten auf der Rechnung.
Backup als eingebauter Teil, nicht als Drittprodukt
Proxmox VE kann Sicherungen von Haus aus. Für ernsthafte Anforderungen gibt es den Proxmox Backup Server mit Deduplizierung, Verschlüsselung und inkrementellen Sicherungen. Auch dessen Preise haben wir an der Quelle gemessen:
| PBS-Stufe | Preis pro Jahr | Support-Tickets |
|---|---|---|
| Community | 560 € | Community-Forum |
| Basic | 1.120 € | 5 pro Jahr |
| Standard | 2.240 € | 15 pro Jahr |
| Premium | 4.480 € | unbegrenzt |
Wichtig zum Verständnis: Der PBS wird pro Server lizenziert, nicht pro Sockel wie Proxmox VE. Und auch hier gilt: Die Software läuft ohne Subskription, gezahlt wird für Support und das getestete Repository.
Im VMware-Umfeld übernimmt das typischerweise ein Drittanbieter wie Veeam — leistungsfähig, etabliert, und ein weiterer Vertrag mit eigener Preislogik.
Der Wechsel von ESXi zu Proxmox: das Werkzeug im Detail
Seit Proxmox VE 8.2 gibt es einen eingebauten Import-Assistenten für ESXi. Wir haben das Paket pve-esxi-import-tools heruntergeladen, entpackt und angesehen, statt die Beschreibung zu übernehmen.
Das Paket ist mit 1,36 MB erstaunlich klein und enthält ganze vier Dateien: ein Python-Skript zum Auflisten der VMs, ein FUSE-Programm von 5 MB, das den ESXi-Datastore als Dateisystem einhängt, dazu Changelog und Lizenz. Lizenz ist wie beim Rest AGPLv3. Die Verbindung läuft über pyVmomi, also die offizielle vSphere-API-Bibliothek — kein nachgebautes Protokoll.
Der praktische Ablauf: ESXi-Host oder vCenter als Storage-Typ hinzufügen, VMs erscheinen in der Liste, Ziel auswählen, importieren. Die Umwandlung der VMDK-Dateien passiert dabei automatisch.
Ein Fund im Quelltext, den man vor dem ersten Import kennen sollte
Beim Lesen von listvms.py ist uns diese Stelle aufgefallen:
ssl_context = (
ssl._create_unverified_context()
if args.skip_cert_verification
else None
)Setzt man im Assistenten den Haken zum Überspringen der Zertifikatsprüfung, wird die TLS-Verbindung zum ESXi-Host vollständig ungeprüft aufgebaut. Und über genau diese Verbindung gehen Benutzername und Passwort eines Kontos, das Lesezugriff auf alle VMs der alten Umgebung hat.
Das ist kein Fehler im Werkzeug — die Alternative steht sogar in der Fehlermeldung des Programms selbst: die CA des ESXi-Hosts in den Systemzertifikatsspeicher legen. Aber es ist eine Option, die man im Assistenten in zwei Sekunden anklickt, weil ESXi-Hosts fast immer selbstsignierte Zertifikate haben und es sonst nicht weitergeht.
🔑 Ein Haken, der eine Sicherheitsprüfung abschaltet, ist im Ablauf nicht von einem Haken zu unterscheiden, der eine Anzeige ausblendet. Wenn Sie migrieren: entweder die CA hinterlegen, oder den Import über ein Netzsegment fahren, in dem ein Mitlesen praktisch ausgeschlossen ist — und die Zugangsdaten danach wechseln.
Was der Import nicht mitbringt
Der Assistent überträgt VMs. Er überträgt nicht Ihre Betriebslogik: keine vSphere-Berechtigungen, keine DRS-Regeln, keine verteilten virtuellen Switches, keine Sicherungsaufträge, kein Monitoring.
Dazu kommen die klassischen Stolpersteine auf Gastseite:
- Windows-VMs brauchen die VirtIO-Treiber, sonst startet das System nach dem Umzug nicht sauber. Der sichere Weg: Treiber vor der Migration im laufenden System installieren.
- VMware Tools sollten entfernt und durch den QEMU-Guest-Agent ersetzt werden.
- Der Festplatten-Controller muss stimmen — VirtIO SCSI ist die richtige Wahl, aber ein Windows, das SATA gewohnt ist, quittiert die Umstellung ohne Vorbereitung mit einem Bluescreen.
- Netzwerkkarten bekommen neue MAC-Adressen; alles, was per MAC festgenagelt ist (DHCP-Reservierungen, Lizenzbindungen), muss nachgezogen werden.
Ein Detail aus dem Changelog des Import-Werkzeugs zeigt, dass diese Dinge in der Praxis auftreten — Version 1.0.1 behebt, dass eine einzelne unlesbare VM bis dahin die gesamte Auflistung scheitern ließ:
„skip VMs we cannot parse or are in a bad state gradually instead of failing the whole list VM invocation.”
Hardware und Betriebssystem-Unterbau
Proxmox VE 9 basiert auf Debian 13 „trixie”. Das hat eine Konsequenz, die im Alltag mehr Gewicht hat als jede Funktionsliste: Die Hardware-Unterstützung ist die des Linux-Kernels, nicht die einer Kompatibilitätsliste.
Bei VMware gibt es die Hardware Compatibility List. Hardware, die dort nicht steht, wird nicht unterstützt — und Geräte fallen mit neuen ESXi-Versionen aus der Liste, unabhängig von ihrem tatsächlichen Zustand. Das erzwingt Austauschzyklen nach fremdem Kalender.
Die Mindestanforderungen von Proxmox sind bewusst niedrig gehalten (Testumgebung: 64-Bit-CPU mit Virtualisierungserweiterung, 1 GB RAM, eine Platte, eine Netzwerkkarte). Für den Produktivbetrieb empfiehlt Proxmox ausdrücklich redundante Netzwerkkarten und — bei lokalem Storage — entweder Hardware-RAID mit gepufferter Schreibcache-Einheit oder ZFS ohne RAID-Controller.
Ein Punkt, der in Vergleichen kaum auftaucht: Proxmox VE unterstützt inzwischen auch ARM64 (Armv9-A oder neuer) — Support dafür läuft über den Vertrieb. Die ISO-Größen sind über die Versionen hinweg moderat gewachsen: 1.071 MB bei PVE 7.4, 1.499 MB bei 8.4, 1.627 MB bei 9.2.
⚠️ Eine Grenze, die wir offen benennen: Wir konnten für diesen Artikel keine eigenen Leistungsmessungen zwischen den beiden Hypervisoren durchführen. Unser Server hat kein
/dev/kvm— er ist selbst eine VM ohne verschachtelte Virtualisierung. Statt fremde Benchmark-Zahlen zu übernehmen, die wir nicht nachprüfen können, lassen wir diesen Abschnitt leer. Eine abgeschriebene Zahl sieht in einer Tabelle identisch aus wie eine gemessene. Was sich seriös sagen lässt: Beide nutzen Hardware-Virtualisierung, und der Unterschied ist bei typischen Serverlasten klein genug, dass er in den meisten Entscheidungen keine Rolle spielt.
Wann ESXi die richtige Wahl bleibt
Dieser Abschnitt gehört in jeden ehrlichen Vergleich. Es gibt Situationen, in denen ein Wechsel falsch wäre:
Wenn Drittanbieter-Software an vSphere hängt. Manche Backup-, Monitoring- oder Branchenlösungen sind gegen die vSphere-API zertifiziert und unterstützen Proxmox schlicht nicht. Diese Prüfung kommt vor jeder Kostenrechnung.
Wenn Zertifizierungen oder Auditvorgaben VMware verlangen. In regulierten Umgebungen steht manchmal wörtlich im Prüfkatalog, welche Plattform eingesetzt wird. Das ändert man nicht mit einem Migrationsassistenten.
Wenn das vorhandene Wissen vollständig bei vSphere liegt. Ein Team, das seit zehn Jahren vCenter bedient, wechselt nicht in einem Quartal. Die eingesparten Lizenzkosten werden in Lernzeit, Fehlern und Nachtstunden wieder ausgegeben — im ersten Jahr oft vollständig.
Wenn Sie sehr große, mehrstandortige Umgebungen mit ausgefeilter Automatik betreiben. DRS, Storage DRS, NSX und die Integration darum herum sind ein gewachsenes Ökosystem. Proxmox holt auf, ist an dieser Stelle aber jünger.
Wenn der Vertrag ohnehin läuft und bezahlt ist. Eine Migration mitten in einer bezahlten Laufzeit spart nichts und bringt Risiko.
Umgekehrt spricht vieles für Proxmox, wenn Sie ein bis ein Dutzend Hosts betreiben, Linux-Kompetenz im Haus haben, planbare Kosten brauchen und Backup sowie Storage nicht als drei separate Verträge führen wollen.
Proxmox vs ESXi: die Gegenüberstellung
| Kriterium | Proxmox VE | VMware ESXi / vSphere |
|---|---|---|
| Lizenz | AGPLv3, quelloffen | proprietär |
| Abrechnungseinheit | pro CPU-Sockel | pro Kern |
| Bestellminimum | keins | 72 Kerne (laut Marktangaben) |
| Betrieb ohne Zahlung | möglich, produktiv | nicht vorgesehen |
| Preise öffentlich einsehbar | ja, gemessen | nein, Login/Vertrieb |
| Funktionsumfang je Stufe | identisch | nach Edition gestaffelt |
| Zentrale Verwaltung | in jedem Knoten enthalten | vCenter, separater Dienst |
| Container | LXC eingebaut | nicht vorhanden |
| Verteilter Storage | Ceph enthalten | vSAN, extra lizenziert |
| Backup | PBS, eigenes Produkt | typisch Drittanbieter |
| Hardware-Unterstützung | Linux-Kernel | Kompatibilitätsliste |
| Automatisches Lastbalancing | HA-Balancer, jung | DRS, lange erprobt |
| Quelltext einsehbar | ja, 157 Repositories | nein |
Häufige Fragen
Ist Proxmox wirklich kostenlos?
Ja, die Software ist unter der AGPLv3 frei verfügbar und darf produktiv eingesetzt werden. Was Geld kostet, ist die Subskription — und die enthält keine zusätzlichen Funktionen, sondern Support-Ansprüche und Zugang zum getesteten Enterprise-Repository. Gemessen: Das Enterprise-Repository antwortet ohne Schlüssel mit HTTP 401, das frei zugängliche No-Subscription-Repository mit HTTP 200.
Was kostet Proxmox im Vergleich zu VMware?
Proxmox kostet zwischen 120 € (Community) und 1.100 € (Premium) pro CPU-Sockel und Jahr, gemessen an der offiziellen Preisseite am 17.09.2026. VMware rechnet pro Kern ab und veröffentlicht keine öffentliche Preisliste; kursierende Marktangaben nennen 150 bis 190 US-Dollar pro Kern und Jahr bei einem Minimum von 72 Kernen. Die beiden Einheiten sind nicht direkt vergleichbar — ein Server mit zwei Sockeln zu je 32 Kernen ist bei Proxmox zwei Einheiten und bei VMware 64.
Wie viele Knoten braucht ein Proxmox-Cluster für Hochverfügbarkeit?
Mindestens drei. Das steht so in der offiziellen Dokumentation: „you need to have at least three nodes for reliable quorum”. Bei zwei Knoten lässt sich ein QDevice als dritte Stimme ergänzen — aber Vorsicht: In großen Clustern kann ein ausgefallenes QDevice dazu führen, dass kein einziger Knoten mehr ausfallen darf.
Kann ich VMs von ESXi zu Proxmox migrieren?
Ja, seit Proxmox VE 8.2 gibt es einen eingebauten Import-Assistenten. Man fügt den ESXi-Host oder vCenter als Storage hinzu, wählt die VMs aus und importiert sie; die VMDK-Umwandlung läuft automatisch. Nicht mitgenommen werden Berechtigungen, DRS-Regeln, verteilte Switches und Sicherungsaufträge — und Windows-Gäste brauchen vorher die VirtIO-Treiber.
Ist ESXi noch kostenlos verfügbar?
Die kostenlose Ausgabe des vSphere Hypervisors wurde im Februar 2024 eingestellt und später nur eingeschränkt und für ältere Versionen wieder zugänglich gemacht. Verlassen sollte man sich darauf nicht: Schon der Zugang zum Downloadbereich verlangt heute eine Anmeldung bei Broadcom — wir haben es geprüft, die URL leitet auf eine Login-Seite um.
Ist Proxmox langsamer als ESXi?
Wir haben das nicht selbst gemessen und geben deshalb keine Zahl an. Beide nutzen Hardware-Virtualisierung mit paravirtualisierten Treibern; bei typischen Serverlasten liegen die Unterschiede in einem Bereich, der in Kaufentscheidungen selten den Ausschlag gibt. Wer belastbare Zahlen für die eigene Arbeitslast braucht, muss sie auf der eigenen Hardware erheben — fremde Benchmarks betreffen fremde Hardware.
Braucht Proxmox einen RAID-Controller?
Für ZFS und Ceph ausdrücklich nein — die Dokumentation sagt wörtlich, dass beide „not compatible with a hardware RAID controller” sind. Platten müssen direkt durchgereicht werden. Nur bei klassischem lokalem Storage ohne ZFS empfiehlt Proxmox Hardware-RAID mit gepuffertem Schreibcache.
Was ist der Unterschied zwischen ESXi und vSphere?
ESXi ist der Hypervisor, der auf dem einzelnen Server läuft. vSphere ist das Produktbündel drumherum, das vor allem vCenter Server für die zentrale Verwaltung mitbringt — und damit erst Funktionen wie vMotion, DRS und clusterweite Hochverfügbarkeit ermöglicht. Proxmox VE entspricht funktional eher dem Bündel als dem nackten Hypervisor, weil die Clusterverwaltung bereits enthalten ist.
Kann Proxmox auch Container?
Ja, LXC-Systemcontainer sind direkt eingebaut und werden in derselben Oberfläche verwaltet wie VMs. Das sind keine Anwendungscontainer wie bei Docker, sondern schlanke Linux-Systeme, die sich den Kernel des Hosts teilen — deutlich sparsamer als eine vollständige VM. ESXi kennt diese Betriebsart nicht.
Lohnt sich ein Wechsel mitten im laufenden Vertrag?
In der Regel nicht. Eine Migration kostet Arbeitszeit, Testaufwand und Risiko; wenn die VMware-Lizenz ohnehin bezahlt ist, spart der Wechsel in diesem Zeitraum nichts. Der sinnvolle Zeitpunkt ist die anstehende Verlängerung — mit genug Vorlauf, um vorher einen Testcluster zu bauen und die Drittanbieter-Software zu prüfen.
Fazit
Proxmox vs ESXi ist in 2026 weniger eine technische Frage als eine über Geschäftsmodelle. Beide Hypervisoren erledigen ihre Hauptaufgabe zuverlässig. Der Unterschied liegt darin, was drumherum passiert: ob Storage und Backup Teil der Plattform oder zusätzliche Verträge sind, ob der Preis auf einer Webseite steht oder im Vertriebsgespräch entsteht, und ob die Rechnung nach Sockeln oder nach Kernen wächst.
Für kleine und mittlere Umgebungen mit Linux-Kompetenz im Haus ist Proxmox VE die pragmatischere Wahl — und der Wechsel ist mit dem eingebauten Import-Assistenten so einfach wie nie. Für große, gewachsene vSphere-Landschaften mit zertifizierter Drittanbieter-Software ist ein Wechsel dagegen ein Projekt, kein Nachmittag.
Was wir aus der Recherche mitnehmen, ist unabhängig vom Produkt: Prüfen Sie Zahlen an der Quelle. Unsere eigene erste Paketzählung war um den Faktor drei zu hoch, weil sie Versionen statt Programme zählte. Und die auffälligste Eigenschaft der VMware-Preise ist nicht ihre Höhe, sondern dass wir sie für diesen Artikel schlicht nicht belegen konnten.
Weiterlesen: Linux-Server-Distributionen im Vergleich als Überblick über den Unterbau, Linux-Server einrichten für die Härtung eines frischen Systems, Debian vs Ubuntu zur Basis von Proxmox und IT-Sicherheitslücken zum Thema Zertifikate und Angriffsflächen.