Migration Proxmox 8 vers 9 : retour d'experience et methodologie
Proxmox VE 9.0 est sorti en juin 2025, base sur Debian 13 Trixie. Nous avons migre l'integralite de notre infrastructure de production vers Proxmox 9.1. Cet article detaille notre methodologie, notre choix du kernel opt-in, le comparatif Debian 12 vs 13, et les etapes techniques pour une migration reussie.
Pourquoi migrer vers Proxmox 9
Proxmox VE 9.x apporte des ameliorations significatives sur trois axes : la base OS, le kernel Linux, et les composants de virtualisation. Voici les raisons principales qui justifient la migration.
Debian 13 Trixie : support long terme
Proxmox VE 9 est base sur Debian 13 "Trixie", sortie en juin 2025. Debian 13 beneficiera d'un support de securite jusqu'en 2028 minimum (LTS jusqu'en 2030+). Rester sur Proxmox 8 (Debian 12 Bookworm) signifie s'approcher progressivement de la fin de support active de Debian 12 (prevue mi-2026 pour le support standard, LTS jusqu'en 2028).
Migrer maintenant nous donne une marge de 4+ ans sur le support de la base OS, au lieu de devoir planifier une migration dans l'urgence quand Debian 12 approchera de sa fin de vie.
Kernel recent et nouvelles fonctionnalites
Proxmox 9.x embarque un kernel 6.x recent avec des ameliorations notables : meilleur support du hardware recent (CPU Intel/AMD derniere generation, NVMe, cartes reseau), optimisations de performance I/O, ameliorations de la securite (mitigations Spectre/Meltdown plus efficaces), et support ameliore de io_uring pour les workloads stockage.
Fin de support Debian 12 a terme
Meme si Debian 12 LTS restera supportee jusqu'en 2028, les paquets Proxmox VE 8.x ne recevront plus de fonctionnalites nouvelles — uniquement des correctifs de securite. Les nouvelles features (GUI, SDN, Ceph) ne seront disponibles que dans la branche 9.x. Migrer maintenant vous permet de beneficier des dernieres ameliorations.
Notre choix
Chez RDEM Systems, nous avons migre toute notre infra de production vers Proxmox 9.1 des decembre 2025. Aucun incident, performances identiques ou superieures, et une base OS fraiche pour les 4+ prochaines annees.
Debian 12 vs 13 / Proxmox 8 vs 9 — etude comparative
Le passage de Proxmox 8 a 9 implique un changement de base OS complet (Debian 12 vers 13). Voici un comparatif detaille des composants cles.
Composants systeme
| Composant | Proxmox 8 (Debian 12) | Proxmox 9 (Debian 13) |
|---|---|---|
| Base OS | Debian 12 Bookworm | Debian 13 Trixie |
| Kernel | 6.8.x (pve-kernel) | 6.12.x+ (pve-kernel) |
| systemd | 252 | 256+ |
| OpenSSL | 3.0.x | 3.3.x+ |
| Python | 3.11 | 3.13+ |
| glibc | 2.36 | 2.40+ |
Composants Proxmox VE
| Composant | Proxmox 8.4 | Proxmox 9.1 |
|---|---|---|
| QEMU | 8.1.x | 9.x |
| LXC | 6.0.x | 6.1.x |
| Ceph | Reef 18.2 | Squid 19.x |
| GUI / Web UI | ExtJS 7 | ExtJS 7 ameliore + new widgets |
| SDN | OVN, VXLAN, EVPN | OVN ameliore, nouveau panneau SDN |
Avantages concrets du passage en 9.x : meilleur support hardware, QEMU 9.x avec performance I/O amelioree, Ceph Squid plus stable et performant, ameliorations de l'interface web, et une base Debian fraichement supportee pour 4+ ans.
Notre choix — kernel opt-in
Avant de lancer le dist-upgrade complet de Debian 12 vers Debian 13, nous avons choisi d'utiliser la methode du kernel opt-in. Cette approche consiste a installer le kernel de Proxmox 9 sur votre installation Proxmox 8 existante, sans migrer la base OS.
Pourquoi le kernel opt-in ?
- Controle de la version : vous choisissez exactement quand passer au nouveau kernel, independamment du dist-upgrade. Cela permet de valider le kernel sur votre hardware specifique avant de changer quoi que ce soit d'autre.
- Rollback facile : si le nouveau kernel pose probleme (driver GPU, carte reseau exotique, module DKMS tiers), il suffit de rebooter sur l'ancien kernel via GRUB. Aucun rollback de dist-upgrade necessaire.
- Stabilite en production : on valide d'abord le kernel (composant le plus critique), puis on fait le dist-upgrade dans un second temps. Deux etapes au lieu d'un big bang.
Comment proceder
L'installation du kernel opt-in se fait en quelques commandes :
# 1. S'assurer d'etre en Proxmox 8.4 (derniere version 8.x) apt update && apt dist-upgrade # 2. Installer le meta-paquet du kernel Proxmox 9 apt install proxmox-default-kernel # 3. Pinning : s'assurer que le nouveau kernel est prioritaire proxmox-boot-tool kernel pin 6.12 # adapter au numero exact # 4. Reboot sur le nouveau kernel reboot # 5. Verification apres reboot uname -r # doit afficher 6.12.x-x-pve pveversion # toujours Proxmox 8.4, mais kernel 9.x
Important
Le kernel opt-in est une etape facultative. C'est ce que nous avons choisi pour des raisons de performances — les gros gains du nouveau kernel justifiaient une validation prealable sur notre hardware de production. Vous pouvez passer directement au dist-upgrade si vous etes confiant dans votre hardware.
Etapes de migration Proxmox 8 vers 9
Voici les etapes techniques detaillees que nous suivons pour chaque migration. Consultez egalement la documentation officielle Proxmox .
Audit et preparation
Avant toute chose, verifiez l'etat de votre infrastructure :
# Verifier la version actuelle pveversion -v # Lancer le checker officiel pve8to9 --full # Verifier l'espace disque (minimum 5 Go libres) df -h / # Sauvegarder la configuration du cluster tar czf /root/pve-config-backup.tar.gz /etc/pve/ # Verifier la sante Ceph (si applicable) ceph status ceph osd tree
Mise a jour vers Proxmox 8.4
Assurez-vous d'etre sur la derniere version 8.x avant de migrer :
# Mise a jour complete vers 8.4 apt update apt dist-upgrade -y # Reboot si nouveau kernel installe reboot # Verifier pveversion # doit afficher 8.4-x
Migration vers Proxmox 9.1
Changez les depots et lancez le dist-upgrade :
# Mettre a jour les sources APT vers Debian 13 + PVE 9 sed -i 's/bookworm/trixie/g' /etc/apt/sources.list sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-*.list # Ou mieux : editer manuellement chaque fichier # Mise a jour et dist-upgrade apt update apt dist-upgrade -y # Repondre aux prompts de configuration # (garder la version locale sauf indication contraire) # Reboot obligatoire reboot
Verification post-migration
Apres le reboot, verifiez que tout fonctionne correctement :
# Version Proxmox pveversion -v # doit afficher PVE 9.1 # Kernel uname -r # doit afficher 6.12.x-x-pve # Services Proxmox systemctl status pvedaemon pveproxy pvestatd # Cluster (si multi-noeud) pvecm status # Ceph (si applicable) ceph status ceph osd versions # doit afficher Squid # VMs et conteneurs qm list pct list # Acces GUI : https://node:8006
Documentation officielle : pour les details complets et les cas particuliers, consultez le guide officiel de migration Proxmox 8 vers 9 .
Notre retour d'experience
Nous avons migre l'integralite de notre infrastructure de production vers Proxmox 9.1 en decembre 2025. Voici notre retour concret.
Perimetre migre
- Clusters multi-noeuds en production
- Stockage Ceph (Reef vers Squid) — migration transparente
- PBS 3.x vers 4.x — sauvegardes continues sans interruption
- SDN OVN — configuration preservee
Resultats
0
incidents post-migration
~30 min
par noeud (dist-upgrade + reboot)
0 s
downtime VM (migration live)
Tarifs de migration : pour connaitre nos forfaits de migration Proxmox 8 vers 9 et les details de notre accompagnement, consultez notre grille tarifaire detaillee sur RDEM Managed Services .
Prerequisites et points de vigilance
Points d'attention
- Ceph : ne migrez jamais plus d'un noeud Ceph a la fois. Attendez que le cluster Ceph soit en
HEALTH_OKavant de passer au noeud suivant. La migration Ceph Reef vers Squid se fait automatiquement lors du dist-upgrade, mais le rebalancing peut prendre du temps. - Extensions et modules DKMS : si vous utilisez des modules kernel tiers (drivers GPU NVIDIA, carte reseau Intel proprietaire, ZFS custom), verifiez leur compatibilite avec le nouveau kernel avant la migration. Le kernel opt-in est votre meilleur outil pour cette validation.
- Backup avant migration : faites une sauvegarde complete de toutes vos VMs et de la configuration du cluster (
/etc/pve/) avant de commencer. Utilisez NimbusBackup ou PBS pour une sauvegarde complete avant la fenetre de maintenance. - HA (Haute Disponibilite) : si vos VMs sont gerees par le HA Manager, desactivez temporairement les ressources HA sur le noeud que vous migrez. Reactivez-les une fois le noeud de retour dans le cluster en version 9.
- Depots custom : si vous avez ajoute des depots APT tiers (Zabbix, Docker, Grafana...), assurez-vous qu'ils proposent des paquets pour Debian 13 Trixie avant le dist-upgrade. Sinon, desactivez-les temporairement.