Proxmox VE 8 es queda sense pedaços a l'agost: per què no actualitzarem el dia 30

La taula de cicle de vida de la documentació oficial de Proxmox és de les coses més avorrides que es poden llegir un dimecres, i també de les més útils: la branca 8 —la que es va instal·lar en gairebé tot el que es va muntar entre el 2023 i el 2025— té el final de vida fixat a l'agost del 2026. És a dir, d'aquí a poc més de trenta dies. La reacció habitual és bloquejar un cap de setmana d'agost i saltar a la 9. Nosaltres direm el contrari: per a uns quants clústers, actualitzar a l'agost és pitjor idea que arribar tard.

No pas perquè la 9 sigui dolenta —la fem servir en producció i ja vam escriure el checklist de hardening que apliquem a cada clúster 9.2— sinó perquè la data límit empeny a fer en un cap de setmana una cosa que, segons com estigui muntat el teu entorn, són dos projectes encadenats. I perquè el salt té una asimetria de la qual gairebé ningú parla i que s'emporta per davant el pla de tornada enrere.

Què s'acaba exactament (i què no)

Val la pena ser precisos, perquè aquí es ven molta por. La taula de suport del FAQ de Proxmox diu això:

Fixa't que la documentació oficial parla de mes, no de dia: «2026-08». Veuràs per aquí el 31 d'agost citat amb molta seguretat; nosaltres no l'hem trobat en cap pàgina de Proxmox. Encara més: el mateix wiki de l'actualització, al seu apartat sobre els contenidors que fan servir cgroup v1, escriu una altra cosa —«el cicle de suport restant de Proxmox VE 8 (estimated EOL is July 2026)»—. Si la documentació del fabricant no es posa d'acord amb ella mateixa en un mes, tu tampoc no hauries de planificar al dia. L'1 de setembre no s'apaga res, no caduca cap llicència i el teu clúster continua arrencant igual. El que deixa d'arribar són els paquets nous: correccions del kernel de Proxmox, de QEMU, dels mateixos pve-*.

I aquí hi ha un matís que gairebé ningú explica bé. Debian 12 (bookworm) va acabar el seu suport de seguretat regular el 12 de juliol del 2026 i va passar a mans de l'equip d'LTS, que el manté fins al 30 de juny del 2028. Sona a xarxa de seguretat, i per als paquets de Debian ho és. Però Debian LTS manté paquets de Debian, i l'hipervisor no ho és: pve-manager, qemu-server, el kernel de Proxmox o l'empaquetat de Ceph surten dels repositoris de Proxmox. Quan la branca 8 cau, aquesta part —la que executa les teves màquines— deixa de rebre correccions. Continues tenint pedaços d'OpenSSL; no del teu hipervisor.

L'asimetria que et deixa sense marxa enrere

El wiki oficial del salt 8→9 ho diu sense dramatisme, en una línia que es llegeix ràpid i s'entén tard: migrar una VM o un contenidor d'una versió antiga a una de nova sempre funcionarà; a l'inrevés «pot funcionar, però en general no està suportat». Traduït a la nit de dissabte: així que actualitzes el primer node i li mous càrrega a sobre, ja no pots comptar amb tornar aquella feina al node que continua a la 8. Potser funcionarà. Però «potser funcionarà» no és un pla de tornada enrere.

Això canvia la naturalesa del pla B. Molta gent entra a la finestra pensant que la seva tornada enrere és «migro les VMs a l'altre node i llestos». No: la teva tornada enrere és restaurar des de còpia, amb el temps de restauració que això implica i amb les hores transcorregudes pel mig. Si no has cronometrat mai quant triga la restauració completa de les tres màquines que de debò importen, no tens pla B: tens una esperança.

Si fas anar Ceph, no és una finestra: en són dues

El requisit és al wiki, en negreta i al seu lloc: si tens Ceph hiperconvergent a Quincy o a Reef, cal portar-lo a Ceph 19.2 Squid abans de començar l'actualització de Proxmox. Abans, no durant. I actualitzar Ceph en un clúster amb dades a sobre és un projecte amb el seu propi ritme: OSD a OSD, mirant l'estat del clúster entre pas i pas, sense pressa, perquè la pressa a Ceph es paga en backfill. Qui tingui això pendent i estigui mirant el calendari d'agost ja sap la resposta: no hi cap. Hi cap la primera meitat, i la segona al setembre.

Comprovar-ho costa una ordre i estalvia una conversa lletja a mitja finestra:

pve8to9 ve als paquets recents de la 8.4 i només comprova i reporta: per defecte no toca res. És l'eina més infravalorada de tot el procés. Passa-la avui, no la nit de la finestra: el seu valor és donar-te la llista de deures amb prou temps per fer-los.

Els contenidors que no arrencaran

Aquest és l'entrebanc que sempre apareix tard. Proxmox VE 9 no admet contenidors amb systemd 230 o anterior —una versió del 2016—, cosa que a la pràctica vol dir CentOS 7, Ubuntu 16.04 i companyia. El wiki ho diu clar. I aquests contenidors existeixen: són justament els que ningú vol tocar, amb una aplicació de la qual l'autor es va jubilar fa anys.

Resoldre-ho vol dir portar aquella aplicació a un sistema operatiu nou, amb les seves proves i el seu acord amb qui la fa servir. Si ho descobreixes dissabte a les onze de la nit, la teva opció realista és deixar aquell contenidor on és, en un node que no actualitzes, i quedar-te amb un clúster a mitges. Si ho descobreixes avui, tens un mes per decidir si aquella aplicació mereix una migració, una màquina virtual dedicada o una jubilació.

Els sis senyals que aquest agost NO toca

La nostra regla és simple: si es compleix una sola d'aquestes sis, l'actualització es mou al setembre i es munta un pla de contenció per al mes que queda sense pedaços. Arribar tard amb el clúster dret és recuperable; arribar puntualment amb un node que no arrenca, a l'agost i amb mitja plantilla de vacances, no.

Com ho fem nosaltres

Quan hi ha maquinari i capacitat de sobres, no fem actualització in-place: preferim buidar el node —migrar-ne la càrrega a la resta—, deixar-lo net, actualitzar-lo o reinstal·lar-lo, tornar-li feina i passar al següent. És més lent i més avorrit, i a canvi el node que estàs tocant no té res a sobre quan es trenca. És la lògica de sempre: separa el canvi del risc. Quan no hi ha marge per buidar un node sencer, l'in-place del wiki és perfectament vàlid i funciona; el que canvia és que llavors sí que necessites tot l'anterior resolt per endavant.

La resta de la disciplina, en curt, i tot surt del wiki oficial més el que ens ha anat ensenyant l'ofici:

I dos avisos concrets del wiki que valen el seu pes: en sistemes amb UEFI i LVM pot caldre instal·lar el metapaquet grub-efi-amd64, i hi ha thin pools d'LVM que després del salt necessiten un lvconvert --repair. Cap de les dues coses és greu si saps que existeixen; totes dues ho semblen molt a les dues de la matinada.

Si no hi arribes: pla de contenció honest

Decidir «al setembre» és legítim, però no és gratis i no es decideix callant. El que fem amb un clúster que es quedarà unes setmanes fora de suport:

Hi ha un cas en què sí que diem «no ho facis ara, compra-ho bé»: si el pla passa per substituir maquinari per fer lloc a la migració, aquest any la memòria no acompanya. Ho vam explicar amb els números de mercat a què li ha fet la IA al preu de la RAM. I si el coll d'ampolla és d'emmagatzematge, la decisió de disseny de Ceph pesa més que la versió: la tens desgranada a rèplica 3 contra erasure coding amb els comptes complets.

Els trenta dies que queden, repartits

Si hi vas a anar, aquest és el repartiment que ens sembla realista comptant des d'avui, 29 de juliol. Aquesta setmana: pve8to9 --full a tots els nodes, inventari de contenidors per versió de sistema operatiu, comprovar la versió de Ceph i l'espai lliure a l'arrel. Tot és lectura, no toca res, es pot fer un dimarts a la tarda. Primera quinzena d'agost: resoldre el que hagi sortit —Ceph a Squid, contenidors vells, avisos del comprovador—, i provar una restauració amb cronòmetre. Segona quinzena: el salt, començant pel node de menys risc, un node per finestra, amb la resta del clúster dret. Si en qualsevol punt del camí alguna cosa no hi és, s'atura i es va al setembre. Aquesta és la part important del pla.

En curt

La data d'agost és real i cal prendre-se-la de debò: sense ella, aquesta actualització es quedaria adormida dos anys més. Però una data no és un pla, i l'error car d'aquest estiu no serà arribar al setembre: serà entrar a la finestra sense haver passat el comprovador, sense saber quins contenidors no arrenquen i creient que es pot tornar enrere movent una VM. Això últim és l'única cosa que de debò no es pot desfer.

Fonts (verificades): taula de cicle de vida de versions (PVE 9 / Debian 13 / 2025-08; PVE 8 / Debian 12 / 2023-06 / final de vida 2026-08; PVE 7 / 2024-07) — FAQ oficial de Proxmox VE. Requisits i problemes coneguts del salt (ser a l'última 8.4 amb pve-manager 8.4.1 o superior per als repositoris, Ceph 19.2 Squid abans de començar, 5 GB lliures a l'arrel i més de 10 recomanats, contenidors amb systemd 230 o anterior no admesos, canvis de nom d'interfícies de xarxa, grub-efi-amd64 en UEFI+LVM, lvconvert --repair, pve8to9 --full, migració en viu garantida només de versió antiga a nova) — wiki oficial «Upgrade from 8 to 9». La contradicció del mateix fabricant («estimated EOL is July 2026», a l'apartat d'eliminació de cgroup v1 del mateix wiki d'actualització). Dates de Debian 12 (final del suport regular el 12-07-2026, tres anys després de la publicació inicial; LTS fins al 30-06-2028) — anunci oficial de Debian i wiki de Debian LTS. El dia exacte del final de vida (31 d'agost) circula per mitjans i agregadors, però no l'hem pogut confirmar en documentació de Proxmox: per això parlem de mes. El criteri dels sis senyals, el repartiment dels trenta dies i la manera de treballar per node buidat són nostres.