Migrer Proxmox VE 8 vers 9 sur un serveur dédié : guide pas à pas

Pourquoi migrer maintenant : Proxmox VE 8 en fin de vie

Proxmox VE est l'hyperviseur open source de référence pour créer et gérer des serveurs virtuels sur un serveur physique. Il permet d'héberger des dizaines de machines virtuelles KVM et de conteneurs LXC sur un seul serveur dédié, chacun avec son propre système d'exploitation (Ubuntu, Debian, Windows Server). Depuis le 31 août 2026, Proxmox VE 8 a atteint sa fin de vie. Proxmox ne publie plus aucun correctif de sécurité ni de mise à jour pour les composants PVE 8 : noyau Linux, QEMU, LXC et paquets Proxmox. Les failles découvertes après cette date restent ouvertes sur tout serveur dédié qui exécute encore cette version.

Proxmox VE 9, disponible depuis août 2025, repose sur Debian 13 Trixie. La version courante (PVE 9.2, mai 2026) embarque le noyau Linux 7.0, QEMU 11.0, LXC 7.0 et ZFS 2.4. Si vous administrez un serveur dédié avec Proxmox pour héberger vos environnements virtuels, la migration est désormais une priorité de sécurité. C'est aussi l'occasion d'améliorer les performances sur vos processeurs et votre hardware actuel.

Ce qui change dans Proxmox VE 9

La version 9 apporte des évolutions significatives pour la gestion des serveurs de virtualisation. Le nouveau noyau Linux 7.0 améliore la prise en charge du hardware récent (processeurs AMD EPYC et Intel Xeon de dernière génération, contrôleurs NVMe et SSD) et les performances des machines virtuelles :

Parmi les fonctionnalités notables introduites depuis la version 9.0 :

• Snapshots sur stockage LVM thick partagé (iSCSI, Fibre Channel), auparavant réservés au thin provisioning ;
• Expansion de pools RAIDZ : ajout de disques SSD ou HDD à un vdev RAIDZ existant sans interruption de service, grâce à ZFS 2.3+ ;
• SDN Fabrics : protocoles WireGuard et BGP intégrés au réseau logiciel de Proxmox pour configurer vos réseaux virtuels ;
• Conteneurs LXC depuis des images OCI (tech preview depuis PVE 9.1), compatibles avec les images Docker ;
• Équilibrage de charge dynamique (CRS) pour répartir automatiquement les machines virtuelles sur les noeuds d'un cluster en haute disponibilité (PVE 9.2) ;
• Interface mobile reconstruite avec le framework Yew (Rust).

Pour les administrateurs venant de VMware ESXi ou d'un autre hyperviseur propriétaire, Proxmox VE 9 offre une alternative open source mature. L'hyperviseur apporte la flexibilité de gérer aussi bien des serveurs virtuels Linux (Ubuntu, Debian) que Windows sur le même serveur physique, avec un accès root complet à l'hôte.

Prérequis avant de commencer la migration

La procédure de mise à niveau s'effectue in-place (sur le serveur en production) et nécessite un redémarrage. Préparez-la soigneusement, surtout si vous n'avez pas d'accès physique à la machine serveur.

Version minimale requise

Votre installation doit être à jour en Proxmox VE 8.4.1 ou supérieur. Connectez-vous en root sur votre serveur et vérifiez avec :

pveversion

Si votre version est inférieure, mettez à jour d'abord :

apt update && apt dist-upgrade

Sauvegarde de toutes les VM et conteneurs

Avant toute opération de migration, réalisez une sauvegarde complète de toutes vos machines virtuelles et conteneurs LXC. Chaque serveur virtuel doit être sauvegardé avec son système d'exploitation, ses données et sa configuration réseau (adresse IP, passerelle, DNS). Si vous utilisez Proxmox Backup Server, lancez une tâche de sauvegarde complète. Sinon, exportez vos VM critiques via vzdump. Pour approfondir les stratégies de sauvegarde sur serveur dédié, consultez notre guide sur les sauvegardes et la haute disponibilité.

Espace disque

La migration nécessite au minimum 5 Go d'espace libre sur la partition racine. Prévoyez 10 Go ou plus si vous avez beaucoup de paquets installés. Vérifiez avec df -h /.

Accès console ou IPMI

Ne comptez pas uniquement sur SSH. Un changement de nommage des interfaces réseau peut rendre le serveur inaccessible après le redémarrage. Un accès IPMI, KVM-over-IP ou une console physique est fortement recommandé. Si vous disposez d'un serveur dédié chez un hébergeur, vérifiez que l'accès console est disponible avant de commencer. Les serveurs dédiés ElypseCloud disposent d'un accès IPMI pour intervenir même en cas de perte de connectivité réseau.

Vérifier la compatibilité des systèmes d'exploitation invités

Le passage à QEMU 11 et au noyau Linux 7.0 peut modifier le comportement de certains pilotes virtuels (virtio). Vérifiez que les systèmes d'exploitation de vos machines virtuelles sont à jour : Ubuntu 22.04 LTS ou supérieur, Debian 11+, Windows Server 2019+ avec les pilotes virtio récents. Mettez à jour les pilotes virtio-win avant la migration si vous hébergez des VM Windows.

Migration Ceph obligatoire (si applicable)

Si votre cluster utilise Ceph, vous devez migrer vers Ceph Squid 19.2 avant de lancer la mise à niveau de Proxmox VE. Les versions Ceph Quincy (17.2) et Reef (18.2) ne sont pas compatibles avec PVE 9. La migration Ceph se fait depuis l'interface web de Proxmox (menu Ceph du noeud) ou en ligne de commande, et nécessite un redémarrage des daemons OSD.

Checklist pré-migration avec pve8to9

Proxmox fournit un outil de diagnostic intégré qui vérifie les prérequis automatiquement. Lancez-le en SSH avec un accès root sur chaque noeud :

pve8to9

Pour un rapport détaillé, ajoutez l'option --full :

pve8to9 --full

L'outil vérifie la version de Proxmox, la compatibilité des dépôts, l'état de Ceph, l'espace disque, les règles de firewall et les paquets en conflit. Corrigez chaque avertissement avant de continuer. Si vous gérez un cluster de multiples serveurs, exécutez la checklist sur tous les noeuds.

Procédure de migration pas à pas

Étape 1 : mettre à jour vers la dernière version de PVE 8.4

apt update
apt dist-upgrade
pveversion

La sortie doit afficher pve-manager/8.4.x (où x >= 1).

Étape 2 : modifier les dépôts Debian (Bookworm vers Trixie)

Remplacez toutes les références à bookworm par trixie dans les fichiers de dépôts :

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list

Étape 3 : configurer le dépôt Proxmox VE 9

Pour les utilisateurs du dépôt enterprise (avec abonnement) :

cat > /etc/apt/sources.list.d/pve-enterprise.sources << 'EOF'
Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

Pour les utilisateurs du dépôt communautaire (sans abonnement) :

cat > /etc/apt/sources.list.d/proxmox.sources << 'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

Étape 4 : configurer le dépôt Ceph (si applicable)

Si votre serveur utilise Ceph, configurez le dépôt Ceph Squid pour Trixie :

cat > /etc/apt/sources.list.d/ceph.sources << 'EOF'
Types: deb
URIs: https://enterprise.proxmox.com/debian/ceph-squid
Suites: trixie
Components: enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

Étape 5 : rafraîchir l'index et lancer la mise à niveau

apt update
apt dist-upgrade

L'opération télécharge et installe les nouveaux paquets Debian 13, le noyau Linux, QEMU, LXC, ZFS et tous les composants Proxmox VE 9. Répondez Y pour confirmer. En cas de question sur la conservation de fichiers de configuration modifiés, conservez la version locale (N) sauf si vous n'avez rien personnalisé.

Étape 6 : redémarrer le serveur

reboot

Le serveur physique redémarre sur le nouveau noyau. Vérifiez la version après le redémarrage :

pveversion

La sortie doit afficher pve-manager/9.x.

Pièges courants et problèmes connus

Changement de nom des interfaces réseau

Le nouveau noyau peut renommer les interfaces réseau (par exemple eth0 devient ens18). Si cela arrive, le serveur perd sa connectivité et l'adresse IP configurée devient inaccessible. C'est la raison principale pour laquelle un accès IPMI ou console est indispensable. En cas de problème, éditez /etc/network/interfaces depuis la console pour mettre à jour les noms d'interfaces et vérifier les adresses IP. Pour les principes de base de la sécurisation d'un serveur dédié, y compris la configuration réseau, consultez notre guide dédié.

LVM Thin Pool corrompu

Sur certaines installations, le pool LVM thin (pve/data) peut nécessiter une réparation après la mise à niveau :

lvconvert --repair pve/data

Vérifiez l'état du pool avec lvs -a avant de relancer des VM.

Règles de firewall

Les règles du firewall Proxmox (pve-firewall) sont conservées après la migration, mais le changement de nommage des interfaces peut les rendre inopérantes. Si vous avez configuré des règles au niveau du datacenter, du noeud ou de chaque serveur virtuel, vérifiez-les dans l'interface web après le redémarrage. Testez la connectivité de vos machines virtuelles et leurs ports ouverts avant de remettre les services en production.

Avertissements Ceph pendant la migration

Des messages d'erreur liés à l'audit Ceph peuvent apparaître pendant la mise à niveau. Ces avertissements sont temporaires et se résolvent après le redémarrage complet du cluster. Ne paniquez pas si ceph status affiche HEALTH_ERR pendant la procédure, à condition qu'aucun autre avertissement critique ne soit présent.

Affichage mémoire des VM

Après la migration, l'interface web peut afficher un pourcentage de mémoire plus élevé pour les machines virtuelles. Il s'agit d'un changement dans la méthode de calcul qui inclut désormais l'overhead de QEMU. Les serveurs virtuels n'utilisent pas réellement plus de RAM.

Cache du navigateur

L'interface web de Proxmox peut mal s'afficher après la migration. Forcez le rechargement du cache avec Ctrl+Maj+R (ou Cmd+Option+R sur macOS).

Vérification post-migration

Après le redémarrage, effectuez ces contrôles pour vous assurer que la migration s'est bien déroulée :

1. Version de Proxmox : pveversion doit afficher pve-manager/9.x.
2. Noyau Linux : uname -r doit afficher un noyau 7.x (PVE 9.2) ou 6.17 (PVE 9.1).
3. État des VM : vérifiez que toutes les machines virtuelles et conteneurs LXC démarrent correctement. Chaque serveur virtuel doit retrouver son adresse IP et ses services.
4. Réseau et DNS : testez la connectivité de chaque VM et conteneur, en particulier les ponts (bridges), les VLAN et la résolution DNS.
5. Firewall : vérifiez que les règles du firewall Proxmox sont actives et que les ports nécessaires sont ouverts.
6. Stockage : vérifiez l'état des pools ZFS (zpool status), des volumes LVM (lvs -a) et du stockage Ceph (ceph status) si applicable. Contrôlez les performances de vos disques SSD si vous constatez une dégradation.
7. Processeurs : si vous utilisez le CPU passthrough (type host) pour vos machines virtuelles, vérifiez que les fonctionnalités du processeur sont correctement exposées aux VM.
8. Haute disponibilité : consultez le journal HA avec journalctl -eu pve-ha-crm pour vérifier qu'aucune ressource n'est en état d'erreur.
9. Checklist finale : relancez pve8to9 pour confirmer que tous les points sont résolus.

Pour les clusters de multiples serveurs, migrez un noeud à la fois. Évacuez les VM du noeud avec la migration en direct (live migration) avant de lancer la mise à niveau sur ce noeud, puis passez au suivant. Cette méthode limite le temps d'indisponibilité de chaque machine virtuelle.

Proxmox sur un serveur dédié ElypseCloud

Proxmox VE est un hyperviseur idéal pour exploiter pleinement un serveur dédié bare metal. Il transforme une seule machine serveur en plateforme de virtualisation comparable à un cloud privé, capable d'héberger des dizaines de serveurs virtuels, chacun avec son propre système d'exploitation, ses adresses IP et ses services. Vous pouvez y héberger vos sites web et leurs services (serveur web, base de données), ainsi que des environnements de test et de développement, avec la flexibilité d'allouer dynamiquement les ressources (processeurs, RAM, stockage SSD) à chaque machine virtuelle. Pour choisir entre un serveur dédié et un VPS selon votre charge de travail, consultez notre comparatif serveur dédié bare metal vs VPS.

Les serveurs dédiés ElypseCloud, hébergés dans notre datacenter en France, sont livrés avec un accès IPMI complet, ce qui facilite la gestion des serveurs et les opérations de maintenance comme une migration Proxmox. En tant qu'hébergeur, nous fournissons la connectivité réseau, l'alimentation redondante et le support technique pour vous permettre de vous concentrer sur vos environnements virtuels. Si vous disposez d'un serveur ou de vos propres machines physiques, notre offre de housing en datacenter vous permet de les héberger dans un environnement sécurisé.

Pour les administrateurs qui gèrent de multiples serveurs et environnements virtuels, la maîtrise de l'accès SSH est essentielle. Consultez notre guide pour sécuriser SSH sur un serveur Linux et celui pour configurer l'authentification par clé SSH.

Questions fréquentes

Puis-je migrer directement de Proxmox VE 7 vers 9 ?

Non. Proxmox ne prend en charge que la mise à niveau d'une version majeure à la suivante. Vous devez d'abord migrer de PVE 7 vers PVE 8 (8.4.1 minimum), puis de PVE 8 vers PVE 9.

La migration provoque-t-elle un temps d'arrêt ?

Oui. Le redémarrage du serveur hôte est obligatoire. Toutes les VM et conteneurs hébergés sur ce noeud seront arrêtés pendant le redémarrage. Sur un cluster multi-noeuds, vous pouvez limiter l'impact en migrant les VM à chaud vers un autre noeud avant la mise à niveau.

Mes VM et conteneurs sont-ils conservés après la migration ?

Oui. La mise à niveau in-place conserve toutes les machines virtuelles, les conteneurs LXC, les configurations réseau et les pools de stockage. Les VM n'ont pas besoin d'être reconfigurées.

Faut-il un abonnement Proxmox pour migrer ?

Non. La migration fonctionne avec le dépôt communautaire (no-subscription). L'abonnement donne accès au dépôt enterprise (testé et stable) et au support technique officiel, mais n'est pas obligatoire pour effectuer la mise à niveau.

Que faire si le serveur ne démarre plus après la migration ?

Connectez-vous via IPMI ou console physique. Les causes les plus fréquentes sont un changement de nom d'interface réseau (éditez /etc/network/interfaces) ou un problème de pool LVM thin (lancez lvconvert --repair pve/data). Si le noyau ne démarre pas, sélectionnez l'ancien noyau dans le menu GRUB pour revenir temporairement à l'état précédent.

Faut-il migrer Ceph avant de mettre à niveau Proxmox VE ?

Oui, si votre cluster utilise Ceph. Vous devez migrer Ceph Quincy (17.2) ou Reef (18.2) vers Ceph Squid (19.2) avant de lancer la mise à niveau de Proxmox VE 8 vers 9. Cette migration se fait depuis l'interface web de Proxmox ou en ligne de commande.

Peut-on migrer des VM VMware ESXi vers Proxmox VE 9 ?

Oui. Proxmox VE permet d'importer des disques virtuels au format VMDK (VMware) et de les convertir au format qcow2 utilisé par QEMU. L'import se fait avec la commande qm disk import. Chaque machine virtuelle importée conserve son système d'exploitation et ses données, mais les VMware Tools doivent être remplacés par l'agent QEMU (qemu-guest-agent).

Quels systèmes d'exploitation peut-on héberger sur Proxmox VE 9 ?

Proxmox VE 9 prend en charge tous les systèmes d'exploitation compatibles avec QEMU/KVM : Linux (Ubuntu, Debian, CentOS, Rocky Linux), Windows (Windows Server 2016 et supérieur, Windows 10/11) et BSD. Les conteneurs LXC hébergent des distributions Linux légères. Chaque serveur virtuel fonctionne de manière isolée avec ses propres ressources (processeur, RAM, stockage, adresse IP).