VM vs LXC su Proxmox: 17 container, zero VM e la matematica che decide

SSO e 2FA su tutto con Authentik — un login per il tuo homelab di produzione

10 servizi, 10 password diverse, zero audit. Poi ho installato Authentik: un identity provider self-hosted con SSO, 2FA e audit log centralizzato. Come e perché l'ho fatto nel mio homelab.

Sul mio cluster pve+pve2 girano 17 LXC e zero VM. La scelta VM vs LXC Proxmox non l'ho fatta per ideologia: per matematica.

Tra VM e LXC su Proxmox la scelta è netta: i container LXC danno 8× la densità a costo di un kernel condiviso, le VM via QEMU/KVM danno isolamento completo a costo di 25-40 secondi di boot e centinaia di MB idle. Per un servizio Linux fidato in casa, vince LXC. Per Windows, FreeBSD, codice non fidato o cluster con live migration, vince la VM. Tutto il resto è marketing.

Il dogma "container = sempre meglio" è proprio questo: dogma. La documentazione ufficiale Proxmox stessa scrive che "full virtual machines provide better isolation". Quando qualcuno ti dice di mettere tutto in LXC senza chiederti il workload, ti sta vendendo religione, non ingegneria.

Cos'è un LXC e cos'è una VM su Proxmox

Un container LXC su Proxmox è un'istanza Linux che condivide il kernel con l'host. Niente hypervisor in mezzo, niente OS guest da emulare: i processi del container girano direttamente sul CPU scheduler dell'host, dentro namespace e cgroup che li tengono isolati dagli altri. Una VM, invece, è una macchina completa gestita da QEMU/KVM — un hypervisor di tipo 1 — con il suo kernel guest, la sua memoria emulata, il suo BIOS/UEFI virtuale. Due paradigmi diversi, sullo stesso hypervisor.

They use the kernel of the host system that they run on, instead of emulating a full operating system. — Documentazione ufficiale Proxmox (in italiano: usano il kernel del sistema host su cui girano, invece di emulare un sistema operativo completo)

Da questa singola differenza discende tutto il resto: densità, boot time, RAM idle, sicurezza, compatibilità sono corollari del fatto che LXC condividono il kernel e le VM no. Conseguenza diretta numero uno: dentro un LXC girano solo distribuzioni Linux. "It is not possible to run other operating systems like, for example, FreeBSD or Microsoft Windows inside a container", scrive la doc. Niente Windows, niente BSD, niente Solaris. Se il vendor ti dà un'ISO che non sia Linux, hai già finito di pensare: VM.

Quanti LXC stanno in 48 GB di RAM (e quante VM no)

La densità è il primo motivo per cui un homelab serio sceglie LXC. Sul nodo principale del mio cluster (Ryzen 7 1800X, 48 GB di RAM, affiancato da un i7-6700K con 16 GB sul secondo nodo) tengo in piedi 17 container Linux — mix Debian 12 e Ubuntu 24.04 — senza che il sistema sudi: il mio resolver DNS di backup gira in CT 124 con ~40 MB di RAM idle, e ne avevamo parlato in dettaglio nell'analisi del cluster Ryzen. La stessa Debian 12 in VM sullo stesso host idle parte da 600 MB. Stesso OS, stessi servizi, 15× più memoria sprecata.

Non sono numeri da cherry-picking. La tabella dei benchmark indipendenti (ashimov.com, propelrc.com) dà LXC tra 50 e 100+ container per host vs 10-30 VM per host. Se scegli VM per tutto su 48 GB di RAM, ti fermi a 4-5 macchine vere prima che lo swap inizi a singhiozzare. Con LXC arrivo tranquillo a 17, e potrei spingermi oltre. La differenza non è marginale: è strutturale.

I numeri di I/O del benchmark utente tomee (forum ufficiale, thread 155546) sono ancora più crudi: oltre 2× di IOPS in random read 16k a favore di LXC, latenza che scende da 146,94 µs a 74,91 µs. Lo staff (Falk R.) ha confermato che il delta è plausibile per workload database I/O-bound. Se il tuo Postgres o MariaDB casalingo è il collo di bottiglia, sai dove infilarlo.

Sicurezza: il container LXC condivide il kernel?

Sì, e questo è il punto. Un container LXC condivide il kernel con l'host: significa che un kernel exploit come Dirty COW (CVE-2016-5195) o Dirty Pipe (CVE-2022-0847) impatta tutti i container in un colpo solo. Una VM no — il suo kernel guest è isolato dal kernel host. È la differenza fra un singolo punto di fallimento e una compartimentazione vera. Il team upstream LXC è esplicito: "those containers aren't and cannot be root-safe" — quei container non sono e non possono essere a prova di root, parlando dei privileged. Tradotto: in privileged mode il kernel exploit è game over.

I container unprivileged riducono drasticamente la superficie d'attacco grazie alla mappatura UID: l'uid 0 dentro il container diventa uid 100000 sull'host, quindi un escape che ottiene root nel container ottiene un utente non-privilegiato fuori. Sono "safe by design" secondo la documentazione upstream. Ma resta il kernel condiviso: un bug in cgroups (CVE-2022-0492) o filesystem context (CVE-2022-0185) ti taglia la gamba lo stesso.

Quando conviene una VM su Proxmox?

Una VM sull'hypervisor conviene in cinque scenari precisi, e fuori da quelli è quasi sempre overkill. OS non-Linux: Windows Server, FreeBSD, OPNsense, pfSense. Vendor che lo richiede esplicitamente o stack Java enterprise grossi, come NAKIVO Backup & Replication che ho infilato in CT 128 con nesting=1 e features=mount=nfs;cifs — funziona, ma è un setup non standard che il vendor non avallerebbe ufficialmente. Stack Docker Compose grossi, multi-tenancy o codice non fidato, e cluster con live migration. Tutto il resto è LXC fino a prova contraria.

Sul mio cluster oggi non gira nessuna VM: tutti e 17 i workload sono container LXC unprivileged, e il firewall casalingo è hardware esterno (Deciso DEC750 con OPNsense), non un'appliance virtuale. Se domani aggiungessi un Windows Server, un OPNsense in cluster o uno stack Docker Compose multi-servizio, quelle finirebbero in VM perché LXC non le copre. È una scelta che si fa per vincolo tecnico, non per gusto.

L'obiezione vera: live migration in cluster

Qui arriva l'obiezione che vale la pena prendere sul serio. LXC su Proxmox non supporta live migration: quando sposti un container fra due nodi del cluster, viene fermato e ripartito sull'altro nodo. Per un homelab è 5-10 secondi di downtime — chi se ne frega. Per un'azienda che sposta workload durante un upgrade kernel host senza fermare niente, è un dealbreaker.

I don't run LX(C) containers in our clusters due to the non-live-migratability. — LnxBil, Proxmox Distinguished Member, forum staff (in italiano: non uso container LXC nei nostri cluster a causa dell'impossibilità di live migration)

La citazione è di uno staffer Proxmox che spinge container su KVM in cluster di produzione. Ha ragione lui? In quel contesto, sì: la non-migratability è il motivo principale per cui in azienda si resta su KVM. Ma non è il tuo caso se hai un homelab a uno o due nodi che riavvia di notte mentre tu dormi. La conclusione si capovolge appena cambia la condizione. Lo riconosce la documentazione stessa: "for use cases demanding maximum isolation and the ability to live-migrate, nesting containers inside a Proxmox QEMU VM remains a recommended practice". In pratica: se vuoi container ma anche live migration, metti Docker dentro una VM Linux e migra la VM — pattern raccomandato dallo staff da anni, valido anche dopo il 9.1.

Docker dentro LXC: la regola, l'eccezione 9.1, e perché lo staff frena

Per anni la regola è stata: Docker non si mette dentro LXC, si mette in una VM Linux dedicata. La FAQ ufficiale lo dice chiaro, e chiunque abbia provato a far convivere Docker con cgroup unprivileged sa perché — conflitti AppArmor, bind mount NAS che vanno in segmentation fault, overlay storage driver capricciosi. Proxmox VE 9.1 di novembre 2025 ha cambiato in parte le carte in tavola con il supporto OCI image nativo per LXC, basato su kernel 6.17.2, LXC 6.0.5 e QEMU 10.1.2 della stessa release.

Tutto vero, ma lo staff non ha cantato vittoria. Sul forum ufficiale Fiona scrive: "in general it's recommended to install Docker inside a VM" — in generale è raccomandato installare Docker dentro una VM. Thomas Lamprecht aggiunge: "That one of the major reasons for why it's a tech preview, i.e., it's a bit involved" — è una delle ragioni principali per cui è ancora in tech preview, è un po' delicato. E Johannes S è ancora più diretto: "If you want to host oci-image-based applications who just work, stick with docker-vms" — se vuoi ospitare applicazioni basate su immagini OCI che funzionano e basta, resta sulle VM Docker.

• OCI-LXC è tech preview, non GA — lo dichiara lo staff stesso, non un blog di parte
• Niente Docker Compose nativo: pulli un'immagine alla volta, niente stack multi-servizio
• Niente update in-place: per aggiornare l'immagine devi ricreare il container e ri-bind dei volumi
• Niente live migration sugli OCI-LXC, esattamente come gli LXC classici
• Niente console interattiva piena, niente env iniziali agevoli
• Per Docker stack di produzione (Portainer, Traefik, 10+ servizi) → VM con Docker engine, ancora oggi

Per servizi Linux nativi che non sono Docker — come Ollama in LXC CPU-only, Nginx, Postgres, Pi-hole, AdGuard, Authentik — il container vince a mani basse, e la versione 9.1 non c'entra. La domanda non è "Docker in LXC sì o no": è "hai davvero bisogno di Docker per questo singolo servizio, o ti serve un LXC Debian con il binario nativo?". Nove volte su dieci la risposta è la seconda.

Le altre crepe degli LXC che spingono in VM

Oltre alla live migration ci sono altri quattro punti dove gli LXC mostrano i limiti, e dove la VM diventa la scelta meno faticosa. Il primo è il kernel module custom: un container non può caricare moduli propri. Se ti serve un driver fuori dal kernel host, devi caricarlo sull'host stesso e fare bind-mount nel container — workaround che rompe il principio di isolamento e rende il setup fragile a ogni upgrade kernel dell'host.

Il secondo è NFS server kernel-space: il forum Proxmox è chiaro — "Running the nfs-kernel-server inside an LXC container does not make sense and does not really work by design", cioè far girare nfs-kernel-server dentro un container LXC non ha senso e non funziona davvero per com'è progettato. Esistono workaround come Ganesha-NFS user-space o mount sull'host con bind, ma non sono trasparenti. Se devi esportare uno share NFS da una sola macchina, una VM Debian con nfs-kernel-server installato e via.

Il terzo è il mount NFS lato client + GPU passthrough esclusivo. Mount NFS in LXC è fattibile (privileged + features=nfs=1, oppure mount sull'host con bind-mount), ma è il punto in cui SELinux, cgroup e AppArmor smettono di parlarsi quando un servizio enterprise chiede block storage in modo aggressivo — sul mio NAKIVO in CT 128 ho dovuto sistemare a mano i permessi mount e disabilitare nesting profile su un paio di feature. La GPU, invece, in LXC si condivide (perfetto per Ollama o transcoding Plex), ma non si assegna in modo esclusivo: se vuoi una VM Windows con la 3060 dedicata per gaming nested o CUDA isolato, il container non è lo strumento adatto.

Come scegliere VM o LXC in trenta secondi

Smontati i miti, resta la matrice VM vs LXC Proxmox in versione operativa. Si legge dall'alto: appena una riga risponde sì, hai la tua decisione e fermi il ragionamento. La logica è semplice — partire dai vincoli duri (compatibilità OS, vendor) e scendere verso i trade-off (densità, sicurezza). Niente filosofia, solo gerarchia.

Domande frequenti su VM e LXC nell'hypervisor

Posso eseguire Windows in un container LXC?

No. La documentazione ufficiale è esplicita: "Only Linux distributions can be run in Proxmox Containers". Windows richiede una VM via QEMU/KVM, niente alternative.

LXC privileged o unprivileged, qual è la differenza?

Privileged = root nel container è root sull'host (sconsigliato dal team upstream LXC, "cannot be root-safe"). Unprivileged = uid 0 mappato a uid 100000 sull'host, container escape ottiene un utente non-privilegiato. Default Proxmox dal 2017 è unprivileged. Usa privileged solo se ti serve esplicitamente (mount NFS legacy, alcuni device passthrough).

Si può fare live migration di un LXC su VE?

No. Il container viene fermato sul nodo sorgente e ripartito sul nodo destinazione (work in progress upstream da anni). Le VM via QEMU/KVM, invece, supportano live migration nativamente. È il motivo principale per cui in cluster di produzione si preferiscono ancora le VM, anche per workload Linux puri.

Cosa è cambiato con VE 9.1 e gli OCI-LXC?

VE 9.1 (novembre 2025, kernel 6.17.2, LXC 6.0.5) introduce il supporto nativo a OCI image nei container LXC: pulli da Docker Hub o registry compatibili e converti in container LXC. È tech preview, non GA, e non sostituisce le VM Docker per stack di produzione: lo dichiara lo staff stesso. Funziona bene per servizi singoli; per Compose, Portainer e stack multi-servizio resta consigliata la VM con Docker engine.

Sul mio cluster oggi: 17 LXC, zero VM, 48 GB di RAM sul nodo principale e 16 GB sul secondo. Tutti i container sono unprivileged. Nessuna VM perché finora non c'è stato uno scenario che la richiedesse — niente Windows, niente FreeBSD, niente Docker Compose grosso di produzione. La matematica della densità non lascia margini fino a che non cambia il vincolo. Cambia il vincolo, cambia la risposta.

Fonti: Proxmox Wiki — Linux Container, Proxmox Docs — Container Toolkit (pct), Proxmox Wiki — Unprivileged LXC containers, Proxmox Docs — QEMU/KVM Virtual Machines, linuxcontainers.org — LXC Security, Proxmox VE 9.1 press release, Forum Proxmox — OCI Images in LXC (9.1), Forum Proxmox — LXC vs VM Performance (tomee, Falk R.), Forum Proxmox — Should I move from KVM to LXC (LnxBil).