LXC-containers vs KVM-VM's in Proxmox: wanneer gebruik je wat

Eerst het antwoord: drie vragen geven de doorslag

Stel voor elke workload de volgende vragen:

1. Heeft het zijn eigen kernel nodig? Een ander besturingssysteem (Windows, BSD), een specifieke kernelversie, kernelmodules, of diepgaande kerneltuning → VM. Containers delen de kernel van de host, punt uit.
2. Hoe sterk moet de isolatie zijn? Onvertrouwde code, scheiding tussen tenants, compliance-grenzen → VM. De grens van hardwarevirtualisatie is categorisch sterker dan namespace-isolatie.
3. Moet je het kunnen verplaatsen zonder het te stoppen? Live migration tussen clusternodes is alleen voor VM's; containers verplaatsen via een stop-en-herstart.

Zijn alle drie de antwoorden "nee" (een vertrouwde, op Linux gebaseerde, herstartbare dienst), dan geeft een LXC-container je dezelfde workload in een fractie van de footprint, en boot hij in ongeveer een seconde. Dat beschrijft veel echte infrastructuur: reverse proxies, DNS, interne tools, per-app service-instanties. Daarom is het praktische Proxmox-patroon gemengd: VM's voor de kroonjuwelen en alles wat vreemd is, containers voor de verzameling kleine Linux-diensten eromheen.

Hoe beide daadwerkelijk werken

Een KVM-virtuele machine is een complete computer in software: QEMU presenteert virtuele hardware, KVM (de hypervisor-module van de kernel) voert guest-code uit met hardwareversnelling, en de guest draait zijn eigen kernel op die hardware, vanaf zijn eigen schijfimage. De host ziet één proces; de guest weet in wezen niet dat hij gevirtualiseerd is (grotendeels: de para-gevirtualiseerde VirtIO-drivers bestaan juist om hem te laten meewerken voor snelheid).

Een LXC-container is geen computer: het is een opgedeeld aanzicht van de kernel van de host. Namespaces geven hem private procesbomen, netwerkstacks en bestandssystemen; cgroups meten zijn CPU- en geheugengebruik. Er is geen tweede kernel, geen virtuele hardware, geen bootproces buiten het starten van init. Daarom start een container binnen een seconde en voegt hij nagenoeg geen overhead per instantie toe, en daarom leeft en sterft elke container op de host met de ene kernel van die host.

Proxmox behandelt beide als eersteklas: dezelfde GUI, dezelfde storage-backends, dezelfde vzdump/PBS-backups, dezelfde firewall- en snapshotworkflow. De verschillen hieronder zijn inherent aan de technologieën, geen beperkingen van Proxmox.

Dichtheid en overhead: de eerlijke versie

Proxmox publiceert geen officieel getal van "X containers per VM-equivalent", en je moet iedereen wantrouwen die dat wel doet: dichtheid hangt volledig af van de workload. Maar het mechanisme is onomstreden en de moeite van het begrijpen waard:

• Elke VM betaalt een vaste tol: zijn eigen kernel en systeemprocessen, plus zijn toegewezen geheugen, dat wordt vastgehouden of de guest het nu gebruikt of niet (ballooning haalt er onvolmaakt een deel van terug). Twintig kleine VM's betekent twintig kernels en twintig geheugenreserveringen.
• Twintig containers delen één kernel en één page cache, en hun cgroup-geheugenlimieten zijn plafonds, geen reserveringen; RAM die een container niet gebruikt, is gewoon vrij RAM voor de host.

Voor CPU-gebonden werk is het verschil in doorvoer klein: de hardwareondersteunde uitvoering van KVM is efficiënt, en een drukke VM is bijna net zo snel als een drukke container. Het verschil zit in de geheugeneconomie en overhead per instantie: op een host met veel kleine diensten vermenigvuldigt containeriseren doorgaans hoeveel ervan passen, minder omdat containers "sneller" zijn dan omdat VM's reserveren wat inactieve diensten nooit gebruiken. Bepaal de grootte van de host in beide gevallen met de virtualisatieregels uit onze sizing guide. RAM is in beide modellen de bindende beperking.

Isolatie: wat "unprivileged" oplevert, en wat niet

Proxmox maakt containers standaard unprivileged aan, en dat moet je zo laten: de root van de container wordt gekoppeld aan een onschadelijke, hoog genummerde UID op de host, dus een volledige compromittering van de container-root brengt de aanvaller in een unprivileged host-account. Gecombineerd met AppArmor, seccomp en cgroups is een unprivileged LXC-container een respectabele grens voor vertrouwde workloads.

Het is nog altijd geen VM-grens. Elke syscall van een container komt direct bij de kernel van de host terecht: het aanvalsoppervlak tussen container en host is de volledige kernelinterface, tegenover de veel smallere hypervisor-interface van een VM. De praktische regels die daaruit volgen:

• Onvertrouwde of aan het internet blootgestelde code met een hoog risico, andere tenants, compliance-gescheiden workloads → VM. Daar dient de sterkere grens voor.
• Privileged containers (niet de standaard) verzwakken het verhaal aanzienlijk: behandel ze als een legacy-noodgreep, niet als een optie. Als een workload een privileged container "nodig heeft", wil hij eigenlijk meestal een VM.
• Containers met nesting ingeschakeld (voor het gemak van Docker en systemd) versoepelen de isolatie verder: prima voor vertrouwde interne diensten, weer een argument tegen gebruik voor iets dat niet vertrouwd wordt.

De Docker-vraag

De meest gestelde versie van deze vergelijking is eigenlijk "waar laat ik mijn Docker-containers draaien?" Proxmox' eigen actuele advies, door de jaren heen afgezwakt maar consistent in richting: draai Docker voor productie (vooral wanneer isolatie of live migration ertoe doen) binnen een VM, niet binnen een LXC-container. Docker-in-LXC (met nesting ingeschakeld) is populair in homelabs omdat het de overhead van een VM overslaat, maar het stapelt twee container-runtimes op één kernel en heeft een geschiedenis van breken bij host-upgrades, het soort kwetsbaarheid dat je in een lab accepteert en in productie betreurt.

Het is de moeite waard om in de gaten te houden terwijl het volwassener wordt: sinds PVE 9.1 kan Proxmox containers direct vanuit OCI-images (het Docker-imageformaat) aanmaken, als technology preview: een image pullen en laten draaien als een door Proxmox beheerde applicatiecontainer, zonder Docker-daemon. Het is oprecht veelbelovend als het uiteindelijke native antwoord, maar "technology preview" betekent precies dat; de saaie VM blijft de aanbeveling voor productie zolang dit zich nog moet bewijzen.

Dus: één "Docker host"-VM (of een paar, per vertrouwensdomein), Docker daarbinnen, en Proxmox beheert de VM: je krijgt isolatie op VM-niveau, live migration voor je hele Docker-bestand, en schone host-upgrades.

Wat alleen VM's kunnen, en waar LXC het beste in is

Naast de drie beslissende vragen, de concrete lijst van dingen die alleen VM's kunnen: Windows en andere non-Linux guests, aangepaste/nieuwere kernels dan die van de host, kernelmodules (WireGuard zit al in de kernel, maar denk aan gespecialiseerde storage- of onderzoeksmodules), PCIe-passthrough via VFIO (GPU's voor transcoding of AI, HBA's voor een NAS-guest), en (operationeel de grote) live migration en hypervisor-onafhankelijke portabiliteit (een VM-schijfimage verhuist naar elke KVM-host; de configuratie van een container is meer verweven met zijn host).

Het thuisterrein van LXC, dienovereenkomstig: het patroon van veel kleine diensten. Een container per dienst (hier DNS, daar een reverse proxy, een Postgres voor deze app, een monitoringstack), elk onafhankelijk te snapshotten, te back-uppen, te begrenzen in resources en te herstarten, tegen een kosten per instantie die laag genoeg zijn om "één dienst, één container" als beleid betaalbaar te maken. Bind mounts voegen een stille superkracht toe: hostmappen direct in containers mounten, zonder netwerkbestandssysteem nodig, vanzelfsprekend voor een container die data verwerkt die op de grote ZFS-pool van de host staat.

Eén clusterkanttekening om rekening mee te houden: "migratie" van containers tussen nodes is migratie via herstart: stoppen, verplaatsen, starten (seconden downtime voor een lichte container, maar downtime). HA werkt op dezelfde manier: de containers van een uitgevallen node herstarten elders. Kan een dienst dat niet verdragen, dan hoort hij in een VM thuis. Dat is vraag 3 die zijn werk doet.

De beslistabel

Veelgestelde vragen

Kan ik een container later omzetten in een VM (of andersom)?

Een conversie met één klik bestaat niet. De schijfinhoud is compatibel (het zijn allemaal Linux-bestandssystemen), maar de verpakking verschilt: een VM heeft een kernel, bootloader en init nodig die een containerimage niet meedraagt. De praktische route is opnieuw uitrollen en data migreren, wat zelden pijnlijk is voor de kleine diensten die containers hosten. De asymmetrie is het vermelden waard op het moment van uitrol: "beginnen als VM, later containeriseren" kost alleen resources, terwijl "beginnen als LXC, later omzetten naar een VM" een migratie kost. Bij oprechte twijfel is de VM de min-of-meer omkeerbare keuze.

Hoeveel sneller is LXC nu echt?

Voor pure rekenkracht: nauwelijks. KVM voert guest-CPU-instructies uit met hardwareondersteuning, waardoor een rekenintensieve VM binnen enkele procenten van native prestaties blijft. De eerlijke verschillen: boottijd (een seconde versus een volledige OS-boot), geheugeneconomie (plafonds versus reserveringen: hier komt de dichtheid vandaan), en de lengte van het I/O-pad (container-I/O is host-I/O; VM-I/O gaat via VirtIO, wat snel is maar niet gratis). Is je motivatie "performance", meet dan eerst; is het "30 kleine diensten op één machine passen", dan bewijst LXC zichzelf wel.

Werken containers met Proxmox HA en clustering?

Ja, met één gedragsverschil: geen live migration. Een container tussen nodes verplaatsen (voor onderhoud of door HA na een node-storing) verloopt via stop-transfer-start, dus reken op enkele seconden tot een minuut downtime per verplaatsing in plaats van de onmerkbare overstap die VM's krijgen. Voor de meeste diensten van containerklasse is dat geen probleem (en HA die je DNS-container op een overlevende node herstart is beter dan dat hij plat blijft liggen); is dat niet het geval, zie dan vraag 3 en gebruik een VM. De clustermechanica komt aan bod in onze HA-gids.

Moet mijn hele opzet gewoon uit VM's bestaan, voor de eenvoud?

Het is een verdedigbare vereenvoudiging (één model, overal de sterkste isolatie, live migration voor alles), en als je weinig diensten hebt en RAM in overvloed, kies er dan voor. De prijs is dichtheid: inactieve VM's reserveren geheugen dat inactieve containers niet zouden reserveren, dus heeft een vloot van uitsluitend VM's een grotere host nodig voor dezelfde workload. De meeste beheerders komen uit bij de mix die dit artikel beschrijft zodra het aantal diensten groeit; er is geen prijs voor puurheid in welke richting dan ook.

Uitrollen op Serverside

Beide modellen willen hetzelfde fundament: cores, RAM en snelle NVMe. Onze Proxmox dedicated servers komen voorgeïnstalleerd en binnen een minuut geprovisioned op ASN 55285, met genoeg RAM-opties om de vloot van uitsluitend VM's te draaien als dat jouw stijl is, privénetwerken voor multi-node-opzetten, en KVM-over-IP voor de host zelf. Bepaal de grootte van de machine met de sizing guide voor servers (tel je guests op, RAM is de beperking), en bouw dan verder met de rest van de reeks: initiële setup, netwerken, en backups.