Proxmox VE 8 arrive en fin de support : la migration vers la 9 se planifie en deux fenêtres, pas en un week-end
La branche Proxmox VE 8, sortie en juin 2023 sur Debian 12, atteint sa fin de vie en août 2026 : les correctifs de l’hyperviseur s’arrêtent, même si Debian LTS continue. Pour qui gère du Ceph ou des conteneurs anciens, la montée vers la 9 est deux projets distincts — et un rollback qui passe par la restauration, pas par la migration inverse.
Août 2026. La branche Proxmox VE 8, sortie en juin 2023 sur une base Debian 12 (Bookworm), atteint sa fin de vie — la documentation officielle fixe l’échéance au mois d’août 2026. Le réflexe est de bloquer un week-end pour sauter vers Proxmox VE 9. Pour une partie des parcs, c’est la mauvaise idée : la migration cache deux projets enchaînés, et un plan de retour qui n’existe pas.
Ce qui s’arrête vraiment, et ce qui continue
La table de cycle de vie du FAQ Proxmox est sans ambiguïté. Proxmox VE 8 (base Debian 12, première version 2023-06) a pour fin de vie 2026-08 ; Proxmox VE 9 (base Debian 13 Trixie) est sorti en 2025-08. Le document parle d’un mois, pas d’un jour : rien ne s’éteint au 1er septembre, aucune licence n’expire, et le cluster continue de démarrer. Ce qui s’arrête, c’est l’arrivée des nouveaux paquets : correctifs du noyau Proxmox, de QEMU, des paquets pve-* eux-mêmes.
C’est là que la nuance compte. Debian 12 a quitté le support de sécurité régulier le 12 juillet 2026 pour passer à l’équipe LTS, maintenue jusqu’au 30 juin 2028. Ce filet est réel — mais il ne couvre que les paquets Debian. L’hyperviseur n’en fait pas partie : pve-manager, qemu-server, le noyau Proxmox ou le packaging Ceph viennent des dépôts de Proxmox. Quand la branche 8 tombe, c’est précisément la partie qui fait tourner vos machines qui cesse de recevoir des correctifs. Vous continuez de recevoir les patches OpenSSL ; pas ceux de l’hyperviseur.
Le piège du plan de retour
La migration officielle 8 → 9 énonce une règle qui se lit vite et se digère tard : déplacer une VM ou un conteneur d’une version ancienne vers une version récente fonctionne toujours ; l’inverse « peut fonctionner, mais n’est généralement pas supporté ». Traduit en samedi soir : dès que vous montez le premier nœud et que vous y déplacez des charges, vous ne pouvez plus compter sur le retour vers le nœud resté en 8.
Cela change la nature du plan B. Beaucoup entrent dans la fenêtre en se disant que leur rollback, c’est « je re-migre les VM sur l’autre nœud ». Ce n’est pas le cas : le rollback, c’est la restauration depuis la sauvegarde, avec le temps que cela implique et les heures de données perdues entre-temps. Si vous n’avez jamais chronométré la restauration complète des trois machines qui comptent vraiment, vous n’avez pas de plan B — vous avez un espoir.
Ceph : ce n’est pas une fenêtre, c’est deux
L’exigence figure dans le wiki, en gras : si vous exploitez du Ceph hyperconvergé en Quincy ou Reef, vous devez d’abord le porter vers Ceph 19.2 Squid, avant d’entamer la montée de Proxmox. Avant, pas pendant. Et monter Ceph sur un cluster avec des données vivantes a son propre rythme : OSD par OSD, en vérifiant la santé du cluster entre chaque étape, sans se presser — parce que se presser sous Ceph se paie en backfill.
Quiconque a encore ce chantier en attente face au calendrier d’août connaît déjà la réponse : cela ne tient pas dans un week-end. La première moitié tient, la seconde se fera en septembre. Vérifier coûte une commande et évite une conversation désagréable au milieu de la fenêtre :
# Version de Ceph sur le cluster
ceph --version
ceph versions
# Vérificateur officiel, sur CHAQUE nœud, avec --full
pve8to9 --fullpve8to9 est livré avec les paquets récents de la 8.4 et ne fait que contrôler et rapporter : par défaut, il ne modifie rien. C’est l’outil le plus sous-estimé du processus — lancez-le aujourd’hui, pas la veille de la fenêtre, car sa valeur est de vous remettre la liste des devoirs tant qu’il reste du temps pour les faire.
Les conteneurs qui ne démarreront pas
C’est le blocage qui surgit toujours tard. Proxmox VE 9 ne supporte pas les conteneurs tournant sous systemd 230 ou plus ancien — une version de 2016 — ce qui, en pratique, vise CentOS 7, Ubuntu 16.04 et leurs semblables. Et ces conteneurs existent : ce sont précisément ceux que personne ne veut toucher, qui exécutent l’application dont l’auteur a depuis pris sa retraite.
S’en sortir, c’est déplacer cette application sur un nouveau système d’exploitation, avec les tests et la validation de ses utilisateurs que cela implique. Si vous le découvrez un samedi à vingt-trois heures, votre option réaliste est de laisser le conteneur sur un nœud que vous ne montez pas, et de finir avec un cluster à moitié migré. Si vous le découvrez aujourd’hui, il vous reste un mois pour décider si cette application mérite une migration, une VM dédiée ou la retraite.
Quand août n’est pas le bon moment
La règle est simple : si une seule de ces conditions est vraie, la migration passe en septembre, avec un plan de confinement pour le mois sans correctifs.
- Ceph encore en Quincy ou Reef. Squid d’abord, dans sa propre fenêtre.
- Des conteneurs en ancien systemd sans décision sur leur destination.
- Aucun accès hors bande au nœud (IPMI, iDRAC, iLO) — le nouveau noyau peut renommer les interfaces réseau.
- Une restauration jamais chronométrée — le plan B passe par la restauration.
pve8to9 --fullqui renvoie des avertissements non compris.- La fenêtre tombe sur une clôture de mois, une paie ou un pic d’activité, ou les gens qui connaissent le système sont en congés.
Verdict
Si vous êtes sur un nœud unique de homelab sans Ceph ni conteneur exotique, montez en Proxmox VE 9 ce mois-ci en suivant la voie in-place du wiki : dernière 8.4, 5 Go libres sur la racine (plutôt 10), session tmux, un nœud à la fois. Vous y gagnez une branche supportée, sans grande prise de risque. Si vous gérez un cluster avec Ceph ou des conteneurs anciens, scindez le chantier en deux fenêtres — Ceph vers Squid d’abord, Proxmox ensuite — et drainez chaque nœud avant de le monter : le nœud que vous touchez ne doit rien porter quand il casse. Et si le calendrier ne tient pas, assumez-le proprement : interface de gestion hors Internet, restaurations réellement chronométrées avant la nouvelle fenêtre, et août consacré à la préparation — pve8to9 --full, inventaire des conteneurs, Ceph vers Squid. Être en retard avec un cluster debout se rattrape ; être à l’heure avec un nœud qui ne boote pas, non.