RDEM Systems
    Guide technique23 fevrier 202614 min de lecture

    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 en decembre 2025 ; le parc est mis a jour mensuellement, en totalite, et tourne aujourd'hui en Proxmox VE 9.2. 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. Depuis, le parc est mis a jour mensuellement dans sa totalite : il tourne aujourd'hui en Proxmox VE 9.2 — c'est pour ca que le noyau que nous avions pris en opt-in a fini rattrape par la release.

    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

    ComposantProxmox 8 (Debian 12)Proxmox 9 (Debian 13)
    Base OSDebian 12 BookwormDebian 13 Trixie
    Kernel6.8.12-9 par défaut, 6.14 en opt-in6.17.2-1 par défaut (9.1)
    systemd252256+
    OpenSSL3.0.x3.3.x+
    Python3.113.13+
    glibc2.362.40+

    Composants Proxmox VE

    ComposantProxmox 8.4Proxmox 9.1
    QEMU9.2.010.1.2
    ZFS2.2.72.3.4
    LXC6.0.06.0.5
    CephSquid 19.2.1 / Reef 18.2.4Squid 19.2.3
    GUI / Web UIExtJS 7ExtJS 7 ameliore + new widgets
    SDNOVN, VXLAN, EVPNOVN ameliore, nouveau panneau SDN

    Attention : « le » kernel de Proxmox, c'est deux choses

    Chaque version de Proxmox VE publie un kernel par défaut et, parfois, un kernel opt-in plus récent que l'on installe explicitement. Confondre les deux fausse toute comparaison de versions.

    • Proxmox VE 8.4 — défaut 6.8.12-9, opt-in 6.14
    • Proxmox VE 9.0 — défaut 6.14.8-2, pas d'opt-in
    • Proxmox VE 9.1 — défaut 6.17.2-1
    • Proxmox VE 9.2 — défaut 7.0, disponible en opt-in sur 9.x avant sa sortie

    Le motif se répète à chaque cycle : le kernel opt-in d'une version devient le kernel par défaut de la suivante. C'est vérifiable sur toute la série — 5.15 puis 6.2 en opt-in sur 7.4, 6.8 puis 6.11 sur 8.3, 6.8 puis 6.14 sur 8.4. Passer en opt-in, c'est donc prendre en avance le noyau que vous aurez de toute façon.

    Exemple concret pris sur l'un de nos hyperviseurs : il tourne enproxmox-ve 9.2.0 sur Debian 13 Trixie, avec7.0.14-6-pve. Les deux méta-paquets y sont installés :proxmox-kernel-7.0 — celui qu'on nomme explicitement pour prendre un noyau en avance — etproxmox-default-kernel. Sur 9.2 ils pointent tous les deux sur 7.0, puisque c'est devenu le défaut : le noyau pris en opt-in a été rattrapé par la release, exactement comme prévu.

    Nos hyperviseurs sont mis à jour au moins une fois par mois, sur l'ensemble du parc — c'est précisément pour ça que le noyau pris en opt-in finit toujours par être rattrapé par la release. Un parc mis à jour une fois par an ne connaît pas ce phénomène : il saute directement d'un défaut à l'autre, avec tous les changements accumulés d'un coup.

    C'est aussi pourquoi uname -r ne suffit pas à savoir si vous êtes en opt-in : il faut regarder quelproxmox-kernel-* est installé, et le comparer au défaut de votre release.

    Le kernel opt-in de 8.4 est le kernel par défaut de 9.0 : c'est précisément ce qui rend la méthode décrite plus bas intéressante — vous validez sur votre matériel le kernel de Proxmox 9 avant de changer de base système. Attention en revanche au méta-paquet proxmox-default-kernel : il pointe vers le défaut de la version installée, donc sur un hôte 8.4 il vous donne 6.8, pas 6.14. Pour l'opt-in il faut nommer le paquet explicitement. Sources : roadmap Proxmox VE et guide officiel Upgrade from 8 to 9.

    Avantages concrets du passage en 9.x : meilleur support hardware, QEMU 10.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.

    Proxmox 8 vs 9 : ce qui change réellement côté performance

    « Proxmox 9 est plus rapide » n'est pas une réponse utile. Ce qui change, c'est la version de quatre composants situés chacun à un endroit différent du chemin d'I/O. Que vous le sentiez ou non dépend de celui qui constitue votre goulot d'étranglement.

    Ce qui bouge8 → 9Où ça se voit
    Kernel6.8.12 → 6.17.2io_uring sur les charges de stockage, ordonnancement sur les CPU récents à grand nombre de cœurs, pilotes pour les NVMe et cartes réseau de dernière génération. Le gain est maximal sur du matériel plus récent que le kernel 6.8, pas sur un parc ancien.
    QEMU9.2.0 → 10.1.2Couche bloc du guest et chemins virtio. Compte surtout pour les VMs à forte I/O ; une VM limitée par le CPU ne verra rien.
    CephSquid 19.2.1 → 19.2.3Uniquement si vous utilisez Ceph. C'est le composant dont le comportement et la stabilité changent le plus des quatre.
    LXC6.0.0 → 6.0.5Marginal. Un conteneur tournait déjà sur le kernel de l'hôte : le saut de kernel compte davantage que le saut de LXC.

    Ce que nous avons observé en production. Nous avons migré nos propres clusters en Proxmox 9.1 en décembre 2025 : zéro incident post-migration, environ 30 minutes par nœud pour le dist-upgrade et le redémarrage, et zéro seconde d'interruption des VMs grâce à la migration à chaud entre nœuds. À charge et matériel identiques, nous n'avons mesuré aucune régression. Ces mêmes nœuds ont depuis suivi la ligne 9.x : ils tournent aujourd'hui en Proxmox VE 9.2 avec le kernel 7.0.14-6-pve, pris en opt-in avant de devenir le défaut de 9.2.

    Ce que nous n'avons pas mesuré, et que nous n'affirmerons pas. Nous n'avons pas mené de campagne de benchmarks synthétiques avant/après. Notre critère de recette était la non-régression sur des charges de production réelles, pas un chiffre de benchmark. Quiconque publie un « X % plus rapide » unique pour Proxmox 8 vs 9 décrit son matériel et son stockage, pas l'hyperviseur. Si votre goulot est la latence disque sur du NVMe récent, le gain est du côté du kernel et de QEMU ; si vous êtes limité par le CPU sur du matériel ancien, attendez-vous à la parité, pas à un bond.

    Fin de vie de Proxmox 8, et sur quelle Debian repose chaque version

    Proxmox VE 9 repose sur Debian 13 « Trixie », sortie en juin 2025. Proxmox VE 8 repose sur Debian 12 « Bookworm ». C'est cette base système qui détermine la fenêtre de support : les deux questions n'en font qu'une.

     Proxmox VE 8Proxmox VE 9
    Base DebianDebian 12 BookwormDebian 13 Trixie (juin 2025)
    Support de sécurité standardfin attendue mi-2026au moins 2028
    LTS Debianjusqu'en 20282030+

    Concrètement : rester en Proxmox 8, c'est devoir planifier la montée de version sous contrainte de temps dès que Debian 12 quitte le support standard. Basculer maintenant vous donne quatre ans de marge sur la base système. Les dates faisant foi sont celles du calendrier des versions Debian.

    Un produit, pas trois. Cette page traite de Proxmox VE (l'hyperviseur) et de son chemin pve8to9. Proxmox Backup Server a le sien (pbs3to4, PBS 3.x vers 4.x) et Proxmox Mail Gateway un autre (pmg8to9). Les trois suivent le même changement de base Debian 12 vers 13 mais ne sont pas interchangeables : lancez le vérificateur correspondant au produit que vous migrez.

    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-kernel-6.14

# 3. Pinning : s'assurer que le nouveau kernel est prioritaire
proxmox-boot-tool kernel pin 6.14.11-4-pve   # adapter au numero exact

# 4. Reboot sur le nouveau kernel
reboot

# 5. Verification apres reboot
uname -r   # doit afficher 6.14.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 .

    1

    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
    2

    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
    3

    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
    4

    Verification post-migration

    Apres le reboot, verifiez que tout fonctionne correctement :

    # Version Proxmox
pveversion -v   # doit afficher la derniere 9.x publiee (9.2 aujourd'hui)

# Kernel
uname -r        # doit afficher le noyau par defaut de votre release
                # 6.17.x-x-pve sur 9.1, 7.0.x-x-pve sur 9.2

# 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 deja en Squid avant la bascule — prerequis officiel
    • 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_OK avant de passer au noeud suivant. Un cluster Ceph hyperconverge doit deja tourner en Squid 19.2 avant de lancer la montee de version : c'est un prerequis officiel, pas une etape 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.

    Documentation officielle

    Questions frequentes

    Oui, en environnement cluster. La methode recommandee consiste a migrer les noeuds un par un : on evacue les VMs du noeud via live migration, on met a jour le noeud vers Proxmox 9, puis on reintegre le noeud au cluster. Les VMs continuent de tourner sur les noeuds restants pendant la mise a jour. Sur un noeud standalone, un redemarrage est necessaire (quelques minutes de downtime).

    Oui. Le kernel opt-in Proxmox 6.x (base Debian 13) est le meme kernel que celui inclus dans Proxmox VE 9.x. Tous les modules KVM, ZFS, Ceph et DKMS fonctionnent de maniere identique. L'avantage du kernel opt-in est qu'il vous permet de tester le nouveau kernel sur votre hardware avant de faire le dist-upgrade complet vers Debian 13 Trixie.

    Non, Ceph n'est pas reinstalle et vos donnees ne bougent pas. En revanche il existe un prerequis bloquant : la documentation officielle impose de faire passer un cluster Ceph hyperconverge en Squid 19.2 AVANT de demarrer la montee de version Proxmox 8 vers 9. La bascule Reef vers Squid ne se fait pas toute seule pendant le dist-upgrade. Verifiez avec ceph --version ; si vous n'etes pas en Squid, suivez d'abord le guide Ceph Reef to Squid. Proxmox VE 8.4 livrait deja Squid 19.2.1 a cote de Reef 18.2.4, donc beaucoup de clusters sont deja prets. Une fois en Squid, les donnees sont preservees et les OSD restent intacts. Il est cependant imperatif de verifier la sante du cluster Ceph (ceph status) avant et apres la migration, et de ne jamais migrer plus d'un noeud Ceph a la fois.

    La commande pve8to9 est un script de verification (checklist) fourni par Proxmox qui analyse votre configuration actuelle et signale les problemes potentiels avant la migration. Il ne fait pas la migration lui-meme. La migration effective se fait via apt dist-upgrade apres avoir mis a jour les depots vers Debian 13 Trixie et Proxmox VE 9.x. Toujours executer pve8to9 avant de lancer le dist-upgrade.

    L'image ISO de Proxmox VE 9.x repose sur Debian 13 « Trixie », sortie en juin 2025. Proxmox VE 8.x reposait sur Debian 12 « Bookworm ». C'est ce changement de base système qui rend la montée de version plus lourde qu'un simple apt upgrade : le dist-upgrade traverse une version majeure de Debian, avec les changements de systemd, d'OpenSSL et de glibc qui vont avec.

    Il est recommande de mettre a jour PBS vers la version 4.x (compatible Proxmox 9) avant ou en meme temps que les hyperviseurs. PBS 3.x (Proxmox 8) reste compatible temporairement avec PVE 9, mais les nouvelles fonctionnalites de backup (verification amelioree, performance) ne seront disponibles qu'avec PBS 4.x. Planifiez la mise a jour PBS dans la meme fenetre de maintenance.

    Articles connexes

    A lire aussi sur nos blogs

    Besoin d'aide pour migrer vers Proxmox 9 ?

    RDEM Systems realise des migrations Proxmox 8 vers 9 cle en main. Audit de votre infrastructure, kernel opt-in, dist-upgrade et validation complete — zero downtime en cluster.

    Proxmox infogéré Planifier ma migration