## Introduction Exploiter Proxmox Virtual Environment (Proxmox VE) en production exige plus que de savoir créer une machine virtuelle. Cela demande une approche disciplinée pour observer l’état actuel, effectuer des changements minimaux et vérifier les résultats. Cet article fournit une liste de contrôle pratique des opérations pour les environnements de production Proxmox, destinée aux développeurs, aux consultants DevOps et aux équipes techniques de startups. Chaque section comprend des commandes concrètes, les sorties attendues, les signaux de défaillance et les étapes de reprise, le tout ancré dans des scénarios réels. Le principe fondamental est la sûreté opérationnelle : observer avant de modifier, limiter le rayon d’impact de toute intervention, utiliser des espaces réservés plutôt que de véritables identifiants, vérifier le résultat et documenter les chemins de reprise avant d’en avoir besoin. ## Inventaire des versions et de l’environnement Avant toute modification, vous devez avoir une image complète de votre environnement Proxmox. Cela inclut la version installée, la topologie du cluster, la configuration du stockage et les ressources matérielles ou virtuelles. Une commande en lecture seule depuis la CLI de Proxmox est le moyen le plus sûr de capturer ces informations. Commencez par identifier la version de Proxmox VE : pveversion Exemple de sortie attendue : pve-manager/7.4-3/9002ab8a (running kernel: 5.15.107-2-pve) Cela vous indique la version exacte et le noyau, ce qui est essentiel pour les vérifications de compatibilité et la documentation. Ensuite, vérifiez l’état du cluster (le cas échéant) : pvecm status Sortie attendue pour un nœud unique sain : Cluster information ------------------- Name: mycluster Config Version: 4 Transport: knet Secure auth: on Quorum information ------------------ Date: Mon Apr 15 10:30:00 2024 Quorum provider: corosync_votequorum Nodes: 1 Node ID: 0x00000001 Ring ID: 1.1a Quorate: Yes Pour un cluster à plusieurs nœuds, chaque nœud doit être listé avec son état et le quorum doit être « Yes ». Si le quorum est « No », le cluster n’est pas sain et les écritures sur le stockage partagé peuvent être bloquées. Vérifiez l’utilisation des ressources des nœuds et des invités : pvesh get /cluster/resources --output-format yaml Cet appel API renvoie une liste structurée de tous les nœuds, VM et stockages avec leur utilisation actuelle du CPU, de la mémoire et du disque. Analysez-la avec un script ou inspectez-la manuellement pour détecter les anomalies. Enfin, listez tous les stockages configurés : pvesm status La sortie attendue inclut le nom, le type, l’état et l’utilisation de chaque stockage. Tout stockage marqué « inactive » ou avec une utilisation élevée (plus de 85 %) nécessite une attention. ### Exemple pratique : vérification matinale de l’état de santé Chaque matin, un ingénieur d’exploitation désigné (par exemple, Priya Shah, responsable de l’infrastructure) exécute un script qui lance ces commandes et compare les sorties aux références attendues. L’ingénieur est responsable d’enquêter sur tout écart. Cette vérification est revue lors du stand-up quotidien et de la revue hebdomadaire des opérations. ## Chemin de configuration sécurisé Modifier la configuration de Proxmox peut affecter de nombreuses VM à la fois, la sécurité est donc primordiale. Le processus doit être : capturer l’état actuel, sauvegarder les fichiers pertinents, effectuer un changement limité, vérifier et savoir comment revenir en arrière. ### Exemple 1 : modification de la mémoire d’une VM Supposons que vous deviez augmenter la mémoire de la VM 100 de 4 Go à 8 Go. La VM exécute une application web critique. D’abord, observez la configuration actuelle : qm config 100 | grep memory Attendu : memory: 4096 Vérifiez l’utilisation actuelle de la RAM de la VM (depuis l’intérieur de l’invité ou via la surveillance Proxmox). Assurez-vous que l’hôte a suffisamment de mémoire libre. Ensuite, effectuez le changement : qm set 100 -memory 8192 Vérifiez immédiatement : qm config 100 | grep memory Attendu : memory: 8192 Remarque : pour une VM en cours d’exécution, le changement peut ne pas prendre effet avant un redémarrage, sauf si le ballonnement est activé. Vérifiez le pilote de ballonnement de la VM et redémarrez si nécessaire. Retour en arrière : remettez la mémoire à 4096 avec la même commande. ### Exemple 2 : ajout d’un nouvel utilisateur Création d’un nouvel utilisateur dans Proxmox avec des autorisations spécifiques : pveum useradd devops@pve --password 'SecurePlaceholder123!' --comment 'DevOps engineer' pveum aclmod /vms/100 -user devops@pve -role PVEVMUser Vérifiez : pveum user list pveum acl list Retour en arrière : supprimez l’utilisateur et l’ACL avec pveum userdel devops@pve . ### Précautions importantes - Sauvegardez toujours les fichiers de configuration avant de les modifier directement. Par exemple, avant d’éditer /etc/pve/storage.cfg , copiez-le : cp /etc/pve/storage.cfg /etc/pve/storage.cfg.bak-$(date +%Y%m%d) . - Utilisez la CLI officielle ou l’API plutôt que d’éditer manuellement les fichiers, quand c’est possible. - Testez les changements sur un nœud hors production ou dans un cluster de test d’abord. - Documentez le changement dans votre système de gestion des changements. ## Vérification et diagnostics La vérification n’est pas une étape ponctuelle ; elle doit être continue et intégrée aux opérations quotidiennes. Voici les diagnostics clés pour Proxmox en production. ### Journaux système Les journaux Proxmox sont essentiels pour le dépannage. Le fichier journal principal est /var/log/syslog . Vous pouvez aussi utiliser journalctl : journalctl -u pve-cluster -u pvedaemon -u pveproxy -u pvestatd --since "1 hour ago" Recherchez les erreurs comme « connection timed out », « storage is not online » ou « quorum lost ». ### Diagnostics réseau Vérifiez l’état des ponts réseau et des interfaces : ip addr show vmbr0 Attendu : l’interface est active avec une adresse IP. Sinon, les VM sur ce pont peuvent perdre la connectivité. Testez la connectivité vers un stockage critique ou un serveur de sauvegarde : ping -c 4 storage.example.com ### État et performance des VM Listez toutes les VM et leurs états : qm list Surveillez l’utilisation des ressources en direct : qm monitor 100 Dans le moniteur qm, tapez info block pour voir les statistiques de disque, info cpus pour les informations CPU et help pour plus de commandes. ### Santé du cluster (le cas échéant) Pour les clusters, vérifiez corosync et le quorum : corosync-quorumtool -s Attendu : « Quorate: Yes » et tous les nœuds listés. ### Vérification des sauvegardes Pour chaque tâche de sauvegarde, vérifiez qu’elle s’est terminée avec succès : cat /var/log/pve/tasks/active Ou vérifiez l’état de la sauvegarde dans l’interface graphique. Testez périodiquement les restaurations pour vous assurer que les sauvegardes sont valides. ## Modes de défaillance et reprise Comprendre les modes de défaillance courants et disposer de procédures de reprise prêtes est essentiel. ### Défaillance : perte de quorum dans le cluster Cause : partition réseau ou défaillance d’un nœud. Symptômes : les opérations du cluster échouent, les VM peuvent ne pas démarrer ou migrer, l’interface web peut afficher des erreurs. Reprise : - Identifiez quels nœuds peuvent encore se voir. - Connectez-vous à la console de chaque nœud et vérifiez l’état de corosync : systemctl status corosync . - Si un nœud est physiquement hors ligne, attendez qu’il récupère, ou retirez-le du cluster s’il est définitivement perdu : pvecm delnode (uniquement si vous avez le quorum sur les nœuds restants). - Regagnez le quorum : dans un cluster à deux nœuds, assurez-vous que le qdevice fonctionne. Vérifiez corosync-quorumtool . - Après avoir restauré le quorum, vérifiez la cohérence du cluster : pvecm status . ### Défaillance : stockage non disponible Cause : serveur NFS hors ligne, cible iSCSI inaccessible ou défaillance du disque local. Symptômes : les VM affichent des erreurs d’E/S, le stockage est marqué « inactive » dans pvesm status . Reprise : - Vérifiez la connectivité réseau vers le serveur de stockage : ping . - Vérifiez l’état du stockage : pvesm status . - Pour NFS, vérifiez les montages : mount | grep nfs . - Si le serveur NFS est de retour, Proxmox devrait se reconnecter ; sinon, montez manuellement : mount -a . - Pour un disque local, vérifiez les données SMART : smartctl -a /dev/sda (si installé). - Si le disque est défaillant, migrez les VM vers un autre stockage ou nœud. ### Défaillance : échec de la sauvegarde Cause : espace insuffisant, problème réseau ou problème de snapshot. Reprise : - Vérifiez le journal de sauvegarde : /var/log/pve/tasks/[UPID].log . - Vérifiez l’espace du stockage de destination : df -h sur le serveur de sauvegarde. - Si vous utilisez vzdump avec le mode snapshot et que le snapshot échoue, essayez le mode suspend ou stop. - Testez avec une sauvegarde manuelle : vzdump 100 --mode snapshot --storage backupstore . - Révisez les paramètres de rétention pour libérer de l’espace. ## Liste de contrôle des opérations Voici une liste de contrôle consolidée pour les opérations quotidiennes, hebdomadaires et mensuelles, avec les responsables et la fréquence de revue. Adaptez-la à votre environnement. ### Vérifications quotidiennes (Responsable : ingénieur d’astreinte, revue lors du stand-up quotidien) - [ ] Exécuter pveversion et comparer avec la version attendue. - [ ] Vérifier l’état du cluster avec pvecm status (si en cluster). - [ ] Exécuter pvesh get /cluster/resources et examiner l’utilisation élevée (>85 % sur toute ressource). - [ ] Vérifier l’état du stockage avec pvesm status . - [ ] Examiner les journaux système pour les erreurs : journalctl -p err -b . - [ ] Vérifier que toutes les VM critiques fonctionnent ( qm list ). - [ ] Vérifier que les tâches de sauvegarde se sont terminées avec succès. ### Vérifications hebdomadaires (Responsable : responsable de l’infrastructure, revue lors de la réunion hebdomadaire des opérations) - [ ] Examiner les tendances de performance (CPU, mémoire, E/S disque) pour les nœuds et les principales VM. - [ ] Vérifier la croissance de l’espace disque et planifier l’expansion. - [ ] Appliquer les correctifs de sécurité après test (voir Chemin de configuration sécurisé). - [ ] Valider l’intégrité des sauvegardes en restaurant une VM de test à partir de la dernière sauvegarde. - [ ] Examiner les comptes utilisateurs et les autorisations ( pveum user list , pveum acl list ). - [ ] Vérifier les alertes matérielles (IPMI, SMART). ### Vérifications mensuelles (Responsable : responsable de l’infrastructure, revue lors de la revue mensuelle d’architecture) - [ ] Effectuer une planification complète des capacités : projeter les besoins futurs basés sur les tendances. - [ ] Tester le plan de reprise après sinistre : simuler une défaillance de nœud et récupérer. - [ ] Examiner l’abonnement et le support Proxmox. - [ ] Documenter tout changement de configuration et mettre à jour les procédures. - [ ] Tester le basculement haute disponibilité si configuré : ha-manager status et ha-manager migrate . ## Pièges courants et comment les éviter ### 1. Ne pas documenter les références de base Pourquoi cela arrive : les équipes omettent d’enregistrer l’état normal, rendant impossible la détection des anomalies. Comment l’éviter : utilisez la liste de contrôle quotidienne pour capturer les métriques clés dans un système de surveillance (par exemple, Prometheus, Zabbix). Configurez des alertes pour les écarts. ### 2. Effectuer des changements sans tester sur un environnement hors production Pourquoi cela arrive : pression pour corriger rapidement les problèmes. Comment l’éviter : maintenez un cluster de test ou au moins un nœud de test. Documentez les résultats des tests avant d’appliquer les changements en production. ### 3. Ignorer la vérification des sauvegardes Pourquoi cela arrive : les sauvegardes sont configurées, mais les restaurations ne sont jamais testées. Comment l’éviter : planifiez des tests de restauration mensuels. Automatisez si possible. Rappelez-vous : une sauvegarde n’est valide que si vous pouvez restaurer à partir d’elle. ### 4. Utiliser des identifiants par défaut ou faibles Pourquoi cela arrive : la commodité. Comment l’éviter : imposez des mots de passe forts, l’authentification à deux facteurs pour l’accès web et utilisez des jetons API avec des autorisations limitées. ### 5. Négliger la santé du stockage Pourquoi cela arrive : on se concentre sur les VM, en oubliant le stockage sous-jacent. Comment l’éviter : surveillez les attributs SMART du stockage et l’utilisation du système de fichiers. Configurez des alertes pour une utilisation élevée ou un RAID dégradé. ### 6. Changements non contrôlés Pourquoi cela arrive : plusieurs administrateurs effectuent des changements sans coordination. Comment l’éviter : mettez en place un processus de gestion des changements avec approbations. Utilisez le journal des tâches de Proxmox pour suivre les changements ( /var/log/pve/tasks/index ). ## Conclusion Exploiter Proxmox VE en production exige une approche structurée des opérations. En utilisant des procédures spécifiques à la version, observables et réversibles, vous pouvez minimiser les temps d’arrêt et assurer la fiabilité. La liste de contrôle fournie ici est un point de départ ; adaptez-la aux besoins spécifiques de votre environnement. Commencez par une vérification à faible risque : exécutez la vérification matinale de l’état de santé demain. Enregistrez l’état actuel, comparez-le aux signaux attendus et examinez toute anomalie. À partir de là, élaborez la liste de contrôle complète et intégrez-la à la routine de votre équipe. Rappelez-vous : un flux de travail fiable rend les défaillances visibles, protège les informations sensibles, limite les changements à la portée prévue et définit la vérification de la reprise avant qu’un incident ne survienne. --- Remarque : toutes les commandes et sorties sont des exemples pour Proxmox VE 7.x. Reportez-vous toujours à la documentation officielle pour votre version spécifique.