Proxmox “failed to start pve-ha-lrm” : pourquoi la HA ne démarre pas et quoi vérifier

janvier 13, 2026 • février 3, 2026 • Lecture : 28 min • Views: 9

Cet article vous a aidé ?

Cette ligne rouge de statut — failed to start pve-ha-lrm — apparaît précisément quand vous avez le plus besoin que la HA se comporte comme de la HA. Un nœud redémarre, un chemin de stockage cale, ou un commutateur est “amélioré” par quelqu’un avec un carnet, et soudainement le Local Resource Manager (LRM) ne veut plus démarrer. Votre cluster est suffisamment vivant pour se moquer de vous, mais pas assez sain pour effectuer un basculement.

Ce n’est pas une situation où il suffit de “redémarrer le service”. pve-ha-lrm est le symptôme. La cause est presque toujours l’une des suivantes : système de fichiers de cluster défaillant, problème corosync/quorum, incohérence de temps ou de résolution de noms, configuration de fencing/watchdog, ou angles de stockage que la HA refuse d’inventer.

Ce que fait réellement pve-ha-lrm (et pourquoi il refuse de démarrer)

La HA de Proxmox est répartie en deux rôles principaux :

pve-ha-manager : le cerveau du cluster qui décide où les ressources (VMs/CTs) doivent s’exécuter.
pve-ha-lrm : la couche d’exécution locale au nœud qui démarre/arrête/migre les ressources et renvoie l’état.

Le LRM est volontairement prudent. S’il ne peut pas faire confiance à l’état du cluster, lire le système de fichiers du cluster, communiquer de manière fiable avec corosync, ou s’il détecte des incohérences de fencing/watchdog, il abandonnera. Ce n’est pas du « chipotage ». C’est la façon d’éviter un split-brain et des démarrages en double, ce qui revient à mettre vos données en feu avec la paperasse attachée.

Une vérité opérationnelle à graver dans un runbook : la HA dépend du fait que le cluster soit ennuyeux. Pas “innovant”. Pas “optimisé”. Ennuyeux. Moins vos horloges, réseau, sémantique de stockage et identité de nœud sont surprenants, plus la HA peut effectuer son travail en toute sécurité.

Et oui, on peut parfois forcer les choses par des démarrages manuels. Mais si vous ne réglez pas les problèmes de confiance sous-jacents, la HA continuera de refuser de prendre la responsabilité — comme un ado qu’on lui demande de conduire dans une tempête avec des pneus lisses.

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

Si vous êtes d’astreinte et que le pager hurle, il faut localiser le goulot rapidement. Voici l’ordre qui gaspille le moins de temps.

Premier : déterminer si c’est un problème de cluster/quorum

Vérifier si corosync est en marche et a le quorum.
Vérifier si pmxcfs est monté et accessible en écriture.
Vérifier l’appartenance au cluster et la cohérence des noms de nœuds.

Si le quorum est perdu ou si pmxcfs est cassé, la HA n’a pas de modèle de monde sûr. Réparez cela avant de toucher aux services HA.

Deuxième : confirmer les services HA et leurs erreurs immédiates

Lire le statut systemd pour pve-ha-lrm et pve-ha-manager.
Lire les journaux journalctl autour de l’heure de l’échec.
Vérifier si le nœud est coincé dans un état fenced/maintenance.

Troisième : valider les prérequis stockage pour les ressources HA

Stockage partagé présent là où attendu (ou vous utilisez correctement la réplication).
Configuration de stockage cohérente entre nœuds.
Verrous obsolètes ou erreurs au niveau du stockage ne bloquant pas les actions de démarrage.

Heuristique raccourci : Si l’UI montre un statut de cluster bizarre, votre problème n’est pas la HA. Si l’UI montre un cluster sain mais que la HA ne peut pas gérer une VM, votre problème est probablement lié au stockage ou à la configuration de la ressource.

Exigences strictes avant que la HA n’envisage de démarrer

1) L’appartenance corosync et le quorum doivent être sains

Le LRM dépend de la couche de communication du cluster. Si corosync ne peut pas former une appartenance stable, les décisions HA deviennent dangereuses : une VM peut être démarrée sur deux nœuds, ou arrêtée sur le mauvais. Proxmox est conçu pour éviter cela en étant obstiné.

2) pmxcfs doit être monté et cohérent

pmxcfs est le système de fichiers de cluster Proxmox (un système FUSE) qui fournit la configuration distribuée sous /etc/pve. S’il n’est pas monté, la HA ne peut pas lire l’état et la configuration du cluster de façon fiable.

3) L’identité du nœud doit correspondre entre les couches

Les incohérences de nom de nœud — entre le hostname, /etc/hosts, la nodelist de corosync et ce que Proxmox pense — provoquent des défaillances subtiles. Les processus HA ne sont pas intéressés par votre créativité DNS.

4) Le temps ne doit pas dériver vers la vallée étrange

Corosync et la coordination distribuée se comportent mal lorsque le temps fait des sauts. Les problèmes NTP/chrony peuvent générer des symptômes qui ressemblent à des fluctuations “aléatoires” d’appartenance. Spoiler : elles ne le sont pas.

5) La configuration fencing/watchdog doit être cohérente

La HA sans fencing est essentiellement du “best effort”. Proxmox peut utiliser le fencing basé sur le watchdog (et s’intègre à des approches de fencing externes selon la configuration). Si le LRM voit des exigences watchdog non satisfaites, il peut refuser de fonctionner ou se bloquer.

Blague #1 : La HA sans quorum, c’est comme un comité sans procès-verbaux : chacun se souvient d’une réalité différente, et d’une manière ou d’une autre la finance gagne toujours.

Tâches pratiques : commandes, signification des sorties et décisions

Ci-dessous se trouvent 14 tâches pratiques que vous pouvez lancer sur un nœud rapportant failed to start pve-ha-lrm. Chacune indique ce que la sortie signifie et quelle décision prendre ensuite. Exécutez-les d’abord sur le nœud en échec, puis sur au moins un nœud sain pour comparaison.

Task 1: Check systemd status for pve-ha-lrm

cr0x@server:~$ systemctl status pve-ha-lrm --no-pager
● pve-ha-lrm.service - PVE Local Resource Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-lrm.service; enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 09:11:02 UTC; 2min 3s ago
    Process: 2149 ExecStart=/usr/sbin/pve-ha-lrm (code=exited, status=1/FAILURE)
   Main PID: 2149 (code=exited, status=1/FAILURE)

Dec 26 09:11:02 server pve-ha-lrm[2149]: unable to read cluster config: /etc/pve/corosync.conf: No such file or directory
Dec 26 09:11:02 server systemd[1]: pve-ha-lrm.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:11:02 server systemd[1]: pve-ha-lrm.service: Failed with result 'exit-code'.

Signification : La ligne d’erreur indique généralement quel sous-système est en panne. Ici, il se plaint de /etc/pve, ce qui hurle que pmxcfs n’est pas monté ou que le FS de cluster est indisponible.

Décision : Si les erreurs mentionnent /etc/pve, passez directement aux Tâches 4–6 (pmxcfs + corosync + quorum).

Task 2: Read recent journal logs for pve-ha-lrm

cr0x@server:~$ journalctl -u pve-ha-lrm -b --no-pager -n 120
Dec 26 09:10:59 server systemd[1]: Starting PVE Local Resource Manager Daemon...
Dec 26 09:11:02 server pve-ha-lrm[2149]: starting lrm service
Dec 26 09:11:02 server pve-ha-lrm[2149]: can't initialize HA stack - aborting
Dec 26 09:11:02 server pve-ha-lrm[2149]: cfs-lock 'file-ha_agent' error: no quorum
Dec 26 09:11:02 server systemd[1]: pve-ha-lrm.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:11:02 server systemd[1]: pve-ha-lrm.service: Failed with result 'exit-code'.

Signification : C’est le classique : no quorum. La HA refuse de fonctionner parce qu’elle ne peut pas se coordonner en toute sécurité.

Décision : Ne pas “forcer” les services HA. Restaurez le quorum : appartenance corosync, réseau, votes ou nombre de nœuds. Allez aux Tâches 7 et 8.

Task 3: Confirm pve-ha-manager status (it matters)

cr0x@server:~$ systemctl status pve-ha-manager --no-pager
● pve-ha-manager.service - PVE HA Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-manager.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:01:18 UTC; 12min ago
   Main PID: 1422 (pve-ha-manager)
      Tasks: 6 (limit: 154838)
     Memory: 33.4M
        CPU: 1.820s
     CGroup: /system.slice/pve-ha-manager.service
             └─1422 /usr/sbin/pve-ha-manager

Signification : Le manager en cours d’exécution ne garantit pas que le LRM puisse tourner. Mais si les deux sont morts, vous regardez probablement un problème de cluster/pmxcfs plus profond plutôt qu’un problème local.

Décision : Si le manager est down sur plusieurs nœuds, traitez-le comme un problème de niveau cluster. Si seul le LRM échoue sur un nœud, focalisez-vous sur les prérequis locaux ou un état bloqué.

Task 4: Verify pmxcfs is mounted

cr0x@server:~$ mount | grep -E '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)

Signification : Si vous ne voyez pas pve-cluster on /etc/pve, la HA ne fonctionnera pas parce que la config/l’état est inaccessible.

Décision : Si c’est manquant, vérifiez pve-cluster et corosync (Tâche 5 et Tâche 7). Ne démarrez pas la HA tant que /etc/pve n’est pas monté.

Task 5: Check pve-cluster service

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:00:32 UTC; 13min ago
   Main PID: 1120 (pmxcfs)
      Tasks: 12 (limit: 154838)
     Memory: 41.6M
        CPU: 4.122s
     CGroup: /system.slice/pve-cluster.service
             └─1120 /usr/bin/pmxcfs

Signification : Si pve-cluster ne tourne pas, /etc/pve ne sera pas disponible.

Décision : Si le service échoue, les logs indiqueront souvent “no quorum” ou montreront des erreurs de connexion corosync. Réparez corosync/quorum d’abord ; redémarrer pmxcfs sans quorum est du whack-a-mole.

Task 6: Check whether /etc/pve is writable (quorum indicator)

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

Quorum information
------------------
Date:             Fri Dec 26 09:13:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.4c
Quorate:          Yes

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

Signification : Quorate: Yes est le feu vert. Si c’est No, la HA est censée s’arrêter.

Décision : Si pas quorate, n’essayez pas de “récupérer” la HA en redémarrant les services. Vous avez besoin du quorum, ou d’une décision délibérée de fonctionner sans (rarement correct, généralement désespéré).

Task 7: Inspect corosync status

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:00:25 UTC; 13min ago
       Docs: man:corosync
   Main PID: 1011 (corosync)
      Tasks: 17 (limit: 154838)
     Memory: 30.1M
        CPU: 2.033s
     CGroup: /system.slice/corosync.service
             └─1011 /usr/sbin/corosync -f

Signification : Corosync en cours d’exécution ne garantit pas la stabilité d’appartenance. Vous devez vérifier la vue du cluster (Tâche 8) et les logs (Tâche 9).

Décision : Si corosync est inactif/failed, corrigez cela avant la HA. S’il est actif mais que le quorum est perdu, examinez le réseau, les votes de nœud ou un nœud manquant.

Task 8: See corosync membership and link state

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

Signification : “connected” entre pairs est ce que vous voulez. Si vous voyez “disconnected”, “faulty” ou un nœud manquant, c’est votre problème de quorum.

Décision : Si les liens fluctuent, arrêtez de courir après la HA et réglez le chemin réseau (mismatch MTU, perte de paquets, firewall, fonctions de commutateur). Corosync déteste les surprises.

Task 9: Read corosync logs for the real reason

cr0x@server:~$ journalctl -u corosync -b --no-pager -n 160
Dec 26 09:07:44 server corosync[1011]: [KNET  ] link: host: 2 link: 0 is down
Dec 26 09:07:45 server corosync[1011]: [TOTEM ] A new membership (1.4b) was formed. Members left: 2
Dec 26 09:07:45 server corosync[1011]: [QUORUM] Members[1]: 1
Dec 26 09:07:45 server corosync[1011]: [QUORUM] This node is within the non-quorate partition
Dec 26 09:07:49 server corosync[1011]: [KNET  ] link: host: 2 link: 0 is up

Signification : Les événements link down/up se corrèlent avec la perte de quorum et le refus de la HA de verrouiller l’état du cluster.

Décision : Traitez cela comme un problème de réseau/transport. Cherchez des changements MTU, des problèmes VLAN, du routage asymétrique, ou des bugs d’offload NIC. Si cela arrive sous charge, suspectez des micro-bursts ou une politique de commutateur qui “protège” le trafic multicast/UDP.

Task 10: Validate node name and resolution consistency

cr0x@server:~$ hostname -f
pve01.corp.local

cr0x@server:~$ grep -E '(^127\.0\.1\.1|10\.10\.10\.)' /etc/hosts
127.0.1.1 pve01.corp.local pve01
10.10.10.11 pve01.corp.local pve01
10.10.10.12 pve02.corp.local pve02
10.10.10.13 pve03.corp.local pve03

Signification : Les clusters Proxmox sont sensibles à la cohérence des identités. Vous voulez que le hostname du nœud corresponde à ce que le cluster attend, et une résolution stable pour les pairs.

Décision : Si les hostnames ne correspondent pas aux noms de nœud du cluster, corrigez l’identité avec soin (et planifiez une fenêtre). Ne “changez pas juste le DNS” en espérant que ça ira.

Task 11: Inspect HA status and node states

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Wed Dec 26 09:13:55 2025)
lrm pve01 (active, Wed Dec 26 09:13:54 2025)
lrm pve02 (active, Wed Dec 26 09:13:51 2025)
lrm pve03 (idle, Wed Dec 26 09:12:10 2025)

service vm:101 (started)
service vm:102 (stopped)
service ct:201 (started)

Signification : Si le nœud en échec affiche lrm ... (idle) ou est absent, il ne participe pas. Si le master rebondit ou est absent, votre manager HA est instable.

Décision : Si le quorum est OK mais que le LRM est idle/manquant, concentrez-vous sur les problèmes locaux : systemd, watchdog, permissions, montage pmxcfs, ou erreurs d’agents de ressource.

Task 12: Check watchdog device (fencing prerequisite in many setups)

cr0x@server:~$ ls -l /dev/watchdog*
crw------- 1 root root 10, 130 Dec 26 09:00 /dev/watchdog
crw------- 1 root root 10, 129 Dec 26 09:00 /dev/watchdog0

cr0x@server:~$ systemctl status watchdog-mux --no-pager
● watchdog-mux.service - Proxmox VE watchdog multiplexer
     Loaded: loaded (/lib/systemd/system/watchdog-mux.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:00:28 UTC; 13min ago

Signification : Des devices watchdog manquants ou un multiplexer mort peuvent bloquer les hypothèses de fencing et rendre la HA conservatrice (ou dysfonctionnelle en cas de panne).

Décision : Si le watchdog manque et que votre politique HA l’attend, réparez le matériel/driver/BIOS watchdog avant de faire confiance à la HA.

Task 13: Check for storage-induced start failures (shared storage visibility)

cr0x@server:~$ pvesm status
Name             Type     Status           Total        Used       Avail      %
local             dir     active        19688240     4680128    14073520  23.77%
shared-nfs         nfs     active      984320000   612480000   371840000  62.22%
ceph-vm            rbd     active      204800000    73216000   131584000  35.75%

Signification : Si le stockage dont dépend une VM est absent/inactif sur le nœud, la HA peut refuser de démarrer cette VM et laisser des ressources en état d’erreur. Parfois le démarrage du LRM lui-même est correct ; la première action déclenche l’échec.

Décision : Si le stockage partagé est inactif sur le nœud en échec, arrêtez de blâmer la HA. Réparez le montage/auth/réseau du stockage ; puis retentez les actions HA.

Task 14: Look for stuck locks or blocked cluster filesystem operations

cr0x@server:~$ pveperf /etc/pve
CPU BOGOMIPS:      55866.40
REGEX/SECOND:      3966050
HD SIZE:           29.34 GB (local-lvm)
BUFFERED READS:    201.15 MB/sec
FSYNCS/SECOND:     1248.61
DNS EXT:           63.63 ms
DNS INT:           0.09 ms (pve01.corp.local)

Signification : pveperf contre /etc/pve est un contrôle santé approximatif. S’il se fige ou produit des erreurs étranges, votre système de fichiers de cluster est malade (souvent à cause d’un quorum instable ou d’une surcharge du nœud).

Décision : Si pveperf /etc/pve bloque, traitez-le comme un problème de comms/quorum du cluster ou une contention sévère des ressources du nœud. Restaurez la stabilité avant la HA.

Modes de panne qui correspondent directement à “failed to start pve-ha-lrm”

1) Pas de quorum (le plus courant, comportement le plus correct)

La HA a besoin d’un consensus. Sans quorum, elle ne peut pas acquérir des verrous en toute sécurité dans le système de fichiers du cluster. Vous verrez des erreurs comme :

cfs-lock ... error: no quorum
unable to read cluster config (parce que pmxcfs est en mode lecture seule / sans quorum)

Direction de correction : restaurer l’appartenance. Ramenez le nœud manquant, réparez le réseau corosync, ou corrigez les attentes de vote. Si vous avez un cluster à deux nœuds, lisez la section FAQ sur pourquoi c’est un piège sans qdevice.

2) pmxcfs non monté ou malsain

Si /etc/pve n’est pas monté, vous n’avez effectivement pas de cluster Proxmox sur ce nœud. La HA échouera. Cela peut arriver si :

pve-cluster a échoué à démarrer
corosync est tombé ou non authentifié
le nœud a démarré dans un état où il ne peut pas joindre ses pairs et donc n’obtient pas le quorum

Direction de correction : traitez-le comme un “cluster non formé”. Résolvez corosync et l’identité d’abord, puis redémarrez pve-cluster, puis la HA.

3) Fluctuation des liens corosync (péchés réseau et MTU)

Lorsque corosync est instable, la HA a tendance à paraître “cassée au hasard”. Ce n’est pas aléatoire ; elle réagit aux changements d’appartenance. Causes :

Mismatch MTU (surtout avec VLANs, bonds, jumbo frames)
Règles de firewall ajoutées “temporairement”
Contrôle de tempête du commutateur / filtrage multicast / policing UDP
Problèmes d’offload NIC/driver sous charge

Direction de correction : rendez le réseau corosync ennuyeux : MTU cohérent bout en bout, sans filtrage, faible perte, latence prévisible.

4) Incohérence de nom de nœud ou identité de cluster obsolète

Si les noms de nœud dérivent (hostname changé après création du cluster, DNS renvoie des noms nouveaux, ou /etc/hosts diffère), l’appartenance peut se former mais les couches supérieures ne peuvent pas concilier les identités. La HA peut alors échouer à mapper les ressources aux nœuds.

Direction de correction : standardisez les noms. Préférez des hostnames stables et des mappages statiques pour le trafic cluster. Si vous devez renommer, faites-le comme une migration contrôlée avec une validation complète de la configuration corosync.

5) Préconditions watchdog/fencing non satisfaites

En HA, le fencing garantit qu’un nœud est vraiment mort avant de démarrer ses workloads ailleurs. Si le device watchdog manque ou est mal configuré, certaines configurations HA refuseront de fonctionner comme prévu ou agiront de manière conservatrice. L’échec peut se manifester par un LRM qui refuse de démarrer ou qui s’arrête rapidement.

Direction de correction : vérifiez la disponibilité des devices watchdog, les paramètres BIOS, les modules kernel et l’état des services. Si votre politique exige le fencing, ne l’écartez pas à la légère.

6) Échecs d’agents de ressources qui ressemblent à des échecs LRM

Parfois pve-ha-lrm démarre correctement mais rapporte immédiatement des échecs de ressources, et l’opérateur en déduit que “LRM ne démarre pas”. Les logs disent la vérité : une action de démarrage/migration d’une VM échoue à cause du stockage, des verrous ou de la config.

Direction de correction : séparez “daemon LRM échoué” de “LRM n’a pas pu exécuter des actions de ressource”. Utilisez ha-manager status et les logs par VM.

Citation (idée paraphrasée) : la leçon orientée fiabilité de Peter Drucker : “Vous ne pouvez pas gérer ce que vous ne mesurez pas.” En HA, l’appartenance et le quorum sont les mesures qui comptent en premier.

Erreurs fréquentes : symptôme → cause racine → fix

Cette section est volontairement directe. Ce sont les erreurs qui se répètent parce qu’elles semblent être des raccourcis raisonnables à 2h du matin.

Mistake 1: “Restart HA services” when quorum is lost

Symptôme : pve-ha-lrm échoue avec no quorum et vous le redémarrez sans fin.

Cause racine : Le cluster ne peut pas verrouiller l’état en toute sécurité ; redémarrer ne restaure pas le consensus.

Fix : Restaurez l’appartenance corosync et le quorum. Ensuite seulement redémarrez les services HA (si ils ne se rétablissent pas automatiquement).

Mistake 2: Two-node cluster without a tie-breaker

Symptôme : Un reboot d’un nœud ou un petit problème réseau met la HA hors service ; pve-ha-lrm échoue ; Quorate: No.

Cause racine : Avec 2 nœuds, la perte de l’un d’eux enlève la majorité à moins d’utiliser un qdevice ou un troisième vote.

Fix : Ajoutez un qdevice (ou un troisième nœud). Si vous ne pouvez pas, acceptez que la “HA” soit conditionnelle et coûteuse en exploitation.

Mistake 3: Changing hostname/DNS after cluster creation

Symptôme : Corosync semble actif, mais les nœuds affichent des identités étranges ; la HA ne peut pas coordonner ; des erreurs LRM référencent des nœuds manquants.

Cause racine : L’identité d’un nœud dans le cluster n’est pas seulement “ce que DNS dit aujourd’hui”.

Fix : Gardez des hostnames stables. Si renommer est indispensable, planifiez une reconfiguration contrôlée et validez la vue noms/IP sur chaque nœud.

Mistake 4: Corosync network shares a congested path with storage or VM traffic

Symptôme : La HA tombe pendant les fenêtres de sauvegarde, migrations ou rééquilibrage de stockage ; les appartenances vacillent.

Cause racine : Le trafic corosync est sensible à la perte/latence. La congestion fait croire que des nœuds échouent.

Fix : Isolez corosync sur un réseau dédié, ou au moins un VLAN/QoS protégé. Gardez le MTU cohérent.

Mistake 5: “Optimizing” MTU or bonding without testing corosync

Symptôme : Perte de quorum aléatoire après des “améliorations” réseau.

Cause racine : MTU mismatch ou changements de hashing LACP entraînant perte/reordonnancement de paquets UDP.

Fix : Validez le MTU bout en bout avec des tests réels, et vérifiez la stabilité corosync sous charge. Si vous ne pouvez pas le prouver, ne le déployez pas.

Mistake 6: HA resources configured without shared storage guarantees

Symptôme : La HA refuse de démarrer ou échoue aussitôt quand elle tente de démarrer une VM ailleurs.

Cause racine : Les disques de la VM sont sur un stockage local au nœud ; le basculement ne peut pas y accéder.

Fix : Déplacez les disques sur un stockage partagé, utilisez Ceph/RBD, ou la réplication quand c’est approprié. La “HA” ne téléporte pas les données.

Blague #2 : La seule chose plus effrayante qu’un split-brain est de réaliser que les deux moitiés pensent être le “primaire” parce que vous les avez nommées ainsi.

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

Checklist A: Bring HA back safely on one node

Confirmer la stabilité corosync : pas de flapping d’appartenance dans les logs pendant plusieurs minutes en conditions normales.
Confirmer le quorum : pvecm status montre Quorate: Yes.
Confirmer pmxcfs : mount | grep /etc/pve montre un montage en lecture-écriture.
Confirmer la synchronisation temporelle : chrony/ntp stable ; pas de gros offsets.
Confirmer le watchdog (si utilisé) : devices présents et service actif.
Démarrer la pile HA (si elle n’est pas déjà lancée) : démarrer le manager puis le LRM, et surveiller les logs.
Vérifier l’état HA : ha-manager status montre le LRM actif.

Checklist B: When you should stop and declare an incident

Le quorum fluctue de façon répétée et vous ne pouvez pas le corréler à une panne d’un nœud unique.
/etc/pve disparaît ou devient lecture-seule de manière intermittente.
Les logs corosync montrent des liaisons up/down fréquentes sans raison physique claire.
Les nœuds sont en désaccord sur l’appartenance ou les votes attendus.
Vous voyez des signes de corruption du stockage ou des erreurs d’I/O répétées sur le disque système (pmxcfs dépend aussi d’un nœud sain).

Checklist C: Clean restart sequence (only after quorum is solid)

cr0x@server:~$ systemctl restart pve-ha-manager
cr0x@server:~$ systemctl restart pve-ha-lrm
cr0x@server:~$ systemctl status pve-ha-lrm --no-pager
● pve-ha-lrm.service - PVE Local Resource Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-lrm.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:20:05 UTC; 3s ago
   Main PID: 3011 (pve-ha-lrm)

Signification : S’il démarre proprement maintenant, l’échec précédent était presque certainement lié au quorum/pmxcfs/identité, pas à “un paquet HA cassé”.

Décision : S’il échoue encore, retournez aux logs et corrélez avec les modes de panne. Ne relancez pas en boucle ; vous ne ferez que générer du bruit.

Trois mini-récits d’entreprise du terrain

Incident causé par une mauvaise hypothèse : “Le DNS va bien ; ce ne sont que des noms”

Une entreprise de taille moyenne faisait tourner un cluster Proxmox dans un bureau régional. Rien de glamour, mais il hébergeait l’habituel : une stack de monitoring, quelques VMs Windows, des applis internes et un service de fichiers. La HA était activée parce que quelqu’un avait promis à la direction un “basculement automatique”.

Un lundi, ils ont migré le DNS interne vers une nouvelle paire de serveurs. Le plan semblait propre : répliquer les zones, mettre à jour les options DHCP, puis retirer les anciens serveurs. Aucun changement prévu sur Proxmox car, selon la demande de changement, “le DNS n’impacte pas le clustering de l’hyperviseur”.

Après la coupure, la HA a commencé à se comporter comme hantée. pve-ha-lrm échouait sur un nœud, puis un autre. Corosync était “en marche”, mais le quorum vacillait pendant le fonctionnement normal. Le vrai coupable n’était pas la disponibilité DNS — c’était le comportement du résolveur. Le nouveau resolver rendait des réponses différentes pour les noms courts vs FQDN, et un nœud avait un mapping /etc/hosts obsolète. L’appartenance corosync se formait, puis les comparaisons d’identité de niveau supérieur ne collaient pas. Le cluster avait une crise existentielle.

La correction était ennuyeuse : forcer la résolution réseau du cluster vers des entrées stables, aligner les hostnames sur ce que Proxmox attend, et arrêter d’utiliser des recherches de noms ambiguës pour les chemins critiques du cluster. La HA a récupéré immédiatement.

L’erreur était de penser que le nommage est cosmétique. Dans un cluster, les noms sont l’identité. L’identité est sécurité. La sécurité est coordination. La coordination décide si votre VM démarre une ou deux fois.

Optimisation qui s’est retournée contre eux : “Mettons du jumbo-frame partout”

Une équipe d’entreprise avait un bon cluster Proxmox à trois nœuds avec stockage partagé et un VLAN corosync séparé. Ils voulaient accélérer les migrations à chaud et réduire l’overhead CPU, alors ils ont déployé des jumbo frames sur tout le tissu de virtualisation. Le changement a été approuvé vite car ils l’avaient fait ailleurs.

Ils ont mis MTU 9000 sur les NICs et les switches top-of-rack. Les performances de stockage se sont améliorées. Les migrations ont été plus rapides. Tout le monde était content.

Puis la HA a commencé à ne plus démarrer sur un nœud après des reboots. L’erreur était intermittente : parfois pve-ha-lrm démarrait, parfois il lançait un no quorum bref et restait mort. Les logs corosync montraient des flaps qui duraient quelques secondes, souvent pendant les sauvegardes.

L’“optimisation” était incomplète : un trunk entre switches sur le chemin corosync avait encore MTU 1500. Sous faible charge, la fragmentation masquait le problème. Sous charge, des paquets étaient perdus. Corosync a interprété la perte comme une instabilité de nœud, le quorum chutait, et les processus HA refusaient les verrous.

La correction n’a rien d’héroïque : aligner le MTU bout en bout, puis vérifier avec des tests réels et du trafic soutenu. Après ça, la HA s’est comportée comme si elle ne les avait jamais rencontrés.

La leçon : les améliorations de performance touchant des fondamentaux réseau nécessitent un plan de validation incluant la stabilité corosync. Votre stockage peut tolérer un peu de perte. Votre coordinateur de cluster non.

Pratique ennuyeuse mais correcte qui a sauvé la mise : “Corosync dédié + fencing prévisible”

Une organisation de santé (du genre qui adore la paperasse plus que l’oxygène) utilisait Proxmox pour des workloads non cliniques. Leur lead SRE insistait sur deux habitudes : (1) corosync sur un réseau physiquement séparé et (2) fencing watchdog configuré et testé trimestriellement. L’équipe ronchonnait car ça semblait du processus pour le processus.

Pendant un événement d’alimentation, un nœud est revenu dans un état dégradé : l’OS était up, mais le driver NIC était bloqué et laissait tomber des paquets. De l’extérieur, il semblait suffisamment vivant pour embrouiller les humains. L’appartenance corosync était instable. Sans fencing, c’est là que les clusters meurent lentement — parce que tout le monde débat si un nœud est “vraiment” down.

Le watchdog a fait son travail. Le nœud malade a été fenced proprement, le quorum s’est stabilisé, et la HA a démarré les workloads sur les nœuds restants. Les utilisateurs ont subi une courte interruption, pas une journée d’“intermittent slowness” qui dégénère en festival de reproches.

Après, le postmortem était presque ennuyeux. Le runbook correspondait à la réalité, le domaine de défaillance était clair, et la correction ciblée : remplacer la NIC, mettre à jour le firmware, retester. Pas de mystère. Pas de folklore.

Les pratiques ennuyeuses ne sont pas glamour. Elles sont aussi la raison pour laquelle vous pouvez dormir.

Faits intéressants et contexte historique

Fait 1: La config du cluster Proxmox vit dans pmxcfs, un filesystem FUSE monté sur /etc/pve, pas dans des fichiers locaux “normaux”.
Fait 2: Le transport moderne de Corosync dans Proxmox utilise couramment knet, conçu pour gérer la redondance multi-lien et un meilleur comportement réseau.
Fait 3: Le concept de quorum est plus ancien que la virtualisation moderne ; il vient des problèmes de coordination des systèmes distribués où la majorité évite le split-brain.
Fait 4: Les piles HA séparent souvent “décider” et “exécuter” (manager vs agent local). Proxmox suit ce modèle avec manager et LRM pour sécurité et clarté.
Fait 5: Le fencing n’est pas une invention Proxmox ; c’est un principe de cluster ancien : si vous ne pouvez prouver qu’un nœud est mort, supposez qu’il est vivant et dangereux.
Fait 6: Les clusters à deux nœuds posent historiquement des problèmes chez plusieurs vendeurs car une seule défaillance retire la majorité ; les brise-égalités (qdevice, witness) sont la solution standard.
Fait 7: Les systèmes de fichiers de cluster et mécanismes de consensus se dégradent souvent en “fail-safe” en passant en lecture seule ou en refusant les verrous lorsque le quorum est perdu — c’est un design de sécurité délibéré.
Fait 8: Beaucoup de “pannes HA” sont en fait des problèmes de sémantique de stockage — le stockage partagé n’est pas juste “monté”, il doit être cohérent, performant et configuré de manière identique sur tous les nœuds.

FAQ

1) Est-ce que “failed to start pve-ha-lrm” signifie toujours que corosync est cassé ?

Non. Corosync/quorum est la cause la plus fréquente, mais le LRM peut aussi échouer à cause de problèmes /etc/pve, d’incohérences d’identité, de watchdog/fencing, ou de corruption/surcharge locale du nœud. Commencez par le quorum car c’est une porte d’entrée stricte.

2) Si le quorum est perdu, puis-je forcer la HA à démarrer quand même ?

Vous pouvez essayer, mais vous demandez à la HA d’opérer sans réalité cohérente. C’est comme provoquer un split-brain et une corruption de stockage. La bonne démarche est de restaurer le quorum ou de désactiver la HA et gérer manuellement les workloads jusqu’à ce que le cluster soit sûr.

3) Pourquoi pmxcfs est-il important pour pve-ha-lrm ?

La HA utilise la configuration et les verrous globaux stockés sous /etc/pve. Si pmxcfs n’est pas monté ou est en lecture seule à cause du manque de quorum, la HA ne peut pas se coordonner et refusera de fonctionner.

4) Quelle est la différence entre pve-ha-manager qui échoue et pve-ha-lrm qui échoue ?

pve-ha-manager est le coordinateur ; s’il est down au niveau du cluster, les décisions HA n’auront pas lieu. pve-ha-lrm est par nœud ; s’il est down sur un nœud, ce nœud ne peut pas exécuter d’actions HA même si le cluster est autrement sain.

5) Un seul mauvais nœud peut-il empêcher la HA de fonctionner sur les autres nœuds ?

Oui, si ce nœud provoque une perte de quorum ou une instabilité d’appartenance. Si le quorum reste intact, les autres nœuds peuvent généralement continuer. L’important est si le cluster peut former une partition majoritaire stable.

6) Mon cluster est à deux nœuds. Est-ce du “vrai HA” ?

Ça peut l’être, mais uniquement si vous ajoutez un vote de départage (qdevice/witness). Sans cela, la perte de l’un ou l’autre nœud (ou une partition réseau) tue généralement le quorum, et la HA refusera d’agir, comme prévu.

7) La HA est up, mais les VMs ne basculent pas. Est-ce encore un problème LRM ?

Parfois. Le LRM peut fonctionner mais échouer dans les actions de ressource à cause du stockage indisponible sur la cible, de contraintes de migration ou de configuration de ressource. Vérifiez ha-manager status, l’état du stockage, et les logs par VM.

8) Quel est l’indicateur le plus rapide qui me dit d’arrêter de toucher à la HA et de réparer le cluster ?

Si vous voyez cfs-lock ... no quorum ou Quorate: No. La HA est aval ; réparez le quorum et la stabilité corosync d’abord.

9) Les dérives temporelles peuvent-elles vraiment causer des problèmes de démarrage HA ?

Oui. Les sauts de temps et une synchronisation instable peuvent se corréler avec des problèmes d’appartenance corosync et des comportements étranges de verrous. Ce n’est pas souvent le premier suspect, mais c’est une cause réelle dans des environnements désordonnés.

10) Si je restaure le quorum, dois-je rebooter les nœuds pour relancer la HA ?

Généralement non. Une fois le quorum et pmxcfs rétablis, redémarrer les services HA suffit la plupart du temps. Un reboot aide seulement si un nœud est bloqué (problèmes de driver, mémoire, erreurs filesystem).

Conclusion : prochaines étapes pratiques

Quand Proxmox affiche failed to start pve-ha-lrm, ce n’est que rarement “un bug HA”. C’est la HA qui refuse d’opérer sans un cluster digne de confiance. Considérez ce refus comme une fonction de sécurité, pas comme un obstacle.

Faites ceci ensuite, dans l’ordre :

Confirmer le quorum et la stabilité d’appartenance avec pvecm status, corosync-cfgtool -s, et les logs corosync.
Vérifier l’état de pmxcfs : /etc/pve monté, lisible, inscriptible (quand quorate).
Vérifier l’identité et le temps : hostnames, /etc/hosts, et la synchronisation temporelle.
Valider les hypothèses watchdog/fencing pour que la HA puisse prendre des décisions sûres en cas de panne partielle.
Puis seulement redémarrer les services HA et vérifier avec ha-manager status.

Si vous suivez ce flux, vous réparerez la cause racine au lieu de vous disputer avec un démon qui fait exactement ce pour quoi il a été conçu : refuser de deviner.