Proxmox « système de fichiers du cluster non prêt » : pourquoi cela arrive et comment le réparer

Ce que signifie réellement « système de fichiers du cluster non prêt »

Dans Proxmox VE, le « système de fichiers du cluster » n’est pas votre CephFS, NFS, ZFS, ni quoi que ce soit monté sous /mnt. C’est pmxcfs, un système de fichiers en espace utilisateur (FUSE) qui vit à /etc/pve. C’est là que Proxmox stocke et distribue la configuration du cluster : définitions de nœuds, configurations VM, config de stockage, config corosync, règles de pare-feu et toute une série de métadonnées d’état.

Quand Proxmox indique que le système de fichiers du cluster n’est pas prêt, il vous dit :

• /etc/pve n’est pas monté correctement (pmxcfs n’est pas en cours ou bloqué), ou
• pmxcfs fonctionne mais refuse de servir une configuration modifiable parce que le cluster n’est pas dans un état cohérent (souvent un problème de quorum ou corosync), ou
• pmxcfs ne peut pas fonctionner à cause de problèmes locaux du nœud (disque plein, pression mémoire, saut horaire, blocage FUSE).

L’interface et la plupart des actions CLI parlent à /etc/pve. Si ce point de montage est absent ou en lecture seule, Proxmox ne peut pas modifier l’état du cluster en toute sécurité. C’est pourquoi vous voyez des erreurs apparemment sans rapport : « impossible d’analyser la config de stockage », « impossible d’écrire le fichier », « échec du verrouillage de fichier », etc. Elles découlent toutes du même goulot d’étranglement : pmxcfs ne fournit pas le système de fichiers de configuration.

Comment pmxcfs et /etc/pve fonctionnent (et pourquoi c’est sensible)

pmxcfs est le petit moteur derrière la configuration du cluster. Il tourne en tant que démon, monte un système de fichiers FUSE à /etc/pve, et réplique les changements entre nœuds en utilisant la couche de communication du cluster (corosync). Il conserve aussi une copie locale afin qu’un nœud puisse encore démarrer et exécuter des VMs même si les autres sont hors ligne — dans une certaine mesure.

Principes opérationnels clés

• /etc/pve n’est pas un répertoire normal. C’est un point de montage vivant. « Corriger » en éditant les fichiers pendant que pmxcfs est arrêté peut être soit intelligent soit désastreux, selon ce que vous touchez.
• Le quorum compte. Dans un cluster multi-nœuds, Proxmox veut un accord majoritaire avant d’autoriser les écritures de configuration. Ce n’est pas du pédantisme ; cela empêche la divergence en situation de split-brain.
• Corosync est le transport. Si corosync ne peut pas former un membership stable, pmxcfs ne sera généralement pas « prêt », ou il sera en lecture seule.
• La latence, la perte de paquets et la dérive temporelle ne sont pas des « problèmes réseau », ce sont des « problèmes d’intégrité du cluster ». La pile cluster les traite comme des menaces pour la cohérence parce que c’est bien ce qu’elles sont.

Voici le modèle opérationnel à garder en tête :

1. Le système démarre.
2. corosync tente de former le membership du cluster.
3. pve-cluster (pmxcfs) monte /etc/pve.
4. pvedaemon/pveproxy (API/UI) lisent et écrivent la configuration sous /etc/pve.

Si vous cassez le point 2, le point 3 vacille. Si vous cassez le point 3, le point 4 devient une scène de crime.

Une idée paraphrasée, attribuée à Werner Vogels (fiabilité et systèmes distribués) : « tout échoue, donc vous concevez en partant du principe que ça arrivera » (idée paraphrasée).

Blague #1 : Un cluster Proxmox sans quorum, c’est comme une réunion sans compte rendu — chacun s’en souvient différemment, et personne n’est d’accord sur ce qui s’est passé.

Mode opératoire de diagnostic rapide

Si vous avez cinq minutes et un pager qui vibre votre bureau en miettes, ne vous éparpillez pas. Exécutez ceci dans l’ordre. Chaque étape réduit le goulot.

Première étape : /etc/pve est‑il monté et pmxcfs est‑il actif ?

• Vérifiez le point de montage et l’état de pve-cluster. Si pmxcfs est mort ou que le montage manque, vous êtes en territoire « nœud local » : crash de service, blocage FUSE, disque plein, pression mémoire.

Deuxième étape : le quorum corosync et le membership sont‑ils sains ?

• Vérifiez pvecm status et corosync-cfgtool. Si le quorum est perdu, décidez si vous pouvez restaurer le réseau/pairs, ou si vous devez forcer temporairement le quorum (rarement la bonne décision à long terme).

Troisième étape : le temps et le réseau sont‑ils suffisamment stables pour le consensus ?

• Vérifiez la synchronisation temporelle (timedatectl) et les logs corosync pour retransmissions, timeouts de token, basculements de lien. Corrigez la dérive horaire et la perte de paquets avant de redémarrer les services ; autrement vous ne faites que produire de nouveaux logs.

Quatrième étape : le nœud lui‑même est‑il malade (disque/RAM/IO) ?

• Vérifiez l’utilisation disque (df), l’usage d’inodes, la pression mémoire et les blocages IO. pmxcfs est léger mais pas magique ; il peut tomber si la pression est extrême.

Cinquième étape : s’agit‑il d’un split brain ou d’une isolation d’un seul nœud ?

• Si plusieurs nœuds prétendent être primaires/actifs avec des memberships incohérents, stoppez et planifiez. Le split brain est l’endroit où les « corrections rapides » deviennent des événements de carrière.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les vérifications que j’exécute réellement. Chacune indique ce que la sortie implique et quelle décision prendre ensuite. Lancez-les d’abord sur le nœud affecté, puis sur un nœud connu sain pour comparaison.

Task 1: Confirm /etc/pve is mounted as pmxcfs

cr0x@server:~$ mount | grep -E '(/etc/pve|pmxcfs)'
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

Sens : Si vous voyez fuse.pmxcfs, le montage existe. Si rien ne retourne, l’erreur UI est expliquée : pmxcfs n’est pas monté.

Décision : Si manquant, passez aux vérifications du service pve-cluster (Task 2) et aux logs (Task 3). Si présent mais toujours « non prêt », regardez le quorum et corosync (Tasks 5–8).

Task 2: Check pve-cluster (pmxcfs) service health

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 Fri 2025-12-26 09:41:18 UTC; 3min ago
   Main PID: 1187 (pmxcfs)
      Tasks: 3 (limit: 154214)
     Memory: 38.2M
        CPU: 1.012s
     CGroup: /system.slice/pve-cluster.service
             └─1187 /usr/bin/pmxcfs

Sens : S’il n’est pas actif/en cours, pmxcfs ne sert pas /etc/pve. S’il clignote, vous avez probablement un problème sous-jacent corosync/temps/disque.

Décision : Si failed, inspectez les logs (Task 3), puis redémarrez prudemment (Task 4) après avoir compris pourquoi il a échoué.

Task 3: Read pve-cluster logs for the real complaint

cr0x@server:~$ journalctl -u pve-cluster -n 200 --no-pager
Dec 26 09:41:18 server pmxcfs[1187]: [main] notice: starting pmxcfs
Dec 26 09:41:18 server pmxcfs[1187]: [main] notice: resolved node name 'server' to '10.10.0.11'
Dec 26 09:41:19 server pmxcfs[1187]: [dcdb] notice: data verification successful
Dec 26 09:41:20 server pmxcfs[1187]: [status] notice: quorum not present - operations restricted
Dec 26 09:41:20 server pmxcfs[1187]: [status] notice: continuing in local mode

Sens : « quorum not present » est votre titre. pmxcfs peut monter, mais il peut être en lecture seule ou restreindre les opérations. Si vous voyez des messages de corruption de base de données, c’est une autre situation.

Décision : Si le quorum manque, passez aux vérifications corosync/quorum (Tasks 5–8). Si la corruption est mentionnée, planifiez la récupération et les sauvegardes avant de toucher quoi que ce soit.

Task 4: Restart pve-cluster (only after reading logs)

cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ systemctl is-active pve-cluster
active

Sens : Si le redémarrage réussit et que le montage apparaît, vous êtes peut‑être de retour. S’il échoue immédiatement, vous n’avez pas corrigé la cause — retournez aux logs et à corosync.

Décision : Si les échecs sont répétés, arrêtez de redémarrer. Corrigez le temps/réseau/quorum ou l’épuisement de ressources d’abord.

Task 5: Check cluster quorum and membership

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

Quorum information
------------------
Date:             Fri Dec 26 09:44:02 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.1
Quorate:          Yes

Sens : Quorate: Yes est ce que vous voulez. S’il indique No, pmxcfs restreindra probablement les écritures et l’UI criera.

Décision : Si non quorate, vérifiez quels nœuds sont visibles (Task 6) et pourquoi les liens sont coupés (Tasks 7–8).

Task 6: List nodes and see who’s missing

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve-a (local)
         2          1 pve-b
         3          1 pve-c

Sens : Les nœuds manquants expliquent la perte de quorum. Si un seul nœud apparaît dans un cluster 2‑ ou 3‑nœuds, vous êtes isolé.

Décision : Si des nœuds manquent, vérifiez les liens corosync (Task 7) et la portée réseau (Task 9).

Task 7: Check corosync ring link status

cr0x@server:~$ corosync-cfgtool -s
Printing link status.
Local node ID 1
LINK ID 0
        addr    = 10.10.0.11
        status  = connected
LINK ID 1
        addr    = 172.16.0.11
        status  = disconnected

Sens : Ceci montre quels réseaux corosync sont opérationnels. Un anneau déconnecté peut être acceptable si vous aviez prévu de la redondance, ou fatal s’il s’agit de votre seul chemin fonctionnel.

Décision : Si l’unique anneau est en panne, corrigez le réseau ou le routage/VLAN/MTU avant de toucher à la configuration corosync.

Task 8: Look for corosync token timeouts and retransmits

cr0x@server:~$ journalctl -u corosync -n 200 --no-pager
Dec 26 09:42:10 pve-a corosync[1050]: [TOTEM ] Token has not been received in 15000 ms
Dec 26 09:42:10 pve-a corosync[1050]: [TOTEM ] Retransmit List: 12
Dec 26 09:42:11 pve-a corosync[1050]: [KNET  ] link: host: 2 link: 0 is down
Dec 26 09:42:12 pve-a corosync[1050]: [QUORUM] Members[1]: 1

Sens : Token non reçu + lien down signifie que corosync ne peut pas maintenir le membership. C’est généralement une perte réseau, un mauvais MTU, ou un switch qui fait des choses « utiles » au multicast/unicast.

Décision : Traitez cela comme un incident réseau en priorité. Ne « forcez » pas le quorum pour contourner un transport instable à moins d’aimer le chaos.

Task 9: Verify L2/L3 reachability between nodes (and catch MTU pain)

cr0x@server:~$ ping -c 3 10.10.0.12
PING 10.10.0.12 (10.10.0.12) 56(84) bytes of data.
64 bytes from 10.10.0.12: icmp_seq=1 ttl=64 time=0.435 ms
64 bytes from 10.10.0.12: icmp_seq=2 ttl=64 time=0.401 ms
64 bytes from 10.10.0.12: icmp_seq=3 ttl=64 time=0.398 ms

--- 10.10.0.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2022ms
rtt min/avg/max/mdev = 0.398/0.411/0.435/0.016 ms

Sens : La portée basique est nécessaire mais pas suffisante. Corosync peut échouer en raison de jitter/perte que ping n’expose pas.

Décision : Si ping échoue, corrigez l’adressage/VLAN/routage. Si ping réussit mais corosync est instable, testez le MTU et la perte de paquets sous charge.

Task 10: Check time sync (corosync hates time travel)

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

Sens : Vous voulez System clock synchronized: yes. Une dérive significative peut contribuer à l’instabilité du membership et à des logs confus.

Décision : Si non synchronisé, corrigez NTP/chrony/systemd-timesyncd. Puis redémarrez corosync/pve-cluster si nécessaire.

Task 11: Check disk space and inode exhaustion (silent killers)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/pve/root    96G   92G  0.0G 100% /

Sens : Un système de fichiers root plein provoque des pannes étranges des services, y compris pmxcfs et le logging. Même si pmxcfs est principalement en mémoire, le système autour a besoin d’espace.

Décision : Libérez de l’espace immédiatement (logs, anciens noyaux, cache ISO). Puis revérifiez la santé des services.

cr0x@server:~$ df -ih /
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/pve/root    6.1M  6.1M     0  100% /

Sens : L’épuisement d’inodes ressemble à un « disque plein » mais c’est pire parce que les petits fichiers ne peuvent plus être créés, y compris les fichiers de verrouillage et d’état.

Décision : Trouvez et supprimez les répertoires contenant des millions de fichiers (coupables fréquents : logs en boucle, sauvegardes mal configurées, overlays de conteneurs).

Task 12: Check memory pressure and OOM kills

cr0x@server:~$ journalctl -k -n 100 --no-pager | grep -E 'Out of memory|Killed process' || true
Dec 26 09:35:07 pve-a kernel: Out of memory: Killed process 28814 (pveproxy) total-vm:620004kB, anon-rss:112344kB

Sens : Si le kernel tue pveproxy/pvedaemon/corosync, votre « système de fichiers du cluster non prêt » est un dommage collatéral dû à la famine en ressources.

Décision : Corrigez la pression : arrêtez les processus gourmands, ajoutez du swap (prudemment), réduisez l’overcommit, et enquêtez sur la charge qui a déclenché l’OOM.

Task 13: Confirm /etc/pve is writable (and not lying)

cr0x@server:~$ touch /etc/pve/.pmxcfs-write-test && echo "ok"
ok
cr0x@server:~$ rm -f /etc/pve/.pmxcfs-write-test

Sens : Si touch échoue avec « Read-only file system » ou « Input/output error », pmxcfs est monté mais pas sain pour les écritures.

Décision : La lecture seule signifie souvent absence de quorum. Les erreurs IO suggèrent un montage FUSE bloqué ou une défaillance interne de pmxcfs — retournez aux logs et envisagez de redémarrer pve-cluster après avoir corrigé les problèmes sous-jacents.

Task 14: Inspect corosync config consistency (do not edit yet)

cr0x@server:~$ sed -n '1,120p' /etc/pve/corosync.conf
totem {
  version: 2
  cluster_name: prod-cluster
  transport: knet
  interface {
    linknumber: 0
    bindnetaddr: 10.10.0.0
  }
}

nodelist {
  node {
    name: pve-a
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.10.0.11
  }
  node {
    name: pve-b
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.10.0.12
  }
  node {
    name: pve-c
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.10.0.13
  }
}

Sens : Vous vérifiez les erreurs évidentes : IP erronées, bindnetaddr incorrect, nœud manquant, nodeid dupliqué. Confirmez aussi que vous pouvez lire le fichier ; sinon pmxcfs ne le sert pas.

Décision : Si la config est erronée à cause d’un changement connu, planifiez une correction contrôlée. Les éditions aléatoires pendant une perte de quorum sont la manière dont on manufacture un split brain.

Task 15: See if pveproxy/pvedaemon are failing because /etc/pve is down

cr0x@server:~$ systemctl status pveproxy pvedaemon --no-pager
● pveproxy.service - PVE API Proxy Server
     Active: active (running) since Fri 2025-12-26 09:41:22 UTC; 6min ago
● pvedaemon.service - PVE API Daemon
     Active: active (running) since Fri 2025-12-26 09:41:21 UTC; 6min ago

Sens : Ces services peuvent être « en marche » tout en générant des erreurs parce qu’ils ne peuvent pas lire la configuration du cluster de manière fiable.

Décision : Si l’UI est cassée mais que les services tournent, vérifiez leurs logs pour des échecs de lecture/écriture sur « /etc/pve » puis concentrez-vous à nouveau sur pmxcfs/corosync.

Causes racines par sous-système

1) Perte de quorum (la plus courante, et généralement un comportement correct)

Le quorum n’est pas une punition ; c’est une ceinture de sécurité. Sans quorum, un cluster ne peut pas être sûr que la configuration que vous vous apprêtez à écrire ne sera pas en conflit avec un autre nœud faisant la même chose. pmxcfs répond en restreignant les opérations. L’interface interprète cela comme « système de fichiers du cluster non prêt », car de son point de vue, elle ne peut pas faire son travail.

Déclencheurs typiques :

• Un nœud en panne dans un cluster à 2 nœuds (il n’y a pas de majorité).
• Partition réseau (les nœuds ne se voient pas ; les deux côtés peuvent penser que l’autre est mort).
• Interface corosync down, changement de VLAN, problème de switch, mismatch MTU.
• Dérive horaire combinée à un réseau instable provoquant des changements de membership.

Patron de réparation : restaurez le membership (ramenez les nœuds, réparez le réseau), ou ajoutez un dispositif de quorum pour les petits clusters, ou repensez l’architecture pour éviter les clusters à 2 nœuds sans qdevice.

2) Instabilité du transport corosync (knet, basculements de lien, et « ça ping bien »)

Corosync n’a pas besoin seulement de connectivité ; il a besoin d’une livraison prévisible. La perte de paquets, les micro-burst, le bufferbloat ou un pare-feu « intelligent » sur le chemin peuvent provoquer des timeouts de token. Quand cela arrive, le membership change constamment, et pmxcfs devient nerveux ou refuse d’être prêt.

Patron de réparation : mettez corosync sur un réseau dédié et ennuyeux. Pas de NAT. Pas de pare-feu stateful entre les nœuds. MTU identique. Évitez le routage asymétrique. Si vous avez besoin de redondance, utilisez plusieurs liens de façon intentionnelle et testez la bascule.

3) Dérive horaire (l’ingrédient furtif)

Les systèmes distribués n’exigent pas un temps parfait, mais ils exigent que le temps ne fasse pas des sauts. Si un nœud a une horloge à plusieurs minutes d’écart, ou si NTP ajuste l’horloge de manière agressive, vous pouvez obtenir des séquences de logs bizarres, des authentifications étranges et un comportement instable du cluster.

Patron de réparation : configurez une synchronisation fiable sur chaque nœud ; privilégiez le lissage progressif ; n’exécutez pas des démons temps incompatibles qui se battent entre eux.

4) Épuisement de ressources locales du nœud (disque plein, inodes épuisés, OOM, blocages IO)

pmxcfs est petit, mais il vit dans un OS réel. Si le root est plein, journald ne peut plus écrire, les services échouent au démarrage et les montages FUSE peuvent se comporter mal. Si la mémoire est tendue, l’OOM tue la mauvaise chose au mauvais moment. Si le stockage se bloque, les processus attendent, y compris corosync.

Patron de réparation : traitez cela comme la cause d’une panne de nœud. Libérez de l’espace, corrigez le logging, arrêtez le processus incontrôlé, puis redémarrez les services.

5) Montage FUSE ou état bloqué de pmxcfs

Parfois pmxcfs est « en marche » mais le montage /etc/pve est bloqué. Vous voyez des erreurs IO, des longues attentes sur ls /etc/pve, ou des processus coincés en état D. Cela peut être causé par des problèmes noyau/FUSE, une pression extrême, ou un deadlock interne de pmxcfs.

Patron de réparation : stabilisez d’abord le nœud (CPU/IO/mémoire), puis redémarrez pve-cluster. Si le point de montage ne se démonte pas proprement, un reboot du nœud peut être nécessaire (oui, vraiment).

6) Divergence de configuration et split brain

Le split brain survient lorsque des parties du cluster ne sont pas d’accord sur le membership et poursuivent indépendamment. En termes Proxmox, ce sont des nœuds qui écrivent des versions concurrentes de la « vérité » sous /etc/pve. La plateforme travaille dur pour l’éviter ; les administrateurs peuvent encore contourner ces garanties en forçant le quorum, en copiant des configs ou en ramenant des nœuds dans le mauvais ordre.

Patron de réparation : arrêtez les écritures, choisissez une source de vérité et réconciliez prudemment. Souvent cela signifie arrêter la partition minoritaire, restaurer la connectivité, et s’assurer que le cluster se forme avec les votes attendus.

Blague #2 : « Forcer le quorum » est la version systèmes distribués de « tiens ma bière ».

Trois mini-histoires d’entreprise (anonymisées, plausibles et pédagogiques)

Incident #1 : une mauvaise hypothèse (le piège des deux nœuds)

Ils avaient un joli petit cluster Proxmox : deux nœuds, stockage partagé, et la croyance rassurante que « si l’un des nœuds survit, on est sauvé ». Ça a tourné des mois. Puis un switch top-of-rack a redémarré lors d’un déploiement de firmware, et un nœud a perdu la connectivité cluster pendant quelques minutes.

Quand le réseau est revenu, l’équipe a trouvé « système de fichiers du cluster non prêt » sur le nœud isolé. Pas de migrations. Pas d’éditions de stockage. Certaines opérations VM fonctionnaient encore localement, mais tout ce qui impliquait la config du cluster était bloqué. L’astreinte a supposé que le système de fichiers du cluster était « un montage de stockage » et a commencé à vérifier le NFS. Le NFS était OK ; le problème n’était pas là.

La mauvaise hypothèse était subtile : ils pensaient que « deux nœuds » impliquait naturellement « redondant ». Dans la logique du quorum, deux nœuds implique « égalité ». Une égalité n’est pas une décision, c’est un blocage poli.

Ils l’ont « résolu » en forçant expected votes à 1 sur le nœud isolé, ont édité la config, puis ont reconnecté le second nœud. Maintenant les deux nœuds avaient fait des changements indépendamment. Ça n’a pas explosé instantanément. C’est devenu une divergence lente de configuration : entrées de stockage incompatibles, ressources HA incohérentes, et une fenêtre de maintenance ultérieure transformée en casse-tête.

La solution finale fut banale : ajouter un dispositif de quorum et cesser de traiter deux nœuds comme un vrai cluster sans tiebreaker. Ils ont aussi réaffecté corosync sur un VLAN dédié. Le grand gain n’était pas la disponibilité ; c’était que le cluster a cessé de se disputer sur la réalité.

Incident #2 : une optimisation qui s’est retournée contre eux (jumbo frames et le token disparu)

Une autre organisation voulait réduire la charge CPU et améliorer le débit sur leur « réseau de cluster », ils ont activé les jumbo frames de bout en bout. Sauf que ce n’était pas du bout en bout. Un port de switch intermédiaire est resté à MTU 1500 car il faisait partie d’un trunk legacy et personne ne voulait y toucher en heures ouvrables.

Le trafic VM a à peine remarqué. TCP sait négocier et récupérer. Corosync a remarqué tout de suite, car il dépend d’une livraison en temps voulu. Il n’a pas échoué proprement. Il a basculé : timeouts de token, retransmissions, membres coupés et réintégrés. Toutes les quelques minutes quelqu’un voyait « système de fichiers du cluster non prêt » dans l’UI, puis ça se réglait, puis ça revenait.

L’équipe avait optimisé pour la performance et a accidentellement optimisé la fiabilité hors de l’équation. Pire, le symptôme ne pointait pas vers le MTU ; il pointait vers Proxmox. Ils ont redémarré les services pendant des heures, ce qui a surtout produit de nouvelles lignes de logs et une confiance fraîche que « c’est aléatoire ».

La réparation a été simple : rendre le MTU cohérent. Pas « plus grand », juste cohérent. Après cela, corosync a arrêté de dépasser les timeouts, le quorum s’est stabilisé, et pmxcfs est redevenu ennuyeux — ce qui, pour la distribution de config, est exactement ce qu’on veut.

Incident #3 : la pratique ennuyeuse mais correcte qui a sauvé la journée (NICs corosync dédiées et changements disciplinés)

Une société financière avait un cluster Proxmox dans une baie partagée où des changements réseau se produisaient souvent. Ils avaient déjà subi des problèmes, donc ils ont gardé le trafic corosync sur une paire de NIC dédiée, connectée à une paire de switches distincts, et documenté les IP et MTU exacts comme si c’était un contrat légal.

Un jour un incident facility a pris un switch. La moitié des serveurs de la baie a vu une perte de lien d’un côté. Leurs nœuds Proxmox ont loggé un lien down, mais corosync est resté connecté sur le second lien. Le quorum n’a jamais chuté. pmxcfs n’est jamais devenu lecture seule. L’UI est restée fonctionnelle.

Ce qui a marché n’était pas de l’héroïsme. C’était qu’ils avaient conçu pour la panne ennuyeuse : perdre un switch. Ils avaient aussi une règle opérationnelle : pas d’édition de config corosync pendant un incident actif. Quand les choses vacillent, les humains prennent des décisions « créatives ». La règle a empêché cela.

Après l’incident, ils n’ont rien changé sauf remplacer le switch mort. Puis ils ont effectué un test de bascule contrôlé la semaine suivante pour confirmer le comportement. Ce n’était pas excitant. Et c’est le but.

Erreurs courantes : symptôme → cause → correctif

1) Symptom: UI banner “cluster filesystem not ready,” but VMs still run

Cause racine : pmxcfs restreint les écritures à cause d’une perte de quorum ; les charges peuvent s’exécuter localement, mais les changements de config cluster sont bloqués.

Correctif : restaurez le membership corosync et le quorum. Ramenez les nœuds manquants en ligne, réparez le réseau corosync, ou déployez un dispositif de quorum pour les petits clusters.

2) Symptom: ls /etc/pve hangs or returns “Input/output error”

Cause racine : le montage FUSE est bloqué, pmxcfs est coincé, ou le nœud subit une pression IO sévère.

Correctif : vérifiez les blocages IO et les logs noyau, puis redémarrez pve-cluster. Si le montage ne récupère pas, redémarrez le nœud après avoir géré les VMs (migrées ou arrêtées si stockage local).

3) Symptom: “quorum not present – operations restricted” in pve-cluster logs

Cause racine : le cluster n’a pas de majorité ; souvent un problème de conception à 2 nœuds ou une panne nœud/réseau.

Correctif : restaurez la connectivité du nœud manquant, ou ajoutez qdevice. Évitez de forcer expected votes à moins que vous exécutiez volontairement un mode mono‑nœud et compreniez le risque de split brain.

4) Symptom: corosync logs show token timeouts, retransmit list grows

Cause racine : perte de paquets, mismatch MTU, VLAN mal étiqueté, ou un pare‑feu/ACL interférant avec le trafic corosync.

Correctif : placez corosync sur un réseau dédié et stable ; validez la cohérence du MTU ; retirez les dispositifs stateful sur le chemin. Puis redémarrez corosync et confirmez un membership stable.

5) Symptom: services keep restarting; logs are sparse; “random” behavior

Cause racine : filesystem root plein ou épuisement d’inodes ; journald ne peut pas écrire, les services échouent de manière confuse.

Correctif : libérez immédiatement de l’espace / inodes. Puis redémarrez les services et revérifiez. Ne chassez pas des fantômes pendant que l’OS ne peut pas créer de fichiers.

6) Symptom: after “fixing,” cluster configs differ between nodes

Cause racine : quelqu’un a édité des configs alors que le nœud était isolé ou le quorum forcé, provoquant une divergence.

Correctif : arrêtez les écritures de config, établissez un nœud source de vérité, et réconciliez prudemment. Si nécessaire, rejoignez les nœuds dans une séquence contrôlée et vérifiez la progression des versions de config du cluster.

7) Symptom: only one node consistently shows “not ready” after reboots

Cause racine : mismatch nom d’hôte/IP, mauvais ring0_addr, résolution DNS cassée, ou renommage d’interface qui a changé l’interface utilisée par corosync.

Correctif : confirmez la résolution du nom, le bindnetaddr corosync, et l’interface correcte. Corrigez d’abord le réseau OS, puis corosync, puis pmxcfs.

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

Checklist A: Restore “ready” state safely (single affected node)

1. Arrêtez les modifications. Pas d’éditions de stockage, pas de jonctions de nœuds, pas de copies de fichiers aléatoires.
2. Vérifiez le montage : mount | grep /etc/pve. Si manquant, concentrez-vous sur pve-cluster.
3. Vérifiez le service : systemctl status pve-cluster et journalctl -u pve-cluster.
4. Vérifiez le quorum : pvecm status. Si non quorate, n’attendez pas une config modifiable.
5. Vérifiez corosync : journalctl -u corosync, corosync-cfgtool -s.
6. Vérifiez le temps : timedatectl.
7. Vérifiez disque/inodes : df -h /, df -ih /.
8. Puis seulement redémarrez : redémarrez corosync si le transport est corrigé ; redémarrez pve-cluster après que corosync soit stable.
9. Validez : pvecm status quorate, touch /etc/pve/test fonctionne, la bannière UI disparaît.

Checklist B: Two-node cluster “not ready” after a node outage

1. Considérez que la perte de quorum est un comportement attendu.
2. Ramenez le second nœud (ou réparez l’interconnexion) plutôt que de forcer les écritures.
3. Si c’est un problème opérationnel récurrent : implémentez un dispositif de quorum.
4. Documentez une règle stricte : « pas de quorum forcé pendant les incidents sauf approbation et enregistrement ».

Checklist C: Suspected split brain

1. Gelez les écritures de config. Empêchez les humains de « réparer » en éditant les fichiers du cluster.
2. Identifiez les partitions : quels nœuds voient quels membres (exécutez pvecm status sur chaque nœud).
3. Choisissez une source de vérité basée sur la partition majoritaire et la version de config la plus récente et cohérente.
4. Restaurez le réseau et assurez-vous que le cluster se forme en une seule membership.
5. Ce n’est qu’ensuite que vous réconciliez les configs divergentes. Vérifiez les définitions de stockage et les configs VM avant toute action HA.

Checklist D: When a reboot is the right answer

Le reboot est justifié quand :

• /etc/pve est bloqué et vous ne pouvez pas débloquer proprement FUSE.
• Le nœud est en fort IO wait ou présente des comportements étranges au niveau noyau (processus en état D) et les redémarrages de services n’aident pas.
• Les conditions OOM persistent et vous devez revenir à un état connu (après avoir réduit la charge).

Le reboot n’est pas justifié quand :

• Vous n’avez pas vérifié disque plein/inodes/temps/réseau et vous espérez juste.
• Le cluster est partitionné et redémarrer va remélanger les cartes sans restaurer la connectivité.

Faits intéressants et contexte historique (pour les curieux)

• pmxcfs est un système de fichiers FUSE, ce qui explique pourquoi /etc/pve se comporte différemment des répertoires normaux et peut « bloquer » quand le démon userspace est malade.
• La configuration de cluster de Proxmox est distribuée, pas basée sur un stockage partagé. Vous n’avez pas besoin d’un SAN pour la réplication de la config ; vous avez besoin de corosync qui fonctionne.
• Historiquement corosync s’appuyait sur le multicast dans de nombreuses configurations ; Proxmox moderne utilise souvent le transport knet, qui peut utiliser l’unicast et gère mieux les liens multiples.
• La logique de quorum existe pour prévenir le split brain, un mode de défaillance bien connu dans les anciens clusters HA où les deux moitiés croyaient être primaires et écrivaient des états contradictoires.
• Les clusters à deux nœuds sont fondamentalement ambigus sans un arbitre. Ce n’est pas une bizarrerie Proxmox ; c’est un problème mathématique des systèmes distribués portant un costume d’opérations.
• /etc/pve contient plus que les configs VM : définitions de stockage, règles de pare-feu et paramètres cluster globaux. Quand il est indisponible, l’impact semble plus large que « juste clustering ».
• La version de config dans pvecm status est un bon fil d’Ariane pendant les incidents : elle indique si les nœuds progressent ensemble ou divergent.
• La dérive horaire provoque des débogages « impossibles » parce que les logs ne s’alignent pas et les événements de membership semblent hors séquence ; les piles cluster tendent à amplifier cette confusion.

FAQ

1) Est‑ce que « système de fichiers du cluster non prêt » signifie que mes disques VM sont indisponibles ?

Non. Cela signifie généralement que /etc/pve (pmxcfs) n’est pas disponible pour les opérations de configuration. Vos disques VM peuvent être intacts. Mais les actions de gestion qui dépendent de la config du cluster peuvent échouer.

2) Puis‑je continuer à faire tourner des VMs quand le système de fichiers du cluster n’est pas prêt ?

Souvent oui. Les charges en cours ne s’arrêtent pas nécessairement. Le risque est opérationnel : vous ne pourrez peut‑être pas migrer, changer la config ou gérer HA proprement tant que pmxcfs et le quorum ne sont pas rétablis.

3) Pourquoi Proxmox bloque les écritures quand le quorum est perdu ?

Pour prévenir le split brain de configuration. Sans quorum, deux partitions pourraient accepter des changements et ensuite entrer en conflit. Bloquer les écritures est le choix sûr.

4) Est‑il sûr de forcer le quorum / expected votes à 1 ?

Cela peut être utile temporairement dans une urgence contrôlée sur un nœud unique, mais c’est risqué. Si un autre nœud est vivant et écrit aussi, vous pouvez créer une divergence. Traitez-le comme un dernier recours et documentez l’action.

5) Quelle est la différence entre corosync « up » et « quorate » ?

corosync « up » peut signifier que le démon tourne localement. « Quorate » signifie qu’il a formé un membership valide avec suffisamment de votes pour prendre des décisions. pmxcfs se soucie de la seconde condition.

6) Pourquoi cela arrive‑t‑il après un changement réseau qui « ne devrait pas affecter » Proxmox ?

Parce que corosync est extrêmement sensible à la perte de paquets, à l’incohérence de MTU et aux basculements de lien. Votre trafic VM peut survivre à un réseau approximatif ; le trafic de consensus l’est beaucoup moins.

7) Comment savoir si /etc/pve est réellement monté ou juste un répertoire ?

Exécutez mount | grep /etc/pve. Cela doit afficher fuse.pmxcfs. Si ce n’est pas le cas, vous ne regardez pas le système de fichiers du cluster.

8) Dois‑je réinstaller le nœud si pmxcfs est cassé ?

Presque jamais comme premier réflexe. La plupart des cas sont causés par le quorum/réseau/temps/pression disque. La réinstallation peut détruire des preuves et compliquer la récupération. Diagnostiquez d’abord.

9) Est‑ce que des problèmes Ceph peuvent provoquer « système de fichiers du cluster non prêt » ?

Indirectement. Si Ceph provoque une forte attente IO ou une pression sur le nœud, cela peut déstabiliser corosync et pmxcfs. Mais pmxcfs lui‑même n’est pas stocké sur Ceph.

10) Pourquoi l’UI affiche l’erreur alors que pve-cluster est actif ?

Parce qu’« actif » ne signifie pas « prêt pour des écritures sûres ». pmxcfs peut être monté mais opérer en mode restreint à cause d’un quorum perdu, ou il peut être bloqué tout en tournant.

Conclusion : prochaines étapes pratiques

Si vous ne retenez qu’une leçon opérationnelle de cette erreur, retenez celle‑ci : ne la traitez pas comme un problème de stockage ; traitez‑la comme un problème de consensus de cluster. Vérifiez si /etc/pve est monté, puis vérifiez le quorum et la santé de corosync, puis corrigez le temps/le réseau/la pression des ressources dans cet ordre.

Prochaines étapes qui rapportent :

• Si vous avez deux nœuds, ajoutez un dispositif de quorum. Ne pariez plus sur les égalités.
• Donnez à corosync un réseau dédié et ennuyeux. MTU stable, pas d’« appliances de sécurité » sur le chemin, liens redondants uniquement si vous pouvez les tester.
• Supervisez les choses ennuyeuses : disque/inodes sur root, statut de synchronisation NTP, et stabilité des liens corosync. L’erreur du système de fichiers du cluster est souvent le messager, pas le méchant.
• Écrivez une règle d’incident : pas de quorum forcé et pas d’éditions manuelles de config pendant une partition, sauf si un propriétaire unique est responsable et que le rayon d’impact est compris.