Proxmox: differenza KVM vs LXC

In Proxmox VE convivono due tecnologie di virtualizzazione: KVM per macchine virtuali complete e LXC per container di sistema. Scegliere la giusta per ogni workload incide su prestazioni, isolamento e densita. Capire le differenze evita scelte sbagliate difficili da invertire in produzione.

KVM: virtualizzazione completa

KVM (Kernel-based Virtual Machine) e una virtualizzazione di tipo 1 a livello hardware. Ogni VM ha il proprio kernel, dispositivi virtuali emulati (rete, disco, CPU), BIOS/UEFI e tutto cio che ha una macchina fisica. Permette di eseguire qualsiasi sistema operativo (Linux, Windows, BSD, persino macOS in alcune configurazioni). L'overhead e contenuto grazie a virtIO e KVM accelerato hardware.

LXC: container di sistema

LXC (Linux Containers) condivide il kernel dell'host: i container sono ambienti Linux completi (init, demoni, package manager) ma senza un kernel proprio. Sono molto più leggeri delle VM: avvio in secondi, footprint memoria ridotto, accesso diretto a CPU e I/O senza emulazione. Limite: solo carichi Linux compatibili con il kernel host.

Quando usare KVM

Usa KVM per: macchine Windows, sistemi operativi diversi dall'host, kernel custom, isolamento massimo (multi-tenant), carichi che richiedono passthrough hardware (GPU, NIC SR-IOV). E la scelta predefinita per applicazioni stateful critiche, database e server di produzione esposti pubblicamente.

Quando usare LXC

Usa LXC per: servizi Linux interni, ambienti di sviluppo, microservizi, dev/test, ambienti con alta densita. Su un'host puoi avere decine o centinaia di container LXC dove avresti potuto avere solo decine di VM. Ideale per ambienti dove l'isolamento del kernel non e una priorità.

Confronto sintetico

• Overhead: KVM moderato, LXC trascurabile.
• Avvio: KVM 10-60 s, LXC 1-5 s.
• Isolamento: KVM forte, LXC condivide kernel.
• OS supportati: KVM tutti, LXC solo Linux.
• Densita: LXC molto superiore.
• Live migration: KVM si, LXC solo restart migration.
• Snapshot: entrambi, con limiti diversi.

Procedura passo-passo

1. Classifica il workload: serve OS non-Linux, kernel custom, isolamento forte?
2. Se si, KVM. Se no, valuta LXC.
3. Per LXC scarica un template da Proxmox (Debian, Ubuntu, AlmaLinux).
4. Configura le risorse (CPU, RAM, storage) e la rete (bridged o NAT).
5. Per KVM monta una ISO, configura BIOS, disco virtio, NIC virtio.
6. Imposta backup con Proxmox Backup Server.
7. Monitora con Netdata o Prometheus.

Errori comuni e come risolverli

• LXC con applicazioni che richiedono moduli kernel custom: non funzioneranno, serve KVM.
• KVM senza virtio: I/O molto più lento; configura sempre dischi virtio e NIC virtio.
• Container LXC privilegiati per default: usa container non privilegiati per maggiore sicurezza.
• Backup di LXC con applicazioni stateful: usa hook per stop/start del servizio durante backup.

Domande frequenti

D: LXC e equivalente a Docker?
R: No, LXC e un container di sistema (init, multi-process); Docker e di applicazione (single-process per container).

D: Posso mescolare KVM e LXC sullo stesso host?
R: Si, in Proxmox convivono senza problemi.

D: LXC e adatto a produzione?
R: Si, ma con backup, monitoring e isolamento accurati.

Approfondimento tecnico: namespace e cgroup

I container LXC si basano su due primitive del kernel Linux: namespace (isolano PID, network, mount, user, IPC, UTS) e cgroup (limitano CPU, RAM, I/O, network). Un container LXC e un'insieme di processi che condividono namespace separati ma vedono lo stesso kernel dell'host. Per questo gli aggiornamenti kernel dell'host beneficiano tutti i container, ma vincolano i container al sistema dell'host.

KVM invece sfrutta le estensioni hardware VT-x (Intel) e AMD-V: il kernel host crea un sub-kernel completo per ogni VM, con vCPU, RAM, devices virtuali. L'overhead e maggiore (5-10 percento di CPU, qualche centinaio di MB di RAM in più) ma l'isolamento e totale: una vulnerabilita kernel della VM non tocca l'host.

Scenari d'uso reali

Una web agency usa LXC per ambienti dev/staging di siti WordPress: bootate in 2 secondi, decine per host, sviluppatori felici.

Un provider VPS vende VM KVM ai clienti per garantire isolamento massimo e supporto Windows.

Un laboratorio interno di una startup mescola: LXC per microservizi interni, KVM per Windows test e ambienti molto isolati.

Checklist operativa per la scelta

• OS guest non-Linux o kernel custom: KVM obbligatorio.
• Isolamento massimo richiesto (multi-tenant): KVM.
• Servizi Linux interni leggeri ad alta densita: LXC.
• Container LXC non privilegiati per maggiore sicurezza.
• KVM con dispositivi virtio per performance ottimali.
• Backup specifico per ogni tecnologia.
• Limiti cgroup configurati per evitare contesa.

Risorse e riferimenti

Documentazione QEMU/KVM su linux-kvm.org. LXC su linuxcontainers.org. Comparativa LXC vs Docker: docs di LXC e di Docker. Firecracker di AWS combina vantaggi di entrambi (VM leggere per multi-tenant). Per scenari Kubernetes, Kata Containers isola pod via mini-VM.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su proxmox richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.