Le support standard de Proxmox VE 8 s'est achevé en août 2026. La montée vers la version 9 n'est donc plus une option de confort, et elle se fait en place, noeud par noeud, sans interruption de service sur un cluster correctement dimensionné. C'est une opération bien outillée, à condition de respecter un ordre précis : certaines étapes faites à l'envers cassent un cluster, et Ceph en est l'exemple le plus brutal.
Cette page est un compagnon de la procédure officielle, qu'elle ne remplace pas. Lisez en parallèle la page Upgrade from 8 to 9 du wiki Proxmox, qui fait foi et reste à jour des cas particuliers.
01Préalables et ordre des opérations
Quatre conditions sont bloquantes. Tant qu'elles ne sont pas réunies, il ne faut pas lancer la montée, et le vérificateur vous le dira de toute façon.
| Condition | Pourquoi | Comment vérifier |
|---|---|---|
| Proxmox VE 8.4.1 au minimum, sur tous les noeuds | Le vérificateur n'existe que dans les derniers paquets de la 8.4 | pveversion -v |
| Ceph déjà en 19.2 Squid | Monter Proxmox sous un Ceph plus ancien casse le cluster | ceph versions |
| Espace libre sur la racine | Au moins 5 Go, 10 Go confortables | df -h / |
| Sauvegardes récentes et vérifiées | C'est le seul vrai plan de repli | Tâche de vérification PBS réussie |
L'ordre général, sur une plateforme complète :
- Mettre tous les noeuds au dernier niveau de la 8.4.
- Monter Ceph vers Squid si ce n'est pas déjà fait, et attendre le retour à
HEALTH_OK. - Monter Proxmox Backup Server vers la version 4, séparément : il ne suit pas la montée du cluster.
- Monter les noeuds Proxmox VE un par un, en vidant chacun avant.
- Une fois tous les noeuds en version 9, monter Ceph vers Tentacle si vous le souhaitez.
Monter Proxmox VE alors que Ceph est resté sur une version antérieure à Squid. Le cluster de
stockage se retrouve piloté par des paquets qui ne savent plus lui parler, et la plateforme
devient inaccessible après le redémarrage. Vérifiez ceph versions avant toute
chose, et pas seulement sur un noeud.
Vous allez changer de noyau et de version de Debian. Prévoyez un accès console matériel, iDRAC, iLO ou IPMI, avant de commencer. La console web de Proxmox s'interrompt pendant la montée, et c'est précisément le moment où l'on aimerait voir ce qui se passe.
02Le script de contrôle pve8to9
Proxmox fournit un vérificateur qui passe en revue la configuration du noeud et classe ce qu'il trouve en informations, avertissements et échecs. Il ne modifie rien, il se lance autant de fois qu'on veut, et c'est le document de référence de toute la préparation.
# amener d'abord le noeud au dernier niveau de la 8.4 apt update && apt dist-upgrade -y # puis le verificateur, en mode complet pve8to9 --full
| Niveau | Signification | Conduite à tenir |
|---|---|---|
| INFO | Constat, souvent sans action | Lire, comprendre, passer |
| WARN | Point à examiner selon votre contexte | Décider explicitement, ne pas ignorer |
| FAIL | Condition bloquante | Corriger avant de continuer |
Le vérificateur signale le méta-paquet systemd-boot comme bloquant sur les
installations où l'amorçage est géré par l'outil de Proxmox. La correction consiste à installer
explicitement les deux paquets qui comptent et à retirer le méta-paquet. Faites-le avant de
toucher aux dépôts, et relancez le vérificateur pour confirmer.
# les deux paquets utiles, installes explicitement apt install systemd-boot-efi systemd-boot-tools # puis le meta-paquet, qui gene les montees liees a l'amorcage apt remove systemd-boot # controle : l'amorcage doit rester coherent proxmox-boot-tool status pve8to9 --full | grep -E 'FAIL|WARN'
03Ce qu'il faut corriger avant
Au-delà de ce que remonte le vérificateur, six situations méritent un examen en amont. Chacune a transformé une montée de routine en soirée difficile chez quelqu'un.
Conteneurs anciens et cgroup v1
Proxmox VE 9 ne sait plus fonctionner en mode hérité : les conteneurs dont le système interne est trop ancien ne démarreront plus. En pratique cela ne concerne que des distributions réellement anciennes, mais il suffit d'un seul conteneur oublié pour perdre un service. Faites l'inventaire avant, pas après.
Greffons de stockage tiers
Un greffon de stockage fourni par un constructeur de baie ou par un éditeur ne se charge pas tant que son auteur n'a pas publié une version compatible. Posez la question au fournisseur avant de monter le premier noeud, sous peine de voir disparaître un stockage entier.
Le fichier sysctl hérité
Le fichier /etc/sysctl.conf n'est plus pris en compte. Si vous y avez placé des
réglages réseau ou mémoire, ils cesseront silencieusement de s'appliquer. Déplacez-les vers un
fichier dédié avant la montée.
# relever ce qui est reellement defini, hors commentaires grep -vE '^\s*(#|$)' /etc/sysctl.conf # les reporter dans un fichier dedie cp /etc/sysctl.conf /etc/sysctl.d/99-local.conf sysctl --system
Noms d'interfaces réseau
Un changement de nom d'interface au redémarrage laisse le noeud sans réseau, donc injoignable. Si vos noms d'interfaces ne sont pas figés par une règle explicite, c'est le bon moment pour le faire, en les liant à leur adresse matérielle. C'est aussi pour cela que l'accès hors bande est un préalable et non une précaution.
Stockage LVM partagé
Sur les plateformes adossées à une baie en iSCSI ou en fibre, l'activation automatique des volumes au démarrage change de comportement. Prévoyez une vérification du montage des stockages au premier redémarrage de chaque noeud.
Routage dynamique et SDN
Si vous utilisez le routage dynamique du SDN Proxmox, le service correspondant dépend désormais du service réseau, ce qui peut bloquer un redémarrage du réseau en cours de fonctionnement. Prévoyez un redémarrage complet du noeud plutôt qu'un rechargement de la configuration réseau.
04Monter Ceph en premier
# la reponse doit montrer Squid partout, moniteurs comme OSD
ceph versions
ceph -s
Si le cluster est sur une version antérieure, la montée de Ceph est une opération à part
entière, qui se mène avant et séparément, service par service et dans l'ordre : moniteurs,
gestionnaires, OSD, puis serveurs de métadonnées. Elle se termine par un retour à
HEALTH_OK et un rééquilibrage complet.
Laissez la plateforme tourner quelques jours entre la montée de Ceph et celle de Proxmox VE. Cela paraît lent, mais si un problème de stockage apparaît, vous saurez immédiatement à quelle opération l'attribuer. Enchaîner les deux revient à diagnostiquer deux changements en même temps, ce qui coûte bien plus que les jours gagnés.
05Basculer les dépôts vers Trixie
Debian 13 abandonne les fichiers d'une ligne au profit du format deb822, en fichiers
.sources à plusieurs champs. Proxmox fournit une commande de conversion, à lancer
avant de changer quoi que ce soit d'autre.
# conversion des anciens fichiers .list vers le format deb822 apt modernize-sources # basculer la suite Debian de bookworm vers trixie sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.sources # verifier AVANT de lancer la montee apt update apt policy proxmox-ve
Si apt propose de retirer le paquet proxmox-ve, arrêtez tout.
Cela signifie que la configuration des dépôts est incorrecte, et poursuivre désinstallerait
Proxmox VE de la machine. Corrigez les dépôts, relancez apt update, et ne
continuez que lorsque la proposition a disparu. Le même raisonnement vaut si
apt policy ne propose aucun candidat en version 9.
06Monter un noeud, pas à pas
La montée se fait noeud par noeud. Tant que le cluster est mélangé, évitez les opérations structurantes : pas de création de machine, pas de modification de la haute disponibilité, pas de changement de stockage.
# deplacer les machines vers un autre noeud qm migrate 101 pve-02 --online # sur stockage local ZFS, les disques suivent qm migrate 101 pve-02 --online --with-local-disks # empecher Ceph de reconstruire pendant l'absence du noeud ceph osd set noout
# dans une session persistante : une coupure SSH en plein milieu fait mal
tmux new -s montee
apt update
apt dist-upgrade
La montée demande quoi faire des fichiers que vous avez modifiés. La règle sûre : conserver votre version pour tout ce que vous avez volontairement personnalisé, prendre la version du mainteneur pour ce que vous n'avez jamais touché, et dans le doute afficher les différences avant de répondre. Notez au passage les fichiers concernés, vous aurez à vérifier leur contenu après le redémarrage.
pve8to9 --full reboot # au retour : version, noyau, services en echec pveversion -v | head -3 uname -r systemctl --failed # cluster, stockages, Ceph pvecm status pvesm status ceph -s
# retirer le drapeau de maintenance ceph osd unset noout # rapatrier une machine et verifier la migration a chaud qm migrate 101 pve-01 --online
Laissez le premier noeud monté tourner quelques heures avec une charge réelle avant d'attaquer le suivant. Un cluster mélangé fonctionne, c'est prévu, et cette pause vous donne la possibilité de vous arrêter si quelque chose cloche, avec une plateforme encore majoritairement sur la version connue.
07Une fois le cluster complet
- Les groupes de haute disponibilité deviennent des règles d'affinité de noeud. La conversion est automatique une fois tous les noeuds en version 9. Vérifiez le résultat plutôt que de le supposer, et profitez-en pour découvrir les règles d'affinité entre ressources, qui n'existaient pas avant.
- Ceph peut passer à Tentacle, devenu la version par défaut des nouvelles installations. Ce n'est pas urgent, et cela constitue une opération à part entière, à mener avec le même soin.
- Les fichiers de configuration signalés pendant la montée méritent une relecture, en particulier tout ce qui touche au réseau, à l'onduleur et à la supervision.
- La supervision doit continuer de remonter : un agent de métriques peut avoir été désactivé par le changement de version.
# tous les noeuds a la meme version pvecm nodes pvesh get /nodes --output-format json-pretty | grep -E 'node|version' # haute disponibilite : les regles ont remplace les groupes ha-manager rules config ha-manager status # plus aucun paquet retenu ni service en echec, sur chaque noeud apt list --upgradable systemctl --failed
08Les pannes connues
| Symptôme | Cause probable | Conduite à tenir |
|---|---|---|
| apt veut retirer proxmox-ve | Dépôts mal configurés | Arrêter, corriger les dépôts |
| Échec du vérificateur sur l'amorçage | Méta-paquet systemd-boot | Voir le paragraphe 02 |
| Plus d'espace sur la partition EFI | Anciens noyaux accumulés | Nettoyer, puis relancer |
| Noeud injoignable après redémarrage | Nom d'interface réseau modifié | Console hors bande, figer les noms |
| Passage direct de carte PCI défaillant | Incompatibilité avec le nouveau noyau | Démarrer sur l'ancien noyau en attendant |
| Conteneur qui ne démarre plus | Système interne trop ancien, cgroup v1 | Reconstruire le conteneur |
| Machine Windows qui ne démarre plus | Changement de noyau, amorçage hérité | Vérifier le firmware et l'ordre de démarrage |
| Réglages système sans effet | sysctl.conf ignoré | Déplacer vers un fichier dédié |
| Stockage absent au démarrage | Activation des volumes LVM partagés | Vérifier le montage, adapter |
| Conflits de paquets tiers | Dépôts externes, conteneurisation | Retirer, monter, réinstaller |
Il n'y a pas de retour arrière d'une montée de version en place. Démarrer sur l'ancien noyau dépanne pour un problème de pilote, mais ne ramène pas le système à la version précédente. Le seul repli réel est la restauration de la machine depuis une sauvegarde, et c'est pour cela que les sauvegardes vérifiées figurent parmi les conditions bloquantes du paragraphe 01.
09Liste de contrôle
| Phase | Action | Vérification |
|---|---|---|
| Préparation | Tous les noeuds en 8.4 à jour | pveversion -v |
| Préparation | Ceph en Squid, HEALTH_OK | ceph versions |
| Préparation | Serveur de sauvegarde monté séparément | Tâche de sauvegarde réussie |
| Préparation | Accès hors bande vérifié | Console accessible |
| Préparation | Vérificateur sans échec sur chaque noeud | pve8to9 --full |
| Préparation | Greffons tiers et conteneurs anciens traités | Inventaire validé |
| Dépôts | Conversion deb822 puis bascule Trixie | apt policy proxmox-ve |
| Dépôts | proxmox-ve non marqué pour suppression | Sortie de apt dist-upgrade |
| Par noeud | Noeud vidé, drapeau noout posé | Aucune machine active |
| Par noeud | Montée dans une session persistante | Session tmux ou screen |
| Par noeud | Redémarrage et contrôles | Version, noyau, services, stockages |
| Par noeud | Drapeau retiré, migration à chaud testée | Aller-retour réussi |
| Fin | Tous les noeuds en version 9 | pvecm nodes |
| Fin | Règles de HA converties et vérifiées | ha-manager rules config |
| Fin | Supervision et sauvegardes opérationnelles | Première sauvegarde post-montée |
Comptez une heure par noeud pour la montée elle-même sur du matériel récent, et autant pour les contrôles et la stabilisation. Sur un cluster de trois noeuds, c'est une journée confortable en étalant correctement, pas une soirée. Le temps réellement consommé est celui de la préparation, et c'est du temps bien employé.
Une plateforme Proxmox a exploiter sereinement
Nous exploitons des clusters Proxmox VE et Ceph en production pour des PME, des structures reglementees et des collectivites. Remplacement de noeud, montee de version, reprise d'une plateforme existante : nous intervenons au forfait comme en astreinte.