Sviluppo web | 25/07/2026 | Gabriele Romanato

Installare e configurare Proxmox VE: guida completa

Proxmox Virtual Environment (Proxmox VE, o più brevemente PVE) è una piattaforma di virtualizzazione open source basata su Debian che unisce in un unico prodotto due tecnologie complementari: QEMU/KVM per le macchine virtuali complete e LXC per i container di sistema. A queste si aggiungono uno stack di storage molto ricco (ZFS, LVM, Ceph, NFS, iSCSI), un firewall integrato, un sistema di backup nativo e un'interfaccia web completa che copre praticamente tutte le operazioni quotidiane.

Il risultato è un hypervisor di tipo 1 che si installa direttamente sul metallo, si gestisce dal browser e non richiede alcuna licenza per essere usato in produzione: la sottoscrizione commerciale dà accesso al repository enterprise e al supporto, ma tutte le funzionalità sono disponibili anche nella versione gratuita.

Al momento della stesura di questo articolo la release stabile è Proxmox VE 9.2, basata su Debian 13 "Trixie", con kernel Linux 7.0, QEMU 11.0, LXC 7.0 e ZFS 2.4. Tutti i comandi e i percorsi indicati fanno riferimento a questa versione; laddove esistano differenze significative con la serie 8.x lo segnalerò esplicitamente.

Requisiti hardware

Proxmox VE gira solo su architettura x86-64 (Intel EM64T o AMD64). Non esistono build ufficiali per ARM. I requisiti minimi per una prova sono modesti, ma quelli consigliati per un uso reale sono ben diversi.

Requisiti minimi (solo per test)

CPU a 64 bit con estensioni di virtualizzazione (Intel VT-x o AMD-V) abilitate nel BIOS/UEFI
2 GB di RAM (più quella destinata alle VM e ai container)
Un disco da almeno 32 GB
Una scheda di rete

Requisiti consigliati per la produzione

CPU multi-core recente; se si prevede di usare Ceph o ZFS, meglio abbondare con i core
Almeno 16-32 GB di RAM. Con ZFS va considerato che l'ARC (la cache in RAM) tende a occupare fino al 50% della memoria totale se non lo si limita
Dischi separati: uno o due SSD/NVMe per il sistema operativo (in mirror), altri dischi per lo storage delle VM
Controller in modalità HBA/IT se si usa ZFS. I controller RAID hardware con cache e write-back sono espressamente sconsigliati con ZFS, perché nascondono i dischi al filesystem e ne compromettono i meccanismi di integrità
Due o più NIC, per separare traffico di gestione, traffico delle VM e (se presente) traffico di storage/cluster
Alimentazione ridondata e UPS

Un punto spesso trascurato: se si intende usare il PCI passthrough (ad esempio per passare una GPU a una VM), servono anche il supporto IOMMU (Intel VT-d o AMD-Vi) sulla scheda madre e una gestione ragionevole dei gruppi IOMMU da parte del firmware.

Per verificare in anticipo che la CPU supporti la virtualizzazione hardware, da un qualsiasi sistema Linux:

# Conta i core che espongono le estensioni di virtualizzazione
# vmx = Intel VT-x, svm = AMD-V
grep -E -c '(vmx|svm)' /proc/cpuinfo

# Verifica che IOMMU sia attivo (utile per il PCI passthrough)
dmesg | grep -E -i 'DMAR|IOMMU'

Download e preparazione del supporto di installazione

L'immagine ISO si scarica dal sito ufficiale di Proxmox. È buona pratica verificarne sempre il checksum SHA-256 prima di scriverla su chiavetta.

# Scarica l'immagine ISO (sostituire con la versione desiderata)
wget https://enterprise.proxmox.com/iso/proxmox-ve_9.2-1.iso

# Calcola il checksum e confrontalo con quello pubblicato sul sito
sha256sum proxmox-ve_9.2-1.iso

Creazione della chiavetta USB su Linux

L'ISO di Proxmox è ibrida: può essere scritta direttamente sul dispositivo a blocchi, senza formattazioni preliminari. Attenzione: il comando seguente distrugge tutto il contenuto del disco indicato, quindi il device va identificato con estrema cura.

# Identifica il device della chiavetta (es. /dev/sdb, NON /dev/sdb1)
lsblk -o NAME,SIZE,MODEL,TRAN

# Smonta eventuali partizioni già montate
sudo umount /dev/sdb* 2>/dev/null

# Scrive l'immagine sul dispositivo a blocchi
# bs=1M velocizza la scrittura, status=progress mostra l'avanzamento
sudo dd if=proxmox-ve_9.2-1.iso of=/dev/sdb bs=1M conv=fsync status=progress

# Forza lo svuotamento dei buffer prima di rimuovere la chiavetta
sync

Creazione della chiavetta USB su macOS

# Elenca i dischi collegati e individua quello corretto
diskutil list

# Smonta il disco (non espellerlo)
diskutil unmountDisk /dev/disk4

# Scrive l'immagine usando il device "raw" (rdisk), molto più veloce
sudo dd if=proxmox-ve_9.2-1.iso of=/dev/rdisk4 bs=1m

# Espelle il disco al termine
diskutil eject /dev/disk4

Creazione della chiavetta USB su Windows

Su Windows lo strumento consigliato è Rufus, impostato in modalità di scrittura DD Image e non ISO Image. Quest'ultima modalità riscrive il bootloader e produce quasi sempre una chiavetta non avviabile. In alternativa funzionano bene anche balenaEtcher e Ventoy.

Installazione

Avviato il sistema dalla chiavetta, il menu dell'installer propone diverse opzioni. Le più rilevanti sono:

Install Proxmox VE (Graphical): l'installer grafico classico
Install Proxmox VE (Terminal UI): la stessa procedura in modalità testuale, utile su hardware con problemi di output video o via IPMI/Serial-over-LAN
Advanced Options: contiene fra le altre cose la modalità debug e le opzioni per il boot con driver problematici

Selezione del disco e del filesystem

È il passaggio che condiziona di più la vita futura del server, perché il filesystem di root non si cambia senza reinstallare. Le opzioni principali:

ext4 su LVM (default): semplice e affidabile. L'installer crea automaticamente il volume group pve con i logical volume root, swap e data, quest'ultimo come thin pool per i dischi delle VM.
XFS su LVM: alternativa a ext4, con prestazioni migliori su file molto grandi.
ZFS (RAID0, RAID1, RAID10, RAIDZ-1/2/3): la scelta più interessante. Offre checksum end-to-end, snapshot istantanei, compressione trasparente, replica asincrona fra nodi e la possibilità di fare boot da mirror. Richiede però più RAM ed è incompatibile con i controller RAID hardware.
Btrfs: supportato ma ancora etichettato come tecnologia in fase di sviluppo.

Per un server con due dischi identici dedicati al sistema, ZFS RAID1 è quasi sempre la scelta migliore: si ottiene ridondanza del boot senza RAID hardware. Nelle opzioni avanzate del disco conviene impostare ashift=12 per dischi con settori da 4K (praticamente tutti quelli moderni) e compress=lz4, che nella pratica è gratis in termini di CPU e fa risparmiare spazio.

Un'altra opzione utile è hdsize: limitando la dimensione usata dall'installer si lascia spazio non allocato sul disco, riutilizzabile in seguito per altri pool o partizioni.

Localizzazione, password e rete

Le schermate successive chiedono paese, fuso orario e layout di tastiera; poi la password di root e un indirizzo email per le notifiche (avvisi di backup, errori dei dischi, allarmi ZFS: conviene metterne uno reale e funzionante).

L'ultima schermata configura la rete di gestione. Qui vanno inseriti hostname FQDN, indirizzo IP con netmask in notazione CIDR, gateway e DNS. Due raccomandazioni importanti:

L'indirizzo IP deve essere statico. Proxmox non è progettato per cambiare indirizzo dopo l'installazione, e in un cluster un cambio di IP è un'operazione delicata.
L'hostname deve essere un FQDN valido e risolvibile, ad esempio pve1.example.com. Il file /etc/hosts deve contenere la corrispondenza fra l'IP di gestione e l'hostname: è da lì che Proxmox ricava il proprio indirizzo, non dal DNS.

Al riavvio, la console mostra l'URL da usare per il primo accesso:

https://192.168.1.10:8006/

Primo accesso all'interfaccia web

L'interfaccia web ascolta sulla porta 8006 in HTTPS, con un certificato autofirmato: il browser mostrerà un avviso di sicurezza, che al primo accesso è normale (più avanti vediamo come sostituire il certificato). Le credenziali sono utente root, password quella impostata durante l'installazione, e come Realm va selezionato Linux PAM standard authentication.

Subito dopo il login compare il popup che segnala l'assenza di una sottoscrizione valida. Non è un blocco funzionale: indica solo che il nodo non è agganciato al repository enterprise.

Configurazione dei repository APT

Questa è la prima operazione da fare su ogni installazione nuova. Di default il nodo punta al repository enterprise, che richiede una sottoscrizione: senza di essa, ogni apt update restituisce un errore 401 e il sistema non riceve aggiornamenti.

A partire da Proxmox VE 9 i repository usano il formato deb822, con file .sources in /etc/apt/sources.list.d/ al posto delle vecchie righe deb ... in sources.list. La struttura è più verbosa ma molto più leggibile.

Disabilitare il repository enterprise

# Il file dichiara il repository enterprise: lo si disattiva
# aggiungendo la direttiva Enabled: false
cat /etc/apt/sources.list.d/pve-enterprise.sources

Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
Enabled: false

Stesso discorso per il repository enterprise di Ceph, definito in /etc/apt/sources.list.d/ceph.sources.

Abilitare il repository no-subscription

# Crea la definizione del repository gratuito no-subscription
cat > /etc/apt/sources.list.d/pve-no-subscription.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

Il repository pve-no-subscription riceve i pacchetti prima di quello enterprise e con meno test alle spalle. Per un laboratorio o un server personale è la scelta normale; in produzione, se non si ha una sottoscrizione, vale almeno la pena di non aggiornare mai alla cieca e di avere backup verificati.

Esiste anche il repository pvetest, riservato al testing delle release candidate: non va mai abilitato su un sistema di produzione.

Verifica e aggiornamento

# Aggiorna gli indici dei pacchetti
apt update

# Applica gli aggiornamenti disponibili
# Su Proxmox si usa sempre dist-upgrade (o "full-upgrade"), mai "upgrade":
# quest'ultimo non installa i nuovi pacchetti e può lasciare il sistema incoerente
apt dist-upgrade -y

# Mostra le versioni dei componenti principali
pveversion -v

Dalla versione 9 è disponibile anche uno strumento dedicato per ispezionare e correggere la configurazione dei repository:

# Elenca i repository configurati e segnala problemi noti
proxmox-repository-manager list

Rimuovere l'avviso di sottoscrizione

Molte guide propongono patch al file JavaScript dell'interfaccia per far sparire il popup. È una modifica che viene sovrascritta a ogni aggiornamento di proxmox-widget-toolkit e che, se la patch non viene aggiornata assieme al pacchetto, può rompere l'interfaccia. Se il server è in produzione, la soluzione corretta e supportata è acquistare una sottoscrizione, anche nel livello Community: costa poco, dà accesso al repository enterprise e finanzia il progetto.

Configurazione della rete

Proxmox usa il classico ifupdown2 con configurazione in /etc/network/interfaces. La particolarità è che le modifiche fatte dall'interfaccia web vengono scritte in /etc/network/interfaces.new e applicate solo al riavvio o con ifreload; questo consente di rivedere i cambiamenti prima di renderli effettivi, cosa preziosa quando si lavora da remoto.

Il bridge Linux

Il modello di rete predefinito è il bridge: vmbr0 è uno switch virtuale al quale sono collegate sia l'interfaccia fisica sia le schede virtuali delle VM. Tutte le macchine risultano quindi direttamente presenti sulla LAN fisica.

# /etc/network/interfaces

auto lo
iface lo inet loopback

# Interfaccia fisica: nessun indirizzo, è solo la porta di uplink del bridge
iface enp1s0 inet manual

# Bridge principale: porta l'indirizzo di gestione del nodo
auto vmbr0
iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports enp1s0
        bridge-stp off
        bridge-fd 0

source /etc/network/interfaces.d/*

Bridge VLAN-aware

Se lo switch a monte è configurato in trunk, conviene rendere il bridge VLAN-aware: in questo modo si può assegnare un VLAN tag direttamente alla singola scheda di rete virtuale della VM, senza creare un bridge per ogni VLAN.

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports enp1s0
        bridge-stp off
        bridge-fd 0
        # Abilita la gestione dei tag VLAN sulle porte del bridge
        bridge-vlan-aware yes
        bridge-vids 2-4094

Bond (aggregazione di link)

Con due o più NIC si può creare un bond per ridondanza e/o aumento di banda. La modalità 802.3ad (LACP) richiede uno switch configurato di conseguenza; active-backup funziona con qualsiasi switch e fornisce solo ridondanza.

iface enp1s0 inet manual
iface enp2s0 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves enp1s0 enp2s0
        bond-miimon 100
        bond-mode 802.3ad
        # Distribuisce il traffico usando IP e porte di livello 3/4
        bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0

Rete interna NAT

Per creare una rete privata dietro NAT, ad esempio in un ambiente di laboratorio o su un VPS con un solo IP pubblico, si usa un bridge senza porte fisiche più alcune regole di post-up:

auto vmbr1
iface vmbr1 inet static
        address 10.10.10.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        # Abilita l'inoltro dei pacchetti IPv4 sul nodo
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        # Maschera il traffico uscente della rete interna con l'IP del nodo
        post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE

Applicare le modifiche

# Verifica la sintassi e applica la configurazione senza riavviare
ifreload -a

# Mostra lo stato delle interfacce
ip -br addr show

# Verifica lo stato del bridge e delle porte collegate
bridge link show

Configurazione dello storage

Lo storage in Proxmox è definito a livello di datacenter nel file /etc/pve/storage.cfg, condiviso automaticamente fra tutti i nodi del cluster. Ogni storage dichiara quali tipi di contenuto può ospitare: images (dischi VM), rootdir (dischi container), vztmpl (template LXC), iso, backup, snippets.

Gli storage predefiniti

Con l'installazione su LVM si trovano due storage: local (una directory su /var/lib/vz, per ISO, template e backup) e local-lvm (il thin pool LVM per i dischi delle VM). Con ZFS si trovano invece local e local-zfs.

Creare un pool ZFS aggiuntivo

# Elenca i dischi disponibili con i loro identificatori stabili
ls -l /dev/disk/by-id/

# Crea un pool in mirror usando gli ID dei dischi (mai /dev/sdX: cambia fra i riavvii)
# ashift=12 -> settori da 4K
zpool create -o ashift=12 tank mirror \
  /dev/disk/by-id/ata-SAMSUNG_SSD_S1 \
  /dev/disk/by-id/ata-SAMSUNG_SSD_S2

# Compressione trasparente: praticamente sempre conveniente
zfs set compression=lz4 tank

# Disattiva l'aggiornamento degli access time: meno scritture inutili
zfs set atime=off tank

# Registra il pool come storage Proxmox per dischi VM e container
pvesm add zfspool tank-vm --pool tank --content images,rootdir

# Verifica lo stato del pool
zpool status tank

Limitare la RAM usata da ZFS

Su un hypervisor la cache ARC compete con la memoria delle VM. È buona pratica imporle un tetto esplicito, tipicamente fra 2 e 8 GB su sistemi di dimensioni medie.

# Limita l'ARC a 8 GB (valore espresso in byte)
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf

# Rigenera l'initramfs perché il modulo viene caricato molto presto nel boot
update-initramfs -u -k all

# Il limite diventa effettivo dopo il riavvio
reboot

Aggiungere uno storage NFS

# Storage di rete condiviso, tipicamente usato per ISO e backup
pvesm add nfs nas-backup \
  --server 192.168.1.50 \
  --export /volume1/proxmox \
  --content backup,iso,vztmpl \
  --options vers=4.2

# Elenca gli storage configurati con spazio usato e disponibile
pvesm status

Aggiungere una directory locale

# Utile per un disco singolo formattato ext4/xfs e montato sul nodo
mkdir -p /mnt/data

# Il montaggio va reso persistente via /etc/fstab usando l'UUID del filesystem
blkid /dev/sdc1

pvesm add dir data-store --path /mnt/data --content backup,iso,snippets

Creare una macchina virtuale

Prima di creare la VM serve un'immagine ISO. La si può caricare dall'interfaccia web oppure scaricare direttamente sul nodo:

# Le ISO risiedono in questa directory per lo storage "local"
cd /var/lib/vz/template/iso
wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.0.0-amd64-netinst.iso

La creazione via CLI usa il comando qm. L'esempio seguente definisce una VM Linux moderna con impostazioni performanti:

# Crea la VM con ID 100
qm create 100 \
  --name debian-web \
  --memory 4096 \
  --balloon 2048 \
  --cores 2 \
  --sockets 1 \
  --cpu host \
  --ostype l26 \
  --machine q35 \
  --bios ovmf \
  --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1 \
  --scsihw virtio-scsi-single \
  --scsi0 local-lvm:32,discard=on,ssd=1,iothread=1 \
  --ide2 local:iso/debian-13.0.0-amd64-netinst.iso,media=cdrom \
  --net0 virtio,bridge=vmbr0,firewall=1 \
  --boot order='scsi0;ide2' \
  --agent enabled=1

# Avvia la VM
qm start 100

# Apre la console testuale (utile in SSH)
qm terminal 100

Alcune scelte meritano una spiegazione:

--cpu host espone alla VM tutte le istruzioni della CPU fisica: è la configurazione più veloce. Va evitata solo se si prevede di migrare a caldo la VM verso nodi con CPU diverse; in quel caso si sceglie un modello comune come x86-64-v2-AES.
virtio-scsi-single assieme a iothread=1 assegna un thread di I/O dedicato a ogni disco, migliorando sensibilmente le prestazioni sotto carico.
discard=on abilita il TRIM: lo spazio liberato dentro la VM viene effettivamente restituito al thin pool o al pool ZFS.
--agent enabled=1 attiva il canale per il QEMU Guest Agent, indispensabile per gli spegnimenti puliti, i backup consistenti e la visualizzazione degli IP della VM nell'interfaccia.
--balloon definisce il minimo garantito quando il ballooning è attivo: la VM parte con memory e può restituire memoria al nodo fino a scendere a quel valore.

Guest Agent e driver VirtIO

Dentro una VM Linux, dopo l'installazione del sistema:

# Installa e abilita il guest agent nella VM (non sul nodo Proxmox)
apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent

Per le VM Windows la situazione è diversa: il disco virtio-scsi non viene riconosciuto dall'installer, quindi occorre montare come secondo CD-ROM l'ISO dei driver VirtIO e caricare il driver vioscsi durante il partizionamento. Alla fine dell'installazione si esegue virtio-win-guest-tools.exe dalla stessa ISO, che installa driver di rete, ballooning e guest agent.

Template e cloud-init

Per creare VM in serie il metodo più efficiente è partire da un'immagine cloud e usare cloud-init per la personalizzazione al primo avvio.

# Scarica l'immagine cloud ufficiale di Debian
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2

# Crea una VM minimale che farà da template
qm create 9000 --name debian-13-template --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0 --ostype l26 --machine q35 --agent enabled=1

# Importa l'immagine come disco principale della VM
qm set 9000 --scsihw virtio-scsi-single --scsi0 local-lvm:0,import-from=$(pwd)/debian-13-genericcloud-amd64.qcow2,discard=on,ssd=1

# Aggiunge il drive cloud-init da cui la VM leggerà la configurazione
qm set 9000 --ide2 local-lvm:cloudinit

# Avvia dal disco e abilita la console seriale (le immagini cloud la usano)
qm set 9000 --boot order=scsi0 --serial0 socket --vga serial0

# Trasforma la VM in template: da qui in poi è in sola lettura
qm template 9000

# Clona il template in modo "linked" (istantaneo, occupa solo i delta)
qm clone 9000 101 --name web01

# Imposta i parametri cloud-init del clone
qm set 101 --ciuser gabriele
qm set 101 --sshkeys ~/.ssh/id_ed25519.pub
qm set 101 --ipconfig0 ip=192.168.1.101/24,gw=192.168.1.1
qm set 101 --nameserver 1.1.1.1

# Aumenta il disco: le immagini cloud partono da pochi GB
qm resize 101 scsi0 +30G

qm start 101

Creare un container LXC

I container LXC condividono il kernel dell'host: consumano molta meno RAM di una VM, si avviano in un secondo e sono ideali per servizi Linux dove non serve un kernel dedicato. Il prezzo è un isolamento inferiore e l'impossibilità di eseguire kernel o sistemi operativi diversi da Linux.

# Aggiorna l'elenco dei template disponibili
pveam update

# Cerca i template Debian
pveam available --section system | grep debian

# Scarica il template sullo storage "local"
pveam download local debian-13-standard_13.0-1_amd64.tar.zst

# Crea un container non privilegiato (impostazione consigliata)
pct create 200 local:vztmpl/debian-13-standard_13.0-1_amd64.tar.zst \
  --hostname ct-nginx \
  --cores 2 \
  --memory 1024 \
  --swap 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=192.168.1.200/24,gw=192.168.1.1,firewall=1 \
  --nameserver 1.1.1.1 \
  --unprivileged 1 \
  --features nesting=1 \
  --ssh-public-keys ~/.ssh/id_ed25519.pub \
  --onboot 1 \
  --start 1

# Entra nel container
pct enter 200

La distinzione fra container privilegiati e non privilegiati è centrale: nei secondi l'utente root del container è mappato a un UID non privilegiato dell'host, quindi un'eventuale evasione dal container non dà accesso root alla macchina fisica. Vanno sempre preferiti. nesting=1 serve se dentro il container si vuole usare Docker o systemd in configurazioni particolari.

Bind mount da host a container

# Monta una directory dell'host dentro il container
# Nota: i bind mount impediscono la migrazione automatica del container
pct set 200 -mp0 /mnt/data/www,mp=/var/www

Con i container non privilegiati bisogna ricordare che gli UID sono traslati di 100000: il file di proprietà di root nel container appartiene all'UID 100000 sull'host, e i permessi vanno impostati di conseguenza.

Backup e restore

Il backup è la funzionalità che più di ogni altra giustifica l'adozione di Proxmox. Lo strumento nativo è vzdump, che produce archivi di VM e container e può essere pianificato dall'interfaccia web sotto Datacenter → Backup.

Modalità di backup

Stop: ferma la macchina, la copia, la riavvia. Massima consistenza, massimo downtime.
Suspend: sospende la macchina durante la copia. Compromesso ormai poco usato.
Snapshot: nessun downtime. È la modalità normale. Per ottenere backup applicativamente consistenti (database, filesystem con scritture in volo) è indispensabile che il guest agent sia installato e che sia attivo il fsfreeze.

# Backup manuale di una VM su storage NFS, compresso con Zstandard
vzdump 100 --storage nas-backup --mode snapshot --compress zstd --notes-template '{{guestname}}'

# Backup di tutte le macchine escludendo alcuni ID
vzdump --all --exclude 9000,200 --storage nas-backup --mode snapshot --compress zstd

# Ripristino con un nuovo ID (150) su uno storage diverso
qmrestore /mnt/pve/nas-backup/dump/vzdump-qemu-100-2026_07_17-02_00_01.vma.zst 150 --storage local-lvm

# Ripristino di un container
pct restore 250 /mnt/pve/nas-backup/dump/vzdump-lxc-200-2026_07_17-02_00_01.tar.zst --storage local-lvm

Politiche di ritenzione

Dalla versione 7 la ritenzione non si esprime più con il solo maxfiles, ma con una politica granulare che ricorda quella di Proxmox Backup Server:

# Conserva: ultimi 3, 7 giornalieri, 4 settimanali, 6 mensili
vzdump 100 --storage nas-backup --prune-backups keep-last=3,keep-daily=7,keep-weekly=4,keep-monthly=6

Proxmox Backup Server

Per qualsiasi installazione seria, vale la pena affiancare a Proxmox VE un Proxmox Backup Server: introduce backup incrementali con deduplicazione a blocchi, verifica periodica dell'integrità, cifratura lato client e sincronizzazione fra datastore remoti. La differenza rispetto a vzdump su NFS è enorme, sia in spazio occupato sia in durata delle finestre di backup.

# Aggiunge un datastore PBS come storage del datacenter
pvesm add pbs backup-remoto \
  --server pbs.example.com \
  --datastore store1 \
  --username backup@pbs \
  --password \
  --fingerprint aa:bb:cc:dd:ee:ff:...

Una regola pratica che vale la pena ripetere: un backup che non è mai stato ripristinato non è un backup, è una speranza. Vale la pena provare periodicamente un restore su un ID diverso, in una rete isolata.

Snapshot

Gli snapshot congelano lo stato di una macchina in un istante e permettono di tornarci indietro. Sono supportati solo su storage che li implementano: ZFS, LVM-thin, qcow2 su directory, Ceph RBD. Non funzionano su LVM classico o su dischi raw.

# Snapshot con memoria RAM inclusa (la VM torna esattamente allo stato di runtime)
qm snapshot 100 pre-upgrade --vmstate 1 --description "Prima aggiornamento kernel"

# Elenca gli snapshot
qm listsnapshot 100

# Torna allo snapshot
qm rollback 100 pre-upgrade

# Rimuove lo snapshot (libera lo spazio occupato dai delta)
qm delsnapshot 100 pre-upgrade

Gli snapshot non sono backup: risiedono sullo stesso storage della macchina e non sopravvivono alla perdita del pool. Vanno usati come rete di sicurezza a breve termine, ad esempio prima di un aggiornamento, e rimossi subito dopo: lasciarli attivi a lungo degrada le prestazioni e consuma spazio in modo imprevedibile.

Utenti, permessi e autenticazione

Il modello di autorizzazione di Proxmox si basa su tre elementi: utenti (identificati come nome@realm), ruoli (insiemi di privilegi) e ACL (associazioni fra utente/gruppo, ruolo e percorso).

# Crea un realm interno (utenti gestiti da Proxmox, non da PAM)
# Il realm "pve" esiste già di default

# Crea un gruppo e un utente
pveum group add operatori --comment "Operatori di sala macchine"
pveum user add gabriele@pve --password --groups operatori

# Assegna al gruppo il ruolo di amministratore delle VM sull'intero datacenter
pveum acl modify / --groups operatori --roles PVEVMAdmin

# Ruolo personalizzato: solo avvio, arresto e console
pveum role add OperatoreVM --privs "VM.PowerMgmt VM.Console VM.Audit"

# Applica il ruolo a un pool specifico
pveum pool add produzione
pveum acl modify /pool/produzione --users gabriele@pve --roles OperatoreVM

I pool sono contenitori logici di risorse (VM, container, storage) e servono proprio a delegare permessi su un sottoinsieme dell'infrastruttura senza dare accesso a tutto il datacenter.

Autenticazione a due fattori

Su un'interfaccia raggiungibile in rete, il 2FA sull'utente root non è opzionale. Proxmox supporta TOTP, WebAuthn (chiavi hardware come YubiKey), recovery key e Yubico OTP. Si configura da Datacenter → Two Factor, oppure via CLI:

# Aggiunge un secondo fattore TOTP all'utente root
pveum user tfa add totp root@pam --description "Telefono personale"

Prima di attivare il 2FA conviene generare e conservare offline le recovery key: senza di esse, la perdita del telefono comporta l'accesso da console fisica e la rimozione manuale del fattore da /etc/pve/priv/tfa.cfg.

Certificati TLS con Let's Encrypt

Il certificato autofirmato funziona ma è scomodo. Proxmox integra un client ACME che gestisce emissione e rinnovo automatico. Il metodo DNS-01 è preferibile a HTTP-01, perché non richiede che la porta 80 del nodo sia esposta su Internet e supporta i wildcard.

# Registra un account ACME (accetta i termini di servizio di Let's Encrypt)
pvenode acme account register default admin@example.com --directory https://acme-v02.api.letsencrypt.org/directory

# Configura un plugin DNS-01 (esempio con Cloudflare)
# Il file dei dati contiene il token API con permessi di edit sulla zona DNS
cat > /root/cf.ini <<'EOF'
CF_Token=il_tuo_token_api
CF_Zone_ID=id_della_zona
EOF

pvenode acme plugin add dns cloudflare --api cf --data /root/cf.ini

# Associa il dominio al nodo usando il plugin appena creato
pvenode config set --acme account=default
pvenode config set --acmedomain0 domain=pve1.example.com,plugin=cloudflare

# Richiede il certificato
pvenode acme cert order

# Verifica la data di scadenza
pvenode cert info

Il rinnovo avviene automaticamente tramite il timer systemd pve-daily-update.timer, che rinnova i certificati con meno di 30 giorni di vita residua.

Firewall

Proxmox integra un firewall a tre livelli: datacenter (regole valide su tutti i nodi), nodo (protegge l'host) e VM/container (applicato alla singola scheda virtuale). Le regole si sommano e il firewall va abilitato esplicitamente a ogni livello.

L'errore più comune è abilitare il firewall a livello di datacenter senza aver prima creato una regola che permetta l'accesso alla porta 8006 e a SSH: il risultato è restare chiusi fuori dal proprio server. Per questo esiste il concetto di Security Group e la sezione Alias, che permettono di preparare le regole prima di attivare tutto.

# /etc/pve/firewall/cluster.fw

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[ALIASES]
# Rete di gestione da cui è consentita l'amministrazione
lan_admin 192.168.1.0/24

[group management]
# Interfaccia web di Proxmox
IN ACCEPT -source +lan_admin -p tcp -dport 8006 -log nolog
# SSH
IN ACCEPT -source +lan_admin -p tcp -dport 22 -log nolog
# Console SPICE e noVNC
IN ACCEPT -source +lan_admin -p tcp -dport 3128 -log nolog
IN ACCEPT -source +lan_admin -p tcp -dport 5900:5999 -log nolog

[RULES]
GROUP management

Nei cluster va sempre consentito il traffico Corosync (UDP 5405-5412) fra i nodi, altrimenti il cluster si spezza appena si attiva il firewall.

# Stato del firewall e regole effettivamente caricate
pve-firewall status

# Simula il compilato delle regole senza applicarle
pve-firewall compile

# Log del firewall
pve-firewall localnet

Creare un cluster

Con due o più nodi si può formare un cluster e ottenere migrazione a caldo, gestione centralizzata e alta disponibilità. Il cluster usa Corosync per la comunicazione e il filesystem distribuito pmxcfs, montato su /etc/pve, per replicare la configurazione su tutti i nodi.

Prerequisiti: nodi con hostname e IP distinti, orologi sincronizzati via NTP, risoluzione dei nomi funzionante, nessuna VM con lo stesso ID su nodi diversi e, soprattutto, i nodi che si aggiungono devono essere vuoti: l'operazione di join sovrascrive la loro configurazione.

# Sul primo nodo: crea il cluster
# --link0 indica l'indirizzo usato per il traffico Corosync
pvecm create produzione --link0 10.0.0.10

# Sugli altri nodi: entra nel cluster (chiede la password di root del primo nodo)
pvecm add 10.0.0.10 --link0 10.0.0.11

# Stato del cluster e quorum
pvecm status

# Elenco dei nodi
pvecm nodes

Quorum e rete Corosync

Il cluster è operativo solo se ha il quorum, cioè la maggioranza dei voti. Con due nodi soli, la caduta di uno rende il cluster non quorato e blocca ogni modifica: per questo un cluster a due nodi richiede un terzo voto, ottenibile con un QDevice installato su una macchina esterna leggera (anche un Raspberry Pi).

# Sul nodo esterno che farà da arbitro
apt install -y corosync-qnetd

# Su un nodo del cluster
apt install -y corosync-qdevice
pvecm qdevice setup 192.168.1.99

Corosync è estremamente sensibile alla latenza: richiede meno di 5 ms di RTT fra i nodi e va sempre messo su una rete dedicata, mai condivisa con il traffico di storage o dei backup. Configurare un secondo link (--link1) come ridondanza è una precauzione a costo praticamente nullo.

Migrazione

# Migrazione a caldo di una VM su un altro nodo (richiede storage condiviso)
qm migrate 100 pve2 --online

# Migrazione con spostamento dei dischi su storage locale
qm migrate 100 pve2 --online --with-local-disks --targetstorage local-lvm

# I container si migrano solo a freddo (o con un breve restart)
pct migrate 200 pve2 --restart

Replica ZFS

Senza uno storage condiviso, la replica ZFS permette comunque di avere una copia periodica della VM su un altro nodo, riducendo drasticamente il tempo di ripristino e rendendo quasi istantanea la migrazione.

# Replica la VM 100 sul nodo pve2 ogni 15 minuti
pvesr create-local-job 100-0 pve2 --schedule "*/15"

# Stato dei job di replica
pvesr status

Alta disponibilità

Con almeno tre nodi e uno storage condiviso (o la replica ZFS) si può attivare l'HA: se un nodo cade, le VM marcate come risorse HA vengono riavviate automaticamente su un altro nodo.

# Definisce un gruppo HA con priorità sui nodi
ha-manager groupadd prod --nodes "pve1:2,pve2:1,pve3:1"

# Aggiunge la VM 100 alle risorse gestite
ha-manager add vm:100 --group prod --max_restart 2 --max_relocate 1 --state started

# Stato del gestore HA
ha-manager status

Va compreso bene il meccanismo di fencing: quando un nodo perde il quorum, il watchdog hardware o software lo riavvia forzatamente dopo circa 60 secondi, per garantire che la VM non risulti attiva su due nodi contemporaneamente. Non è un comportamento aggirabile: è la condizione che rende sicura la ripartenza altrove.

Notifiche

Dalla versione 8 il sistema di notifiche è stato riscritto: si basa su endpoint (sendmail, SMTP, Gotify, webhook) e matcher che decidono quali eventi inviare dove. Configurare l'invio email è tra le prime cose da fare, perché è l'unico modo per accorgersi in tempo di un disco che sta morendo.

# Crea un endpoint SMTP autenticato
pvesh create /cluster/notifications/endpoints/smtp \
  --name mailer \
  --server smtp.example.com \
  --port 587 \
  --mode starttls \
  --username notifiche@example.com \
  --password \
  --from-address proxmox@example.com \
  --mailto admin@example.com

# Invia una notifica di prova
pvesh create /cluster/notifications/endpoints/smtp/mailer/test

Va poi verificato che lo smartd sia attivo e configurato per segnalare gli errori SMART dei dischi, e che gli avvisi ZFS (zed) puntino allo stesso indirizzo.

Hardening e buone pratiche

Alcune misure che conviene applicare su ogni installazione destinata alla produzione:

Non esporre mai la porta 8006 su Internet. L'accesso remoto va fatto tramite VPN (WireGuard è la scelta naturale) o tramite un reverse proxy con autenticazione forte davanti.
Disabilitare l'accesso SSH con password e usare solo chiavi. Nei cluster va ricordato che i nodi si autenticano fra loro con chiavi in /etc/pve/priv/authorized_keys.
Non usare root per l'amministrazione quotidiana: creare utenti dedicati con i ruoli minimi necessari.
Attivare il 2FA su tutti gli account amministrativi.
Monitorare lo spazio del thin pool: un thin pool LVM che raggiunge il 100% corrompe i dati delle VM, e non è un'esagerazione retorica.
Fare lo scrub periodico dei pool ZFS (Proxmox ne configura uno mensile) e leggere davvero le email che ne riportano l'esito.
Salvare la configurazione dell'host: /etc/pve, /etc/network/interfaces, /etc/hosts, /etc/apt/sources.list.d/. vzdump salva le VM, non l'hypervisor.

# Disabilita l'autenticazione a password e il login root con password via SSH
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
systemctl restart ssh

# Controlla l'occupazione del thin pool: la colonna Data% è quella critica
lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent

# Avvia uno scrub manuale del pool ZFS
zpool scrub tank

Diagnostica: i comandi da conoscere

# Versione dei componenti e stato dei pacchetti
pveversion -v

# Stato dei servizi principali
systemctl status pveproxy pvedaemon pve-cluster pvestatd

# Log del demone principale in tempo reale
journalctl -u pvedaemon -f

# Task recenti con esito (equivalente del pannello "Tasks" nella web UI)
cat /var/log/pve/tasks/index

# Configurazione completa di una VM
qm config 100

# Elenca tutte le VM con il loro stato
qm list

# Elenca i container
pct list

# Sblocca una VM rimasta in stato di lock dopo un task fallito
# Da usare solo dopo essersi accertati che il task sia realmente terminato
qm unlock 100

# Statistiche di I/O e carico del nodo
pvesh get /nodes/localhost/status --output-format json-pretty

Un'ultima nota su /etc/pve: è un filesystem FUSE sincronizzato via Corosync, non una directory normale. Se il cluster perde il quorum, diventa in sola lettura, ed è esattamente il motivo per cui in quella condizione non si riesce più a modificare nulla. Il database sottostante è un SQLite in /var/lib/pve-cluster/config.db.

Conclusioni

Proxmox VE è uno di quei progetti che restituiscono molto più di quanto chiedano: si installa in un quarto d'ora, ma le decisioni prese in quel quarto d'ora — filesystem di root, layout della rete, separazione degli storage — condizionano gli anni successivi. Vale quindi la pena partire con calma su ZFS in mirror, con una rete pensata per crescere, con i backup configurati e verificati fin dal primo giorno e con le notifiche che funzionano davvero.

Il passo successivo naturale, una volta consolidato il singolo nodo, è affiancargli un Proxmox Backup Server e poi valutare un cluster a tre nodi: è a quel punto che la piattaforma smette di essere semplicemente un hypervisor comodo e diventa un'infrastruttura seria.