Proxmox HA « impossible de démarrer la ressource » : trouver le vrai blocage (quorum, stockage, réseau)

Ce que « impossible de démarrer la ressource » signifie réellement pour HA

Dans Proxmox HA, une « ressource » est généralement une VM ou un conteneur que la pile HA (CRM + LRM + manager) est responsable de placer, démarrer, arrêter et déplacer. Quand vous voyez « impossible de démarrer la ressource », cela signifie typiquement :

• Le manager HA a tenté une action (démarrer/migrer/récupérer) et le nœud cible a refusé ou n’a pas pu s’exécuter.
• Ou le manager HA a refusé d’agir parce qu’il estimait que cela pourrait créer un split-brain, un double-montage ou un double-démarrage.

Ce second cas explique pourquoi cette erreur est à la fois ennuyeuse et pertinente. HA est conservateur par conception. Il préfère garder votre service arrêté plutôt que de corrompre silencieusement vos données. Ce n’est pas un bug ; c’est la raison d’être du système.

Une citation à garder en tête, parce qu’elle reflète l’attitude des systèmes HA :

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

HA ne fonctionne pas sur l’espoir. Il fonctionne sur un état net et une atteignabilité vérifiée. Si ces éléments ne sont pas clairs, il s’arrête.

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

Voici ce que vous faites quand un cadre surveille, que la VM est tombée et que l’interface HA vous renvoie un haussement d’épaules.

Premier : confirmer que le cluster peut prendre des décisions (quorum + adhésion)

• Vérifiez le quorum (pvecm status). Pas de quorum signifie qu’on ne sait pas « qui possède quoi ».
• Vérifiez l’adhésion corosync (corosync-cfgtool -s, corosync-quorumtool -s). Cherchez des nœuds manquants, des problèmes d’anneau ou une « partition ».
• Vérifiez que pmxcfs est monté et sain (df -h /etc/pve).

Décision : si le quorum est absent, arrêtez de poursuivre les vérifications de stockage. Corrigez d’abord le quorum/l’adhésion. Toute autre « correction » risque d’empirer la situation.

Deuxième : confirmer que l’état du manager HA n’est pas mensonger (état CRM/LRM)

• ha-manager status pour la ressource et le nœud où il pense qu’elle doit s’exécuter.
• Sur chaque nœud : systemctl status pve-ha-lrm pve-ha-crm.
• Surveillez les logs : journalctl -u pve-ha-crm -u pve-ha-lrm -n 200 --no-pager.

Décision : si les services HA sont malsains ou bloqués sur un nœud, corrigez cela avant de démarrer manuellement la VM. Gagner contre HA n’est pas un sport que vous gagnez.

Troisième : vérifier que le stockage requis est vraiment disponible sur le nœud cible

• Vérifiez l’état du stockage Proxmox (pvesm status) et confirmez que les disques VM existent sur le nœud.
• Pour le stockage partagé : vérifiez le montage/la connexion (NFS/iSCSI/Ceph/cibles ZFS réplication).
• Cherchez des verrous (qm config inclut lock:), et vérifiez l’historique des tâches.

Décision : si le stockage n’est pas disponible partout où HA l’attend, la bonne correction est de restaurer l’accès au stockage ou d’ajuster les contraintes de placement HA — pas de « forcer le démarrage » en espérant le meilleur.

Tout le reste — pression CPU, mémoire, logs noyau, attentes de fencing — vient après ces trois étapes. Soyez astucieux plus tard. Soyez correct d’abord.

Modèle mental : quorum, adhésion, manager et réalité du stockage

Le quorum n’est pas « le cluster est en ligne ». C’est « le cluster peut se mettre d’accord ».

Le quorum est le mécanisme qui empêche le split brain : deux moitiés du cluster pensant chacune être le vrai cluster. Sans quorum, Proxmox restreint délibérément les écritures sur le système de fichiers du cluster et bloque certaines actions. Les actions HA sont parmi les premières refusées, car HA sans consensus conduit à des VM double-démarrées et à la corruption des disques.

Corosync est le système nerveux ; la latence est un poison

Corosync est une couche d’adhésion et de messagerie. Il ne veut pas seulement des paquets ; il veut des paquets en temps opportun. Vous pouvez « pinguer » entre nœuds et avoir quand même du flapping corosync à cause de pertes, de réordonnancement ou d’un MTU mal configuré. HA dépend de la stabilité de l’adhésion corosync. Si l’adhésion fluctue, HA change d’avis — parce qu’il le doit.

pmxcfs est votre cerveau partagé

/etc/pve est fourni par pmxcfs (système de fichiers de cluster Proxmox). Ce n’est pas un système de fichiers partagé générique ; c’est une base de données de cluster exposée comme un système de fichiers. S’il n’est pas monté ou non inscriptible à cause d’une perte de quorum, les configurations peuvent sembler « obsolètes », HA ne peut pas coordonner de façon fiable, et vous verrez des erreurs qui ressemblent à des problèmes de VM alors qu’en réalité « les métadonnées du cluster ne sont pas cohérentes ».

Le stockage est le blocage le plus courant, car c’est là que les données peuvent être endommagées

HA peut démarrer une VM sur un nœud uniquement si les disques sont accessibles et sûrs. « Sûr » signifie : le backend de stockage est présent, les disques VM ne sont pas montés ailleurs, et tous les verrous (migration, snapshot, sauvegarde) sont résolus. Beaucoup de backends peuvent être « actifs » mais quand même dangereux : un montage NFS obsolète, une session iSCSI existante mais en train de timeouter, un cluster Ceph en mode dégradé avec I/O bloquées, ou ZFS vivant mais en train de thrash avec une latence élevée.

Blague n°1 : La haute disponibilité, c’est comme un exercice d’incendie : tout le monde adore ça jusqu’à ce que quelqu’un tire réellement l’alarme.

Faits et contexte intéressants (pourquoi ces comportements existent)

• Fait 1 : Le quorum en tant que concept précède la plupart des piles de virtualisation ; c’est un contrôle classique des systèmes distribués pour éviter le « split brain » dans les stockages et bases de données en cluster.
• Fait 2 : Corosync a évolué à partir des efforts initiaux de messagerie pour clusters Linux où l’adhésion stable était considérée comme la pierre angulaire d’un basculement sûr.
• Fait 3 : Le pmxcfs de Proxmox se comporte délibérément différemment en l’absence de quorum : il privilégie la sécurité à la commodité, c’est pourquoi les écritures peuvent être bloquées même quand les nœuds « semblent corrects ».
• Fait 4 : Les piles HA séparent typiquement la « prise de décision » (gestionnaire de ressources cluster) de l’« exécution » (gestionnaire local de ressources). Proxmox suit ce schéma avec les composants CRM et LRM.
• Fait 5 : Le fencing de stockage (s’assurer qu’un nœud défaillant ne peut plus écrire sur le stockage partagé) est antérieur aux hyperviseurs modernes ; il vient des systèmes de fichiers en cluster et des environnements SAN où un seul écrivain incontrôlé pouvait tout corrompre.
• Fait 6 : Les protocoles d’adhésion style « heartbeat » souffraient historiquement de faux positifs pendant la congestion ; les piles modernes font toujours face à la même physique : pertes et jitter ressemblent à une mort de nœud.
• Fait 7 : Les approches « shared-nothing » (comme ZFS local + réplication) réduisent les modes de panne du stockage partagé mais introduisent des problèmes « quelle copie est faisant foi » — toujours un problème de quorum, juste sous un autre angle.
• Fait 8 : Beaucoup d’incidents HA ne sont pas causés par une panne complète, mais par une panne partielle : le nœud est en ligne, le lien est instable, le stockage est à moitié vivant. HA déteste les pannes partielles parce qu’elles sont ambiguës.
• Fait 9 : « Impossible de démarrer la ressource » est souvent un message de sécurité intentionnel. C’est la pile HA qui vous dit qu’elle ne peut pas prouver que démarrer est sûr, pas qu’elle a tenté et échoué comme pour un démarrage manuel.

Tâches pratiques : commandes, sortie attendue et décisions (12+)

Voici les vérifications que j’exécute quand je suis d’astreinte et que je veux la vérité rapidement. Chaque tâche inclut ce que la sortie signifie et ce qu’il faut faire ensuite.

Task 1: Check cluster quorum and expected votes

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

Quorum information
------------------
Date:             Fri Dec 26 10:14:03 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.22
Quorate:          Yes

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

Ce que cela signifie : Quorate: Yes signifie que le cluster peut prendre des décisions faisant autorité et que pmxcfs devrait être inscriptible. S’il affiche No, les actions HA sont souvent bloquées.

Décision : si non quorate, arrêtez ici et réparez la connectivité corosync ou la configuration des votes. Ne forcez pas le démarrage des ressources HA.

Task 2: Check corosync ring status (are all links healthy?)

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

Ce que cela signifie : « active with no faults » est l’état désiré. Les fautes ici se corrèlent fortement avec le refus d’actions HA ou des ressources « flappantes ».

Décision : si un anneau est en faute, corrigez le réseau/MTU/vLAN/jumbo frames avant de toucher HA. Les mauvaises configurations à double anneau sont un classique : « semble redondant, se comporte de façon fragile ».

Task 3: Check corosync quorum details (partition hints)

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Fri Dec 26 10:15:31 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          1
Ring ID:          1.22
Quorate:          Yes

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

Ce que cela signifie : confirme que le sous-système quorum voit la même réalité que pvecm. Si ces sorties divergent, vous êtes déjà dans un territoire étrange.

Décision : si non quorate : traitez cela comme un incident de cluster, pas comme un incident VM.

Task 4: Verify pmxcfs is mounted (and not in a sad state)

cr0x@server:~$ df -h /etc/pve
Filesystem      Size  Used Avail Use% Mounted on
pmxcfs            0     0     0    - /etc/pve

Ce que cela signifie : Cela paraît étrange car ce n’est pas un système de fichiers normal. Si vous voyez « not mounted » ou autre chose, la distribution des configs du cluster est rompue.

Décision : si /etc/pve n’est pas pmxcfs, réparez les services de cluster. HA ne se comportera pas de façon prédictible.

Task 5: Check HA manager view of the world

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Fri Dec 26 10:16:12 2025)

service vm:101 (pve-ha-lrm:pve02, running)
service vm:105 (pve-ha-lrm:pve03, stopped)
service ct:210 (pve-ha-lrm:pve01, running)

Ce que cela signifie : Vous obtenez le master HA, l’état du quorum, et où HA pense que chaque ressource doit être gérée. Si votre VM défaillante est « stopped » alors qu’elle devrait être démarrée, concentrez-vous sur pourquoi elle ne peut pas être placée.

Décision : si le master flappe entre nœuds, vous avez probablement une instabilité corosync. Corrigez cela avant toute autre action.

Task 6: Zoom into a single resource’s state and recent actions

cr0x@server:~$ ha-manager status vm:105
service vm:105
  state: stopped
  desired: started
  node: pve03
  last_error: unable to start VM 105 on node 'pve03': storage 'ceph-vm' is not available

Ce que cela signifie : C’est la ligne décisive. HA indique souvent le véritable blocage dans last_error. Ne l’ignorez pas parce qu’elle n’apparaît pas dans l’interface graphique.

Décision : si last_error pointe vers le stockage, basculez immédiatement sur les vérifications de stockage sur ce nœud.

Task 7: Check HA services health (CRM/LRM)

cr0x@server:~$ systemctl status pve-ha-crm pve-ha-lrm --no-pager
● pve-ha-crm.service - PVE Cluster Resource Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-crm.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:01:12 UTC; 1h 15min ago

● 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:01:14 UTC; 1h 15min ago

Ce que cela signifie : si l’un d’eux n’est pas en cours, l’orchestration HA est compromise. LRM est les « mains » sur chaque nœud ; CRM est le « cerveau » de coordination.

Décision : si un service a échoué, lisez les logs et rétablissez la stabilité du service avant d’essayer des démarrages manuels.

Task 8: Read HA logs like you mean it

cr0x@server:~$ journalctl -u pve-ha-crm -u pve-ha-lrm -n 200 --no-pager
Dec 26 10:12:44 pve01 pve-ha-crm[2123]: status change: node pve03 online
Dec 26 10:13:02 pve01 pve-ha-crm[2123]: trying to start vm:105 on pve03
Dec 26 10:13:07 pve03 pve-ha-lrm[1988]: unable to start vm 105: storage 'ceph-vm' is not available
Dec 26 10:13:07 pve01 pve-ha-crm[2123]: service vm:105 start failed on node pve03 (exit code 255)

Ce que cela signifie : vous obtenez la chronologie. Si le log dit « storage not available », arrêtez le débat. C’est du stockage.

Décision : suivez l’erreur sur le nœud où LRM a échoué. C’est là que se trouve la dépendance manquante.

Task 9: Confirm storage status as Proxmox sees it

cr0x@server:~$ pvesm status
Name         Type     Status           Total        Used       Avail
local        dir      active        19528604     7824480    10716524
local-lvm    lvmthin  active        19000000     9200000     9800000
ceph-vm      rbd      inactive              0           0           0

Ce que cela signifie : inactive signifie que Proxmox ne l’utilisera pas. HA ne démarrera pas une VM dont les disques résident là. Ce n’est pas négociable.

Décision : corrigez la connectivité Ceph/RBD sur ce nœud, ou migrez/restaurez les disques ailleurs, ou modifiez les contraintes de placement HA.

Task 10: Verify the VM’s disks and where they live

cr0x@server:~$ qm config 105
boot: order=scsi0;net0
cores: 4
memory: 8192
name: api-prod-01
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0
scsi0: ceph-vm:vm-105-disk-0,size=80G
scsihw: virtio-scsi-pci

Ce que cela signifie : le disque est sur ceph-vm. Si pvesm status indique que ce stockage est inactif sur le nœud cible, vous avez trouvé le blocage.

Décision : ne tentez pas de « démarrer quand même ». Rendez le stockage actif, ou migrez les disques vers un backend disponible.

Task 11: Look for locks that block start

cr0x@server:~$ qm config 105 | grep -E '^lock:|^template:'
lock: backup

Ce que cela signifie : un verrou peut empêcher le démarrage/la migration. Un verrou backup reste souvent après une sauvegarde interrompue ou un incident de stockage.

Décision : confirmez qu’aucun job de sauvegarde n’est en cours ; si le verrou est obsolète, supprimez-le prudemment (après vérification).

Task 12: Inspect recent tasks for failures that left state behind

cr0x@server:~$ tail -n 30 /var/log/pve/tasks/index
UPID:pve01:00012A1B:0A2F3C4D:676D9B12:vzdump:105:root@pam:
UPID:pve01:00012A40:0A2F3C99:676D9B55:qmstart:105:root@pam:
UPID:pve03:0000B120:0A2F3D01:676D9B90:ha-recover:105:root@pam:

Ce que cela signifie : vous obtenez une piste de miettes de ce qui s’est passé. Utilisez l’UPID pour récupérer les détails.

Décision : si vous voyez des démarrages ou récupérations échoués répétés, traitez cela comme systémique (stockage/réseau), pas comme « réessayez ».

Task 13: Pull one UPID’s real log

cr0x@server:~$ cat /var/log/pve/tasks/0A/2F3C4D-676D9B12
INFO: starting new backup job: vzdump 105 --mode snapshot
ERROR: ceph-vm: rbd: error opening vm-105-disk-0: (2) No such file or directory
INFO: aborting backup

Ce que cela signifie : si les sauvegardes échouent à cause du stockage, le démarrage HA peut échouer pour la même raison. Des images RBD manquantes pointent vers une incohérence de stockage plus profonde.

Décision : arrêtez-vous et validez l’intégrité et la nomenclature du stockage. Ne « nettoyez » pas les verrous avant de savoir ce qui a disparu.

Task 14: Validate cluster network health quickly (drops, errors)

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    8942349234 9023434      0     124       0       0
    TX:  bytes packets errors dropped carrier collsns
    7342342342 8234234      0       0       0       0

Ce que cela signifie : des pertes sur le réseau corosync (ou le bond partagé) sont un indice fort. Corosync tolère certaines pertes, mais la stabilité HA exige un réseau « ennuyeux ».

Décision : si les pertes augmentent pendant l’incident, examinez les buffers du switch, le MTU, le hashing LACP ou une liaison saturée.

Task 15: Check time sync (yes, it matters more than you want)

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

Ce que cela signifie : si les horloges divergent, les logs mentent et le débogage devient une danse interprétative. Certaines authentifications et comportements de cluster deviennent également instables avec un décalage temporel.

Décision : si la synchronisation est défaillante, corrigez NTP/chrony sur tous les nœuds avant de chasser des comportements HA « aléatoires ».

Task 16: Confirm the VM is not actually running somewhere else

cr0x@server:~$ qm list | awk '$1==105 {print}'
105 api-prod-01               stopped    8192     4

Ce que cela signifie : Proxmox indique qu’elle est arrêtée sur ce nœud. Répétez sur d’autres nœuds si vous suspectez un split-brain ou un état obsolète.

Décision : si vous la trouvez en cours d’exécution ailleurs, ne lancez pas une seconde copie. Analysez immédiatement le placement HA et les verrous.

Trouver le véritable blocage : quorum vs stockage vs réseau vs état

1) Perte de quorum : le « tout arrêter » silencieux

Quand le quorum est perdu, beaucoup de choses continuent d’avoir l’air opérationnelles. Les nœuds démarrent. Vous pouvez SSHer. Vous pouvez même accéder au stockage local. L’interface peut s’afficher. Et HA refusera quand même de faire ce que vous voulez, parce qu’il ne peut pas prouver que c’est sûr.

Signes typiques :

• pvecm status affiche Quorate: No.
• /etc/pve est en lecture seule ou ne se met pas à jour entre les nœuds.
• Le master HA bascule, ou HA rapporte « quorum not OK ».

Que faire : restaurez la connectivité entre la majorité des nœuds. Si vous avez un cluster à deux nœuds sans dispositif de vote tertiaire approprié, vous vivez en bordure par conception. Ajoutez un dispositif de quorum ou un troisième nœud si vous voulez un comportement HA qui ne ressemble pas à de l’art performance.

2) Partition réseau : le cluster ne peut pas se mettre d’accord parce qu’il ne peut pas parler

Les partitions sont pires que les pannes. Une panne est honnête ; une partition est menteuse. Avec une partition, les deux côtés peuvent être vivants. Les deux côtés peuvent penser que l’autre est mort. C’est ainsi que naît la corruption des données.

Signes typiques :

• Fautes d’anneau corosync sur un ou plusieurs nœuds.
• Changements d’adhésion intermittents dans journalctl -u corosync.
• Pertes de paquets, MTU mal assorti, ou une règle de pare-feu « utile » ajoutée par quelqu’un qui déteste les week-ends.

Que faire : stabilisez le réseau corosync : VLAN dédié, MTU cohérent bout en bout, pas de routage asymétrique, pas de filtrage et une latence prévisible. HA veut de l’ennui. Donnez-lui de l’ennui.

3) Stockage indisponible : le blocage que HA a raison d’appliquer

Les problèmes de stockage produisent le plus fréquent « impossible de démarrer la ressource », car ils sont à la fois courants et dangereux. HA refusera de démarrer si elle ne peut pas accéder aux disques VM en toute sécurité. « En toute sécurité » inclut « pas déjà utilisé ailleurs ».

Signes typiques :

• pvesm status montre le stockage inactive sur le nœud cible.
• Erreurs Ceph/RBD dans les logs, timeouts de session iSCSI, ou « stale file handle » NFS.
• La config VM pointe vers un stockage absent sur certains nœuds du groupe HA.

Que faire : rendez le stockage uniformément disponible sur tous les nœuds qui pourraient exécuter la ressource, ou restreignez la ressource aux nœuds qui ont l’accès au stockage. Le placement HA sans symétrie de stockage, c’est du chaos avec des étapes en plus.

4) Verrous et état obsolète : HA attend une condition qui ne se libère jamais

Parfois le cluster est sain et le stockage fonctionne, mais la ressource est « verrouillée » ou HA pense qu’elle est en transition. Cela peut arriver après des migrations interrompues, des sauvegardes, ou un crash de nœud en cours d’opération.

Signes typiques :

• qm config montre des valeurs lock: comme backup, migrate, snapshot.
• Les tâches montrent des opérations non terminées.
• L’état HA affiche des tentatives répétées avec des codes d’erreur mais sans progression.

Que faire : confirmez que l’opération n’est plus en cours. Ensuite, effacez les verrous obsolètes avec précaution. Si vous supprimez des verrous alors que le processus sous-jacent est encore actif, vous pouvez créer exactement le type de conflit en écriture double que HA existe pour prévenir.

Blague n°2 : La seule chose pire qu’un manager HA bloqué, c’est deux managers « débloqués », convaincus d’être les héros.

Trois mini-récits d’entreprise tirés de la vie réelle

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: HA says “cannot start resource” right after a node reboot

Cause racine : Quorum temporairement perdu ou adhésion corosync instable pendant le reboot ; HA refuse d’agir en toute sécurité.

Correction : vérifiez pvecm status est quorate et que les anneaux corosync sont sains. Ne poursuivez pas les logs VM tant que le cluster ne s’est pas mis d’accord sur l’adhésion.

2) Symptom: VM starts manually with qm start, but HA won’t start it

Cause racine : contraintes HA ou machine d’état HA pense que la VM appartient ailleurs, ou une défaillance antérieure est enregistrée ; HA applique la politique, pas seulement la capacité.

Correction : vérifiez ha-manager status vm:ID et les groupes HA. Alignez les actions manuelles sur HA : désactivez temporairement HA pour cette VM ou corrigez le problème de placement sous-jacent.

3) Symptom: Storage shows “active” on one node, “inactive” on another

Cause racine : connectivité backend spécifique au nœud : routes manquantes, multipath échoué, problèmes d’auth Ceph, montage NFS obsolète ou règles de pare-feu.

Correction : corrigez la connectivité du stockage sur le nœud défaillant, ou retirez ce nœud du groupe HA pour les ressources sur ce stockage. HA exige symétrie ou contraintes explicites.

4) Symptom: “cannot start resource” after a backup window

Cause racine : verrou obsolète laissé par une sauvegarde interrompue, ou problèmes de snapshot, ou incident de stockage pendant la sauvegarde.

Correction : confirmez qu’aucun job de sauvegarde n’est en cours, inspectez les logs de tâches, puis nettoyez les verrous obsolètes. Si les sauvegardes sont fréquemment interrompues, corrigez le stockage/réseau qui en est la cause.

5) Symptom: HA keeps moving a VM back and forth (“ping-pong”)

Cause racine : adhésion corosync qui flappe, contrôles de santé du nœud qui échouent de façon intermittente, ou timeouts de démarrage de ressource trop agressifs.

Correction : stabilisez le réseau corosync, annulez les réglages de timeouts trop agressifs, et vérifiez les contraintes de ressource au niveau du nœud (CPU, mémoire, latence stockage).

6) Symptom: UI shows node online, but HA says node offline

Cause racine : le réseau de gestion est up, mais le réseau corosync ne l’est pas (ou l’inverse). L’interface peut induire en erreur car ce n’est pas l’oracle d’adhésion.

Correction : faites confiance aux outils corosync (corosync-cfgtool, corosync-quorumtool) et corrigez le chemin corosync.

7) Symptom: “storage is not available” but Ceph/NFS “looks fine” from one node

Cause racine : panne partielle : le backend est joignable mais trop lent, bloqué ou en timeout ; Proxmox le marque inactif après des vérifications échouées.

Correction : vérifiez la santé du backend depuis le nœud qui échoue spécifiquement. Pour Ceph : vérifiez l’auth client et la reachabilité des monitors. Pour NFS : cherchez des montages obsolètes et examinez les logs noyau.

8) Symptom: HA refuses to recover after a crash; resource stuck in “error”

Cause racine : HA a enregistré une défaillance et empêche les boucles ; ou LRM sur le nœud cible ne fonctionne pas ; ou la ressource est encore « possédée » quelque part à cause d’un verrou/état.

Correction : lisez les logs CRM/LRM, vérifiez les services LRM, contrôlez les verrous, et envisagez une action de nettoyage ha-manager contrôlée seulement après avoir corrigé la cause sous-jacente.

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

Checklist d’urgence : remettre une ressource en fonctionnement en toute sécurité

1. Confirmer le quorum : pvecm status doit être quorate. Si non, restaurez d’abord la connectivité majoritaire.
2. Confirmer la stabilité d’adhésion : corosync-cfgtool -s doit montrer des anneaux actifs sans fautes.
3. Confirmer l’état de /etc/pve : df -h /etc/pve affiche pmxcfs.
4. Lire l’erreur propre à HA : ha-manager status vm:ID et vérifiez last_error.
5. Vérifier le stockage requis sur le nœud cible : pvesm status et validez le stockage des disques via qm config ID.
6. Vérifier les verrous : qm config ID | grep '^lock:'.
7. Inspecter l’historique des tâches : lisez les logs de tâches pour la VM et les dernières opérations.
8. Ensuite seulement : tentez une récupération via HA (préféré) ou un démarrage manuel contrôlé avec HA désactivé (uniquement si vous comprenez les conséquences).

Checklist de stabilité : empêcher le retour de « impossible de démarrer la ressource »

1. Rendre le réseau corosync ennuyeux : VLAN dédié, MTU cohérent, pas d’ingérence pare-feu, surveiller pertes et latence.
2. Arrêtez de traiter les clusters à deux nœuds comme HA : utilisez un dispositif de quorum ou un troisième nœud pour un vrai arbitrage.
3. Contraindre la symétrie de stockage : si une VM est gérée en HA sur plusieurs nœuds, son stockage doit être accessible sur ces nœuds, ou encodez cette réalité dans les groupes/contraintes HA.
4. Standardiser les vérifications de santé du stockage par nœud : ne considérez pas « marche sur le nœud A » comme preuve suffisante.
5. Maintenir la synchronisation temporelle : NTP/chrony cohérents sur tous les nœuds.
6. Documenter les attentes de fencing : même si Proxmox HA ne réalise pas de fencing externe, votre runbook opérationnel doit préciser comment éviter les double-écritures.
7. Pratiquer un exercice de basculement trimestriel : pas pour impressionner — pour savoir à quoi ressemble le « normal étrange » dans les logs.

Garde-fous décisionnels (ce qu’il faut éviter sous pression)

• Évitez : effacer des verrous sans réfléchir. Faites : confirmez que le job sous-jacent est réellement terminé.
• Évitez : redémarrer des nœuds au hasard « pour réparer HA ». Faites : identifiez si le problème est quorum, stockage ou réseau d’abord.
• Évitez : modifier les timeouts corosync en pleine incident. Faites : stabilisez le chemin réseau ; affinez ensuite avec des données.

FAQ

1) Est-ce que « impossible de démarrer la ressource » signifie toujours des problèmes de quorum ?

Non. Le quorum est fréquent, mais l’indisponibilité du stockage et les verrous sont tout aussi courants. La vérité la plus rapide se trouve dans ha-manager status vm:ID et dans les logs LRM sur le nœud cible.

2) L’interface affiche tout en vert. Pourquoi HA refuse-t-il quand même ?

L’interface reflète la disponibilité du plan de gestion et certains états du cluster, mais les décisions HA dépendent de l’adhésion corosync et des vérifications de stockage. Faites confiance aux outils corosync et aux logs HA plutôt qu’à l’optimisme de l’interface.

3) Puis-je simplement lancer qm start et ignorer HA ?

Vous le pouvez, mais vous prenez la responsabilité de la sécurité. Si la pile HA estime qu’il y a un risque de split brain ou de double-montage, un démarrage manuel peut transformer un « temps d’arrêt » en « récupération de données ». Si vous devez le faire, désactivez d’abord HA pour cette ressource et vérifiez l’exclusivité du stockage.

4) Pourquoi HA se préoccupe du stockage « inactif » si le montage existe ?

Parce que « monté » ne signifie pas « fonctionnel ». NFS peut être monté mais bloqué ; iSCSI peut être connecté mais en timeout ; Ceph peut être lié mais I/O bloquées. Proxmox marque un stockage inactif quand ses contrôles échouent ou timeoutent.

5) Quelle est la différence entre CRM et LRM dans Proxmox HA ?

CRM coordonne les décisions à l’échelle du cluster (où une ressource doit s’exécuter). LRM exécute les actions sur un nœud (démarrer/arrêter). « Impossible de démarrer la ressource » signifie souvent que CRM a demandé, LRM a essayé, et qu’une dépendance locale a échoué.

6) Si corosync est instable, pourquoi mes VMs continuent-elles de fonctionner ?

Les VMs peuvent rester en cours sur leur nœud actuel même si le cluster est confus. Démarrer et déplacer des VMs en toute sécurité est la partie difficile. HA cessera d’initier des actions si l’adhésion n’est pas stable.

7) Comment distinguer rapidement une panne de stockage d’une partition réseau ?

Si le quorum est perdu ou que les anneaux signalent des fautes, c’est d’abord réseau/adhésion. Si le quorum est OK et que HA indique « storage not available », exécutez pvesm status sur le nœud cible et confirmez le stockage de la VM via qm config. Les problèmes de stockage sont souvent spécifiques à un nœud et n’apparaîtront pas sur un pair sain.

8) Pourquoi un cluster à deux nœuds paraît-il si fragile ?

Parce qu’il l’est. Avec deux nœuds, toute perte de nœud (ou de lien) crée un partage égal. Sans vote tiers (qdevice), vous ne pouvez pas prouver quel côté est autoritaire. HA devient conservateur, comme il se doit.

9) Que faire si je suspecte que l’état du manager HA est obsolète ?

Confirmez d’abord le quorum et la stabilité corosync. Ensuite, vérifiez les services HA sur tous les nœuds. Si le manager est bloqué, redémarrer les services HA peut aider, mais faites-le délibérément et seulement après avoir confirmé que la dépendance sous-jacente (stockage/réseau) est réellement corrigée.

Conclusion : étapes suivantes pour éviter les récidives

« Impossible de démarrer la ressource » est Proxmox HA qui vous dit qu’il ne peut pas prouver que l’opération est sûre. Votre tâche est de supprimer l’ambiguïté. Faites-le dans cet ordre : quorum/adhésion, état du manager HA, puis disponibilité du stockage et verrous.

Étapes pratiques :

1. Rédigez un runbook d’une page commençant par pvecm status, corosync-cfgtool -s et ha-manager status vm:ID. Rendez-le ennuyeux et obligatoire.
2. Auditez les ressources HA pour la symétrie du stockage. Si une VM ne peut fonctionner que sur deux nœuds à cause du stockage, encodez-le dans les groupes et contraintes HA.
3. Instrumentez votre réseau corosync : pertes, erreurs, MTU cohérent et saturation. Les échecs HA sont souvent des pannes réseau qui ont attendu poliment pour devenir évidentes.
4. Pratiquez un basculement contrôlé quand personne ne panique. Le meilleur moment pour apprendre le comportement HA, c’est quand il ne cherche pas à vous humilier.