Guida all’aggiornamento di Proxmox VE 8 a Proxmox VE 9 su Debian 12

Aggiornare un ambiente Proxmox VE da una versione 8.x alla nuova major release 9.x è un processo delicato che richiede attenzione e una corretta preparazione. Questo articolo guida passo passo, con esempi pratici, come eseguire l’upgrade in sicurezza, minimizzando rischi di downtime o problemi di compatibilità.

Introduzione

Proxmox VE 9 porta diverse novità e miglioramenti rispetto alla versione 8.x, inclusi aggiornamenti ai componenti di sistema, nuovi kernel, miglior supporto hardware e ottimizzazioni delle funzionalità di virtualizzazione. Tuttavia, l’aggiornamento da una release 8 (es. 8.3 o 8.4) alla 9 non è un semplice comando “apt upgrade”: richiede alcune attenzioni preliminari e la risoluzione di avvisi specifici, soprattutto legati a Debian 12 (bookworm) che ora diventa “trixie”.

1. Preparazione: backup e controllo versione

Prima di iniziare è fondamentale effettuare un backup completo delle macchine virtuali (VM) e container (CT), e dei file di configurazione chiave, come:

• /etc/network/interfaces
• /etc/pve (configurazione cluster Proxmox)

Inoltre, se il tuo nodo Proxmox è ancora su una versione minore della 8.x (ad esempio la 8.3), ti consiglio di aggiornarla prima tramite il pannello web di Proxmox:

clicca il nodo che vuoi aggiornare, vai nella colonna accanto su – [Updates] – poi in alto sull’area ancora a destra fai – [Refresh] – da qui avrai tutta lista di pacchetti aggiornabili disponibili con la loro versione, infine fai – [Upgrade] – si aprirà una console attendi la fine dell’upgrade.

Oppure via shell:

apt update && apt upgrade

Assicurati di portare la versione almeno alla 8.4.10, l’ultima minore prima del passaggio alla 9.

Backup VM/CT e configurazioni critiche prima dell’upgrade

Prima di procedere con qualsiasi upgrade di Proxmox, è fondamentale avere copie di sicurezza.
Backup delle VM e CT. Puoi usare il pannello grafico o, da shell, il comando:

vzdump --storage --mode stop

Esempio per una VM con ID 101 salvata nello storage local:

vzdump 101 --storage local --mode stop

Backup delle configurazioni di rete e cluster

mkdir -p /root/upgrade-backup
cp /etc/network/interfaces /root/upgrade-backup/
cp -r /etc/pve /root/upgrade-backup

2. Verifica e gestione degli avvisi con pve8to9

Proxmox fornisce uno strumento chiamato pve8to9 per verificare la compatibilità e i problemi che potrebbero emergere durante l’upgrade.

Prima del passaggio a PVE9 per un controllo approfondito, esegui:

pve8to9 --full

Un avviso comune riguarda il file /etc/sysctl.conf che su Debian 12 (bookworm) risulta deprecato. La best practice è rinominarlo e migrare le configurazioni in un nuovo file personalizzato sotto /etc/sysctl.d/99-custom.conf.

Gestione di sysctl.conf prima dell’upgrade a Proxmox 9

Prima del passaggio da Proxmox 8.x (Debian 12 bookworm) a Proxmox 9.x (Debian 13 trixie), il tool pve8to9 –full potrebbe segnalare un WARN legato all’uso di /etc/sysctl.conf.
Infatti, nelle release più recenti di Debian, il file sysctl.conf è considerato deprecato in favore di configurazioni modulari dentro /etc/sysctl.d/.

In molte installazioni, troverai che:

ls -l /etc/sysctl.d/99-sysctl.conf

mostra un symlink verso /etc/sysctl.conf: “/etc/sysctl.d/99-sysctl.conf -> /etc/sysctl.conf“

Perché nasce il warning

Quando rinomini o elimini /etc/sysctl.conf, il symlink /etc/sysctl.d/99-sysctl.conf resta puntato a un file inesistente, causando un avviso nel pre-check di upgrade.

Come risolvere

1. Fare backup del file originale

Prima di modificare qualsiasi configurazione:

cp /etc/sysctl.conf /etc/sysctl.conf.backup

2. Creare un nuovo file di configurazione

Copiare solo le righe non commentate e non vuote in un nuovo file:

grep -v '^\s#' /etc/sysctl.conf | grep -v '^\s$' > /etc/sysctl.d/99-custom.conf

3. Rinominare il vecchio file

mv /etc/sysctl.conf /etc/sysctl.conf.bak

4. Sistemare il symlink (opzionale, ma consigliato)

Puoi rimuoverlo o farlo puntare al nuovo file:

Per rimuoverlo:

rm /etc/sysctl.d/99-sysctl.conf

Per aggiornarlo:

ln -sf /etc/sysctl.d/99-custom.conf /etc/sysctl.d/99-sysctl.conf

O anche lasciarlo com’è, tanto nella nuova versione Debian 13 il sistema leggera direttamente le configurazioni dentro il file che abbiamo creato (/etc/sysctl.d/99-custom.conf).

5. Ricaricare le impostazioni

Dopo la modifica, ricaricare tutte le configurazioni sysctl senza riavviare:

sysctl --system

Questo comando: legge /etc/sysctl.conf (se esiste), legge tutti i file .conf in /etc/sysctl.d/ ed applica immediatamente le impostazioni al kernel.

3. Aggiornare i repository e passare a Proxmox 9

Dopo aver risolto eventuali warning e verificato la compatibilità, puoi procedere con la sostituzione dei repository per passare da Debian bookworm a trixie e aggiornare Proxmox:

# Backup delle sorgenti attuali
mkdir -p /root/repo-backup
cp /etc/apt/sources.list /etc/apt/sources.list.d/*.list /root/repo-backup/

# Modifica delle fonti da 'bookworm' a 'trixie'
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-install-repo.list

#Solo se hai licenza enterprise (in caso contrario salta questo comando)
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

# Verifica che i file siano aggiornati correttamente
cat /etc/apt/sources.list
cat /etc/apt/sources.list.d/pve-install-repo.list

# Aggiorna pacchetti e sistema
apt update
apt dist-upgrade

# Riavviare quando richiesto
reboot

Se si preferisce agire manualmente sui repository si puo modificare autonomamente il file /etc/apt/sources.list aggiungedo i seguenti repository:

deb http://deb.debian.org/debian trixie main contrib
deb http://deb.debian.org/debian trixie-updates main contrib
deb http://security.debian.org/debian-security trixie-security main contrib

Modificare anche:

nano /etc/apt/sources.list.d/pve-install-repo.list

E impostare:

deb http://download.proxmox.com/debian/pve trixie pve-no-subscription

(oppure in /etc/apt/sources.list.d/pve-enterprise.list impostare deb https://enterprise.proxmox.com/debian/pve trixie pve-enterprise – se si ha una licenza enterprise).

In questo modo si aggiornano le voci relative a Debian Bookworm con quelle di Proxmox VE 9 (basato su Trixie)

Durante la fase di aggiornamento (dist-upgrade), presta attenzione alle richieste in prompt, in particolare quelle relative a file di configurazione modificati.

4. Verifiche finali post-upgrade

Una volta riavviato il nodo, verifica:

• Versioni Proxmox, Debian e Kernel con:

pveversion
pveversion -v
cat /etc/debian_version
lsb_release -a
uname -a

• Che tutti i servizi Proxmox siano attivi e senza errori:

systemctl status pve-cluster pvedaemon pveproxy

• Che le VM e i container siano avviabili.

Nota Importante – Priorità IPv6 dopo l’upgrade a PVE 9

Dopo l’aggiornamento da Proxmox VE 8 (Debian 12) a Proxmox VE 9 (Debian 13), alcuni utenti hanno riscontrato il mancato avvio di container (CT) o VM.
L’analisi ha evidenziato che in Debian 13:

Il file /etc/gai.conf viene ripristinato ai valori di default, con la priorità IPv6 superiore a IPv4 (tutte le righe sono commentate).

La configurazione di rete può subire modifiche, riportando l’indirizzo IPv6 /64 sull’interfaccia errata o non più routed sulla bridge principale (es. vmbr1 invece di vmbr0) o su nessun bridge e nessuna interfaccia di rete fisica e virtuale.

Se l’IPv6 configurato non è raggiungibile o non ha il routing corretto, i servizi all’interno dei container possono andare in timeout durante la fase di avvio, impedendone il boot.

Soluzione:

Verificare che la classe v6 o l’IPv6 globale sia assegnato correttamente alla bridge di rete primaria (vmbr0 o vmbr1) e che il gateway IPv6 sia raggiungibile.

ip -6 addr show vmbr0

ip -6 addr show vmbr1

ping6 <gateway-ipv6>

Verifica l’intera configurazione delle interfacce di rete:

ip addr

oppure

ifconfig

Controlla anche la configurazione di rete dentro il file interfaces: /etc/network/interfaces

Se si preferisce dare priorità a IPv4, decommentare in /etc/gai.conf la riga:

precedence ::ffff:0:0/96 100

e salvare il file.

Ricaricare la configurazione:

sysctl --system

Riavviare il container o la VM:

pct start <CTID>

Suggerimento: subito dopo l’upgrade, testare l’avvio di almeno una VM e un CT per verificare la piena funzionalità della rete e della risoluzione DNS.

Riepilogo

1. Preparazione prima dell’aggiornamento

Prima di eseguire l’upgrade, è fondamentale:

• Fare un backup completo di tutte le VM/CT.
• Annotare eventuali configurazioni personalizzate in /etc/network/interfaces, /etc/gai.conf, /etc/pve, e altre aree di rete.
• Aggiornare il sistema all’ultima release minore 8.x.
• Verificare tramite il tool pve8to9 la compatibilità e i problemi che potrebbero emergere durante l’upgrade.
• Riavviare per assicurarsi che tutto funzioni correttamente prima di procedere.

2. Modifica dei repository e Aggiornamento a Proxmox VE 9

Modificare i file dei repository di Proxmox per passare dalla versione 8 alla 9 e aggiornare la distribuzione.

3. Test post-aggiornamento

Nota importante (per esperienza diretta):
Dopo l’aggiornamento, è fondamentale testare immediatamente l’avvio di tutte le VM e CT listale con: qm list e/o pct list e provane l’avvio con: qm start <VMID> e/o pct start <CTID>.

Nel mio caso, la mancata verifica subito dopo l’aggiornamento ha nascosto un problema che avrebbe potuto essere scoperto prima.

5. Problema post-aggiornamento: ping su IPv6 e CT che non si avviano

Dopo l’aggiornamento a PVE 9, ho notato due comportamenti anomali:

1. Un semplice ping www.google.it tentava la connessione via IPv6, che però non rispondeva, causando tempi di attesa.
2. Alcuni container LXC fallivano l’avvio con pct start <CTID>.

Diagnosi IPv6

Test iniziali:

ping www.google.it # tentava IPv6 → 100% packet loss
ping6 <IPv6_Google> # 100% packet loss
ping <IPv4_Google> # OK

Il comportamento era dovuto al fatto che /etc/gai.conf non era configurato per dare priorità all’IPv4 (vedi precedence ::ffff:0:0/96 100) e che la classe ipv6 non era routed su nessuna delle interfacce di rete. Sorprendentemente, dopo aver risolto il problema di rete, i container LXC hanno ripreso ad avviarsi correttamente. Molto probabilmente il problema di avvio era legato a tentativi falliti di collegamento IPv6 durante l’inizializzazione del container.

Conclusioni

L’aggiornamento da Proxmox 8.x a 9.x richiede una corretta preparazione, un’attenta gestione dei backup e una verifica puntuale delle modifiche ai file di configurazione. Seguendo questa guida puoi affrontare la procedura in modo sicuro e affidabile, mantenendo la tua infrastruttura sempre aggiornata.

Considerazioni finali

• È importante testare subito l’avvio delle VM/CT dopo un aggiornamento.
• In Debian 12 con PVE 8, la riga in gai.conf era già decommentata, mentre in Debian 13 con PVE 9 potrebbe essere commentata di default.
• Se si nota che ping dominio punta a IPv6 e questo non risponde, la priorità IPv4 deve essere ripristinata.
• Alcuni problemi apparentemente “misteriosi” (come l’avvio fallito di CT) possono derivare da questioni di rete e non direttamente da errori di Proxmox.

UPDATE

Aggiungo un paio di controlli extra da effettuare a causa di un bug emerso ad agosto 2025:

– Per cambiare tutte le liste APT in un colpo solo, conviene usare:

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
find /etc/apt/sources.list.d -type f -exec sed -i 's/bookworm/trixie/g' {} \;

– Prima di eseguire apt dist-upgrade o qualsiasi upgrade, mettere in hold il pacchetto mdadm:

apt-mark hold mdadm

– Quindi procedere all’upgrade distro e smarcare successivamente mdadm:

apt-mark hold mdadm

e rilanciare l’upgrade con

apt update && apt full-upgrade

– Dato il passaggio a Debian 13, conviene già passare anche al nuovo formato deb822 con:

apt modernize-sources

Inoltre consiglio di prestare particolare attenzione ai log, in quanto ho notato, utilizzando ipsec, che su Debian 13 viene installata una nuova versione di apparmor che lo blocca, con questo log: Strongswan apparmor=”DENIED” operation=”open”
Il fix è installare apparmor-utils e sbloccare IPSec, impartendo questi comandi:

apt install -y apparmor-utils
aa-complain /usr/lib/ipsec/charon
aa-complain /usr/lib/ipsec/stroke