Proxmox « pve-cluster.service failed » : Comment remettre la pile du cluster en route

Ce que signifie vraiment « pve-cluster failed »

pve-cluster est le service qui exécute le système de fichiers de cluster Proxmox (pmxcfs). pmxcfs est un système de fichiers basé sur FUSE monté sur /etc/pve. S’il n’est pas monté et sain, Proxmox perd l’accès à la configuration du cluster telle qu’il l’attend. Cela inclut :

• La configuration à l’échelle du cluster, les définitions de stockage, l’état HA
• La configuration du pare-feu (portée cluster)
• L’appartenance des nœuds et la distribution de la configuration Corosync
• Les fichiers de configuration des VM et CT (en mode cluster)

Sous le capot, pmxcfs dépend fortement de Corosync (adhésion au cluster, quorum, messagerie). Corosync n’est pas juste « agréable à avoir ». C’est l’arbitre. Si vous n’avez pas le quorum, pmxcfs devient prudent pour éviter des écritures en split-brain.

C’est la partie qui fait mal : vous pouvez avoir « un nœud parfaitement sain » avec des VM en cours d’exécution et des disques OK, mais si Corosync ne peut pas former l’appartenance, pmxcfs peut refuser les écritures — ou échouer au démarrage — et alors toute action de gestion se transforme en une erreur cryptique.

Voici la position opérationnelle que je recommande : traitez pve-cluster.service failed comme un symptôme, pas comme un diagnostic. Le vrai diagnostic se trouve généralement dans l’un de ces paniers :

• Échec de quorum/adhésion (réseau, nombre de nœuds, incohérence de configuration Corosync)
• Contraintes locales (disque plein, épuisement d’inodes, pression mémoire, limites de descripteurs de fichiers)
• Problèmes de temps (dérive NTP rendant Corosync mécontent ; TLS casse ; journaux trompeurs)
• Configuration de cluster corrompue ou incohérente (mauvais corosync.conf, mises à jour partielles, certificats de nœuds obsolètes)
• Erreurs humaines (flags forcés utilisés au mauvais moment, « correctifs rapides » qui créent silencieusement un split-brain)

Une citation à garder en tête : L’espoir n’est pas une stratégie. —General Gordon R. Sullivan. Ce n’est pas une citation Proxmox, mais elle a sa place dans chaque rotation d’astreinte.

Playbook de diagnostic rapide

Si vous êtes chronométré, ne relancez pas les services au hasard. Votre objectif est d’identifier rapidement le goulot d’étranglement : s’agit-il d’un problème du nœud local ou d’un problème de quorum du cluster ?

Première étape (60 secondes) : déterminer si /etc/pve est monté et si Corosync a le quorum

• Vérifier si pmxcfs est monté : findmnt /etc/pve
• Vérifier Corosync/quorum : pvecm status et corosync-quorumtool -s
• Vérifier la raison exacte de l’échec : systemctl status pve-cluster + journalctl -u pve-cluster -b

Deuxième étape (2–5 minutes) : valider les « basiques ennuyeux » qui tuent les services de cluster

• Espace disque/inodes : df -h, df -i
• Pression mémoire : free -h, dmesg -T | tail
• Synchronisation temporelle : timedatectl, chronyc tracking (ou systemctl status systemd-timesyncd)
• Accessibilité réseau sur les liens Corosync : tests ping/MTU entre nœuds

Troisième étape (5–15 minutes) : décider du mode de récupération

• Si le quorum peut être rétabli : corrigez le réseau/la config/le temps et remettez Corosync en service normalement. Puis redémarrez pve-cluster.
• Si le quorum ne peut pas être rétabli rapidement : choisissez entre opérations en lecture seule sûres ou un mode contrôlé temporaire nœud-unique (seulement si vous comprenez les conséquences).
• Si c’est un cluster à deux nœuds : décidez d’utiliser un qdevice (idéal), ou un ajustement temporaire de expected-votes (risqué mais parfois nécessaire).

Blague #1 : Si votre première étape de récupération est « redémarrer tout », vous ne dépannez pas — vous exécutez une danse interprétative pour les dieux des pannes.

Faits intéressants et contexte historique (qui aident vraiment à déboguer)

1. pmxcfs est un système de fichiers FUSE. Cela signifie que le répertoire /etc/pve que vous voyez est un montage en espace utilisateur ; s’il est en panne, vos fichiers réels sur disque se trouvent ailleurs et le comportement change.
2. Proxmox a orienté tôt sa configuration vers le cluster. Cette décision rend la gestion multi-nœuds raisonnable, mais implique aussi que la santé du cluster affecte les opérations de base sur un seul nœud.
3. La conception de Corosync met le quorum en priorité. Il préfère refuser les écritures plutôt que risquer un split-brain. C’est pourquoi les échecs semblent souvent « trop stricts ».
4. Les clusters à deux nœuds sont intrinsèquement compliqués. Sans troisième vote (qdevice ou témoin), vous êtes toujours à une panne d’un débat philosophique sur qui devient « le cluster ».
5. Le quorum ne concerne pas seulement la majorité de disponibilité — il concerne une adhésion sûre. Vous pouvez avoir 99 % des services en marche et être néanmoins « non sûr pour écrire l’état du cluster ».
6. La dérive d’horloge peut se faire passer pour une panne réseau. Corosync et TLS se comportent mal quand le temps est incorrect ; les journaux deviennent trompeurs et les tentatives augmentent.
7. Les problèmes de disque plein frappent plus fort les clusters. Un système de fichiers root plein peut empêcher les écritures d’état, la journalisation ou le fonctionnement interne de pmxcfs, provoquant des pannes en cascade qui ressemblent à « Corosync mort ».
8. Les erreurs de l’interface Proxmox reflètent souvent l’état de pmxcfs. L’interface web peut encore se charger mais les opérations échouent parce qu’elle ne peut pas écrire les configs dans /etc/pve.

Tâches pratiques de récupération (commandes, sorties, décisions)

Ce sont des tâches réelles à exécuter sur un nœud. Chaque tâche inclut : commande, ce que la sortie signifie et la décision suivante. Ne les exécutez pas aveuglément ; suivez l’ordre du diagnostic rapide.

Tâche 1 : Confirmer l’échec du service et capturer la raison réelle

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: failed (Result: exit-code) since Tue 2025-12-25 09:41:02 UTC; 2min 3s ago
    Process: 1832 ExecStart=/usr/bin/pmxcfs (code=exited, status=255/EXCEPTION)
     Memory: 1.6M
     CPU: 43ms

Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: starting pmxcfs
Dec 25 09:41:02 server pmxcfs[1832]: [main] crit: unable to initialize cluster communication
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

Signification : pmxcfs a démarré mais n’a pas pu initialiser la communication du cluster — souvent Corosync/quorum. Ce n’est pas un crash générique.

Décision : Vérifiez immédiatement l’état de Corosync et le quorum avant de toucher aux flags de pmxcfs ou de redémarrer tout et n’importe quoi.

Tâche 2 : Lire le journal de pve-cluster pour la chaîne d’échecs précise

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 25 09:40:59 server systemd[1]: Starting The Proxmox VE cluster filesystem...
Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: starting pmxcfs
Dec 25 09:41:02 server pmxcfs[1832]: [dcdb] notice: data verification successful
Dec 25 09:41:02 server pmxcfs[1832]: [main] crit: unable to initialize cluster communication
Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: exit now
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION

Signification : La base de données locale (dcdb) semble correcte. L’échec est lié au réseau/à l’adhésion plutôt qu’à une corruption locale.

Décision : Concentrez-vous sur Corosync et le quorum, pas sur la réinstallation de paquets ou la « réparation » des fichiers pour l’instant.

Tâche 3 : Vérifier si /etc/pve est monté (pmxcfs)

cr0x@server:~$ findmnt /etc/pve

Signification : L’absence de sortie signifie généralement qu’il n’est pas monté. S’il est monté, vous verrez un montage FUSE (pmxcfs).

Décision : S’il n’est pas monté et que pve-cluster est en échec, vous êtes en territoire « système de fichiers de cluster tombé ». N’éditez pas /etc/pve en pensant que cela se propagera au cluster.

Tâche 4 : Vérifier l’état de Corosync et du quorum avec les outils Proxmox

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-clu
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Tue Dec 25 09:43:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.152
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      1
Quorum:           2
Flags:            2Node Quorate

Signification : Pas de quorum. Avec seulement 1 des 3 votes visibles, les services du cluster adopteront un comportement défensif.

Décision : Vous devez rétablir la connectivité vers au moins un autre nœud (ou qdevice) avant d’espérer que pmxcfs se comporte normalement.

Tâche 5 : Croiser la vue propre de Corosync

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Tue Dec 25 09:43:46 2025
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          1
Ring ID:          152.209
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Total votes:      1
Quorum:           2
Flags:            None

Signification : Cela confirme que ce n’est pas seulement l’outil Proxmox ; Corosync manque réellement d’adhésion.

Décision : Arrêtez de penser « pve-cluster est cassé ». Commencez à penser « le cluster est cassé ».

Tâche 6 : Vérifier le service Corosync et les journaux récents

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:41:10 UTC; 2min 50s ago
       Docs: man:corosync
   Main PID: 1904 (corosync)
      Tasks: 9
     Memory: 29.8M
     CPU: 2.214s

cr0x@server:~$ journalctl -u corosync -b --no-pager -n 80
Dec 25 09:41:10 server corosync[1904]:   [KNET  ] link: host: 2 link: 0 is down
Dec 25 09:41:10 server corosync[1904]:   [KNET  ] link: host: 3 link: 0 is down
Dec 25 09:41:10 server corosync[1904]:   [QUORUM] This node is within the non-primary component and will NOT provide service.

Signification : Corosync fonctionne, mais le lien knet ne peut pas atteindre les pairs. C’est généralement un problème réseau, MTU, VLAN, pare-feu ou une mauvaise IP dans corosync.conf.

Décision : Vérifiez le chemin réseau du ring de bout en bout avant d’effectuer des modifications de configuration.

Tâche 7 : Valider que corosync.conf est présent et cohérent sur ce nœud

cr0x@server:~$ sed -n '1,200p' /etc/pve/corosync.conf
sed: can't read /etc/pve/corosync.conf: No such file or directory

Signification : Si pmxcfs est en panne, /etc/pve peut être vide/non monté, donc le fichier ne sera pas lisible. Cela ne signifie pas qu’il est « manquant », cela signifie que le montage n’est pas présent.

Décision : Lisez la copie de secours locale dans /etc/corosync/corosync.conf (pas parfaite, mais indique ce que ce nœud croit être la configuration).

cr0x@server:~$ sed -n '1,220p' /etc/corosync/corosync.conf
totem {
  version: 2
  cluster_name: prod-clu
  transport: knet
  interface {
    linknumber: 0
    bindnetaddr: 10.10.50.0
    mcastport: 5405
  }
}
nodelist {
  node {
    name: pve1
    nodeid: 1
    ring0_addr: 10.10.50.11
  }
  node {
    name: pve2
    nodeid: 2
    ring0_addr: 10.10.50.12
  }
  node {
    name: pve3
    nodeid: 3
    ring0_addr: 10.10.50.13
  }
}
quorum {
  provider: corosync_votequorum
}

Signification : Ce nœud attend des pairs sur 10.10.50.0/24. Si votre équipe réseau a « optimisé » les VLAN, c’est ici que vous le constatez.

Décision : Confirmez que 10.10.50.x est joignable en L2/L3 comme prévu et que l’interface du nœud est bien sur ce sous-réseau.

Tâche 8 : Confirmer que l’IP et le routage du nœud correspondent au réseau du ring Corosync

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.50.11/24
eno2             DOWN
vmbr0            UP             192.168.10.11/24

cr0x@server:~$ ip route
default via 192.168.10.1 dev vmbr0
10.10.50.0/24 dev eno1 proto kernel scope link src 10.10.50.11
192.168.10.0/24 dev vmbr0 proto kernel scope link src 192.168.10.11

Signification : Le réseau du ring Corosync est connecté directement sur eno1. C’est bon. Si ce n’était pas le cas, vous verriez un routage étrange.

Décision : Testez la connectivité et le MTU vers les pairs sur le réseau du ring ensuite.

Tâche 9 : Tester la joignabilité des pairs et le MTU (Corosync déteste les pertes silencieuses)

cr0x@server:~$ ping -c 2 10.10.50.12
PING 10.10.50.12 (10.10.50.12) 56(84) bytes of data.

--- 10.10.50.12 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1016ms

cr0x@server:~$ ping -M do -s 1472 -c 2 10.10.50.12
PING 10.10.50.12 (10.10.50.12) 1472(1500) bytes of data.

--- 10.10.50.12 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1013ms

Signification : Une perte totale suggère un problème de lien/VLAN/pare-feu/port, pas seulement un MTU. Si un petit ping fonctionne mais que le ping MTU échoue, suspectez un décalage MTU ou un chemin où la fragmentation est bloquée.

Décision : Si le ping échoue, arrêtez. Corrigez le chemin réseau (port de commutateur, balisage VLAN, règles de pare-feu, routage). Relancer des services ne changera pas la physique.

Tâche 10 : Vérifier si le pare-feu bloque le trafic Corosync sur l’hôte

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ iptables -S | head
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Signification : Le pare-feu Proxmox peut être activé et ne pas bloquer Corosync selon le jeu de règles. L’extrait iptables ici montre ACCEPT par défaut, ce qui suggère que le pare-feu de l’hôte n’est pas la cause.

Décision : Si vous voyez DROP par défaut ou des drops explicites sur UDP 5405/5404 etc., corrigez les règles. Sinon, concentrez-vous sur le réseau en amont.

Tâche 11 : Vérifier l’espace disque et l’épuisement des inodes (oui, vraiment)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        48G   47G  180M 100% /

cr0x@server:~$ df -i /
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2     3145728 3120000   25728   100% /

Signification : Disque plein et inodes pleins sont des causes classiques de panne de cluster. Les services ne peuvent pas écrire l’état, les logs ou fichiers temporaires. pmxcfs peut échouer de façon créative.

Décision : Libérez de l’espace en toute sécurité (journaux, anciens noyaux, ISO inutiles). Ne supprimez pas des fichiers de cluster au hasard par colère.

Tâche 12 : Vérification de la cohérence du temps (parce que les systèmes distribués sont pointilleux)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-25 09:46:10 UTC
           Universal time: Tue 2025-12-25 09:46:10 UTC
                 RTC time: Tue 2025-12-25 09:46:09
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

cr0x@server:~$ chronyc tracking
Reference ID    : 192.0.2.10
Stratum         : 3
Last offset     : +3.421 seconds
RMS offset      : 1.922 seconds
Frequency       : 34.112 ppm fast
Leap status     : Not synchronised

Signification : Vous dérivez de quelques secondes. C’est suffisant pour que des composants distribués se comportent étrangement — surtout lors de changements d’adhésion et de validation TLS.

Décision : Réparez d’abord la synchronisation temporelle (portée NTP, configuration chrony). Puis retentez Corosync/pve-cluster.

Tâche 13 : Remettre Corosync proprement en route (après correction du problème sous-jacent)

cr0x@server:~$ systemctl restart corosync

cr0x@server:~$ pvecm status | sed -n '1,40p'
Cluster information
-------------------
Name:             prod-clu
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Tue Dec 25 09:49:02 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.154
Quorate:          Yes

Signification : Le quorum est revenu. Maintenant pmxcfs a une chance de démarrer correctement.

Décision : Redémarrez pve-cluster et vérifiez le montage.

Tâche 14 : Redémarrer pve-cluster et valider le montage pmxcfs + lectures basiques

cr0x@server:~$ systemctl restart pve-cluster

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:20 UTC; 4s ago
   Main PID: 2488 (pmxcfs)

cr0x@server:~$ findmnt /etc/pve
TARGET   SOURCE  FSTYPE OPTIONS
/etc/pve pmxcfs  fuse   rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other

cr0x@server:~$ ls -la /etc/pve | head
total 0
drwxr-xr-x 2 root www-data 0 Dec 25 09:49 .
drwxr-xr-x 1 root root     0 Dec 25 09:49 ..
-rw-r----- 1 root www-data 0 Dec 25 09:49 .members
-rw-r----- 1 root www-data 0 Dec 25 09:49 corosync.conf
drwxr-xr-x 2 root www-data 0 Dec 25 09:49 nodes

Signification : C’est monté et la configuration du cluster est de nouveau visible. C’est l’indicateur que « la pile est revenue ».

Décision : Vérifiez pvedaemon et pveproxy ensuite si l’interface web affiche encore des erreurs.

Tâche 15 : Valider les services back-end de l’interface une fois le FS de cluster sain

cr0x@server:~$ systemctl status pvedaemon pveproxy --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:40 UTC; 9s ago
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:42 UTC; 7s ago

Signification : La pile API est en cours d’exécution. Si l’interface graphique échoue encore, c’est probablement lié à l’authentification/aux certificats, au cache du navigateur ou à un nœud spécifique toujours non quoré.

Décision : Vérifiez l’adhésion au cluster et la liste des nœuds sur tous les nœuds.

Tâche 16 : Confirmer l’appartenance et rechercher des « nœuds fantômes »

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1
         2          1 pve2
         3          1 pve3

Signification : L’appartenance est propre. Si vous voyez des nœuds que vous avez radiés des mois auparavant, votre configuration de cluster est obsolète et peut provoquer des mathématiques de quorum ou des tentatives de liaison étranges.

Décision : Si des nœuds fantômes existent, planifiez une suppression propre du cluster, pas une édition ad hoc pendant une panne.

Tâche 17 : Si pmxcfs est monté mais que les écritures échouent, tester une écriture sûre

cr0x@server:~$ touch /etc/pve/.pmxcfs-write-test
touch: cannot touch '/etc/pve/.pmxcfs-write-test': Read-only file system

Signification : pmxcfs est monté en lecture seule. Cela corrèle souvent avec une perte de quorum ou un mode de protection interne.

Décision : Revérifiez le quorum (pvecm status). Si quorate est « No », arrêtez d’essayer de forcer des écritures. Rétablissez le quorum ou choisissez délibérément le mode nœud-unique avec les yeux ouverts (voir les checklists).

Tâche 18 : Confirmer les signaux de santé de la base de données locale du cluster

cr0x@server:~$ systemctl status pve-cluster --no-pager -l
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:20 UTC; 1min 22s ago
   Main PID: 2488 (pmxcfs)
     CGroup: /system.slice/pve-cluster.service
             └─2488 /usr/bin/pmxcfs

Signification : Vous vérifiez principalement qu’il reste en ligne et ne se relance pas en boucle. S’il oscille, il se bat toujours avec Corosync, le disque ou le temps.

Décision : S’il oscille, arrêtez de le redémarrer. Revenez aux journaux Corosync et aux contrôles de ressources de l’hôte.

Causes racines par symptôme (comment raisonner, pas seulement quoi taper)

Symptôme : pve-cluster échoue immédiatement avec « unable to initialize cluster communication »

Causes probables : Corosync arrêté, Corosync actif mais pas de quorum, mauvais réseau du ring, UDP bloqué, décalage MTU, ou dérive temporelle provoquant une instabilité d’adhésion.

Approche : Vérifiez d’abord le quorum et les journaux Corosync. Si Corosync ne voit pas ses pairs, pmxcfs ne formera généralement pas une vue cohérente.

Symptôme : /etc/pve existe mais est vide ou manque des fichiers attendus

Causes probables : pmxcfs n’est pas monté ; vous regardez le répertoire sous-jacent (ou un montage cassé).

Approche : Utilisez findmnt. S’il n’est pas monté, ne « recréez » pas manuellement les fichiers dans /etc/pve. C’est ainsi que l’on crée une future panne avec des étapes supplémentaires.

Symptôme : pmxcfs monte en lecture seule

Causes probables : Pas de quorum. Parfois un « mode de protection » local après une instabilité.

Approche : Rétablissez le quorum si possible. Si ce n’est pas possible, décidez si vous avez absolument besoin d’écrire en acceptant le risque de split-brain (généralement : non).

Symptôme : Corosync est « active (running) » mais le cluster n’est pas quoré

Causes probables : Partition réseau, nœuds pairs arrêtés, incohérence de configuration entre nœuds, ou calcul de « expected votes » qui ne reflète pas la réalité (commun après suppression de nœud ou design à deux nœuds).

Approche : Lisez les journaux Corosync, vérifiez la joignabilité, confirmez la version de configuration et validez la liste des nœuds.

Symptôme : Tout allait bien jusqu’à ce que quelqu’un change VLAN/MTU/teaming

Causes probables : Le trafic Corosync est tombé, fragmenté ou rerouté. knet est robuste mais pas magique.

Approche : Validez le MTU de bout en bout, vérifiez les balises de ports de commutateur, et assurez-vous que le réseau du ring Corosync ne passe pas accidentellement sur un segment congestionné ou filtré.

Symptôme : La pile du cluster échoue après une coupure de courant

Causes probables : Dérive temporelle (RTC incorrect), ordre de démarrage incohérent, nœuds démarrant sans réseau prêt, ou problèmes disques partiels liés à des arrêts brutaux.

Approche : Confirmez la synchronisation temporelle, vérifiez que les disques sont sains, puis remontez Corosync avant d’espérer que pmxcfs soit heureux.

Blague #2 : Le quorum, c’est comme une réunion qui a besoin de deux personnes pour approuver une décision — jusqu’à ce qu’une personne manque et soudainement personne ne se souvient comment faire son travail.

Trois mini-histoires d’entreprise (parce que la douleur enseigne)

Mini-histoire 1 : L’incident causé par une fausse hypothèse

Ils exploitaient un cluster Proxmox à trois nœuds dans une entreprise de taille moyenne : nœuds de calcul dans une baie, stockage sur une plateforme séparée, réseau « standardisé ». Un après-midi, l’interface de gestion d’un nœud a commencé à renvoyer des erreurs de cluster, et pve-cluster.service est passé en échec. Un ingénieur junior a fait ce que beaucoup d’entre nous ont fait sous pression : « C’est juste l’interface ; les VM tournent, donc le cluster doit être sain. »

La fausse hypothèse était subtile : ils pensaient que l’état du cluster n’était nécessaire que pour les actions cluster-wide. Mais leurs sauvegardes de VM, changements de pare-feu et définitions de stockage vivaient tous dans /etc/pve via pmxcfs. Quand pmxcfs a échoué, les tâches de sauvegarde ont commencé à échouer silencieusement au début (les configs ne pouvaient pas être lues de façon cohérente), puis bruyamment (les opérations API échouaient). Le rapport d’incident a plus tard utilisé l’expression « panne secondaire », qui est le jargon corporate pour « on a empiré les choses ».

La cause racine était un changement réseau sur le VLAN Corosync. Un profil de port de switch a été mis à jour pour un « MTU standard », ce qui en pratique signifiait que le réseau Corosync a perdu les jumbo frames alors qu’une partie du chemin en envoyait encore. Corosync ne meurt pas ; il ne pouvait simplement pas maintenir une adhésion stable. pmxcfs a refusé de participer, préférant correctement la sécurité à l’absurde.

Ce qui l’a réparé n’a pas été des redémarrages. C’était de vérifier le réseau du ring de bout en bout avec des pings MTU, puis d’aligner le MTU de façon cohérente. Après cela, Corosync a regagné le quorum, pmxcfs s’est monté en lecture-écriture, et l’interface est redevenue ce qu’elle doit être.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a jugé que leur réseau de cluster « bavardait trop ». Ils avaient un réseau de stockage, un réseau VM et un réseau de management. Ils ont « optimisé » en consolidant Corosync sur le bridge de management parce que « ça a déjà de la connectivité partout ». Le changement a été fait en heures ouvrables car l’ingénieur pensait que Corosync se reconnecterait vite et que pmxcfs serait tolérant. L’optimisme est une ressource renouvelable.

Le réseau de management avait des règles de pare-feu, des limites de débit et des pointes de trafic occasionnelles provenant de la supervision, du patching et de la gestion de configuration. L’adhésion Corosync a commencé à osciller sous charge, ce qui signifiait que le quorum était perdu de façon intermittente. pmxcfs alternait entre utilisable et défensif. Leur interface Proxmox est devenue une machine à sous : cliquer sur « démarrer VM », parfois ça marche, parfois ça renvoie une erreur.

Le vrai dommage est apparu plus tard. L’état HA et les écritures de configuration ont eu lieu pendant de brèves fenêtres « quorées », mais étaient bloquées pendant les fenêtres « non quorées », créant des attentes incohérentes pour les opérateurs. Les gens ont commencé à « réparer » les symptômes : redémarrages de daemons, désactivation de pare-feu, ajout de hacks sur expected votes. L’environnement est devenu opérationnellement bruyant — le pire type d’instabilité, parce qu’il semble vivant.

La récupération a été de défaire l’optimisation. Corosync a retrouvé un réseau dédié avec latence stable et MTU cohérent, et ils ont arrêté de considérer l’adhésion au cluster comme « juste un autre service UDP ». Ensuite, ils ont ajouté un qdevice parce que le cluster fonctionnait parfois avec seulement deux nœuds pendant des maintenances. Des choix de conception ennuyeux. Très efficaces.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers avait un cluster Proxmox qui échouait rarement — parce qu’ils pratiquaient une discipline peu glamour. Ils documentaient la topologie du ring Corosync, gardaient un simple script « santé du cluster » exécuté par la supervision, et imposaient la synchronisation temporelle comme s’il s’agissait d’un contrôle de sécurité (parce que c’en est un).

Un matin, pve-cluster a échoué sur un nœud après une mise à jour du noyau. L’ingénieur d’astreinte n’a pas commencé par redémarrer les services. Il a commencé par collecter des preuves : pvecm status, journalctl, df, timedatectl. En quelques minutes, il a vu que l’horloge du nœud était décalée et que NTP ne se synchronisait pas. La mise à jour avait réinitialisé une politique réseau et bloqué l’accès NTP egress sur ce VLAN.

Parce qu’ils avaient une checklist connue et fiable, ils ont corrigé la règle de pare-feu, confirmé que chronyc tracking s’était stabilisé, puis redémarré Corosync et pmxcfs dans le bon ordre. Le cluster s’est rétabli sans aucun hack de configuration. Les VM ont continué à tourner. L’interface est revenue. Personne n’a eu à « forcer » quoi que ce soit.

Le postmortem était presque ennuyeux. C’est le but. Ils n’ont pas gagné parce qu’ils étaient plus malins ; ils ont gagné parce qu’ils étaient constants.

Listes de contrôle / plan étape par étape

Checklist A : Récupération sûre lorsque le quorum peut être rétabli

1. Geler les opérations risquées. Ne migrez pas de VM, ne changez pas les définitions de stockage, n’éditez pas la configuration du cluster tandis qu’il est instable.
2. Capturer l’état. Sauvegardez les sorties de systemctl status pve-cluster corosync, pvecm status, et les ~100 dernières lignes des journaux pour les deux services.
3. Corriger les basiques d’abord :
   • Espace disque / inodes
   • Synchronisation temporelle
   • Joignabilité réseau sur les liens du ring (y compris MTU)
4. Redémarrer Corosync après la correction sous-jacente. Ne le redémarrez pas par superstition.
5. Confirmer quoré = Yes. Si non, arrêtez et continuez à travailler le réseau/l’adhésion.
6. Redémarrer pve-cluster. Validez que findmnt /etc/pve montre pmxcfs.
7. Valider le comportement lecture/écriture. Si lecture seule, vous n’avez toujours pas le quorum ou la stabilité.
8. Puis valider les services API. pvedaemon, pveproxy.
9. Ensuite seulement reprenez les opérations normales.

Checklist B : Mode contrôlé nœud-unique (dernier recours, temporaire)

Ici c’est souvent que les gens se font du mal. Si vous faites fonctionner un nœud unique comme s’il était « le cluster » alors que d’autres nœuds peuvent revenir ensuite, vous risquez le split-brain de configuration. Si vous ne comprenez pas cette phrase, ne faites pas cela.

1. Confirmer que les autres nœuds sont vraiment hors-ligne ou isolés. S’ils peuvent revenir de façon imprévisible, vous jouez à la roulette de configuration.
2. Communiquer. Informez votre équipe que vous entrez en mode dégradé et que les changements de configuration pourront nécessiter une réconciliation ultérieure.
3. Privilégier les actions en lecture seule. Maintenez les charges de travail. Évitez les éditions de configuration cluster-wide.
4. Si vous devez impérativement retrouver la capacité d’écriture, utilisez une stratégie de quorum délibérée (qdevice, ou ajustement temporaire de expected-votes) et documentez ce que vous avez changé.
5. Planifiez le retour à la normale. La partie difficile n’est pas d’entrer en mode dégradé — c’est d’en sortir proprement.

Checklist C : Plan de survie pour cluster à deux nœuds

1. Meilleur : ajoutez un qdevice/témoin dans un troisième domaine de défaillance (pas sur le même hôte, pas sur le même switch si possible).
2. Pendant l’incident : si un nœud est down, attendez-vous à une perte de quorum sauf si vous l’avez planifié.
3. Ne « hackez » pas de façon permanente les expected votes.
4. Après récupération : investissez dans le troisième vote. C’est moins cher que la prochaine panne.

Erreurs courantes : symptôme → cause racine → correctif

1) « pve-cluster failed, donc j’ai édité /etc/pve manuellement »

Symptôme : Après la récupération, les modifications de configuration ont disparu ou n’existaient que sur un seul nœud.

Cause racine : pmxcfs n’était pas monté ; vous avez modifié le répertoire sous-jacent ou une vue locale fictive.

Correctif : Vérifiez findmnt /etc/pve avant toute modification. N’apportez des changements que lorsque pmxcfs est monté et que le cluster est quoré.

2) Corosync tourne, mais quoré est « No », alors j’ai redémarré pve-cluster 20 fois

Symptôme : pmxcfs oscille ; les erreurs UI persistent.

Cause racine : Problème d’adhésion (partition réseau, pairs manquants, mismatch de expected votes).

Correctif : Rétablissez la connectivité réseau et la configuration Corosync cohérente ; redémarrez Corosync une fois après avoir corrigé la cause sous-jacente ; puis redémarrez pve-cluster.

3) « Nous avons trois nœuds, donc nous avons toujours le quorum »

Symptôme : Un nœud en moins et soudain le cluster n’est pas quoré.

Cause racine : Deux nœuds ne communiquent pas réellement (partition silencieuse), ne laissant qu’un seul vote visible.

Correctif : Validez la connectivité entre tous les nœuds sur le réseau du ring. Un cluster est un graphe, pas un simple comptage de têtes.

4) Le décalage MTU cause des pertes de quorum intermittentes

Symptôme : L’adhésion Corosync oscille, surtout sous charge ou après des modifications réseau.

Cause racine : MTU mixte sur le chemin, fragmentation bloquée, ou incohérence de port de switch.

Correctif : Standardisez le MTU de bout en bout. Utilisez ping -M do -s entre interfaces de ring.

5) Disque plein déclenche des pannes ressemblant à « communication de cluster »

Symptôme : Services plantent ou refusent de démarrer ; les journaux peuvent être tronqués ; comportement étrange après des mises à jour.

Cause racine : Système de fichiers root ou inodes épuisés.

Correctif : Libérez espace/inodes en sécurité, puis redémarrez les services. Ajustez aussi la rétention des logs et l’entretien pour éviter la récidive.

6) La dérive temporelle fait ressembler tout à un problème réseau

Symptôme : Erreurs TLS, état de cluster étrange, journaux incohérents, instabilité d’adhésion.

Cause racine : NTP non synchronisé ; RTC incorrect ; NTP bloqué.

Correctif : Rétablissez la synchronisation temporelle, confirmez le suivi stable, puis réévaluez l’adhésion Corosync.

7) Supprimer un nœud « en le supprimant »

Symptôme : Nœuds fantômes apparaissent ; expected votes erronés ; la mathématique du quorum vous surprend.

Cause racine : Le nœud a été décommissionné sans suivre la procédure de suppression du cluster.

Correctif : Utilisez la procédure correcte de suppression de nœud lorsque le cluster est sain ; n’improvisez pas pendant une panne.

FAQ

1) Qu’est-ce exactement que pve-cluster.service ?

Il exécute pmxcfs, le système de fichiers de cluster Proxmox monté sur /etc/pve. S’il est arrêté, l’accès à la configuration du cluster est rompu de façons qui rendent l’API et l’interface web peu fiables.

2) Mes VM en cours sont-elles affectées quand pve-cluster est arrêté ?

Généralement les VM continuent de tourner. La douleur concerne les opérations de gestion : démarrer/arrêter depuis l’UI, migrations, sauvegardes, actions HA et écritures de configuration qui peuvent échouer ou devenir dangereuses.

3) Pourquoi /etc/pve semble vide ?

Parce que pmxcfs n’est pas monté. Vous voyez le répertoire sous-jacent, pas le montage FUSE. Confirmez avec findmnt /etc/pve.

4) Corosync tourne. Pourquoi le cluster ne fonctionne-t-il pas ?

Corosync peut être « en marche » mais sans quorum. Sans quorum, pmxcfs peut refuser les écritures ou échouer au démarrage. Vérifiez pvecm status et les journaux Corosync.

5) Puis-je simplement redémarrer pve-cluster et corosync jusqu’à ce que ça marche ?

Vous pouvez, mais c’est une stratégie faible. Si la cause racine est la joignabilité réseau, le MTU, le disque plein ou la dérive temporelle, les redémarrages ne font qu’ajouter du bruit et peuvent aggraver l’instabilité.

6) Quelle est la manière la plus rapide de savoir si c’est réseau vs. nœud local ?

Si df -h et timedatectl sont corrects, alors pvecm status + journalctl -u corosync pointeront normalement directement vers réseau/adhésion.

7) J’ai un cluster à deux nœuds. Est-ce normal de perdre le quorum si un nœud est down ?

Oui. Le quorum à deux nœuds est délicat par conception. Si vous voulez un comportement de panne propre, utilisez un qdevice/témoin pour que le cluster puisse encore prendre une décision de majorité.

8) pmxcfs est monté en lecture seule. Comment le forcer en lecture-écriture ?

La plupart du temps, la lecture seule indique une perte de quorum ou une instabilité. La « solution » est de restaurer le quorum. Forcer des écritures sans quorum risque un split-brain de configuration.

9) L’interface Proxmox dit « cluster not ready » mais les services semblent actifs. Et maintenant ?

Vérifiez le montage de /etc/pve, le quorum et si les services API sont sains. Beaucoup d’erreurs UI sont simplement des problèmes pmxcfs/quorum reflétés via l’API.

10) Après la récupération, un nœud affiche encore une ancienne configuration. Est-ce possible ?

Oui — surtout après des partitions ou si quelqu’un a fait des modifications locales pendant que pmxcfs était arrêté. Confirmez l’appartenance, la version de configuration, et évitez la réconciliation manuelle à moins d’être certain de l’état faisant autorité.

Étapes suivantes pour éviter les récidives

Remettre pve-cluster en marche n’est que la moitié du travail. Le garder en état stable est l’autre moitié.

• Donnez à Corosync un chemin réseau stable. VLAN dédié si possible, MTU cohérent de bout en bout, pas de « surprises » de pare-feu.
• Corrigez le temps comme s’il était critique en production (parce que c’est le cas). Supervisez la synchronisation NTP ; alertez sur la dérive.
• Surveillez le quorum et le point de montage pmxcfs. Alertez quand Quorate: No ou quand findmnt /etc/pve n’affiche pas pmxcfs.
• Arrêtez de construire des clusters à deux nœuds sans témoin. Si le budget ne permet que deux nœuds, prévoyez un petit troisième vote.
• Rédigez votre ordre de récupération. Corosync/quorum d’abord, puis pve-cluster, puis les services API. Ne faites pas d’improvisation en cas de panne.

Si vous ne retenez qu’une seule habitude opérationnelle : avant de toucher la configuration, confirmez que /etc/pve est monté et que le cluster est quoré. Cette simple vérification évite une quantité remarquable de dégâts auto-infligés.