Proxmox VE permet d'exécuter facilement des machines virtuelles KVM et des conteneurs LXC avec des fonctions robustes de stockage, de réseau, de sauvegarde et de clustering. Lorsqu'un problème survient, le message d'erreur peut paraître intimidant. Ce guide traduit les erreurs Proxmox les plus fréquentes en langage clair, explique pourquoi elles se produisent et montre des correctifs sûrs, étape par étape, que vous pouvez copier et adapter. Ce que vous obtiendrez : - Un workflow de dépannage sûr, reproductible même sous pression - Des commandes pratiques pour le stockage, le réseau, le clustering, Ceph et les sauvegardes - Un plan de validation en laboratoire avant d'intervenir en production Prérequis : - Accès shell au nœud en root ou via sudo - À l'aise avec l'outillage réseau et stockage basé sur Debian ## Vue d'ensemble du workflow Utilisez ce flux pour éviter les suppositions et réduire les reprises. - Capturer l'erreur exacte et les journaux - Depuis l'interface graphique : ouvrez le journal de la tâche où l'erreur est apparue. - Sur le nœud : journalctl -xe --no-pager | tail -n 200 cat /var/log/syslog | tail -n 200 cat /var/log/pveproxy/pveproxy.log | tail -n 200 cat /var/log/pvedaemon.log | tail -n 200 - Définir le périmètre - S'agit-il d'une seule VM/CT, d'un nœud, du stockage, du réseau, ou de l'ensemble du cluster/Ceph ? - Vérifier les bases d'abord df -h free -h timedatectl status systemctl is-active pveproxy pvedaemon pve-cluster corosync || true - S'assurer que l'heure est synchronisée et que le nœud n'est pas à court d'espace disque ou de mémoire. - Identité et DNS hostname -f cat /etc/hosts - Le nom court du nœud et son FQDN doivent résoudre vers l'IP de gestion correcte. - Vérifications de stockage (LVM, ZFS, répertoire, ou Ceph) pvesm status pvesm list lvs; vgs zpool status || true rbd ls --id || true - Vérifications réseau ip a ip r ss -lntp | egrep ':22|:8006|:590[0-9]{2}' bridge vlan show || true - Cluster et Corosync pvecm status systemctl status corosync journalctl -u corosync --since -1h --no-pager | tail -n 200 - Sauvegardes ls -lh /var/log/vzdump/ cat /etc/vzdump.conf - Appliquer le plus petit correctif sûr - Modifier une seule chose à la fois. Sauvegarder les fichiers de configuration avant toute édition. - Valider et documenter - Relancer la tâche en échec, capturer les métriques de succès (durée, débit) et noter le correctif appliqué. ## Erreurs courantes et correctifs Voici les motifs d'erreur Proxmox fréquents, leurs causes, comment les diagnostiquer et les remédiations sûres. ## 1) Message d'abonnement et configuration des dépôts Symptôme : l'interface graphique affiche une notification indiquant qu'aucun abonnement valide n'est détecté ou des erreurs apt pour les dépôts enterprise. Cause : le dépôt enterprise est activé par défaut, alors que vous utilisez peut-être le dépôt no-subscription. Correctif sûr : # Désactiver le dépôt enterprise sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list 2>/dev/null || true # Activer le dépôt no-subscription (exemple Debian 12) cat >/etc/apt/sources.list.d/pve-no-subscription.list <<'EOF' deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription EOF apt update apt dist-upgrade -y Validation : apt policy | egrep 'proxmox|pve' | head ## 2) Cluster non prêt, pas de quorum Symptôme : les tâches échouent avec des erreurs de quorum ; l'interface graphique affiche "Cluster not ready" ; pvecm status indique l'absence de quorum. Cause : Corosync ne peut pas joindre les pairs, l'heure est décalée, ou il n'y a pas assez de votants. Diagnostic : pvecm status journalctl -u corosync --since -1h --no-pager | tail -n 200 ping -c3 timedatectl status cat /etc/hosts Correctif sûr : - Vérifier la connectivité du réseau de gestion et les ports du commutateur. - Assurer une synchronisation horaire précise sur tous les nœuds (NTP/Chrony dans les 50 ms). - Confirmer que /etc/hosts associe chaque FQDN de nœud à la bonne IP de gestion. - Pour un cluster mono-nœud en récupération après maintenance : # Mesure temporaire uniquement pour une configuration mono-nœud pvecm expected 1 Ne pas laisser expected votes 1 sur un cluster multi-nœuds. Validation : pvecm status Vous devez voir Quorum: Yes et le nombre correct de nœuds. ## 3) Échec de démarrage de la VM : le volume n'existe pas Erreur : TASK ERROR: volume 'local-lvm: vm-100-disk-0' does not exist Cause : la configuration de la VM pointe vers un disque déplacé, supprimé, ou un LV thin inactif. Diagnostic : qm config 100 | egrep 'scsi|sata|virtio' pvesm list local-lvm | grep vm-100 lvs | grep -E 'data|vm-100' Correctif sûr : - Si le LV existe mais est inactif : lvchange -ay pve/vm-100-disk-0 - Si le LV manque mais qu'une sauvegarde existe, restaurer uniquement le disque : vzrestore /mnt/pve/backup/dump/vm-100-*.vma.zst 100 --unique 1 - Si le disque a été déplacé vers un autre stockage, mettre à jour la configuration de la VM vers le bon ID de stockage via l'interface graphique ou : qm set 100 --scsi0 newstorage:vm-100-disk-0 Validation : démarrer la VM et consulter les journaux système dans l'invité. ## 4) VM verrouillée (sauvegarde, snapshot ou migration) Erreur : TASK ERROR: VM 100 is locked (backup) Cause : un job antérieur a laissé un drapeau de verrouillage. Correctif sûr : # S'assurer qu'aucun job n'est actif ps aux | egrep 'vzdump|qmigrate|qemu-img' | grep -v egrep || true # Puis supprimer le verrou qm unlock 100 Validation : relancer l'opération. ## 5) Échec ou timeout de la sauvegarde vers NFS Symptômes : les jobs vzdump échouent avec "connection timed out" ou des fichiers partiels. Cause : chemin réseau instable, options de montage NFS sous-optimales, ou IO insuffisant sur la cible. Diagnostic : grep -A3 nfs /etc/pve/storage.cfg showmount -e mount | grep nfs ping -c10 Correctif sûr : - Utiliser NFSv3 stable avec options résilientes (exemple) : # Dans /etc/pve/storage.cfg pour votre entrée de stockage NFS # options vers=3, hard, timeo=600, retrans=2 - Ajuster vzdump pour le débit et la résilience : # /etc/vzdump.conf mode: snapshot compress: zstd pigz: 1 bwlimit: 0 tmpdir: /var/tmp - Vérifier l'espace libre et l'utilisation des inodes sur le serveur NFS ( df -i ). Validation d'une sauvegarde mono-VM : vzdump 100 --storage nfs-backups --mode snapshot --compress zstd --ionice 5 --bwlimit 0 -v ## 6) Mauvaise configuration du pont réseau (VM sans réseau) Symptômes : la VM n'obtient pas de bail DHCP ou ne rejoint pas la passerelle. Cause : le pont n'est pas lié à la bonne interface, passerelle manquante, ou incompatibilité VLAN. Diagnostic : ip a ip r brctl show || bridge link bridge vlan show Correctif sûr (Debian ifupdown2) : # /etc/network/interfaces auto lo iface lo inet loopback auto enp3s0 iface enp3s0 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.1.10/24 gateway 192.168.1.1 bridge-ports enp3s0 bridge-stp off bridge-fd 0 # bridge-vlan-aware yes # si vous trunk des VLANs Appliquer sans redémarrage : ifreload -a Validation : depuis une VM, renouveler le bail DHCP ou ping la passerelle. ## 7) Échec de connexion de la console NoVNC Symptômes : écran noir ou "connection failed" à l'ouverture de la console de la VM. Cause : pveproxy non démarré, pare-feu bloquant le port 8006, ou reverse proxy ne transférant pas les en-têtes WebSocket Upgrade. Diagnostic : systemctl status pveproxy ss -lntp | grep 8006 Correctif sûr : systemctl restart pveproxy - Si vous utilisez un reverse proxy, assurez-vous que les en-têtes Upgrade et Connection sont transmis pour les WebSockets. - Autoriser le TCP 8006 depuis votre réseau d'administration dans le pare-feu. Validation : rouvrir la console. ## 8) Disque plein sur le nœud ou pool thin Symptômes : de nombreuses tâches échouent, les snapshots se cassent, ou des erreurs de métadonnées apparaissent. Diagnostic : df -h lvs -a -o+seg_monitor | grep -E 'thin|data' Correctif sûr : - Libérer de l'espace sur le système de fichiers racine : journalctl --vacuum-time=7d apt clean - Pour un pool thin LVM presque plein, l'étendre ou libérer de l'espace : # Exemple : étendre le pool thin de 50 Go lvextend -L +50G pve/data - Envisager de supprimer d'anciens snapshots de VM plus nécessaires. Validation : relancer df -h et lvs ; retenter la tâche. ## 9) Avertissements de santé Ceph (HEALTH_WARN, OSD down, nearfull) Symptômes : ceph -s affiche HEALTH_WARN , redondance de données dégradée, ou OSDs down. Diagnostic : ceph -s ceph osd tree ceph osd df journalctl -u ceph-osd@ --since -1h --no-pager | tail -n 200 Correctif sûr : - Avant une maintenance planifiée de nœud ou d'OSD : ceph osd set noout # effectuer la maintenance ceph osd unset noout - Si un OSD est down, tenter de le redémarrer : systemctl restart ceph-osd@ - Si un pool est nearfull, ajouter de la capacité ou augmenter le poids CRUSH de manière appropriée. Validation : ceph -s doit retourner HEALTH_OK ou un ensemble réduit de problèmes de placement groups. ## 10) Problèmes Corosync après changement de NIC ou d'IP Symptômes : Corosync ne peut pas binder, les pairs ne sont pas joignables. Diagnostic : cat /etc/pve/corosync.conf ip a | grep -A2 -E 'enp|eth|bond|vmbr' Correctif sûr : - Mettre à jour ring0_addr avec l'IP de gestion correcte pour chaque nœud dans /etc/pve/corosync.conf . - Sauvegarder d'abord : cp /etc/pve/corosync.conf /root/corosync.conf.bak.$(date +%F) - Redémarrer Corosync sur un nœud à la fois pendant une fenêtre de maintenance sûre : systemctl restart corosync Validation : pvecm status ## Plan pilote local Objectif : prouver votre workflow de dépannage et vos correctifs sur une installation petite et à faible risque avant une utilisation plus large. Périmètre et étapes : - Laboratoire mono-nœud - Installation fraîche de Proxmox avec local-lvm et une VM de test (ex. ID 100). - Réseau : vmbr0 sur un sous-réseau de laboratoire dédié. - Stockage : ajouter une cible de sauvegarde NFS. - Vérifications de base df -h; free -h; timedatectl status pvesm status; ip a; pvecm status - Exercer les parcours principaux - Démarrer/arrêter la VM. - Créer un snapshot puis le supprimer. - Lancer une sauvegarde vers NFS et restaurer la VM avec un nouvel ID via --unique . - Induire et résoudre un problème sûr et réversible - Arrêter le serveur NFS ou bloquer son IP brièvement, confirmer le timeout de sauvegarde, puis rétablir le service et relancer la sauvegarde. - S'exercer à qm unlock sur une VM de test. - Mesurer - Enregistrer la durée, le débit et le taux d'erreur des sauvegardes avant et après les modifications. - Étendre prudemment - Ajouter un second nœud et vérifier que vos étapes détectent et résolvent les problèmes de cluster courants. - Ajouter Ceph seulement si vous pouvez dédier au moins 3 OSDs sur plusieurs nœuds et disposer d'un réseau stable. Critères de sortie - Les sauvegardes se terminent de façon fiable avec une durée acceptable. - Aucune erreur non résolue dans les journaux système ou de jobs sous charge normale. ## Conclusion Un workflow de dépannage cohérent transforme les erreurs Proxmox vagues en actions claires. Commencez par les journaux et le périmètre, vérifiez les bases, puis ciblez le bon sous-système. Appliquez le plus petit correctif sûr, validez immédiatement et conservez des notes sur ce qui a fonctionné. Utilisez le pilote en laboratoire pour gagner en confiance, puis étendez aux clusters, Ceph et charges de travail plus exigeantes une fois vos métriques stables. Points de contrôle clés à retenir : - Synchronisation horaire, espace disque et santé des services en premier - Correspondance correcte de /etc/hosts et du FQDN - Visibilité du stockage via pvesm , lvs , zpool ou les outils Ceph - Ponts réseau, VLANs et accessibilité des ports - Sauvegardes que vous pouvez restaurer rapidement Avec ces habitudes et exemples, la plupart des problèmes Proxmox deviennent des correctifs rapides et prévisibles.