Verschil tussen KVM, Xen en LXC voor uw VPS

Wat uw VPS-abonnement werkelijk verkoopt

KVM, Xen en LXC zijn de drie virtualisatiefamilies waarop een VPS-abonnement is gebaseerd, en de keuze is geen detail van het rack van de provider. Het bepaalt of u over een eigen kernel beschikt. Alles wat voor een koper van belang is, vloeit voort uit dat ene feit: het laden van modules, het beheren van swap, het draaien van geneste virtualisatie, of /proc uw server beschrijft of die van iemand anders, en of 'steal time' überhaupt meetbaar is.

Volledige virtualisatie (KVM en Xen HVM) geeft elke huurder een kernel en een virtuele machine. Paravirtualisatie via Xen geeft u eveneens een kernel, maar een die weet dat deze een gast is en de hypervisor verzoekt om geprivilegieerd werk uit te voeren. Een containerabonnement (LXC, of de lijn van OpenVZ en Virtuozzo) geeft u een bestandssysteem en een set namespaces op de kernel van de provider. Alle drie worden onder dezelfde drie letters verkocht.

KVM versus Xen versus LXC: één kernel per stuk of één gedeelde kernel

Bij KVM en Xen benoemt uname -r uw kernel. U kunt een andere kernel installeren, een module laden en de machine opnieuw opstarten in die kernel. Niets van wat u daar doet, heeft invloed op een andere huurder. Bij een containerplan benoemt uname -r de kernel van de provider, die op de host draait en wordt gedeeld met elke andere container op die machine. U kunt deze niet wijzigen en apt install linux-image-generic zal bestanden uitpakken die nooit opstarten.

Dat ene verschil is waardevoller dan welke specificatielijst dan ook. Lees de rest van deze handleiding als de gevolgen daarvan.

Volledige virtualisatie: KVM en Xen HVM

KVM (kernel-based virtual machine) is een module binnen de Linux-kernel die een standaard Linux-host verandert in een hypervisor, waarbij gebruik wordt gemaakt van de Intel VT-x of AMD-V instructies die in de CPU zijn ingebouwd. QEMU levert de virtuele hardware eromheen: schijf, netwerkkaart, seriële console. Xen heeft een ander ontwerp. Xen is een eigen hypervisor en start op voordat Linux dat doet. Een bevoorrecht controledomein genaamd dom0 voert de managementstack uit, en elke huurder is een domU. Xen HVM (hardware virtual machine) gebruikt dezelfde CPU-extensies als KVM, meestal met paravirtual-drivers voor schijf en netwerk omdat geëmuleerde hardware traag is. Die combinatie wordt PVHVM genoemd.

Voor een huurder gedragen de twee zich vrijwel identiek. U krijgt een kernel, een bootloader, een echt block device, een werkende modprobe, een eerlijke /proc, eigen swapruimte en een reboot die daadwerkelijk opnieuw opstart. Als de provider u toestaat een ISO te koppelen, kunt u een distributie installeren die zij nooit hebben aangeboden.

U betaalt daarvoor in dichtheid. Uw 4 GB is toegewezen aan uw machine en kan niet worden uitgeleend aan een buurman terwijl u niets doet, en elke gast draait een QEMU-proces, zijn eigen paginatabellen en zijn eigen page cache. Die kosten zijn de reden waarom een KVM-abonnement duurder is geprijsd dan een container-abonnement met dezelfde specificaties.

Paravirtualisatie in Xen en hoe u dit herkent

Xen PV bestond al voordat CPU's over virtualisatie-instructies beschikten. In plaats van bevoorrechte instructies te onderscheppen, is de gast-kernel aangepast om de hypervisor direct aan te roepen. Het draait zonder VT-x, wat in 2005 het hoofddoel was. De kernel wordt vanuit uw eigen schijfimage geladen door pygrub of pvgrub; het is dus uw eigen kernel, maar deze moet zijn gebouwd met ondersteuning voor PV-gasten.

Tekenen dat u op een dergelijk systeem werkt: lscpu rapporteert het virtualisatietype als para in plaats van full, /sys/hypervisor/type bestaat en vermeldt Xen, en uw schijven zijn xvda in plaats van vda of sda. Tools die de SMBIOS- of DMI-tabellen uitlezen, vinden niets, omdat een PV-gast geen firmware heeft om deze te publiceren.

De prijs die u hiervoor betaalt, is het definitieve verlies van geneste virtualisatie. Aan een PV-gast worden nooit de CPU-virtualisatie-extensies getoond, waardoor er geen hypervisor binnenin kan draaien. Xen zelf is niet verdwenen. Specifiek Xen PV is het onderdeel dat naar de achtergrond is verdwenen, en de koers van het project is verschoven naar PVH en HVM. Als een plan "Xen" vermeldt, vraag dan om welke variant het gaat. HVM is een moderne, standaard VPS. PV is een plan dat u lager zou moeten prijzen.

Container VPS: LXC en de OpenVZ-lijn

Een container-VPS is een verzameling Linux-namespaces (gescheiden weergaven van proces-ID's, mounts, netwerkinterfaces, hostnaam en gebruikers) plus cgroups (control groups, de resourcelimieten van de kernel) die op de kernel van de provider draaien. Uw init is een proces op de host. Uw ls draait direct op de kernel van de host, zonder emulatie en zonder een tweede scheduler die in de weg zit. Daarom zijn containers snel en efficiënt.

De namen op een bestelpagina zijn LXC, Proxmox VE-containers (wat LXC is), OpenVZ en Virtuozzo. OpenVZ 7 en Virtuozzo zijn de commerciële afstammelingen van hetzelfde concept.

Vier zaken veranderen voor u:

• Modules. modprobe zal niets laden. Als WireGuard, ZFS of een specifieke netfilter-module niet al in de kernel van de provider aanwezig is, kunt u deze niet gebruiken.
• sysctl. Het grootste deel van /proc/sys is alleen-lezen. Netwerken is een echte namespace, dus net.ipv4.ip_forward en de bijbehorende bestanden zijn meestal beschrijfbaar. Systeembrede instellingen zoals vm.swappiness of fs.file-max behoren toe aan de host.
• Geneste containers. Docker binnen een LXC-container werkt alleen als de provider nesting inschakelt en de storage-driver meewerkt. Test dit voordat u tot aanschaf overgaat in plaats van ervan uit te gaan dat het werkt.
• De kernelversie. U bent afhankelijk van het update-schema van de provider, inclusief de reboots.

Hoe u bepaalt welk type u heeft aangeschaft

Voer deze commando's uit op de server en combineer de resultaten. Eén enkel commando geeft zelden uitsluitsel.

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

systemd-detect-virt toont een korte identificatie uit een vaste set waarden. De machine-zijde omvat kvm, qemu, xen, amazon en vmware. De container-zijde omvat lxc, lxc-libvirt, openvz, docker en systemd-nspawn. Wanneer er niets wordt gedetecteerd, toont het none en sluit het af met een non-zero exitcode. De -c-vorm geeft alleen antwoord voor containertechnologieën; elk ander antwoord dan none bevestigt dus dat het om een container gaat, ongeacht wat de verkoopomschrijving vermeldde.

lscpu noemt de leverancier van de hypervisor en geeft aan of het virtualisatietype full of para is; dit is de manier om Xen HVM van Xen PV te onderscheiden. /sys/hypervisor/type bestaat alleen onder Xen.

De /lib/modules-controle wordt vaak overgeslagen, terwijl dit de meest directe methode is. Als de directory voor de actieve kernelversie ontbreekt of leeg is, terwijl het systeem wel degelijk op die kernel draait, dan is de kernel niet afkomstig van uw bestandssysteem. Deze is afkomstig van de host en de bijbehorende module-tree is nooit in uw image geïnstalleerd. In dat geval betreft het een container.

Voor een onafhankelijke tweede mening voert sudo apt install -y virt-what && sudo virt-what de detectietests uit als een toegewezen tool. Dit vereist root-rechten en geeft op bare metal helemaal geen uitvoer.

Waarom /proc de verkeerde machine beschrijft in een container

Op een KVM- of Xen-guest is /proc/meminfo de boekhouding van uw eigen kernel over het geheugen dat de hypervisor aan u heeft toegewezen. Dit is correct voor uw machine en zegt niets over de host. Dat is het doel van een virtuele machine.

In een container is er geen tweede kernel die deze boekhouding uitvoert, dus is /proc de /proc van de host. LXCFS is een klein bestandssysteem dat sommige van deze bestanden herschrijft om overeen te komen met uw cgroup-limieten, en het dekt /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats en /sys/devices/system/cpu/online. Proxmox koppelt dit standaard aan. Veel kleinere providers doen dit niet, en dan rapporteert free -m het totale geheugen van de host, kan nproc elke core in de machine rapporteren en rapporteert uptime hoe lang de host al draait.

Dit is niet louter cosmetisch, omdat software zijn omvang baseert op deze bestanden. nginx met worker_processes auto telt de cores die het kan zien. make -j$(nproc) op een host met 64 cores en een quotum van 2 cores start 64 compilers. Een JVM of een database die een cachegrootte kiest op basis van MemTotal, kiest een getal dat uw cgroup zal weigeren, waarna de kernel het proces beëindigt zodra de limiet is bereikt. Die beëindiging wordt gelogd in het kernel-logboek van de host, dat u niet kunt inzien.

De gezaghebbende getallen bevinden zich in de cgroup, niet in /proc:

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

Dit zijn cgroup v2-paden, die door huidige distributies worden gebruikt. memory.max bij het lezen van max betekent dat er op dat niveau geen limiet is ingesteld. cpu.max toont een quotum en een periode in microseconden, dus 200000 100000 staat voor twee cores aan CPU-tijd per periode. Op een oudere cgroup v1-host bevinden dezelfde waarden zich onder /sys/fs/cgroup/memory/memory.limit_in_bytes en /sys/fs/cgroup/cpu/cpu.cfs_quota_us.

Swap, en wie de eigenaar ervan is

Op KVM en Xen is swap van u. Het is een bestand of een partitie op uw schijf en uw kernel voert de paging uit.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

swapon --show zou nu het bestand met de grootte en prioriteit moeten weergeven. Als swapon het bestand weigert, maak het dan aan met dd if=/dev/zero of=/swapfile bs=1M count=2048, omdat een vooraf toegewezen bestand met niet-geschreven extents op sommige bestandssystemen wordt geweigerd. Voeg /swapfile none swap sw 0 0 toe aan /etc/fstab, anders is de swap na de volgende herstart verdwenen.

In een container is niets daarvan van u. swapon vereist een capability die een niet-geprivilegieerde container niet bezit, waardoor het aanmaken van een eigen swap-bestand faalt vanwege de rechten en nooit de schijf bereikt. Wat het plan swap noemt, is een cgroup-instelling op de host, memory.swap.max onder cgroup v2, ondersteund door de eigen swap-apparaten van de host. Oudere OpenVZ-plannen verkochten een "vswap"-toewijzing die zich meer gedroeg als een burst-tegoed dan als een schijf. U kunt het plafond aflezen. U beheert het apparaat eronder niet.

Geneste virtualisatie en de CPU-vlag die misleidt

Geneste virtualisatie betekent dat u een hypervisor binnen uw VPS draait: een QEMU-gast, een Vagrant-box, of een lab voor geneste virtualisatie met eigen VM's. Er moet aan twee voorwaarden tegelijk worden voldaan. De provider moet nesting op de host inschakelen en uw gast moet de virtualisatie-extensies van de CPU kunnen zien.

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

Op een KVM-gast met ingeschakelde nesting bestaat /dev/kvm en geeft kvm-ok duidelijk aan of versnelling kan worden gebruikt. Op Xen HVM is het technisch mogelijk, maar wordt het zelden aangeboden. Op Xen PV is het niet mogelijk.

In een container faalt de controle op een leerzame manier. /proc/cpuinfo is het bestand van de host, dus de vlag vmx of svm is aanwezig en is feitelijk waar: de fysieke CPU onder u beschikt inderdaad over die instructies. Ze zijn echter niet van u. Er is geen /dev/kvm in uw namespace, u kunt de module kvm_intel niet laden en de vlag die u zojuist las, beschrijft de machine waarvan u een gast bent in plaats van een machine die u beheert. Dit is het duidelijkste voorbeeld van de algemene regel. In een container beschrijft /proc de namespace en de hardware daaromheen, niet een server die u in eigendom heeft.

AES-NI en de CPU-functies die uw plan blootstelt

AES-NI (advanced encryption standard new instructions) is een set CPU-instructies die AES-encryptie aanzienlijk sneller maken dan dezelfde berekeningen in software. TLS-termination, schijfencryptie, SSH en back-uppijplijnen maken hier allemaal gebruik van.

Bij KVM wordt wat uw guest ziet bepaald door het CPU-model dat de provider voor QEMU heeft geconfigureerd. Met host passthrough ziet u de werkelijke vlaggen. Bij een generiek model zoals qemu64, of een bewust gekozen verouderde baseline zodat guests tussen verschillende hosts kunnen migreren, kan de aes-vlag ontbreken. OpenSSL schakelt in dat geval geruisloos terug naar de softwarematige uitvoering.

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

Het derde commando is het voorbeeld uit de OpenSSL-handleiding voor het uitschakelen van die instructies binnen de bibliotheek: het wist de AES-NI-bit en de VAES-bit en laat de rest ongewijzigd. Vergelijk de twee doorvoersnelheden. Als deze dicht bij elkaar liggen, werd het snelle pad in eerste instantie niet gebruikt en is het correct controleren van AES-NI op een VPS de vijf minuten waard voordat u zich aan een plan verbindt.

Een container heeft geen CPU-model voor zich, dus de vlaggen in /proc/cpuinfo zijn de werkelijke vlaggen van de host en deze zijn op u van toepassing. Dat is een reëel voordeel van containerplannen, en het is het enige punt in deze handleiding waar de gedeelde kernel in uw voordeel werkt.

Waar steal time vandaan komt en waarom een container dit niet heeft

Steal time is de tijd dat uw virtuele CPU klaar was om taken uit te voeren, maar dit niet kon omdat de hypervisor op dat moment een andere taak verwerkte. Dit wordt weergegeven als st in top en vmstat, en als het achtste veld van de cpu-regel in /proc/stat.

Een gast-OS kan dit niet zelf meten, omdat het niet actief is op het moment dat de tijd wordt 'gestolen'. De hypervisor moet dit aan het gast-OS doorgeven. KVM schrijft een totaaloverzicht naar een pagina die het gast-OS registreert via zijn paravirtual clock-interface, en Xen houdt voor dezelfde taak een run state-gebied per vCPU bij. Het getal dat u leest is de eigen bekentenis van de hypervisor; daarom bestaat het en is het betrouwbaar.

Hoge steal time betekent dat de host overbezet is en uw buren op dat moment actief zijn. Het is de zichtbare verhouding tussen het aantal verkochte vCPU's en de fysieke cores. Steal time uitlezen om een luidruchtige buur te identificeren is de enige meting die aantoont of een plan daadwerkelijk zo krachtig is als de specificaties beweren.

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

In een container zal die kolom niet veranderen, omdat er geen hypervisor tussen u en de scheduler staat. Uw processen staan in de wachtrij naast de processen van alle andere huurders als gewone taken in de CPU-scheduler van de host. Contentie uit zich doordat werk simpelweg langer duurt, zonder dat er een teller is die de oorzaak benoemt. Het dichtstbijzijnde equivalent is quota throttling: wanneer de provider cpu.max instelt, telt /sys/fs/cgroup/cpu.stat het aantal nr_throttled-periodes en throttled_usec-microseconden dat wordt gewacht op het volgende quotavenster. Dit heeft alleen betrekking op uw eigen quotum, nooit op concurrentie van buren. Eén waarschuwing: als de container-host van de provider zelf een virtuele machine is, kan er een steal-waarde verschijnen in /proc/stat; deze hoort bij die host en niet bij u.

Overselling, en waarom het container-abonnement goedkoper is

Het eerlijke antwoord is kort. Een container-abonnement kost minder omdat de provider meer van dezelfde machine deelt met meer mensen.

Geheugen is het punt waar het verschil het grootst is. Het RAM-geheugen van een KVM-gast is aan die gast toegewezen, dus een host met 256 GB verkoopt ongeveer 256 GB aan gasten, minus de overhead. De geheugenlimiet van een container is eerder een plafond dan een reservering, en geheugen dat een container niet gebruikt, is direct beschikbaar voor de andere containers. Hierdoor kan de provider limieten verkopen die bij elkaar opgeteld vele malen groter zijn dan het fysieke RAM-geheugen, en in bijna alle gevallen klopt dit. Er wordt niets gefaket. Het werkt totdat er te veel huurders tegelijkertijd actief zijn; dan stopt het voor iedereen met werken.

CPU wordt bij elk type abonnement oververkocht, inclusief KVM, door meer vCPU's te verkopen dan er fysieke cores zijn. Schijfruimte wordt bijna overal 'thin provisioned'. Containers voegen daar een extra dichtheid aan toe: één kernel, één page cache, geen QEMU-proces per gast, waardoor een host vele malen meer huurders kan huisvesten.

Wat u inlevert is isolatie, en dat is een reële technische afweging in plaats van een bangmakerij. U deelt een kernel, dus een kernel-bug is een gedeeld probleem, en een container-escape komt direct op de host terecht. Voor het ontsnappen uit een virtuele machine is een hypervisor-bug nodig, wat een veel kleiner en veel lastiger doelwit is. U bent ook afhankelijk van het schema van de provider voor kernel-updates en reboots. Als een van deze zaken voor u van belang is, lees dan hoe veilig VPS-hosting werkelijk is voordat u uw keuze uitsluitend op basis van de prijs maakt.

Welke keuze maken

Koop KVM wanneer u een eigen kernel nodig heeft: voor WireGuard- of ZFS-modules, een specifieke kernelversie, nested virtualisation, volledige controle over swap, of een grens die u aan een auditor kunt verantwoorden. Koop een container-abonnement wanneer u standaarddiensten draait met een beperkt budget, de kernel van de provider actueel is en u heeft bevestigd dat de functies waar u afhankelijk van bent, reeds in de kernel zijn gecompileerd. Beschouw Xen HVM voor de meeste doeleinden als gelijkwaardig aan KVM, en stel vragen voordat u iets aanschaft dat nog als Xen PV wordt verkocht.

Twee vormen vallen buiten deze verdeling. Firecracker microVMs geven elke huurder een echte kernel met opstarttijden die vergelijkbaar zijn met die van een container; dit is waar serverless-platformen op draaien. Incus system containers stellen u in staat om zelf het containermodel te draaien op hardware die u beheert, wat een andere positie is dan wanneer u er een afneemt. Als de terminologie het struikelblok vormt, behandelen wat een VPS daadwerkelijk is en het verschil tussen een VPS, een VM en een VPC de begrippen waarvan deze handleiding uitgaat dat u ze al kent.

FAQ

Hoe bepaal ik of mijn VPS KVM of een container is?

Voer systemd-detect-virt -c uit. Elk antwoord anders dan none betekent dat u zich in een container bevindt, ongeacht de productnaam van het abonnement. Bevestig dit op twee andere manieren, aangezien detectie kan worden misleid. lscpu noemt een hypervisor-leverancier en geeft aan of het virtualisatietype volledig of para-virtualisatie is. ls /lib/modules/$(uname -r) ontbreekt of is leeg in een container, omdat de actieve kernel afkomstig is van de host en de bijbehorende moduleboom nooit in uw bestandssysteem is geïnstalleerd. sudo virt-what geeft een onafhankelijk antwoord van een tool die specifiek voor deze vraag is geschreven.

Waarom toont free -m veel meer geheugen dan mijn abonnement bevat?

U bevindt zich op een container-abonnement zonder LXCFS gemount, waardoor /proc/meminfo het bestand van de host is en free getrouw het geheugen van de host rapporteert. Uw werkelijke limiet is de cgroup. Lees /sys/fs/cgroup/memory.max voor de limiet en /sys/fs/cgroup/memory.current voor het huidige gebruik, of /sys/fs/cgroup/memory/memory.limit_in_bytes op een oudere cgroup v1-host. Configureer elke service die een cache of worker-pool dimensioneert op basis van dat getal in plaats van free.

Kan ik Docker of WireGuard draaien op een LXC VPS?

Soms, en nooit vanwege iets dat u zelf installeert. Beide zijn afhankelijk van de kernel van de provider, aangezien u daar geen module in kunt laden. WireGuard werkt wanneer de module al aanwezig is op de host en aan u is blootgesteld; de userspace wireguard-go-implementatie is het alternatief wanneer dit niet het geval is. Docker vereist dat de provider nesting toestaat en heeft een storage driver nodig die functioneert binnen een container. Vraag dit na voordat u koopt, of test op een termijn die u direct kunt beëindigen.

Waarom rapporteert mijn container-VPS nooit steal time?

Steal time bestaat alleen wanneer een hypervisor een virtuele CPU inplant, en het wordt gerapporteerd omdat die hypervisor het cijfer schrijft naar een pagina die uw kernel leest. Een container heeft geen hypervisor onder zich. Uw processen zijn gewone taken in de scheduler van de host, dus strijd om resources uit zich in het feit dat alles langer duurt zonder dat er een teller is die dit aanwijst. Lees in plaats daarvan /sys/fs/cgroup/cpu.stat: nr_throttled en throttled_usec tellen de tijd die uw cgroup heeft gewacht op het volgende CPU-quotumvenster, wat het dichtst in de buurt komt van steal time in een container.