Hoe KVM onder de motorkap werkt
KVM zet de Linux-kernel om in een Type-1-hypervisor door een /dev/kvm-tekenapparaat beschikbaar te stellen. Een user-space-proces (doorgaans QEMU) opent dat apparaat, vraagt de kernel om een virtuele CPU aan te maken en draait vervolgens guest-instructies rechtstreeks op de fysieke CPU met behulp van hardware-virtualisatie-extensies. De kernel verwerkt geprivilegieerde gebeurtenissen; al het overige wordt op native snelheid uitgevoerd.
Drie componenten laten KVM werken. Ten eerste beheert de kernelmodule kvm.ko CPU- en geheugenvirtualisatie en stelt de /dev/kvm-interface beschikbaar. Ten tweede vertaalt een architectuurspecifieke module — kvm-intel.ko voor Intel VT-x of kvm-amd.ko voor AMD-V — tussen de generieke KVM-API en de virtualisatie-instructies van de onderliggende CPU. Ten derde levert een user-space-hypervisorproces zoals QEMU, cloud-hypervisor of Firecracker de apparaatemulatie: virtuele schijven, NIC's, USB-controllers en BIOS- of UEFI-firmware. Omdat de Linux-kernel zelf de hypervisor is, gelden elke Linux-scheduler, geheugenbeheerder en beveiligingsfunctie voor VM's op dezelfde manier als voor native processen. Een KVM-guest is vanuit het oogpunt van de kernel simpelweg een zwaargewicht proces, en daarom werken tools als top, perf en cgroups erop zonder aanpassing.
KVM vs OpenVZ vs VMware ESXi vs Hyper-V
KVM biedt volledige hardware-virtualisatie met een aparte guest-kernel voor elke VM. OpenVZ gebruikt containerisatie op OS-niveau waarbij elke container de host-kernel deelt. VMware ESXi is een propriëtaire bare-metal Type-1-hypervisor met een eigen kernel (VMkernel). Hyper-V is de op Windows gebaseerde Type-1-hypervisor van Microsoft. Alleen KVM, ESXi en Hyper-V geven u een echte, geïsoleerde guest-kernel.
OpenVZ (en zijn opvolger Virtuozzo) is een containertechnologie, geen hypervisor. Elke OpenVZ-container deelt de Linux-kernel van de host, wat betekent dat u geen andere kernelversie kunt draaien, geen aangepaste kernelmodules kunt laden en geen niet-Linux-besturingssysteem kunt draaien. De afweging is dichtheid: omdat er geen kerneloverhead per VM is, kan een OpenVZ-host meer containers op dezelfde hardware persen, en dat is de reden dat goedkope shared-VPS-pakketten het vaak gebruikten. VMware ESXi is de enterprise-standaard voor Type-1-virtualisatie, maar wordt geleverd als gesloten-bron product met licenties per socket die het historisch buiten de prijsklasse van standaard VPS-hosting plaatsten. Hyper-V domineert Windows-serveromgevingen en integreert nauw met Active Directory en System Center, maar is een minder gangbare keuze voor Linux-zware hostingvloten. KVM is de standaard geworden voor moderne VPS-hosting omdat het open source is, in de mainline-kernel zit, elk guest-OS ondersteunt dat op x86_64 of aarch64 draait, en een volwassen beheersecosysteem heeft (libvirt, oVirt, Proxmox, OpenStack Nova).
Waarom KVM de moderne standaard is voor VPS
KVM werd de dominante VPS-technologie omdat het elke klant een echte, geïsoleerde kernel geeft zonder licentiekosten in de stijl van VMware. Het ondersteunt Linux-, Windows-, BSD- en Solaris-guests, draait op standaard x86_64- en ARM-hardware en is geïntegreerd in elke grote cloud-orchestratiestack — OpenStack, Proxmox VE, Kubernetes via KubeVirt en AWS Nitro bouwen er allemaal op.
Drie krachten kwamen samen om KVM tot de standaard te maken. Ten eerste werden hardware-virtualisatie-extensies universeel: Intel VT-x werd in 2006 in Core 2-chips geleverd en AMD-V in vroege Athlon 64's, dus tegen het begin van de jaren 2010 kon vrijwel elke server-CPU KVM draaien op bijna-native snelheid. Ten tweede weigerde de Linux-gemeenschap paravirtualisatie in Xen-stijl in de mainline op te nemen, maar nam KVM in 2007 wel op in de mainline, waardoor elke distributie direct een ingebouwde hypervisor kreeg. Ten derde investeerde het publieke-cloud-ecosysteem fors: Google Cloud Engine startte op KVM, AWS migreerde van Xen naar een KVM-gebaseerde Nitro-architectuur, en OpenStack standaardiseerde op KVM als referentie-hypervisor. Kleinere VPS-aanbieders profiteren van deze aantrekkingskracht omdat dezelfde tooling die hyperscaler-vloten draait — libvirt, virtio-drivers, cloud-init — ook draait op één rek met standaard servers.
Echte prestatiekenmerken: CPU steal, IO en overhead
Op een correct ingerichte KVM-host kunt u een eencijferig CPU-overhead-percentage verwachten ten opzichte van bare metal, submilliseconde-netwerklatentie toegevoegd aan lokale netwerkroutes, en 80-95% van de native schijf-IOPS wanneer virtio-blk of virtio-scsi met een paravirtualized driver wordt gebruikt. Aanhoudende CPU steal time boven 5% is het canonieke teken van overcommit op de host en een sterk upgradesignaal.
Drie cijfers zijn belangrijk voor een KVM-guest in productie. CPU steal time, beschikbaar in /proc/stat als het achtste veld, meet het percentage tijd dat de virtuele CPU klaar was om te draaien maar de fysieke CPU bezig was met het uitvoeren van andere guests. Alles onder 1-2% is normaal achtergrondruis; aanhoudende waarden boven 5% betekenen dat de host overcommitted is en uw werklast wordt afgeknepen. IO wait, getoond door tools als iostat en top, meet het percentage tijd dat de CPU geblokkeerd was op schijf of netwerk. Met virtio paravirtualized drivers en moderne NVMe backing-opslag is aanhoudende IO wait boven 20% op een werklast die CPU-gebonden zou moeten zijn een sterk signaal dat het schijfsubsysteem verzadigd is. Netwerkdoorvoer op virtio-net moet 80-95% van de line-rate van de fysieke NIC bereiken; iets wat daar materieel onder zit, wijst op een verkeerd geconfigureerde offload of een oude geëmuleerde e1000-driver.
Wanneer KVM NIET te gebruiken
KVM is de verkeerde keuze in drie situaties: containerwerklasten met ultrahoge dichtheid waarbij de kerneloverhead per VM dominant is, Windows-licentiegevoelige uitrollen waarbij de SPLA-prijs van Hyper-V materieel goedkoper is, en bepaalde scenario's met hardware-passthrough met lage latentie waarbij SR-IOV of GPU-passthrough slecht wordt ondersteund op uw specifieke NIC of GPU-model.
Voor containermicroservices die geen kernelisolatie nodig hebben, zullen Linux-containers (Docker, Podman, Kubernetes) die rechtstreeks op bare metal draaien elke KVM-gebaseerde VPS met een factor 3-5 verslaan op dichtheid, omdat elke container slechts een procesgroep is met namespaces en cgroups. Goedkope, op dichtheid gerichte VPS-aanbieders kozen historisch om dezelfde reden voor OpenVZ. Windows-zware uitrollen — vooral die waarbij Windows Server-licenties via SPLA worden ingekocht — betalen soms materieel minder op Hyper-V dan op KVM vanwege hoe Microsoft guest-licenties op concurrerende hypervisors prijst. Tot slot zijn bepaalde hardware-passthrough-scenario's nog steeds lastig op KVM: GPU-passthrough vereist dat IOMMU-groepen schoon geïsoleerd zijn, sommige consumenten-NIC's hebben geen SR-IOV-ondersteuning, en PCIe-passthrough van NVMe-schijven activeert soms reset-bug-workarounds. Voor 95% van algemene Linux-VPS-werklasten geldt geen van deze, en KVM is dan de juiste standaard.
Hoe verifieert u dat een VPS werkelijk KVM-gebaseerd is?
Voer binnen een Linux-guest `systemd-detect-virt` uit — het zou `kvm` moeten weergeven. Controleer dit met `lscpu` (de regel 'Hypervisor vendor' moet 'KVM' tonen) en `dmesg | grep -i kvm`. Als u in plaats daarvan 'OpenVZ', 'lxc' of 'VMware' ziet, gebruikt uw aanbieder een andere technologie, ook al beweert de marketing iets anders.
Voer voordat u een contract tekent een kleine diagnostische test uit op een proef-VPS. Voer `systemd-detect-virt` uit voor de canonieke detectie-uitvoer. Voer `cat /proc/cpuinfo | grep -E 'vmx|svm'` uit om te bevestigen dat hardware-virtualisatie-extensies worden doorgegeven (sommige aanbieders verwijderen ze, wat geneste virtualisatie kapotmaakt). Voer `uname -r` uit om te verifiëren dat u een guest-specifieke kernel ziet in plaats van een gedeelde host-kernel — op een echte KVM-VPS kunt u een andere kernel installeren via `apt install linux-image-...` of `dnf install kernel-...` en daarin opstarten. Op OpenVZ kunt u dat niet. Controleer ten slotte `/proc/user_beancounters` — als dat bestand bestaat, draait de host OpenVZ ongeacht wat de marketingteksten beweren.