Mise à niveau et migration Proxmox : guide pratique de mise en œuvre

Introduction

La mise à niveau de Proxmox Virtual Environment (VE) et la migration des charges de travail entre nœuds sont des opérations courantes, mais à haut risque. Une erreur peut entraîner l'arrêt de plusieurs machines virtuelles, corrompre le stockage ou laisser un cluster dans un état de split-brain. Ce guide propose une approche pratique, basée sur des commandes, destinée aux développeurs, consultants DevOps et équipes techniques de startups qui doivent réaliser des mises à niveau et des migrations Proxmox en toute sécurité.

Nous mettons l'accent sur la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des valeurs génériques plutôt que des secrets, vérifier les résultats et documenter les procédures de reprise. Chaque étape majeure inclut des commandes concrètes, les sorties attendues et les signaux d'échec. Ce guide couvre Proxmox VE 8.x, la version stable actuelle au moment de la rédaction, mais les principes s'appliquent aux versions antérieures.

Inventaire de la version et de l'environnement

Avant toute intervention, vous devez savoir exactement ce que vous exécutez. Commencez par recueillir les informations de version et la topologie du déploiement à l'aide de commandes en lecture seule. Cela établit une base de référence et aide à identifier les problèmes de compatibilité.

Vérifier la version de Proxmox VE

Exécutez la commande suivante sur chaque nœud :

pveversion

Exemple de sortie attendue :

pve-manager/8.1.4/6b6e2a6d (running kernel: 6.5.11-7-pve)

Cela indique la version du gestionnaire Proxmox VE, le noyau et un hachage de build. Notez la version du noyau, car certaines mises à niveau nécessitent un redémarrage pour utiliser un nouveau noyau.

Vérifier l'état du cluster

Si vous êtes dans un cluster, assurez-vous qu'il est sain avant toute modification :

pvecm status

Recherchez un quorum et aucun nœud marqué hors ligne. La sortie attendue inclut :

Quorum information
------------------
Date:             Mon Jan  1 12:00:00 2024
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.abc
Quorate:          Yes

Si Quorate est No, arrêtez-vous et corrigez le cluster avant de continuer.

Lister les machines virtuelles et conteneurs en cours d'exécution

Vous devez savoir ce qui tourne sur le nœud que vous prévoyez de modifier.

qm list

Pour les conteneurs :

pct list

Les deux commandes affichent les identifiants, noms, statuts et allocations de ressources. Notez cette liste ; vous l'utiliserez pour vérifier que tout revient après l'opération.

Vérifier la santé du stockage

Proxmox utilise des plugins de stockage comme LVM, ZFS, Ceph ou NFS. Vérifiez l'état de vos backends de stockage :

pvesm status

La sortie attendue montre chaque stockage avec son type, son statut et son utilisation. Si un stockage n'est pas active, investiguez avant de poursuivre.

Pour les pools ZFS :

zpool status

Pour Ceph :

ceph -s

Identifier précisément le composant à inspecter

Ne mettez pas tout à niveau en une seule fois. Choisissez un nœud à la fois, ou un composant, et limitez la portée du changement. Par exemple, si vous mettez à niveau Proxmox VE de la version 7.x vers 8.x, ne modifiez pas simultanément la configuration du stockage ou les paramètres réseau.

Chemin de configuration sûr

Un chemin de configuration sûr s'appuie sur l'inventaire. Cela signifie apporter le plus petit changement justifié, le vérifier et disposer d'un plan de restauration.

Configuration des dépôts

Les mises à niveau de Proxmox dépendent des dépôts apt. Assurez-vous que vos sources sont correctes. Pour Proxmox VE 8.x, le dépôt enterprise est désactivé par défaut si vous n'avez pas d'abonnement. Le dépôt no-subscription est couramment utilisé pour les tests et les homelabs.

Vérifiez votre configuration actuelle des dépôts :

grep -r "" /etc/apt/sources.list /etc/apt/sources.list.d/

Pour une configuration Proxmox VE 8.x correcte sans abonnement, vous devez avoir un fichier comme /etc/apt/sources.list.d/pve-no-subscription.list contenant :

deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Si vous utilisez le dépôt enterprise, il doit pointer vers :

deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Important : mélanger les dépôts enterprise et no-subscription peut provoquer des conflits de versions. La voie sûre consiste à utiliser l'un ou l'autre. Si vous avez un abonnement actif, utilisez enterprise ; sinon, utilisez no-subscription.

Contrôles de santé avant mise à niveau

Avant la mise à niveau, effectuez une mise à jour complète des paquets :

apt update
apt list --upgradable

Passez en revue la liste. Faites attention aux paquets qui pourraient casser la compatibilité, tels que le noyau, QEMU ou les composants Ceph.

Vérifiez également l'espace disque sur le système de fichiers racine :

df -h /

Assurez-vous d'avoir au moins 5 Go d'espace libre. Une mise à niveau qui manque d'espace peut laisser le système dans un état incohérent.

Sauvegarder la configuration critique

Sauvegardez vos fichiers de configuration avant de les modifier. Par exemple, sauvegardez le répertoire de configuration de Proxmox VE :

tar czf /root/pve-config-backup-$(date +%Y%m%d).tar.gz /etc/pve /etc/apt/sources.list /etc/apt/sources.list.d

Cette archive inclut la configuration du cluster, les définitions de stockage et les paramètres des dépôts. Stockez-la dans un endroit sûr, de préférence hors du nœud.

Effectuer la mise à niveau

Pour mettre à niveau Proxmox VE lui-même, utilisez :

apt dist-upgrade

Pendant la mise à niveau, surveillez les invites concernant les fichiers de configuration. Si une nouvelle version d'un fichier de configuration est disponible, Proxmox recommande généralement de conserver l'existant. Choisissez N ou keep the local version sauf si vous avez une raison spécifique.

Après la mise à niveau, vérifiez si un redémarrage est nécessaire. Proxmox peut installer un nouveau noyau. Vous pouvez vérifier le noyau en cours d'exécution et les paquets de noyau installés :

uname -r

dpkg --list | grep pve-kernel

Si le noyau en cours est plus ancien que le dernier pve-kernel installé, prévoyez un redémarrage pendant une fenêtre de maintenance.

Vérification et diagnostics

Après toute modification, vous devez vérifier que le système est dans l'état attendu. La vérification doit être précise et automatisée lorsque c'est possible.

Vérification après mise à niveau

Après une mise à niveau de Proxmox, exécutez :

pveversion

Confirmez que la nouvelle version correspond à votre cible. Par exemple, une mise à niveau de 7.4 vers 8.1 doit afficher pve-manager/8.1.x.

Vérifiez à nouveau l'état du cluster :

pvecm status

Assurez-vous que tous les nœuds sont en ligne et que le quorum est intact.

Vérifiez que toutes les VM et conteneurs sont en cours d'exécution :

qm list
pct list

Comparez la sortie à votre inventaire d'avant mise à niveau. Si une VM est arrêtée, recherchez pourquoi.

Consultez les journaux système pour les erreurs au démarrage et au lancement des services :

journalctl -b -p err

Recherchez les messages liés au stockage, au réseau ou aux services Proxmox comme pvedaemon, pveproxy ou pvestatd.

Valider le stockage et les sauvegardes

Si vous utilisez ZFS, vérifiez l'état du pool :

zpool status -v

Cela montre les périphériques dégradés ou en panne. Pour Ceph, exécutez :

ceph -s

Confirmez que le cluster est sain (HEALTH_OK).

Testez que les sauvegardes fonctionnent toujours. Vous pouvez créer une sauvegarde manuelle d'une petite VM de test :

vzdump 100 --mode snapshot --compress zstd --storage local

Remplacez 100 par l'ID d'une VM non critique. Cela prouve que le sous-système de sauvegarde et le stockage sont fonctionnels.

Commandes de diagnostic pour les problèmes courants

Si quelque chose ne va pas, voici quelques commandes de diagnostic :

• Vérifier le statut des services Proxmox :

systemctl status pvedaemon pveproxy pvestatd

• Examiner le journal des tâches Proxmox :

cat /var/log/pve/tasks/active

• Afficher les messages du noyau :

dmesg | tail -50

• Vérifier la configuration réseau :

ip addr show

cat /etc/network/interfaces

Ces commandes aident à isoler si une défaillance est due à un service, au noyau ou à la configuration.

Planification et exécution de la migration

La migration dans Proxmox peut signifier déplacer une VM ou un conteneur d'un nœud à un autre au sein d'un cluster, ou déplacer les données d'un nœud autonome vers un nouveau matériel. Cette section couvre la migration à chaud au sein d'un cluster et la migration hors ligne pour les configurations autonomes.

Migration à chaud au sein d'un cluster

La migration à chaud déplace une VM en cours d'exécution avec un temps d'arrêt minimal. Elle nécessite un stockage partagé ou un stockage local avec réplication. Pour cet exemple, nous supposons un cluster à deux nœuds avec réplication ZFS.

Tout d'abord, assurez-vous que la VM est répliquée :

pve-zsync list

Ou vérifiez les tâches de réplication dans l'interface graphique. La VM doit avoir une tâche de réplication configurée.

Pour migrer la VM 100 du nœud A vers le nœud B :

qm migrate 100 nodeB --online

Surveillez la progression de la migration :

qm status 100 --verbose

Après la migration, la VM doit apparaître comme en cours d'exécution sur le nœud B. Vérifiez en exécutant qm list sur le nœud B.

La migration peut échouer s'il n'y a pas assez de mémoire ou si les types de CPU diffèrent considérablement. Pour atténuer cela, définissez le type de CPU de la VM sur kvm64 avant la migration pour une compatibilité maximale.

Migration hors ligne pour les nœuds autonomes

Si vous déplacez d'un nœud Proxmox autonome à un autre sans stockage partagé, vous devez sauvegarder et restaurer.

1. Créez une sauvegarde de la VM :

vzdump 100 --mode stop --compress zstd --storage /mnt/backup

1. Copiez le fichier de sauvegarde vers le nouveau nœud en utilisant scp ou une clé USB.

1. Sur le nouveau nœud, restaurez la sauvegarde :

qmrestore /mnt/backup/vzdump-qemu-100-2024_01_01-12_00_00.vma.zst 100

1. Démarrez la VM et vérifiez son réseau et ses services.

Cette méthode entraîne un temps d'arrêt égal au temps de sauvegarde et de restauration. Pour les VM critiques, planifiez en conséquence.

Migration de stockage

Proxmox permet également de déplacer le disque d'une VM d'un stockage à un autre pendant que la VM est en cours d'exécution (si le stockage le prend en charge). Par exemple, pour déplacer le disque de la VM 100 de local-lvm vers ceph-pool :

qm move-disk 100 scsi0 ceph-pool --delete

L'option --delete supprime le disque d'origine après une copie réussie. Sans elle, l'original est conservé, ce qui est une bonne mesure de sécurité.

Surveillez la progression de la migration du disque avec :

qm status 100 --verbose

Recherchez la section disk pour voir le stockage et la taille.

Modes d'échec et récupération

Malgré les meilleures pratiques, des échecs surviennent. Cette section décrit les modes d'échec courants et les étapes de récupération.

Échec de mise à niveau dû à un conflit de paquets

Symptôme : apt dist-upgrade échoue avec des erreurs de dépendance ou dpkg renvoie un code d'erreur.

Récupération :

• Exécutez apt -f install pour corriger les dépendances cassées.
• Si cela échoue, consultez /var/log/apt/term.log et /var/log/dpkg.log pour le paquet spécifique.
• Vous devrez peut-être supprimer ou geler un paquet problématique. Par exemple :

apt remove problematic-package

• Après correction, relancez apt dist-upgrade.

Panique du noyau après redémarrage

Symptôme : Après la mise à niveau et le redémarrage, le nœud ne démarre pas, affichant une panique du noyau ou se bloquant.

Récupération :

• Redémarrez et sélectionnez le noyau précédent dans le menu GRUB (Options avancées pour Proxmox VE).
• Une fois démarré avec l'ancien noyau, figez le bon noyau et supprimez le problématique :

proxmox-boot-tool kernel pin 5.15.107-2-pve

• Vous pouvez également supprimer le mauvais noyau avec apt remove pve-kernel-<version>.
• Recherchez la cause avant de retenter la mise à niveau.

Échec de migration dû au réseau ou au stockage

Symptôme : qm migrate échoue avec un délai d'attente ou une erreur d'E/S.

Récupération :

• Vérifiez la connectivité réseau entre les nœuds :

ping -c 4 nodeB

• Vérifiez que le réseau de migration est configuré et non bloqué par un pare-feu.
• Vérifiez la disponibilité du stockage sur les deux nœuds. Pour la réplication ZFS, assurez-vous que la cible de réplication a suffisamment d'espace et que le pool est sain.
• Si la VM est toujours en cours d'exécution sur le nœud source, vous pouvez réessayer après avoir corrigé le problème. Si la VM est dans un état indéfini, arrêtez-la sur le nœud source et démarrez-la manuellement sur la cible après vous être assuré que les données du disque sont cohérentes.

Configuration corrompue

Symptôme : Les services Proxmox ne démarrent pas en raison d'erreurs de configuration.

Récupération :

• Restaurez à partir de la sauvegarde de configuration que vous avez effectuée :

tar xzf /root/pve-config-backup-<date>.tar.gz -C /

• Redémarrez les services Proxmox :

systemctl restart pvedaemon pveproxy pvestatd

• Vérifiez avec pveversion et pvecm status.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant, pendant et après toute mise à niveau ou migration Proxmox. Chaque élément a un responsable et une fréquence de révision.

Attribuez un seul responsable pour chaque élément de la liste. Le responsable est chargé d'exécuter et de vérifier l'étape, et de faire remonter les problèmes si nécessaire. Passez en revue l'ensemble de la liste lors d'une réunion hebdomadaire des opérations.

Pièges courants et comment les éviter

1. Sauter la phase d'inventaire

Pourquoi cela arrive : Les équipes sont sous pression et veulent « simplement mettre à niveau ». Elles sautent la vérification des versions, de la santé du stockage ou du quorum du cluster.

Comment éviter : Faites de l'inventaire une étape obligatoire. Utilisez la liste de contrôle ci-dessus et exigez la validation du responsable avant de continuer.

Récupération si touché : Arrêtez immédiatement, documentez l'état actuel du mieux possible et restaurez à partir des sauvegardes si nécessaire.

2. Utiliser des dépôts mixtes

Pourquoi cela arrive : Quelqu'un active à la fois les dépôts enterprise et no-subscription, ou ajoute un dépôt Debian sans comprendre les conflits de dépendances.

Comment éviter : Utilisez un seul dépôt Proxmox par version majeure. Supprimez ou commentez les autres. Testez dans un environnement de staging si possible.

Récupération : Désactivez le dépôt en conflit, exécutez apt update, puis apt -f install, et envisagez de rétrograder des paquets spécifiques si nécessaire.

3. Espace disque insuffisant

Pourquoi cela arrive : Le système de fichiers racine se remplit pendant une grosse mise à niveau, provoquant l'échec de dpkg en cours d'installation.

Comment éviter : Avant la mise à niveau, vérifiez df -h / et nettoyez les anciens noyaux, journaux et paquets inutilisés. Gardez au moins 5 Go libres, plus si vous avez beaucoup de paquets.

Récupération : Démarrez en mode récupération ou utilisez un live CD pour libérer de l'espace. Ensuite, exécutez apt -f install pour terminer la mise à niveau. Si le système ne démarre pas, restaurez à partir de la sauvegarde.

4. Ne pas tester les sauvegardes avant la migration

Pourquoi cela arrive : Les équipes supposent que les sauvegardes fonctionnent parce qu'elles sont planifiées, mais ne restaurent jamais réellement.

Comment éviter : Effectuez une restauration de test d'une VM non critique avant la fenêtre de migration. Automatisez ce test périodiquement.

Récupération : Si vous découvrez que la sauvegarde est corrompue pendant la migration et que la source a disparu, vous risquez de perdre des données. Pour réduire le risque, prenez une nouvelle sauvegarde immédiatement avant la migration et vérifiez son intégrité avec vzdump --verify.

5. Ignorer la santé de la réplication pour la migration à chaud

Pourquoi cela arrive : La tâche de réplication échoue silencieusement, donc le nœud cible n'a pas de copie à jour du disque de la VM.

Comment éviter : Vérifiez l'état de la réplication avant de migrer. Exécutez pve-zsync list ou consultez l'interface graphique Proxmox pour les journaux de réplication. Assurez-vous que la dernière synchronisation est récente.

Récupération : Déclenchez manuellement une synchronisation de réplication ou utilisez la migration hors ligne si la réplication n'est pas fiable.

6. Ne pas avoir de plan de restauration

Pourquoi cela arrive : La confiance excessive ou le manque d'expérience conduit à l'absence de solution de repli.

Comment éviter : Définissez toujours un chemin de restauration avant d'apporter une modification. Pour les mises à niveau, sachez comment démarrer le noyau précédent. Pour la migration, sachez comment revenir au nœud d'origine. Documentez ces étapes dans un runbook.

Récupération : Si vous êtes bloqué sans plan, minimisez les dégâts en isolant le nœud affecté, restaurez à partir de la dernière sauvegarde et demandez l'aide d'un expert.

Conclusion

La mise à niveau et la migration Proxmox sont gérables lorsqu'elles sont abordées avec discipline : inventaire d'abord, changement minimal, vérification rigoureuse et toujours un chemin de récupération. Les commandes et listes de contrôle de ce guide vous donnent un cadre opérationnel concret.

Comme prochaine étape, prenez une action à faible risque : exécutez pveversion et pvecm status sur chacun de vos nœuds et enregistrez la sortie. Ensuite, passez en revue votre procédure de sauvegarde et de restauration avec une restauration de test. Cette simple pratique révélera les lacunes avant que vous ne tentiez une mise à niveau ou une migration majeure.

Un flux de travail technique fiable rend les échecs visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. Utilisez ce guide comme base opérationnelle et adaptez les détails à votre environnement.