VM vs LXC su Proxmox: 14 container, 2 VM e la matematica che decide

ZFS, backup e disaster recovery — i buchi che ho trovato nel mio homelab

ZFS mirror, replica cross-node ogni 15 minuti, 5 job vzdump stratificati. Pensavo di essere protetto. Poi ho controllato davvero: il mirror non era un mirror, i backup stavano sulla root, e l'offsite era vuoto.

Sul mio cluster pve+pve2 girano 14 LXC e 2 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

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 64 GB di RAM (e quante VM no)

La densità è il primo motivo per cui un homelab serio sceglie LXC. Sul mio Ryzen 7 5825U con 64 GB di RAM tengo in piedi 14 container Debian 12 più 2 VM senza che il sistema sudi: homelabz.cc gira in CT 110 con 80 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, 7,5× 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 64 GB, ti fermi a 5-6 macchine vere prima che lo swap inizi a singhiozzare. Con LXC arrivi tranquillo a 14, e potresti spingerti 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" 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: NAKIVO Backup & Replication non gira in LXC, e ne ho fatto esperienza diretta installandolo su Proxmox 9.1. 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 pfSense storico è in VM perché il kernel è BSD, NAKIVO è in VM perché il vendor lo richiede e mounting NFS+block storage in LXC mi dava troppi conflitti SELinux. Punto. Le altre 14 unità sono LXC perché non c'era alcun motivo razionale per pagare il pedaggio QEMU.

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

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". Thomas Lamprecht aggiunge: "That one of the major reasons for why it's a tech preview, i.e., it's a bit involved". E Johannes S è ancora più diretto: "If you want to host oci-image-based applications who just work, stick with docker-vms".

• 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". 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 il mio NAKIVO ha smesso di collaborare e ho dovuto pivottare su VM — SELinux, cgroup e AppArmor non si parlano sempre bene quando un servizio enterprise chiede block storage. 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: 14 LXC, 2 VM, 64 GB di RAM. Nessuno dei container è in privileged mode. Nessuna VM gira lì per moda — pfSense ci sta perché il kernel è BSD, NAKIVO ci sta perché il vendor lo impone. Tutto il resto è container, perché la matematica non lascia margini. Cambia la matematica, 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).