Qué significa realmente “no se puede iniciar el recurso” en términos de HA

En Proxmox HA, un “recurso” suele ser una VM o un contenedor que la pila HA (CRM + LRM + manager) se encarga de ubicar, iniciar, detener y trasladar. Cuando ves “no se puede iniciar el recurso”, normalmente significa:

• El manager HA intentó una acción (iniciar/migrar/recuperar) y el nodo objetivo se negó o no pudo cumplir.
• O el manager HA se negó a actuar porque creyó que hacerlo podría crear un split-brain, un doble montaje o un doble arranque.

Ese segundo caso es por lo que este error es tan molesto y tan correcto. HA es conservador por diseño. Prefiere mantener tu servicio caído a corromper tus datos en silencio. Eso no es un fallo; es toda la descripción del trabajo.

Una cita que vale la pena recordar, porque resume la postura de los sistemas HA:

“La esperanza no es una estrategia.” — General Gordon R. Sullivan

HA no funciona con esperanza. Funciona con estado claro y alcanzabilidad verificada. Si eso no está claro, se detiene.

Guion rápido de diagnóstico (primero/segundo/tercero)

Esto es lo que haces cuando un ejecutivo te observa, la VM está caída y la interfaz HA te encoge de hombros.

Primero: confirma que el clúster puede tomar decisiones (quórum + membresía)

• Comprueba el quórum (pvecm status). Sin quórum no hay “quién posee qué” fiable.
• Comprueba la membresía de corosync (corosync-cfgtool -s, corosync-quorumtool -s). Busca nodos ausentes, problemas en el anillo o “partitioned”.
• Comprueba que pmxcfs esté montado y sano (df -h /etc/pve).

Decisión: Si falta quórum, deja de perseguir el almacenamiento. Arregla quórum/membresía primero. Cualquier otro “arreglo” corre el riesgo de empeorar las cosas.

Segundo: confirma que el estado del manager HA no está mintiendo (estado CRM/LRM)

• ha-manager status para el recurso y en qué nodo cree que debe ejecutarse.
• En cada nodo: systemctl status pve-ha-lrm pve-ha-crm.
• Sigue los logs: journalctl -u pve-ha-crm -u pve-ha-lrm -n 200 --no-pager.

Decisión: Si los servicios HA están enfermos o atascados en un nodo, arréglalo antes de iniciar VMs manualmente. Ganar una pelea con HA no es un deporte donde siempre salgas victorioso.

Tercero: verifica que el almacenamiento requerido esté realmente disponible en el nodo objetivo

• Comprueba el estado de almacenamiento de Proxmox (pvesm status) y confirma que los discos de la VM están en un almacenamiento presente en el nodo.
• Para almacenamiento compartido: comprueba el montaje/conexión (NFS/iSCSI/Ceph/objetivos de replicación ZFS).
• Busca bloqueos (qm config incluye lock:), y revisa el historial de tareas.

Decisión: Si el almacenamiento no está disponible donde HA lo espera, la solución correcta es restaurar la alcanzabilidad del almacenamiento o ajustar las restricciones de colocación HA—no “forzar inicio” y rezar.

Todo lo demás—presión de CPU, memoria, logs del kernel, expectativas de fencing—viene después de estos tres. Puedes ser ingenioso luego. Sé correcto primero.

Modelo mental: quórum, membresía, manager y la realidad del almacenamiento

Quórum no es “el clúster está arriba.” Es “el clúster puede ponerse de acuerdo.”

El quórum es el mecanismo que previene el split-brain: dos mitades del clúster pensando ambas que son el clúster real. Sin quórum, Proxmox restringe deliberadamente las escrituras al filesystem del clúster y bloquea ciertas acciones. Las acciones HA son de las primeras en ser rechazadas, porque HA sin consenso es cómo se obtienen VMs iniciadas doblemente y corrupción de discos.

Corosync es el sistema nervioso; la latencia es veneno

Corosync es una capa de mensajería y membresía. No quiere solo paquetes; quiere paquetes puntuales. Puedes “hacer ping” entre nodos y aun así tener corosync inestable por pérdidas, reordenamientos o desajuste de MTU. HA depende de que la membresía de corosync sea estable. Si la membresía fluctúa, HA sigue cambiando de opinión—porque tiene que hacerlo.

pmxcfs es tu cerebro compartido

/etc/pve está respaldado por pmxcfs (sistema de archivos del clúster Proxmox). No es un filesystem compartido genérico; es una base de datos de clúster expuesta como filesystem. Si no está montado o no es escribible por pérdida de quórum, las configuraciones pueden parecer “obsoletas”, HA no puede coordinar de forma fiable y obtendrás errores que parecen problemas de VM pero que en realidad son “la metadata del clúster no es consistente”.

El almacenamiento es el bloqueo real más común, porque ahí es donde están los datos

HA puede iniciar una VM en un nodo solo si los discos son accesibles y seguros. “Seguro” significa: el backend de almacenamiento está presente, los discos de la VM no están montados en otro sitio y cualquier bloqueo (snapshot de migración, backup) está resuelto. Muchos backends pueden estar “arriba” pero aún inseguros: un montaje NFS obsoleto, una sesión iSCSI que existe pero tiene timeouts, un clúster Ceph en modo degradado con I/O bloqueado o ZFS vivo pero con latencia extrema.

Broma #1: Alta disponibilidad es como un simulacro de incendio: a todo el mundo le encanta hasta que realmente tiras de la alarma.

Datos interesantes y contexto (por qué existen los bordes afilados)

• Dato 1: El quórum como concepto precede a la mayoría de las pilas de virtualización; es un control clásico en sistemas distribuidos para prevenir el “split brain” en almacenamiento en clúster y bases de datos.
• Dato 2: Corosync evolucionó desde los primeros esfuerzos de mensajería en clústeres Linux, donde la membresía estable se consideraba la piedra angular del failover seguro.
• Dato 3: pmxcfs en Proxmox se comporta deliberadamente distinto bajo condiciones de no quórum: prioriza la seguridad sobre la conveniencia, por eso las escrituras pueden bloquearse incluso cuando los nodos “parecen bien”.
• Dato 4: Las pilas HA suelen separar “toma de decisiones” (cluster resource manager) de “ejecución” (local resource manager). Proxmox sigue ese patrón con componentes CRM y LRM.
• Dato 5: El fencing de almacenamiento (asegurar que un nodo fallado no pueda seguir escribiendo en almacenamiento compartido) es anterior a los hipervisores modernos; vino de filesystems en clúster y entornos SAN donde un escritor descontrolado podía corromperlo todo.
• Dato 6: Los protocolos de tipo “heartbeat” históricamente sufrían falsos positivos durante congestión; las pilas modernas todavía enfrentan la misma física: pérdidas y jitter parecen muerte de nodo.
• Dato 7: Los enfoques shared-nothing (como ZFS local + replicación) reducen modos de fallo de almacenamiento compartido pero introducen el problema de “qué copia es la autorizada”—sigue siendo un problema de quórum, solo que con otro disfraz.
• Dato 8: Muchos incidentes HA no son causados por una falla completa, sino por una falla parcial: el nodo está arriba, el enlace es inestable, el almacenamiento está medio vivo. HA odia las fallas parciales porque son ambiguas.
• Dato 9: “No se puede iniciar el recurso” suele ser un mensaje de seguridad intencionado. Es la pila HA diciéndote que no puede demostrar que iniciar sea seguro, no que lo intentó y falló como un inicio manual normal.

Tareas prácticas: comandos, salida esperada y decisiones (12+)

Estas son las comprobaciones que ejecuto cuando estoy de guardia y quiero la verdad rápido. Cada tarea incluye qué significa la salida y qué hacer a continuación.

Tarea 1: Comprobar quórum del clúster y votos esperados

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

Qué significa: Quorate: Yes significa que el clúster puede tomar decisiones autoritativas y pmxcfs debería ser escribible. Si dice No, las acciones HA a menudo estarán bloqueadas.

Decisión: Si no hay quórum, detente aquí y arregla la conectividad de corosync o la configuración de votos. No fuerces inicios de recursos HA.

Tarea 2: Comprobar el estado del ring de corosync (¿están sanos los enlaces?)

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

Qué significa: “active with no faults” es lo que quieres. Los fallos aquí se correlacionan fuertemente con HA rechazando acciones o recursos “flapeando”.

Decisión: Si un ring tiene fallos, arregla red/MTU/vLAN/jumbo frames antes de tocar HA. Las misconfiguraciones de doble ring son una trampa clásica que “parece redundante pero es frágil”.

Tarea 3: Comprobar detalles de quórum de corosync (pistas de partición)

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

Qué significa: Confirma que el subsistema de quórum ve la misma realidad que pvecm. Si difieren, ya estás en territorio extraño.

Decisión: Si no hay quórum: trátalo como un incidente de clúster, no como un incidente de VM.

Tarea 4: Verificar que pmxcfs esté montado (y no en un estado triste)

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

Qué significa: Parece raro porque no es un filesystem normal. Si ves “not mounted” o apunta a otra cosa, la distribución de configuración del clúster está rota.

Decisión: Si /etc/pve no es pmxcfs, arregla los servicios del clúster. HA no se comportará de forma predecible.

Tarea 5: Comprobar la visión del mundo del manager HA

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)

Qué significa: Obtienes el master HA, el estado del quórum y dónde HA cree que debe manejar cada recurso. Si tu VM rota está “stopped” pero debería estar en ejecución, céntrate en por qué no puede situarla.

Decisión: Si el master está flapeando entre nodos, probablemente tengas inestabilidad en corosync. Arregla eso antes de cualquier otra cosa.

Tarea 6: Profundizar en el estado de un único recurso y acciones recientes

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

Qué significa: Esta es la línea que importa. HA a menudo te dice el bloqueo real en last_error. No lo ignores porque no esté en la GUI.

Decisión: Si last_error apunta al almacenamiento, pivota a las comprobaciones de almacenamiento en ese nodo ahora.

Tarea 7: Comprobar salud de los servicios HA (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

Qué significa: Si alguno no está en ejecución, la orquestación HA está comprometida. LRM son las “manos” en cada nodo; CRM es el “cerebro coordinador”.

Decisión: Si uno falla, lee los logs y arregla la estabilidad del servicio antes de intentar iniciar VMs manualmente.

Tarea 8: Leer los logs HA como si te fuera la vida en ello

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)

Qué significa: Obtienes la línea temporal. Si el log dice “storage not available”, deja de debatir. Es almacenamiento.

Decisión: Sigue el error en el nodo donde falló el LRM. Ahí está la dependencia faltante.

Tarea 9: Confirmar el estado de almacenamiento según Proxmox

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

Qué significa: inactive significa que Proxmox no lo usará. HA no iniciará una VM cuyos discos vivan allí. Esto no es negociable.

Decisión: Arregla la conectividad Ceph/RBD en ese nodo, o mueve/recupera discos a otro almacenamiento disponible, o cambia las restricciones de colocación HA.

Tarea 10: Verificar los discos de la VM y dónde residen

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

Qué significa: El disco está en ceph-vm. Si pvesm status indica que ese almacenamiento está inactivo en el nodo objetivo, has encontrado el bloqueo.

Decisión: No intentes “iniciar de todos modos”. Activa el almacenamiento o migra los discos a un backend disponible.

Tarea 11: Buscar bloqueos que impidan el inicio

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

Qué significa: Un bloqueo puede impedir iniciar/migrar. Un bloqueo backup suele quedar tras un trabajo de backup interrumpido o un fallo de almacenamiento.

Decisión: Confirma si aún hay un backup en ejecución; si el bloqueo es obsoleto, elimínalo con precaución (tras verificar que no hay tarea activa).

Tarea 12: Inspeccionar tareas recientes por fallos que dejaron estado

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:

Qué significa: Obtienes migas de pan de lo ocurrido. Usa el UPID para sacar detalles.

Decisión: Si ves intentos repetidos de arranque o recuperación fallida, trátalo como algo sistémico (almacenamiento/red), no como “intenta otra vez”.

Tarea 13: Extraer el log real de un UPID

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

Qué significa: Si los backups fallan por almacenamiento, el inicio HA puede fallar por la misma causa. Además, imágenes RBD faltantes apuntan a una inconsistencia de almacenamiento más profunda.

Decisión: Para y valida la integridad y el nombre del almacenamiento. No “borres bloqueos” hasta saber qué desapareció.

Tarea 14: Validar salud rápida de la red de clúster (pérdidas, errores)

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

Qué significa: Las pérdidas en la red corosync (o en el bond compartido) son una señal inequívoca. Corosync tolera algo de pérdida, pero la estabilidad HA requiere redes aburridas y estables.

Decisión: Si las pérdidas suben durante incidentes, investiga buffers de switch, desajuste de MTU, hashing LACP o enlace saturado.

Tarea 15: Comprobar sincronización de tiempo (sí, importa más de lo que quieres)

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

Qué significa: Si los relojes se desincronizan, los logs mienten y depurar se vuelve una danza interpretativa. Algunos comportamientos de autenticación y de clúster también se vuelven inestables con deriva de tiempo.

Decisión: Si no están sincronizados, arregla NTP/chrony en todos los nodos antes de perseguir comportamiento “aleatorio” de HA.

Tarea 16: Confirmar que la VM no esté realmente ejecutándose en otro lado

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

Qué significa: Proxmox dice que está detenida en este nodo. Repite en otros nodos si sospechas split-brain o estado obsoleto.

Decisión: Si la encuentras ejecutándose en otro nodo, no “inicies una segunda copia”. Investiga inmediatamente la colocación HA y los bloqueos.

Encontrar el bloqueo real: quórum vs almacenamiento vs red vs estado

1) Pérdida de quórum: el silencioso “parar todo”

Cuando se pierde el quórum, gran parte del sistema aún parece operativo. Los nodos arrancan. Puedes hacer SSH. Incluso puedes acceder a almacenamiento local. La UI puede renderizar. Y aun así HA se negará a hacer lo que quieres, porque no puede demostrar que es seguro.

Signos típicos:

• pvecm status muestra Quorate: No.
• /etc/pve es de solo lectura o no se actualiza entre nodos.
• El master HA cambia, o HA informa “quorum not OK”.

Qué hacer: Restaura la conectividad entre la mayoría de los nodos. Si tienes un clúster de dos nodos sin un dispositivo de voto tercero adecuado, estás viviendo al límite por diseño. Añade un dispositivo de quórum o un tercer nodo si quieres un comportamiento HA que no parezca arte performativo.

2) Partición de red: el clúster no puede ponerse de acuerdo porque no puede hablar

Las particiones son peores que los apagones. Un apagón es honesto; una partición es mentirosa. Con una partición, ambos lados pueden estar vivos. Ambos lados pueden pensar que el otro está muerto. Ahí nace la corrupción de datos.

Signos típicos:

• Fallos en el ring de corosync en uno o más nodos.
• Cambios intermitentes de membresía en journalctl -u corosync.
• Pérdidas de paquetes, desajuste de MTU o una regla de firewall “útil” añadida por alguien que odia los fines de semana.

Qué hacer: Estabiliza la red corosync: VLAN dedicada, MTU consistente de extremo a extremo, sin enrutamiento asimétrico, sin filtrado y latencia predecible. HA quiere redes aburridas. Dáselas.

3) Almacenamiento no disponible: el bloqueo que HA tiene razón en imponer

Los problemas de almacenamiento producen el “no se puede iniciar el recurso” más común, porque son frecuentes y peligrosos. HA se negará a iniciar si no puede acceder a los discos de la VM de forma segura. “Seguro” incluye “no ya en uso en otro sitio”.

Signos típicos:

• pvesm status muestra almacenamiento inactive en el nodo objetivo.
• Errores Ceph/RBD en logs, timeouts de sesión iSCSI o “stale file handle” en NFS.
• La configuración de la VM apunta a almacenamiento no presente en todos los nodos del grupo HA.

Qué hacer: Haz que el almacenamiento esté disponible de forma uniforme en todos los nodos que puedan ejecutar el recurso, o restringe el recurso a nodos que tengan el almacenamiento. La colocación HA sin simetría de almacenamiento es solo caos con pasos extra.

4) Bloqueos y estado obsoleto: HA espera una condición que nunca se limpia

A veces el clúster está sano y el almacenamiento bien, pero el recurso está “bloqueado” o HA cree que está en transición. Esto puede ocurrir tras migraciones interrumpidas, backups o un crash de nodo a mitad de operación.

Signos típicos:

• qm config muestra valores lock: como backup, migrate, snapshot.
• Las tareas muestran operaciones que nunca se completaron.
• El estado HA muestra reintentos repetidos con códigos de salida de error pero sin progreso.

Qué hacer: Confirma que la operación no siga en ejecución. Luego limpia los bloqueos obsoletos con cuidado. Si limpias bloqueos mientras el proceso subyacente sigue activo, puedes crear exactamente el tipo de condición de doble escritura que HA existe para evitar.

Broma #2: Lo único peor que un manager HA atascado son dos “managers destapados”, ambos convencidos de que son el héroe.

Tres microhistorias corporativas reales

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

1) Síntoma: HA dice “no se puede iniciar el recurso” justo después de reiniciar un nodo

Causa raíz: Quórum temporalmente perdido o membresía corosync inestable durante el reinicio; HA se niega a actuar de forma segura.

Solución: Verifica pvecm status está quorate y que los anillos corosync están sanos. No persigas logs de la VM hasta que el clúster acuerde la membresía.

2) Síntoma: La VM inicia manualmente con qm start, pero HA no la inicia

Causa raíz: Restricciones HA o la máquina de estado HA piensa que la VM pertenece a otro nodo, o hay un fallo previo registrado; HA aplica la política, no la capacidad.

Solución: Revisa ha-manager status vm:ID y los grupos HA. Alinea acciones manuales con HA: desactiva HA para esa VM temporalmente o arregla el problema de colocación subyacente.

3) Síntoma: El almacenamiento muestra “active” en un nodo y “inactive” en otro

Causa raíz: La conectividad al backend es específica por nodo: rutas faltantes, multipath caído, problemas de auth Ceph, montaje NFS obsoleto o reglas de firewall.

Solución: Arregla la conectividad de almacenamiento en el nodo roto, o elimina ese nodo del grupo HA para recursos en ese almacenamiento. HA requiere simetría o restricciones explícitas.

4) Síntoma: “no se puede iniciar el recurso” después de una ventana de backups

Causa raíz: Bloqueo obsoleto dejado por un backup interrumpido, problemas con modo snapshot o fallo de almacenamiento durante el backup.

Solución: Confirma que no hay ningún job de backup corriendo, inspecciona los logs de tareas y luego limpia bloqueos si son obsoletos. Si los backups se interrumpen con frecuencia, arregla la red/almacenamiento que lo provoca.

5) Síntoma: HA sigue moviendo una VM de un lado a otro (“ping-pong”)

Causa raíz: Flapeo de membresía corosync, comprobaciones de salud de nodo fallando intermitentemente o timeouts de inicio de recurso demasiado agresivos.

Solución: Estabiliza la red corosync, revierte ajustes de timeouts agresivos y verifica restricciones a nivel de nodo (CPU, memoria, latencia de almacenamiento).

6) Síntoma: La UI muestra el nodo en línea, pero HA dice que está offline

Causa raíz: La red de gestión está arriba, la red corosync no (o viceversa). La UI puede engañarte porque no es el oráculo de membresía.

Solución: Confía en las herramientas corosync (corosync-cfgtool, corosync-quorumtool) y arregla el path corosync.

7) Síntoma: “el almacenamiento no está disponible” pero Ceph/NFS “parece bien” desde un nodo

Causa raíz: Falla parcial: el backend es alcanzable pero demasiado lento, bloqueado o con timeouts; Proxmox lo marca inactivo por comprobaciones fallidas.

Solución: Comprueba la salud del backend desde el nodo que falla específicamente. Para Ceph: verifica auth de cliente y alcance de monitores. Para NFS: busca montajes obsoletos y logs del kernel.

8) Síntoma: HA se niega a recuperar tras un crash; recurso atascado en “error”

Causa raíz: HA registró un fallo y evita bucles; o el LRM en el nodo objetivo no funciona; o el recurso aún “pertenece” a algún sitio por bloqueo/estado.

Solución: Lee logs CRM/LRM, verifica servicios LRM, comprueba bloqueos y considera una limpieza controlada con ha-manager solo después de arreglar la causa subyacente.

Listas de verificación / plan paso a paso

Lista de emergencia: poner un recurso en ejecución de forma segura

1. Confirma quórum: pvecm status debe ser quorate. Si no, restaura la conectividad de la mayoría primero.
2. Confirma estabilidad de membresía: corosync-cfgtool -s debe mostrar anillos activos sin fallos.
3. Confirma salud de /etc/pve: df -h /etc/pve muestra pmxcfs.
4. Lee el error de HA: ha-manager status vm:ID y revisa last_error.
5. Comprueba el almacenamiento requerido en el nodo objetivo: pvesm status y valida el almacenamiento de disco de la VM desde qm config ID.
6. Comprueba bloqueos: qm config ID | grep '^lock:'.
7. Inspecciona historial de tareas: lee logs de tareas de la VM y últimas operaciones.
8. Sólo entonces: intenta recuperación vía HA (preferido) o inicio manual controlado con HA deshabilitado (solo si comprendes las consecuencias).

Lista de estabilidad: prevenir que “no se puede iniciar el recurso” regrese

1. Haz la red corosync aburrida: VLAN dedicada, MTU consistente, sin firewall, monitoriza pérdidas y latencia.
2. Deja de tratar clusters de dos nodos como HA: usa un dispositivo de quórum apropiado o un tercer nodo para decisiones reales.
3. Enforce simetría de almacenamiento: si una VM es gestionada por HA entre nodos, su almacenamiento debe ser accesible desde esos nodos o las restricciones deben reflejar la realidad.
4. Estandariza comprobaciones de salud de almacenamiento por nodo: no aceptes “funciona en nodo A” como evidencia.
5. Mantén la sincronización de tiempo: NTP/chrony consistente en todos los nodos.
6. Escribe las expectativas de fencing: aunque Proxmox HA no haga fencing externo de potencia por ti, tu runbook operativo debe especificar cómo previenes escritores dobles.
7. Practica un simulacro de failover trimestral: no para impresionar—para saber qué aspecto tiene lo “normal raro” en logs.

Guardrail de decisiones (qué evitar bajo presión)

• Evita: borrar bloqueos a ciegas. Haz: confirma que el job subyacente está realmente muerto.
• Evita: reiniciar nodos al azar “para arreglar HA.” Haz: identifica si el problema es quórum, almacenamiento o red primero.
• Evita: cambiar timeouts de corosync a mitad de incidente. Haz: estabiliza la ruta de red; afina después con datos.

Preguntas frecuentes

1) ¿“No se puede iniciar el recurso” siempre significa problemas de quórum?

No. El quórum es común, pero la indisponibilidad del almacenamiento y los bloqueos son igual de habituales. La verdad más rápida está en ha-manager status vm:ID y en los logs LRM del nodo objetivo.

2) La UI muestra todo en verde. ¿Por qué HA aún se niega?

La UI refleja la reachabilidad del plano de gestión y algo del estado del clúster, pero las decisiones HA dependen de la membresía corosync y comprobaciones de almacenamiento. Confía en las herramientas corosync y en los logs HA más que en el optimismo de la UI.

3) ¿Puedo simplemente ejecutar qm start e ignorar HA?

Puedes, pero te haces responsable de la seguridad. Si la pila HA cree que existe riesgo de split brain o doble montaje, el inicio manual puede convertir “tiempo muerto” en “recuperación de datos”. Si debes hacerlo, desactiva HA para ese recurso primero y verifica la exclusividad del almacenamiento.

4) ¿Por qué a HA le importa que el almacenamiento esté “inactive” si el montaje existe?

Porque “montado” no significa “funciona”. NFS puede estar montado y colgado; iSCSI puede estar logueado y timouteando; Ceph puede estar conectado y bloqueado. Proxmox marca el almacenamiento como inactive cuando sus comprobaciones fallan o expiran.

5) ¿Cuál es la diferencia entre CRM y LRM en Proxmox HA?

CRM coordina las decisiones a nivel de clúster (dónde debe ejecutarse un recurso). LRM ejecuta acciones en un nodo (iniciar/detener). “No se puede iniciar el recurso” a menudo significa que CRM pidió la acción, LRM lo intentó y alguna dependencia falló localmente.

6) Si corosync está inestable, ¿por qué mis VMs siguen ejecutándose?

Las VMs pueden seguir ejecutándose en su nodo actual aun cuando el clúster está confuso. Iniciar y mover VMs de forma segura es lo difícil. HA dejará de iniciar acciones si la membresía no es estable.

7) ¿Cómo distinguir rápidamente fallo de almacenamiento de partición de red?

Si se pierde el quórum o los anillos muestran fallos, primero es red/membresía. Si el quórum está bien y HA dice “storage not available”, ejecuta pvesm status en el nodo objetivo y confirma el almacenamiento de la VM. Los problemas de almacenamiento suelen ser específicos de nodo y no aparecen en un par sano.

8) ¿Por qué un clúster de dos nodos se siente tan frágil?

Porque lo es. Con dos nodos, la pérdida de cualquier nodo (o del enlace) crea un empate. Sin un tercer voto (qdevice), no puedes demostrar de manera fiable qué lado es autoritativo. HA se vuelve conservador, como debe ser.

9) ¿Y si sospecho que el estado del manager HA está obsoleto?

Primero confirma quórum y estabilidad corosync. Luego verifica los servicios HA en todos los nodos. Si el manager está atascado, reiniciar servicios HA puede ayudar, pero hazlo de forma deliberada y solo después de confirmar que la dependencia subyacente (almacenamiento/red) está realmente arreglada.

Conclusión: siguientes pasos que realmente previenen repeticiones

“No se puede iniciar el recurso” es Proxmox HA diciéndote que no puede demostrar que la acción es segura. Tu trabajo es eliminar la ambigüedad. Hazlo en este orden: quórum/membresía, estado del manager HA y luego disponibilidad de almacenamiento y bloqueos.

Pasos prácticos siguientes:

1. Elabora un runbook de una página que comience con pvecm status, corosync-cfgtool -s y ha-manager status vm:ID. Hazlo aburrido y obligatorio.
2. Audita recursos HA para simetría de almacenamiento. Si una VM solo puede ejecutarse en dos nodos por realidad de almacenamiento, codifica eso en grupos y restricciones HA.
3. Instrumenta tu red corosync: pérdidas, errores, consistencia de MTU y saturación. Los fallos HA suelen ser fallos de red esperando hacerse obvios.
4. Practica un failover controlado cuando nadie esté en pánico. El mejor momento para aprender el comportamiento HA es cuando no te está humillando activamente.