Proxmox VE 8 è fuori supporto: cosa rischi e come passare alla 9

Se il vostro server o il vostro cluster gira ancora su Proxmox VE 8, da qualche settimana sta funzionando senza rete di sicurezza. La tabella del ciclo di vita pubblicata da Proxmox fissa la fine del supporto della versione 8 ad agosto 2026, e uno sviluppatore del progetto ha precisato sul forum ufficiale che da fine agosto le release basate su Debian 12, cioè tutta la famiglia della 8, sono uscite dal supporto. Da allora non arrivano più correzioni di sicurezza, né per Proxmox né per il kernel su cui girano le vostre macchine virtuali.

Non è un problema che si vede subito, ed è proprio per questo che viene rimandato: il server continua ad accendersi, le VM partono, l'interfaccia web risponde come prima. Il rischio cresce però con ogni vulnerabilità scoperta dopo agosto, perché ciascuna resterà aperta per sempre su chi non aggiorna. Se Proxmox è arrivato in azienda da poco, può essere utile ripassare prima cos'è Proxmox VE e come funziona. In questo articolo raccogliamo cosa è cambiato davvero, cosa si rischia a restare sulla 8, cosa porta la 9 e, soprattutto, come si fa l'aggiornamento senza sorprese, sia su un nodo singolo sia su un cluster in produzione.

Cosa è successo a fine agosto

Proxmox lega la durata del supporto di ogni versione a quella della distribuzione Debian su cui è costruita: secondo la FAQ ufficiale una versione resta supportata almeno finché il team di sicurezza di Debian supporta la versione corrispondente, cioè per circa tre anni dal rilascio. Proxmox VE 8 è basata su Debian 12 «Bookworm», è uscita a giugno 2023, e la stessa tabella riporta la fine del supporto di Debian 12 a luglio 2026 e quella di Proxmox VE 8 ad agosto 2026. La versione 9, basata su Debian 13 «Trixie», è uscita ad agosto 2025 e la sua data di fine supporto non è ancora stata annunciata.

Il ciclo è identico per Proxmox Backup Server, come riporta la sua FAQ: la versione 3, anch'essa su Debian 12, ha raggiunto la fine del supporto nello stesso mese, mentre la 4 è su Debian 13 come la nuova Proxmox VE. Chi usa PBS per i backup del cluster ha quindi due aggiornamenti da pianificare, non uno.

Qualcuno spera in un'estensione, sul modello del supporto a lungo termine che Debian offre per alcuni pacchetti. Gli sviluppatori di Proxmox, interpellati più volte sul forum, hanno sempre risposto di non avere piani per un supporto più lungo, ricordando che il supporto esteso di Debian copre solo una parte dei pacchetti. Non c'è quindi una proroga da aspettare.

Figura 1. Le versioni 8 e 9 hanno convissuto per un anno, da agosto 2025 ad agosto 2026: quella era la finestra pensata per aggiornare con calma.

Cosa si rischia restando sulla 8

Il primo rischio è la sicurezza, ed è concreto già oggi. A metà ottobre, nella discussione sul forum dedicata alla vulnerabilità CVE-2026-74580, che permette di uscire da una macchina virtuale passando dal sottosistema vhost del kernel, lo staff di Proxmox ha ricordato che la versione 8 è fuori supporto e che quella vulnerabilità è soltanto uno dei tanti problemi che la riguardano, mentre la correzione è stata rilasciata solo nel kernel della versione 9. Una falla che consente a una VM di raggiungere l'host è esattamente il tipo di problema che non si vuole lasciare aperto su un server che ospita i sistemi di tutta l'azienda.

Lo stesso concetto vale per il kernel nel suo insieme. Rispondendo a chi chiedeva di continuare a usare un kernel ormai senza aggiornamenti, un membro dello staff ha scritto che per quel kernel non arrivano più correzioni di sicurezza né di altro tipo, e che usare un kernel non supportato non è una buona idea su nessun sistema in produzione.

Ci sono poi conseguenze meno immediate ma altrettanto reali. Ogni mese che passa, la distanza fra la vostra installazione e quella attuale aumenta, e con lei la quantità di cambiamenti da assorbire tutti insieme quando l'aggiornamento diventerà inevitabile, magari per via di un guasto o di un nuovo server da aggiungere al cluster. E se l'azienda rientra fra quelle soggette alla direttiva NIS2, un hypervisor che non riceve più patch di sicurezza è un punto difficile da giustificare in un audit.

Cosa cambia con la versione 9

La 9.0 è uscita il 5 agosto 2025 e, secondo le note di rilascio, porta Debian 13, il kernel 6.14, QEMU 10.0 e Ceph Squid 19.2.3, con un percorso di aggiornamento diretto dalla 8.4. Da allora sono uscite altre due versioni minori, e l'ultima disponibile è la 9.2, rilasciata il 21 maggio 2026.

Fra le novità della 9.0 che interessano chi ha un'infrastruttura in produzione, le note di rilascio citano le snapshot sui volumi LVM condivisi, in anteprima tecnologica, che sono utili a chi usa storage iSCSI o Fibre Channel, le regole di affinità per l'alta disponibilità, che permettono di decidere su quali nodi deve o non deve girare una risorsa, e i fabric della rete definita via software, oltre alla possibilità di espandere i pool ZFS in RAIDZ.

La 9 porta anche cambiamenti che possono rompere qualcosa, e sono quelli da conoscere prima di iniziare. Le note di rilascio segnalano fra l'altro che il supporto a GlusterFS è stato eliminato, che il vecchio cgroup v1 non c'è più, che i nomi delle schede di rete possono cambiare dopo l'aggiornamento e che il file /etc/sysctl.conf non viene più letto. Ne parliamo nella sezione sulle verifiche, perché ognuno di questi punti va controllato sulla vostra installazione specifica.

Chi sta ancora lasciando VMware, infine, non ha motivo di passare dalla 8: conviene installare direttamente la 9 e poi spostare le macchine virtuali, con la procedura descritta nella nostra guida alla migrazione da VMware ESXi a Proxmox VE o affidandola al nostro servizio di migrazione.

Prima di iniziare: le verifiche che non vanno saltate

La guida ufficiale all'aggiornamento elenca alcuni prerequisiti precisi, e conviene trattarli come condizioni bloccanti: se uno solo non è soddisfatto, l'aggiornamento non si comincia.

Tutti i nodi devono essere aggiornati all'ultima versione della 8.4, e il comando pveversion deve riportare almeno la 8.4.1. Sulla partizione principale devono esserci almeno 5 GB liberi, e la guida consiglia di averne più di 10. Deve esistere un backup valido e verificato di tutte le macchine virtuali e di tutti i container, e se il nodo fa parte di un cluster, il cluster deve essere in buona salute. La guida raccomanda anche di lavorare dalla console del server o da un accesso remoto come IPMI, e se è disponibile solo SSH, di usare tmux o screen, perché una connessione che cade a metà aggiornamento può lasciare il sistema in uno stato scomodo.

Per chi ha un cluster con Ceph c'è un prerequisito in più, ed è il più impegnativo: Ceph va portato alla versione 19.2 Squid prima di iniziare l'aggiornamento di Proxmox, seguendo la guida dedicata, che a sua volta richiede che il cluster sia in buona salute e che i pacchetti di partenza siano abbastanza recenti. Chi è ancora su Ceph Quincy deve passare prima da Reef, quindi in quel caso gli aggiornamenti di Ceph sono due.

Lo strumento che tiene insieme tutto è pve8to9, incluso negli ultimi pacchetti della 8.4. Controlla la configurazione e segnala i problemi senza correggere nulla da solo, va lanciato almeno una volta con l'opzione --full, che attiva tutti i controlli, e va rilanciato dopo ogni correzione per verificare che l'avviso sia sparito. La guida stessa avverte però che Proxmox può essere personalizzato molto, e che lo script potrebbe non riconoscere tutti i problemi di una configurazione particolare.

Ed è qui che servono le verifiche caso per caso, cioè quelle che dipendono da cosa gira sui vostri nodi. Le più frequenti, fra quelle elencate nelle note di rilascio e nella guida, sono queste:

• GlusterFS: se lo usate come storage, il supporto è stato rimosso e va pianificata un'alternativa prima dell'aggiornamento.
• Container molto vecchi: i container con versioni di systemd molto datate, come CentOS 7 o Ubuntu 16.04, non sono più supportati.
• Nomi delle schede di rete: possono cambiare, e Proxmox fornisce lo strumento pve-network-interface-pinning per fissarli prima di aggiornare.
• Impostazioni del kernel: chi ha messo parametri in /etc/sysctl.conf deve spostarli, perché quel file non viene più considerato.
• Backup con Veeam: secondo la guida, Veeam non funziona con le VM che usano la nuova versione di macchina 10.0, e la soluzione indicata è fissare la versione a 9.2+pve1 oppure rimandare l'aggiornamento.
• Plugin di storage di terze parti, vGPU NVIDIA e passthrough PCI: per i plugin va attesa la versione compatibile del produttore, per le vGPU NVIDIA serve almeno GRID 18.3, e con il nuovo kernel il passthrough di alcune periferiche PCI può smettere di funzionare.

Figura 2. Le condizioni a sinistra fermano l'aggiornamento se non sono soddisfatte; quelle a destra vanno controllate in base a cosa gira sui nodi.

L'aggiornamento su un singolo nodo

Superate le verifiche, la procedura vera e propria è più corta di quanto ci si aspetti, ed è descritta nella guida ufficiale. Il primo passo è portare il nodo all'ultima 8.4 e controllare la versione:

apt update
apt dist-upgrade
pveversion

Poi si passano i repository di Debian e di Proxmox da Bookworm a Trixie. La guida indica di sostituire il nome della distribuzione nei file esistenti, controllando che non resti nessun repository di Bookworm:

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

I repository di Proxmox VE 9 vanno poi aggiunti nel nuovo formato deb822, cioè in file con estensione .sources, sia per il repository enterprise sia per quello senza sottoscrizione, e nei cluster con Ceph anche per il repository di Ceph Squid. La guida riporta il contenuto esatto di ciascun file, ed è da lì che conviene copiarlo, verificando poi con apt update e apt policy che i repository nuovi siano letti e che i vecchi siano spariti.

A quel punto parte l'aggiornamento vero:

apt update
apt dist-upgrade

Quanto dura dipende soprattutto dai dischi: la guida parla di oltre un'ora su dischi meccanici lenti e di meno di cinque minuti su un server con storage SSD. Durante l'operazione il sistema chiede cosa fare con alcuni file di configurazione modificati, e per ciascuno dei più comuni, come quelli di LVM, SSH e GRUB, la guida indica la scelta consigliata. Al termine si rilancia pve8to9, si riavvia sul nuovo kernel e si ricarica l'interfaccia web svuotando la cache del browser. Facoltativamente, il comando apt modernize-sources converte nel formato nuovo anche i repository rimasti nel formato vecchio.

Su un nodo singolo, però, l'aggiornamento significa fermare tutte le macchine virtuali per il tempo dell'operazione e del riavvio, e soprattutto significa che se qualcosa va storto non c'è un altro nodo su cui ripartire, ed è uno dei motivi per cui molte aziende, a questo punto, valutano il passaggio a un cluster Proxmox a tre nodi. Per questo il backup verificato non è una formalità: è il piano di ritorno, e conviene aver provato a ripristinarlo, come spieghiamo nell'articolo su come si fa il backup di Proxmox.

L'aggiornamento di un cluster, un nodo alla volta

In un cluster l'aggiornamento si fa a rotazione, ed è il motivo per cui si può fare senza fermare i servizi. Si sceglie un nodo, si spostano le macchine virtuali e i container che devono restare accesi sugli altri nodi, si aggiorna il nodo e lo si riavvia, si controlla che sia tornato nel cluster in buona salute, e solo allora si passa al successivo.

L'ordine conta per una ragione precisa. La guida spiega che una migrazione da un nodo con una versione più vecchia a uno con una versione più nuova funziona sempre, mentre quella in senso contrario può funzionare ma in generale non è supportata. In pratica, man mano che i nodi passano alla 9, le macchine virtuali devono spostarsi verso i nodi già aggiornati e non tornare indietro. La guida avverte anche che in un cluster aggiornato solo in parte possono comparire piccole incoerenze se si opera dall'interfaccia di un nodo già sulla 9 su un nodo ancora sulla 8, e suggerisce in quel caso di ripetere l'operazione dall'interfaccia del nodo non ancora aggiornato.

Chi usa l'alta disponibilità deve sapere che la 9 sostituisce i vecchi gruppi HA con le nuove regole, e che la conversione avviene da sola, ma solo quando tutti i nodi del cluster sono stati aggiornati. Fino a quel momento conviene non toccare la configurazione dell'HA, e alla fine verificare nei log che la conversione sia andata a buon fine.

Nei cluster con Ceph, inoltre, l'aggiornamento di Ceph a Squid viene prima di tutto il resto e va completato su tutti i nodi, con lo storage in buona salute, prima di cominciare la rotazione per Proxmox.

Figura 3. In un cluster a tre nodi i servizi restano accesi per tutta l'operazione, perché in ogni momento due nodi su tre ospitano le macchine virtuali.

Quanto tempo serve davvero

L'aggiornamento di un singolo nodo, con le verifiche già fatte, è un lavoro di qualche ora fra preparazione, esecuzione e controlli finali. Quello che allunga i tempi sono quasi sempre le verifiche caso per caso: uno storage che non è più supportato, un vecchio container da migrare, un plugin di backup che non è ancora compatibile, un aggiornamento di Ceph che deve passare da due versioni. Sono problemi che pve8to9 aiuta a scoprire, ma che vanno risolti uno per uno prima di iniziare, ed è lì che conviene investire il tempo, perché una volta lanciato l'aggiornamento tornare indietro non è semplice.

Se preferite che ce ne occupiamo noi

Aggiorniamo nodi singoli da Proxmox VE 8 a 9 a 250 euro per nodo, partendo sempre da un backup verificato e dal controllo completo con pve8to9. Per i cluster, soprattutto con Ceph o alta disponibilità, prepariamo un piano su misura, perché l'ordine dei nodi, l'aggiornamento di Ceph e la gestione delle macchine virtuali cambiano il lavoro da fare. I dettagli sono nella pagina del servizio di aggiornamento a Proxmox VE 9, e per un intervento puntuale, come la sola verifica con pve8to9, si possono usare anche i nostri pacchetti di ore senza abbonamento.

Se invece volete smettere di rincorrere le versioni, con il nostro abbonamento di assistenza Proxmox gli aggiornamenti li pianifichiamo e li facciamo noi, un nodo alla volta e senza fermare le VM, insieme al monitoraggio e alla verifica dei backup. Tutti i nostri servizi su Proxmox e VMware sono raccolti nella pagina dedicata alla virtualizzazione e alle infrastrutture server.

Se state valutando anche la sottoscrizione di Proxmox, che dà accesso al repository enterprise ma non comprende chi pianifica e applica gli aggiornamenti, le differenze fra le due cose le abbiamo messe in fila nell'articolo Sottoscrizione Proxmox o contratto di assistenza.

Fonti

1. Proxmox VE, FAQ, tabella del ciclo di vita delle versioni e regola sulla durata del supporto.
2. Forum di Proxmox, Kernel 6.17 end of support after July, messaggi dello staff del 21 luglio e del 22 settembre 2026 sulla fine del supporto delle release basate su Debian 12 e sull'uso di kernel non supportati.
3. Forum di Proxmox, Proxmox VE support lifecycle, risposte dello staff sull'assenza di piani di supporto a lungo termine.
4. Proxmox Backup Server, FAQ, tabella del ciclo di vita delle versioni.
5. Forum di Proxmox, CVE-2026-74580 V-GHOST, affected Proxmox VE versions, messaggio dello staff del 15 ottobre 2026.
6. Proxmox VE, Roadmap, note di rilascio della 9.0 e della 9.2 e problemi noti della 9.0.
7. Proxmox VE, Upgrade from 8 to 9, prerequisiti, procedura, indicazioni per i cluster e problemi noti.
8. Proxmox VE, Ceph Reef to Squid, requisiti e procedura per l'aggiornamento di Ceph.