Proxmox VE 9 in homelab: checklist pratica prima dell'upgrade

Proxmox VE 9 è una release importante: base Debian 13, kernel più recente, QEMU 10, LXC 6, Ceph Squid e OpenZFS 2.3. Non è il classico aggiornamento “clicca e spera”. In un homelab serio, o in una piccola infrastruttura aziendale dove Proxmox regge servizi reali, va trattato come una manutenzione programmata: inventario, backup verificati, finestra di downtime e piano di rollback.

La buona notizia è che l'upgrade è gestibile. La cattiva è che molte installazioni homelab crescono per stratificazione: bridge creati anni fa, storage NFS montati “al volo”, VM critiche senza documentazione, container LXC con bind mount locali, nodi cluster con versioni miste. Proxmox VE 9 porta miglioramenti interessanti, ma proprio per questo conviene arrivarci con ordine.

Perché valutare Proxmox VE 9

Le novità più utili per un SysAdmin non sono solo “versioni più nuove”. Debian 13 porta una base più moderna e supportabile, QEMU 10 migliora la parte di virtualizzazione, LXC 6 aggiorna il mondo container, ZFS 2.3 introduce evoluzioni importanti e Ceph Squid è il riferimento per chi usa cluster storage. Nella roadmap Proxmox compaiono anche lavori interessanti sulle snapshot come catene di volumi, pensate per estendere semantiche simili a storage che storicamente erano meno flessibili rispetto a ZFS.

In pratica: Proxmox VE 9 è interessante se vuoi restare su una piattaforma aggiornata, prepararti alle prossime feature e ridurre il debito tecnico. Non è invece obbligatorio aggiornarlo il primo giorno su nodi che ospitano servizi critici e funzionano bene.

Prima regola: backup verificato, non “backup presente”

Prima di toccare il nodo, verifica davvero i backup. Se usi Proxmox Backup Server, controlla almeno:

• ultimo backup riuscito per ogni VM e container;
• job di verifica completati senza errori;
• spazio libero sul datastore;
• retention coerente con il rischio accettabile;
• possibilità di ripristino su storage alternativo.

Un controllo rapido da shell sul nodo può aiutare:

pvesm status
vzdump --dumpdir /tmp --mode snapshot --compress zstd <VMID>

Non serve fare un backup manuale di tutto se PBS è sano, ma per le VM più critiche ha senso lanciare un backup on-demand prima della manutenzione. Ancora meglio: prova almeno un restore parziale o un file restore da PBS. Un backup mai testato è una speranza, non una procedura.

Inventario minimo del nodo

Prima dell'upgrade salva lo stato attuale. Bastano pochi comandi, ma devono finire fuori dal nodo: nel tuo repository di documentazione, in un vault, o almeno su un altro server.

pveversion -v
pvecm status
qm list
pct list
pvesm status
ip -br addr
ip route
cat /etc/network/interfaces

Se usi ZFS:

zpool status
zfs list
zpool get all | grep -E 'ashift|autotrim|fragmentation'

Se usi Ceph:

ceph -s
ceph osd tree
ceph versions

Questo inventario serve per due motivi. Primo: capire cosa stai aggiornando. Secondo: avere un riferimento se dopo il reboot una VM non parte, uno storage non monta o un bridge non si comporta come prima.

Attenzione a rete e storage

Le rogne peggiori negli upgrade Proxmox spesso non sono nella GUI, ma in rete e storage. Controlla bridge Linux, bond, VLAN e MTU. Se hai configurazioni particolari, evita di “pulire” file di rete durante la stessa finestra dell'upgrade. Cambia una cosa alla volta.

Per lo storage, verifica mount NFS/CIFS, target iSCSI, multipath e datastore locali. Se hai VM con disco su storage remoto, la disponibilità di quello storage durante il reboot è fondamentale. Se usi Directory storage su dischi esterni o mount manuali, assicurati che siano in /etc/fstab o gestiti in modo prevedibile.

ZFS merita una nota separata: Proxmox VE 9 include OpenZFS 2.3.x, con novità importanti come l'espansione RAIDZ aggiungendo device. È una funzione interessante, ma non la mischiare con l'upgrade di piattaforma. Prima aggiorna e stabilizza. Solo dopo valuta modifiche strutturali ai pool.

Cluster: niente fretta e quorum sotto controllo

Su un cluster Proxmox, aggiorna un nodo alla volta. Prima svuota il nodo con migrazioni live dove possibile, oppure spegni ordinatamente le VM meno adatte alla migrazione. Controlla quorum e stato cluster:

pvecm status
ha-manager status

Se usi HA, evita manutenzioni improvvisate: metti i servizi in stato gestibile, documenta quali risorse possono muoversi e quali no, e verifica che lo storage condiviso sia realmente condiviso. Le versioni miste tra nodi sono tollerabili durante una finestra di upgrade, non come stato permanente.

Sequenza consigliata

Una procedura ragionevole per homelab e piccoli ambienti IT è questa:

1. leggere le note di rilascio Proxmox VE 9 e la pagina roadmap;
2. aggiornare completamente Proxmox VE 8 all'ultima minor disponibile;
3. verificare backup e restore;
4. esportare inventario di rete, storage, VM e container;
5. pianificare finestra e comunicare downtime;
6. aggiornare un nodo non critico o meno carico;
7. reboot e verifica VM/container;
8. attendere qualche giorno prima di aggiornare i nodi più importanti.

Non aggiornare anche firmware, schema di rete, layout ZFS e versione Proxmox nella stessa notte. È efficiente solo finché qualcosa non si rompe; poi diventa impossibile capire la causa.

Checklist post-upgrade

Dopo il reboot, non limitarti a vedere la dashboard verde. Controlla:

• pveversion -v per confermare i pacchetti;
• stato cluster e quorum;
• storage disponibili in pvesm status;
• avvio automatico delle VM critiche;
• console VNC/SPICE;
• rete interna ed esterna delle VM;
• job di backup notturni;
• log di sistema con journalctl -p warning..alert -b.

Per un homelab, aggiungerei anche un test molto concreto: spegni e riaccendi una VM non critica, fai una migrazione se hai cluster, lancia un backup manuale verso PBS e prova un file restore. Se questi quattro test passano, hai molte più informazioni di una semplice schermata “running”.

Piano di rollback realistico

Il rollback di un hypervisor non è banale. Per questo il piano deve essere realistico: backup delle VM, configurazioni salvate e possibilità di reinstallare il nodo se necessario. In ambienti piccoli, spesso il rollback più pulito non è “downgrade pacchetti”, ma reinstallazione della versione precedente e restore delle configurazioni/VM.

Se il nodo è standalone, valuta di avere una chiavetta di installazione pronta, accesso IPMI o console fisica, credenziali PBS e documentazione di rete. Se è cluster, assicurati di poter spostare i carichi sugli altri nodi prima di intervenire.

Conclusione

Proxmox VE 9 è una release da seguire con attenzione, soprattutto per chi usa Proxmox come base di laboratorio avanzato o piccola produzione. Il punto non è avere paura dell'upgrade: è evitare l'approccio casuale. Backup verificati, inventario, controllo di rete e storage, upgrade graduale e test post-reboot sono la differenza tra una manutenzione ordinata e una notte persa davanti alla console.

Il mio consiglio: prepara ora la checklist, aggiorna prima un nodo secondario e non mischiare l'upgrade con altri cambiamenti infrastrutturali. In un homelab ben gestito, la disciplina operativa conta quanto l'hardware.

Fonti principali: note di rilascio Proxmox VE 9, roadmap Proxmox VE, documentazione Proxmox Backup Server e note Proxmox Backup Server 4.x.