Proxmox « impossible d’initialiser le service CMAP » : checklist de dépannage Corosync/pmxcfs

L’erreur survient au pire moment : vous avez redémarré un nœud (ou il a redémarré tout seul), et maintenant le cluster semble « à moitié vivant ».
pve-cluster ne se comporte plus normalement, /etc/pve est vide ou en lecture seule, et les journaux de corosync répètent sans cesse :
cannot initialize CMAP service.

C’est l’un de ces échecs dans Proxmox où le stockage, le réseau et les systèmes distribués ont tous leur mot à dire. Si vous n’écoutez qu’un seul d’entre eux,
vous ne réparerez rien et vous apprendrez de nouveaux jurons. Ci-dessous une checklist de niveau production : triage rapide d’abord, puis isolation systématique, puis récupération sûre.

Ce que signifie réellement « cannot initialize CMAP service »

CMAP est la base de données clé-valeur interne de corosync pour la configuration et l’exécution. Pensez-y comme « l’interface mémoire partagée du cluster » pour les paramètres et l’état :
identifiants de nœud, appartenance aux anneaux, bits de quorum, temporisation de totem, journalisation, et plus encore. Lorsqu’un processus indique qu’il
cannot initialize CMAP service, il n’arrive pas à se connecter à l’API CMAP de corosync — généralement parce que corosync n’est pas lancé, est bloqué, redémarre,
ou que ses sockets IPC ne sont pas accessibles.

Dans les clusters Proxmox, cela apparaît le plus souvent selon ces schémas :

• Corosync est arrêté → pve-cluster ne peut pas lire l’appartenance au cluster → /etc/pve se comporte de façon erratique.
• Corosync ne peut pas former un anneau (réseau/MTU/firewall) → pas de quorum → le système de fichiers du cluster peut être en lecture seule ou non monté.
• Incohérence de configuration corosync ou mauvais nom/IP de nœud → corosync démarre mais ne peut pas rejoindre ses pairs → CMAP inutilisable par les démons dépendants.
• Dérive de l’heure ou interruptions extrêmes du scheduling → timeouts de jeton → basculements d’appartenance → échecs intermittents des consommateurs CMAP.

Traduction pratique : traitez les erreurs CMAP comme « corosync n’est pas suffisamment sain pour fournir l’état runtime du cluster ». Réparez d’abord la santé de corosync, puis pmxcfs,
et seulement ensuite touchez aux services Proxmox de plus haut niveau.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : décidez si vous avez un problème de cluster ou un problème mono-nœud

Le gain le plus rapide est de savoir si vous déboguez un crash d’un démon local ou une situation de split brain / quorum.
Lancez ces trois commandes sur le nœud défaillant et sur un nœud sain (si vous en avez un).

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

Sens : Si corosync est inactive/failed, les erreurs CMAP sont un symptôme, pas la maladie.
Si corosync est actif mais que les consommateurs se plaignent encore, vous cherchez des problèmes d’anneau/quorum/config.
Décision : Réparez d’abord corosync. Ne redémarrez pas pvedaemon, pveproxy, ou des services au hasard « pour voir ».

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

Quorum information
------------------
Date:             Thu Dec 25 12:07:21 2025
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.52
Quorate:          No

Sens : « Quorate: No » est votre titre. Sans quorum, pmxcfs peut refuser les écritures et certaines opérations de cluster échoueront.
Décision : Déterminez si le(s) nœud(s) manquant(s) sont réellement arrêtés, isolés par le réseau, ou mal configurés. Ne forcez pas le quorum à la légère.

cr0x@server:~$ journalctl -u corosync -b --no-pager | tail -n 40
Dec 25 12:05:12 pve1 corosync[1789]:   [TOTEM ] A processor failed, forming new configuration.
Dec 25 12:05:14 pve1 corosync[1789]:   [KNET  ] link: host: 2 link: 0 is down
Dec 25 12:05:18 pve1 corosync[1789]:   [QUORUM] Members[1]: 1
Dec 25 12:05:18 pve1 corosync[1789]:   [QUORUM] This node is within the non-primary component and will NOT provide any services.

Sens : C’est un classique partition réseau ou peer mort. KNET indique que le lien est down.
Décision : Arrêtez de penser à CMAP et commencez à penser au réseau corosync : routage, VLANs, MTU, firewall, état des liens.

Deuxième : prouvez que le chemin réseau du cluster est propre (pas seulement « ping fonctionne »)

Corosync utilise le multicast dans les anciennes configurations et le unicast (knet) dans les Proxmox modernes, typiquement sur UDP, avec des contraintes de temporisation strictes.
Une seule règle de firewall, un routage asymétrique ou un MTU incohérent peut laisser l’ICMP heureux tandis que corosync crame silencieusement.

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.10.11/24
eno2             UP             172.16.20.11/24

Sens : Identifiez l’interface réelle que corosync doit utiliser. Beaucoup de clusters dédient une NIC/VLAN à corosync — jusqu’à ce que quelqu’un « simplifie » tout.
Décision : Comparez avec /etc/pve/corosync.conf (ou la copie locale si pmxcfs est malsain) et vérifiez que l’adresse de ring correspond à la réalité.

Troisième : confirmez l’état de pmxcfs et si vous êtes bloqué en lecture seule

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

Sens : Si ce montage manque, est obsolète ou en lecture seule, Proxmox se comportera comme s’il avait perdu la mémoire.
Décision : Si corosync est cassé, pmxcfs peut ne pas se monter ou se monter mais refuser les écritures. Ne modifiez pas /etc/pve directement si ce n’est pas monté correctement.

Faits intéressants et contexte historique (pourquoi c’est ainsi)

• Le nom Corosync vient de « coros », une lignée de projets ancienne liée à la communication de groupe et à l’appartenance au cluster — ce sont des décennies de cicatrices en systèmes distribués.
• CMAP a remplacé des approches précédentes pour que les démons puissent lire et réagir à l’état du cluster via une API cohérente plutôt que de parser des fichiers en boucle.
• Le protocole Totem (utilisé par corosync) a été conçu pour maintenir la livraison ordonnée des messages et l’appartenance malgré les pannes — excellent quand tout va bien, impitoyable quand la temporisation part en vrille.
• Proxmox a choisi un système de fichiers FUSE (pmxcfs) pour distribuer rapidement des petits états de configuration, pas pour servir de stockage général.
• pmxcfs stocke la configuration « autoritaire » dans des fichiers SQLite/DB sous /var/lib/pve-cluster/ ; /etc/pve est la vue montée, pas le répertoire source original.
• Les règles de quorum proviennent des garanties classiques de consensus : mieux vaut refuser les écritures que d’accepter des mises à jour conflictuelles irréconciliables ensuite.
• Le transport knet est devenu la voie standard pour améliorer la gestion des liens et les capacités multi-lien par rapport aux anciens schémas orientés multicast.
• Beaucoup de « problèmes corosync » sont en réalité des problèmes d’horloge : le mécanisme basé sur des jetons est extrêmement sensible au jitter, à la famine CPU et aux sauts de temps.

Corosync + CMAP + pmxcfs : les composants que vous déboguez

Corosync : appartenance, messagerie, quorum

Corosync est le moteur d’appartenance du cluster. Il décide qui est dedans, qui est dehors, et à quel point il en est sûr.
Sa configuration se trouve dans corosync.conf. Son état runtime est exposé via CMAP. Si corosync ne peut pas fonctionner ou stabiliser l’appartenance, tout ce qui repose dessus
devient décoratif.

CMAP : interface d’état runtime

CMAP est l’endroit où corosync expose la configuration et l’état aux clients. Les composants Proxmox et les outils de corosync le consultent.
Quand vous voyez « cannot initialize CMAP service », le client n’a pas réussi à se connecter à l’interface runtime de corosync — souvent via des sockets IPC.
C’est pourquoi l’erreur peut apparaître même sur un « cluster » à nœud unique après une mise à jour ou un problème de permission/SELinux/AppArmor (rare sur Proxmox), ou après un crash laissant des sockets obsolètes.

pmxcfs : le système de fichiers du cluster Proxmox

pmxcfs est un système de fichiers FUSE monté sur /etc/pve. C’est là que Proxmox attend la configuration du cluster :
définitions de stockage, configuration du pare-feu, configurations de VM, configuration de cluster, domaines d’utilisateurs. Il dépend de corosync pour les décisions d’appartenance et de quorum.

Si corosync est arrêté ou que vous n’êtes pas quorate, pmxcfs peut :

• ne pas se monter du tout, laissant /etc/pve comme un répertoire vide ou un montage obsolète,
• se monter en lecture seule, rendant les écritures impossibles de manière déroutante,
• se monter mais n’afficher que l’état local du nœud si vous êtes isolé, selon la manière dont la panne est survenue.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : Tout échoue, tout le temps ; construisez des systèmes qui s’y attendent et récupèrent rapidement.

Blague #1 : Corosync, c’est comme une invitation à une réunion. Si la moitié des participants ne peut pas se connecter, personne ne peut modifier l’ordre du jour.

Tâches pratiques (commandes, sortie attendue, décisions)

Voici les tâches que j’exécute réellement quand quelqu’un écrit « CMAP service » à 02:00. Chaque tâche inclut ce que signifie la sortie et quelle décision prendre ensuite.
Exécutez-les sur le nœud défaillant d’abord, puis comparez avec un nœud sain si disponible.

Tâche 1 : Vérifier l’état des services et les échecs récents

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-25 12:01:03 UTC; 4min ago
       Docs: man:corosync
    Process: 1732 ExecStart=/usr/sbin/corosync -f $COROSYNC_OPTIONS (code=exited, status=1/FAILURE)

Sens : Corosync n’est pas en cours d’exécution ; les erreurs CMAP sont attendues.
Décision : Allez directement aux journaux et à la validation de la configuration. Ne redémarrez pas tout ; réparez la première domino.

Tâche 2 : Lire les journaux corosync avec contexte, pas seulement la dernière ligne

cr0x@server:~$ journalctl -u corosync -b --no-pager -n 200
Dec 25 12:00:58 pve1 corosync[1732]:   [CFG   ] Parsing config file '/etc/corosync/corosync.conf'
Dec 25 12:00:58 pve1 corosync[1732]:   [CFG   ] No valid name found for nodeid 1
Dec 25 12:00:58 pve1 corosync[1732]:   [MAIN  ] Corosync Cluster Engine exiting with status 8 at main.c:1835.

Sens : Incohérence de configuration : mappage nodeid ou nodelist incorrect.
Décision : Validez le nodelist, les noms de nœuds et les adresses d’anneau. Ne touchez pas encore aux réglages de quorum ; vous avez une erreur de configuration déterministe.

Tâche 3 : Confirmer quel corosync.conf vous utilisez réellement

Dans un cluster sain, la configuration canonique se trouve typiquement sous /etc/pve/corosync.conf (vue du système de fichiers du cluster), et corosync lit
/etc/corosync/corosync.conf qui est généralement un lien symbolique vers /etc/pve. Quand pmxcfs est cassé, ce lien peut pointer dans le vide.

cr0x@server:~$ ls -l /etc/corosync/corosync.conf /etc/pve/corosync.conf
lrwxrwxrwx 1 root root 17 Dec 25 11:58 /etc/corosync/corosync.conf -> /etc/pve/corosync.conf
-rw-r----- 1 root www-data 512 Dec 25 11:57 /etc/pve/corosync.conf

Sens : Le lien symbolique est correct et le fichier existe dans /etc/pve.
Décision : Si /etc/pve/corosync.conf est manquant ou illisible, vous devez le restaurer à partir des fichiers locaux de la base de données du cluster ou des sauvegardes.

Tâche 4 : Valider la syntaxe de la configuration corosync

cr0x@server:~$ corosync -t
Parsing of config file successful

Sens : La syntaxe est correcte. Cela ne prouve pas que la configuration est juste ; cela prouve seulement qu’elle se parse.
Décision : Si l’analyse échoue, corrigez la syntaxe avant toute autre action. Si l’analyse réussit, concentrez-vous sur la sémantique : IPs, node IDs, liens, crypto, MTU.

Tâche 5 : Vérifier l’appartenance et le quorum via les outils Proxmox

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   18
Transport:        knet

Quorum information
------------------
Nodes:            3
Node ID:          0x00000001
Quorate:          Yes

Sens : Si ceci retourne proprement et indique qu’il y a quorum, CMAP est probablement fonctionnel, et votre erreur peut venir d’un service dépendant démarré trop tôt.
Décision : Si corosync est sain, pivotez vers pmxcfs et l’ordre de démarrage des services ; vérifiez les journaux de pve-cluster.

Tâche 6 : Interroger corosync runtime depuis les outils CMAP directement

cr0x@server:~$ corosync-cmapctl | head
runtime.config.totem.token (u32) = 3000
runtime.config.totem.token_retransmits_before_loss_const (u32) = 10
runtime.config.totem.consensus (u32) = 3600
runtime.totem.pg.mrp.srp.members (str) = 1 2 3

Sens : Si cela fonctionne, CMAP est accessible. Si cela échoue avec une erreur d’initialisation CMAP, corosync n’est pas atteignable via IPC.
Décision : Si CMAP est inaccessible mais que corosync affiche « active », suspectez des problèmes de permissions/sockets, un répertoire runtime obsolète, ou des boucles de redémarrage rapides.

Tâche 7 : Inspecter les sockets runtime de corosync et leurs permissions

cr0x@server:~$ ls -ld /run/corosync /run/corosync/* 2>/dev/null | head
drwxr-xr-x  2 root root  80 Dec 25 12:06 /run/corosync
srwxrwx---  1 root root   0 Dec 25 12:06 /run/corosync/corosync.sock
srwxrwx---  1 root root   0 Dec 25 12:06 /run/corosync/cmap.sock

Sens : Les sockets existent. Si les sockets manquent, les clients CMAP ne peuvent pas se connecter. Si les permissions sont trop restrictives, les clients non-root peuvent échouer.
Décision : Sockets manquants → corosync n’est pas réellement lancé ou est bloqué tôt. Permissions étranges → vérifiez l’intégrité du paquet et les durcissements locaux.

Tâche 8 : Confirmer la santé du montage pmxcfs et les messages d’erreur

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 Thu 2025-12-25 12:03:11 UTC; 3min ago
   Main PID: 2011 (pmxcfs)

Sens : pmxcfs est en cours d’exécution, mais il peut quand même être en lecture seule à cause de l’absence de quorum.
Décision : Vérifiez le quorum et testez la capacité d’écriture en toute sécurité (créez un fichier temporaire dans un emplacement sûr comme /etc/pve/nodes/<node>/ si approprié).

Tâche 9 : Détecter un système de fichiers cluster en lecture seule (sans deviner)

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

Sens : pmxcfs est monté mais refuse les écritures. Cela correspond généralement à l’absence de quorum ou au mode de protection local.
Décision : Rétablissez le quorum (préférable) ou utilisez un basculement contrôlé de quorum uniquement si vous avez véritablement un nœud survivant unique et acceptez le risque.

Tâche 10 : Vérifier la dérive horaire et la santé NTP

cr0x@server:~$ timedatectl status
Local time: Thu 2025-12-25 12:08:30 UTC
Universal time: Thu 2025-12-25 12:08:30 UTC
RTC time: Thu 2025-12-25 12:08:29
System clock synchronized: yes
NTP service: active

Sens : Bien. Si l’horloge n’est pas synchronisée ou saute, la temporisation des jetons corosync devient rapidement problématique.
Décision : Si non synchronisé, corrigez NTP/chrony/systemd-timesyncd. Ensuite redémarrez corosync pour stabiliser l’appartenance.

Tâche 11 : Vérifier le chemin réseau et le MTU (parce que « ping fonctionne » ment)

cr0x@server:~$ ping -M do -s 1472 -c 3 172.16.20.12
PING 172.16.20.12 (172.16.20.12) 1472(1500) bytes of data.
1480 bytes from 172.16.20.12: icmp_seq=1 ttl=64 time=0.352 ms
1480 bytes from 172.16.20.12: icmp_seq=2 ttl=64 time=0.339 ms
1480 bytes from 172.16.20.12: icmp_seq=3 ttl=64 time=0.347 ms

Sens : La PMTU pour des trames 1500 octets est correcte. Si cela échoue mais qu’un ping plus petit fonctionne, vous avez des problèmes de MTU/fragmentation.
Décision : Corrigez la cohérence MTU sur les switches, bonds, VLANs et NICs. Corosync/knet n’apprécie pas les trous noirs de fragmentation silencieux.

Tâche 12 : Vérifier les règles de pare-feu qui cassent souvent corosync silencieusement

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

cr0x@server:~$ iptables -S | grep -E 'corosync|5405|5404|knet' | head

Sens : Le pare-feu Proxmox est activé. Corosync avec knet utilise typiquement UDP et des ports dynamiques ; l’ancien corosync utilisait UDP 5405 par défaut.
Le grep vide ne prouve pas que le trafic est autorisé ; il prouve juste que vous n’étiquetez pas clairement vos règles (ce qui est courant).
Décision : Si vous avez récemment activé le filtrage, autorisez explicitement le trafic de cluster sur le réseau dédié corosync. Vérifiez aussi les firewalls hôtes hors des outils Proxmox.

Tâche 13 : Inspecter l’état du lien corosync et l’atteignabilité des peers

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 172.16.20.11
        status  = ring 0 active with no faults

Sens : L’anneau local est actif. Si il montre des faults ou down, vous avez un problème de lien ou de bindnetaddr/mauvaises adresses d’anneau.
Décision : Si l’anneau est fautif, vérifiez que le bon réseau est utilisé, inspectez le tag VLAN et confirmez que les IP peers correspondent à la topologie physique.

Tâche 14 : Rechercher un split brain / des partitions multiples

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1 (local)
         2          1 pve2

Sens : Deux nœuds visibles uniquement. Si vous en attendiez trois, vous avez peut-être un nœud mort ou une partition.
Décision : Si un nœud est définitivement perdu, retirez-le proprement (après stabilisation). Ne gardez pas un nœud mort dans la config « au cas où ».

Tâche 15 : Redémarrage de corosync (seulement après avoir une hypothèse)

cr0x@server:~$ systemctl restart corosync

cr0x@server:~$ systemctl is-active corosync
active

Sens : Le redémarrage a réussi. Re-vérifiez immédiatement le quorum et l’accès CMAP.
Décision : Si il bascule entre active/failed, vous êtes en crash loop — revenez aux journaux et à la validation de config. Ne redémarrez pas en boucle ; vous créerez du thrashing.

Tâche 16 : Vérifier les journaux pve-cluster pour des indices spécifiques à pmxcfs

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager | tail -n 60
Dec 25 12:03:12 pve1 pmxcfs[2011]: [status] notice: cpg_initialize failed: 2
Dec 25 12:03:12 pve1 pmxcfs[2011]: [status] notice: retrying in 1 seconds
Dec 25 12:03:18 pve1 pmxcfs[2011]: [status] notice: resolved node name 'pve1' to '172.16.20.11'

Sens : pmxcfs ne peut pas initialiser sa communication de groupe CPG, typiquement parce que corosync n’est pas prêt ou que l’appartenance n’est pas stable.
Décision : Traitez ceci comme un autre signal « corosync d’abord ». Réparez l’anneau/quorum, puis pmxcfs cessera de se plaindre.

Tâche 17 : Vérifier que la résolution de noms du nœud est stable et correspond à la config corosync

cr0x@server:~$ hostname -f
pve1.prod.example

cr0x@server:~$ getent hosts pve1
172.16.20.11     pve1.prod.example pve1

Sens : Le nom d’hôte résout vers l’IP attendue du cluster. Si il résout vers le réseau de gestion un jour et le réseau de stockage le lendemain,
corosync va mal réagir.
Décision : Verrouillez les entrées correctes dans le DNS ou /etc/hosts pour les noms de cluster ; évitez les DNS « intelligents » qui retournent des adresses différentes selon la source.

Tâche 18 : Si vous devez opérer sans quorum (contrôlé, temporaire)

C’est la partie où vous pouvez empirer les choses en toute confiance. Faites-le seulement si vous avez vraiment un nœud survivant unique et que vous avez besoin d’accéder aux configs
pour récupérer des charges. Dès que le cluster redevient sain, annulez l’opération.

cr0x@server:~$ pvecm expected 1
expected votes set to 1

Sens : Vous avez indiqué au cluster d’attendre 1 vote, ce qui peut restaurer l’état quorate sur le nœud isolé.
Décision : Utilisez-le pour débloquer la situation, pas pour fonctionner indéfiniment. Si le « nœud manquant » revient de façon inattendue, vous entrez dans le territoire des vérités conflictuelles.

Blague #2 : Forcer le quorum, c’est comme remplir ses impôts au lance-flammes. Ça peut marcher, mais vous le sentirez après.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : « cannot initialize CMAP service » et corosync est « active »

• Cause racine : corosync est instable (flapping), ou les sockets IPC sous /run/corosync sont manquants/avec de mauvaises permissions.
• Correction : Vérifiez journalctl -u corosync -b pour des boucles de crash ; vérifiez l’existence des sockets ; réinstallez/réparez les paquets corosync si nécessaire ; corrigez la sémantique de la config.

2) Symptom : /etc/pve est vide, et l’UI Proxmox affiche des bizarreries

• Cause racine : pmxcfs non monté (mount FUSE manquant), souvent parce que pve-cluster a échoué ou corosync n’est pas disponible.
• Correction : Commencez par la santé de corosync, puis redémarrez pve-cluster. Vérifiez le montage avec mount | grep /etc/pve.

3) Symptom : pmxcfs monté mais en lecture seule ; touch échoue

• Cause racine : pas de quorum ou nœud isolé dans une composante non-primaire.
• Correction : Rétablissez la connectivité/quorum du cluster. Si la perte de nœud est permanente, retirez le nœud mort proprement et rétablissez le quorum. Solution temporaire : pvecm expected 1 uniquement si vous êtes vraiment isolé et planifié.

4) Symptom : Corosync échoue avec des plaintes nodeid/nom après changement d’IP

• Cause racine : La config corosync référence encore d’anciennes adresses d’anneau ; le hostname résout vers une IP différente de celle dans le nodelist.
• Correction : Mettez à jour les entrées ring0_addr du nodelist (dans la config autoritaire du cluster), alignez DNS/hosts, et redémarrez corosync sur tous les nœuds dans un ordre contrôlé.

5) Symptom : Tout fonctionne jusqu’aux sauvegardes ou migrations, puis corosync flappe

• Cause racine : famine CPU, IO wait, ou saturation réseau provoquant des timeouts de jetons. Corosync est sensible à la temporisation ; votre réseau de cluster peut être « correct » jusqu’à ce qu’il ne le soit plus.
• Correction : Déplacez le trafic corosync vers un réseau/VLAN plus calme ; corrigez le MTU ; réservez du CPU (évitez la sursouscription sur l’hôte) ; investiguez les problèmes de bonding/driver NIC.

6) Symptom : Après un reboot, le cluster ne se forme pas ; journaux indiquent « wrong authkey »

• Cause racine : authkey mismatched entre les nœuds, souvent suite à une restauration partielle ou à une copie manuelle incorrecte.
• Correction : Re-synchronisez la clé d’authentification corosync entre les nœuds à partir d’une source connue bonne, puis redémarrez corosync partout.

7) Symptom : Le cluster à nœud unique affiche toujours des échecs CMAP

• Cause racine : défaillance locale du service corosync ; pas réellement un problème de « cluster ». Causes courantes : fichier de config cassé, état de paquet corrompu, disque défaillant, ou permissions.
• Correction : Validez la config, assurez-vous que les répertoires runtime existent, vérifiez la santé du disque et les journaux, réinstallez corosync si nécessaire.

Trois mini-récits d’entreprise venus du terrain

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

Une entreprise de taille moyenne avait un cluster Proxmox propre à trois nœuds. « Propre » signifie qu’il fonctionnait suffisamment pour que personne ne s’inquiète.
Pendant une fenêtre de changements de routine, un ingénieur a mis à jour des enregistrements DNS pour standardiser les noms : pve1, pve2, pve3 résolvaient désormais vers le réseau de gestion,
et non vers le réseau corosync. L’hypothèse était apparemment inoffensive : « les noms doivent pointer vers l’interface principale ».

Corosync n’était pas d’accord. Après le premier reboot d’un nœud, corosync a démarré, tenté de binder et d’annoncer sur un réseau, et les autres nœuds s’attendaient à le voir sur un autre.
Les timeouts de jeton sont apparus, le quorum a oscillé, et pmxcfs est passé en lecture seule au moment exact où une migration de VM était en cours.
La migration a échoué d’une façon qui ressemblait à une corruption de stockage — parce que l’UI ne pouvait pas engager correctement les mises à jour de config.

La correction n’était pas magique. Ils ont fixé la résolution spécifique au cluster dans /etc/hosts pour que pve1 pointe toujours vers l’adresse d’anneau.
Ils ont aussi arrêté d’utiliser des noms génériques pour les clusters multi-réseaux ; ils ont introduit des noms explicites pour le trafic cluster et le trafic de gestion.
C’était ennuyeux. Ça a marché. La plus grande leçon a été psychologique : les changements DNS sont des changements d’infrastructure, pas « juste un nettoyage ».

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre équipe disposait d’un VLAN corosync dédié et a décidé « d’optimiser » en le combinant avec le VLAN de stockage pour réduire la complexité des switches.
Leur réseau de stockage était en 10GbE et généralement stable. L’hypothèse : réseau plus rapide = corosync heureux.
Ils ont aussi activé les jumbo frames sur le réseau de stockage — parce que le stockage aime ça.

Un mois plus tard, ils ont commencé à voir des rapports intermittents « cannot initialize CMAP service » pendant les nuits de sauvegarde intensives.
Pas continuellement ; juste assez pour créer la confusion. Corosync n’était pas complètement tombé, mais il basculait l’appartenance pendant quelques secondes,
ce qui suffit pour que les clients pmxcfs lancent des erreurs et que les humains paniquent.

Le coupable était une incohérence de MTU sur quelques ports de trunk et une configuration de bond sur un nœud. Les pings ICMP fonctionnaient car ils étaient petits.
Le trafic de stockage fonctionnait souvent car TCP retransmettait et s’en remettait. Corosync, utilisant UDP et des hypothèses de temporisation, a souffert.
L’« optimisation » a introduit un mode de panne inexistant quand corosync avait un réseau petit, calme et bien contrôlé.

La remédiation a été de séparer à nouveau le trafic corosync sur un VLAN dédié avec MTU=1500 strict bout en bout, et de limiter le débit des domaines de broadcast bruyants.
Ils n’avaient pas besoin d’un réseau plus rapide. Ils avaient besoin d’un réseau prévisible.

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

Une organisation financière exploitait un cluster Proxmox à quatre nœuds. Aucun acte héroïque. Mais ils avaient une pratique qui semblait démodée : après chaque changement de cluster
(ajout/retrait de nœuds, changements d’IP, ajustements corosync), ils archivaient des snapshots de /etc/pve et /var/lib/pve-cluster sur chaque nœud,
et tenaient un petit journal des changements avec horodatage et « pourquoi ».

Un matin, le filesystem root d’un nœud a développé des erreurs. Le nœud a rebooté, corosync a échoué, ensuite pmxcfs a échoué, et /etc/pve semblait incorrect.
L’astreignant n’a pas commencé à deviner. Il a comparé la config corosync archivée localement avec la version courante, a vu que le fichier courant était tronqué,
et a immédiatement suspecté une corruption disque locale plutôt que « bizarrerie du cluster ».

Ils ont reconstruit le nœud proprement, l’ont réintégré avec la config cluster connue bonne, et ont restauré les services sans aggraver le quorum.
La bonne pratique n’était pas glamour. Elle a réduit le temps de décision quand tout semblait suspect.

Checklists / plan étape par étape

Checklist A : Stabiliser corosync d’abord (faites ceci avant de toucher pmxcfs)

1. Confirmer la santé des services.

   cr0x@server:~$ systemctl is-active corosync
   active
   

   Décision : Si non actif, lisez les journaux et corrigez la config/le réseau avant toute autre action.

2. Valider que la config se parse.

   cr0x@server:~$ corosync -t
   Parsing of config file successful
   

   Décision : Échec de parsing = arrêtez-vous et corrigez la syntaxe, pas de redémarrage hasardeux.

3. Vérifier les adresses d’anneau et la résolution de noms.

   cr0x@server:~$ grep -E 'ring0_addr|name|nodeid' -n /etc/pve/corosync.conf | head -n 40
   12:        name: pve1
   13:        nodeid: 1
   14:        ring0_addr: 172.16.20.11
   

   Décision : Si l’IP de ring n’existe pas sur l’hôte, corrigez ce décalage avant de continuer.

4. Vérifier l’état de l’anneau et les faults.

   cr0x@server:~$ corosync-cfgtool -s
   Printing ring status.
   Local node ID 1
   RING ID 0
           id      = 172.16.20.11
           status  = ring 0 active with no faults
   

   Décision : Les faults pointent vers MTU/firewall/routage/VLAN. Allez là-bas, pas sur l’UI Proxmox.

5. Confirmer que CMAP est interrogeable.

   cr0x@server:~$ corosync-cmapctl totem.cluster_name
   totem.cluster_name (str) = prod-cluster
   

   Décision : Si la requête CMAP échoue, corosync n’est pas sain. Résolvez cela avant pmxcfs.

Checklist B : Restaurer le quorum en toute sécurité

1. Vérifier l’état de quorum.

   cr0x@server:~$ pvecm status | grep -E 'Quorate|Nodes|Node ID'
   Nodes:            2
   Node ID:          0x00000001
   Quorate:          No
   

   Décision : Si « No », identifiez les votants manquants et si ils sont réellement joignables.

2. Valider l’atteignabilité des pairs sur le réseau corosync (pas management).

   cr0x@server:~$ ping -c 3 172.16.20.12
   PING 172.16.20.12 (172.16.20.12) 56(84) bytes of data.
   64 bytes from 172.16.20.12: icmp_seq=1 ttl=64 time=0.301 ms
   64 bytes from 172.16.20.12: icmp_seq=2 ttl=64 time=0.287 ms
   64 bytes from 172.16.20.12: icmp_seq=3 ttl=64 time=0.294 ms
   

   Décision : Si ping échoue, corrigez le réseau. Si ping réussit, vérifiez tout de même MTU et firewall.

3. Uniquement si un nœud est définitivement mort : planifiez son retrait, ne supprimez pas à chaud.

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

   Décision : Confirmez quel nœud est mort et pourquoi. S’il peut revenir, réparez-le au lieu de le retirer.

4. Mode de survie temporaire (nœud unique seulement) : régler expected votes.

   cr0x@server:~$ pvecm expected 1
   expected votes set to 1
   

   Décision : Utilisez ceci pour accéder aux configs et récupérer. Annulez-le quand le quorum normal est rétabli.

Checklist C : Ramener pmxcfs à un état monté sain

1. Vérifier le montage.

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

   Décision : Pas de montage signifie que pve-cluster ne fonctionne pas ; vérifiez ses journaux et la santé de corosync.

2. Redémarrer pmxcfs seulement après que corosync soit stable.

   cr0x@server:~$ systemctl restart pve-cluster
   

   Décision : Si il échoue immédiatement avec des erreurs CPG/CMAP, corosync n’est toujours pas réglé.

3. Contrôle de sanity : lister les répertoires de nœuds.

   cr0x@server:~$ ls -1 /etc/pve/nodes
   pve1
   pve2
   pve3
   

   Décision : Des nœuds manquants peuvent signifier partition, vue sans quorum, ou incohérence de config. Cross-check avec pvecm nodes.

FAQ

1) « cannot initialize CMAP service » est-ce un bug Proxmox ?

Généralement non. C’est un signal sur la santé de corosync. Proxmox le remonte parce que ses composants dépendent de l’état runtime de corosync. Réparez le service/anneau/quorum corosync sous-jacent et les erreurs CMAP disparaissent en général.

2) Puis-je simplement redémarrer tout : corosync, pve-cluster, pvedaemon, pveproxy ?

Vous pouvez, mais c’est comme redémarrer le détecteur de fumée pour éteindre un feu de cuisine. Redémarrer corosync sans comprendre pourquoi il est malheureux peut aggraver le flapping d’appartenance, ce qui rend pmxcfs plus têtu, et l’UI/API plus déroutants.

3) Pourquoi /etc/pve agit-il comme vide ou en lecture seule ?

Parce que c’est un montage FUSE fourni par pmxcfs. Si pmxcfs n’est pas monté, vous voyez un répertoire ordinaire. Si vous n’avez pas de quorum, pmxcfs peut se monter mais refuser les écritures.
Vérifiez toujours le montage et l’état de quorum avant de modifier quoi que ce soit.

4) Quel est l’ordre le plus sûr pour redémarrer les services ?

Corosync d’abord (mais seulement après vérification config/réseau). Ensuite pve-cluster. Puis les démons UI/API (pveproxy, pvedaemon) s’ils se comportent mal.
Commencer par le haut fait perdre du temps.

5) Ai-je besoin de multicast pour corosync ?

La plupart des clusters Proxmox modernes utilisent le transport knet (unicast). Le multicast était courant historiquement mais est souvent bloqué ou mal supporté dans les réseaux d’entreprise.
Ne poursuivez pas le multicast sauf si votre configuration l’utilise explicitement.

6) Forcer le quorum avec pvecm expected 1 est-ce sûr ?

C’est un outil, pas un style de vie. Cela peut être sûr dans une vraie situation de survie à nœud unique, quand vous comprenez que vous outrepasser les règles de sécurité
pour retrouver de la gérabilité. C’est dangereux si d’autres nœuds peuvent encore être vivants et écrire des configs conflictuelles ailleurs.

7) Des problèmes de stockage peuvent-ils causer des erreurs CMAP ?

Indirectement, oui. Si l’hôte est en forte IO wait (disque de boot mourant, pool ZFS surchargé, OSD CEPH saturé sur le même nœud),
corosync peut manquer des fenêtres de temporisation, l’appartenance peut flapper, et les clients CMAP échouent. Corosync n’est pas impressionné par vos beaux graphiques de latence.

8) Et si j’ai changé les IP du réseau de cluster ?

Attendez-vous à des douleurs corosync tant que chaque nœud n’aura pas son corosync.conf nodelist et la résolution de noms en accord. Les changements partiels provoquent une appartenance asymétrique.
Planifiez les changements d’IP comme une migration : mettez à jour la config de manière cohérente, validez le MTU, validez le firewall, redémarrez dans un ordre contrôlé.

9) Pourquoi ça marche un moment après un redémarrage, puis ça retombe ?

C’est classique pour les problèmes de temporisation ou le jitter réseau : timeouts de jeton, trous MTU sous charge, ou famine CPU pendant les sauvegardes. Cela peut aussi indiquer un lien qui bascule (bonding, LACP, ports de switch). Cherchez des motifs : « échoue sous charge » n’est pas une coïncidence.

10) Comment savoir si c’est une partition vs un nœud mort ?

Comparez la sortie de pvecm nodes sur plusieurs nœuds. Si différents nœuds voient des appartenances différentes, vous avez une partition.
Si tous les nœuds sains s’accordent pour dire qu’un nœud manque et qu’il est injoignable sur le réseau corosync, il est probablement mort ou isolé.

Conclusion : prochaines étapes sans générer un second incident

Quand Proxmox affiche « cannot initialize CMAP service », ne le traitez pas comme une humeur mystérieuse de Proxmox. C’est corosync qui vous indique qu’il ne peut pas fournir
un état runtime stable. Votre travail consiste à stabiliser l’anneau, restaurer le quorum, et seulement ensuite attendre que pmxcfs et l’UI se comportent.

Prochaines étapes pratiques :

• Exécutez le playbook de diagnostic rapide : santé des services → quorum → réseau/MTU de l’anneau → état du montage pmxcfs.
• Collectez des preuves avant de redémarrer quoi que ce soit : journaux corosync, état d’anneau, requête CMAP, et synchronisation horaire.
• Corrigez d’abord les causes ennuyeuses : décalages IP/nom, incohérences MTU, règles de firewall, et dérive de l’horloge.
• Si vous devez forcer le quorum, faites-le délibérément, documentez-le, et annulez-le dès que possible.
• Après la récupération, planifiez un renforcement : réseau corosync dédié, résolution de noms cohérente, et sauvegardes de config fiables.