Proxmox VE vs VMware ESXi in 2026: de blik van de dedicated-serverbeheerder

Het korte antwoord

Voor een single-tenant dedicated server of een klein cluster in 2026 geldt: Proxmox VE is de standaard, en VMware ESXi is alleen te verdedigen als je al betaalt voor (en gebruikmaakt van) de volledige vSphere-stack. Dat is een stelligere uitspraak dan de meeste vergelijkingen durven te doen, dus de rest van dit artikel onderbouwt haar: wat de licentiewijziging van Broadcom deed, wat de teruggekeerde gratis ESXi wel en niet kan, de architectuurverschillen die specifiek op bare metal tellen, de storingen in clusters met meerdere nodes die in productie pijn doen, en een eerlijke kostenberekening per node.

Waarom je dit eerder kunt vertrouwen dan het gemiddelde overzicht: de meeste content over Proxmox vs ESXi is geschreven voor homelabs (geoptimaliseerd voor een mini-pc) of door back-upleveranciers (functielijstjes die eindigen met "en hier is ons product"). Wie een dedicated server beheert, werkt met andere randvoorwaarden (herstel gaat alleen via IPMI, de hardware is single-tenant, er is geen SAN en het netwerk wordt op de host ingesteld), en die randvoorwaarden veranderen het antwoord.

Wat er veranderde: Broadcom, en de ESXi die terugkwam

Twee dingen hebben deze vergelijking op nul gezet, en je hebt ze allebei nodig om erover te redeneren.

De licentiewijziging. Sinds de overname van VMware door Broadcom zijn eeuwigdurende licenties verdwenen en is alles een abonnement, gelicentieerd per fysieke core, met een minimum van 16 cores per CPU dat ook wordt gerekend op CPU's met minder cores. De oude losse SKU's zijn opgegaan in twee bundels: VMware vSphere Foundation (VVF) voor het middensegment en de grotere VMware Cloud Foundation (VCF) voor een volledige private cloud (VCF voegt NSX, SDDC Manager en 4× de meegeleverde vSAN-capaciteit toe). In 2025 was er ook een veelbesproken minimum van 72 cores per bestelling; de huidige status daarvan is onduidelijk (sommige kanalen melden dat het na protest is teruggedraaid, andere noemen het nog steeds), dus behandel het als "vraag het je reseller", niet als vaste regel. Voor een kleine beheerder met moderne CPU's met veel cores duwen het per-coremodel en de abonnementsondergrens de jaarlijkse kosten ver boven wat een licentie voor dezelfde hardware vroeger kostte.

Gratis ESXi is terug, maar lees de beperkingen. Broadcom bracht in april 2025 opnieuw een gratis ESXi uit met versie 8.0 Update 3e. Daarmee kwam de vraag "moet ik gewoon terug naar gratis ESXi?" weer op tafel, dus hier zijn de gedocumenteerde beperkingen, rechtstreeks uit de KB van Broadcom:

• 8 vCPU's per virtuele machine. Niet 8 in totaal, maar 8 per VM. Een enkele databasegast met 16 vCPU's valt af.
• Maximaal 2 fysieke CPU's (sockets) per host. Dit is een limiet op sockets, niet op VM's.
• De beheer-API's zijn read-only. Deze weegt het zwaarst: back-uptools van derden (Veeam en consorten) hebben API's met schrijfrechten nodig (VADP), dus je kunt VM's op gratis ESXi daarmee niet back-uppen. Ook vMotion, DRS en HA ontbreken.
• Het kan niet via vCenter beheerd worden, en er is geen support of SLA.

Samen maken die beperkingen gratis ESXi prima voor een testomgeving of één geïsoleerde host, en ongeschikt als basis voor een beheerde productieserver met back-ups, vooral op een moderne dual-socketmachine met 32+ cores per socket, waar de grens van 8 vCPU's per VM en het ontbreken van een back-up-API meteen knellen. Medio 2026 is de gratis build nog steeds 8.0U3e; vSphere 9 bestaat, maar er is geen gratis ESXi 9. "Gratis ESXi is terug" klopt dus, en doet er voor een productieserver weinig toe.

Architectuur, waar die op bare metal telt

Tabellen die functie tegen functie zetten, missen wat er verschilt als de hele machine van jou is. Vier dingen doen dat wel.

Hypervisormodel: KVM + LXC vs een pure Type-1. Proxmox VE draait zowel volledige KVM-VM's als LXC-systeemcontainers vanuit één interface; ESXi is een pure Type-1-hypervisor die alleen VM's draait. Op één volgepakte machine scheelt dat verschil geld: LXC-containers delen de kernel van de host, dus je past veel meer Linux-only workloads op dezelfde hardware dan als volledige VM's, terwijl je VM's houdt voor alles wat een eigen kernel of een harde isolatiegrens nodig heeft.

Opslag: software-defined vs de VMware-stack. Proxmox levert standaard ZFS (lokaal, met snapshots, checksums en replicatie), Ceph RBD (gedistribueerd, hyperconverged) en LVM-thin, plus directory, NFS en iSCSI. VMware biedt VMFS op blockstorage en vSAN, en in de huidige bundels wordt vSAN-capaciteit binnen de licentie per core afgemeten. Op een dedicated server met lokale NVMe en zonder SAN past ZFS op één node of Ceph over een paar nodes het best, en dat zit erbij in plaats van per terabyte gelicentieerd te worden.

Netwerk: Linux op de host. Netwerken in Proxmox bestaat standaard uit Linux-bridges, met Open vSwitch en een SDN-framework als optie; je stelt het in via /etc/network/interfaces zoals op elke Linux-machine, en dat is precies wat een dedicated-serverbeheerder al doet. VMware gebruikt standaard- en distributed vSwitches, met NSX alleen in de VCF-bundel. Als je herstelroute een IPMI-console is, is "het is gewoon Linux-netwerken" een tastbaar voordeel.

API en automatisering. Proxmox levert bij elke installatie een volledige REST API mee (HTTPS op 8006, pvesh, API-tokens), gratis. De automatiseringslaag van vSphere zit achter vCenter en een betaalde licentie, en de API van gratis ESXi is read-only, dus de gratis variant heeft helemaal geen bruikbare automatiserings- of back-up-API. Stuur je je infrastructuur aan met Terraform of Ansible, dan is Proxmox vanaf dag één kosteloos te automatiseren.

De praktijk van het beheer: wat geen functietabel laat zien

Hier wijkt de ervaring van een productiebeheerder af van een homelabreview. Proxmox is uitstekend, maar heeft scherpe randjes die pas opduiken bij meerdere nodes en onder geheugendruk. Wie ze vooraf kent, houdt saaie infrastructuur over in plaats van een slechte nacht. Dit zijn de problemen die het vaakst toeslaan, met de oplossing erbij.

ZFS ARC die ongemerkt het RAM van gasten opslokt

Het klassieke incident met Proxmox op ZFS: VM's gaan swappen of worden door de OOM-killer afgeschoten op een host die "RAM genoeg heeft", omdat de geheugencache van ZFS (de ARC) is gegroeid tot hij alles vult. ZFS ziet vrij RAM als vrij spel voor cache, en bij krapte vechten de ARC en de geheugentoewijzingen van je gasten om dezelfde ruimte.

Dit is geen theorie: de Proxmox-forums staan er vol mee. In een typische thread had een host met 64 GB op Proxmox 8.1.4 een ARC van bijna 32 GB; een vaste forumgebruiker telde het zo op: "ZFS neemt 32GB, de VM 16.5GB, Proxmox neemt 2GB, samen 80%", en de OOM-killer beëindigde prompt de Windows Server-VM van 16 GB, die alleen met een herstart via IPMI terug te halen was. In een andere thread zat de ARC op een host met 32 GB vast op 15.5 GiB (99.7%) en schoot hij steeds een Windows-gast af, terwijl de VM's samen maar ~8 GB vroegen. Beide keren dezelfde oorzaak: de ARC stond nog op de oude ZFS-standaard van ongeveer de helft van het RAM van de host.

Nieuwere Proxmox-versies beperken dit: sinds PVE 8.1 zet de installer de ARC op 10% van het RAM van de host, met een maximum van 16 GiB, terwijl hij vóór 8.1 de eigen ZFS-standaard van 50% volgde (62.5% vanaf ZFS 2.3.0). Hosts die op oudere versies zijn geïnstalleerd, ter plekke zijn geüpgraded of met de hand zijn opgebouwd, kunnen nog op die oude standaard draaien. De oplossing is een expliciete instelling: zet zfs_arc_max (in bytes) in /etc/modprobe.d/zfs.conf en bouw de initramfs opnieuw. Om de ARC op 8 GiB te begrenzen:

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

Eén gedocumenteerde valkuil: ligt de gekozen zfs_arc_max op of onder zfs_arc_min, verlaag dan ook zfs_arc_min, anders wordt de wijziging niet toegepast. De gedocumenteerde vuistregel is ongeveer 2 GiB basis plus ~1 GiB ARC per TiB pool, de rest laat je over voor de gasten. De eigenlijke les: controleer arc_summary op elke host die je overneemt in plaats van aan te nemen dat de grens is ingesteld. In het geval met 64 GB koos de beheerder voor een grens van 24 GiB; in het geval met 32 GB bracht een grens van 4 GiB de host terug naar een stabiel geheugengebruik van ~70%.

Clusters met twee nodes hebben een QDevice nodig voor quorum

Een cluster met twee nodes voelt als HA, maar is het niet. Proxmox-clustering gebruikt corosync, dat een meerderheid van stemmen nodig heeft om quorum te houden; valt bij twee nodes er één weg, dan heeft de overgebleven node één van de twee stemmen (geen meerderheid) en neemt hij geen clusterbeslissingen meer, om split-brain te voorkomen. Teams ontdekken dit precies op het slechtst denkbare moment: één node valt uit en het "cluster" loopt vast.

De oplossing is een volwaardig cluster met drie nodes of een Corosync QDevice, een lichte externe daemon (die kan draaien op een kleine VM of zelfs op een Raspberry Pi ernaast) die een derde, beslissende stem uitbrengt. Neem die beslissing voordat de tweede node in productie gaat, niet erna.

Ceph op te weinig nodes of met te weinig netwerk

Ceph is uitstekend en vergeeft geen onderdimensionering. Proxmox adviseert zelf minimaal 3 nodes (5 voor productie) en een apart netwerk van minimaal 10 Gbps, 25 Gbps+ zodra je op NVMe draait. Draai je Ceph op twee nodes, of over een gedeelde 1 Gbps-verbinding, dan krijg je precies de teleurstelling die je kunt verwachten: haperingen tijdens herstel, latentiepieken en een rebuild die dezelfde verbinding verzadigt die je VM's willen gebruiken. Heb je het aantal nodes en het netwerk voor Ceph niet, gebruik dan ZFS met replicatie. Dat is het juiste gereedschap voor twee of drie nodes.

Live migratie: realistische verwachtingen

Live migratie werkt goed op Proxmox, maar twee getallen lopen vaak door elkaar: de downtime bij het omschakelen (de korte pauze waarin het laatste gewijzigde geheugen en de CPU-status worden overgedragen) en de totale migratietijd (hoe lang de hele overdracht duurt). Ze gedragen zich verschillend, en de Proxmox-forums staan vol echte takenlogs die laten zien hoe. Proxmox mikt op een standaard maximale omschakel-downtime van 100 ms, die alleen automatisch oploopt (200 ms, 400 ms, …) als de gast sneller RAM wijzigt dan de verbinding kan wegwerken. Op gedeelde of snelle opslag ligt de gemeten omschakeltijd bijna los van de VM-grootte tussen enkele tientallen en enkele honderden milliseconden. Dit zijn echte waarden die beheerders uit hun eigen migraties hebben geplakt:

Uit die logs volgen twee lessen voor beheerders. Ten eerste: bij een migratie die goed verloopt, staat de omschakel-downtime vrijwel los van de RAM-grootte en de verbindingssnelheid; het is de totale tijd die meeschaalt met RAM ÷ doorvoer. Ten tweede: wat de totale tijd het meest verpest, is niet het netwerk maar de SSH-versleutelingstunnel: die is gebonden aan één core en houdt de doorvoer geregeld ver onder wat de netwerkkaart aankan. In een geval met een VM van 32 GB op een Ceph-verbinding van 40 Gbps duurde de standaard beveiligde migratie meer dan 20 minuten; met migration: insecure op het vertrouwde clusternetwerk zakte dat naar 30 seconden. En wees eerlijk over het woord "downtime": de gelogde waarde is de stop/copy-pauze van QEMU, en echte zero-downtime bestaat niet; omschakelen binnen een seconde op gedeelde opslag is het realistische doel, niet nul. Niets hiervan is een fout van Proxmox; het is het soort detail dat een homelabreview nooit boven water haalt en waar een vlootbeheerder omheen plant.

Kosten: per node, niet per gebruiker

Een homelabblik of een prijs per gebruiker verbergt waar een beheerder om geeft: de terugkerende rekening per fysieke node. De twee modellen verschillen fundamenteel van vorm, en om die vorm draait het.

Proxmox is onder de AGPLv3 gratis in productie te gebruiken; het abonnement is optioneel en geprijsd per CPU-socket per jaar, puur voor de stabiele enterprise-repository en support. Volgens de prijspagina van Proxmox (juli 2026, exclusief btw, EUR): Community € 120, Basic € 370, Standard € 550, Premium € 1.100, per socket per jaar. Op een dual-socketnode is dat € 0 (no-subscription-repository) tot € 2.200 per jaar in het hoogste niveau.

VMware is een abonnement per fysieke core met het minimum van 16 cores per CPU. Broadcom publiceert geen openbare prijslijst, dus elk bedrag is een gedateerde schatting van derden, maar het model zegt genoeg. Een dual-socketnode met 32 cores per socket heeft 64 licentieplichtige cores, elk jaar opnieuw gefactureerd. Het best onderbouwde getal is dat van VCF: een VP van Broadcom beschreef bij de herlancering in juni 2024 dat de prijs was verlaagd "van $700 per core per jaar naar $350". Die "verlaging" is misleidend, want de VCF van $350 bundelt nu NSX, vSAN en Aria en is voor veel klanten verplicht, dus voor de meesten kwam het neer op een verhoging, geen besparing. Voor de middensegmentbundel VVF plaatst resellerrekenwerk voor 2026 de marktprijs tussen $150 en $190 per core per jaar, tegenover het gemiddelde van ~$135 dat nog vanuit de herlancering wordt aangehaald.

Laat een reseller de prijs bevestigen: onderstaande bedragen zijn gedateerde schattingen van derden (juli 2026), geen door Broadcom gepubliceerde prijzen.

Die VMware-bedragen zijn jaarlijks en terugkerend; de Proxmox-kolom is een optionele vaste supportvergoeding (of nul met de no-subscription-repository). Bij een kleine vloot loopt het verschil elk jaar verder op.

Over back-ups: Proxmox Backup Server is gratis en open source, met incrementele back-ups aan de clientkant en deduplicatie aan de serverkant voor VM's, containers en fysieke hosts. Veeam is uitstekend en ondersteunt Proxmox VE inmiddels als volwaardig platform (toegevoegd in Backup & Replication 12.2, 2024), maar is een extra abonnement per workload. Telt je back-uppost mee, dan verschuift PBS de rekensom nog eens in het voordeel van Proxmox.

Eerlijk samengevat: bij een kleine vloot zijn de kosten per node bij Proxmox een vaste, optionele supportvergoeding (of nul), en bij VMware een verplicht, terugkerend abonnement per core dat meegroeit met je aantal cores. Met de huidige CPU's met veel cores is dat verschil groot, en het loopt elk jaar op.

Wanneer ESXi nog de juiste keuze is

Geloofwaardigheid vraagt dat je zegt waar de gevestigde speler wint, en op een paar punten doet hij dat:

• Je draait (en gebruikt) de volledige vSphere-stack al. Zijn DRS, vSAN, NSX en de automatisering van vCenter dragende onderdelen van je beheer en kent je team vSphere op de automatische piloot, dan kan eruit stappen om op licenties te besparen meer kosten dan het oplevert.
• Een leverancierscertificering of appliance vereist ESXi. Sommige enterprisesoftware en virtuele appliances zijn alleen op vSphere gecertificeerd of ondersteund. Hangt een supportcontract daarvan af, dan is de keuze gemaakt.
• Een geaudit bedrijfsproces is rond vCenter opgebouwd. Change control, RBAC en compliancetools die in vCenter zijn ingebed, vormen echte overstapkosten. Een migratie moet daar rekening mee houden.
• Je hebt al geïnvesteerd in vSAN en het beheermodel eromheen, en je bent nog niet klaar om dat op Ceph opnieuw op te bouwen.

Geen van deze gevallen beschrijft de typische huurder van een dedicated server of een kleine hostingvloot, maar past er één op jou, dan is de volwassenheid van ESXi echt en is ESXi nergens heen.

Migreren van ESXi naar Proxmox, in het kort

Sinds versie 8.2 levert Proxmox VE een ingebouwde importwizard voor VMware-gasten: je voegt de ESXi-host (of vCenter) toe als importbron onder Datacenter → Storage → Add → ESXi en haalt daarna de VM's over. De wizard praat rechtstreeks met de ESXi-API, ondersteunt ESXi 6.5–8.0 en biedt een modus voor "live import" die de VM vroeg opstart en de rest op de achtergrond kopieert. Twee kanttekeningen uit echte migraties kun je beter vooraf kennen:

• Hij is niet snel, en vSAN wordt niet ondersteund. De importer loopt via de API van VMware, die de snelheid begrenst; forumgebruikers melden doorvoer van slechts ~30 MB/s via vCenter, en sommigen slaan de wizard bij grote VM's over en duwen ze via NFS met Storage vMotion over. VM's op vSAN kan de wizard helemaal niet importeren.
• Windows-gasten hebben VirtIO-voorbereiding nodig, anders starten ze niet. Importeer je een Windows-bootschijf direct op een VirtIO SCSI-controller, dan krijg je een blauw scherm met INACCESSIBLE_BOOT_DEVICE (stopcode 0x7B), omdat Windows geen VirtIO-opslagdriver heeft geladen. De gedocumenteerde oplossing: start de gast eerst op SATA/IDE, installeer de virtio-win-drivers en zet daarna de bootschijf om naar VirtIO SCSI, of vink in de wizard "Prepare for VirtIO-SCSI" aan, en installeer de VirtIO-drivers bij voorkeur al terwijl de VM nog op ESXi draait.

Een volledige stap-voor-stapuitleg is een eigen gids; waar het hier om gaat, is dat de migratie een opgelost, gedocumenteerd traject is (de officiële Proxmox-migratiewiki loopt het van begin tot eind door) en geen herbouw vanaf nul.

Het oordeel, met voorwaarden

• Kies Proxmox VE als je een single-tenant dedicated server of een klein cluster draait, KVM-VM's en LXC-containers op één host wilt, ZFS/Ceph-opslag en een gratis REST API waardeert, en liever een vaste, optionele supportvergoeding per socket betaalt dan een verplicht abonnement per core. Voor de doelgroep van dit artikel is dit de standaard.
• Kies betaald VMware vSphere als je al vastzit aan DRS/vSAN/NSX/vCenter en die actief gebruikt, afhankelijk bent van een specifieke ISV-certificering, of een geaudit proces rond vCenter hebt, en het abonnement per core kunt dragen.
• Kies gratis ESXi alleen als je één losse, onbeheerde testhost zonder back-ups wilt en kunt leven met 8 vCPU's per VM, twee sockets en geen back-up-API. Het is een homelabproduct, geen serverproduct.

Weeg je deze beslissing af, dan behandelt onze aanvullende gids over wat een bare-metal hypervisor is en hoe de vier belangrijkste platformen zich verhouden ook XCP-ng en Hyper-V, en loopt onze stap-voor-stapgids voor het opzetten van Proxmox VE de installatie door vanaf een lege schijf. Plan je eigenlijk een verhuizing weg van een public cloud met verbruiksfacturering in plaats van weg van VMware-licenties, dan behandelt onze gids voor cloudmigratie lift-and-shift en het moderniseren van databases.

Veelgestelde vragen

Is Proxmox VE klaar voor productie?

Ja. Het valt onder AGPLv3 zonder limieten op functies, VM's of nodes, verschijnt al jaren in een voorspelbaar ritme en is de meest gekozen bestemming voor teams die VMware verlaten. De huidige release is Proxmox VE 9.2 (mei 2026), gebouwd op Debian 13 "Trixie". De kanttekeningen gaan over beheer, niet over volwassenheid: stel de ZFS ARC goed in, draai geen HA met twee nodes zonder QDevice, en geef Ceph de nodes en het netwerk die het nodig heeft.

Kan Proxmox vCenter vervangen?

Voor de meeste beheerders wel: de beheerlaag van Proxmox (webinterface plus REST API) zit in elke node en vormt zelf clusters, dus er is geen aparte beheerappliance waarvoor je een licentie nodig hebt zoals bij vCenter. Wat het niet één-op-één vervangt, is de specifieke DRS/NSX/vSAN-functionaliteit van een volledige vSphere-omgeving; staan die centraal in hoe je werkt, dan is dat het gat dat je moet afwegen.

Komt gratis ESXi terug, of is het er al?

Het is terug. Broadcom heeft gratis ESXi opnieuw uitgebracht met build 8.0 Update 3e in april 2025. Maar het is beperkt tot 8 vCPU's per VM en twee fysieke sockets, kan niet via vCenter beheerd worden en biedt alleen een read-only API, waardoor back-uptools van derden de VM's niet kunnen beschermen. Het is geschikt voor een testomgeving, niet voor een productieserver met back-ups. Medio 2026 bestaat er geen gratis ESXi 9.

Hoeveel nodes heeft een Proxmox-cluster minimaal nodig?

Eén node kun je onbeperkt draaien. Voor betrouwbare high availability wil je drie nodes, zodat corosync altijd een meerderheid van stemmen heeft. Twee nodes kunnen een cluster vormen, maar houden geen quorum als er één uitvalt. Heb je er maar twee, voeg dan een QDevice toe als externe tiebreaker. Ceph wil minimaal drie nodes en vijf voor productie.

Proxmox VE uitrollen op Serverside.com

Proxmox heeft bare metal nodig, en daar is dit aanbod voor. Serverside.com rolt Proxmox VE 9.2 als kant-en-klare image in minder dan een minuut uit op single-tenant hardware; je krijgt volledige root op de hele machine, dus repositorykeuze, opslagindeling en clusterconfiguratie zijn aan jou. De hardware sluit er direct op aan: AMD EPYC met veel cores en ECC DDR5 voor volle VM- en containerhosts, en snel netwerk voor het bandbreedte-intensieve werk waar Proxmox goed in is: Ceph en ZFS-replicatie tussen nodes. Altijd-actieve DDoS-mitigatie op ons netwerk ASN 55285 staat voor de beheerlaag en je gasten.

Klaar om er een te bouwen? Bekijk onze Proxmox VE dedicated servers om de kant-en-klare image uit te rollen, of het volledige aanbod dedicated servers. Omdat Proxmox op Debian is gebaseerd, behandelen onze pagina's over Debian en Ubuntu het onderliggende besturingssysteem, als je de host liever zelf opbouwt. Helemaal nieuw hierin? Begin met onze Proxmox VE-installatiegids.