Proxmox VE vs VMware ESXi 2026: die Sicht des Dedicated-Server-Betreibers

Die kurze Antwort

Für einen Single-Tenant-Dedicated-Server oder einen kleinen Cluster im Jahr 2026 gilt: Proxmox VE ist der Standard, und VMware ESXi ist nur vertretbar, wenn Sie bereits für den vollständigen vSphere-Stack bezahlen (und ihn auch nutzen). Das ist eine deutlichere Aussage, als die meisten Vergleiche wagen, deshalb begründet der Rest dieses Artikels sie: was die Lizenzänderung von Broadcom bewirkt hat, was das zurückgekehrte kostenlose ESXi kann und was nicht, die Architekturunterschiede, die speziell auf Bare Metal zählen, die Fehlerbilder im Multi-Node-Betrieb, die in Produktion wehtun, und eine ehrliche Kostenrechnung pro Node.

Warum Sie diesem Text eher trauen können als dem durchschnittlichen Überblick: Die meisten Inhalte zu Proxmox vs ESXi sind für Homelabs geschrieben (optimiert für einen Mini-PC) oder von Backup-Anbietern (Funktionslisten, die mit „und hier ist unser Produkt“ enden). Wer einen Dedicated Server betreibt, arbeitet unter anderen Bedingungen (Wiederherstellung nur über IPMI, Single-Tenant-Hardware, kein SAN, Netzwerk auf dem Host konfiguriert), und diese Bedingungen verändern die Antwort.

Was sich geändert hat: Broadcom und das zurückgekehrte ESXi

Zwei Dinge haben diesen Vergleich neu aufgesetzt, und Sie brauchen beide, um ihn zu bewerten.

Die Lizenzumstellung. Seit der Übernahme von VMware durch Broadcom gibt es keine unbefristeten Lizenzen mehr; alles ist ein Abonnement, lizenziert pro physischem Core, mit einem Minimum von 16 Cores pro CPU, das auch bei CPUs mit weniger Cores berechnet wird. Die alten Einzel-SKUs sind in zwei Bundles aufgegangen: VMware vSphere Foundation (VVF) für den Mittelstand und die größere VMware Cloud Foundation (VCF) für eine vollständige Private Cloud (VCF ergänzt NSX, SDDC Manager und die 4-fache mitgelieferte vSAN-Kapazität). 2025 gab es außerdem ein viel diskutiertes Minimum von 72 Cores pro Bestellung; sein aktueller Status ist unklar (einige Kanäle berichten, es sei nach Protesten zurückgenommen worden, andere nennen es weiterhin), behandeln Sie es also als „beim Reseller nachfragen“, nicht als feste Regel. Für einen kleinen Betreiber mit modernen CPUs mit vielen Cores treiben das Core-Modell und die Abo-Untergrenze die jährlichen Kosten weit über das, was die Lizenzierung derselben Hardware früher gekostet hat.

Das kostenlose ESXi ist zurück, aber lesen Sie die Grenzen. Broadcom hat mit Version 8.0 Update 3e im April 2025 wieder ein kostenloses ESXi eingeführt. Damit stellte sich die Frage „sollte ich einfach zurück zum kostenlosen ESXi?“ erneut, deshalb hier die dokumentierten Grenzen direkt aus der KB von Broadcom:

• 8 vCPUs pro virtueller Maschine. Nicht 8 insgesamt, sondern 8 pro VM. Ein einzelner Datenbank-Gast mit 16 vCPUs ist ausgeschlossen.
• Bis zu 2 physische CPUs (Sockel) pro Host. Das ist eine Sockel-Grenze, keine VM-Grenze.
• Die Management-APIs sind schreibgeschützt. Diese Grenze wiegt am schwersten: Backup-Tools von Drittanbietern (Veeam und Co.) brauchen schreibfähige APIs (VADP), also können Sie VMs auf dem kostenlosen ESXi damit nicht sichern. Auch vMotion, DRS und HA fehlen.
• Es lässt sich nicht über vCenter verwalten, und es gibt weder Support noch SLA.

Zusammen genommen machen diese Grenzen das kostenlose ESXi zu einem brauchbaren Produkt für ein Labor oder einen einzelnen isolierten Host und zu einer ungeeigneten Grundlage für einen verwalteten, gesicherten Produktionsserver, besonders auf einer modernen Dual-Socket-Maschine mit 32+ Cores pro Sockel, wo die Grenze von 8 vCPUs pro VM und die fehlende Backup-API sofort greifen. Stand Mitte 2026 ist der kostenlose Build weiterhin 8.0U3e; vSphere 9 existiert, ein kostenloses ESXi 9 gibt es nicht. „Das kostenlose ESXi ist zurück“ stimmt also und spielt für einen Produktionsserver kaum eine Rolle.

Architektur, wo sie auf Bare Metal zählt

Tabellen, die Funktion gegen Funktion stellen, übersehen, was sich unterscheidet, wenn Ihnen die ganze Maschine gehört. Vier Punkte tun es.

Hypervisor-Modell: KVM + LXC vs reiner Type-1. Proxmox VE betreibt vollständige KVM-VMs und LXC-Systemcontainer über eine Oberfläche; ESXi ist ein reiner Type-1-Hypervisor, der nur VMs ausführt. Auf einer einzelnen, dicht belegten Maschine bedeutet dieser Unterschied Geld: LXC-Container teilen sich den Host-Kernel, sodass Sie deutlich mehr reine Linux-Workloads auf dieselbe Hardware packen als mit vollständigen VMs, während Sie VMs für alles behalten, was einen eigenen Kernel oder eine harte Isolationsgrenze braucht.

Storage: softwaredefiniert vs VMware-Stack. Proxmox liefert ZFS (lokal, mit Snapshots, Prüfsummen und Replikation), Ceph RBD (verteilt, hyperkonvergent) und LVM-thin direkt mit, dazu Verzeichnis, NFS und iSCSI. VMware bietet VMFS auf Block-Storage und vSAN, und in den aktuellen Bundles wird die vSAN-Kapazität innerhalb der Lizenz pro Core bemessen. Auf einem Dedicated Server mit lokalem NVMe und ohne SAN passt ZFS auf einem einzelnen Node oder Ceph über ein paar Nodes am besten, und beides ist enthalten statt pro Terabyte lizenziert.

Netzwerk: Linux auf dem Host. Das Netzwerk in Proxmox besteht standardmäßig aus Linux-Bridges, Open vSwitch und ein SDN-Framework sind verfügbar; Sie konfigurieren es in /etc/network/interfaces wie auf jedem anderen Linux-System, und genau das tut ein Dedicated-Server-Betreiber ohnehin. VMware nutzt Standard- und Distributed-vSwitches, NSX gibt es nur im VCF-Bundle. Wenn Ihr Wiederherstellungsweg eine IPMI-Konsole ist, ist „das ist einfach Linux-Netzwerk“ ein handfester Vorteil.

API und Automatisierung. Proxmox liefert bei jeder Installation eine vollständige REST-API mit (HTTPS auf 8006, pvesh, API-Tokens), kostenlos. Die Automatisierungsschnittstelle von vSphere liegt hinter vCenter und einer kostenpflichtigen Lizenz, und die API des kostenlosen ESXi ist schreibgeschützt, sodass die kostenlose Stufe überhaupt keine nutzbare Automatisierungs- oder Backup-API hat. Wenn Sie Ihre Infrastruktur mit Terraform oder Ansible steuern, ist Proxmox vom ersten Tag an ohne Kosten automatisierbar.

Der Betriebsalltag: was keine Funktionstabelle zeigt

Hier weicht die Erfahrung eines Produktionsbetreibers von einem Homelab-Test ab. Proxmox ist ausgezeichnet, hat aber scharfe Kanten, die erst bei mehreren Nodes und unter Speicherdruck sichtbar werden. Wer sie vorher kennt, hat eine langweilige Infrastruktur statt einer schlechten Nacht. Hier sind die häufigsten, jeweils mit der Lösung.

Der ZFS-ARC frisst unbemerkt den Gast-RAM

Der klassische Proxmox-auf-ZFS-Vorfall: VMs beginnen zu swappen oder werden vom OOM-Killer beendet, auf einem Host, der „reichlich RAM hat“, weil der In-Memory-Cache von ZFS (der ARC) ihn vollständig belegt hat. ZFS betrachtet freien RAM als Freiwild für den Cache, und bei Konkurrenz kämpfen der ARC und die Speicherzuweisungen Ihrer Gäste gegeneinander.

Das ist nicht hypothetisch: Die Proxmox-Foren sind voll davon. In einem typischen Thread hatte ein Host mit 64 GB unter Proxmox 8.1.4 einen ARC von fast 32 GB; ein Stammnutzer des Forums rechnete es so vor: „ZFS nimmt 32GB, die VM 16.5GB, Proxmox nimmt 2GB, das ergibt zusammen 80%“, und der OOM-Killer beendete prompt die Windows-Server-VM mit 16 GB, die sich nur durch einen Neustart über IPMI zurückholen ließ. In einem anderen hatte ein Host mit 32 GB den ARC bei 15.5 GiB (99.7%) festgefahren und beendete immer wieder einen Windows-Gast per OOM-Killer, obwohl seine VMs zusammen nur ~8 GB anforderten. Beide Male dieselbe Ursache: Der ARC stand auf dem alten ZFS-Standard von etwa der Hälfte des Host-RAMs.

Neuere Proxmox-Versionen entschärfen das: Seit PVE 8.1 begrenzt der Installer den ARC auf 10% des Host-RAMs, höchstens 16 GiB, während er vor 8.1 dem ZFS-eigenen Standard von 50% folgte (62.5% ab ZFS 2.3.0). Hosts, die mit älteren Versionen installiert, direkt aktualisiert oder von Hand aufgebaut wurden, können aber weiterhin mit dem alten Standard laufen. Die Lösung ist eine explizite Einstellung: Setzen Sie zfs_arc_max (in Bytes) in /etc/modprobe.d/zfs.conf und bauen Sie das initramfs neu. So begrenzen Sie den ARC auf 8 GiB:

# 8 GiB in bytes
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u -k all
reboot

Ein dokumentierter Stolperstein: Liegt Ihr gewähltes zfs_arc_max auf oder unter zfs_arc_min, senken Sie auch zfs_arc_min, sonst greift die Änderung nicht. Die dokumentierte Faustregel lautet etwa 2 GiB Basis plus ~1 GiB ARC pro TiB Pool, der Rest bleibt für die Gäste. Die eigentliche Lehre: Prüfen Sie arc_summary auf jedem Host, den Sie übernehmen, statt anzunehmen, dass die Grenze gesetzt ist. Im Fall mit 64 GB entschied sich der Betreiber für eine Grenze von 24 GiB; im Fall mit 32 GB brachte eine Grenze von 4 GiB den Host zurück auf stabile ~70% Speicherauslastung.

Cluster mit zwei Nodes brauchen ein QDevice für das Quorum

Ein Cluster mit zwei Nodes fühlt sich nach HA an und ist keins. Proxmox-Clustering nutzt corosync, das eine Mehrheit der Stimmen braucht, um das Quorum zu halten; fällt bei zwei Nodes einer aus, hat der verbleibende eine von zwei Stimmen (keine Mehrheit) und trifft keine Cluster-Entscheidungen mehr, um Split-Brain zu vermeiden. Teams merken das genau dann, wenn es am wenigsten passt: Ein Node fällt aus, und der „Cluster“ blockiert.

Die Lösung ist entweder ein echter Cluster mit drei Nodes oder ein Corosync QDevice, ein schlanker externer Daemon (er kann auf einer kleinen VM oder sogar auf einem Raspberry Pi nebenher laufen), der eine dritte, entscheidende Stimme abgibt. Treffen Sie diese Entscheidung, bevor der zweite Node in Produktion geht, nicht danach.

Ceph auf zu wenigen Nodes oder zu wenig Netzwerk

Ceph ist hervorragend und verzeiht keine Unterdimensionierung. Proxmox selbst empfiehlt mindestens 3 Nodes (5 für die Produktion) und ein eigenes Netzwerk mit mindestens 10 Gbps, 25 Gbps+ sobald NVMe im Spiel ist. Betreiben Sie Ceph auf zwei Nodes oder über eine geteilte 1-Gbps-Verbindung, bekommen Sie genau die Enttäuschung, die man erwartet: Hänger während der Wiederherstellung, Latenzspitzen und ein Rebuild, der dieselbe Verbindung sättigt, die Ihre VMs nutzen wollen. Fehlen Ihnen Node-Zahl und Netzwerk für Ceph, nehmen Sie ZFS mit Replikation. Es ist das richtige Werkzeug für zwei oder drei Nodes.

Live-Migration: realistische Erwartungen

Live-Migration funktioniert in Proxmox gut, aber zwei Werte werden oft verwechselt: die Umschalt-Downtime (die kurze Pause, in der der letzte geänderte Speicher und der CPU-Zustand übergeben werden) und die Gesamtdauer der Migration (wie lange die ganze Übertragung dauert). Sie verhalten sich unterschiedlich, und die Proxmox-Foren sind voller echter Task-Logs, die zeigen, wie. Proxmox zielt auf eine maximale Umschalt-Downtime von standardmäßig 100 ms, die nur automatisch ansteigt (200 ms, 400 ms, …), wenn der Gast RAM schneller verändert, als die Verbindung ihn abtragen kann. Auf geteiltem oder schnellem Storage liegt die gemessene Umschaltzeit fast unabhängig von der VM-Größe im Bereich von einigen zehn bis wenigen hundert Millisekunden. Hier echte Werte, die Betreiber aus ihren eigenen Migrationen gepostet haben:

Aus diesen Logs ergeben sich zwei Lehren für den Betrieb. Erstens: Bei einer sauber laufenden Migration ist die Umschalt-Downtime weitgehend unabhängig von RAM-Größe und Verbindungsgeschwindigkeit; mit RAM ÷ Durchsatz skaliert die Gesamtdauer. Zweitens: Was die Gesamtdauer am stärksten verschlechtert, ist nicht das Netzwerk, sondern der SSH-Verschlüsselungstunnel: Er hängt an einem einzelnen Core und begrenzt den Durchsatz regelmäßig weit unter die Leistung der Netzwerkkarte. In einem Fall mit einer 32-GB-VM auf einer 40-Gbps-Ceph-Verbindung dauerte die standardmäßige sichere Migration über 20 Minuten; mit migration: insecure im vertrauenswürdigen Cluster-Netzwerk sank sie auf 30 Sekunden. Und seien Sie ehrlich beim Wort „Downtime“: Der protokollierte Wert ist die Stop/Copy-Pause von QEMU, und echte Zero-Downtime gibt es nicht; eine Umschaltung unter einer Sekunde auf geteiltem Storage ist das realistische Ziel, nicht null. Nichts davon ist ein Fehler von Proxmox; es ist die Art Detail, die ein Homelab-Test nie zeigt und die ein Flottenbetreiber einplant.

Kosten: pro Node, nicht pro Arbeitsplatz

Homelab- und Pro-Arbeitsplatz-Betrachtungen verdecken, worauf es einem Betreiber ankommt: die laufende Rechnung pro physischem Node. Die beiden Modelle könnten in ihrer Form kaum unterschiedlicher sein, und genau um diese Form geht es.

Proxmox ist unter der AGPLv3 kostenlos in Produktion nutzbar; das Abonnement ist optional und wird pro CPU-Sockel und Jahr berechnet, allein für das stabile Enterprise-Repository und Support. Laut Preisseite von Proxmox (Juli 2026, netto, EUR): Community 120 €, Basic 370 €, Standard 550 €, Premium 1.100 €, pro Sockel und Jahr. Auf einem Dual-Socket-Node sind das 0 € (No-Subscription-Repository) bis 2.200 €/Jahr in der höchsten Stufe.

VMware ist ein Abonnement pro physischem Core mit dem Minimum von 16 Cores/CPU. Broadcom veröffentlicht keine öffentliche Preisliste, daher ist jede Zahl eine datierte Schätzung Dritter, aber das Modell spricht für sich. Ein Dual-Socket-Node mit 32 Cores pro Sockel hat 64 lizenzpflichtige Cores, jedes Jahr berechnet. Die am besten belegte Zahl betrifft VCF: Ein VP von Broadcom beschrieb beim Relaunch im Juni 2024, man habe den Preis „von $700 pro Core und Jahr auf $350“ gesenkt. Diese „Senkung“ führt in die Irre, denn das VCF für $350 bündelt jetzt NSX, vSAN und Aria und ist für viele Kunden Pflicht, sodass es für die meisten unterm Strich eine Erhöhung war, keine Ersparnis. Für das Mittelstands-Bundle VVF setzen Reseller-Rechnungen für 2026 die Marktspanne bei $150 bis $190 pro Core und Jahr an, gegenüber dem Durchschnitt von ~$135, der noch aus dem Relaunch zitiert wird.

Lassen Sie sich die Zahlen von einem Reseller bestätigen: Die folgenden Werte sind datierte Schätzungen Dritter (Juli 2026), keine von Broadcom veröffentlichten Preise.

Die VMware-Werte fallen jährlich und wiederkehrend an; die Proxmox-Spalte ist eine optionale pauschale Supportgebühr (oder null mit dem No-Subscription-Repository). Bei einer kleinen Flotte wächst der Abstand jedes Jahr weiter.

Zum Thema Backup: Proxmox Backup Server ist kostenlos und Open Source, mit clientseitig inkrementellen und serverseitig deduplizierten Backups von VMs, Containern und physischen Hosts. Veeam ist ausgezeichnet und unterstützt Proxmox VE inzwischen als vollwertige Plattform (eingeführt in Backup & Replication 12.2, 2024), ist aber ein zusätzliches Abonnement pro Workload. Wenn Ihr Backup-Posten ins Gewicht fällt, verschiebt PBS die Rechnung noch einmal zugunsten von Proxmox.

Ehrlich zusammengefasst: Bei einer kleinen Flotte sind die Kosten pro Node bei Proxmox eine pauschale, optionale Supportgebühr (oder null), bei VMware ein verpflichtendes, wiederkehrendes Abonnement pro Core, das mit Ihrer Core-Zahl wächst. Mit den heutigen CPUs mit vielen Cores ist dieser Abstand groß und wächst jedes Jahr.

Wann ESXi weiterhin die richtige Wahl ist

Zur Glaubwürdigkeit gehört, zu sagen, wo der etablierte Anbieter gewinnt, und an einigen Stellen tut er das:

• Sie betreiben (und nutzen) bereits den vollständigen vSphere-Stack. Wenn DRS, vSAN, NSX und die vCenter-Automatisierung tragende Teile Ihres Betriebs sind und Ihr Team vSphere im Schlaf beherrscht, kann der Ausstieg zum Sparen von Lizenzen mehr kosten, als er einspart.
• Eine Herstellerzertifizierung oder Appliance setzt ESXi voraus. Manche Enterprise-Software und virtuelle Appliances sind nur auf vSphere zertifiziert oder unterstützt. Hängt ein Supportvertrag daran, ist die Frage entschieden.
• Ein auditierter Unternehmensprozess ist um vCenter herum aufgebaut. Change Control, RBAC und Compliance-Tools, die an vCenter angebunden sind, bedeuten echte Wechselkosten. Eine Migration muss das berücksichtigen.
• Sie haben bereits in vSAN investiert und ein Betriebsmodell darum herum, das Sie noch nicht auf Ceph neu aufbauen wollen.

Keiner dieser Fälle beschreibt den typischen Mieter eines Dedicated Servers oder eine kleine Hosting-Flotte, aber wenn einer auf Sie zutrifft: Die Reife von ESXi ist real, und ESXi ist nicht verschwunden.

Migration von ESXi zu Proxmox in Kurzform

Seit Version 8.2 liefert Proxmox VE einen integrierten Import-Assistenten für VMware-Gäste mit: Sie fügen den ESXi-Host (oder vCenter) als Import-Storage unter Datacenter → Storage → Add → ESXi hinzu und holen die VMs dann herüber. Er spricht direkt mit der ESXi-API, unterstützt ESXi 6.5–8.0 und bietet einen „Live-Import“-Modus, der die VM früh startet und den Rest im Hintergrund kopiert. Zwei Vorbehalte aus echten Migrationen sollten Sie vorher kennen:

• Er ist nicht schnell, und vSAN wird nicht unterstützt. Der Importer geht über die VMware-API, die drosselt; Forennutzer berichten von Durchsätzen von nur ~30 MB/s über vCenter, und manche umgehen den Assistenten bei großen VMs und schieben sie per NFS-Storage-vMotion hinüber. VMs auf vSAN kann der Assistent überhaupt nicht importieren.
• Windows-Gäste brauchen eine VirtIO-Vorbereitung, sonst starten sie nicht. Importieren Sie eine Windows-Bootplatte direkt auf einen VirtIO-SCSI-Controller, stürzt sie mit INACCESSIBLE_BOOT_DEVICE ab (Stop-Code 0x7B), weil Windows keinen VirtIO-Storage-Treiber geladen hat. Die dokumentierte Lösung: Den Gast zuerst über SATA/IDE starten, die virtio-win-Treiber installieren und dann die Bootplatte auf VirtIO SCSI umstellen, oder im Assistenten die Option „Prepare for VirtIO-SCSI“ anhaken und die VirtIO-Treiber am besten schon installieren, solange die VM noch auf ESXi läuft.

Eine vollständige Schritt-für-Schritt-Anleitung ist ein eigenes Thema; entscheidend ist hier, dass die Migration ein gelöster, dokumentierter Weg ist (das offizielle Proxmox-Migrations-Wiki beschreibt ihn von Anfang bis Ende) und kein Neuaufbau von Grund auf.

Das Urteil, mit Bedingungen

• Wählen Sie Proxmox VE, wenn Sie einen Single-Tenant-Dedicated-Server oder einen kleinen Cluster betreiben, KVM-VMs und LXC-Container auf einem Host wollen, ZFS/Ceph-Storage und eine kostenlose REST-API schätzen und lieber eine pauschale, optionale Supportgebühr pro Sockel zahlen als ein verpflichtendes Abonnement pro Core. Für die Zielgruppe dieses Artikels ist das der Standard.
• Wählen Sie kostenpflichtiges VMware vSphere, wenn Sie bereits auf DRS/vSAN/NSX/vCenter festgelegt sind und diese aktiv nutzen, von einer bestimmten ISV-Zertifizierung abhängen oder einen auditierten Prozess rund um vCenter haben und das Abonnement pro Core tragen können.
• Wählen Sie das kostenlose ESXi nur, wenn Sie einen einzelnen, unverwalteten, ungesicherten Labor-Host wollen und mit 8 vCPUs pro VM, zwei Sockeln und ohne Backup-API leben können. Es ist ein Homelab-Produkt, kein Serverprodukt.

Wenn Sie diese Entscheidung abwägen, behandelt unser Begleitartikel dazu, was ein Bare-Metal-Hypervisor ist und wie die vier wichtigsten Plattformen im Vergleich abschneiden, auch XCP-ng und Hyper-V, und unsere Schritt-für-Schritt-Anleitung zur Einrichtung von Proxmox VE führt durch die Installation ab einer leeren Platte. Wenn Sie eher den Umzug aus einer nutzungsabhängig abgerechneten Public Cloud planen als den Abschied von VMware-Lizenzen, deckt unser Leitfaden zur Cloud-Migration Lift-and-Shift und die Modernisierung von Datenbanken ab.

Häufig gestellte Fragen

Ist Proxmox VE produktionsreif?

Ja. Es steht unter AGPLv3 ohne Begrenzung bei Funktionen, VMs oder Nodes, erscheint seit Jahren in einem vorhersehbaren Rhythmus und ist das häufigste Ziel von Teams, die VMware verlassen. Die aktuelle Version ist Proxmox VE 9.2 (Mai 2026) auf Basis von Debian 13 „Trixie“. Die Vorbehalte betreffen den Betrieb, nicht die Reife: Dimensionieren Sie den ZFS-ARC, betreiben Sie kein HA mit zwei Nodes ohne QDevice, und geben Sie Ceph die Nodes und das Netzwerk, die es braucht.

Kann Proxmox vCenter ersetzen?

Für die meisten Betreiber ja: Die Management-Ebene von Proxmox (Weboberfläche plus REST-API) steckt in jedem Node und bildet nativ Cluster, es gibt also keine separate Management-Appliance, die wie vCenter lizenziert werden muss. Was sie nicht eins zu eins ersetzt, ist der DRS/NSX/vSAN-Funktionsumfang einer vollständigen vSphere-Umgebung; wenn diese Funktionen zentral für Ihren Betrieb sind, ist das die Lücke, die Sie abwägen müssen.

Kommt das kostenlose ESXi zurück, oder ist es schon wieder da?

Es ist wieder da. Broadcom hat das kostenlose ESXi mit Build 8.0 Update 3e im April 2025 wieder eingeführt. Es ist aber auf 8 vCPUs pro VM und zwei physische Sockel begrenzt, lässt sich nicht über vCenter verwalten und bietet nur eine schreibgeschützte API, sodass Backup-Tools von Drittanbietern seine VMs nicht sichern können. Es taugt für ein Labor, nicht für einen gesicherten Produktionsserver. Stand Mitte 2026 gibt es kein kostenloses ESXi 9.

Wie viele Nodes braucht ein Proxmox-Cluster mindestens?

Einen einzelnen Node können Sie dauerhaft betreiben. Für verlässliche Hochverfügbarkeit brauchen Sie drei Nodes, damit corosync immer eine Stimmenmehrheit hat. Zwei Nodes können einen Cluster bilden, halten aber kein Quorum, wenn einer ausfällt. Haben Sie nur zwei, ergänzen Sie ein QDevice als externen Tie-Breaker. Ceph verlangt mindestens drei Nodes und fünf für die Produktion.

Proxmox VE auf Serverside.com bereitstellen

Proxmox braucht Bare Metal, und genau dafür ist dieses Angebot da. Serverside.com stellt Proxmox VE 9.2 als fertiges Image in unter einer Minute auf Single-Tenant-Hardware bereit; voller Root-Zugriff auf die ganze Maschine, sodass Repository-Wahl, Storage-Layout und Cluster-Konfiguration bei Ihnen liegen. Die Hardware passt direkt dazu: AMD EPYC mit vielen Cores und ECC-DDR5 für dicht belegte VM- und Container-Hosts, und schnelles Netzwerk für die bandbreitenhungrige Arbeit, in der Proxmox stark ist: Ceph und ZFS-Replikation zwischen Nodes. Permanente DDoS-Mitigation in unserem Netzwerk ASN 55285 schützt die Management-Ebene ebenso wie Ihre Gäste.

Bereit für den Aufbau? Sehen Sie sich unsere Proxmox VE Dedicated Server an, um das fertige Image bereitzustellen, oder das gesamte Dedicated-Server-Angebot. Da Proxmox auf Debian basiert, behandeln unsere Seiten zu Debian und Ubuntu das zugrunde liegende Betriebssystem, falls Sie den Host lieber selbst aufbauen. Ganz neu im Thema? Beginnen Sie mit unserer Anleitung zur Einrichtung von Proxmox VE.