Checklist pre-upgrade Proxmox VE 9: 12 controlli prima di aggiornare

Prima di passare da Proxmox VE 8.4 a Proxmox VE 9, non cambierei una singola riga dei repository finché questi 12 controlli non sono verdi. Il major upgrade coinvolge infatti Debian, kernel, QEMU, LXC, ZFS, rete, bootloader e, negli ambienti più complessi, Ceph e HA: il rischio vero non è lanciare apt dist-upgrade, ma scoprire durante il reboot che mancava una via di recovery.

A settembre 2026 Proxmox VE 9.2 è la release corrente della serie 9, basata su Debian 13.5 "Trixie". Proxmox aveva indicato agosto 2026 come termine della finestra di security update e correzioni critiche per PVE 8.4. Se sei ancora su 8.4, quindi, ha senso pianificare il passaggio senza rimandarlo, ma evitando un upgrade improvvisato.

Questa è una checklist pre-upgrade, non la procedura completa. Se hai già verificato tutti i punti e devi eseguire materialmente il passaggio, trovi la sequenza operativa nella mia guida Upgrade Proxmox VE 8 a 9: procedura reale.

Regola pratica: se uno dei controlli su backup, console, storage, cluster o pve8to9 fallisce, per me l'upgrade è NO-GO finché il problema non viene risolto.

Checklist rapida: i 12 controlli

#	Controllo	Condizione per procedere
1	Versione di partenza	PVE 8.4 completamente aggiornato
2	`pve8to9 --full`	Nessuna failure; warning compresi e gestiti
3	Backup	Backup recenti e almeno un restore verificato
4	Configurazione host	Copia esterna di rete, storage, firewall e repository
5	Console fuori banda	IPMI, iKVM, console provider o accesso fisico disponibile
6	Spazio e filesystem	Root con margine, filesystem e pool senza errori
7	Storage	Tutti gli storage critici attivi e raggiungibili
8	Cluster, HA e Ceph	Quorum sano, piano nodo-per-nodo, Ceph compatibile
9	Repository e pacchetti extra	Nessun repository o modulo terzo non verificato per Trixie
10	Rete	Bridge, bond, VLAN, NIC e route documentati
11	Guest legacy e passthrough	LXC, VM datate, DKMS e passthrough verificati
12	Recovery e finestra	Runbook, rollback, ordine di riaccensione e monitoraggio pronti

1. Verifica di partire dall'ultima PVE 8.4

Il passaggio supportato verso PVE 9 parte da una Proxmox VE 8.4 aggiornata. Prima di pensare a Trixie, aggiorna ancora il sistema mantenendo i repository Bookworm/PVE 8.

pveversion -v
apt update
apt dist-upgrade

Poi verifica di nuovo:

pveversion

Non cambiare i repository a Trixie prima di avere completato questo passaggio. Se apt update restituisce errori, chiavi scadute o repository irraggiungibili, quello è già un blocker.

GO: PVE 8.4 aggiornata e apt update pulito.
NO-GO: pacchetti trattenuti o repository PVE 8 già incoerenti.

2. Esegui il checker ufficiale `pve8to9 --full`

È il controllo più importante e va eseguito prima di modificare i repository:

pve8to9 --full

Il checker analizza molti problemi noti della migrazione. Non modifica automaticamente il nodo: segnala failure, warning, notice e controlli che richiedono una decisione.

La mia regola è semplice:

una FAILURE blocca l'upgrade;
un WARNING deve essere capito, non semplicemente ignorato;
dopo ogni correzione, rilancia pve8to9 --full.

Nella procedura reale di upgrade a PVE 9 mostro anche alcuni warning che ho incontrato sul mio nodo, tra storage PBS, spazio disco, NTP e boot.

GO: nessuna failure e ogni warning ha una spiegazione e una mitigazione.
NO-GO: continui con l'idea di "vedere cosa succede" durante dist-upgrade.

3. Verifica backup e restore, non solo la data dell'ultimo job

Vedere un job verde non dimostra che il recovery funzioni.

Prima del major upgrade controlla almeno:

backup recenti di VM e LXC;
datastore raggiungibile;
verifica dei backup PBS, se lo usi;
spazio disponibile sul target di backup;
almeno un restore reale eseguito in un ambiente isolato o su storage di test.

Per una fotografia veloce degli storage:

pvesm status

Per elencare VM e container e assicurarti di non dimenticare workload:

qm list
pct list

Se usi Proxmox Backup Server, verifica anche che datastore, verify job e retention siano coerenti. Un backup non recuperabile non è un rollback.

Ho approfondito questo punto anche nella guida sui backup in ambiente Proxmox e nell'articolo sulle architetture storage resilienti.

GO: sai esattamente da quale backup ripristinare almeno i workload critici.
NO-GO: l'unica prova è che "il backup stanotte è diventato verde".

4. Salva la configurazione dell'host fuori dal nodo

Il backup dei guest non contiene necessariamente tutto ciò che ti serve per ricostruire l'hypervisor.

Prima dell'upgrade salvo almeno:

/etc/pve
/etc/network/interfaces
/etc/hosts
/etc/resolv.conf
configurazione APT
eventuali file custom relativi a firewall, passthrough, moduli e mount

Un archivio di base può essere creato così:

tar czf /root/pve-config-$(date +%F).tar.gz \
  /etc/pve \
  /etc/network/interfaces \
  /etc/hosts \
  /etc/resolv.conf \
  /etc/apt

Poi copialo fuori dal nodo. Lasciare l'unica copia in /root sul server che stai per aggiornare non è una strategia di recovery.

Se utilizzi configurazioni custom per IOMMU, GPU/NIC passthrough, bonding, VLAN o mount particolari, documentale separatamente.

GO: configurazione disponibile su un sistema esterno.
NO-GO: per ricostruire rete o storage dovresti affidarti alla memoria.

5. Assicurati di avere una console fuori banda

Un major upgrade cambia anche kernel e componenti di rete. Se dopo il reboot l'interfaccia di management non torna, SSH non ti aiuta.

Prima di iniziare verifica realmente l'accesso tramite almeno uno di questi canali:

IPMI;
iKVM;
console remota del provider;
accesso fisico al server.

Su un dedicato remoto apro la console prima della manutenzione e verifico che accetti input. Non considero sufficiente sapere che "dovrebbe esserci".

Evita inoltre di eseguire un major upgrade dalla console integrata nella Web UI di Proxmox: dipende dai servizi che stai aggiornando.

GO: puoi intervenire anche se management network e SSH non rispondono.
NO-GO: SSH è l'unica via di accesso.

6. Controlla spazio, inode, filesystem, ZFS e boot

Prima di aggiornare controlla che il nodo non stia già lavorando al limite:

df -h /
df -i /
lsblk -f
systemctl --failed

Se usi ZFS:

zpool status
zpool list

Controlla anche il bootloader:

proxmox-boot-tool status

pve8to9 --full può segnalare problemi legati al boot, incluso il caso del meta-pacchetto systemd-boot in configurazioni dove interferirebbe con gli aggiornamenti. Non applicare correzioni generiche prese da una guida: interpreta il warning in base a come è installato il tuo host.

Lo spazio libero minimo non dovrebbe essere trattato come un obiettivo. Voglio margine sufficiente per scaricare pacchetti, generare initramfs, mantenere log e completare l'upgrade senza arrivare al 100% di /.

GO: nessun errore filesystem/pool, boot coerente, root con margine.
NO-GO: pool degradato, root quasi piena o warning boot non compresi.

7. Verifica tutti gli storage, compreso PBS

Un major upgrade con uno storage dichiarato attivo ma irraggiungibile parte già male.

Controlla:

pvesm status
findmnt

Se usi NFS, iSCSI, Ceph, ZFS, SMB/CIFS o storage custom, verifica anche:

mount effettivamente presenti;
path accessibili;
latenza e connettività;
credenziali/token ancora validi;
assenza di errori recenti nei log;
spazio disponibile.

Per i log del boot corrente:

journalctl -p warning..alert -b --no-pager

Se hai un PBS separato, assicurati che sia raggiungibile e che tu sappia come ripristinare i workload anche durante una perdita temporanea del nodo PVE. Se PBS è installato sullo stesso host di PVE, devi coordinare anche il passaggio PBS 3 → 4 e i relativi repository Trixie.

GO: ogni storage critico è attivo, sano e previsto nel piano.
NO-GO: un datastore "torna quasi sempre" o è già in errore prima dell'upgrade.

8. Se sei in cluster, controlla quorum, HA e Ceph

La checklist di un nodo standalone non basta per un cluster.

Prima di aggiornare un nodo:

pvecm status
ha-manager status

Se usi Ceph:

ceph -s
ceph versions

Il cluster deve essere sano e avere quorum. Devi inoltre sapere dove migrare le VM e quanta capacità rimarrà sugli altri nodi durante la manutenzione.

Per un cluster PVE 8.4 con Ceph Reef, Proxmox indica un percorso in due fasi: prima l'upgrade di Ceph a Squid 19.2, poi il passaggio PVE 8.4 → 9. Non improvvisare l'ordine dei componenti.

Aggiorna i nodi uno alla volta, verificando stabilità, storage, migrazione e workload prima di passare al successivo.

GO: quorum sano, capacità di evacuazione sufficiente, Ceph coerente con il percorso ufficiale.
NO-GO: cluster già degradato o nessuno spazio per spostare i guest.

9. Inventaria repository, pacchetti terzi e moduli DKMS

PVE 9 porta il sistema da Debian 12 Bookworm a Debian 13 Trixie. Il punto critico non sono solo i repository Proxmox, ma ciò che hai aggiunto negli anni.

Prima di cambiarli, inventaria:

grep -RhsE '^(deb|Types:|URIs:|Suites:|Components:)' \
  /etc/apt/sources.list /etc/apt/sources.list.d/* 2>/dev/null

apt policy
apt-mark showmanual | sort

Per eventuali moduli DKMS:

command -v dkms >/dev/null && dkms status

Presta particolare attenzione a:

repository vendor;
agent di monitoring;
driver GPU;
driver NIC/storage fuori albero;
moduli ZFS o DKMS installati manualmente;
software di backup o sicurezza;
pacchetti pinning/hold.

Con PVE 9.2 il kernel stabile corrente è della serie 7.0. Un modulo terzo che funzionava sul kernel di PVE 8 non va dato per compatibile.

GO: ogni componente esterno è compatibile con Debian 13 e con il kernel previsto, oppure può essere disabilitato/rimosso.
NO-GO: non sai perché esiste un repository o quale pacchetto dipende da esso.

10. Documenta la rete e il rischio di rinomina delle NIC

Un reboot che torna con un nome NIC diverso può trasformare un upgrade riuscito in un server irraggiungibile.

Prima della manutenzione salva almeno:

ip -br link
ip -br addr
ip route
cat /etc/network/interfaces

Controlla con attenzione:

bridge vmbrX;
bond;
VLAN;
route statiche;
MTU;
firewall host;
interfaccia usata per Corosync;
interfaccia di management.

La documentazione Proxmox segnala che nuove versioni di systemd, kernel o driver possono cambiare i nomi prevedibili delle interfacce. PVE offre anche pve-network-interface-pinning per generare nomi persistenti e aggiornare varie configurazioni, ma non lo userei a ridosso dell'upgrade senza test: è una modifica di rete distinta che richiede un reboot e una verifica propria.

GO: sai quale NIC fisica alimenta ogni bridge/bond e hai una console indipendente.
NO-GO: la rete funziona, ma nessuno sa più perché.

11. Cerca LXC legacy, VM molto vecchie, passthrough e dipendenze dal kernel

PVE 9 non è solo "PVE 8 con numeri più alti".

Per i container, controlla le distribuzioni più vecchie: Proxmox VE 9 non supporta più il legacy cgroup v1. Un LXC con userland/systemd troppo vecchio può quindi richiedere un upgrade del sistema operativo o una migrazione a VM.

Inventaria:

pct list
qm list

Per ogni guest critico verifica almeno:

distribuzione e versione;
guest agent;
machine type QEMU se la VM nasce da molte major precedenti;
CPU type;
boot BIOS/UEFI;
passthrough PCI/GPU/USB;
mount point LXC e bind mount;
dipendenze da device host specifici.

Se usi passthrough, controlla anche la configurazione host:

grep -RhsE 'iommu|vfio' /etc/default/grub /etc/kernel/cmdline /etc/modprobe.d/* 2>/dev/null
lspci -nnk

Non fare contemporaneamente upgrade PVE, cambio machine type, cambio CPU type e refactoring del passthrough. Riduci il numero di variabili per finestra di manutenzione.

GO: i guest legacy sono identificati e quelli critici sono stati testati.
NO-GO: scopri l'età di un container solo quando non riparte.

12. Scrivi prima il recovery plan e l'ordine di riaccensione

L'ultimo controllo è organizzativo, ma spesso decide quanto dura un incidente.

Prima di iniziare devi poter rispondere a queste domande:

Qual è il punto esatto in cui dichiaro NO-GO?
Chi può accedere alla console?
Da quale backup ripristino i servizi critici?
Posso reinstallare il nodo e ricollegare gli storage?
In quale ordine riaccendo database, applicazioni, reverse proxy e servizi secondari?
Quali metriche e log devono tornare normali prima di chiudere la manutenzione?

Dopo il reboot non limitarti a verificare che la GUI risponda. Controlla almeno:

pveversion -v
uname -r
systemctl --failed
pvesm status
qm list
pct list
journalctl -p warning..alert -b --no-pager

Per ambienti con molti servizi, pianifica anche l'ordine di startup e un periodo di osservazione. Il rollback di un major upgrade non va immaginato come un semplice downgrade dei pacchetti: la via prudente è poter recuperare configurazione e workload da backup verificati.

GO: esiste una procedura di recovery concreta e qualcuno sa eseguirla.
NO-GO: il piano di rollback è "se va male vediamo".

La mia soglia GO / NO-GO prima di PVE 9

Considero un nodo pronto solo quando posso spuntare tutto:

Quando conviene fermarsi e fare un assessment

Se pve8to9 restituisce warning che non sai interpretare, hai storage non perfettamente affidabili, un cluster con Ceph, passthrough complesso o non hai mai verificato un restore, non considererei l'upgrade una normale attività di patching.

In questi casi posso fare un Assessment Proxmox prima della finestra di manutenzione: inventario del nodo o cluster, lettura dei finding di pve8to9, verifica di backup e recovery, repository, storage, networking e punti di rollback. L'obiettivo è arrivare all'upgrade con una lista chiara di blocker, correzioni e controlli post-reboot.

Scopri il servizio Proxmox oppure contattami per un Assessment Proxmox.

FAQ

`pve8to9 --full` basta per dire che il nodo è pronto?

No. È il checker ufficiale e va eseguito, ma non può sapere tutto del tuo ambiente: per esempio procedure di restore mai provate, dipendenze applicative, accesso alla console, capacity planning del cluster o componenti esterni non riconosciuti.

Posso passare direttamente da PVE 8.4 a PVE 9.2?

La documentazione e l'annuncio di PVE 9.2 confermano il percorso di upgrade dall'ultima PVE 8 alla serie 9 tramite APT, seguendo la guida ufficiale 8 → 9. Prima porta comunque PVE 8.4 all'ultimo stato disponibile e usa pve8to9 --full.

Devo spegnere tutte le VM?

Su un nodo standalone devi pianificare il downtime dei workload ospitati. In cluster puoi migrare i guest su altri nodi, ma devi prima verificare quorum, capacità, HA e compatibilità della migrazione durante una fase con versioni miste.

Se uso Ceph Reef posso aggiornare direttamente PVE?

No per il percorso documentato da PVE 8.4 con Ceph iperconvergente: Proxmox indica prima l'upgrade di Ceph da Reef a Squid, poi l'upgrade di PVE 8.4 a 9.

È sufficiente avere un backup PBS recente?

No. Il requisito utile è avere un backup recuperabile. Un restore testato vale più dell'orario dell'ultimo job riuscito.