Proxmox « cluster non prêt — pas de quorum ? » : restaurer le quorum sans empirer

Ce que signifie vraiment le quorum dans Proxmox (et pourquoi il vous bloque)

Le clustering Proxmox repose sur Corosync pour l’appartenance et la messagerie, ainsi que sur pmxcfs (Proxmox Cluster File System)
pour répliquer la configuration (configs VM, définitions de stockage, règles de pare-feu, utilisateurs, etc.) entre les nœuds. Lorsqu’on perd le quorum, Proxmox arrête volontairement
les modifications « cluster-étendues » parce qu’il ne peut pas savoir en toute sécurité s’il détient la seule vérité valable.

Pensez au quorum comme à la capacité du cluster à répondre avec confiance à une question : « Sommes-nous la vue majoritaire légitime ? »
Sans cela, deux moitiés d’une partition peuvent chacune croire qu’elles sont aux commandes. C’est le split-brain. Le split-brain n’est pas un modèle d’architecture glamour ;
c’est juste de la corruption déguisée.

Dans Proxmox, la perte de quorum se manifeste généralement par :

• Bannière UI : « cluster non prêt — pas de quorum ? »
• Erreurs CLI : erreurs pvesh / pveproxy, impossibilité d’écrire dans /etc/pve
• Opérations VM bloquées : en particulier les workloads gérés par HA
• État étrange du stockage : parce qu’une partie de la config vit dans /etc/pve

Notez la nuance : vos VM peuvent continuer de fonctionner. Votre stockage peut être intact. Votre réseau peut être opérationnel.
La perte de quorum est principalement un problème de coordination du cluster. Le danger est qu’elle vous incite à prendre des mesures qui créent un problème de données.

Une citation à garder en tête pendant les incidents de cluster :
« L’espoir n’est pas une stratégie. » — Gene Kranz

Blague #1 : Le quorum, c’est comme une réunion qui ne compte que si assez de personnes sont présentes. Pour une fois, c’est le cluster qui fait preuve de sérieux.

Carnet de diagnostic rapide (vérifications 1/2/3)

Quand vous êtes en plein incident, vous n’avez pas besoin de théorie. Vous devez trouver rapidement le goulet d’étranglement, choisir la voie de récupération la moins risquée,
et éviter les « correctifs » qui ne fonctionnent que parce que vous n’avez pas remarqué la seconde panne.

Première étape : confirmez que c’est vraiment le quorum, pas un problème d’UI ou de proxy

• Exécutez pvecm status sur le nœud où vous êtes.
• Vérifiez systemctl status pve-cluster corosync.
• Vérifiez si /etc/pve est monté et réactif.

Deuxième étape : déterminez la réalité de l’appartenance (qui est vivant, qui peut communiquer)

• Exécutez pvecm nodes.
• Vérifiez l’état de l’anneau Corosync (corosync-cfgtool -s ou corosync-quorumtool -s).
• Depuis chaque nœud, testez les interfaces d’anneau avec ping/arping et validez les routes/VLAN.

Troisième étape : décidez de la classe de récupération

Choisissez une des options suivantes, dans cet ordre de préférence :

1. Restaurer les nœuds manquants ou le réseau afin que le cluster d’origine retrouve naturellement le quorum.
2. Ajuster temporairement les votes attendus uniquement pour correspondre à la réalité dont vous pouvez prouver la sécurité.
3. Dernier recours : forcer un nœud unique à devenir opérationnel le temps de stabiliser (en acceptant explicitement le risque).
4. Récupération après sinistre : reconstruire le cluster et réintégrer les nœuds, après avoir gelé l’état ancien.

Si vous ne pouvez pas articuler dans quelle classe de récupération vous vous trouvez, vous n’êtes pas prêt à taper des commandes qui modifient le quorum.

Faits intéressants et contexte (pourquoi c’est comme ça)

• Fait 1 : Le « quorum » dans Corosync est fourni par le service votequorum, qui décide si la partition a suffisamment de votes pour fonctionner.
• Fait 2 : Le /etc/pve de Proxmox est un système de fichiers distribué (pmxcfs) stocké en RAM et synchronisé via Corosync ; ce n’est pas un répertoire normal.
• Fait 3 : Le mécanisme des « votes attendus » existe parce que les clusters changent de taille ; il peut aussi être abusé pour « convaincre » une partition qu’elle a le quorum.
• Fait 4 : Les clusters à deux nœuds sont intrinsèquement délicats pour le quorum : sans un troisième vote, une partition ne distingue pas « le pair est tombé » de « le lien est tombé ».
• Fait 5 : L’idée du quorum et du vote majoritaire remonte à des décennies dans les systèmes distribués, et c’est un compromis pratique : la sécurité plutôt que la disponibilité pendant les partitions.
• Fait 6 : Corosync utilise des identifiants d’anneau et des transitions d’appartenance ; des changements fréquents d’anneau signifient généralement perte de paquets, mismatch MTU ou liens instables.
• Fait 7 : Le HA de Proxmox utilise l’état du cluster ; si le quorum est perdu, le HA refuse généralement d’agir « intelligemment » parce que l’intelligence est la façon la plus sûre de démarrer deux fois une VM.
• Fait 8 : Le concept de qdevice (tiers d’arbitrage) existe surtout parce que des organisations insistent sur des clusters à nombre pair puis s’étonnent lorsque la physique intervient.

Blague #2 : Un cluster à deux nœuds sans arbitre, c’est comme deux managers qui se disputent sur Slack. Le seul gagnant, c’est le canal d’incident.

Règles de sécurité : faites ceci avant de toucher à quoi que ce soit

1) Décidez ce que vous protégez : intégrité des VM, intégrité du stockage, ou juste l’interface

Si le stockage est partagé (Ceph, SAN, NFS, iSCSI), le risque principal est que deux nœuds croient posséder la même ressource en écriture.
Si le stockage est local (ZFS par nœud), le risque se déplace vers la dérive de configuration et des opérations HA ratées plutôt que vers la corruption brute des blocs.

2) Geler l’automatisation

Si vous exécutez une automatisation externe qui modifie la configuration Proxmox (Terraform, Ansible, scripts appelant l’API), mettez-la en pause.
Les incidents de quorum sont des moments où l’idempotence meurt car le cluster n’accepte pas les écritures de façon cohérente.

3) Ne « corrigez » pas en redémarrant tout

Un redémarrage peut parfois débloquer un état figé, mais il peut aussi détruire les preuves dont vous aviez besoin : logs, transitions d’anneau, ou le seul nœud qui avait la configuration correcte.
Traitez les redémarrages comme des interventions contrôlées, pas comme une thérapie.

4) Si le stockage partagé est impliqué, établissez les faits de fencing

Si vous avez des LUN partagés ou des exports NFS montés en lecture-écriture par plusieurs nœuds, vous devez savoir s’il existe un mécanisme de fencing :
contrôle IPMI, réservations SCSI au niveau du SAN, règles OSD Ceph, etc. Si la réponse est « euh », ne forcez pas le quorum à la légère.

Tâches pratiques avec commandes : lire, décider, agir

Ci-dessous se trouvent des tâches réelles que vous pouvez exécuter sur un nœud Proxmox. Chaque étape inclut : commande, sortie d’exemple, ce que cela signifie, et la décision à prendre.
Utilisez-les comme une méthode d’investigation, pas comme une liste d’incantations magiques.

Task 1: Confirm quorum state and expected votes

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

Quorum information
------------------
Date:             2025-12-25 10:14:18
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          No

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

Sens : Cette partition a 1 vote mais en attend 3 ; le quorum requiert 2. Vous n’êtes pas quorate.

Décision : Ne touchez pas au HA ni à la config cluster-wide. Ensuite, déterminez où sont passés les deux autres votes : nœuds tombés ou partition réseau.

Task 2: See what nodes the cluster thinks exist

cr0x@pve1:~$ pvecm nodes
Membership information
----------------------
Nodeid      Votes Name
0x00000001      1 pve1
0x00000002      1 pve2
0x00000003      1 pve3

Sens : La configuration du cluster attend trois nœuds avec un vote chacun.

Décision : Si pve2/pve3 sont désaffectés intentionnellement, vous devez effectuer un changement d’appartenance contrôlé. S’ils sont censés être vivants, rétablissez d’abord leur accessibilité.

Task 3: Check corosync service health on the local node

cr0x@pve1:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Thu 2025-12-25 10:01:03 UTC; 13min ago
       Docs: man:corosync
   Main PID: 1189 (corosync)
      Tasks: 10
     Memory: 45.2M
        CPU: 7.412s

Sens : Corosync tourne. Ce n’est pas « le service est mort » ; c’est « le service ne voit pas assez de pairs ».

Décision : Concentrez-vous sur la santé réseau/anneau/peer, pas sur un redémarrage aveugle.

Task 4: Check pve-cluster and pmxcfs readiness

cr0x@pve1:~$ 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 Thu 2025-12-25 10:01:10 UTC; 13min ago
   Main PID: 1260 (pmxcfs)
      Tasks: 12
     Memory: 78.0M
        CPU: 3.201s

Sens : pmxcfs tourne, mais peut être en mode partiellement lecture seule pour les écritures du cluster faute de quorum.

Décision : Validez si /etc/pve est accessible et si les écritures sont bloquées.

Task 5: Confirm /etc/pve is mounted (and not wedged)

cr0x@pve1:~$ mount | grep /etc/pve
pve on /etc/pve type fuse.pve (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Sens : pmxcfs est monté. C’est bon.

Décision : S’il manque, vous avez un problème local plus sérieux (pmxcfs non monté), pas seulement une perte de quorum.

Task 6: Check if cluster filesystem is writable (practically)

cr0x@pve1:~$ touch /etc/pve/.rw-test
touch: cannot touch '/etc/pve/.rw-test': Read-only file system

Sens : Sans quorum, pmxcfs refuse les écritures (comportement courant).

Décision : Arrêtez d’essayer d’« éditer pour vous en sortir ». Restaurez d’abord le quorum, ou utilisez une procédure de récupération contrôlée en nœud unique si c’est la voie choisie.

Task 7: Look at Corosync ring status (link-level signal)

cr0x@pve1:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 10.10.10.11
        status:
                nodeid:          1:     connected
                nodeid:          2:     disconnected
                nodeid:          3:     disconnected

Sens : pve1 est connecté à lui-même mais ne parvient pas à atteindre pve2/pve3 sur le réseau d’anneau.

Décision : Confirmez la joignabilité du réseau d’anneau (IP, VLAN, MTU, pare-feu) avant de toucher aux votes.

Task 8: Check for packet loss and MTU mismatch on the ring

cr0x@pve1:~$ ping -c 5 -M do -s 8972 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500

--- 10.10.10.12 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4087ms

Sens : Vous avez tenté un jumbo ping et découvert un MTU 1500 sur le chemin émetteur. Si vous attendiez des jumbo frames, vous avez trouvé une cause réelle.

Décision : Alignez le MTU de bout en bout sur le réseau Corosync (ports de switch, bonds, interfaces VLAN). Corosync n’aime pas la fragmentation mystérieuse.

Task 9: Validate basic reachability to peers (don’t skip the boring part)

cr0x@pve1:~$ ping -c 3 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.602 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.581 ms
64 bytes from 10.10.10.12: icmp_seq=3 ttl=64 time=0.594 ms

--- 10.10.10.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2041ms
rtt min/avg/max/mdev = 0.581/0.592/0.602/0.009 ms

Sens : La connectivité IP existe, du moins pour ICMP. C’est nécessaire mais pas suffisant.

Décision : Si ICMP fonctionne mais Corosync affiche toujours déconnecté, suspectez un filtrage UDP, un routage asymétrique ou un bindnetaddr incorrect.

Task 10: Check corosync logs for membership churn and token timeouts

cr0x@pve1:~$ journalctl -u corosync -n 50 --no-pager
Dec 25 10:12:02 pve1 corosync[1189]:   [KNET  ] host: 2 (passive) link: 0 is down
Dec 25 10:12:03 pve1 corosync[1189]:   [TOTEM ] A processor failed, forming new configuration.
Dec 25 10:12:04 pve1 corosync[1189]:   [QUORUM] Members[1]: 1
Dec 25 10:12:04 pve1 corosync[1189]:   [QUORUM] This node is within the non-primary component and will NOT provide service.

Sens : KNET link down vers l’hôte 2, et le sous-système quorum refuse le service. C’est la preuve que le problème vient du réseau ou d’un nœud distant down.

Décision : Réparez le chemin réseau physique/virtuel ou remettez le nœud distant en ligne, puis attendez la stabilisation de l’appartenance.

Task 11: Inspect Corosync configuration (bindnetaddr and node list)

cr0x@pve1:~$ cat /etc/pve/corosync.conf
totem {
  version: 2
  cluster_name: prod-cluster
  transport: knet
  interface {
    linknumber: 0
    bindnetaddr: 10.10.10.0
    mcastport: 5405
  }
}

nodelist {
  node {
    name: pve1
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.10.10.11
  }
  node {
    name: pve2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.10.10.12
  }
  node {
    name: pve3
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.10.10.13
  }
}

quorum {
  provider: corosync_votequorum
}

Sens : Corosync attend le réseau d’anneau sur 10.10.10.0/24. Si les nœuds ont changé de sous-réseau, d’IP ou de tag VLAN, l’appartenance cassera.

Décision : Si les IP ont changé, restaurez-les ou mettez à jour corosync.conf en utilisant un nœud quorate (ou une méthode de récupération contrôlée). N’éditez pas à la main tant que pmxcfs est instable.

Task 12: Determine if the missing nodes are actually down

cr0x@pve1:~$ ssh root@10.10.10.12 "uptime && systemctl is-active corosync && pvecm status | sed -n '1,20p'"
 10:15:41 up 12 days,  3:22,  2 users,  load average: 0.22, 0.18, 0.15
active
Cluster information
-------------------
Name:             prod-cluster
Config Version:   12
Transport:        knet
Secure auth:      on

Sens : pve2 est en ligne et corosync est actif. Pourquoi pve1 est-il déconnecté ? Probablement une partition réseau, un pare-feu ou un routage asymétrique.

Décision : Exécutez les mêmes vérifications d’anneau depuis pve2. Vous voulez des preuves symétriques (pve2 ne voit pas pve1 non plus, ou voit quelque chose de différent).

Task 13: Confirm UDP port reachability (Corosync traffic) via tcpdump

cr0x@pve1:~$ tcpdump -ni vmbr1 udp port 5405 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:16:02.112233 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256
10:16:03.113244 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256
10:16:04.114255 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256

Sens : Les paquets sortants partent. Si vous ne voyez pas de réponses entrantes, le problème est entre les nœuds (ACL, switch, routage, ou pare-feu du pair).

Décision : Capturez aussi sur pve2 en simultané. Si pve2 voit les paquets entrants mais les réponses disparaissent, suspectez un routage asymétrique ou un filtrage en amont.

Task 14: Check host firewall status (PVE firewall can bite)

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

Sens : Le pare-feu est actif. Ce n’est pas mauvais en soi ; c’est juste une variable.

Décision : Vérifiez que les règles autorisent Corosync sur l’interface d’anneau. Si vous avez durci récemment les règles de pare-feu, c’est un suspect majeur.

Task 15: Confirm cluster communication isn’t blocked by time drift

cr0x@pve1:~$ timedatectl
               Local time: Thu 2025-12-25 10:16:55 UTC
           Universal time: Thu 2025-12-25 10:16:55 UTC
                 RTC time: Thu 2025-12-25 10:16:55
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : La synchronisation horaire est saine sur ce nœud. Corosync ne vérifie pas la validité TLS de vos paquets, mais la dérive horaire corrèle avec « tout est étrange », y compris l’auth et les logs.

Décision : Si un nœud est en retard de plusieurs minutes, corrigez NTP avant de vous fier aux diagnostics horodatés.

Task 16: As a controlled action, set expected votes (temporary) to regain quorum

cr0x@pve1:~$ pvecm expected 1
Setting expected votes to 1

Sens : Vous avez dit à votequorum de n’attendre qu’1 vote. Cela peut rendre cette partition quorate immédiatement.

Décision : Ne le faites que si vous êtes certain que les autres nœuds sont down ou que vous les avez fenceés. Sinon, vous risquez d’avoir deux partitions quorates simultanément (c’est le film d’horreur).

Task 17: Validate quorum after the change

cr0x@pve1:~$ pvecm status | grep -E "Quorate|Expected votes|Total votes|Quorum"
Quorate:          Yes
Expected votes:   1
Total votes:      1
Quorum:           1

Sens : Le nœud est maintenant quorate (selon sa nouvelle attente).

Décision : Profitez de cette fenêtre pour stabiliser la configuration du cluster, mais prévoyez de revenir aux votes attendus une fois le cluster réintégré.

Task 18: Remove a dead node cleanly (when the cluster is quorate)

cr0x@pve1:~$ pvecm delnode pve3
Removing node pve3 from cluster

Sens : L’appartenance du cluster est mise à jour ; les votes attendus et les mathématiques du quorum changent en conséquence.

Décision : Ne faites cela que lorsque vous avez décidé que pve3 est définitivement parti (ou sera réinstallé et réintégré). Ne faites pas delnode comme test de ping.

Task 19: Check pmxcfs health after quorum restoration

cr0x@pve1:~$ ls -la /etc/pve/nodes
total 0
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 .
drwxr-xr-x 1 root www-data 0 Dec 25 10:18 ..
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 pve1
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 pve2

Sens : Le répertoire nodes reflète les membres actuels du cluster ; c’est un contrôle de cohérence du FS du cluster.

Décision : Si des nœuds apparaissent/disparaissent de façon inattendue, arrêtez-vous et investiguez le flap d’appartenance avant de faire des modifications de config.

Task 20: If HA is configured, check manager status before unblocking operations

cr0x@pve1:~$ systemctl status pve-ha-lrm pve-ha-crm --no-pager
● pve-ha-lrm.service - PVE Local Resource Manager Daemon
     Active: active (running)
● pve-ha-crm.service - PVE Cluster Resource Manager Daemon
     Active: active (running)

Sens : Les agents HA tournent. Cela ne veut pas dire qu’ils sont sûrs d’agir maintenant ; cela veut dire qu’ils agiront une fois le quorum revenu et l’état convergé.

Décision : Passez en revue les ressources HA et assurez-vous de ne pas déclencher de migrations/démarrages inattendus au moment où le quorum revient.

Voies de récupération : choisissez l’option la moins risquée

« Restaurer le quorum » n’est pas une seule action. C’est une famille de mouvements avec différents rayons d’impact.
Voici comment je choisis sous pression.

Voie A (meilleure) : restaurer le réseau et/ou ramener les nœuds manquants

Si les nœuds sont sains mais déconnectés, réparez le réseau Corosync. C’est la résolution la plus propre car elle préserve l’historique d’appartenance et évite les astuces spéciales sur le quorum.
Coupables typiques : VLAN mal tagué, mismatch de mode de bond, mismatch MTU, erreur LACP, règles de pare-feu, ou un redémarrage de switch revenu avec un profil de port différent.

Une fois la connectivité rétablie, l’appartenance Corosync devrait converger, votequorum redeviendra quorate, pmxcfs redeviendra inscriptible, et la vie reprendra.
Si l’appartenance continue de flapper, n’effectuez pas de changements de configuration. Réparez d’abord la stabilité.

Voie B (acceptable) : ajuster temporairement les votes attendus

pvecm expected est un outil, pas un mode de vie. Il est approprié lorsque :

• Vous avez un cluster multi-nœuds, mais suffisamment de nœuds sont hors ligne de façon permanente pour que vous ne puissiez pas retrouver rapidement la majorité.
• Vous pouvez prouver que l’autre côté ne pourra pas non plus déclarer le quorum (car il est éteint, fenceé, ou isolé du stockage partagé en écriture).
• Vous devez retrouver la capacité d’écriture du cluster pour effectuer de la maintenance (delnode, corriger corosync.conf via pmxcfs, ajuster le HA, planifier une maintenance).

Ce n’est pas approprié lorsque vous suspectez simplement que les autres sont down. Le soupçon est pour les romans policiers, pas pour les mathématiques du cluster.

Voie C (haut risque) : forcer un nœud unique à opérer

Parfois vous avez un nœud survivant et vous devez remettre des services en ligne. Le risque est que lorsque le réseau se rétablit, vous ayez deux « vérités » divergentes de la config du cluster.
Si vous prenez cette voie, vous devez appliquer des mesures de confinement :

• Confirmez que les autres nœuds sont down ou fenceés.
• Désactivez les actions HA si elles pouvaient démarrer des doublons.
• Si un stockage partagé existe, assurez-vous qu’un seul côté peut écrire (fencing, verrou d’export, masquage de LUN SAN).

En pratique, beaucoup « règlent » le quorum en forçant, puis découvrent plus tard que le HA a redémarré une VM ailleurs pendant qu’ils la démarraient localement.
Ce n’est pas une réparation du quorum ; c’est une page de choix de désastre.

Voie D (reconstruction) : quand le cluster a perdu toute cohérence

Si pmxcfs est incohérent, que plusieurs nœuds ont été forcés en quorum isolément, ou que la config corosync a divergé, vous êtes peut-être en territoire de reconstruction :
choisissez un nœud source de vérité, capturez les configurations, réinstallez/recréez le cluster, réintégrez les nœuds et réintroduisez le HA prudemment.
C’est plus lent, mais souvent la seule façon de retrouver la confiance dans le système.

Trois mini-récits d’entreprise (douleur réaliste incluse)

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

Une entreprise de taille moyenne gérait un cluster Proxmox à trois nœuds. Deux nœuds étaient dans la même baie ; le troisième était « à proximité » dans une autre rangée.
L’anneau Corosync utilisait un VLAN dédié. Quelqu’un a effectué une maintenance sur un switch et a déplacé temporairement quelques ports d’accès vers un VLAN par défaut.
La carte d’anneau du troisième nœud s’est retrouvée sur le mauvais VLAN. Le nœud est resté en ligne, les VM ont continué de tourner, la supervision montrait l’hôte sain.

Le lendemain matin, quelqu’un a vu « cluster non prêt — pas de quorum ? » sur l’un des nœuds locaux à la baie. Leur hypothèse : « pve3 doit être down. »
Ils n’ont pas vérifié depuis pve3. Ils ont lancé pvecm expected 1 sur pve1 et ont immédiatement retrouvé l’UI et l’accès en écriture à /etc/pve.
Victoire, non ?

Pas tout à fait. pve3 était en réalité vivant et toujours connecté à pve2 de façon intermittente via un autre chemin accidentel à cause d’un second changement réseau.
Il y avait maintenant des moments où deux partitions devenaient brièvement « confiantes » dans des réalités différentes. Des modifications de config (pare-feu et stockage) ont été appliquées d’un côté uniquement.

Quand le VLAN a été corrigé, le cluster s’est reformé et l’équipe a obtenu un ensemble de symptômes étranges : VM manquantes dans l’UI sur un nœud, définitions de stockage désynchronisées,
et erreurs de permission sporadiques. Ils ont passé des heures à « réparer des permissions » qui étaient en fait des symptômes de divergence de config durant la fenêtre de quorum forcé.

La correction a été ennuyeuse : revenir aux votes attendus réels, stabiliser la connectivité d’anneau, puis réconcilier la config depuis des sauvegardes et depuis un nœud choisi comme source de vérité.
La leçon : ne modifiez pas la mathématique du quorum sur des hypothèses concernant l’état des nœuds. Prouvez-le.

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

Une autre organisation voulait « accélérer le trafic cluster » et a décidé d’activer les jumbo frames sur leur réseau de virtualisation.
Ils ont changé le MTU sur les bridges et bonds Proxmox. Ils l’ont changé sur les switches top-of-rack.
Ils ne l’ont pas modifié sur quelques ports de trunk VLAN intermédiaires parce qu’ils étaient gérés par une autre équipe et que « ça doit être standard ».

Pendant un certain temps, tout semblait OK. Le trafic VM allait bien. Le stockage allait généralement bien.
Corosync, en revanche, a commencé à flapper sous charge. Des changements d’appartenance se produisaient durant les fenêtres de sauvegarde.
Le quorum tombait, revenait, retombait. Le HA s’est mis en alerte et a cessé d’agir ; les opérateurs ont commencé à redémarrer des nœuds.

Le flapping n’était pas aléatoire. Le trafic Corosync était fragmenté ou perdu à travers le chemin MTU non uniforme.
Parce que Corosync est conçu pour protéger la cohérence, il a traité la perte de paquets comme une menace d’appartenance. Et c’en était une.

L’« optimisation » a abouti à un cluster techniquement plus rapide mais opérationnellement moins fiable. Ils sont revenus à MTU 1500 sur l’anneau Corosync et ont gardé les jumbo frames
pour le stockage uniquement, où ils pouvaient prouver la cohérence de bout en bout.

Le point : optimisez là où vous pouvez valider. Corosync n’est pas impressionné par vos graphiques de débit si vos paquets n’arrivent pas de façon cohérente.

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

Une entreprise proche de la finance (donc : audits, contrôle des changements et longues réunions) gérait un cluster Proxmox à cinq nœuds.
Ils avaient une habitude que les ingénieurs se moquaient : un runbook imprimé d’une page avec les IPs de l’anneau Corosync, les ports de switch et les adresses IPMI de chaque nœud.
Il était mis à jour trimestriellement, signé et plastifié. Oui, plastifié.

Un après-midi, une unité de distribution d’alimentation a lâché et a mis hors service deux nœuds. Un autre nœud est resté en ligne mais a perdu son uplink de switch d’anneau suite à une reconnexion spanning-tree.
Le cluster est tombé à deux nœuds accessibles sur cinq. Pas de quorum. L’UI s’est énervée. Les téléphones ont chauffé.

Au lieu de forcer le quorum, l’on-call a fait trois choses rapidement : vérifier quels nœuds étaient vraiment éteints via IPMI, confirmer le problème d’anneau sur les nœuds restants,
et utiliser le runbook pour identifier l’uplink exact du switch à vérifier. Ils n’ont pas eu besoin de deviner. Ils n’ont pas eu besoin de « découvrir » la topologie pendant l’incident.

L’uplink a été remis, le troisième nœud a rejoint, le quorum est revenu naturellement (3/5) et ils ont évité toute manœuvre de vote forcé.
Plus tard, ils ont remis en service les deux nœuds morts et ont laissé le cluster se stabiliser. Drame minimal.

La leçon : l’inventaire ennuyeux et l’hygiène de topologie battent l’improvisation. Aussi, les runbooks plastifiés ne sont pas glamours, mais un postmortem split-brain non plus.

Erreurs courantes : symptôme → cause → correctif

1) Symptom: « cluster not ready – no quorum? » after a network change

Cause : Réseau de l’anneau Corosync cassé (VLAN, MTU, bond/LACP, pare-feu).

Correctif : Utilisez corosync-cfgtool -s, tcpdump et des pings MTU pour confirmer la perte ; restaurez la cohérence L2/L3 ; ne changez pas les votes en premier.

2) Symptom: One node sees quorum, another does not

Cause : Partition, routage asymétrique, ou un nœud a forcé les votes attendus localement.

Correctif : Comparez pvecm status sur chaque nœud ; annulez les réglages de votes forcés ; assurez-vous que tous les nœuds partagent la même vue d’appartenance avant de modifier la configuration du cluster.

3) Symptom: /etc/pve is read-only or writes fail

Cause : Pas de quorum, ou pmxcfs est malade à cause d’une instabilité Corosync.

Correctif : Restaurez le quorum (préféré) ou utilisez un changement contrôlé de votes attendus ; puis confirmez la stabilité de l’appartenance avant d’éditer la config du cluster.

4) Symptom: Quorum drops intermittently (flapping)

Cause : Perte de paquets, mismatch MTU, lien instable, interface d’anneau surchargée, ou réseau virtualisé bruyant.

Correctif : Traitez cela comme un incident de fiabilité réseau : mesurez la perte, vérifiez les erreurs sur les switches, désactivez les offloads problématiques si nécessaire, et envisagez de dédier un anneau propre à Corosync.

5) Symptom: Two-node cluster loses quorum whenever one node reboots

Cause : Mathématique du quorum à deux nœuds : la majorité de 2 est 2 ; perdre un vote signifie pas de quorum.

Correctif : Ajoutez un troisième vote (qdevice ou troisième nœud). Si vous devez rester à deux nœuds, acceptez des sémantiques de cluster limitées et planifiez des procédures de maintenance soigneuses.

6) Symptom: After “fixing quorum,” HA starts/shuts down VMs unexpectedly

Cause : Réconciliation d’état HA après des changements d’appartenance ; les ressources peuvent être dans des états obsolètes.

Correctif : Avant de restaurer le quorum, passez en revue les ressources HA ; envisagez de mettre les services en mode maintenance ; restaurez le quorum, puis validez les décisions HA avant de réactiver l’automatisation.

7) Symptom: Cluster looks fine, but nodes can’t join or keep rejoining

Cause : Mauvais corosync.conf (adresses node), IDs de nœud dupliqués, hostnames obsolètes, ou clés d’auth mismatched.

Correctif : Validez /etc/pve/corosync.conf sur le nœud faisant autorité ; assurez-vous d’un nodeid unique et des adresses d’anneau correctes ; réintégrez les nœuds proprement plutôt que de bricoler.

Listes de contrôle / plan pas à pas

Checklist 1: « Je viens de voir no quorum » (à faire en 5 minutes)

1. Sur le nœud affecté : exécutez pvecm status. Faites une capture ou copiez la sortie dans le journal d’incident.
2. Exécutez pvecm nodes pour confirmer l’appartenance attendue.
3. Exécutez corosync-cfgtool -s pour voir qui est déconnecté.
4. Vérifiez journalctl -u corosync -n 50 pour des messages link-down.
5. Depuis le nœud, pingez les IPs d’anneau des pairs manquants. Si le ping échoue, arrêtez-vous et réparez le réseau ou l’alimentation.
6. Si le ping fonctionne, lancez tcpdump -ni <ring-if> udp port 5405 pendant que vous testez depuis le pair aussi.

Checklist 2: « Dois-je utiliser pvecm expected ? » (porte de décision)

1. Les nœuds manquants sont-ils confirmés éteints (IPMI) ou fencés ? Si non : ne le faites pas.
2. Y a-t-il un stockage partagé en écriture qui pourrait être monté par les deux partitions ? Si oui : ne le faites pas sauf si le stockage est fenceé/verrouillé.
3. Avez-vous besoin d’effectuer des écritures cluster-wide (delnode, corriger corosync.conf via pmxcfs, ajuster le HA) immédiatement ? Si non : attendez et réparez le réseau.
4. Avez-vous un plan explicite pour revenir aux votes attendus quand les nœuds reviendront ? Si non : rédigez le plan d’abord.

Checklist 3: Restauration contrôlée du quorum (workflow plutôt sûr)

1. Stabiliser l’appartenance : réparez le réseau d’anneau jusqu’à ce que corosync-cfgtool -s montre les pairs connectés et que les logs cessent de flapper.
2. Confirmer le quorum : pvecm status montre Quorate: Yes avec les votes attendus correspondant à la taille réelle du cluster.
3. Valider les écritures /etc/pve : créez et supprimez un fichier test dans /etc/pve (ou vérifiez les éditions via l’UI).
4. Vérifier le HA : assurez-vous que les services HA sont sains et qu’aucune action inattendue n’est en attente.
5. Ensuite seulement : effectuez les changements de cluster (supprimer nœuds morts, changer config stockage, modifier règles pare-feu).

Checklist 4: Si vous devez faire fonctionner un nœud unique temporairement

1. Confirmez que les autres nœuds sont down via IPMI ou physiquement déconnectés du réseau d’anneau.
2. Si un stockage partagé existe : assurez-vous que seul ce nœud peut écrire (désactiver exports, retirer mappings LUN ou appliquer fencing).
3. Ajustez les votes attendus uniquement pour la durée nécessaire. Documentez la modification dans la timeline d’incident.
4. Évitez de faire des modifications massives de config cluster en état forcé ; faites le minimum pour restaurer les workloads critiques.
5. Quand les autres nœuds reviennent, revenez aux votes attendus et surveillez la convergence d’appartenance avant de réactiver HA et l’automatisation.

FAQ

1) Est-ce que « no quorum » signifie que mes VM sont corrompues ?

Généralement non. Cela signifie que la coordination du cluster est dangereuse. Les VM peuvent continuer de tourner, surtout sur stockage local.
Le risque de corruption augmente si vous démarrez/arrêtez la même VM depuis plusieurs partitions ou si le stockage partagé est écrire-des deux côtés.

2) Puis-je juste redémarrer corosync pour régler le problème ?

Redémarrer corosync peut aider si le processus est bloqué, mais cela corrige rarement la cause réelle (partition réseau, MTU, pare-feu, pair down).
De plus, redémarrer un composant pendant un flap peut provoquer plus de churn. Diagnostiquez d’abord ; redémarrez avec intention.

3) Que fait exactement « pvecm expected » ?

Il définit le nombre total de votes attendu utilisé pour calculer le quorum. Le réduire peut rendre une plus petite partition quorate.
C’est puissant et dangereux : vous pouvez créer une situation où deux partitions pensent toutes deux être majoritaires si vous l’exécutez des deux côtés.

4) Pourquoi les clusters Proxmox à deux nœuds sont-ils si pénibles ?

Parce que la majorité de 2 est 2. Si l’un des nœuds est inaccessible, aucun des deux ne peut prouver qu’il a la majorité.
Sans arbitre, le comportement le plus sûr est d’arrêter les écritures du cluster. C’est ce que vous voyez.

5) Ai-je besoin d’un qdevice ?

Si vous avez deux nœuds et que vous voulez un comportement de quorum propre, oui : ajoutez un qdevice (ou un troisième nœud) pour fournir un troisième vote.
Si vous avez déjà trois nœuds ou plus, un qdevice est optionnel mais peut aider dans certaines architectures.

6) Pourquoi /etc/pve est-il spécial ?

C’est pmxcfs : un système de fichiers de cluster monté via FUSE, basé sur un état distribué. Il est conçu pour empêcher les écritures non sûres quand l’appartenance est incertaine.
Traitez-le comme une base de données, pas comme un dossier local.

7) Après le retour du quorum, pourquoi tout semble « lent » pendant un moment ?

L’appartenance se reforme, l’état converge, le HA recalcul, et les services rétablissent les connexions.
Si vous aviez du flapping, vous pouvez avoir un arriéré de tentatives. Donnez-lui une minute, mais surveillez les logs pour tout churn persistant.

8) Comment savoir si je suis à risque de split-brain ?

Si vous ne pouvez pas prouver qu’une seule partition peut accéder aux ressources partagées en écriture, vous êtes à risque.
Un autre signal d’alerte : des nœuds affichent des vues d’appartenance différentes ou des votes attendus différents. C’est comme ça que le split-brain commence — silencieusement.

9) Est-il sûr d’éditer corosync.conf directement ?

Ce n’est sûr que lorsque vous avez un cluster quorate (pour que le changement se propage de façon cohérente) ou pendant une récupération contrôlée en nœud unique où vous comprenez
que vous créez une nouvelle source de vérité. Les éditions aléatoires pendant l’absence de quorum sont un excellent moyen de produire un état de cluster incohérent.

10) Si un seul nœud reste et que j’ai besoin de l’UI pour gérer les VM, que faire ?

Vous pouvez utiliser les votes attendus pour retrouver le quorum sur ce nœud, mais seulement après avoir confirmé que les autres nœuds sont down ou fenceés.
Ensuite, gardez les modifications minimales et planifiez comment réintroduire proprement les autres nœuds.

Conclusion : prochaines étapes concrètes

La perte de quorum, c’est Proxmox qui vous rend service : il refuse de vous laisser créer un état de cluster incohérent.
Votre travail consiste à restaurer d’abord la connectivité et l’appartenance, puis à restaurer la commodité.

Prochaines étapes qui aident vraiment :

1. Exécutez le carnet de diagnostic rapide et identifiez si la panne est due à l’alimentation, au réseau ou à une divergence de configuration.
2. Réparez la stabilité du réseau Corosync avant de changer les votes. Traitez le flapping comme un incident réseau, pas comme un incident Proxmox seul.
3. Si vous devez utiliser pvecm expected, faites-le de façon contrôlée, documentée et limitée dans le temps avec des faits de fencing.
4. Une fois stable, réduisez la douleur future : évitez les clusters à deux nœuds sans arbitre, gardez Corosync sur un réseau propre, et documentez la topologie comme si votre vie en dépendait.

Si vous retenez une chose : ne forcez pas le quorum tant que vous ne pouvez pas expliquer où sont passés tous les autres votes.
Cette explication fait la différence entre une récupération et de l’archéologie.