KVM vs. OpenVZ vs. LXC: wat het virtualisatietype van je VPS je echt toestaat

Twee VPS-pakketten, dezelfde pagina. Vier vCPU, 8 GB RAM, 160 GB opslag, vrijwel dezelfde prijs. Op de één staat KVM. Op de ander OpenVZ. Geen van beide pagina's legt uit wat dat woord verandert.

Het verandert wat je mag draaien. Virtualisatietypes bij een VPS zijn niet zomaar een voetnoot over prestaties. Ze bepalen of jij de kernel beheert, of Windows mogelijk is en of Docker werkt zonder hulp van de provider. KVM vs. OpenVZ vs. LXC is eerst een vraag over mogelijkheden en pas daarna over snelheid.

Deze gids behandelt de drie labels die het meest relevant zijn voor deze aankoopbeslissing. Xen, VMware, Hyper-V en andere virtualisatieplatformen bestaan wel, maar vallen buiten deze driewegvergelijking.

TL;DR

• KVM geeft elke VPS een eigen gastkernel. Docker draait gewoon, Windows is technisch mogelijk en meestal kun je kernelmodules laden of een eigen kernel starten. KVM alleen garandeert echter geen dedicated CPU of RAM; toezeggingen over resources hangen nog steeds af van de provider en het pakket.
• OpenVZ VPS-pakketten zijn meestal Linux-containers die de host-kernel delen. Docker draait alleen op OpenVZ 7 als de provider een compatibele kernel en templateconfiguratie gebruikt. Je kunt de host-kernel niet vervangen, en geheugen boven de RAM loopt via door de provider beheerde VSwap in plaats van gewone, door de gast beheerde disk-swap.
• LXC deelt ook de host-kernel, maar is gebouwd rond de containment-functies van de mainline Linux-kernel. Docker kan draaien als de host de vereiste functies inschakelt, al raadt Proxmox aan containers te nesten in een QEMU-VM voor workloads die maximale isolatie en live migratie nodig hebben.
• Containers zijn meestal makkelijker aan te passen terwijl ze draaien. Ook KVM kan CPU- en geheugen-hotplug ondersteunen, dus "KVM vereist altijd een herstart" is geen betrouwbare vuistregel bij aankoop. Vraag de provider wat zijn platform daadwerkelijk ondersteunt.
• Voor een statische site of een kleine LAMP-stack die nooit Docker, Windows of aanpassingen op kernelniveau nodig heeft, kan het praktische verschil klein zijn. Isolatie, levenscyclus en resourcebeleid kunnen nog steeds verschillen.

Het ene verschil waaruit alle andere voortkomen

KVM geeft elke VPS op de host een eigen gastkernel. OpenVZ- en LXC-containers gebruiken de kernel die de host heeft opgestart.

KVM is een volledige virtualisatieoplossing voor x86-hardware met virtualisatie-extensies. Vanaf versie 2.6.20 is het opgenomen in de mainline Linux-kernel. Elke gast ziet virtuele hardware en start een eigen besturingssysteem en kernel op.

De containertypes werken anders. LXC is een userspace-interface voor de containment-functies van de Linux-kernel, waaronder namespaces, cgroups, capabilities, seccomp en beveiligingsprofielen. Het doel is een omgeving die dicht bij een gewone Linux-installatie komt, zonder een aparte kernel te starten.

Een OpenVZ-container volgt hetzelfde brede model van een gedeelde kernel, al gebruikt OpenVZ een eigen platform en eigen kernelstack. OpenVZ 7 kan zowel containers als KVM-VM's beheren, maar als een VPS-pakket in de winkel "OpenVZ" heet, is het verkochte product doorgaans het containertype.

Alle onderstaande verschillen in mogelijkheden vloeien daaruit voort. Een kernelmodule moet geladen worden in een kernel die jij beheert. Een ander besturingssysteem vraagt om een andere kernel. Docker heeft namespacing op kernelniveau nodig, en dat moet beschikbaar zijn waar de kernel zelf zit. Aan de KVM-kant van die grens volgt de hypervisorlaag een architectuur die vaak wordt onderverdeeld in type 1- en type 2-hypervisors.

LXC duikt vaak op in Proxmox-omgevingen, waaronder zelfbeheerde servers en sommige hostingplatformen. Of je geavanceerde LXC-functies kunt inschakelen, hangt af van wie die host beheert.

LEES

KVM vs. OpenVZ 2022: wie is de virtualisatie-expert?

Wat elk type je laat draaien

De assen die de aankoop bepalen zijn kernelbeheer, ondersteuning voor het gastbesturingssysteem, Docker-compatibiliteit, geheugengedrag, aanpassen van de omvang en resourcebeleid.

Welke moet je kiezen? KVM is het duidelijkste antwoord als je Windows, een eigen kernel, door de gast geladen modules of een voorspelbare Docker-host nodig hebt. OpenVZ en LXC kunnen efficiënte Linux-omgevingen zijn, maar laten beslissingen op kernelniveau bij de provider.

Dit is een kaart van mogelijkheden, geen benchmark. Het zegt niets over opslaglatentie, netwerkkwaliteit, CPU-generatie, hostbezetting of het toewijzingsbeleid van de provider. Twee providers met hetzelfde virtualisatietype kunnen heel verschillende machines leveren.

Bij de voorwaardelijke cellen verliezen kopers tijd. Ik heb ooit een VPN uitgerold op een container-VPS waar de vereiste netwerkfunctie aan de hostkant niet beschikbaar was. De interface kwam niet omhoog, en de oplossing vroeg om een supportticket in plaats van een configuratiewijziging in de gast. Vraag bij een containerpakket of de provider precies het apparaat of de kernelfunctie beschikbaar stelt die jouw VPN nodig heeft. Bij KVM regel je dat normaal gesproken zelf in de gast.

Waarom Docker de vraag is die de meeste aankopen bepaalt

Container-VPS versus KVM-VPS is geen abstracte vergelijking meer zodra Docker in je eisen opduikt. Docker zelf gebruikt kernel-namespaces, cgroups, netwerken en opslagdrivers. Binnen KVM horen die functies bij de gastkernel die jij beheert. Binnen OpenVZ of LXC hangen ze uiteindelijk af van de host.

Docker op OpenVZ

Docker-ondersteuning op OpenVZ is een provisioningbeslissing die boven jou wordt genomen. Een SolusVM-supportartikel stelt dat Docker binnen OpenVZ 7 kan draaien vanaf een bepaalde 3.10-kernelrelease, maar zegt ook dat Docker niet werkt met de standaard voorgemaakte legacy-templates. De container moet een EZ-template of een geschikt eigen template gebruiken. Datzelfde artikel sluit CentOS 8-gasten uit.

Werkt Docker dus op OpenVZ? Soms. De provider moet de dienst hebben gebouwd rond een compatibele OpenVZ 7-kernel en een geschikt templatepad. Staat dat niet duidelijk op de pakketpagina, vraag het dan vóór aankoop aan de support en bewaar het antwoord schriftelijk.

Als de hostconfiguratie niet compatibel is, lost het aanpassen van Docker-flags binnen de VPS het onderliggende probleem niet op. De provider moet de containerconfiguratie wijzigen of je naar een ander virtualisatietype verplaatsen.

Docker op LXC

Docker kan binnen LXC draaien als de host de vereiste functies beschikbaar stelt. In Proxmox omvat dat doorgaans containernesting en keyctl voor ongeprivilegieerde containers.

Het belangrijkere koopsignaal is de aanbeveling van de platformeigenaar. De Proxmox-documentatie stelt dat het nesten van containers in een Proxmox QEMU-VM een aanbevolen praktijk blijft voor gebruikssituaties die maximale isolatie en live migratie vereisen, in plaats van ze rechtstreeks in een LXC-systeemcontainer te draaien.

Beheer je de LXC-host zelf, dan kun je die afweging maken en upgrades op je eigen tempo testen. Huur je een LXC-VPS, dan beheert de provider de kernel, het beveiligingsprofiel en de geavanceerde feature flags. Laat de ondersteunde configuratie bevestigen in plaats van aan te nemen dat root-toegang binnen de container genoeg is.

Docker op KVM

Docker werkt normaal omdat de Linux-gast zijn eigen kernelomgeving beheert. Boven de gast is er geen LXC-nestingschakelaar en geen OpenVZ-templatevereiste. Je hebt nog altijd een ondersteunde Linux-distributie nodig, een compatibele kernel en genoeg RAM en opslag voor de workload.

De gastkernel bezitten betekent ook hem onderhouden. Op een unmanaged VPS blijven updates, firewallregels, Docker-beveiliging en back-ups jouw verantwoordelijkheid.

Kernpunt: Docker maakt OpenVZ of LXC niet onmogelijk, maar maakt de configuratie van de provider onderdeel van de betrouwbaarheid van je applicatie. Voor een gehuurde Docker-host in productie neemt KVM die extra afhankelijkheid weg.

Of "4 vCPU" vier dedicated CPU-cores betekent

Een VPS die traag aanvoelt terwijl de eigen monitoring een inactieve CPU laat zien: dat is het symptoom dat mensen het vaakst beschrijven. Containervirtualisatie maakt dat mogelijk. De strijd om resources speelt zich een laag lager af dan de gast kan zien, dus zijn eigen metrics tonen niets verdachts.

Het mechanisme is de lage overhead zelf. Een container kost de host veel minder dan een volledige virtuele machine, dus passen er meer containers op dezelfde hardware. Die dichtheid is goedkoop te maken en van binnenuit de gast lastig te detecteren, waardoor overselling structureel makkelijker is op OpenVZ dan op KVM. KVM belet een provider niet om een host vol te stouwen. Maar het legt echt geheugen en echte CPU-aandelen per gast vast, wat een rekenkundig plafond zet op hoe ver dat kan gaan. Voor de diagnosekant is er een aparte uitleg over hoe je merkt of je provider aan overselling doet.

Ook geheugen gedraagt zich anders. Op OpenVZ kun je disk-swap niet als extra geheugen gebruiken, dus het RAM-getal op de pakketpagina is een muur en geen helling. Een KVM-gast onder geheugendruk wordt trager. Bij een OpenVZ-container onder geheugendruk worden processen afgeschoten.

Er is ook een gevolg voor isolatie, en dat wordt het meest onderschat. Het geheugen van een container is vanaf de host adresseerbaar op een manier die bij een KVM-gast niet geldt. Schijfversleuteling in de gast beschermt je nog steeds tegen een gestolen schijf. Het beschermt de sleutels van een draaiende container niet tegen de machine die hem draait. Hoort de hostbeheerder bij je dreigingsmodel, dan is een gedeelde kernel de verkeerde ondergrond. Geen enkele configuratie binnen de gast verandert dat.

Kernpunt: hetzelfde getal op een pakketpagina is een andere belofte, afhankelijk van het type. Bij KVM is het een toewijzing. Bij OpenVZ is het een plafond dat je deelt.

Waar OpenVZ nog zinvol is, en waar het heen gaat

Draai je een statische site of een LAMP-stack met weinig verkeer, dan raak je de mogelijkheden die OpenVZ beperkt misschien nooit. Geen Windows, geen eigen kernel, geen door de gast geladen module en geen Docker in productie. Voor die smalle workload kan een goed beheerde OpenVZ-container de klus nog steeds klaren.

De levenscyclus vraagt meer aandacht dan tien jaar geleden. OpenVZ 7 is gebaseerd op de kerneltak van RHEL 7, versie 3.10. Het versienummer alleen bewijst niet dat een onderhouden enterprise-kernel beveiligingsfixes mist, want leveranciers backporten patches. Het betekent wel dat je de compatibiliteit moet nagaan met software die nieuwere kernelinterfaces verwacht.

The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the officiële levenscyclusbeleid.

Dat breekt vandaag geen werkende OpenVZ-site. Het maakt het migratieplan van de provider wel relevant voordat je er een nieuwe, langlopende workload aan toevertrouwt. Vraag welke OpenVZ- of Virtuozzo-versie draait, hoe beveiligingsfixes worden geleverd en welk migratiepad er is.

Als een pakketpagina het virtualisatietype niet noemt, vraag het dan aan de support in plaats van het uit de prijs af te leiden. Het antwoord is het waard om zwart op wit te hebben.

Kiezen op basis van je workload

Begin bij de eis, niet bij de technologie.

Kies KVM als de workload een eigen kernel nodig heeft

KVM is de directe keuze zodra je een van de volgende dingen nodig hebt:

• Windows als gastbesturingssysteem
• Een eigen kernel
• Door de gast geladen kernelmodules
• Docker in productie zonder afhankelijkheden van container-in-container
• Geneste virtualisatie, als de provider die beschikbaar stelt
• Door de gast beheerde swap en kernelafstemming

Windows is doorslaggevend omdat zowel OpenVZ- als LXC-containers een Linux-host-kernel gebruiken. De keuze tussen Linux en Windows voor de applicatie zelf is een aparte vraag, met softwarecompatibiliteit, beheer en licenties. Zie de vergelijking tussen Linux- en Windows-VPS voor die beslissing.

Kies LXC als je een efficiënte Linux-systeemcontainer wilt

LXC is verstandig als de workload alleen Linux is, geen aparte kernel nodig heeft en profiteert van lage overhead of snelle, door de host beheerde wijzigingen. Het is vooral nuttig als je de Proxmox- of LXC-host zelf beheert.

Controleer bij een gehuurde LXC-VPS de Docker-ondersteuning, de vereiste apparaten, de beveiligingsmodus, het back-upgedrag en of geavanceerde functies ingeschakeld kunnen worden.

Overweeg OpenVZ voor een eenvoudige, geverifieerde Linux-workload

OpenVZ kan nog steeds acceptabel zijn voor een eenvoudige website, een kleine LAMP-stack, een DNS-dienst of een even conventionele Linux-workload, mits:

• De provider documenteert de platformversie.
• Je software ondersteunt de beschikbare kernelomgeving.
• Je hebt geen Windows of kernelaanpassingen nodig.
• Docker is óf niet nodig, óf expliciet ondersteund.
• De provider heeft een geloofwaardig beveiligings- en migratieplan.
• De prijs of het operationele model geeft je een echte reden om ervoor te kiezen.

Kies het niet alleen omdat een oude vergelijking zegt dat OpenVZ altijd goedkoper is. Vergelijk het huidige pakket, de support, het resourcebeleid en de migratiemogelijkheden.

Kwam je uit op KVM, dan is het de randvoorwaarde die beslist, niet een voorkeur. De KVM VPS van Cloudzy start in 60 seconden op AMD EPYC met puur NVMe, en elke instantie krijgt een eigen gastkernel. Kernelmodules laden, eigen kernels booten, en zowel Linux- als Windows-gasten worden ondersteund. Docker staat in de marketplace als je het liever niet zelf installeert.

Veelgestelde vragen

systemd-detect-virt