Come funziona KVM dietro le quinte
KVM converte il kernel Linux in un hypervisor Type-1 esponendo un dispositivo a caratteri /dev/kvm. Un processo user-space (tipicamente QEMU) apre quel dispositivo, chiede al kernel di creare una CPU virtuale, e poi esegue le istruzioni guest direttamente sulla CPU fisica utilizzando le estensioni di virtualizzazione hardware. Il kernel gestisce gli eventi privilegiati; tutto il resto viene eseguito alla velocità nativa.
Tre componenti fanno funzionare KVM. Primo, il modulo del kernel kvm.ko gestisce la virtualizzazione di CPU e memoria ed espone l'interfaccia /dev/kvm. Secondo, un modulo specifico per architettura — kvm-intel.ko per Intel VT-x o kvm-amd.ko per AMD-V — traduce tra l'API generica di KVM e le istruzioni di virtualizzazione della CPU sottostante. Terzo, un processo hypervisor user-space come QEMU, cloud-hypervisor o Firecracker fornisce l'emulazione dei dispositivi: dischi virtuali, NIC, controller USB e firmware BIOS o UEFI. Poiché il kernel Linux stesso è l'hypervisor, ogni scheduler Linux, gestore di memoria e funzionalità di sicurezza si applica alle VM nello stesso modo in cui si applica ai processi nativi. Un guest KVM è semplicemente un processo pesante dal punto di vista del kernel, motivo per cui strumenti come top, perf e cgroups funzionano su di esso senza modifiche.
KVM vs OpenVZ vs VMware ESXi vs Hyper-V
KVM fornisce virtualizzazione hardware completa con un kernel guest separato per ogni VM. OpenVZ utilizza la containerizzazione a livello di OS dove ogni container condivide il kernel host. VMware ESXi è un hypervisor Type-1 bare-metal proprietario con il proprio kernel (VMkernel). Hyper-V è l'hypervisor Type-1 basato su Windows di Microsoft. Solo KVM, ESXi e Hyper-V offrono un kernel guest reale e isolato.
OpenVZ (e il suo successore Virtuozzo) è una tecnologia di container, non un hypervisor. Ogni container OpenVZ condivide il kernel Linux dell'host, il che significa che non può eseguire una versione del kernel diversa, non può caricare moduli del kernel personalizzati e non può eseguire un sistema operativo non Linux. Il compromesso è la densità: poiché non c'è overhead del kernel per VM, un host OpenVZ può comprimere più container sullo stesso hardware, motivo per cui i piani VPS condivisi di basso livello lo utilizzavano frequentemente. VMware ESXi è lo standard enterprise per la virtualizzazione Type-1 ma viene fornito come prodotto closed-source con licenze per socket che storicamente l'hanno escluso dal prezzo dell'hosting VPS commodity. Hyper-V domina gli ambienti Windows-server e si integra strettamente con Active Directory e System Center, ma è una scelta meno comune per le flotte di hosting Linux-pesanti. KVM è diventato il default per l'hosting VPS moderno perché è open source, mainline nel kernel, supporta qualsiasi OS guest che gira su x86_64 o aarch64, e ha un ecosistema di gestione maturo (libvirt, oVirt, Proxmox, OpenStack Nova).
Perché KVM è il default moderno per VPS
KVM è diventato la tecnologia VPS dominante perché offre a ogni cliente un kernel reale e isolato senza pagare licenze in stile VMware. Supporta guest Linux, Windows, BSD e Solaris, gira su hardware commodity x86_64 e ARM, ed è integrato in ogni grande stack di orchestrazione cloud — OpenStack, Proxmox VE, Kubernetes via KubeVirt, e AWS Nitro tutti si basano su di esso.
Tre forze hanno convergiuto per rendere KVM lo standard. Primo, le estensioni di virtualizzazione hardware sono diventate universali: Intel VT-x è stato spedito nei chip Core 2 nel 2006 e AMD-V nei primi Athlon 64, quindi all'inizio degli anni 2010 essenzialmente ogni CPU server poteva ospitare KVM a velocità quasi nativa. Secondo, la community Linux ha rifiutato di adottare la paravirtualizzazione in stile Xen nel mainline, ma ha mainlined KVM nel 2007, dando istantaneamente a ogni distribuzione un hypervisor integrato. Terzo, l'ecosistema cloud pubblico ha investito pesantemente: Google Cloud Engine è stato lanciato su KVM, AWS è migrato da Xen a un'architettura Nitro basata su KVM, e OpenStack si è standardizzato su KVM come hypervisor di riferimento. I fornitori VPS più piccoli beneficiano di questa attrazione gravitazionale perché lo stesso tooling che esegue le flotte degli hyperscaler — libvirt, driver virtio, cloud-init — gira anche su un singolo rack di server commodity.
Caratteristiche di prestazioni reali: CPU steal, IO e overhead
Su un host KVM correttamente provisionato, si aspetti un overhead CPU a singola cifra percentuale rispetto al bare metal, latenza di rete sub-millisecondo aggiunta ai percorsi di rete locali, e l'80-95% degli IOPS disco nativi quando si usa virtio-blk o virtio-scsi con un driver paravirtualizzato. Un tempo di CPU steal sostenuto sopra il 5% è il segno canonico di overcommit dell'host e un forte segnale di aggiornamento.
Tre numeri contano per un guest KVM in produzione. Il tempo di CPU steal, esposto in /proc/stat come ottavo campo, misura la percentuale di tempo in cui la CPU virtuale era pronta per essere eseguita ma la CPU fisica era occupata a eseguire altri guest. Qualsiasi cosa sotto l'1-2% è normale rumore di fondo; valori sostenuti sopra il 5% significano che l'host è overcommitted e il Suo carico di lavoro viene strozzato. L'IO wait, esposto da strumenti come iostat e top, misura la percentuale di tempo in cui la CPU è stata bloccata su disco o rete. Con i driver paravirtualizzati virtio e lo storage NVMe moderno di backup, un IO wait sostenuto sopra il 20% su un carico di lavoro che dovrebbe essere CPU-bound è un forte segno che il sottosistema disco è saturo. Il throughput di rete su virtio-net dovrebbe raggiungere l'80-95% del line rate del NIC fisico; qualsiasi cosa significativamente al di sotto indica un offload mal configurato o un vecchio driver e1000 emulato.
Quando NON usare KVM
KVM è la scelta sbagliata in tre situazioni: carichi di lavoro containerizzati ad altissima densità dove l'overhead del kernel per VM domina, deployment sensibili alla licenza Windows dove il pricing SPLA di Hyper-V è significativamente più economico, e certi scenari di passthrough hardware a bassa latenza dove SR-IOV o GPU passthrough è scarsamente supportato sul Suo specifico modello di NIC o GPU.
Per microservizi containerizzati che non necessitano di isolamento del kernel, i container Linux (Docker, Podman, Kubernetes) eseguiti direttamente su bare metal supereranno qualsiasi VPS basato su KVM di 3-5x perché ogni container è solo un gruppo di processi con namespace e cgroup. I fornitori VPS a basso costo sensibili alla densità hanno storicamente scelto OpenVZ per lo stesso motivo. I deployment Windows-pesanti — in particolare quelli che eseguono licenze Windows Server acquistate tramite SPLA — a volte pagano significativamente meno su Hyper-V che su KVM a causa di come Microsoft prezza le licenze guest su hypervisor concorrenti. Infine, certi scenari di passthrough hardware sono ancora dolorosi su KVM: il GPU passthrough richiede gruppi IOMMU che siano puliti e isolati, alcuni NIC consumer non hanno supporto SR-IOV, e il passthrough PCIe di drive NVMe a volte attiva workaround per bug di reset. Per il 95% dei carichi di lavoro VPS Linux generici, nessuno di questi si applica e KVM è il default corretto.
Come verificare che un VPS sia veramente basato su KVM
All'interno di un guest Linux, esegua `systemd-detect-virt` — dovrebbe stampare `kvm`. Verifichi con `lscpu` (la riga 'Hypervisor vendor' dovrebbe leggere 'KVM') e `dmesg | grep -i kvm`. Se vede 'OpenVZ', 'lxc' o 'VMware' invece, il Suo fornitore sta utilizzando una tecnologia diversa anche se il marketing afferma il contrario.
Prima di firmare un contratto, esegua una piccola batteria diagnostica su un VPS di prova. Esegua `systemd-detect-virt` per l'output di rilevamento canonico. Esegua `cat /proc/cpuinfo | grep -E 'vmx|svm'` per confermare che le estensioni di virtualizzazione hardware vengano passate (alcuni fornitori le rimuovono, rompendo la virtualizzazione nidificata). Esegua `uname -r` per verificare di vedere un kernel specifico per guest piuttosto che un kernel host condiviso — su un vero VPS KVM può installare un kernel diverso tramite `apt install linux-image-...` o `dnf install kernel-...` e riavviare in esso. Su OpenVZ non può. Infine, controlli `/proc/user_beancounters` — se quel file esiste, l'host sta eseguendo OpenVZ indipendentemente da ciò che dice il marketing.