Proxmox VE per Svogliati - Il datacenter completo che gira su un Mini PC

01 / 12

Cos'è Proxmox VE

Un hypervisor type-1 open-source che combina KVM (VM) e LXC (container) con un pannello web, su Debian.

🏫 La definizione tecnica

Proxmox Virtual Environment (abbreviato PVE o "Proxmox") è una distribuzione Linux basata su Debian, sviluppata da Proxmox Server Solutions GmbH (Vienna), che integra KVM per le macchine virtuali full e LXC per i container Linux, sotto un'unica web UI (porta 8006) e una CLI coerente.

È un hypervisor di tipo 1 (bare-metal): si installa direttamente sul ferro come sistema operativo dell'host, non gira sopra Windows o un altro OS. Open source (AGPLv3), gratuito da scaricare e usare. Subscription commerciali esistono ma sono opzionali per accedere al repository "enterprise" testato meglio.

2008

prima release

AGPLv3

licenza

8006

porta web UI

nodi per HA

Cosa contiene la scatola

🧮 KVM/QEMU

Virtualizzazione hardware-assistita per VM Linux/Windows/BSD/macOS. Performance vicine al bare-metal con Intel VT-x / AMD-V.

📦 LXC

Container Linux full-OS, alternativa leggera alle VM. Più densi, boot in 1 secondo, condividono il kernel dell'host.

🌐 Cluster

Fino a ~32 nodi sotto un solo pannello. Corosync per messaging, pmxcfs (filesystem distribuito) per la configurazione condivisa.

♻️ HA Manager

Failover automatico di VM/CT su altri nodi quando uno cade. Richiede 3+ nodi, watchdog, storage condiviso o replicato.

💾 Storage

ZFS, LVM-thin, Ceph (RBD + CephFS), NFS, CIFS, iSCSI, BTRFS, GlusterFS. Tutto astratto dietro l'API "storage".

📁 Backup (vzdump + PBS)

Backup nativo full con vzdump. Per backup incrementali + deduplicazione + retention serve PBS (gratis, prodotto separato).

🔐 Firewall

Firewall a 3 livelli (cluster / nodo / VM) basato su nftables, configurabile da web UI.

🌐 SDN

Software-Defined Networking: zones (Simple/VLAN/QinQ/VXLAN/EVPN), VNets, IPAM. Stable da PVE 7.

👤 Auth multi-backend

PAM (utenti Linux), realm Proxmox VE, LDAP, Active Directory, OpenID Connect (SSO). 2FA TOTP/WebAuthn.

🧠 L'analogia

Se VMware vSphere è il "Mercedes" della virtualizzazione (raffinato, costoso, ti spiega con condiscendenza che hai bisogno di una Standard Plus), Proxmox è il Toyota Hilux: meno chic, ma porta tre quintali in salita, funziona a -30, lo ripari con quello che hai e non costa più di una macchina al mese. Per il 90% dei carichi del mondo reale, è quello che vuoi.

🏫 "VE" vs "PBS" vs "PMG". Proxmox è un brand di prodotti: Proxmox VE (questo) per virtualizzazione, Proxmox Backup Server (PBS) per backup deduplicati cifrati, Proxmox Mail Gateway (PMG) per antispam/antivirus mail. Tre prodotti separati, stessa filosofia, web UI molto simili.

02 / 12

Perché non altro

Lo scenario di mercato 2024-2026 ha cambiato tutto. Vediamo le alternative.

🔭 Il contesto: l'effetto Broadcom su VMware

Nel novembre 2023 Broadcom completa l'acquisizione di VMware. Nei mesi successivi: fine del prodotto Free ESXi, listino subscription ridisegnato (con aumenti riportati fino a 10x per molti clienti SMB), eliminazione delle SKU più piccole, partner program ridotto. Conseguenza: esodo di massa verso alternative. Proxmox VE ne è uscito come principale beneficiario.

Le alternative dolorose

VMware ESXi/vSphere: post-Broadcom, prezzi alti, ESXi Free chiuso, lock-in
Hyper-V: Windows-centric, gestione fra GUI e PowerShell, niente container Linux nativi
Xen / XCP-ng: meno mainstream, ecosistema più piccolo, performance ottime ma community più di nicchia
OpenStack: potente, complesso da morire, "tre persone full-time solo per mantenerlo"
oVirt / RHV: oVirt EOL, Red Hat Virtualization morta nel 2022
KVM raw + libvirt: funziona, ma fai a mano cluster/HA/backup/web UI — e diventi Proxmox da solo, peggio

Proxmox VE

Open source AGPLv3, niente lock-in, niente sorprese di listino
KVM + LXC integrati, una sola UI/CLI per entrambi
Cluster + HA built-in, configurabili in mezz'ora
Stack standard Linux: ZFS, Ceph, LVM, nftables, systemd — quello che già conosci
Migrazione da VMware assistita: qm importovf, plus tooling community
Subscription opzionale: i €115/anno-CPU (community) sono per il repo enterprise + supporto, non per usare il software

🎯 Il caso d'uso ideale. Da homelab (1 mini-PC, qualche VM/CT) a SMB (3-10 nodi, ~100 VM, cluster HA con Ceph) a medie aziende (10-32 nodi, qualche centinaio di VM). Per scenari iper-large (1000+ host, multi-tenant cloud pubblico) si guarda OpenStack o cloud pubblico vero.

🧠 L'analogia (revisited)

Quando VMware era "lo standard" e costava cifre umane, Proxmox era "quello che usano gli homelabber e qualche PMI". Dopo Broadcom, è diventato "quello che usano gli homelabber, le PMI, le università, gli ISP, le PA, e quei team enterprise che hanno smesso di sopportare le quote vSphere". Il software non è cambiato — il mercato sì.

03 / 12

Architettura

Cosa c'è sotto il cofano: demoni, filesystem distribuito, web UI, API REST.

⚙️ Lo stack del nodo

Un nodo Proxmox è una Debian standard (PVE 8.x = Debian 12 bookworm; PVE 9.x = Debian 13 trixie) con un kernel ottimizzato (Ubuntu kernel, ZFS in-tree) e una serie di demoni Proxmox-specifici sopra.

I demoni principali

Servizio	Cosa fa	Porta
`pveproxy`	Web server HTTPS (front-end), proxy API REST	8006
`pvedaemon`	API REST locale (root), backend per le azioni privilegiate	localhost
`pve-cluster`	Replica configurazione tra nodi del cluster (pmxcfs)	—
`corosync`	Cluster messaging engine (quorum, membership)	5405 udp
`pvestatd`	Polling stato VM/CT/storage, popola la UI	—
`pveha-lrm`	HA local resource manager (per-nodo)	—
`pveha-crm`	HA cluster resource manager (elegge il master)	—
`spiceproxy`	Proxy SPICE (console remota performante)	3128
`qmeventd`	Notifica eventi delle VM QEMU	—

pmxcfs — il filesystem distribuito magico

pmxcfs (Proxmox Cluster File System) è un FUSE filesystem montato su /etc/pve/ che replica tutta la configurazione del cluster su tutti i nodi, in tempo reale, tramite Corosync. Se scrivi un file su /etc/pve/qemu-server/100.conf da un nodo, in millisecondi tutti gli altri lo vedono. Backend: una SQLite locale per nodo + il bus Corosync per la sincronizzazione.

/etc/pve/ # pmxcfs (FUSE), replicato cluster-wide ├── authkey.pub ├── datacenter.cfg # config globale: timezone, console, language ├── storage.cfg # tutti gli storage definiti nel cluster ├── user.cfg # utenti + gruppi + permessi ├── corosync.conf # config Corosync (replicata) ├── nodes/<node>/ │ ├── qemu-server/ # <vmid>.conf — def VM KVM │ ├── lxc/ # <vmid>.conf — def container LXC │ └── pve-ssl.pem ├── ha/ # risorse HA, gruppi, fencing ├── sdn/ # config Software-Defined Networking └── firewall/ # regole firewall (cluster, nodo, VM)

⚠️ Senza quorum, /etc/pve/ diventa read-only. Se perdi il quorum (es. troppi nodi giù in un cluster), pmxcfs blocca le scritture per evitare split-brain. Le VM continuano a girare, ma non puoi creare/modificare nulla. È per design e ti salva il sedere.

Web UI & API

La web UI (Ext JS, lo so, ha 12 anni ma funziona) gira su https://<node>:8006. Sotto, è tutto API REST sotto /api2/json/. La UI è un client API come gli altri — tutto quello che fai cliccando lo puoi fare con pvesh da CLI o con qualunque HTTP client.

API REST in azione

# Versione del cluster
$ pvesh get /version

# Lista VM di un nodo
$ pvesh get /nodes/pve1/qemu

# Creazione VM via API
$ pvesh create /nodes/pve1/qemu \
    --vmid 200 --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0

# Via curl puro (con ticket)
$ curl -k -d "username=root@pam&password=..." \
    https://pve1:8006/api2/json/access/ticket

04 / 12

VM — QEMU/KVM

Macchine virtuali full, kernel proprio, qualunque OS. qm è il tuo comando.

🧮 Cosa è una VM in Proxmox

Una VM in PVE è un processo kvm (== qemu-system-x86_64 con accelerazione KVM) avviato da pvedaemon in base al file /etc/pve/qemu-server/<vmid>.conf. Ogni VM ha un vmid intero univoco nel cluster (es. 100, 101, ...).

Anatomia di un .conf VM

/etc/pve/qemu-server/100.conf

name: debian-web
memory: 4096
cores: 2
sockets: 1
cpu: host                                # max perf, no cross-CPU migration
machine: q35
bios: ovmf                                # UEFI; alt: seabios
scsihw: virtio-scsi-single                # virtio paravirt SCSI
scsi0: local-zfs:vm-100-disk-0,size=32G,iothread=1
efidisk0: local-zfs:vm-100-disk-1,efitype=4m,size=1M
net0: virtio=BC:24:11:AA:BB:CC,bridge=vmbr0,tag=10
ide2: local:iso/debian-13.0.0-amd64-netinst.iso,media=cdrom
boot: order=scsi0;ide2;net0
ostype: l26                                # Linux 2.6+/3.x/4.x/5.x/6.x kernel
agent: 1                                   # attiva qemu-guest-agent
balloon: 0                                 # 0 = disattiva ballooning

I dettagli che contano

Opzione	Scelta sana	Note
CPU type	`host` per perf, `x86-64-v2-AES` per migrate	`host` espone tutte le feature CPU host, ma blocca live-migration verso CPU diverse
Machine type	`q35`	Q35 supporta PCIe nativamente. `i440fx` è legacy ma compatibile con tutto
BIOS	`ovmf` (UEFI)	Necessario per Secure Boot, GPU passthrough, Win11. Richiede `efidisk0`
SCSI controller	`virtio-scsi-single`	Paravirt, supporta TRIM/discard, performance + flessibilità
Disk interface	`scsi` (+ virtio-scsi-single)	Alt: `virtio` (legacy), `sata`, `ide`. Mai `ide` in prod.
iothread=1	Sì (con virtio-scsi-single)	Thread I/O dedicato per disco, riduce contesa
NIC	`virtio`	Paravirt, ~10 Gbit interno trivialmente. Alt: `e1000e` per Win senza driver
Ballooning	Off per DB, on per workload generici	Riallocazione dinamica RAM. Inutile/dannoso per DB
QEMU agent	Sì, installa nel guest	Permette freeze-fs durante backup, IP discovery, shutdown pulito

PCI passthrough

Esponi un device PCI (GPU, NIC, controller) direttamente a una VM. Bypass dell'hypervisor: la VM ne ha l'accesso esclusivo, performance native, niente sharing.

Requisiti: IOMMU abilitato in BIOS (Intel VT-d / AMD-Vi), kernel boot con intel_iommu=on o amd_iommu=on, driver vfio-pci agganciato al device prima che lo prenda il driver normale del kernel.

setup GPU passthrough (esempio)

# 1. Abilita IOMMU nel boot
$ echo "intel_iommu=on iommu=pt" >> /etc/kernel/cmdline   # systemd-boot
$ proxmox-boot-tool refresh

# 2. Identifica device + vendor ID
$ lspci -nn | grep VGA
01:00.0 VGA compatible controller [0300]: NVIDIA ... [10de:1b06]

# 3. Vincola al driver vfio-pci
$ echo "options vfio-pci ids=10de:1b06" > /etc/modprobe.d/vfio.conf
$ update-initramfs -u

$ reboot

# 4. Aggiungi alla VM
$ qm set 100 -hostpci0 01:00,pcie=1,x-vga=1

Cloud-init

PVE supporta nativamente le cloud images (Debian/Ubuntu/Rocky/...) con cloud-init: aggiungi un disco cloudinit, configuri user/password/SSH-key/network dalla UI o CLI, all'avvio la VM si auto-configura. Pattern standard per provisioning veloce.

cloud-init quick start

# Scarica cloud image Debian
$ wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2

# Crea VM e importa disco
$ qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr0 \
    --scsihw virtio-scsi-single --serial0 socket
$ qm importdisk 9000 debian-13-genericcloud-amd64.qcow2 local-zfs
$ qm set 9000 --scsi0 local-zfs:vm-9000-disk-0
$ qm set 9000 --ide2 local-zfs:cloudinit
$ qm set 9000 --boot c --bootdisk scsi0
$ qm set 9000 --ciuser selif --sshkey ~/.ssh/id_ed25519.pub
$ qm set 9000 --ipconfig0 ip=dhcp

# Marcalo come template e clona
$ qm template 9000
$ qm clone 9000 100 --name web1 --full
$ qm start 100

05 / 12

LXC — container Linux

Più leggeri delle VM, boot in 1 secondo, condividono il kernel host. pct è il comando.

📦 LXC vs Docker

Sia LXC che Docker usano i namespace + cgroups del kernel. La differenza filosofica:

LXC = system container: simula una macchina intera (init, /etc, multi-process, multi-utente). Pensa a una VM senza l'overhead del kernel.
Docker = application container: un processo, una immagine, immutabile, orchestrato.

Per ospitare un'app monoprocesso isolata → Docker. Per ospitare "un Debian con qualche cosa dentro" con boot rapido e gestione classica (systemd, ssh, apt) → LXC.

Anatomia di un .conf LXC

/etc/pve/lxc/200.conf

arch: amd64
hostname: ct-web
memory: 1024
cores: 2
ostype: debian
rootfs: local-zfs:subvol-200-disk-0,size=8G
net0: name=eth0,bridge=vmbr0,ip=dhcp,hwaddr=BC:24:11:AA:BB:CC
unprivileged: 1                          # UID/GID mapping = sicurezza
features: nesting=1                      # opt-in: Docker dentro l'LXC
onboot: 1

Privileged vs unprivileged

L'opzione cruciale per la sicurezza:

unprivileged (default, raccomandato): l'UID 0 dentro il container è mappato su un UID alto sull'host (es. 100000). Se evade, è nobody, non root host.
privileged: UID 0 del container = UID 0 host. Pratico per montare bind, ma chi entra root nel container può uscire root sull'host. Per casi specifici (NFS server, ...), evita altrimenti.

Template di OS

PVE include una libreria di template OS scaricabili via pveam (PVE Appliance Manager): Debian, Ubuntu, Alpine, Rocky, Arch, Devuan, e altri. Ogni template è un .tar.zst con un root filesystem minimale.

gestione template LXC

# Aggiorna l'indice dei template disponibili
$ pveam update

# Cerca
$ pveam available --section system | grep debian

# Scarica
$ pveam download local debian-13-standard_13.0-1_amd64.tar.zst

# Crea CT da template
$ pct create 200 \
    local:vztmpl/debian-13-standard_13.0-1_amd64.tar.zst \
    --hostname ct-web --memory 1024 --cores 2 \
    --rootfs local-zfs:8 --net0 name=eth0,bridge=vmbr0,ip=dhcp \
    --unprivileged 1

$ pct start 200
$ pct enter 200       # shell dentro il container

🧩 Quando LXC vince sulle VM: alta densità (50 CT su un nodo modesto vs 10-20 VM), boot rapido (1s vs 30s), allocazione RAM "elastica" (consumo reale, non riservato), backup più piccoli. Quando perde: serve un kernel diverso (Windows, BSD, kernel custom), serve una syscall esotica bloccata da seccomp, serve isolamento "duro" tipo cloud multi-tenant.

⚠️ Docker dentro LXC. Si può (servono nesting=1, keyctl=1, ZFS storage driver compatibile o overlay2 con caveats). Il pattern "LXC contenente Docker" è comune in homelab per isolare stack Docker senza dedicare una VM full, ma sappi che aggiungi un layer di astrazione e qualche edge case (cgroup v2, fuse-overlayfs, ...).

06 / 12

Storage

La parte più complessa di Proxmox — ma anche la più potente. Locale, condiviso, distribuito.

💾 Storage = backend + content types

In PVE uno storage è definito da:

Un backend (tipo): dove vivono i dati (ZFS pool, LVM-thin VG, NFS share, Ceph pool, ...)
Un set di content types: cosa può contenere (VM disk, CT rootfs, backup, ISO, template, snippet)

Uno storage definito una sola volta nel cluster è visibile e usabile da tutti i nodi (se è shared) o solo dal nodo locale (se è local).

Backend principali

Tipo	Shared?	Snapshot	Thin	Note
`dir`	no	solo qcow2	solo qcow2	Directory POSIX. Semplice, lento per molte VM
`lvm`	no*	no	no	Volume LVM "fat". Veloce, no snapshot.
`lvmthin`	no	sì	sì	Default per il setup base. Veloce, snapshot nativi
`zfspool`	no	sì	sì	ZFS rocks. Compressione, dedup, send/recv per replica
`btrfs`	no	sì	sì	Sperimentale-ish in PVE, alcuni edge case
`nfs`	sì	solo qcow2	solo qcow2	NFSv3/v4. Veloce solo se backend è veloce
`cifs`	sì	solo qcow2	solo qcow2	SMB. Per shares Windows / NAS
`iscsi`	sì (con LVM sopra)	no (raw)	no	Block storage di rete. Spesso con LVM cluster sopra
`rbd` (Ceph)	sì	sì	sì	RADOS Block Device. Built-in dal PVE
`cephfs`	sì	solo qcow2	solo qcow2	Ceph filesystem POSIX. Per ISO, backup, snippet
`pbs`	(remoto)	—	—	Solo backup. Server PBS remoto.
`glusterfs`	sì	solo qcow2	solo qcow2	Deprecato upstream — evita per nuove install

Content types

💾

images

Disk VM (qcow2/raw/zvol)

📁

rootdir

Rootfs container LXC

📥

iso

ISO per installazione VM

📦

vztmpl

Template LXC

📂

backup

Archivi vzdump

📝

snippets

Hook script, cloud-init custom

ZFS — lo storage che vuoi

Su un nodo single-server o un cluster piccolo, ZFS è la scelta di default per molti: snapshot atomici, compressione trasparente (lz4 di default, ottimo trade-off CPU/spazio), checksumming end-to-end, zfs send/receive per replica incrementale tra nodi, RAID software performante (RAIDZ, mirror).

Vedi anche la guida ZFS dedicata — tutti i caveat (RAM, RAIDZ vs mirror, ZIL/SLOG, ARC tuning) si applicano qui pari pari.

🔌 SSD consumer + ZFS = disastro lento. Le SSD consumer (Samsung EVO, Crucial MX) hanno endurance bassa e niente cache PLP (power-loss protection). Con ZFS scrivere il ZIL su SSD consumer le brucia in mesi e ha latenze terribili per sync writes. Per ZFS in prod: SSD enterprise (Samsung PM, Intel S-series, Micron Pro), o NVMe enterprise. La differenza in IOPS sync è di 10x-100x.

Ceph — lo storage distribuito built-in

Da PVE 5+ Ceph è integrato nella web UI. Trasformi i dischi locali dei tuoi nodi in uno storage shared distribuito con replica configurabile (default 3 copie). Vantaggio enorme: niente shared storage esterno (SAN), HA che funziona davvero, scaling orizzontale aggiungendo nodi.

Requisiti: 3 nodi minimo (per quorum), rete dedicata 10 GbE+ per il cluster storage (jumbo frames raccomandate), SSD/NVMe per gli OSD in prod. Su HDD funziona ma le latenze diventano serie.

🎯 Quando Ceph, quando ZFS? Cluster ≤ 3 nodi piccolo, budget contenuto, niente rete dedicata 10G: ZFS locale + replica (basta per quasi tutto l'homelab). Cluster ≥ 3 nodi medio/grande, rete 10/25 GbE, vuoi vera shared storage senza SAN: Ceph. Scelta che plasma tutta l'infra, scegli all'inizio.

Esempio: aggiungere un pool ZFS come storage

storage.cfg snippet + comandi

# 1. Crea il pool ZFS (3-way mirror su 3 dischi)
$ zpool create -o ashift=12 rpool-data mirror /dev/sda /dev/sdb /dev/sdc

# 2. Aggiungi come storage PVE
$ pvesm add zfspool local-zfs-fast \
    --pool rpool-data \
    --content images,rootdir \
    --sparse 1

# Equivalente in /etc/pve/storage.cfg
zfspool: local-zfs-fast
        pool rpool-data
        content images,rootdir
        sparse 1

07 / 12

Networking & SDN

Linux bridges di default, bonds per ridondanza, VLAN per segmentazione, SDN quando le cose si fanno serie.

🌐 Il modello base

Su un nodo PVE fresco trovi una sola interfaccia bridged: vmbr0, un Linux bridge che corrisponde all'interfaccia fisica primaria (eno1 o enp1s0). Ogni VM/CT con net0: ...,bridge=vmbr0 ottiene una tap interface agganciata a quel bridge — di fatto, è come uno switch L2 virtuale.

Layout di rete tipico (cluster 3 nodi, prod-ready)

vmbr0 — rete management/admin (web UI 8006, SSH)
vmbr1 — rete VM/workload (con VLAN tagging)
vmbr2 o interface diretta — rete Corosync (dedicata, basso latency, ridondata)
vmbr3 o interface diretta — rete storage Ceph/iSCSI (10G+, jumbo MTU 9000)

Le ultime due idealmente separate fisicamente dalla management/VM, su NIC dedicate e switch dedicati.

VLAN-aware bridge

Un singolo vmbr0 può essere "VLAN-aware": permette a ogni VM di dichiarare un VLAN tag nel suo conf (es. net0: virtio,bridge=vmbr0,tag=10) senza dover creare un bridge per VLAN. Più pulito.

/etc/network/interfaces — bond + VLAN-aware bridge

auto bond0
iface bond0 inet manual
    bond-slaves enp1s0f0 enp1s0f1
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer2+3

auto vmbr0
iface vmbr0 inet static
    address 10.0.0.10/24
    gateway 10.0.0.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Bonds (link aggregation)

Combinano 2+ NIC fisiche in una sola logica per throughput e fault tolerance. Modi più usati:

active-backup — una attiva, l'altra di scorta. Funziona con qualunque switch. Sicurezza, no throughput
802.3ad (LACP) — aggregazione attiva, ~doppia bandwidth, richiede switch con LACP configurato
balance-rr — round-robin, throughput max ma fuori sequenza (sconsigliato fuori da scenari controllati)

SDN (Software-Defined Networking)

Da PVE 7 stable. Astrae la rete fisica in zones e VNets, configurabili dalla web UI in modo centralizzato. Pensato per multi-tenancy o setup più grandi dove configurare ogni nodo a mano in /etc/network/interfaces è insostenibile.

Zone Type	Per cosa
`Simple`	Rete privata isolata locale al nodo (testing)
`VLAN`	Tagging 802.1Q su bridge VLAN-aware. Tipico in datacenter
`QinQ`	VLAN-in-VLAN (802.1ad), per ISP/cloud provider
`VXLAN`	Overlay L2 su L3, scale orizzontale, nessun limite 4094 VLAN
`EVPN`	VXLAN + BGP EVPN. Cloud-scale, multi-tenant routing

Firewall

PVE include un firewall a 3 livelli basato su nftables (in modalità classica era iptables, ora nftables), configurabili dalla UI o direttamente in /etc/pve/firewall/:

Cluster-level: regole + IPSet condivisi cluster-wide
Node-level: regole per il management dell'host (porta 22, 8006, ...)
VM-level: regole per-VM, applicate alla tap interface

Va abilitato esplicitamente (default off in PVE 8): impostazione cluster firewall on, poi "input policy: drop" dopo aver scritto almeno una regola di accept per SSH/management. Misura due volte, taglia una volta — lockout via firewall è un classico.

🔒 Lockout protection. PVE rileva se le tue regole stanno per bloccarti fuori dal nodo (es. perdere SSH) e te lo segnala. Però il rilevamento non è perfetto: prima di flippare a "drop" globale, prova le regole con SSH separato già aperto, e tieni una console fisica/IPMI accessibile.

08 / 12

Cluster & High Availability

Tre nodi minimum. Corosync per il quorum. HA Manager per il failover automatico.

🌐 Cluster — quanti nodi

Tecnicamente un "cluster" inizia da 2 nodi, ma 2 nodi è pericoloso: se la rete tra loro cade, ognuno crede di essere "l'unico vivo" e procede a montare gli storage / startare le VM → split-brain (corruzione potenziale di dati).

Per il quorum sano serve un numero dispari di "voti", quindi:

3 nodi — minimo sano. Quorum = 2/3
5 nodi — quorum 3/5, tollera 2 nodi down
2 nodi + QDevice — un terzo "votante" esterno (mini-PC, container su NAS, una raspberry) che fa da tiebreaker

Setup cluster (3 nodi, da zero)

pvecm: creare e joinare

# Sul primo nodo: crea il cluster
pve1$ pvecm create mycluster

# Sul secondo nodo: join
pve2$ pvecm add 10.0.0.10        # IP del primo nodo

# Sul terzo nodo: join
pve3$ pvecm add 10.0.0.10

# Verifica
$ pvecm status
Cluster information
-------------------
Name:    mycluster
...
Quorate:  Yes

Membership information
----------------------
   Nodeid    Votes  Name
        1        1  pve1 (local)
        2        1  pve2
        3        1  pve3

⚠️ Una volta che un nodo è nel cluster, non torna indietro senza dolore. Se vuoi rimuovere un nodo, leggi i docs prima di fare. Reinstall di un nodo che era in cluster: sempre pvecm delnode <name> dagli altri PRIMA di reinstallare, altrimenti pulizia manuale di /etc/pve/nodes/<name>/.

Rete Corosync dedicata

Corosync è sensibile alla latenza: se la rete passa pacchetti late (jitter, packet loss, congestione), il cluster può perdere quorum spontaneamente, con conseguenze brutte per le VM HA. Best practice:

Rete dedicata Corosync, separata fisicamente da workload/storage
Ridondata: pvecm supporta multipli "ring" (link0, link1, ...) per failover automatico
Gigabit suff. (banda non è il problema, latenza sì)

HA Manager — failover automatico

Con il cluster su, attivi HA Manager per fare in modo che VM/CT marcate "HA" siano automaticamente riavviate su un altro nodo se quello su cui giravano cade.

Requisiti rigidi:

Storage condiviso (Ceph, NFS, iSCSI) oppure replicato (ZFS replication periodica)
Watchdog hardware (IPMI, iLO, iDRAC) — PVE fa fencing self-fence: il nodo che perde quorum si auto-reboot, ed è il watchdog che lo costringe se il software non risponde
Quorum 3+ nodi (o 2+QDevice)

HA Manager via CLI

# Marca VM 100 come HA
$ ha-manager add vm:100 --state started --max_restart 3 --max_relocate 2

# Crea un gruppo HA (nodi preferiti)
$ ha-manager groupadd web-tier --nodes "pve1,pve2,pve3" --restricted 0

# Assegna risorsa al gruppo
$ ha-manager set vm:100 --group web-tier

# Stato HA
$ ha-manager status
quorum OK
master pve1 (active, ...)
lrm pve1 (active, ...)
lrm pve2 (active, ...)
lrm pve3 (active, ...)
service vm:100 (pve1, started)

⏱️ Tempo di failover. Non istantaneo: un nodo deve essere dichiarato "lost" (~tens of seconds di silenzio Corosync), poi self-fenced via watchdog, poi il CRM elegge un nuovo nodo e fa start della VM. Pratico: 3-5 minuti di downtime per failover non-pianificato. Per uptime estremo serve un'altra architettura (replica applicativa, anycast, load balancer L4 stateful, ...).

Live migration

Spostare una VM accesa tra nodi del cluster senza downtime. Trasferimento memoria iterativo via rete, finché le pagine dirty sono poche, freeze breve, switch atomico.

Online (live): con storage condiviso, copia solo la RAM. Veloce, downtime sub-secondo
Online con storage migration: senza storage condiviso, copia anche i dischi. Lento ma fa il lavoro
Offline: VM spenta, copia tutto, riaccende sull'altro nodo

Per LXC, la migrazione è sempre "restart" (lo stato di processo non si può trasferire come la RAM QEMU). Downtime di alcuni secondi.

qm migrate — CLI

# Live migration di VM 100 da pve1 a pve2
$ qm migrate 100 pve2 --online

# Con storage migration (no shared storage)
$ qm migrate 100 pve2 --online --with-local-disks

# CT: sempre "restart"
$ pct migrate 200 pve2 --restart

09 / 12

Backup — vzdump + PBS

Backup nativi locali con vzdump. Incrementali e deduplicati con Proxmox Backup Server.

📁 vzdump — il default built-in

vzdump è il backup tool di PVE: produce un singolo file archivio per VM/CT. Formati: .vma per VM (proprietario, ottimizzato), .tar per CT. Compressione opzionale (gzip, lzo, zstd). Lo schedule lo configuri dalla UI → Datacenter → Backup, con destination uno storage che supporta content type backup.

Modes di backup

Mode	Downtime	Quando
`snapshot`	zero	Default, richiede storage con snapshot (ZFS, LVM-thin, qcow2). Snapshot del disco, backup dello snapshot, drop. La VM continua a girare
`suspend`	~secondi	VM messa in pausa, RAM scritta su disco, backup, resume. Più sicuro consistency-wise se non hai qemu-guest-agent
`stop`	completo	VM spenta, backup pulito, restart. Per chi vuole bullet-proof

🎯 QEMU guest agent + fs-freeze. Con qemu-guest-agent installato nel guest, vzdump --mode snapshot chiama fsfreeze sul filesystem del guest prima dello snapshot — il backup è consistente a livello FS (niente corruzione di transazioni DB in-flight). Senza agent è un crash-consistent backup (come fosse un blackout): di solito ok, ma DB possono richiedere recovery.

vzdump CLI

# Backup di una VM, snapshot, zstd, su storage "backup-nfs"
$ vzdump 100 --mode snapshot --compress zstd --storage backup-nfs

# Backup di tutte le VM/CT del nodo, eccetto 999
$ vzdump --all --exclude 999 --mode snapshot --compress zstd \
    --storage backup-nfs --mailnotification failure --mailto [email protected]

# Restore
$ qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_05_01-03_00_00.vma.zst 105 \
    --storage local-zfs

PBS — quando vzdump non basta

Proxmox Backup Server è un prodotto separato (gratis, Debian-based, web UI dedicata) che integra PVE come destination di backup. Cosa offre rispetto a vzdump+NFS:

Backup incrementali (forever-incremental): dopo il primo full, ogni backup è solo il delta. Tempo ↓, banda ↓, spazio ↓
Deduplicazione globale: i chunk identici tra VM diverse non occupano spazio doppio
Cifratura end-to-end: chiave sul client (PVE), il server PBS vede solo blob cifrati
Retention policy granulare: "tieni 7 giornalieri + 4 settimanali + 12 mensili + 5 annuali", con tooling per il pruning
Verify integrity: ri-checksum periodico per individuare bit-rot
Garbage collection: libera spazio dei chunk non più referenziati
Datastore namespaces: multi-tenant logico
Sync remoto PBS→PBS: replica off-site nativa

aggiungere PBS come storage

# In /etc/pve/storage.cfg (o dalla UI: Datacenter → Storage → Add → PBS)
pbs: pbs-main
        server pbs.example.local
        datastore main
        username backup@pbs
        password <...>
        fingerprint 12:34:56:...     # SHA256 cert del server PBS
        content backup
        encryption-key /etc/pve/priv/pbs-encryption-key.json

💾 Pattern raccomandato: PBS su una macchina separata (diversa rete, diverso building/region se possibile), su disco ZFS/Ceph con redundancy, retention 7d+4w+12m, GC settimanale, verify mensile. Più un PBS remoto in sync sull'altra sede. Backup come si deve.

10 / 12

Subscription, repository, "no valid subscription"

Capire cosa stai usando, cosa paghi, e come usare il software senza pagare ma in modo corretto.

💰 Il modello commerciale

Proxmox è AGPLv3: l'uso completo del software è gratis, anche commerciale. Quello che paghi con una subscription è:

Accesso al repository "enterprise", dove le release sono testate più a lungo prima della distribuzione
Supporto tecnico via portal (scala con il tier)
Rimozione del popup "no valid subscription"

Tier indicativi (per CPU socket, per anno; consultare il sito per i prezzi correnti): Community ~€115, Basic ~€365, Standard ~€530, Premium ~€1060. Niente di gratuito che diventa a pagamento — solo il livello di "supporto e canale di update".

I 3 repository APT

Repo	Path	Quando
`pve-enterprise`	`/etc/apt/sources.list.d/pve-enterprise.list`	Default. Richiede subscription valida (otherwise 401 in apt update). Più testato
`pve-no-subscription`	Aggiungere a mano	Gratis, free for all. Release più fresche, "less tested" per design
`pvetest`	Aggiungere a mano	Pacchetti di test, da non usare in produzione

Usare il repo no-subscription (la cosa corretta in homelab)

switch a no-subscription

# 1. Disabilita il repo enterprise (no subscription valida)
$ sed -i 's|^deb|# deb|' /etc/apt/sources.list.d/pve-enterprise.list

# 2. Aggiungi il repo no-subscription
$ echo "deb http://download.proxmox.com/debian/pve $(lsb_release -cs) pve-no-subscription" \
    > /etc/apt/sources.list.d/pve-no-subscription.list

# 3. (Stesso pattern per ceph se usi Ceph)
$ sed -i 's|^deb|# deb|' /etc/apt/sources.list.d/ceph.list 2>/dev/null

$ apt update && apt full-upgrade -y

Il famoso popup "no valid subscription"

Senza subscription, ogni login alla web UI mostra un alert: "You do not have a valid subscription for this server". Non blocca nulla, è un nag. Si può rimuovere modificando un file JS della UI (cerca pvemanagerlib.js), patch ben documentata da terze parti.

Riflessione sana: se Proxmox ti serve davvero per qualcosa di importante, prendere almeno la Community subscription (€115/anno-socket) toglie il popup, ti dà il canale enterprise più testato, e finanzia un progetto open che sta sostenendo migliaia di sysadmin in fuga da Broadcom. Per i tuoi 3 nodi homelab, comunque, no-subscription è perfettamente legittimo.

📝 Versioning: PVE adotta versioning major.minor (es. 8.1, 8.2, 9.0). Major bump si allinea spesso a una nuova Debian (PVE 8 = Debian 12, PVE 9 = Debian 13). Upgrade major-to-major fattibile in-place ma serve leggere le release notes — sono dettagliate, riportano breaking changes.

11 / 12

Pitfalls comuni

Le cose con cui ti scotti se è la prima volta. Te le risparmi.

Cosa fare

3+ nodi nel cluster (o 2 + QDevice)
SSD enterprise per ZFS/Ceph (PLP + alta endurance)
Rete Corosync dedicata, ridondata
Storage Ceph su 10GbE+ con jumbo frames (MTU 9000)
QEMU guest agent installato nei guest
Backup PBS off-site (almeno settimanale)
Monitorare lo SMART dei dischi
Test di restore prima che serva davvero
Aggiornamenti regolari (no skip di 2 major)
Documentare l'IPMI per accesso remoto fisico

Cosa non fare

Cluster a 2 nodi senza QDevice (split-brain garantito)
SSD consumer per ZFS sync writes (latency assurde, wear veloce)
Corosync sullo stesso link di management e workload
Ceph su HDD per workload importanti
HA Manager senza watchdog hardware (no fencing → no HA)
Mescolare repo enterprise + no-subscription
Sovrallocare RAM (no swap) con ballooning off
Backup mai testati ("Schrödinger's backup")
Tenere 1 sola copia del backup, sulla stessa macchina
Lasciare default la password root e fidarsi

I bachi più tipici da debugging

"Cannot start VM, ZFS pool degraded" — un disco è morto e nessuno se ne è accorto. zpool status sempre, monitora SMART, fai alert
HA non si scatena al riboot di un nodo — manca il watchdog hardware o non è configurato. Senza fencing automatic, HA Manager rifiuta di failover (giustamente)
Live migration fallisce con "incompatible CPU" — hai cpu: host con CPU diverse tra i nodi. Soluzione: cpu: x86-64-v3 (o v2-AES per max compat)
Backup occupa tantissimo — non stai usando PBS (no dedup), e vzdump compresso ha limiti. Migra a PBS
"qemu-server: storage 'X' has not the right content type" — quel storage non è abilitato a contenere ciò che gli chiedi. pvesm set X --content images,rootdir,backup,iso
Cluster quorum perso al riboot di 1 nodo (su 3) — rete Corosync non separata, in upgrade ha visto pacchetti late. Sposta Corosync su NIC dedicata

📢 Monitoring è obbligatorio. Proxmox non spedisce alerting completo built-in oltre alle notifiche email per i backup. Per produzione: node_exporter + Prometheus + Grafana (oppure Zabbix), alert su disk usage, ZFS pool state, RAM/swap, Corosync ring, temperature CPU. Non è opzionale.

12 / 12

Cheat sheet

I comandi che userai davvero. Tutto sotto qm, pct, pvecm, pvesm, pvesh.

VM (qm)

qm essentials

$ qm list                          # lista VM
$ qm status 100                    # stato di una VM
$ qm start  100                    # start
$ qm shutdown 100 --forceStop=1   # shutdown pulito (timeout fallback)
$ qm reboot 100
$ qm reset 100                     # hard reset
$ qm stop 100                      # hard power off

$ qm config 100                    # mostra config
$ qm set 100 --memory 8192         # modifica al volo
$ qm set 100 --cores 4
$ qm resize 100 scsi0 +20G         # estende il disco

$ qm clone 100 200 --name web2 --full
$ qm template 100                  # marca come template
$ qm migrate 100 pve2 --online
$ qm destroy 100                   # elimina (+ disco se purge)

$ qm monitor 100                   # entra nella QEMU monitor
$ qm guest cmd 100 ping            # comandi al qemu-guest-agent

Container (pct)

pct essentials

$ pct list
$ pct status 200
$ pct start  200
$ pct stop   200
$ pct shutdown 200

$ pct enter 200                    # shell dentro il CT
$ pct exec 200 -- apt update       # un comando one-shot

$ pct config 200
$ pct set 200 --memory 2048
$ pct resize 200 rootfs +5G

$ pct clone 200 201 --hostname ct-new
$ pct template 200
$ pct migrate 200 pve2 --restart
$ pct destroy 200

Cluster (pvecm)

pvecm essentials

$ pvecm status                     # stato cluster + quorum
$ pvecm nodes                      # lista nodi + voti
$ pvecm create mycluster
$ pvecm add 10.0.0.10              # join
$ pvecm delnode pve3               # remove (sui nodi rimasti)
$ pvecm qdevice setup <ip>         # QDevice tiebreaker
$ pvecm expected 1                 # forza quorum (DANGER, solo per recovery)

Storage (pvesm)

pvesm essentials

$ pvesm status                     # tutti gli storage + utilizzo
$ pvesm list local-zfs             # dischi VM/CT su uno storage
$ pvesm add zfspool local-fast --pool tank/vm --content images,rootdir
$ pvesm set local --content images,iso,vztmpl,backup,snippets
$ pvesm remove local-old
$ pvesm alloc local-zfs 100 vm-100-disk-2 32G

HA Manager

ha-manager essentials

$ ha-manager status
$ ha-manager add vm:100 --state started --max_restart 3
$ ha-manager groupadd grp1 --nodes "pve1,pve2,pve3" --restricted 0
$ ha-manager set vm:100 --group grp1
$ ha-manager migrate vm:100 pve2   # sposta gestita da HA
$ ha-manager remove vm:100         # de-listo da HA

Backup

vzdump + restore

$ vzdump 100 --mode snapshot --compress zstd --storage backup-nfs
$ vzdump --all --exclude 999 --mode snapshot --compress zstd \
       --storage pbs-main --mailto [email protected] --mailnotification failure

$ qmrestore /path/vzdump-qemu-100-2026_05_01.vma.zst 105 --storage local-zfs
$ pct restore 205 /path/vzdump-lxc-200-2026_05_01.tar.zst --storage local-zfs

Template OS LXC

pveam essentials

$ pveam update
$ pveam available --section system | grep debian
$ pveam download local debian-13-standard_13.0-1_amd64.tar.zst
$ pveam list local

API REST

pvesh essentials

$ pvesh get /version
$ pvesh get /nodes
$ pvesh get /nodes/pve1/qemu
$ pvesh get /cluster/resources --type vm

$ pvesh create /nodes/pve1/qemu --vmid 200 --memory 2048 --cores 1 \
    --net0 virtio,bridge=vmbr0

$ pvesh set /cluster/firewall/options --enable 1

Aggiornamenti + repo

maintenance

$ apt update && apt full-upgrade -y
$ pveupgrade                       # wrapper smart che valida
$ pveversion -v                    # versione dettagliata di tutti i pkg
$ proxmox-boot-tool refresh        # refresh dei boot loader (systemd-boot/grub)

📚 Documentazione canonica: pve.proxmox.com/pve-docs/ (admin guide completa, HTML + PDF, sempre aggiornata), pve.proxmox.com/wiki/ (how-to, ricette, edge case), forum.proxmox.com (community molto attiva, sviluppatori che rispondono spesso).

🔗 Guide collegate: ZFS (storage di default in Proxmox), Linux Admin (Proxmox è Debian, tutto vale), Ansible (per provisionare VM/CT Proxmox da fuori), arx · nomina · missus (ottimi candidati per girare dentro LXC su Proxmox), VLAN (per il networking serio).