Proxmox «failed to start pve-ha-lrm»: por qué HA no arranca y qué comprobar

enero 13, 2026 • febrero 3, 2026 • Lectura: 26 min • Views: 8

¿Te fue útil?

Esa línea de estado en rojo—failed to start pve-ha-lrm—aparece justo cuando necesitas que HA se comporte como HA. Un nodo se reinicia, una ruta de almacenamiento tiene una caída, o alguien con una lista de comprobación “mejora” un switch, y de repente el Local Resource Manager (LRM) no arranca. Tu clúster está lo bastante vivo como para burlarse de ti, pero no lo bastante sano como para hacer un failover.

Esto no es una situación de “reinicia el servicio”. pve-ha-lrm es el síntoma. La causa casi siempre es una de estas: el sistema de archivos del clúster no está bien, problemas con corosync/quórum, rarezas de tiempo o resolución de nombres, configuración de fencing/watchdog, o aristas de almacenamiento que HA se niega a adivinar.

Qué hace realmente pve-ha-lrm (y por qué se niega a arrancar)

Proxmox HA se divide en dos roles principales:

pve-ha-manager: el cerebro del clúster que decide dónde deben ejecutarse los recursos (VMs/CTs).
pve-ha-lrm: la capa de ejecución local en el nodo que inicia/para/migra recursos y reporta el estado de vuelta.

El LRM es deliberadamente conservador. Si no puede confiar en el estado del clúster, no puede leer el sistema de archivos del clúster, no puede hablar con corosync de forma fiable, o detecta inconsistencias de fencing/watchdog, se dará por vencido. Eso no es ser “quisquilloso”. Es cómo evitas un split-brain con arranques dobles, que es la versión HA de prender fuego a tus datos con papeleo adjunto.

Una verdad operativa que merece estar tatuada en un runbook: HA depende de que el clúster sea aburrido. No “innovador”. No “optmizado”. Aburrido. Cuanto menos sorprendentes sean tu hora, red, semántica de almacenamiento e identidad de nodos, más podrá HA hacer su trabajo de forma segura.

Y sí, a veces puedes forzar cosas con arranques manuales. Pero si no solucionas los problemas subyacentes de confianza, HA seguirá negándose a asumir responsabilidad—como un adolescente al que le pides que conduzca en una ventisca con neumáticos pelados.

Guía de diagnóstico rápido (primero/segundo/tercero)

Si estás de guardia y el pager suena, necesitas localizar el cuello de botella rápido. Aquí está el orden que desperdicia menos tiempo.

Primero: determina si es un problema de clúster/quórum

Comprueba si corosync está arriba y tiene quórum.
Verifica si pmxcfs está montado y es escribible.
Revisa la membresía del clúster y la consistencia de los nombres de nodo.

Si falta quórum o pmxcfs está roto, HA no tiene un modelo de mundo seguro. Arregla eso antes de tocar los servicios HA.

Segundo: confirma los servicios HA y sus errores inmediatos

Lee el estado systemd de pve-ha-lrm y pve-ha-manager.
Consulta los registros del journal alrededor del momento de la falla.
Comprueba si el nodo está atascado en un estado fenced/maintenance.

Tercero: valida prerrequisitos de almacenamiento para recursos HA

Almacenamiento compartido presente donde se espera (o estás usando replicación correctamente).
Configuración de almacenamiento consistente entre nodos.
Bloqueos obsoletos o errores a nivel de almacenamiento que no bloqueen acciones de inicio.

Heurística de atajo: Si la interfaz muestra un estado de clúster extraño, tu problema no es HA. Si la interfaz muestra clúster sano pero HA no puede gestionar una VM, lo más probable es que sea almacenamiento o configuración de recursos.

Requisitos imprescindibles antes de que HA piense en arrancar

1) La membresía de corosync y el quórum deben estar sanos

LRM depende de la capa de comunicaciones del clúster. Si corosync no puede formar una membresía estable, las decisiones HA se vuelven inseguras: una VM puede iniciarse en dos nodos o detenerse en el equivocado. Proxmox está diseñado para evitar eso siendo terco.

2) pmxcfs debe estar montado y consistente

pmxcfs es el sistema de archivos del clúster de Proxmox (un FUSE) que proporciona la configuración distribuida bajo /etc/pve. Si no está montado, HA no puede leer el estado y la configuración del clúster de forma fiable.

3) La identidad del nodo debe coincidir entre capas

Desajustes en nombres de nodo—entre hostname, /etc/hosts, la nodelist de corosync y lo que Proxmox cree—causan fallos sutiles. Los procesos HA no están interesados en tu creatividad con alias DNS.

4) El tiempo no debe desviarse hacia el valle extraño

Corosync y la coordinación distribuida se comportan mal cuando el tiempo salta. Problemas de NTP/chrony pueden crear síntomas que parecen “aleatorios” en la membresía. Spoiler: no son aleatorios.

5) La configuración de fencing/watchdog debe ser coherente

HA sin fencing es básicamente “mejor esfuerzo”. Proxmox puede usar fencing basado en watchdog (y se integra con enfoques externos según la configuración). Si LRM detecta requisitos de watchdog incumplidos, puede negarse a funcionar o comportarse como si estuviera bloqueado.

Chiste #1: HA sin quórum es como un comité sin actas: todos recuerdan una realidad distinta, y de alguna manera finanzas siempre gana.

Tareas prácticas: comandos, significado de la salida y decisiones

A continuación hay 14 tareas prácticas que puedes ejecutar en un nodo que informa failed to start pve-ha-lrm. Cada una incluye qué significa la salida y qué decisión tomar después. Ejecútalas primero en el nodo con fallo y luego al menos en un nodo sano para comparar.

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'.

Significado: La línea de error suele decirte qué subsistema está roto. Aquí se queja de /etc/pve, lo que indica a gritos que pmxcfs no está montado o el FS del clúster no está disponible.

Decisión: Si los errores mencionan /etc/pve, ve directamente a las Tareas 4–6 (pmxcfs + corosync + quórum).

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'.

Significado: Este es el clásico: no quorum. HA se niega a funcionar porque no puede coordinarse de forma segura.

Decisión: No intentes “forzar” los servicios HA. Restaura el quórum: membresía de corosync, red, votos o contar nodos. Ve a Task 7 y Task 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

Significado: Que el manager esté ejecutándose no garantiza que LRM pueda arrancar. Pero si ambos están muertos, probablemente estés ante un problema más profundo del clúster/pmxcfs y no un fallo local.

Decisión: Si el manager está abajo en varios nodos, trátalo como un problema a nivel de clúster. Si solo falla LRM en un nodo, examina prerrequisitos locales o un estado atascado.

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)

Significado: Si no ves pve-cluster on /etc/pve, HA no funcionará porque la configuración/estado es inaccesible.

Decisión: Si falta, comprueba pve-cluster y corosync (Task 5 y Task 7). No inicies HA hasta que /etc/pve esté montado.

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

Significado: Si pve-cluster no está en ejecución, /etc/pve no estará disponible.

Decisión: Si falla, los registros a menudo dirán “no quorum” o mostrarán errores de conexión con corosync. Arregla corosync/quórum primero; reiniciar pmxcfs sin quórum es jugar al 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

Significado: Quorate: Yes es la luz verde. Si es No, es esperable que HA se detenga.

Decisión: Si no hay quórum, no intentes “recuperar” HA reiniciando servicios. Necesitas recuperar quórum, o una decisión deliberada para operar sin él (rara vez correcto, normalmente desesperado).

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

Significado: Que corosync esté en ejecución no garantiza estabilidad de la membresía. Necesitas comprobar la vista del clúster (Task 8) y los registros (Task 9).

Decisión: Si corosync está inactivo/fallido, arréglalo antes de HA. Si está activo pero se perdió quórum, revisa la red, los votos de nodos o un nodo ausente.

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

Significado: “connected” entre peers es lo que quieres. Si ves “disconnected”, “faulty” o un nodo ausente, ahí está tu problema de quórum.

Decisión: Si los enlaces están dando flaps, deja de perseguir HA y arregla la ruta de red (MTU desajustada, pérdida de paquetes, firewall, features del switch). A corosync no le gustan las sorpresas.

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

Significado: Eventos link down/up se correlacionan con pérdida de quórum y HA negándose a bloquear el estado del clúster.

Decisión: Trátalo como red/transporte. Busca cambios de MTU, problemas con VLANs, enrutamiento asimétrico o bugs de offload en la NIC. Si ocurre bajo carga, sospecha microbursts o una política de switch que “protege” contra 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

Significado: Los clústeres Proxmox son sensibles a la consistencia de identidades. Quieres que el hostname del nodo coincida con lo que el clúster espera, y resolución estable para nodos pares.

Decisión: Si los hostnames no coinciden con los nombres de nodo del clúster, corrige la identidad con cuidado (y planifica downtime). No “cambies DNS y listo”.

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)

Significado: Si el nodo con fallo muestra lrm ... (idle) o falta, no está participando. Si el master está rebotando o ausente, tu manager HA es inestable.

Decisión: Si el quórum está OK pero LRM está idle/falta, céntrate en problemas locales: systemd, watchdog, permisos, montaje de pmxcfs, o errores del agente de recursos.

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

Significado: Dispositivos watchdog faltantes o un multiplexor muerto pueden bloquear supuestos de fencing y hacer que HA sea conservador (o se comporte mal durante fallas).

Decisión: Si falta el watchdog y tu política HA lo requiere, arregla hardware/driver/BIOS antes de confiar en 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%

Significado: Si el almacenamiento que necesita una VM falta/inactivo en el nodo, HA puede no iniciar esa VM y dejar recursos en estados de error. A veces el arranque del LRM en sí está bien; la primera acción desencadena fallos.

Decisión: Si el almacenamiento compartido está inactivo en el nodo con fallo, deja de culpar a HA. Arregla el montaje/autenticación/ruta de red; luego reintenta las acciones 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)

Significado: pveperf contra /etc/pve es una comprobación de salud aproximada. Si se queda colgado o produce errores extraños, tu sistema de archivos de clúster está enfermo (a menudo por quórum inestable o nodo sobrecargado).

Decisión: Si pveperf /etc/pve cuelga, trátalo como un problema de comunicaciones del clúster/quórum o contención severa de recursos en el nodo. Arregla la estabilidad antes de HA.

Modos de fallo que se mapean directamente a “failed to start pve-ha-lrm”

1) Sin quórum (más común, comportamiento más correcto)

HA necesita consenso. Sin quórum no puede adquirir bloqueos en el sistema de archivos del clúster de forma segura. Verás errores como:

cfs-lock ... error: no quorum
unable to read cluster config (porque pmxcfs está en modo solo lectura/sin quórum)

Dirección de la solución: restaura la membresía. Recupera el nodo perdido, arregla la red de corosync, o corrige las expectativas de voto. Si tienes un clúster de dos nodos, lee la sección “FAQ” sobre por qué eso es una trampa salvo que uses un qdevice.

2) pmxcfs no montado o no saludable

Si /etc/pve no está montado, en efecto no tienes un clúster Proxmox en ese nodo. HA fallará. Esto puede suceder si:

pve-cluster no arrancó
corosync está abajo o no autenticado
el nodo arranca en un estado donde no puede alcanzar pares y por tanto no obtiene quórum

Dirección de la solución: trátalo como “clúster no formado”. Resuelve corosync e identidad primero, luego reinicia pve-cluster, y después HA.

3) Flapping de enlaces de corosync (pecados de red y MTU)

Cuando corosync no es estable, HA tiende a parecer “aleatoriamente roto”. No es aleatorio; responde a cambios de membresía. Causas:

Desajuste de MTU (especialmente con VLANs, bonds, jumbo frames)
Reglas de firewall añadidas “temporalmente”
Control de tormentas en switches / filtrado de multicast / limitación de UDP
Problemas de offload de NIC/driver bajo carga

Dirección de la solución: haz que la red de corosync sea aburrida: MTU consistente de extremo a extremo, sin filtrado, baja pérdida y latencia predecible.

4) Desajuste de nombre de nodo o identidad obsoleta

Si los nombres de nodo cambian (hostname modificado tras crear el clúster, DNS devuelve nombres nuevos, o /etc/hosts difiere), la membresía del clúster puede formarse pero las capas superiores no pueden reconciliar identidades. HA entonces puede fallar al mapear recursos a nodos.

Dirección de la solución: estandariza nombres. Prefiere hostnames estables y mapeos estáticos para tráfico crítico del clúster. Si debes renombrar, hazlo como una migración controlada validando la vista de nombres en cada nodo.

5) Prerrequisitos de watchdog/fencing no cumplidos

En HA, fencing es cómo aseguras que un nodo esté realmente muerto antes de arrancar sus cargas en otro sitio. Si el dispositivo watchdog falta o está mal configurado, algunas configuraciones HA se negarán a operar como están diseñadas o se comportarán de forma conservadora. La falla puede presentarse como LRM negándose a arrancar o deteniéndose rápidamente.

Dirección de la solución: verifica disponibilidad del watchdog, ajustes de BIOS, módulos de kernel y estado del servicio. Si tu política requiere fencing, no lo renuncies a la ligera.

6) Fallos de agentes de recursos que parecen fallos de LRM

A veces pve-ha-lrm arranca bien pero inmediatamente reporta fallos en recursos, y el operador interpreta que “LRM no arranca”. Los registros dicen la verdad: una acción de arranque/migración falla por almacenamiento, bloqueos o configuración.

Dirección de la solución: separa “daemon LRM falló” de “LRM no pudo ejecutar acciones de recursos”. Usa ha-manager status y los logs por-VM.

Cita (idea parafraseada): La lección de fiabilidad de Peter Drucker: “No puedes gestionar lo que no mides.” En HA, las mediciones que importan primero son la membresía y el quórum.

Errores comunes: síntoma → causa raíz → solución

Esta sección es intencionalmente directa. Estos son los errores que se repiten porque parecen atajos razonables a las 2 a.m.

Mistake 1: “Reiniciar servicios HA” cuando se perdió el quórum

Síntoma: pve-ha-lrm falla con no quorum y sigues reiniciándolo.

Causa raíz: El clúster no puede bloquear el estado de forma segura; reiniciar no restaura el consenso.

Solución: Restaura membresía de corosync y quórum. Solo entonces reinicia servicios HA (si no se recuperan automáticamente).

Mistake 2: Clúster de dos nodos sin desempate

Síntoma: Un nodo se reinicia o una pequeña incidencia de red derriba HA; pve-ha-lrm falla; Quorate: No.

Causa raíz: Con 2 nodos, perder cualquiera de los dos te hace perder la mayoría salvo que uses un qdevice o un tercer voto.

Solución: Añade un qdevice (o un tercer nodo). Si no puedes, acepta que “HA” es condicional y operacionalmente caro.

Mistake 3: Cambiar hostname/DNS tras crear el clúster

Síntoma: Corosync parece arriba, pero los nodos muestran identidades extrañas; HA no puede coordinar; LRM muestra errores sobre nodos faltantes.

Causa raíz: La identidad del nodo no es solo “lo que DNS dice hoy”.

Solución: Mantén hostnames estables. Si renombrar es obligatorio, planifica una reconfiguración controlada y valida la vista de nombres e IPs en cada nodo.

Mistake 4: Compartir la red de corosync con tráfico congestionado de almacenamiento o VMs

Síntoma: HA se cae durante backups, migraciones o rebalanceos de almacenamiento; la membresía hace flapping.

Causa raíz: El tráfico de corosync es sensible a pérdida/latencia. La congestión hace que parezca que los nodos fallan.

Solución: Sitúa corosync en una red dedicada y de baja pérdida (o al menos en una VLAN/QoS protegida). Mantén MTU consistente.

Mistake 5: “Optimizar” MTU o bonding sin probar corosync

Síntoma: Pérdida de quórum aleatoria tras “mejoras” de red.

Causa raíz: Desajuste de MTU o cambios en hashing LACP que causan pérdida/reordenamiento de paquetes UDP.

Solución: Valida MTU de extremo a extremo con pruebas reales y verifica estabilidad de corosync bajo carga. Si no puedes demostrarlo, no lo despliegues.

Mistake 6: Recursos HA configurados sin garantías de almacenamiento compartido

Síntoma: HA se niega a arrancar o falla inmediatamente al intentar iniciar una VM en otro nodo.

Causa raíz: Los discos de la VM están en almacenamiento local del nodo; el failover no puede acceder a ellos.

Solución: Mueve discos a almacenamiento compartido, usa Ceph/RBD, o aplica replicación adecuada. “HA” no teletransporta datos.

Chiste #2: Lo único más aterrador que un split-brain es darse cuenta de que ambas mitades creen ser “primarias” porque así las nombraste.

Listas de comprobación / plan paso a paso

Checklist A: Recuperar HA de forma segura en un nodo

Confirma que corosync está estable: sin flaps de membresía en registros durante varios minutos con tráfico normal.
Confirma quórum: pvecm status muestra Quorate: Yes.
Confirma pmxcfs: mount | grep /etc/pve muestra montado en lectura-escritura.
Confirma sincronización de tiempo: chrony/ntp estable; sin grandes desfases.
Confirma watchdog (si se usa): dispositivos presentes y servicio activo.
Inicia la pila HA (si no está ya): inicia manager y luego LRM, y observa los registros.
Verifica estado HA: ha-manager status muestra LRM activo.

Checklist B: Cuándo detenerse y declarar incidente

El quórum hace flapping repetidamente y no puedes correlacionarlo con la caída de un nodo concreto.
/etc/pve desaparece intermitentemente o pasa a solo lectura.
Los registros de corosync muestran link up/down frecuentes sin causa física clara.
Los nodos discrepan sobre la membresía o los votos esperados.
Ves signos de corrupción de almacenamiento o errores I/O repetidos en el disco del sistema (pmxcfs depende de que el nodo también esté sano).

Checklist C: Secuencia de reinicio limpia (solo después de que el quórum sea sólido)

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)

Significado: Si arranca bien ahora, la falla anterior fue casi con seguridad quórum/pmxcfs/identidad, no “un paquete HA roto”.

Decisión: Si todavía falla, vuelve a los registros y correlaciona con los modos de fallo. No hagas bucles de reinicio; solo crearás más ruido.

Tres micro-historias corporativas desde el campo

Incidente por una suposición equivocada: “DNS está bien; solo son nombres”

Una empresa mediana ejecutaba un clúster Proxmox en una oficina regional. No era glamuroso, pero alojaba lo habitual: un stack de monitorización, algunas VMs Windows, apps internas y un servicio de archivos. Tenían HA activado porque alguien prometió a dirección “failover automático”.

Un lunes migraron el DNS interno a un nuevo par de servidores. El plan parecía limpio: replicar zonas, actualizar opciones DHCP y retirar las cajas viejas. No había cambios programados en Proxmox porque, según la solicitud de cambio, “DNS no impacta el clustering del hipervisor”.

Tras el corte, HA empezó a comportarse de forma fantasmagórica. pve-ha-lrm falló en un nodo y luego en otro. Corosync “estaba en ejecución”, pero el quórum oscilaba durante operaciones normales. El culpable real no fue la disponibilidad del DNS, sino su comportamiento. El nuevo resolver devolvía respuestas distintas para nombres cortos frente a FQDNs, y un nodo tenía un mapeo obsoleto en /etc/hosts. La membresía de corosync se formaba, pero las comparaciones de identidad en capas superiores no coincidían de forma consistente. El clúster básicamente tuvo una crisis existencial.

La solución fue aburrida: fijar la resolución de red del clúster con entradas estables, alinear hostnames con lo que Proxmox espera y dejar de usar nombres cortos ambiguos en rutas críticas del clúster. HA se recuperó de inmediato.

La suposición equivocada fue pensar que el naming es cosmético. En clústeres, los nombres son identidad. La identidad es seguridad. La seguridad es coordinación. La coordinación determina si tu VM arranca una vez o dos veces.

Optimización que salió mal: “Vamos a jumbo-framear todo”

Un equipo empresarial tenía un clúster Proxmox de tres nodos con almacenamiento compartido y una VLAN separada para corosync. Querían migraciones más rápidas y menos CPU, así que desplegaron jumbo frames en toda la capa de virtualización. El cambio se aprobó rápidamente porque lo habían hecho en otros entornos.

Pusieron MTU 9000 en NICs host y en los switches top-of-rack. El rendimiento de almacenamiento mejoró. Las migraciones fueron más rápidas. Todos celebraron.

Entonces HA empezó a fallar al arrancar en un nodo tras reinicios. El error era intermitente: a veces pve-ha-lrm arrancaba, otras lanzaba no quorum brevemente y quedaba muerto. Los registros de corosync mostraban flaps de enlace de unos segundos, normalmente cuando arrancaban backups.

La “optimización” estaba incompleta: un trunk entre switches en la ruta de corosync seguía con MTU 1500. Bajo tráfico ligero, la fragmentación y buffering enmascaraban el problema. Bajo carga, los paquetes se perdían. Corosync interpretó la pérdida como inestabilidad de nodos, el quórum bajó y los procesos HA se negaron a bloquear estado.

La solución no fue heroica: hacer MTU consistente de extremo a extremo y verificar con pruebas reales y tráfico sostenido. Tras eso, HA se comportó como si nunca los hubiese conocido.

La lección: mejoras de rendimiento que tocan fundamentos de red necesitan un plan de validación que incluya la estabilidad de corosync. Tu almacenamiento puede tolerar algo de pérdida. Tu coordinador de clúster no lo hará.

Práctica aburrida pero correcta que salvó el día: “Corosync dedicado + fencing predecible”

Una organización sanitaria (del tipo que ama el papeleo más que al oxígeno) ejecutaba Proxmox para cargas no clínicas. Su líder SRE insistió en dos hábitos: (1) corosync en su propia red físicamente separada y (2) fencing con watchdog configurado y probado trimestralmente. El equipo se quejaba porque parecía proceso por proceso.

Durante un evento de corte de energía, un nodo volvió en mal estado: el OS estaba arriba, pero el driver de la NIC estaba bloqueado y perdía paquetes. Desde fuera parecía lo bastante vivo como para confundir a humanos. La membresía de corosync fue inestable. Sin fencing, aquí es donde los clústeres mueren lentamente—porque todos debaten si un nodo está “realmente” abajo.

El watchdog hizo su trabajo. El nodo enfermo fue fenced limpiamente, el quórum se estabilizó y HA arrancó cargas en los nodos restantes. Los usuarios vieron una breve interrupción, no un día de “lentitud intermitente” que se convierte en festival de culpas.

Después, la revisión fue casi aburrida. El runbook coincidió con la realidad, el dominio de fallo fue claro y la solución se centró: reemplazar la NIC, actualizar firmware, re-probar. Sin misterio. Sin folklore.

Las prácticas aburridas no son glamorosas. También son la razón por la que puedes dormir.

Hechos interesantes y contexto histórico

Hecho 1: La configuración del clúster de Proxmox vive en pmxcfs, un sistema de archivos FUSE montado en /etc/pve, no en archivos locales “normales”.
Hecho 2: El transporte moderno de corosync en Proxmox suele usar knet, diseñado para manejar redundancia multi-enlace y mejor comportamiento de red que enfoques antiguos.
Hecho 3: El concepto de quórum es anterior a la virtualización moderna; proviene de problemas de coordinación en sistemas distribuidos donde el acuerdo mayoritario evita el split-brain.
Hecho 4: Las pilas HA suelen separar “decidir” y “hacer” (manager vs agente local). Proxmox sigue ese patrón con manager y LRM por seguridad y claridad.
Hecho 5: Fencing no es invención de Proxmox; es un principio de clúster de larga data: si no puedes probar que un nodo está muerto, asume que está vivo y es peligroso.
Hecho 6: Los clústeres de dos nodos son históricamente complicados entre proveedores porque cualquier fallo simple elimina la mayoría; desempates (qdevice, witness) son la solución estándar.
Hecho 7: Los sistemas de archivos de clúster y mecanismos de consenso suelen degradar a modo “fail-safe” pasando a solo lectura o negando bloqueos cuando se pierde quórum—esto es un diseño deliberado de seguridad.
Hecho 8: Muchos “fallos HA” son en realidad problemas de semántica de almacenamiento—el almacenamiento compartido no es solo “montado”, debe ser consistente, performant y configurado idénticamente entre nodos.

Preguntas frecuentes

1) ¿“failed to start pve-ha-lrm” siempre significa que corosync está roto?

No. Corosync/quórum es la causa más común, pero LRM también puede fallar por problemas con /etc/pve, desajustes de identidad, problemas de watchdog/fencing, o corrupción/sobrecarga local del nodo. Empieza por el quórum porque es una puerta dura.

2) Si se pierde el quórum, ¿puedo forzar que HA arranque de todos modos?

Puedes intentarlo, pero estás pidiendo a HA que opere sin una realidad consistente. Así se provoca split-brain y corrupción de almacenamiento. El movimiento correcto es restaurar el quórum o desactivar HA deliberadamente y gestionar las cargas manualmente hasta que el clúster sea seguro.

3) ¿Por qué importa pmxcfs para pve-ha-lrm?

HA usa configuración y bloqueos a nivel de clúster almacenados bajo /etc/pve. Si pmxcfs no está montado o está en solo lectura por falta de quórum, HA no puede coordinar estado y se negará a ejecutarse.

4) ¿Cuál es la diferencia entre pve-ha-manager fallando y pve-ha-lrm fallando?

pve-ha-manager es el coordinador; si está caído a nivel de clúster, las decisiones HA no ocurrirán. pve-ha-lrm es por nodo; si está caído en un nodo, ese nodo no puede ejecutar acciones HA aunque el clúster esté bien.

5) ¿Un único nodo defectuoso puede impedir que HA funcione en otros nodos?

Sí, si ese nodo provoca pérdida de quórum o inestabilidad de membresía. Si el quórum permanece intacto, los demás nodos suelen poder continuar. La clave es si el clúster puede formar una partición mayoritaria estable.

6) Mi clúster tiene dos nodos. ¿Es eso “HA real”?

Puedes lograrlo, pero solo si añades un voto de desempate (qdevice/witness). Sin ello, la pérdida de cualquiera de los nodos (o una partición de red) típicamente mata el quórum y HA se negará a actuar, correctamente.

7) HA está arriba, pero las VMs no hacen failover. ¿Sigue siendo un problema de LRM?

A veces. Puede que LRM esté ejecutándose pero falle en acciones de recursos debido a que el almacenamiento no esté disponible en el nodo destino, restricciones de migración o configuración de recursos. Revisa ha-manager status, estado de almacenamiento y logs por VM.

8) ¿Cuál es el indicador más rápido para dejar de tocar HA y arreglar el clúster?

Si ves cfs-lock ... no quorum o Quorate: No. HA está aguas abajo. Arregla quórum y corosync primero.

9) ¿Realmente puede el drift de tiempo causar problemas de arranque de HA?

Sí. Saltos de tiempo y sincronización inestable pueden correlacionarse con problemas de membresía de corosync y comportamiento extraño de bloqueos. No es el sospechoso principal, pero es un contribuyente real en entornos desordenados.

10) Si arreglo el quórum, ¿necesito reiniciar nodos para recuperar HA?

Normalmente no. Una vez que quórum y pmxcfs estén sanos, reiniciar los servicios HA suele ser suficiente. Reiniciar puede ayudar solo si un nodo está atascado (problemas de driver, presión de memoria, errores en el sistema de archivos).

Conclusión: siguientes pasos prácticos

Cuando Proxmox dice failed to start pve-ha-lrm, rara vez es “un bug de HA”. Es HA negándose a operar sin un clúster de confianza. Trata esa negativa como una característica de seguridad, no como un obstáculo.

Haz esto a continuación, en orden:

Confirma quórum y estabilidad de membresía con pvecm status, corosync-cfgtool -s y los logs de corosync.
Verifica la salud de pmxcfs: /etc/pve montado, legible, escribible (cuando hay quórum).
Comprueba identidad y tiempo: hostnames, /etc/hosts y sincronización de tiempo.
Valida supuestos de watchdog/fencing para que HA pueda tomar decisiones seguras en fallos parciales.
Sólo entonces reinicia los servicios HA y verifica con ha-manager status.

Si sigues ese flujo, arreglarás la causa raíz en lugar de discutir con un daemon que hace exactamente lo que se diseñó para hacer: negarse a adivinar.