Proxmox VE 7 EOL: piano di upgrade a PVE 8 e 9

Un nodo Proxmox VE 7 ancora in produzione non è semplicemente “un po’ vecchio”: è fuori supporto dal 31 luglio 2024. Anche Proxmox VE 8.4 è ormai vicino alla fine del proprio ciclo e riceverà aggiornamenti di sicurezza e correzioni critiche soltanto fino ad agosto 2026.

L'hypervisor continua a funzionare dopo queste date, ma cambia la responsabilità operativa: non si può più presumere che una nuova vulnerabilità nel kernel, in KVM, QEMU o nei componenti Proxmox venga corretta sul ramo EOL.

Per chi è ancora su PVE 7 la priorità non è saltare subito alla release più recente. Il percorso supportato è sequenziale:

PVE 7 aggiornato all'ultimo minor → PVE 8 → stabilizzazione → PVE 9

In breve: inventaria il nodo, verifica davvero i backup e i restore, porta PVE 7 all'ultima 7.4 disponibile, esegui pve7to8 --full, passa a PVE 8 e stabilizza l'ambiente. Soltanto dopo pianifica il secondo upgrade a PVE 9 con pve8to9 --full.

Date di supporto da conoscere

La tabella ufficiale Proxmox collega ogni major release alla relativa base Debian e indica separatamente la fine del supporto Debian e quella di Proxmox VE.

Versione	Base Debian	Stato al 29 luglio 2026	Azione
Proxmox VE 7	Debian 11 Bullseye	EOL dal 31 luglio 2024	Migrazione urgente
Proxmox VE 8.4	Debian 12 Bookworm	Aggiornamenti di sicurezza e correzioni critiche fino ad agosto 2026	Completare il passaggio a PVE 9
Proxmox VE 9	Debian 13 Trixie	Ramo supportato	Destinazione finale

La scadenza di PVE 8.4 non significa che sia corretto migrare un vecchio nodo 7 direttamente a 9. Le guide ufficiali documentano due salti distinti, 7→8 e 8→9. Saltare una major rende molto più difficile distinguere un problema di pacchetti da una regressione di rete, storage o configurazione.

Perché l'EOL di un hypervisor pesa più di quello di un server applicativo

Proxmox VE si trova sotto macchine virtuali, container, storage, bridge, firewall, backup e accesso amministrativo. Un errore o una vulnerabilità a questo livello può quindi coinvolgere più servizi contemporaneamente.

Con un ramo fuori supporto aumentano almeno quattro rischi:

assenza di patch per nuove vulnerabilità del kernel e di KVM;
incompatibilità crescente con backup, guest e strumenti di gestione più recenti;
upgrade futuri più complessi perché partono da pacchetti e configurazioni molto indietro;
recovery non verificato proprio nel momento in cui il change diventa più rischioso.

Una subscription Proxmox offre repository enterprise e supporto, ma non estende indefinitamente la vita di una major EOL. Allo stesso modo, usare il repository pve-no-subscription non trasforma una release fuori supporto in una piattaforma mantenuta.

Januscape mostra perché il problema non è teorico

Januscape, tracciata come CVE-2026-53359, è una vulnerabilità guest-to-host nel codice shadow MMU di KVM/x86. Un guest controllato dall'attaccante, quando dispone della virtualizzazione annidata, può raggiungere un use-after-free nel kernel dell'host.

Il PoC pubblico dimostra un denial of service capace di provocare il panic dell'host; il ricercatore afferma inoltre di avere realizzato in ambiente controllato un escape completo con esecuzione come root, non pubblicato. Il problema interessa il percorso KVM condiviso da Intel e AMD e non dipende da una vulnerabilità di QEMU.

Proxmox ha distribuito kernel corretti sui rami supportati. Nel confronto pubblico, un membro dello staff Proxmox ha però ricordato che PVE 7 è fuori supporto e non va usato per workload non affidabili, indipendentemente dalla mitigazione della singola CVE.

Se non è possibile applicare immediatamente un kernel corretto, disabilitare il nested KVM riduce il percorso di attacco di Januscape. Prima bisogna però verificare se viene realmente usato da Hyper-V, WSL, Docker in VM, laboratori KVM annidati o altri workload.

Un primo controllo sull'host:

cat /sys/module/kvm_intel/parameters/nested 2>/dev/null
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
grep -R --line-number -E '^cpu:.*(host|vmx|svm|nested-virt)' \
  /etc/pve/qemu-server/ 2>/dev/null

Questi comandi producono indicatori da interpretare: il solo modello CPU non è una prova completa dell'esposizione. La mitigazione richiede una finestra di manutenzione e non sostituisce l'aggiornamento del kernel e della piattaforma.

Prima dell'upgrade: raccogliere un inventario ripetibile

Prima di modificare repository o pacchetti, salva l'output dei controlli in una cartella esterna al nodo. L'inventario minimo comprende versione, storage, cluster, filesystem e capacità:

pveversion -v
pvesm status
pvecm status
zpool status
df -h

Su un nodo standalone pvecm status può non restituire uno stato cluster utile; su un sistema senza ZFS zpool può non essere presente. Non sono errori da correggere automaticamente: servono a descrivere l'ambiente.

Completerei l'inventario con:

uname -a
lsblk -f
lvs
ip -br address
ip route
bridge vlan show
cat /etc/network/interfaces
qm list
pct list
ha-manager status

Se è presente Ceph:

ceph -s
ceph versions

Conserva anche:

configurazione dei bridge, VLAN, bond e MTU;
mapping delle NIC e relativi indirizzi MAC;
storage ID, mount point e contenuti ammessi;
VM e container con ordine e policy di avvio;
passthrough PCI, USB, GPU o dischi fisici;
configurazioni firewall a livello datacenter, nodo e guest;
certificati, utenti, realm e autenticazione a più fattori;
job di backup, retention, prune, verify e replica;
eventuali hook script, moduli DKMS e pacchetti esterni.

Controllare repository e pacchetti estranei

Molti upgrade falliscono non per Proxmox, ma per repository Debian duplicati, suite miste, pinning dei pacchetti o componenti di terze parti dimenticati.

Per visualizzare tutte le sorgenti:

grep -R --line-number . \
  /etc/apt/sources.list \
  /etc/apt/sources.list.d/

Per mostrare soltanto le righe abilitate:

grep -R --line-number --no-messages \
  -E '^[[:space:]]*[^#[:space:]]' \
  /etc/apt/sources.list \
  /etc/apt/sources.list.d/

Controlla inoltre pacchetti bloccati e moduli esterni:

apt-mark showhold
dkms status
dpkg -l

Non eliminare alla cieca un pacchetto solo perché non sembra standard. Driver per NIC, HBA, UPS, agenti di monitoraggio o strumenti del provider possono essere necessari al boot o alla connettività. Devono essere classificati e, se incompatibili, sostituiti in un change separato.

Backup: non basta vedere un job verde

Il prerequisito reale non è “avere un backup”, ma sapere che il backup è leggibile e ripristinabile.

Prima dell'upgrade:

verifica che tutte le VM e i container critici abbiano un backup recente;
controlla log, dimensioni, retention e spazio libero del datastore;
esegui la verifica di integrità prevista da Proxmox Backup Server;
ripristina almeno un guest su un ID libero e su una rete isolata;
avvialo, verifica filesystem e servizio applicativo;
documenta tempo e passaggi del recovery;
conserva fuori dal nodo le configurazioni necessarie a ricostruire rete e storage.

Un restore reale individua problemi che il solo job di backup non mostra: chiavi mancanti, namespace errato, datastore non raggiungibile, dipendenze da dischi esclusi, credenziali scadute o tempi di ripristino incompatibili con la finestra disponibile.

Anche Proxmox Backup Server va inventariato e verificato. Il suo eventuale upgrade deve avere una finestra distinta: aggiornare contemporaneamente hypervisor e sistema di backup riduce le opzioni di recovery proprio durante il change più delicato.

Scegliere tra upgrade in-place e reinstallazione con restore

Entrambe le strategie possono essere valide.

Strategia	Vantaggio	Rischio principale	Quando valutarla
Upgrade in-place 7→8	Mantiene storage e configurazione esistenti	Trasporta configurazioni obsolete e pacchetti estranei	Nodo ordinato, hardware supportato e checker pulito
Nuova installazione PVE 8/9 + restore	Parte da una baseline pulita e prova il recovery	Richiede più capacità, downtime e ricostruzione documentata	Forte configuration drift, storage riorganizzabile o hardware da sostituire
Migrazione su altro nodo/cluster	Riduce il fermo dei workload	Compatibilità CPU, storage e rete da verificare	Disponibilità di capacità temporanea e piano di migrazione testato

Su un nodo installato da molti anni, con repository modificati e backup mai ripristinati, la reinstallazione può essere più prevedibile dell'in-place. Su un host con storage locale molto grande e nessuna capacità temporanea, l'in-place può essere più realistico. La scelta va presa dopo inventario e test, non per abitudine.

Fase 1: portare PVE 7 all'ultima baseline disponibile

Il checker e il percorso ufficiale richiedono un sistema PVE 7 aggiornato, non una vecchia installazione 7.0 rimasta ferma per anni.

La preparazione comprende:

correggere repository Debian Bullseye e Proxmox senza ancora convertirli a Bookworm;
rimuovere o rendere compatibili i componenti estranei già classificati;
aggiornare tutti i pacchetti PVE 7 all'ultima versione 7.4 disponibile;
riavviare sul kernel previsto;
controllare nuovamente storage, cluster, rete e workload;
eseguire il checker completo.

Comandi di riferimento:

apt update
apt full-upgrade
reboot

Dopo il riavvio:

pveversion -v
uname -r
pve7to8 --full

Ogni FAIL deve essere risolto. Anche i warning vanno letti nel contesto: ignorarli in blocco elimina il principale vantaggio del checker.

Fase 2: eseguire l'upgrade da PVE 7 a PVE 8

La guida ufficiale descrive la conversione della base Debian da Bullseye a Bookworm e dei repository Proxmox al ramo PVE 8. Non conviene trasformarla in un comando unico da copiare e incollare: tra un passaggio e l'altro vanno letti output, conflitti e richieste sui file di configurazione.

Durante la finestra:

ferma o migra i workload secondo il piano;
mantieni accesso alla console out-of-band del provider o del server;
registra l'output di apt;
confronta i file di configurazione proposti dal maintainer;
non riavviare finché l'upgrade dei pacchetti non è terminato correttamente;
dopo il reboot verifica che il kernel e pve-manager appartengano allo stesso ramo supportato.

Controlli post-upgrade:

pveversion -v
uname -r
pvesm status
pvecm status
zpool status
systemctl --failed
journalctl -p err -b

Poi verifica GUI/API, DNS, route, bridge, VLAN, MTU, backup, replica, HA e avvio dei guest. Non considerare riuscito il change soltanto perché la pagina web di Proxmox è raggiungibile.

Stabilizzare PVE 8 prima di passare a PVE 9

Per chi parte da PVE 7, PVE 8 non deve essere una sosta di pochi minuti. Serve come punto di controllo:

porta il nodo almeno alla baseline PVE 8.4 richiesta dalla guida successiva;
completa tutti gli aggiornamenti e riavvia;
verifica per alcuni cicli workload, backup e monitoraggio;
ripeti un restore;
elimina errori e warning introdotti dal primo salto;
acquisisci un nuovo inventario da confrontare con quello iniziale.

Questa pausa rende attribuibile un problema al salto 7→8 oppure 8→9. Fare i due upgrade nella stessa finestra produce un unico incidente molto più difficile da diagnosticare.

Fase 3: pianificare l'upgrade da PVE 8 a PVE 9

PVE 9 usa Debian 13 Trixie. Prima del secondo salto aggiorna PVE 8.4 alla versione richiesta dalla guida ed esegui:

pve8to9 --full

Anche in questo caso, risolvi errori e warning prima di cambiare repository.

Se il cluster usa Ceph Reef, la documentazione Proxmox richiede il passaggio a Ceph Squid prima di PVE 9. È un prerequisito, ma deve essere trattato come change autonomo:

stabilizzazione PVE 8 → upgrade Ceph → verifica cluster → upgrade PVE 9

Lo stesso principio vale per:

upgrade di ZFS non indispensabili al salto;
sostituzione di NIC o HBA;
modifica di bridge, bond, VLAN o MTU;
migrazione dello storage;
nuova architettura firewall;
upgrade di PBS.

Cosa non combinare nello stesso change

Durante un major upgrade evita di modificare contemporaneamente:

versione Proxmox;
bridge, bond o VLAN;
destinazione e tecnologia dello storage;
versione di Ceph o interventi strutturali su ZFS;
NIC, HBA o controller;
policy firewall;
topologia del cluster;
piattaforma di backup.

La regola non è burocrazia. Se dopo il riavvio lo storage non monta o il nodo non è raggiungibile, una sola variabile cambiata riduce drasticamente i tempi e il rischio della diagnosi.

Piano operativo consigliato

Prima della manutenzione

Inventario di versioni, rete, storage, cluster, guest e pacchetti.
Repository classificati e componenti di terze parti verificati.
Capacità e stato di ZFS, LVM o Ceph controllati.
Backup recenti e job PBS senza errori.
Restore reale completato su rete isolata.
Console out-of-band verificata.
Finestra, rollback e criteri di stop documentati.
PVE 7 portato all'ultima 7.4 disponibile.
pve7to8 --full senza errori irrisolti.

Dopo PVE 8

Versione di pve-manager e kernel coerenti.
Storage e pool integri.
Quorum e servizi cluster regolari.
Bridge, VLAN, routing e firewall verificati.
VM e container avviati e raggiungibili.
Backup, restore, replica e monitoraggio testati.
Nessun errore nuovo in systemctl --failed e nel journal.
Periodo di stabilizzazione completato.

Prima di PVE 9

PVE 8.4 aggiornato alla baseline richiesta.
pve8to9 --full eseguito e analizzato.
Compatibilità di hardware, moduli e pacchetti esterni verificata.
Eventuale upgrade Ceph completato e stabilizzato separatamente.
Nuovo backup e nuovo restore verificati.
Seconda finestra di manutenzione approvata.

Supporto per audit e migrazione Proxmox

Un upgrade dell'hypervisor non è soltanto un apt full-upgrade. La parte più importante è capire lo stato reale di storage, rete, backup e dipendenze prima del riavvio e avere un percorso di recovery già provato.

Posso supportare aziende e professionisti con:

inventario e audit di nodi e cluster Proxmox;
verifica dei repository, pacchetti esterni e compatibilità;
controllo di Proxmox Backup Server e test di restore;
piano di upgrade PVE 7→8→9 con finestre separate;
assessment di storage ZFS, LVM e Ceph;
verifica di bridge, VLAN, firewall e accesso out-of-band;
controlli post-upgrade, analisi dei log e troubleshooting;
hardening e verifica dell'esposizione a vulnerabilità KVM come Januscape.

Se hai un nodo Proxmox 7 ancora in produzione o devi completare il passaggio da PVE 8.4 a PVE 9, puoi contattarmi per una valutazione tecnica.