KVM, Xen o LXC: quale virtualizzazione usa il tuo VPS?

Cosa vende realmente il tuo piano VPS

KVM, Xen e LXC sono le tre principali famiglie di virtualizzazione su cui si basano i piani VPS. La scelta non riguarda un dettaglio dell'infrastruttura del provider. Determina se hai un kernel dedicato. Da questo dipende tutto ciò che interessa a chi acquista: il caricamento dei moduli, il controllo dello swap, l'esecuzione della virtualizzazione annidata, il fatto che /proc descriva il tuo server o quello di qualcun altro e la possibilità stessa di misurare lo steal time.

La virtualizzazione completa (KVM e Xen HVM) assegna a ogni tenant un kernel e una macchina virtuale. Anche Xen paravirtualizzato fornisce un kernel, ma il kernel sa di essere un guest e chiede all'hypervisor di eseguire per suo conto le operazioni privilegiate. Un piano basato sui container (LXC oppure le piattaforme OpenVZ e Virtuozzo) fornisce un filesystem e un insieme di namespace sul kernel del provider. Tutte e tre le soluzioni vengono vendute usando le stesse tre lettere.

KVM vs Xen vs LXC: un kernel per ciascuna istanza oppure un kernel condiviso

Su KVM e Xen, uname -r indica il kernel della tua istanza. Puoi installarne un altro, caricarvi un modulo e riavviare l'istanza con il nuovo kernel. Le operazioni eseguite in questo modo non interessano gli altri tenant. Con un piano basato su container, uname -r indica il kernel del provider, in esecuzione sull'host e condiviso con tutti gli altri container presenti su quella macchina. Non puoi modificarlo e apt install linux-image-generic estrarrà file che non verranno mai utilizzati per l'avvio.

Questa sola differenza è più importante di qualsiasi scheda tecnica. Considera il resto di questa guida come una serie di conseguenze di tale differenza.

Virtualizzazione completa: KVM e Xen HVM

KVM (kernel-based virtual machine) è un modulo del kernel Linux che trasforma un normale host Linux in un hypervisor, usando le istruzioni Intel VT-x o AMD-V integrate nella CPU. QEMU fornisce l'hardware virtuale circostante: disco, scheda di rete e console seriale. Xen segue un'architettura diversa. Xen è un hypervisor autonomo e viene avviato prima di Linux. Un dominio di controllo privilegiato chiamato dom0 esegue lo stack di gestione, mentre ogni tenant è un domU. Xen HVM (hardware virtual machine) usa le stesse estensioni della CPU di KVM, in genere con driver paravirtualizzati per disco e rete perché l'hardware emulato è lento. Questa combinazione è chiamata PVHVM.

Per un tenant, i due sistemi si comportano quasi nello stesso modo. Sono disponibili un kernel, un bootloader, un dispositivo a blocchi reale, un modprobe funzionante, un /proc effettivamente disponibile, uno swap dedicato e un riavvio che esegue davvero il boot. Se il provider consente di collegare un'immagine ISO, è possibile installare una distribuzione che non viene normalmente offerta.

Il costo è una densità inferiore. I 4 GB sono riservati alla macchina e non possono essere prestati a un altro utente mentre la macchina resta inattiva. Inoltre, ogni guest include un processo QEMU, le proprie tabelle delle pagine e la propria cache delle pagine. Questo costo spiega perché un piano KVM abbia un prezzo superiore a un piano basato su container con gli stessi valori dichiarati.

Xen paravirtualizzato e come riconoscerlo

Xen PV è nato prima che le CPU disponessero delle istruzioni per la virtualizzazione. Invece di intercettare le istruzioni privilegiate, modifica il kernel guest in modo che chiami direttamente l’hypervisor. Funziona senza VT-x, che era l’obiettivo principale nel 2005. pygrub o pvgrub caricano il kernel dall’interno della tua immagine disco: è quindi il tuo kernel, ma deve essere compilato con il supporto per i guest PV.

Se stai usando questo tipo di virtualizzazione, puoi notare i seguenti segnali: lscpu indica para come tipo di virtualizzazione invece di full, esiste /sys/hypervisor/type e identifica Xen, e i dischi sono xvda invece di vda o sda. Gli strumenti che leggono le tabelle SMBIOS o DMI non trovano nulla, perché un guest PV non dispone di firmware che le esponga.

La conseguenza è l’impossibilità permanente di usare la virtualizzazione annidata. A un guest PV non vengono mai esposte le estensioni di virtualizzazione della CPU, quindi nessun hypervisor può essere eseguito al suo interno. Xen non è un progetto abbandonato. È Xen PV, nello specifico, ad avere perso rilevanza; inoltre, lo sviluppo del progetto si è spostato verso PVH e HVM. Se un piano indica semplicemente "Xen", chiedi quale variante viene utilizzata. HVM è un normale VPS moderno. PV è un piano per cui dovresti pagare meno.

Container VPS: LXC e la linea OpenVZ

Un VPS container è un insieme di namespace Linux (viste separate degli ID dei processi, dei mount, delle interfacce di rete, del nome host e degli utenti) oltre ai cgroups (control group, cioè i limiti delle risorse imposti dal kernel) che viene eseguito sul kernel del provider. Il tuo init è un processo sull'host. Il tuo ls viene eseguito direttamente sul kernel dell'host, senza emulazione e senza un secondo scheduler intermedio. Per questo i container sono veloci e consentono un'elevata densità.

I nomi riportati nelle pagine degli ordini sono LXC, container Proxmox VE (che sono LXC), OpenVZ e Virtuozzo. OpenVZ 7 e Virtuozzo sono i discendenti commerciali della stessa idea.

Per te cambiano quattro aspetti:

• Moduli. modprobe non inserirà nulla. Se WireGuard, ZFS o uno specifico modulo netfilter non è già presente nel kernel del provider, non puoi utilizzarlo.
• sysctl. La maggior parte di /proc/sys è in sola lettura. La rete usa un namespace reale, quindi net.ipv4.ip_forward e gli elementi adiacenti sono generalmente scrivibili. I parametri che riguardano l'intera macchina, come vm.swappiness o fs.file-max, appartengono all'host.
• Container annidati. Docker all'interno di un container LXC funziona solo se il provider abilita il nesting e il driver di storage è compatibile. Verificalo prima dell'acquisto, senza darlo per scontato.
• La versione del kernel. Erediti il calendario degli aggiornamenti del provider, inclusi i riavvii.

Come stabilire quale dei due hai acquistato

Esegui questi comandi sul server e valuta insieme i risultati. Nessun singolo comando è sufficiente per stabilirlo.

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 stampa un identificatore breve appartenente a un vocabolario fisso. Il lato macchina include kvm, qemu, xen, amazon e vmware. Il lato container include lxc, lxc-libvirt, openvz, docker e systemd-nspawn. Quando non rileva nulla, stampa none e termina con un codice diverso da zero. La forma -c restituisce risultati solo per le tecnologie container. Pertanto, qualsiasi risposta diversa da none risolve la questione, indipendentemente da quanto indicato nella pagina di vendita.

lscpu indica il fornitore dell'hypervisor e specifica se il tipo di virtualizzazione è full o para. Questo consente di distinguere Xen HVM da Xen PV. /sys/hypervisor/type esiste solo in ambiente Xen.

Il controllo /lib/modules viene spesso saltato, ma è quello più diretto. Se la directory relativa alla versione del kernel in esecuzione è assente o vuota mentre il sistema sta chiaramente eseguendo quel kernel, il kernel non proviene dal filesystem del sistema. Proviene dall'host e il relativo albero dei moduli non è mai stato installato nell'immagine. Questo indica un container.

Per una seconda verifica indipendente, sudo apt install -y virt-what && sudo virt-what esegue i test di rilevamento come strumento dedicato. Richiede root e non stampa nulla su bare metal.

Perché /proc descrive la macchina sbagliata in un container

Su un guest KVM o Xen, /proc/meminfo è la contabilità della memoria gestita dal kernel del guest, relativa alla memoria assegnata dall’hypervisor. Il dato riguarda la macchina guest e non fornisce informazioni sull’host. Questo è il principio alla base di una macchina virtuale.

In un container non esiste un secondo kernel che gestisca questa contabilità, quindi /proc corrisponde a quello dell’host: /proc. LXCFS è un filesystem di piccole dimensioni che riscrive alcuni di questi file in base ai limiti del cgroup e gestisce /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats e /sys/devices/system/cpu/online. Proxmox lo monta per impostazione predefinita. Molti provider più piccoli non lo fanno; di conseguenza free -m restituisce la memoria totale dell’host, nproc può indicare tutti i core della macchina e uptime mostra da quanto tempo è in esecuzione l’host.

Questo non è un problema solo estetico, perché i software dimensionano le proprie risorse in base a questi file. nginx con worker_processes auto conta i core che riesce a vedere. make -j$(nproc), su un host con 64 core e una quota di 2 core, avvia 64 compilatori. Una JVM o un database che calcola la dimensione della cache a partire da MemTotal sceglie un valore che il cgroup non consentirà; quando il processo raggiunge il limite, il kernel lo termina. Questa terminazione viene registrata nel log del kernel dell’host, che non è possibile leggere.

I valori autorevoli si trovano nel cgroup, non in /proc:

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

Questi sono percorsi di cgroup v2, utilizzati dalle distribuzioni attuali. La lettura di memory.max da parte di max indica che a quel livello non è impostato alcun limite. cpu.max stampa una quota e un periodo espressi in microsecondi, quindi 200000 100000 corrisponde a due core di tempo CPU per periodo. Su un host cgroup v1 meno recente, gli stessi valori si trovano in /sys/fs/cgroup/memory/memory.limit_in_bytes e /sys/fs/cgroup/cpu/cpu.cfs_quota_us.

Swap: chi lo gestisce effettivamente

Su KVM e Xen, lo swap è a tua disposizione. È un file o una partizione sul disco e il paging viene gestito dal tuo kernel.

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

swapon --show dovrebbe ora elencare il file con dimensioni e priorità. Se swapon rifiuta il file, crealo invece con dd if=/dev/zero of=/swapfile bs=1M count=2048, perché alcuni filesystem rifiutano un file preallocato con extent non scritti. Aggiungi /swapfile none swap sw 0 0 a /etc/fstab, altrimenti lo swap viene rimosso al successivo riavvio.

In un container, nessuno di questi elementi è sotto il tuo controllo. swapon richiede una capability che un container senza privilegi non possiede, quindi la creazione di un file di swap personale fallisce per mancanza di permessi e non arriva mai al disco. Quello che il piano definisce swap è un'impostazione cgroup sull'host, memory.swap.max con cgroup v2, supportata dai dispositivi di swap dell'host. I piani OpenVZ meno recenti vendevano una disponibilità "vswap" che si comportava più come un credito per i picchi che come spazio su disco. Puoi leggere il limite massimo. Non controlli il dispositivo sottostante.

Virtualizzazione annidata e il flag CPU che trae in inganno

La virtualizzazione annidata consiste nell'eseguire un hypervisor all'interno del proprio VPS: un guest QEMU, un box Vagrant oppure un laboratorio di virtualizzazione annidata con le proprie VM. Devono essere soddisfatte entrambe le condizioni. Il provider deve abilitare la virtualizzazione annidata sull'host e al guest devono essere esposte le estensioni di virtualizzazione della CPU.

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

Su un guest KVM con la virtualizzazione annidata abilitata, /dev/kvm esiste e kvm-ok indica chiaramente se è possibile usare l'accelerazione. Su Xen HVM è tecnicamente possibile, ma viene offerta raramente. Su Xen PV non è possibile.

In un container, il controllo fallisce in modo istruttivo. /proc/cpuinfo è il file dell'host, quindi il flag vmx o svm è presente ed è realmente corretto: la CPU fisica sottostante dispone effettivamente di quelle istruzioni. Tuttavia, la CPU non è a tua disposizione. Nel tuo namespace non esiste alcun /dev/kvm, non puoi caricare il modulo kvm_intel e il flag appena letto descrive la macchina su cui sei guest, non una macchina che controlli. Questo è il caso più evidente della regola generale. In un container, /proc descrive il namespace e l'hardware circostante, non un server di tua proprietà.

AES-NI e le funzionalità della CPU esposte dal piano

AES-NI (advanced encryption standard new instructions) è un insieme di istruzioni della CPU che rende la cifratura AES diverse volte più veloce rispetto allo stesso calcolo eseguito via software. La terminazione TLS, la cifratura dei dischi, SSH e le pipeline di backup sfruttano tutte queste istruzioni.

Su KVM, ciò che vede il guest dipende dal modello di CPU configurato dal provider per QEMU. Con il passthrough dell'host sono visibili i flag reali. Con un modello generico come qemu64, oppure con una baseline volutamente datata scelta per consentire la migrazione dei guest tra host non omogenei, il flag aes può essere assente e OpenSSL passa senza segnalarlo al percorso software.

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

Il terzo comando è l'esempio riportato nel manuale di OpenSSL per disabilitare queste istruzioni nella libreria: cancella il bit AES-NI e il bit VAES, lasciando invariato il resto. Confronta i due valori di throughput. Se sono simili, il percorso accelerato non veniva usato già in precedenza e vale la pena dedicare cinque minuti a verificare correttamente AES-NI su un VPS prima di sottoscrivere un piano.

Un container non ha un modello di CPU davanti a sé, quindi i flag in /proc/cpuinfo sono quelli reali dell'host e si applicano anche al container. Questo è un vantaggio concreto dei piani basati su container ed è l'unico punto di questa guida in cui il kernel condiviso opera a tuo favore.

Da dove proviene lo steal time e perché un container non ne ha

Lo steal time è il tempo durante il quale la CPU virtuale era pronta per essere eseguita, ma non è stata eseguita perché l'hypervisor stava eseguendo il carico di un altro tenant. Viene mostrato come st in top e vmstat, oltre che come ottavo campo della riga cpu in /proc/stat.

Un guest non può misurarlo autonomamente, perché durante l'intervallo sottratto non sta eseguendo istruzioni. Deve essere l'hypervisor a comunicarglielo. KVM scrive un totale progressivo in una pagina che il guest registra tramite la propria interfaccia per l'orologio paravirtualizzato, mentre Xen mantiene un'area dello stato di esecuzione per ogni vCPU con la stessa funzione. Il valore letto è la dichiarazione dell'hypervisor stesso: per questo esiste ed è ragionevole considerarlo affidabile.

Un valore elevato di steal indica che l'host è sovrallocato e che, in quel momento, i tenant vicini stanno utilizzando la CPU. Rende visibile il rapporto tra le vCPU vendute e i core fisici; leggere lo steal time per individuare un tenant rumoroso è l'unica misurazione che permette di capire se un piano ha davvero le dimensioni dichiarate.

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

In un container quella colonna non cambia, perché tra te e lo scheduler non c'è un hypervisor. I tuoi processi vengono accodati insieme a quelli di tutti gli altri tenant come normali task nello scheduler della CPU dell'host. La contesa si manifesta semplicemente nel fatto che il lavoro richiede più tempo, senza un contatore che ne identifichi la causa. L'equivalente più vicino è il throttling imposto dalla quota: quando il provider imposta cpu.max, /sys/fs/cgroup/cpu.stat conta i periodi nr_throttled e i microsecondi throttled_usec trascorsi in attesa della finestra di quota successiva. Questo riguarda soltanto la tua quota e non misura mai la concorrenza degli altri tenant. Attenzione: se l'host dei container del provider è a sua volta una macchina virtuale, in /proc/stat può comparire un valore di steal, che appartiene a quell'host e non a te.

Sovrapprovisionamento e perché il piano container costa meno

La risposta è semplice. Un piano container costa meno perché il provider condivide la stessa macchina con più clienti.

La differenza è maggiore per la memoria. La RAM di un guest KVM è assegnata a quel guest, quindi un host con 256 GB vende circa 256 GB di guest, al netto dell'overhead. Il limite di memoria di un container è invece un tetto, non una prenotazione. La memoria che un container non utilizza è immediatamente disponibile per gli altri. Per questo il provider può vendere limiti che, sommati, arrivano a diverse volte la RAM fisica, mantenendo comunque prestazioni accettabili quasi sempre. Non c'è nulla di falsificato. Il modello funziona finché non ci sono abbastanza tenant attivi contemporaneamente; in quel momento smette di funzionare per tutti.

La CPU è sovrapprovisionata in tutti i tipi di piano, incluso KVM, perché vengono vendute più vCPU dei core disponibili. Lo storage è quasi sempre soggetto a thin provisioning. I container aumentano ulteriormente la densità: usano un solo kernel e una sola page cache e non richiedono un processo QEMU per ogni guest. Di conseguenza, un host può contenere diverse volte più tenant.

Il compromesso riguarda l'isolamento, ed è un aspetto tecnico concreto, non un allarmismo. Condividete il kernel, quindi un bug del kernel diventa un problema condiviso; inoltre, un container escape porta direttamente sull'host. Per evadere da una macchina virtuale serve un bug nell'hypervisor, che rappresenta un obiettivo molto più ristretto e difficile da sfruttare. Dovete inoltre seguire il calendario del provider per gli aggiornamenti del kernel e i riavvii. Se uno di questi aspetti è importante per voi, consultate quanto è realmente sicuro il VPS hosting prima di scegliere basandovi soltanto sul prezzo.

Quale acquistare

Acquista un KVM quando ti serve un kernel tuo: moduli WireGuard o ZFS, una versione specifica del kernel, la virtualizzazione annidata, il controllo effettivo dello swap oppure un confine che puoi spiegare a un auditor. Acquista un piano con container quando esegui servizi ordinari con un budget limitato, il kernel del provider è aggiornato e hai verificato che le funzionalità da cui dipendi siano già compilate al suo interno. Considera Xen HVM equivalente a KVM per la maggior parte degli utilizzi e poni questa domanda prima di acquistare un'offerta ancora venduta come Xen PV.

Due modelli non rientrano in questa distinzione. Le microVM Firecracker forniscono a ogni tenant un kernel reale con costi di avvio simili a quelli di un container; è il modello usato dalle piattaforme serverless. I container di sistema Incus consentono di gestire autonomamente il modello dei container su hardware sotto il tuo controllo, una situazione diversa rispetto all'acquisto di un container come servizio. Se il problema è la terminologia, che cosa sia realmente un VPS e la differenza tra un VPS, una VM e una VPC illustrano i termini che questa guida presuppone tu conosca già.

FAQ

Come faccio a capire se il mio VPS usa KVM o un container?

Esegui systemd-detect-virt -c. Qualsiasi risposta diversa da none indica che ti trovi in un container, indipendentemente dal nome del prodotto associato al piano. Confermalo in altri due modi, perché il rilevamento può essere alterato. lscpu identifica il fornitore dell'hypervisor e indica se il tipo di virtualizzazione è completa o para-virtualizzata. ls /lib/modules/$(uname -r) è assente o vuoto in un container, perché il kernel in esecuzione proviene dall'host e il relativo albero dei moduli non è mai stato installato nel filesystem. sudo virt-what fornisce una risposta indipendente tramite uno strumento scritto appositamente per questa verifica.

Perché free -m mostra molta più memoria di quella inclusa nel mio piano?

Usi un piano container senza LXCFS montato; quindi /proc/meminfo è il file dell'host e free riporta correttamente la memoria dell'host. Il limite effettivo è quello del cgroup. Leggi /sys/fs/cgroup/memory.max per il limite e /sys/fs/cgroup/memory.current per l'utilizzo corrente, oppure /sys/fs/cgroup/memory/memory.limit_in_bytes su un host meno recente con cgroup v1. Configura ogni servizio che dimensiona una cache o un pool di worker usando quel valore, non free.

Posso eseguire Docker o WireGuard su un VPS LXC?

A volte, ma mai in funzione di qualcosa che installi tu. Entrambi dipendono dal kernel del provider, perché non puoi caricarvi un modulo. WireGuard funziona quando il modulo è già presente sull'host ed è esposto al tuo ambiente; in caso contrario, l'implementazione userspace wireguard-go è l'alternativa. Docker richiede che il provider abiliti il nesting e che sia disponibile un driver di storage funzionante all'interno di un container. Chiedi conferma prima dell'acquisto oppure esegui i test durante un periodo dal quale puoi recedere.

Perché il mio VPS container non riporta mai lo steal time?

Lo steal time esiste solo quando un hypervisor pianifica una CPU virtuale. Viene riportato perché l'hypervisor scrive il valore in una pagina che il kernel può leggere. Un container non ha un hypervisor sottostante. I tuoi processi sono normali task nello scheduler dell'host, quindi la contesa si manifesta come un rallentamento generale, senza un contatore specifico da consultare. Leggi invece /sys/fs/cgroup/cpu.stat: nr_throttled e throttled_usec contano il tempo trascorso dal tuo cgroup in attesa della successiva finestra di quota CPU. È il fenomeno più simile allo steal time disponibile in un container.