L’essentiel à retenir

Proxmox VE 8 repose sur Debian 12 et arrive à la fin de son cycle de support.

Proxmox indique que la branche 8.4 recevra :

  • des mises à jour de sécurité ;
  • des corrections de bugs critiques ;

jusqu’en :

août 2026

La branche stable actuelle au moment de la rédaction est :

Proxmox VE 9.2

Elle repose sur Debian 13.

Une mise à niveau en place depuis une installation Proxmox VE 8.4 à jour est prise en charge, à condition de suivre la documentation officielle.

L’outil suivant doit être utilisé avant la migration :

pve8to9

Il vérifie plusieurs prérequis et signale des avertissements à traiter avant de modifier les dépôts ou de lancer la mise à niveau.

Que signifie réellement la fin du support ?

La fin du support ne provoque pas l’arrêt immédiat :

  • des machines virtuelles ;
  • des conteneurs LXC ;
  • du stockage ;
  • de l’interface d’administration ;
  • du cluster.

Une infrastructure peut continuer à fonctionner après août 2026.

Le problème est ailleurs : les nouvelles vulnérabilités ou certains bugs critiques découverts après l’échéance pourraient ne plus être corrigés sur Proxmox VE 8.

Le risque augmente donc avec le temps.

Une plateforme de virtualisation concentre souvent :

  • plusieurs serveurs ;
  • les contrôleurs de domaine ;
  • la messagerie ;
  • les applications métiers ;
  • les sauvegardes temporaires ;
  • les réseaux virtuels ;
  • les accès administrateurs.

Retarder indéfiniment une migration revient à conserver un composant central sans garantie de correctifs futurs.

Faut-il migrer immédiatement ?

Pas nécessairement dans la précipitation.

Mais la migration doit être planifiée avant l’échéance.

Le bon calendrier dépend :

  • du nombre de nœuds ;
  • de la présence d’un cluster ;
  • du stockage ;
  • de Ceph ;
  • des pilotes particuliers ;
  • des paquets tiers ;
  • de la criticité des machines virtuelles ;
  • des périodes d’activité de l’entreprise ;
  • de la possibilité de tester sur un laboratoire.

Une infrastructure simple peut nécessiter quelques heures d’arrêt.

Un cluster complexe avec Ceph, réplication, haute disponibilité et plusieurs réseaux demande une préparation beaucoup plus importante.

Proxmox VE 9.2 : quelle cible choisir ?

Au moment de la rédaction, Proxmox VE 9.2 est la version stable la plus récente annoncée par le projet.

La documentation officielle permet une migration de la dernière version de Proxmox VE 8 vers la branche 9.

Avant l’intervention :

  1. mettez entièrement à jour Proxmox VE 8.4 ;
  2. consultez la documentation de migration ;
  3. vérifiez la dernière version 9.x disponible ;
  4. utilisez les dépôts adaptés à votre abonnement ;
  5. évitez de cibler un numéro ancien si une version corrective plus récente existe.

L’objectif n’est pas forcément d’installer exactement 9.2.0.

Il est d’installer la version stable et corrigée recommandée au jour de l’intervention.

Identifier le type d’infrastructure

La procédure et le niveau de risque changent selon l’architecture.

Hôte unique

Un hôte unique héberge toutes les charges sur une seule machine.

Conséquences :

  • interruption nécessaire pour le redémarrage ;
  • aucune migration à chaud vers un autre nœud ;
  • importance critique des sauvegardes externes ;
  • nécessité d’un accès console local ou distant indépendant du réseau Proxmox.

Petit cluster

Un cluster de deux ou trois nœuds peut permettre de déplacer certaines machines avant de migrer un nœud.

Il faut néanmoins tenir compte :

  • du quorum ;
  • de la capacité restante ;
  • du stockage partagé ou local ;
  • de la haute disponibilité ;
  • des versions temporairement mixtes ;
  • de l’ordre de migration.

Cluster avec Ceph

Un cluster utilisant Ceph demande une procédure spécifique.

Proxmox indique qu’un environnement Proxmox VE 8.4 avec Ceph Reef doit procéder en plusieurs étapes :

  1. migrer Ceph Reef vers Ceph Squid en restant sur Proxmox VE 8.4 ;
  2. migrer Proxmox VE 8.4 vers Proxmox VE 9.2 ;
  3. éventuellement, migrer ensuite Ceph Squid vers une version plus récente prise en charge, selon la documentation courante.

Étape 1 : inventorier l’infrastructure

Avant toute modification, créez un état des lieux.

Vérifier la version Proxmox

pveversion --verbose

Conservez la sortie :

pveversion --verbose \
  > /root/pve-version-avant-migration.txt

Vérifier la version Debian

cat /etc/os-release

Vérifier le noyau

uname -a

Listez les noyaux installés :

dpkg --list |
  grep -E 'pve-kernel|proxmox-kernel'

Vérifier les mises à jour en attente

apt update

Puis :

apt list --upgradable

Relever la configuration réseau

ip -br address
ip route
cat /etc/network/interfaces

Si le système utilise des fichiers inclus :

find /etc/network/interfaces.d \
  -maxdepth 1 \
  -type f \
  -print \
  -exec cat {} \;

Relever le stockage

pvesm status

Vérifiez également les systèmes de fichiers :

lsblk -f

Pour ZFS :

zpool status
zfs list

Pour LVM :

pvs
vgs
lvs

Relever les machines virtuelles et conteneurs

qm list
pct list

Exportez les configurations :

mkdir -p /root/inventaire-pve-avant-migration/qemu
mkdir -p /root/inventaire-pve-avant-migration/lxc
cp -a \
  /etc/pve/qemu-server/. \
  /root/inventaire-pve-avant-migration/qemu/
cp -a \
  /etc/pve/lxc/. \
  /root/inventaire-pve-avant-migration/lxc/

Étape 2 : inventorier les composants particuliers

Recherchez les éléments susceptibles de compliquer la migration :

  • cartes réseau utilisant un module spécifique ;
  • cartes HBA ;
  • passthrough PCIe ;
  • GPU passthrough ;
  • périphériques USB attachés aux VM ;
  • modules DKMS ;
  • pilotes propriétaires ;
  • dépôts tiers ;
  • paquets installés manuellement ;
  • scripts de hooks ;
  • sauvegardes personnalisées ;
  • supervision ;
  • outils d’arrêt d’onduleur ;
  • montages NFS ou CIFS ;
  • stockage iSCSI ;
  • SDN ;
  • règles nftables ou iptables personnalisées.

Rechercher les modules DKMS

dkms status

Rechercher les dépôts

grep -R --line-number --no-messages \
  -E '^[[:space:]]*deb|^Types:' \
  /etc/apt/sources.list \
  /etc/apt/sources.list.d/

Rechercher les paquets non officiels

Un premier contrôle peut être réalisé avec :

apt-mark showmanual \
  > /root/paquets-manuels-avant-migration.txt

Cette liste contient aussi des paquets légitimes. Elle sert de base d’analyse, pas de preuve qu’un paquet est problématique.

Rechercher les scripts associés aux invités

grep -R --line-number \
  'hookscript' \
  /etc/pve/qemu-server \
  /etc/pve/lxc \
  2>/dev/null

Étape 3 : vérifier la santé générale

Une migration ne doit pas être lancée sur une infrastructure déjà dégradée.

Espace disque

df -h
df -i

Contrôlez particulièrement :

  • / ;
  • /boot ou la partition EFI ;
  • /var ;
  • le stockage local ;
  • les volumes temporaires ;
  • l’espace utilisé par les sauvegardes.

État des services

systemctl --failed

Journaux récents

journalctl \
  --priority=err \
  --since='7 days ago'

État du cluster

Pour un cluster :

pvecm status

Vérifiez :

  • les nœuds présents ;
  • le quorum ;
  • les liens Corosync ;
  • les erreurs ;
  • les nœuds hors ligne.

Réplication

pvesr status

Haute disponibilité

ha-manager status

Ceph

ceph status

Une migration ne doit pas commencer avec un cluster Ceph dégradé sans analyse précise de la cause.

Étape 4 : mettre Proxmox VE 8.4 à jour

Avant de migrer vers la branche 9, l’installation doit utiliser les derniers paquets de la branche 8.4.

Mettez à jour l’index :

apt update

Appliquez les mises à jour selon la procédure habituelle Proxmox :

apt full-upgrade

Redémarrez si nécessaire :

reboot

Après reconnexion :

pveversion --verbose
systemctl --failed
pvecm status

pour un cluster.

Étape 5 : vérifier les sauvegardes

Une sauvegarde doit se trouver hors de l’hôte

Une sauvegarde stockée uniquement sur le serveur à migrer ne suffit pas.

Privilégiez :

  • Proxmox Backup Server sur une autre machine ;
  • stockage NFS externe ;
  • stockage objet compatible avec votre stratégie ;
  • disque externe déconnecté après sauvegarde ;
  • copie vers un site distant.

Vérifier les dernières tâches

Dans l’interface Proxmox, contrôlez :

  • date ;
  • statut ;
  • durée ;
  • taille ;
  • erreurs ;
  • rétention.

En ligne de commande, consultez les tâches et journaux selon votre environnement.

Tester une restauration

Restaurez au minimum :

  • une petite VM ;
  • un conteneur LXC ;
  • un fichier via la restauration granulaire, si utilisée.

Le test doit être réalisé dans un emplacement isolé :

  • avec un nouvel identifiant ;
  • sans démarrage automatique sur le réseau de production ;
  • avec une adresse IP différente ;
  • sans conflit de nom ;
  • avec un réseau de laboratoire si possible.

Vérifier les dépendances externes

Une VM restaurée peut dépendre :

  • d’un contrôleur de domaine ;
  • d’un serveur DNS ;
  • d’une base de données ;
  • d’un stockage réseau ;
  • d’une licence ;
  • d’un dongle ;
  • d’une adresse MAC ;
  • d’une règle de pare-feu.

Le test doit vérifier que la sauvegarde est exploitable, pas seulement que la tâche se termine.

Étape 6 : sauvegarder les configurations essentielles

Conservez une copie sécurisée de :

/etc/pve
/etc/network/interfaces
/etc/network/interfaces.d
/etc/hosts
/etc/hostname
/etc/resolv.conf
/etc/apt
/etc/modprobe.d
/etc/modules
/etc/default
/etc/systemd/system
/root

Une archive peut être créée ainsi :

tar \
  --create \
  --gzip \
  --file /root/configuration-pve-avant-migration.tar.gz \
  /etc/pve \
  /etc/network/interfaces \
  /etc/network/interfaces.d \
  /etc/hosts \
  /etc/hostname \
  /etc/resolv.conf \
  /etc/apt \
  /etc/modprobe.d \
  /etc/modules \
  /etc/default \
  /etc/systemd/system \
  /root

La commande peut produire des avertissements si un fichier n’existe pas ou change pendant la lecture.

Copiez ensuite cette archive vers un stockage externe.

Étape 7 : préparer un accès console

La migration peut interrompre :

  • le bridge réseau ;
  • SSH ;
  • l’interface web ;
  • une carte réseau ;
  • le démarrage.

Prévoyez un accès indépendant :

  • écran et clavier ;
  • IPMI ;
  • iDRAC ;
  • iLO ;
  • KVM distant ;
  • console série ;
  • intervention d’une personne sur site.

Vérifiez avant l’opération :

  • que le compte fonctionne ;
  • que l’affichage de la console est accessible ;
  • que le clavier est utilisable ;
  • que le serveur peut être redémarré ;
  • que la séquence de démarrage est visible ;
  • que les identifiants ne sont pas uniquement stockés dans une VM hébergée sur le serveur.

Étape 8 : exécuter pve8to9

Proxmox fournit un outil de contrôle dans les derniers paquets Proxmox VE 8.4 :

pve8to9

Commencez par vérifier sa disponibilité :

command -v pve8to9

Exécutez le contrôle :

pve8to9

La documentation officielle peut recommander une option de contrôle complet. Consultez l’aide :

pve8to9 --help

Traitez chaque avertissement.

L’outil peut notamment signaler :

  • une version trop ancienne ;
  • des dépôts incorrects ;
  • des paquets problématiques ;
  • des configurations incompatibles ;
  • des paramètres supprimés ou modifiés ;
  • des conditions propres au cluster ;
  • des problèmes de stockage ;
  • des éléments à corriger avant le redémarrage.

Conservez le résultat :

pve8to9 \
  > /root/pve8to9-avant-migration.txt \
  2>&1

Étape 9 : étudier les changements de Debian 13 et Proxmox VE 9

Le passage à Proxmox VE 9 implique également une migration de Debian 12 vers Debian 13.

Avant de modifier les dépôts, relisez :

  • le guide Proxmox ;
  • les problèmes connus ;
  • les notes de version ;
  • les changements réseau ;
  • les changements de paquets ;
  • les dépendances tierces ;
  • les évolutions de QEMU et LXC ;
  • les évolutions de ZFS ;
  • les modifications des règles de sécurité.

Dépôts tiers

Pour chaque dépôt tiers :

  1. vérifiez l’existence d’une branche Debian 13 ;
  2. confirmez sa compatibilité avec Proxmox VE 9 ;
  3. désactivez-le temporairement si la procédure officielle le recommande ;
  4. ne le réactivez qu’après validation.

Modules externes

Vérifiez si les modules DKMS ou pilotes particuliers peuvent être reconstruits pour le nouveau noyau.

Passthrough

Documentez :

  • identifiants PCI ;
  • groupes IOMMU ;
  • paramètres du noyau ;
  • modules liés au VFIO ;
  • fichiers de configuration ;
  • ROM personnalisées ;
  • dépendances des VM.

Une évolution du noyau peut modifier le comportement de certains périphériques.

Cas particulier : Ceph Reef

Pour un cluster Proxmox VE 8.4 utilisant Ceph Reef, Proxmox demande de migrer Ceph vers Squid avant Proxmox VE.

La séquence générale est :

Proxmox VE 8.4 + Ceph Reef
              │
              ▼
Proxmox VE 8.4 + Ceph Squid
              │
              ▼
Proxmox VE 9.2 + Ceph Squid

Une évolution supplémentaire de Ceph pourra ensuite être envisagée si elle est prise en charge et nécessaire.

Avant la migration Ceph :

  • vérifiez que le cluster est sain ;
  • lisez les notes de version amont ;
  • contrôlez la capacité ;
  • vérifiez les versions des moniteurs, managers et OSD ;
  • planifiez l’ordre des nœuds ;
  • surveillez le rééquilibrage ;
  • ne poursuivez pas si le cluster devient dégradé sans comprendre pourquoi.

L’article ne détaille volontairement pas toutes les commandes Ceph. La procédure doit être suivie depuis la documentation officielle, ligne par ligne.

Étape 10 : définir la fenêtre de maintenance

Hôte unique

Prévoyez :

  • arrêt des services ;
  • arrêt propre des VM ;
  • sauvegarde finale ;
  • mise à niveau ;
  • redémarrage ;
  • contrôles ;
  • redémarrage progressif des invités ;
  • marge en cas de retour arrière.

Cluster

Définissez :

  • l’ordre des nœuds ;
  • les migrations de VM ;
  • la capacité nécessaire sur les autres nœuds ;
  • le comportement de la haute disponibilité ;
  • le quorum ;
  • les périodes de versions mixtes autorisées ;
  • les contrôles après chaque nœud.

Communication

Informez les utilisateurs :

  • de l’heure de début ;
  • des services indisponibles ;
  • de la durée estimée ;
  • du canal d’information ;
  • de la personne responsable ;
  • du moment de reprise.

N’annoncez pas une durée trop optimiste.

Étape 11 : modifier les dépôts et lancer la migration

La migration consiste notamment à :

  • remplacer les dépôts Debian 12 par les dépôts Debian 13 ;
  • utiliser les dépôts Proxmox VE 9 adaptés ;
  • mettre à jour les index ;
  • exécuter une mise à niveau complète ;
  • répondre aux questions concernant les fichiers de configuration ;
  • corriger les erreurs éventuelles ;
  • relancer pve8to9 ;
  • redémarrer.

Avant toute modification :

cp -a \
  /etc/apt \
  /root/apt-avant-migration

Après modification selon le guide officiel :

apt update

Examinez attentivement les erreurs.

N’ignorez pas :

  • un dépôt sans fichier Release ;
  • une signature invalide ;
  • un paquet conservé ;
  • un conflit ;
  • une tentative de suppression du méta-paquet Proxmox ;
  • un paquet tiers incompatible.

Lancez ensuite la commande de mise à niveau indiquée dans le guide officiel.

La procédure actuelle utilise une mise à niveau complète du système. Avant de valider, examinez la liste :

  • paquets installés ;
  • paquets supprimés ;
  • paquets conservés ;
  • nouveaux noyaux ;
  • changements de bootloader.

Pendant les questions sur les fichiers de configuration :

  • comparez les versions ;
  • ne remplacez pas automatiquement une configuration réseau personnalisée ;
  • conservez une copie ;
  • notez les choix effectués.

Étape 12 : relancer les contrôles avant redémarrage

Lorsque la mise à niveau se termine correctement :

pve8to9

Vérifiez également :

systemctl --failed
pveversion --verbose
df -h
ip -br address
ip route

Assurez-vous que :

  • le noyau Proxmox VE 9 est installé ;
  • le bootloader est correctement configuré ;
  • aucun paquet critique n’est cassé ;
  • le réseau correspond toujours à la configuration attendue ;
  • les systèmes de fichiers ne sont pas pleins ;
  • les services n’affichent pas d’erreur bloquante.

Étape 13 : redémarrer

Lorsque les contrôles sont satisfaisants :

reboot

Suivez le démarrage depuis la console indépendante.

Observez :

  • le choix du noyau ;
  • les erreurs du bootloader ;
  • l’initialisation des interfaces réseau ;
  • le montage des stockages ;
  • les erreurs de modules ;
  • l’arrivée de l’invite de connexion.

Étape 14 : contrôles après redémarrage

Version et noyau

pveversion --verbose
uname -a

Services en échec

systemctl --failed

Journaux du démarrage

journalctl \
  --boot \
  --priority=err

Réseau

ip -br address
ip route

Testez :

  • interface web ;
  • SSH ;
  • DNS ;
  • passerelle ;
  • VLAN ;
  • bond ;
  • bridges ;
  • accès aux stockages.

Stockage

pvesm status

Pour ZFS :

zpool status

Pour un cluster Ceph :

ceph status

Cluster

pvecm status

Haute disponibilité

ha-manager status

Réplication

pvesr status

Machines virtuelles

qm list

Démarrez progressivement les VM.

Pour chaque service critique, vérifiez :

  • démarrage ;
  • réseau ;
  • disque ;
  • heure ;
  • agent invité ;
  • application ;
  • sauvegarde ;
  • supervision.

Conteneurs

pct list

Contrôlez particulièrement les conteneurs anciens ou personnalisés.

Étape 15 : tester les fonctions d’administration

Vérifiez :

  • création d’un snapshot de test ;
  • console noVNC ou SPICE ;
  • migration entre nœuds ;
  • sauvegarde ;
  • restauration ;
  • réplication ;
  • ajout de stockage ;
  • accès aux journaux ;
  • métriques ;
  • notifications ;
  • arrêt et démarrage d’une VM ;
  • arrêt et démarrage d’un conteneur.

Pour un cluster, ne passez pas au nœud suivant tant que le précédent n’est pas stable.

Que faire en cas de problème réseau ?

Utiliser la console

Connectez-vous avec l’accès hors bande préparé avant l’intervention.

Vérifier les interfaces

ip -br link
ip -br address

Vérifier les noms d’interfaces

ls /sys/class/net

Comparez avec :

cat /etc/network/interfaces

Vérifier les journaux

journalctl \
  --boot \
  -u networking
journalctl \
  --boot |
  grep -i -E 'network|bridge|bond|vlan|link'

Appliquer prudemment

Proxmox utilise couramment ifupdown2.

Vérifiez la syntaxe et l’impact avant de recharger une configuration distante.

Ne redémarrez pas aveuglément le réseau si cela peut couper le seul accès disponible.

Que faire si l’interface web ne répond plus ?

Vérifiez les services :

systemctl status pveproxy
systemctl status pvedaemon
systemctl status pvestatd

Consultez les journaux :

journalctl \
  --boot \
  -u pveproxy

Vérifiez l’écoute du port :

ss -lntp |
  grep 8006

Vérifiez :

  • DNS local ;
  • /etc/hosts ;
  • nom d’hôte ;
  • certificats ;
  • heure système ;
  • espace disque ;
  • résolution du nom du nœud.

Que faire si une VM ne démarre plus ?

Affichez sa configuration :

qm config ID_VM

Tentez le démarrage et relevez l’erreur :

qm start ID_VM

Consultez :

  • stockage ;
  • périphériques PCI ;
  • disques ;
  • firmware ;
  • machine type ;
  • réseau ;
  • hooks ;
  • journaux.

Pour un périphérique en passthrough :

lspci -nnk

Vérifiez les groupes IOMMU et les modules VFIO.

N’altérez pas simultanément plusieurs paramètres. Changez un élément, testez, puis documentez.

Le plan de retour arrière

Une migration majeure en place n’est pas toujours réversible avec une simple commande.

Le plan de retour doit donc reposer sur :

  • sauvegardes externes vérifiées ;
  • média d’installation ;
  • configurations exportées ;
  • inventaire matériel ;
  • accès console ;
  • procédure de réinstallation ;
  • ordre de restauration ;
  • identifiants hors ligne ;
  • DNS et réseau documentés.

Hôte unique

Le scénario de repli réaliste peut être :

  1. réinstaller une version compatible ;
  2. restaurer la configuration nécessaire ;
  3. reconnecter le stockage ;
  4. restaurer les VM et conteneurs ;
  5. vérifier les services.

Cette procédure peut prendre plusieurs heures.

Cluster

Selon l’incident :

  • ne migrez pas les autres nœuds ;
  • conservez les charges sur les nœuds sains ;
  • analysez le nœud en erreur ;
  • restaurez-le si nécessaire ;
  • vérifiez le quorum et les versions prises en charge.

Les erreurs les plus fréquentes

Modifier les dépôts sans mettre la branche 8 à jour

L’outil de contrôle et les scripts de migration peuvent ne pas être à jour.

Ne pas lire pve8to9

Les avertissements sont parfois ignorés parce que le serveur semble fonctionner.

Conserver des dépôts tiers actifs

Ils peuvent fournir des paquets incompatibles avec Debian 13.

Migrer avec un stockage dégradé

Une reconstruction ou un pool en erreur réduit fortement la marge de sécurité.

Ne pas tester de restauration

Une sauvegarde verte dans l’interface peut rester inexploitable pour un besoin précis.

Dépendre uniquement de SSH

Une erreur réseau peut couper l’accès au milieu de l’intervention.

Oublier Ceph

Ceph Reef doit être traité selon la séquence officielle avant le passage à Proxmox VE 9.

Tout migrer en une seule nuit

Pour un cluster, avancez nœud par nœud et validez chaque étape.

Confondre snapshot et sauvegarde

Un snapshot sur le même stockage ne protège pas contre une panne ou une erreur affectant l’hôte.

Checklist avant migration

  • ☐ Tous les nœuds utilisent la dernière version de Proxmox VE 8.4.
  • ☐ pve8to9 a été exécuté.
  • ☐ Les avertissements ont été analysés.
  • ☐ Les dépôts tiers sont inventoriés.
  • ☐ Les modules DKMS sont inventoriés.
  • ☐ Le réseau est documenté.
  • ☐ Le stockage est sain.
  • ☐ Le cluster possède le quorum.
  • ☐ Ceph est sain et utilise une version prise en charge.
  • ☐ Les sauvegardes sont hors de l’hôte.
  • ☐ Une VM a été restaurée.
  • ☐ Un conteneur a été restauré.
  • ☐ Les configurations sont exportées.
  • ☐ L’accès console a été testé.
  • ☐ La fenêtre de maintenance est validée.
  • ☐ Le plan de retour est écrit.
  • ☐ Les utilisateurs sont informés.
  • ☐ Les commandes sont comparées au guide officiel à jour.

Checklist après migration

  • ☐ Proxmox VE 9.2 ou une version ultérieure stable est installée.
  • ☐ Le nouveau noyau est actif.
  • ☐ Aucun service critique n’est en échec.
  • ☐ L’interface web fonctionne.
  • ☐ SSH fonctionne.
  • ☐ Les bridges, VLAN et bonds fonctionnent.
  • ☐ Tous les stockages sont disponibles.
  • ☐ ZFS ou Ceph est sain.
  • ☐ Le cluster possède le quorum.
  • ☐ La haute disponibilité fonctionne.
  • ☐ La réplication fonctionne.
  • ☐ Les VM critiques démarrent.
  • ☐ Les conteneurs critiques démarrent.
  • ☐ Le passthrough fonctionne.
  • ☐ La supervision remonte les données.
  • ☐ Une nouvelle sauvegarde a réussi.
  • ☐ Une restauration après migration a été testée.
  • ☐ La documentation est mise à jour.

Conclusion

La fin du support de Proxmox VE 8.4 en août 2026 ne doit pas provoquer une migration précipitée.

Elle doit déclencher une préparation sérieuse.

Une bonne migration repose sur :

  • un inventaire fiable ;
  • une branche 8.4 entièrement mise à jour ;
  • l’outil pve8to9 ;
  • des sauvegardes externes ;
  • un test de restauration ;
  • un accès console ;
  • une analyse des dépôts et pilotes tiers ;
  • une procédure adaptée à l’hôte unique, au cluster ou à Ceph ;
  • des contrôles après chaque étape ;
  • un plan de retour réaliste.

Pour une petite entreprise, la plateforme de virtualisation concentre souvent une grande partie du système d’information. Quelques heures consacrées à préparer la migration peuvent éviter plusieurs jours d’interruption.

L’objectif n’est pas seulement d’obtenir une interface affichant « Proxmox VE 9.2 ».

L’objectif est de confirmer que :

  • les VM fonctionnent ;
  • les sauvegardes fonctionnent ;
  • le réseau fonctionne ;
  • le stockage est sain ;
  • l’administration reste disponible ;
  • la reprise est toujours possible.

Besoin de préparer votre migration Proxmox ?

AGE-Info accompagne les TPE et PME dans la maintenance et l’évolution de leurs infrastructures virtualisées.

Nous pouvons notamment :

  • inventorier les nœuds et les machines virtuelles ;
  • vérifier l’état du stockage ;
  • contrôler les sauvegardes ;
  • tester une restauration ;
  • analyser les résultats de pve8to9 ;
  • préparer la fenêtre de maintenance ;
  • accompagner la migration ;
  • contrôler les services après redémarrage ;
  • documenter le plan de reprise.