Upgrade Proxmox VE 8 a 9: guida completa, pve8to9 e controlli reali

Aggiornare da Proxmox VE 8 a Proxmox VE 9 conviene quando il nodo parte da una versione 8.4 completamente aggiornata, i backup sono stati verificati, gli storage sono raggiungibili e puoi accedere al server anche senza SSH. Se una di queste condizioni manca, la scelta corretta non è forzare l'upgrade: è preparare meglio l'ambiente.

Questa guida unisce due livelli: prima ti aiuta a capire se sei pronto ad aggiornare Proxmox, poi documenta la procedura reale che ho seguito. È quindi utile sia a chi cerca una risposta a “conviene passare a Proxmox VE 9?”, sia a chi è già arrivato ai controlli con pve8to9 o cerca una procedura PVE 8 to 9 verificata sul campo.

Il mio caso non era un cluster e non utilizzava Ceph iperconvergente. Per questi scenari servono pianificazione, ordine di aggiornamento e verifiche dedicate: non applicare automaticamente la sequenza standalone descritta qui.

Il mio scenario era volutamente lineare:

nodo standalone
nessun cluster
nessun Ceph iperconvergente
VM e container spenti prima dell'upgrade
repository aggiornati da Debian 12 "Bookworm" a Debian 13 "Trixie"

Proxmox VE 9 è basato su Debian 13 Trixie e include generazioni più recenti di kernel, QEMU, LXC, ZFS e Ceph. Questi cambiamenti portano un ciclo di vita più lungo, ma aumentano anche l'importanza di verificare repository, storage e compatibilità delle VM più datate.

Questo non è un comando magico da lanciare e sperare che vada bene. È una manutenzione infrastrutturale: backup, check, warning, repository, reboot e verifica finale.

Conviene aggiornare subito? La risposta per scenario

Scenario	Indicazione	Prima di procedere
Nodo standalone su PVE 8.4, aggiornato e recuperabile	Puoi pianificare l'upgrade	Verifica backup, console e `pve8to9 --full`
Repository o storage con errori	Fermati	Correggi `apt update` e storage non attivi
Cluster Proxmox	Procedura dedicata	Verifica quorum, ordine dei nodi e migrazione guest
Ceph iperconvergente	Non applicare direttamente questa procedura	Segui prima la sequenza Ceph ufficiale
VM molto datate	Verifica preventiva	Controlla machine version e compatibilità QEMU

Rimandare non significa restare indefinitamente sulla vecchia versione. Significa eliminare un blocco conosciuto — per esempio un backup mai provato o un repository incompatibile — e fissare una nuova finestra di manutenzione con condizioni più sicure.

Quando procederei

Procederei se il nodo è su Proxmox VE 8.4 aggiornato, pve8to9 --full non mostra failure, i backup sono recuperabili e l'accesso console non dipende esclusivamente dalla rete che stai per aggiornare.

Quando aspetterei

Aspetterei se non conosco lo stato dei repository, uno storage critico è offline, non ho testato il ripristino o non posso intervenire sul server se dopo il reboot la rete non torna disponibile.

Perché pianificare l'upgrade prima che diventi urgente

Aspettare l'ultimo momento è quasi sempre una cattiva idea.

Un hypervisor non è un'applicazione qualsiasi: sopra ci girano VM, container, storage, rete, backup, firewall, reverse proxy, servizi interni e spesso pezzi importanti dell'operatività aziendale.

Fare l'upgrade con anticipo permette di:

verificare compatibilità di VM e container
correggere warning senza pressione
testare backup e restore
controllare repository e pacchetti di terze parti
gestire eventuali problemi di rete o storage con margine
pianificare downtime ordinato

Il punto non è solo "passare alla versione nuova". Il punto è arrivarci con un sistema leggibile, aggiornato e recuperabile.

Checklist: sei pronto per l'upgrade?

La checklist non sostituisce un piano di recovery. Se vuoi ragionare sulla recuperabilità dell'intera infrastruttura, non soltanto sui file delle singole VM, puoi partire dalla guida sulle architetture storage resilienti in ambiente Proxmox.

1. Aggiornamento completo di Proxmox VE 8

Prima di iniziare il major upgrade ho aggiornato completamente Proxmox VE 8:

apt update
apt dist-upgrade

Nel mio caso il sistema era già aggiornato e apt ha rimosso solo alcuni vecchi kernel Debian non più necessari.

Ho poi verificato il kernel in uso:

uname -r

Output:

6.8.12-20-pve

Questo confermava che il nodo stava usando un kernel Proxmox corretto.

2. Check ufficiale con pve8to9

Il passaggio più importante prima dell'upgrade è stato eseguire il tool ufficiale:

pve8to9 --full

pve8to9 è il checker ufficiale per il passaggio da PVE 8 a PVE 9. Controlla prerequisiti e configurazioni che possono rendere rischioso l'upgrade. Una failure è un blocco da risolvere; un warning richiede una decisione consapevole e non deve essere ignorato automaticamente. Dopo ogni correzione, esegui di nuovo il check completo.

Nel mio caso il risultato iniziale era:

FAILURES: 0
WARNINGS: 5

Non c'erano errori bloccanti, ma i warning non vanno ignorati. Sono esattamente il punto in cui si capisce se l'upgrade sarà una manutenzione ordinata oppure una sessione di debug al buio.

Fermati qui se: pve8to9 mostra failure, uno storage critico non è raggiungibile o non hai un backup recuperabile.

3. Warning rilevati e correzioni

Storage PBS non attivo

Il check segnalava uno storage Proxmox Backup Server non attivo:

WARN: storage 'my_pbs' enabled but not active!

Nel mio caso il problema era legato a un datastore montato via SMB:

/mnt/hetzner-smb/pbs-datastore/.chunks

Il percorso non risultava disponibile, quindi Proxmox Backup Client non riusciva ad aprire il chunk store.

Ho verificato il mount e la struttura del datastore:

findmnt /mnt/hetzner-smb
ls -la /mnt/hetzner-smb
ls -la /mnt/hetzner-smb/pbs-datastore

Nel mio scenario lo storage non serviva durante l'upgrade, quindi ho potuto disabilitarlo temporaneamente da:

Datacenter -> Storage -> my_pbs -> Disable

oppure da configurazione:

nano /etc/pve/storage.cfg

impostando:

disable 1

Questa non è una regola universale: se lo storage contiene backup, dischi o dati necessari ai guest, disabilitarlo può essere la scelta sbagliata. La regola generale è non iniziare un major upgrade con storage critici dichiarati attivi ma non raggiungibili.

Spazio libero su /

Il check segnalava:

NOTICE: Less than 10 GB free space on root file system.

Ho verificato lo spazio:

df -h /

Poi ho fatto una pulizia base:

apt clean
journalctl --vacuum-time=7d

Per capire cosa occupava spazio:

du -xhd1 / | sort -h

Il checker indicava nel mio caso una soglia operativa da correggere. Io preferisco mantenere un margine superiore al minimo richiesto: durante un major upgrade, lo spazio disco non deve diventare il collo di bottiglia. Fai riferimento all'output aggiornato di pve8to9 e alla guida ufficiale per la soglia applicabile al tuo nodo.

Se il nodo usa ZFS, oltre allo spazio su / controlla lo stato dei pool e valuta come l'architettura storage reagisce alla manutenzione dell'host. La guida su ZFS bare metal o in VM su Proxmox approfondisce questo confine operativo.

NTP: passaggio a Chrony

Nel mio ambiente il check consigliava di non usare systemd-timesyncd come servizio NTP principale sul server.

Ho installato chrony:

apt install chrony
systemctl enable --now chrony
systemctl disable --now systemd-timesyncd
timedatectl

Questa è stata la mia correzione, non un comando da copiare senza controllo. Prima verifica quale servizio sincronizza già l'orario e se esistono policy o configurazioni aziendali dedicate. Su un hypervisor, il tempo corretto non è un dettaglio: log, certificati, cluster, backup e monitoraggio dipendono tutti da timestamp affidabili.

Configurazione sysctl deprecata

Il check segnalava:

WARN: Deprecated config '/etc/sysctl.conf' contains settings - move them to a dedicated file in '/etc/sysctl.d/'.

Nel mio /etc/sysctl.conf erano attive solo queste due direttive:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Poiché erano impostazioni ancora necessarie alla mia rete, le ho spostate in un file dedicato:

cat > /etc/sysctl.d/99-proxmox-forwarding.conf <<'EOF'
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
EOF

Poi ho fatto backup del file originale:

cp /etc/sysctl.conf /etc/sysctl.conf.bak

E ho commentato le direttive attive nel vecchio file:

sed -i 's/^net\.ipv4\.ip_forward=1/#net.ipv4.ip_forward=1/' /etc/sysctl.conf
sed -i 's/^net\.ipv6\.conf\.all\.forwarding=1/#net.ipv6.conf.all.forwarding=1/' /etc/sysctl.conf

Infine ho applicato le configurazioni:

sysctl --system
sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

Non copiare questi due valori se il tuo host non esegue routing. Il punto generale è verificare ogni direttiva segnalata, conservarla solo se serve e spostarla nel percorso raccomandato senza modificarne involontariamente il comportamento.

Guest in esecuzione

Il warning finale rimasto era:

WARN: 35 running guest(s) detected - consider migrating or stopping them.

Essendo un nodo standalone, non avevo un altro nodo su cui migrare i guest. Ho quindi spento VM e container prima dell'upgrade.

Per vedere VM e CT:

qm list
pct list

Per spegnere tutte le VM accese:

for id in $(qm list | awk 'NR>1 && $3=="running" {print $1}'); do
  qm shutdown "$id"
done

Per spegnere tutti i container accesi:

for id in $(pct list | awk 'NR>1 && $2=="running" {print $1}'); do
  pct shutdown "$id"
done

Dopo lo spegnimento ho rilanciato:

pve8to9 --full

A quel punto il check risultava pulito, senza errori bloccanti.

Fermati qui se: dopo le correzioni rimangono failure o warning che non sai spiegare. Il numero di warning non è un obiettivo; conta comprenderne l'impatto sul tuo ambiente.

4. Backup dei repository e della configurazione storage

Prima di modificare i repository APT ho salvato una copia della configurazione:

mkdir -p /root/upgrade-pve8-to-pve9-backup

cp -a /etc/apt/sources.list /root/upgrade-pve8-to-pve9-backup/ 2>/dev/null
cp -a /etc/apt/sources.list.d /root/upgrade-pve8-to-pve9-backup/
cp -a /etc/pve/storage.cfg /root/upgrade-pve8-to-pve9-backup/

In un contesto aziendale farei anche un export documentato di rete, storage, firewall e lista VM/CT. Il backup vero delle VM resta obbligatorio, ma avere a portata di mano i file di configurazione accelera molto il ripristino in caso di problemi.

5. Cambio repository da Bookworm a Trixie

Proxmox VE 8 è basato su Debian 12 Bookworm. Proxmox VE 9 è basato su Debian 13 Trixie.

Prima di sostituire bookworm con trixie, elenca tutte le sorgenti APT e confrontale con la configurazione prevista dalla documentazione ufficiale. Una sostituzione globale non dimostra che ogni repository di terze parti sia compatibile con Debian 13.

Nel mio nodo, dopo aver verificato le sorgenti presenti, ho aggiornato i repository con:

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list 2>/dev/null
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.sources 2>/dev/null

Poi ho verificato:

grep -R "bookworm\|trixie" /etc/apt/sources.list /etc/apt/sources.list.d/

Ho revisionato manualmente ogni riga restituita. Nei repository destinati all'upgrade non devono rimanere riferimenti a bookworm, ma non basta cambiare il nome della suite: URI, componenti, chiavi e disponibilità del repository devono essere corretti per Trixie.

Se ci sono repository di terze parti, bisogna fermarsi e controllare che esista una versione compatibile con Debian 13. Questo vale per agent, monitoring, driver, repository custom, pacchetti storage e tooling installato manualmente.

Fermati qui se: non riconosci una sorgente APT, manca una variante compatibile con Trixie o non hai salvato la configurazione precedente.

6. Aggiornamento degli indici APT

Dopo il cambio repository:

apt update

Se apt update restituisce errori sui repository, non bisogna procedere con dist-upgrade.

Un major upgrade con repository incoerenti può lasciare il sistema in uno stato difficile da recuperare.

Fermati qui se: apt update mostra errori, firme non valide, repository non raggiungibili o una distribuzione diversa da quella prevista.

7. Upgrade vero e proprio

A questo punto ho lanciato:

apt dist-upgrade

Durante l'upgrade sono comparse alcune richieste sui file di configurazione.

Per /etc/issue, cioè il banner testuale mostrato prima del login, nel mio caso ho scelto la versione del maintainer:

Per /etc/lvm/lvm.conf, invece, nel mio ambiente ho mantenuto la versione locale:

Motivo: lvm.conf può contenere impostazioni rilevanti per LVM e LVM-thin. Inoltre il check pve8to9 aveva già confermato che la configurazione era corretta.

Le risposte Y e N descrivono il mio caso, non una combinazione universale. Non rispondere in automatico: confronta le versioni e valuta ogni file in base a cosa contiene e a quanto è critico per storage, rete o boot.

8. Verifica finale prima del reboot

Terminato il dist-upgrade, ho eseguito:

apt -f install
dpkg --configure -a
apt update
apt dist-upgrade

L'obiettivo era arrivare a una situazione senza pacchetti pendenti:

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Solo a quel punto ho considerato il nodo pronto per il reboot.

Fermati qui se: dpkg ha configurazioni pendenti, apt propone ancora operazioni inattese o non hai una console alternativa a SSH per gestire il reboot.

9. Reboot del nodo

Terminato l'upgrade:

reboot

Su server remoti consiglio sempre accesso console fuori banda, IPMI, iKVM o equivalente. Durante un major upgrade non bisogna dipendere solo da una sessione SSH.

10. Controlli dopo il reboot

Dopo il riavvio ho controllato versione, kernel, servizi e storage:

pveversion -v
uname -r
systemctl --failed
pvesm status
apt update
apt list --upgradable

I due controlli più importanti sono:

systemctl --failed

che dovrebbe non mostrare servizi falliti, e:

pvesm status

che deve confermare gli storage principali attivi.

Solo dopo questi controlli ha senso riaccendere i workload.

Il controllo non finisce all'host. Ho verificato anche rete e accesso amministrativo, poi ho riacceso i workload in ordine controllato e controllato che i servizi applicativi fossero raggiungibili. Uno stack di monitoraggio con Grafana aiuta a confrontare lo stato prima e dopo la manutenzione; per gli accessi remoti conviene verificare anche il percorso WireGuard su Proxmox. Se usi un reverse proxy in LXC, includi fra i test il servizio descritto nella guida a Nginx Proxy Manager su Proxmox.

Considero conclusa la verifica soltanto quando:

versione e kernel sono quelli attesi;
non risultano servizi falliti rilevanti;
gli storage principali sono attivi;
rete e accesso amministrativo funzionano;
VM e LXC si avviano in ordine controllato;
i servizi applicativi sono raggiungibili;
i job di backup sono nuovamente operativi.

11. Riaccensione graduale di VM e container

Dopo aver verificato che Proxmox era stabile, ho riacceso VM e CT in modo graduale.

Versione prudente, con pausa tra un guest e l'altro:

for id in $(qm list | awk 'NR>1 && $3!="running" {print $1}'); do
  echo "Starting VM $id"
  qm start "$id"
  sleep 5
done

for id in $(pct list | awk 'NR>1 && $2!="running" {print $1}'); do
  echo "Starting CT $id"
  pct start "$id"
  sleep 5
done

In ambienti più delicati conviene riaccendere prima i servizi fondamentali, poi database, poi applicazioni, poi servizi secondari. Non tutto insieme.

12. Pulizia finale

Solo dopo aver verificato VM, LXC, rete e storage ho eseguito la pulizia:

apt autoremove --purge
apt clean

Non consiglio di eliminare subito in modo aggressivo tutti i kernel precedenti. Meglio tenere almeno un kernel funzionante come fallback finché il sistema non è stato osservato per qualche giorno.

VM datate e machine version QEMU

Durante il ciclo di vita di Proxmox VE 9, le versioni QEMU previste rimuoveranno il supporto alle machine version anteriori alla 6.0. Prima del major upgrade, individua le VM ereditate da installazioni molto vecchie e valuta l'aggiornamento della machine version secondo la documentazione Proxmox.

Non cambiare questa impostazione senza backup e test del guest: una nuova machine version può modificare l'hardware virtuale esposto alla VM. Il controllo va pianificato, provato e documentato come una modifica distinta dall'upgrade dell'host.

Cosa cambia per cluster e Ceph

Il mio caso era un nodo standalone. In cluster la procedura va pianificata con più attenzione.

In particolare, per ambienti Proxmox VE 8.4 con Ceph iperconvergente, la documentazione Proxmox indica di aggiornare Ceph a Squid 19.2 prima di passare a Proxmox VE 9.

Questo è uno dei motivi per cui non considero l'upgrade Proxmox una semplice attività da "apt dist-upgrade e reboot". La parte difficile non è il comando. La parte difficile è conoscere le dipendenze: storage, cluster, rete, backup, repository, guest legacy e finestre di downtime.

Checklist riassuntiva

Preparazione

Aggiornare completamente Proxmox VE 8.4.
Verificare backup, possibilità di ripristino e accesso console.
Controllare VM datate e machine version QEMU.
Eseguire pve8to9 --full.

Correzione dei blocker

Risolvere failure e valutare ogni warning.
Verificare spazio disco, storage, NTP e configurazioni segnalate.
Spegnere o migrare ordinatamente i guest.
Salvare repository APT, storage.cfg e configurazioni essenziali.

Upgrade

Verificare e aggiornare i repository da Bookworm a Trixie.
Eseguire apt update e fermarsi in caso di errori.
Eseguire apt dist-upgrade valutando ogni conflitto di configurazione.
Completare la configurazione dei pacchetti e riavviare solo con sistema coerente.

Verifica e riapertura dei servizi

Controllare versione, kernel, servizi, storage e rete.
Riaccendere VM e container in ordine graduale.
Verificare applicazioni, monitoraggio e job di backup.
Eseguire la pulizia finale soltanto dopo un periodo di osservazione.

FAQ sull'upgrade PVE 8 to 9

Che cosa fa `pve8to9 --full`?

È il checker ufficiale che analizza prerequisiti e configurazioni rilevanti per il passaggio da Proxmox VE 8 a 9. Non esegue l'upgrade: evidenzia failure, warning e notice da valutare prima di cambiare repository. Va rilanciato dopo le correzioni per verificare lo stato aggiornato del nodo.

Posso aggiornare da una versione precedente a Proxmox VE 8.4?

Non userei questa procedura partendo direttamente da una release precedente. Prima porta il nodo lungo il percorso di aggiornamento supportato fino a una Proxmox VE 8.4 completamente aggiornata, seguendo la documentazione ufficiale applicabile alla tua versione di partenza. Solo dopo ha senso eseguire il checker pve8to9.

Quanto downtime devo prevedere?

Dipende da hardware, numero di pacchetti, storage, velocità del reboot e ordine di riaccensione dei workload. Su un nodo standalone devi prevedere l'arresto dei servizi ospitati; in cluster il downtime può essere ridotto migrando i guest, ma la procedura diventa più articolata. Misura i tempi in un ambiente comparabile e aggiungi margine per la verifica finale.

Posso eseguire l'upgrade soltanto via SSH?

Tecnicamente molti passaggi si eseguono da shell, ma su un server remoto critico non dipenderei soltanto da SSH. Se rete, boot o firewall non tornano correttamente dopo il reboot, servono IPMI, iKVM, console del provider o un accesso equivalente fuori banda.

Che cosa devo fare se `pve8to9` mostra warning o failure?

Una failure è un blocco: risolvila prima di procedere. Un warning non impone sempre la stessa correzione, ma deve essere compreso e documentato nel contesto del tuo nodo. Dopo ogni intervento rilancia pve8to9 --full e verifica che il risultato sia coerente con il rischio che hai deciso di accettare.

Posso tornare a Proxmox VE 8 dopo l'upgrade?

Non pianificare il ritorno come un semplice downgrade in-place dei pacchetti. Il piano di recupero prudente prevede backup verificati, copia delle configurazioni e la possibilità di reinstallare o ripristinare host e guest. Prima del cambio repository definisci concretamente come ricostruiresti il servizio se l'upgrade non fosse recuperabile.

La stessa procedura vale per cluster e Ceph?

No. Questa guida documenta un nodo standalone senza Ceph iperconvergente. Cluster e Ceph richiedono controlli sullo stato, sul quorum, sull'ordine dei nodi, sulla migrazione dei guest e sulla sequenza di aggiornamento Ceph indicata dalla documentazione ufficiale.

Devo spegnere tutte le VM e i container?

Nel mio nodo standalone li ho spenti prima dell'upgrade per ridurre variabili e proteggere i workload durante il reboot. In un cluster sano può essere possibile migrare i guest, ma la scelta dipende da capacità, quorum e compatibilità. In ogni caso definisci prima quali servizi fermare, migrare e riaccendere.

Le VM più vecchie continueranno a funzionare?

Non va dato per scontato. Durante il ciclo di Proxmox VE 9, le versioni QEMU previste rimuoveranno il supporto alle machine version anteriori alla 6.0. Individua le VM molto datate, verifica la loro configurazione e prova separatamente ogni aggiornamento della machine version con backup disponibile.

Quali controlli devo fare dopo il reboot?

Controlla versione e kernel, servizi falliti, stato degli storage, rete e accesso amministrativo. Riaccendi VM e LXC gradualmente, verifica le applicazioni e conferma che monitoraggio e job di backup siano tornati operativi. Il reboot riuscito, da solo, non dimostra che l'upgrade sia concluso.

Conclusione

L'upgrade ha avuto successo non perché i comandi fossero complessi, ma perché ogni passaggio aveva una condizione di ingresso e un controllo d'uscita. pve8to9 --full, backup recuperabili, repository coerenti e riaccensione graduale hanno trasformato il major upgrade in una manutenzione controllata.

Il punto più importante è sapere quando fermarsi. Una failure, uno storage irraggiungibile o un repository incoerente non sono dettagli da risolvere durante l'upgrade: sono condizioni da correggere prima.

Se devi aggiornare un nodo Proxmox, verificare un cluster o pianificare backup e recovery, posso aiutarti a preparare l'intervento e i controlli successivi.

Contattami qui