Upgrade Proxmox VE da 8 a 9: procedura reale, warning e controlli post-migrazione

Proxmox VE 8 sta entrando nella fase finale del suo ciclo di vita: la documentazione ufficiale indica una EOL stimata a luglio 2026. Per chi usa Proxmox in produzione, in laboratorio o come base per servizi self-hosted, questo significa una cosa semplice: l'upgrade a Proxmox VE 9 va pianificato prima che diventi urgente.

In questo articolo racconto il percorso che ho seguito per aggiornare un nodo Proxmox VE 8.4 a Proxmox VE 9.

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 e basato su Debian 13 Trixie e porta con se componenti aggiornati come kernel piu recente, QEMU 10, LXC 6, ZFS 2.3 e Ceph Squid. L'upgrade in-place supportato parte da Proxmox VE 8.4 aggiornato.

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

Perche fare l'upgrade prima della scadenza

Aspettare l'ultimo mese prima della EOL e quasi sempre una cattiva idea.

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

Fare l'upgrade con anticipo permette di:

verificare compatibilita 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 e solo "passare alla versione nuova". Il punto e arrivarci con un sistema leggibile, aggiornato e recuperabile.

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 gia aggiornato e apt ha rimosso solo alcuni vecchi kernel Debian non piu 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 piu importante prima dell'upgrade e stato eseguire il tool ufficiale:

pve8to9 --full

Il risultato iniziale era positivo:

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 sara una manutenzione ordinata oppure una sessione di debug al buio.

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

Se lo storage non serve durante l'upgrade, conviene disabilitarlo temporaneamente da:

Datacenter -> Storage -> my_pbs -> Disable

oppure da configurazione:

nano /etc/pve/storage.cfg

impostando:

disable 1

La cosa importante e non iniziare un major upgrade con storage 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

La documentazione Proxmox indica almeno 5 GB liberi sul mount point root, idealmente piu di 10 GB. Io preferisco stare largo: durante un major upgrade, lo spazio disco non deve essere il collo di bottiglia.

NTP: passaggio a Chrony

Il check consigliava di non usare systemd-timesyncd come servizio NTP principale su server.

Ho installato chrony:

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

Su un hypervisor, il tempo corretto non e 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

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

Questo e un esempio classico di manutenzione che sembra minore, ma che evita ambiguita dopo l'upgrade.

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.

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 e basato su Debian 12 Bookworm. Proxmox VE 9 e basato su Debian 13 Trixie.

Ho aggiornato i repository:

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/

Non devono rimanere riferimenti a bookworm.

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.

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 puo lasciare il sistema in uno stato difficile da recuperare.

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, cioe il banner testuale mostrato prima del login, ho scelto la versione del maintainer:

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

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

Qui la regola e semplice: non rispondere in automatico. Ogni file di configurazione va valutato in base a cosa contiene e a quanto e 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.

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 piu 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.

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 piu 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 finche il sistema non e stato osservato per qualche giorno.

Cosa cambia per cluster e Ceph

Il mio caso era un nodo standalone. In cluster la procedura va pianificata con piu 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 e uno dei motivi per cui non considero l'upgrade Proxmox una semplice attivita da "apt dist-upgrade e reboot". La parte difficile non e il comando. La parte difficile e conoscere le dipendenze: storage, cluster, rete, backup, repository, guest legacy e finestre di downtime.

Checklist riassuntiva

La sequenza che ho seguito e stata:

1. aggiornamento completo di Proxmox VE 8.4
2. esecuzione di pve8to9 --full
3. correzione dei warning
4. verifica backup e storage
5. spegnimento ordinato dei guest
6. backup dei repository APT e di storage.cfg
7. cambio repository da bookworm a trixie
8. apt update
9. apt dist-upgrade
10. verifica pacchetti pendenti
11. reboot
12. controllo versione, kernel, servizi e storage
13. riaccensione graduale di VM e container
14. pulizia finale solo dopo verifica

Conclusione

L'upgrade da Proxmox VE 8 a Proxmox VE 9 e andato a buon fine perche e stato gestito in modo conservativo.

Il punto piu importante e non ignorare pve8to9 --full: nel mio caso non c'erano failure, ma i warning hanno permesso di sistemare prima storage PBS, spazio disco, NTP, configurazioni sysctl e guest attivi.

Questo e il tipo di attivita in cui l'esperienza operativa conta: non basta conoscere i comandi, bisogna capire cosa puo rompersi, quali controlli fare prima del reboot e quando fermarsi.

Se devi aggiornare un nodo Proxmox, verificare un cluster, migrare workload o mettere ordine in backup e storage prima della EOL di Proxmox VE 8, posso aiutarti a pianificare e seguire l'intervento.

Contattami qui