Erreurs courantes Proxmox et correctifs avec exemples pratiques

Intro

Cette version française explique Proxmox common errors and fixes with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Proxmox facilite l'exécution de machines virtuelles KVM et de conteneurs LXC, avec des fonctionnalités robustes de stockage, réseau, sauvegarde et cluster. Pourtant, certains Proxmox error messages peuvent sembler obscurs. Ce guide les reformule en clair, explique pourquoi ils surviennent et propose des Proxmox fixes sûrs, étape par étape. Vous pourrez ainsi pratiquer un Proxmox troubleshooting reproductible, limité en risque, et applicable à Ceph, au réseau, aux sauvegardes (backup and restore), et aux virtual machines.

Ce que vous allez obtenir:

• Un workflow de dépannage sûr, répétable sous pression
• Des commandes pratiques pour le stockage, le réseau, le cluster, Ceph et les sauvegardes
• Un plan « labo d'abord » pour valider les correctifs avant la production

Prérequis:

• Accès shell au nœud en root ou via sudo
• Aisance avec les outils Linux de type Debian pour réseau et stockage

Vue d'ensemble du workflow

Utilisez ce flux pour éviter les suppositions et réduire les retours arrière.

1. Capturer l'erreur exacte et les logs

• Depuis la GUI: ouvrez le journal de la tâche ayant échoué.
• 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

1. Définir le périmètre

• Est-ce une seule VM/CT, un nœud, le stockage, le réseau ou tout le cluster/Ceph ?

1. Vérifier les bases d'abord

df -h
free -h
timedatectl status
systemctl is-active pveproxy pvedaemon pve-cluster corosync || true

• Assurez-vous que l'heure est synchronisée et que le nœud n'est pas à court d'espace disque ou de mémoire.

1. Identité et DNS

hostname -f
cat /etc/hosts

• Le shortname et le FQDN doivent résoudre vers la bonne IP de gestion.

1. Contrôles stockage (LVM, ZFS, directory, ou Ceph)

pvesm status
pvesm list <storage-id>
lvs; vgs
zpool status || true
rbd ls <pool> --id <ceph-user> || true

1. Contrôles réseau

ip a
ip r
ss -lntp | egrep ':22|:8006|:590[0-9]{2}'
bridge vlan show || true

1. Cluster et corosync

pvecm status
systemctl status corosync
journalctl -u corosync --since -1h --no-pager | tail -n 200

1. Sauvegardes

ls -lh /var/log/vzdump/
cat /etc/vzdump.conf

1. Appliquer le plus petit correctif sûr

• Changez une chose à la fois. Sauvegardez les configs avant d'éditer.

1. Valider et documenter

• Relancez la tâche en échec, capturez les métriques (durée, débit) et notez le correctif.

Erreurs courantes et correctifs

Voici des schémas d'erreurs Proxmox common errors fréquents, leurs causes, leur diagnostic et des remédiations sûres.

1) Message d'abonnement et configuration des dépôts

Symptôme: la GUI signale l'absence d'abonnement valide ou des erreurs APT pour les dépôts enterprise.

Pourquoi: le dépôt enterprise est activé par défaut alors que vous utilisez 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: tâches en échec pour cause de quorum; la GUI affiche « Cluster not ready »; pvecm status indique no quorum.

Pourquoi: corosync ne joigne pas les pairs, l'heure diverge, ou il manque des votants.

Diagnostic:

pvecm status
journalctl -u corosync --since -1h --no-pager | tail -n 200
ping -c3 <peer_mgmt_ip>
timedatectl status
cat /etc/hosts

Correctif sûr:

• Vérifier la portée réseau de gestion et les ports de switch.
• Assurer la synchronisation horaire sur tous les nœuds.
• Confirmer que /etc/hosts mappe chaque FQDN vers la bonne IP de gestion.
• Pour un cluster mono-nœud en maintenance:

# Mesure temporaire pour une configuration à un seul nœud uniquement
pvecm expected 1

Ne laissez pas expected votes à 1 sur un cluster multi-nœuds.

Validation:

pvecm status

Vous devez voir Quorum: Yes et le nombre de nœuds correct.

3) La VM ne démarre pas: volume inexistant

Erreur:

TASK ERROR: volume 'local-lvm: vm-100-disk-0' does not exist

Pourquoi: la configuration pointe vers un disque déplacé/supprimé, ou un LV fin n'est pas actif.

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 que vous avez une sauvegarde, restaurez 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, mettez à jour la config VM via GUI ou:

qm set 100 --scsi0 newstorage: vm-100-disk-0

Validation: démarrez la VM et vérifiez les journaux du système invité.

4) VM verrouillée (backup, snapshot ou migration)

Erreur:

TASK ERROR: VM 100 is locked (backup)

Pourquoi: un job précédent a laissé un lock.

Correctif sûr:

# S'assurer qu'aucun job actif n'existe
ps aux | egrep 'vzdump|qmigrate|qemu-img' | grep -v egrep || true

# Puis retirer le verrou
qm unlock 100

Validation: réessayez l'opération.

5) Sauvegarde vers NFS en échec ou timeout

Symptômes: jobs vzdump en timeout ou fichiers partiels.

Pourquoi: chemin réseau instable, options NFS sous-optimales, ou IO cible insuffisant.

Diagnostic:

grep -A3 nfs /etc/pve/storage.cfg
showmount -e <nfs_server>
mount | grep nfs
ping -c10 <nfs_server>

Correctif sûr:

• Utiliser un NFSv3 stable avec options résilientes (exemple):

# Dans /etc/pve/storage.cfg pour votre entrée 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 les inodes côté serveur NFS.

Validation d'une sauvegarde unitaire:

vzdump 100 --storage nfs-backups --mode snapshot --compress zstd --ionice 5 --bwlimit 0 -v

6) Bridge réseau mal configuré (VM sans réseau)

Symptômes: la VM n'obtient pas de DHCP ou n'atteint pas la passerelle.

Pourquoi: bridge lié au mauvais NIC, passerelle manquante, ou VLAN mal aligné.

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 tronquez des VLANs

Appliquer sans redémarrer:

ifreload -a

Validation: depuis une VM, renouvelez le DHCP ou pingez la passerelle.

7) La console NoVNC n'arrive pas à se connecter

Symptômes: écran noir ou « connection failed » à l'ouverture.

Pourquoi: pveproxy arrêté, firewall bloquant 8006, ou reverse proxy ne passant pas les WebSockets.

Diagnostic:

systemctl status pveproxy
ss -lntp | grep 8006

Correctif sûr:

systemctl restart pveproxy

• Avec reverse proxy, propager les en-têtes Upgrade et Connection pour WebSocket.
• Autoriser TCP 8006 depuis votre réseau d'admin.

Validation: rouvrez la console.

8) Disque plein sur le nœud ou thin pool saturé

Symptômes: multiples tâches en échec, snapshots cassés, erreurs de métadonnées.

Diagnostic:

df -h
lvs -a -o+seg_monitor | grep -E 'thin|data'

Correctif sûr:

• Libérer l'espace du système:

journalctl --vacuum-time=7d
apt clean

• Pour un LVM-thin presque plein, étendre ou libérer:

# Exemple: étendre le thin pool de 50G
lvextend -L +50G pve/data

• Supprimer d'anciens snapshots VM non nécessaires.

Validation: relancez df -h et lvs; réessayez la tâche.

9) Avertissements de santé Ceph (HEALTH_WARN, OSD down, nearfull)

Symptômes: ceph -s en HEALTH_WARN, redondance dégradée, OSDs down.

Diagnostic:

ceph -s
ceph osd tree
ceph osd df
journalctl -u ceph-osd@<id> --since -1h --no-pager | tail -n 200

Correctif sûr:

• Avant une maintenance planifiée de nœud/OSD:

ceph osd set noout
# maintenance
ceph osd unset noout

• Si un OSD est down, tentez de le redémarrer:

systemctl restart ceph-osd@<id>

• Si un pool est near full, ajoutez de la capacité ou ajustez le CRUSH weight de façon appropriée.

Validation: ceph -s doit tendre vers HEALTH_OK ou réduire les problèmes de PG.

10) Problèmes Corosync après changement de NIC ou d'IP

Symptômes: corosync ne se lie plus, pairs injoignables.

Diagnostic:

cat /etc/pve/corosync.conf
ip a | grep -A2 -E 'enp|eth|bond|vmbr'

Correctif sûr:

• Mettre à jour ring0_addr avec la bonne IP de gestion pour chaque nœud dans /etc/pve/corosync.conf.
• Sauvegarder avant modification:

cp /etc/pve/corosync.conf /root/corosync.conf.bak.$(date +%F)

• Redémarrer corosync, un nœud à la fois et en fenêtre sûre:

systemctl restart corosync

Validation:

pvecm status

Plan pilote local

Objectif: prouver votre workflow de diagnostic et vos correctifs sur un périmètre réduit et sans risque avant un déploiement plus large.

Portée et étapes:

1. Nœud unique en labo

• Installation Proxmox fraîche avec local-lvm et une VM de test (ID 100).
• Réseau: vmbr0 sur un sous-réseau de labo dédié.
• Stockage: ajoutez une cible NFS pour les sauvegardes.

1. Vérifications de base

df -h; free -h; timedatectl status
pvesm status; ip a; pvecm status

1. Parcourir les chemins critiques

• Démarrer/arrêter la VM.
• Prendre un snapshot et le supprimer.
• Lancer une sauvegarde NFS et restaurer la VM avec un nouvel ID via --unique.

1. Provoquer puis résoudre un incident réversible

• Coupez brièvement le serveur NFS ou bloquez son IP, confirmez le timeout de sauvegarde, puis rétablissez et relancez la sauvegarde.
• Exercez qm unlock sur une VM de test.

1. Mesurer

• Relevez la durée des sauvegardes, le débit et le taux d'erreurs avant/après changements.

1. Étendre prudemment

• Ajoutez un second nœud et vérifiez que vos étapes détectent et résolvent les problèmes de cluster courants.
• Ajoutez Ceph seulement si vous pouvez dédier au moins 3 OSDs répartis et un réseau stable.

Critères de sortie

• Sauvegardes fiables avec une durée acceptable.
• Pas d'erreurs non résolues dans les journaux système ou de jobs sous charge normale.

Conclusion

Un workflow cohérent transforme des Proxmox error messages flous en actions claires. Commencez par les logs 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 notez ce qui a fonctionné. Utilisez un pilote en labo pour bâtir la confiance, puis montez en charge vers les clusters, Ceph et des workloads plus exigeants une fois vos métriques stabilisées.

Points de contrôle à garder en tête:

• Synchronisation horaire, espace disque et santé des services d'abord
• Mapping correct de /etc/hosts et du FQDN
• Visibilité stockage via pvesm, lvs, zpool ou outils ceph
• Bridges réseau, VLANs et ports accessibles
• Des sauvegardes que vous pouvez restaurer rapidement

Avec ces habitudes et exemples, la plupart des Proxmox common errors deviennent des correctifs rapides et prévisibles, appuyés par une démarche de Proxmox debugging structurée.