Proxmox “cluster not ready – no quorum?”: restaurar el quórum sin empeorar

Qué significa realmente el quórum en Proxmox (y por qué te bloquea)

El clustering de Proxmox se basa en Corosync para la membresía y la mensajería, además de pmxcfs (Proxmox Cluster File System)
para replicar la configuración (configuraciones de VM, definiciones de almacenamiento, reglas de firewall, usuarios, etc.) entre nodos. Cuando se pierde el quórum, Proxmox intencionalmente
deja de realizar cambios “a nivel de clúster” porque no puede saber con seguridad si es la única verdad viva.

Piensa en el quórum como la capacidad del clúster para responder con confianza a una pregunta: “¿Somos la vista mayoritaria legítima?”
Sin eso, dos mitades de una partición pueden creer que están a cargo. Eso es split-brain. Split-brain no es un patrón arquitectónico emocionante;
es simplemente corrupción con mejor marketing.

En Proxmox, la pérdida de quórum suele manifestarse como:

• Banner en la UI: “cluster not ready – no quorum?”
• Errores en CLI: pvesh / pveproxy errores, incapacidad para escribir en /etc/pve
• Operaciones de VM bloqueadas: especialmente cargas gestionadas por HA
• Estado extraño del almacenamiento: porque partes de la configuración viven en /etc/pve

Nota la diferencia: tus VMs pueden seguir ejecutándose. Tu almacenamiento puede seguir bien. Tu red puede estar bien.
La pérdida de quórum es principalmente un problema de coordinación del clúster. El peligro es que te tienta a tomar acciones que crean un problema de datos.

Una cita que vale la pena tener en mente durante incidentes de clúster:
“La esperanza no es una estrategia.” — Gene Kranz

Broma #1: El quórum es como una reunión que solo cuenta si suficientes personas aparecen. Por una vez, el clúster es el adulto en la sala.

Guion de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Cuando estás en medio de una interrupción, no necesitas teoría. Necesitas encontrar el cuello de botella rápido, elegir la vía de recuperación menos arriesgada,
y evitar “arreglos” que solo funcionan porque no has notado la segunda falla aún.

Primero: confirma que es realmente el quórum, no un problema de UI o proxy

• Ejecuta pvecm status en el nodo en el que estás.
• Comprueba systemctl status pve-cluster corosync.
• Verifica si /etc/pve está montado y responde.

Segundo: determina la realidad de la membresía (quién está vivo, quién puede hablar)

• Ejecuta pvecm nodes.
• Revisa el estado del anillo de Corosync (corosync-cfgtool -s o corosync-quorumtool -s).
• Desde cada nodo, prueba las interfaces del anillo con ping/arping y valida rutas/VLANs.

Tercero: decide la clase de recuperación

Elige una de estas, en este orden de preferencia:

1. Restaurar nodos o redes faltantes para que el clúster original recupere el quórum naturalmente.
2. Ajustar temporalmente los votos esperados solo para coincidir con la realidad que puedas probar que es segura.
3. Último recurso: forzar un único nodo para que opere el tiempo suficiente para estabilizar (con aceptación explícita del riesgo).
4. Recuperación de desastre: reconstruir el clúster y volver a unir nodos, después de congelar el estado antiguo.

Si no puedes articular en cuál clase de recuperación estás, no estás listo para escribir comandos que cambien el quórum.

Datos y contexto interesantes (por qué es así)

• Hecho 1: “Quórum” en Corosync lo proporciona el servicio votequorum, que decide si la partición tiene suficientes votos para operar.
• Hecho 2: El /etc/pve de Proxmox es un sistema de archivos distribuido (pmxcfs) almacenado en RAM y sincronizado vía Corosync; no es un directorio normal.
• Hecho 3: El mecanismo de “votos esperados” existe porque los clústeres cambian de tamaño; también puede ser abusado para “convencer” a una partición de que tiene quórum.
• Hecho 4: Los clústeres de dos nodos son inherentemente incómodos para el quórum: sin un tercer voto, una partición no puede distinguir “el par está caído” de “el enlace está caído”.
• Hecho 5: La idea del quórum y la votación mayoritaria viene de hace décadas en sistemas distribuidos, y es un compromiso práctico: seguridad sobre disponibilidad durante particiones.
• Hecho 6: Corosync usa IDs de anillo y transiciones de membresía; cambios frecuentes de anillo suelen significar pérdida de paquetes, desajuste de MTU o enlaces inestables.
• Hecho 7: HA de Proxmox usa el estado del clúster; si se pierde el quórum, HA generalmente se niega a hacer nada “ingenioso” porque lo “ingenioso” es cómo se inician VMs dos veces.
• Hecho 8: El concepto de qdevice (desempate externo) existe principalmente porque las organizaciones insisten en clústeres de número par y luego se sorprenden cuando actúa la física.

Broma #2: Un clúster de dos nodos sin desempate es como dos gerentes discutiendo en Slack. El único ganador es el canal de incidentes.

Reglas de seguridad: haz esto antes de tocar nada

1) Decide qué estás protegiendo: integridad de VM, del almacenamiento o solo la UI

Si el almacenamiento es compartido (Ceph, SAN, NFS, iSCSI), el mayor riesgo es que dos nodos crean que poseen el mismo recurso escribible.
Si el almacenamiento es local (ZFS por nodo), el riesgo se desplaza hacia la deriva de la configuración y operaciones HA fallidas más que a la corrupción directa de bloques.

2) Congela la automatización

Si ejecutas alguna automatización externa que cambia la configuración de Proxmox (Terraform, Ansible, scripts que llaman a la API), deténla.
Los incidentes de quórum son donde la idempotencia va a morir porque el clúster no acepta escrituras de forma consistente.

3) No “arregles” reiniciando todo

Reiniciar a veces puede limpiar un estado atascado, pero también puede destruir la evidencia que necesitabas: logs, transiciones de anillo o el único nodo que aún tenía la configuración correcta.
Trata los reinicios como intervenciones controladas, no como terapia.

4) Si hay almacenamiento compartido, establece hechos de fencing

Si tienes LUNs compartidos o exportaciones NFS montadas en modo lectura-escritura por varios nodos, necesitas saber si existe algún mecanismo de fencing:
control de energía IPMI, reservaciones SCSI a nivel SAN, reglas de Ceph OSD, etc. Si la respuesta es “eh”, no fuerces el quórum a la ligera.

Tareas prácticas con comandos: leer, decidir, actuar

A continuación hay tareas reales que puedes ejecutar en un nodo Proxmox. Cada una incluye: comando, ejemplo de salida, qué significa y la decisión que tomas.
Úsalas como una guía de investigación, no como una lista de encantamientos mágicos.

Task 1: Confirmar estado de quórum y votos esperados

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

Quorum information
------------------
Date:             2025-12-25 10:14:18
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          No

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

Significado: Esta partición tiene 1 voto pero espera 3; el quórum requiere 2. No tienes quórum.

Decisión: No toques HA ni la configuración a nivel de clúster. A continuación, averigua dónde fueron los otros dos votos: nodos caídos o partición de red.

Task 2: Ver qué nodos cree que existen el clúster

cr0x@pve1:~$ pvecm nodes
Membership information
----------------------
Nodeid      Votes Name
0x00000001      1 pve1
0x00000002      1 pve2
0x00000003      1 pve3

Significado: La configuración del clúster espera tres nodos con un voto cada uno.

Decisión: Si pve2/pve3 están desmantelados intencionalmente, necesitas un cambio de membresía controlado. Si deben estar activos, arregla primero su alcanzabilidad.

Task 3: Comprobar salud del servicio corosync en el nodo local

cr0x@pve1:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Thu 2025-12-25 10:01:03 UTC; 13min ago
       Docs: man:corosync
   Main PID: 1189 (corosync)
      Tasks: 10
     Memory: 45.2M
        CPU: 7.412s

Significado: Corosync está en ejecución. Esto no es “servicio muerto”; es “el servicio no ve suficientes pares”.

Decisión: Céntrate en la salud de la red/anillo/pares, no en reiniciar a ciegas.

Task 4: Comprobar preparación de pve-cluster y pmxcfs

cr0x@pve1:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Thu 2025-12-25 10:01:10 UTC; 13min ago
   Main PID: 1260 (pmxcfs)
      Tasks: 12
     Memory: 78.0M
        CPU: 3.201s

Significado: pmxcfs está en ejecución, pero puede estar en un modo más bien de solo lectura para escrituras de clúster debido a la falta de quórum.

Decisión: Valida si /etc/pve es accesible y si las escrituras están bloqueadas.

Task 5: Confirmar que /etc/pve está montado (y no atascado)

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

Significado: pmxcfs está montado. Eso es bueno.

Decisión: Si falta, tienes un problema local mayor en el nodo (pmxcfs no montado), no solo pérdida de quórum.

Task 6: Comprobar si el sistema de archivos del clúster es escribible (prácticamente)

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

Significado: Con no quórum, pmxcfs rechaza escrituras (comportamiento común).

Decisión: Deja de intentar “editar para salir”. Restaura el quórum primero, o usa un procedimiento de recuperación de un solo nodo controlado si esa es la vía elegida.

Task 7: Ver estado del anillo de Corosync (señal a nivel de enlace)

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

Significado: pve1 está conectado consigo mismo pero no puede alcanzar pve2/pve3 en la red del anillo.

Decisión: Confirma la alcanzabilidad de la red del anillo (IP, VLAN, MTU, firewall) antes de tocar los votos.

Task 8: Comprobar pérdida de paquetes y desajuste de MTU en el anillo

cr0x@pve1:~$ ping -c 5 -M do -s 8972 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500

--- 10.10.10.12 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4087ms

Significado: Intentaste un ping jumbo y descubriste MTU 1500 en la ruta del emisor. Si esperabas jumbo frames, has encontrado una causa real.

Decisión: Alinea MTU de extremo a extremo en la red corosync (puertos del switch, bonds, interfaces VLAN). A Corosync no le gustan las fragmentaciones misteriosas.

Task 9: Validar la alcanzabilidad básica a pares (no te saltes lo aburrido)

cr0x@pve1:~$ ping -c 3 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.602 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.581 ms
64 bytes from 10.10.10.12: icmp_seq=3 ttl=64 time=0.594 ms

--- 10.10.10.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2041ms
rtt min/avg/max/mdev = 0.581/0.592/0.602/0.009 ms

Significado: Existe conectividad IP, al menos para ICMP. Eso es necesario pero no suficiente.

Decisión: Si ICMP funciona pero Corosync aún muestra desconectado, sospecha filtrado UDP, enrutamiento asimétrico o bindnetaddr incorrecto.

Task 10: Revisar logs de Corosync por cambios de membresía y timeouts de token

cr0x@pve1:~$ journalctl -u corosync -n 50 --no-pager
Dec 25 10:12:02 pve1 corosync[1189]:   [KNET  ] host: 2 (passive) link: 0 is down
Dec 25 10:12:03 pve1 corosync[1189]:   [TOTEM ] A processor failed, forming new configuration.
Dec 25 10:12:04 pve1 corosync[1189]:   [QUORUM] Members[1]: 1
Dec 25 10:12:04 pve1 corosync[1189]:   [QUORUM] This node is within the non-primary component and will NOT provide service.

Significado: Enlace KNET caído hacia host 2, y el subsistema de quórum se niega a dar servicio. Esto es la evidencia decisiva de “red o nodo remoto caído”.

Decisión: Arregla la ruta física/virtual de red o vuelve a poner el nodo remoto en línea, luego espera a que la membresía se estabilice.

Task 11: Inspeccionar la configuración de Corosync (bindnetaddr y lista de nodos)

cr0x@pve1:~$ cat /etc/pve/corosync.conf
totem {
  version: 2
  cluster_name: prod-cluster
  transport: knet
  interface {
    linknumber: 0
    bindnetaddr: 10.10.10.0
    mcastport: 5405
  }
}

nodelist {
  node {
    name: pve1
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.10.10.11
  }
  node {
    name: pve2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.10.10.12
  }
  node {
    name: pve3
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.10.10.13
  }
}

quorum {
  provider: corosync_votequorum
}

Significado: Corosync espera la red del anillo en 10.10.10.0/24. Si los nodos se movieron de subred, cambiaron IPs o etiquetas VLAN, la membresía fallará.

Decisión: Si las IP cambiaron, arréglalas o actualiza corosync.conf usando un nodo quórum (o un método de recuperación controlado). No edites a mano mientras pmxcfs esté inestable.

Task 12: Determinar si los nodos faltantes están realmente caídos

cr0x@pve1:~$ ssh root@10.10.10.12 "uptime && systemctl is-active corosync && pvecm status | sed -n '1,20p'"
 10:15:41 up 12 days,  3:22,  2 users,  load average: 0.22, 0.18, 0.15
active
Cluster information
-------------------
Name:             prod-cluster
Config Version:   12
Transport:        knet
Secure auth:      on

Significado: pve2 está arriba y corosync está activo. Entonces, ¿por qué pve1 está desconectado? Probablemente partición de red, firewall o enrutamiento asimétrico.

Decisión: Ejecuta las mismas comprobaciones del anillo desde pve2. Quieres evidencia simétrica (pve2 también no puede ver a pve1, o ve algo diferente).

Task 13: Confirmar alcanzabilidad de puertos UDP (tráfico de Corosync) vía tcpdump

cr0x@pve1:~$ tcpdump -ni vmbr1 udp port 5405 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:16:02.112233 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256
10:16:03.113244 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256
10:16:04.114255 IP 10.10.10.11.5405 > 10.10.10.12.5405: UDP, length 256

Significado: Los paquetes salientes están saliendo. Si no ves respuestas entrantes, el problema está entre los nodos (ACL, switch, enrutamiento o firewall del par).

Decisión: Captura en pve2 simultáneamente. Si pve2 ve entradas pero las respuestas desaparecen, sospecha enrutamiento asimétrico o filtrado aguas arriba.

Task 14: Comprobar estado del firewall del host (el firewall de PVE puede morder)

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

Significado: El firewall está activo. Eso no es malo; es solo una variable.

Decisión: Verifica que las reglas permitan Corosync en la interfaz del anillo. Si recientemente endureciste reglas de firewall, este es un sospechoso principal.

Task 15: Confirmar que la comunicación del clúster no esté bloqueada por deriva horaria

cr0x@pve1:~$ timedatectl
               Local time: Thu 2025-12-25 10:16:55 UTC
           Universal time: Thu 2025-12-25 10:16:55 UTC
                 RTC time: Thu 2025-12-25 10:16:55
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: La sincronización de tiempo está saludable en este nodo. Corosync no valida la TLS de tus paquetes por tiempo, pero la deriva horaria se correlaciona con “todo está raro”, incluyendo autenticación y logs.

Decisión: Si un nodo está minutos fuera, arregla NTP antes de confiar en cualquier diagnóstico basado en timestamps.

Task 16: Como acción controlada, establece los votos esperados (temporal) para recuperar quórum

cr0x@pve1:~$ pvecm expected 1
Setting expected votes to 1

Significado: Le has dicho a votequorum que espere solo 1 voto. Eso puede hacer que esta partición obtenga quórum al instante.

Decisión: Haz esto solo si estás seguro de que los otros nodos están caídos o los has fenceado. De lo contrario, corres el riesgo de tener dos particiones quoradas a la vez (esa es la película de horror).

Task 17: Validar el quórum después del cambio

cr0x@pve1:~$ pvecm status | grep -E "Quorate|Expected votes|Total votes|Quorum"
Quorate:          Yes
Expected votes:   1
Total votes:      1
Quorum:           1

Significado: El nodo ahora tiene quórum (según su nueva expectativa).

Decisión: Usa esta ventana para estabilizar la configuración del clúster, pero planea revertir los votos esperados cuando el clúster vuelva a estar completo.

Task 18: Eliminar un nodo muerto limpiamente (cuando el clúster tiene quórum)

cr0x@pve1:~$ pvecm delnode pve3
Removing node pve3 from cluster

Significado: La membresía del clúster se actualiza; los votos esperados y las matemáticas de quórum cambian en consecuencia.

Decisión: Haz esto solo cuando hayas decidido que pve3 se ha ido permanentemente (o será reinstalado y vuelto a unir). No uses delnode como “prueba de ping”.

Task 19: Comprobar salud de pmxcfs después de restaurar el quórum

cr0x@pve1:~$ ls -la /etc/pve/nodes
total 0
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 .
drwxr-xr-x 1 root www-data 0 Dec 25 10:18 ..
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 pve1
drwxr-xr-x 2 root www-data 0 Dec 25 10:18 pve2

Significado: El directorio nodes refleja los miembros actuales del clúster; esto es una comprobación de cordura de que el FS del clúster es coherente.

Decisión: Si los nodos aparecen/desaparecen inesperadamente, para e investiga el flapping de membresía antes de hacer cambios de configuración.

Task 20: Si HA está configurado, comprueba el estado del manager antes de desbloquear operaciones

cr0x@pve1:~$ systemctl status pve-ha-lrm pve-ha-crm --no-pager
● pve-ha-lrm.service - PVE Local Resource Manager Daemon
     Active: active (running)
● pve-ha-crm.service - PVE Cluster Resource Manager Daemon
     Active: active (running)

Significado: Los agentes HA están en ejecución. Eso no significa que sea seguro que actúen todavía; significa que actuarán una vez que el quórum vuelva y el estado converja.

Decisión: Revisa los recursos HA y asegúrate de que no desencadenarás migraciones/arranques inesperados en cuanto el quórum regrese.

Vías de recuperación: elige la opción menos peligrosa

“Restaurar quórum” no es una sola cosa. Es una familia de movimientos con diferentes radios de impacto.
Aquí explico cómo elijo bajo presión.

Ruta A (mejor): restaurar la red y/o traer de vuelta los nodos faltantes

Si los nodos están sanos pero desconectados, arregla la red del anillo de Corosync. Esta es la resolución más limpia porque preserva el historial de membresía y evita hacks especiales de quórum.
Culpables típicos: etiqueta VLAN errónea, desajuste de modo de bond, desajuste de MTU, LACP mal configurado, reglas de firewall o un reinicio de switch que volvió con un perfil de puerto diferente.

Una vez que la conectividad vuelva, la membresía de Corosync debería converger, votequorum se pondrá quórum, pmxcfs será escribible y la vida volverá.
Si la membresía sigue fluctuando, no procedas a cambios de configuración. Arregla la estabilidad primero.

Ruta B (aceptable): ajustar temporalmente los votos esperados

pvecm expected es una herramienta, no un estilo de vida. Es apropiado cuando:

• Tienes un clúster de varios nodos, pero suficientes nodos están permanentemente offline ahora para que no puedas recuperar la mayoría rápidamente.
• Puedes demostrar que el otro lado tampoco puede declarar quórum (porque está apagado, fenceado o aislado del almacenamiento compartido escribible).
• Necesitas recuperar la capacidad de escritura del clúster para realizar tareas de mantenimiento (delnode, ajustar corosync.conf vía pmxcfs, arreglar HA, programar mantenimiento).

No es apropiado cuando sospechas simplemente que los otros están caídos. La sospecha es para novelas de misterio, no para matemáticas de clúster.

Ruta C (alto riesgo): forzar un solo nodo para operar

A veces solo tienes un nodo superviviente y debes restaurar servicios. El riesgo es que cuando la red sane, podrías tener dos “verdades” divergentes de la configuración del clúster.
Si eliges esta vía, necesitas contención:

• Confirma que los otros nodos están caídos o fenceados.
• Desactiva acciones HA si pueden iniciar duplicados.
• Si existe almacenamiento compartido, asegúrate de que solo un lado pueda escribir (fencing, bloqueo de exportaciones, enmascaramiento SAN).

En la práctica, mucha gente “arregla” el quórum forzándolo, y luego descubre que HA reinició una VM en otro lado mientras también la iniciaron localmente.
Eso no es una solución de quórum; es un libro de desastres a tu elección.

Ruta D (reconstruir): cuando el clúster ha perdido coherencia

Si pmxcfs es inconsistente, varios nodos han sido forzados a quórum en aislamiento, o la configuración de corosync divergió, puedes estar en territorio de reconstrucción:
elige un nodo fuente de la verdad, captura configuraciones, reinstala/recrea el clúster, vuelve a unir nodos y reintroduce HA con cuidado.
Esto es más lento, pero a menudo es la única forma de recuperar la confianza en el sistema.

Tres mini-historias corporativas (dolor real incluido)

Mini-historia 1: El incidente causado por una suposición equivocada

Una compañía mediana ejecutaba un clúster Proxmox de tres nodos. Dos nodos estaban en el mismo rack; el tercero estaba “cerca” en otra fila.
El anillo de Corosync usaba una VLAN dedicada. Alguien hizo mantenimiento en un switch y movió temporalmente algunos puertos de acceso a la VLAN por defecto.
La NIC del anillo del tercer nodo quedó en la VLAN equivocada. El nodo siguió arriba, las VMs siguieron corriendo y la monitorización mostraba el host sano.

A la mañana siguiente, alguien vio “cluster not ready – no quorum?” en uno de los nodos del rack. Su suposición: “pve3 debe estar caído.”
No verificaron desde pve3. Ejecutaron pvecm expected 1 en pve1 y recuperaron inmediatamente la UI y el acceso de escritura a /etc/pve.
Victoria, ¿no?

No tanto. pve3 estaba vivo y todavía se conectaba a pve2 de forma intermitente por un camino accidental diferente debido a un segundo cambio de red.
Ahora hubo momentos donde dos particiones se volvieron “confiadas” en realidades distintas. Los cambios de configuración (firewall y almacenamiento) se aplicaron solo en un lado.

Cuando la VLAN se corrigió, el clúster se reconstituyó y el equipo obtuvo un nuevo conjunto de síntomas extraños: VMs faltantes en la UI de un nodo, definiciones de almacenamiento desincronizadas,
y errores de permisos esporádicos. Pasaron horas “arreglando permisos” que en realidad eran síntomas de divergencia de configuración durante la ventana de quórum forzado.

La solución fue aburrida: revertir los votos esperados al valor real, estabilizar la conectividad del anillo y luego reconciliar la configuración desde backups y desde un nodo elegido como fuente de verdad.
La lección fue más aguda: no cambies la matemática del quórum basándote en suposiciones sobre la salud de los nodos. Pruébalo.

Mini-historia 2: La optimización que salió mal

Otra organización quería “tráfico de clúster más rápido” y decidió habilitar jumbo frames en su red de virtualización.
Cambiaron la MTU en los bridges y bonds de Proxmox. La cambiaron en los switches top-of-rack.
No la cambiaron en un par de puertos trunk intermedios porque esos pertenecían a otro equipo y “seguro estaban en el estándar”.

Durante un tiempo, todo pareció bien. El tráfico de VM iba bien. El tráfico de almacenamiento funcionaba mayormente.
Corosync, sin embargo, empezó a fluctuar bajo carga. Ocurrían cambios de membresía durante ventanas de backup.
El quórum caía, volvía, volvía a caer. HA se puso nervioso y dejó de actuar; los operadores se pusieron nerviosos y empezaron a reiniciar nodos.

El flapping no era aleatorio. El tráfico de Corosync se fragmentaba o se descartaba a través de la ruta MTU desajustada.
Porque Corosync está diseñado para proteger la corrección, trató la pérdida de paquetes como una amenaza de membresía. Y lo era.

La “optimización” resultó en un clúster técnicamente más rápido pero operativamente menos fiable. Volvieron a MTU 1500 en el anillo de Corosync y mantuvieron jumbo frames
solo para almacenamiento, donde podían probar consistencia extremo a extremo.

El punto: optimiza donde puedas validar. A Corosync no le impresionan tus gráficos de throughput si tus paquetes no llegan consistentemente.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa del sector financiero (asuntos de auditoría, control de cambios y reuniones largas) ejecutaba un clúster Proxmox de cinco nodos.
Tenían una costumbre que los ingenieros se burlaban: un runbook impreso de una página con las IPs del anillo de corosync, puertos de switch y direcciones IPMI para cada nodo.
Se actualizaba trimestralmente, se firmaba y se plastificaba. Sí, plastificado.

Una tarde, una unidad de distribución de energía falló y dejó fuera dos nodos. Otro nodo se mantuvo arriba pero perdió el uplink del switch del anillo debido a una reconvergencia de spanning-tree.
El clúster cayó a dos nodos alcanzables de cinco. Sin quórum. La UI se volvió inestable. Los teléfonos sonaron.

En lugar de forzar el quórum, el on-call hizo tres cosas rápidamente: verificó qué nodos estaban realmente apagados vía IPMI, confirmó el problema del anillo en los nodos restantes,
y usó el runbook para identificar el uplink exacto del switch a revisar. No necesitaban adivinar. No necesitaban “descubrir” la topología durante el incidente.

El uplink se devolvió, el tercer nodo se reincorporó, el quórum regresó de forma natural (3/5) y evitaron cualquier maniobra de votos forzada.
Más tarde trajeron los dos nodos caídos y dejaron que el clúster se asentara. Drama mínimo.

La lección: inventario aburrido y buena higiene de topología superan la improvisación. Además, los runbooks plastificados no son cool, pero tampoco lo es un postmortem por split-brain.

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

1) Síntoma: “cluster not ready – no quorum?” después de un cambio de red

Causa raíz: Red del anillo Corosync rota (VLAN, MTU, bond/LACP, firewall).

Solución: Usa corosync-cfgtool -s, tcpdump y pings de MTU para confirmar la pérdida; restaura la consistencia L2/L3; no cambies votos como primera respuesta.

2) Síntoma: Un nodo ve quórum, otro no

Causa raíz: Partición, enrutamiento asimétrico o un nodo con votos esperados forzados localmente.

Solución: Compara pvecm status en cada nodo; deshace ajustes de votos forzados; asegúrate de que todos los nodos compartan la misma vista de membresía antes de cambiar la configuración del clúster.

3) Síntoma: /etc/pve es de solo lectura o las escrituras fallan

Causa raíz: No quórum, o pmxcfs está inestable debido a inestabilidad de corosync.

Solución: Restaura el quórum (preferido) o usa un cambio controlado de votos esperados; luego confirma la estabilidad de la membresía antes de editar la configuración del clúster.

4) Síntoma: El quórum cae intermitentemente (flapping)

Causa raíz: Pérdida de paquetes, desajuste de MTU, enlace inestable, interfaz del anillo sobrecargada o red virtual ruidosa.

Solución: Trátalo como un incidente de fiabilidad de red: mide la pérdida, revisa errores en switches, desactiva offloads problemáticos si hace falta y considera dedicar una red limpia al anillo.

5) Síntoma: El clúster de dos nodos pierde quórum cuando uno se reinicia

Causa raíz: Matemática del quórum en dos nodos: mayoría de 2 es 2; perder un voto significa sin quórum.

Solución: Añade un tercer voto (qdevice o tercer nodo). Si debes ejecutar dos nodos, acepta semánticas de clúster limitadas y planifica procedimientos de mantenimiento cuidadosamente.

6) Síntoma: Después de “arreglar el quórum”, HA inicia/apaga VMs inesperadamente

Causa raíz: Reconciliación del estado HA tras cambios de membresía; los recursos pueden estar en estados obsoletos.

Solución: Antes de restaurar el quórum, revisa los recursos HA; considera poner servicios en modo mantenimiento; restaura el quórum y luego valida las decisiones HA antes de permitir la automatización.

7) Síntoma: El clúster parece bien, pero los nodos no pueden unirse o se reinsertan constantemente

Causa raíz: corosync.conf con direcciones equivocadas, IDs de nodo duplicados, hostnames obsoletos o claves de autenticación desajustadas.

Solución: Valida /etc/pve/corosync.conf en el nodo autoritativo; asegura nodeid único y direcciones de anillo correctas; vuelve a unir nodos limpiamente en lugar de parchear.

Listas de comprobación / plan paso a paso

Checklist 1: “Acabo de ver no quorum” (haz esto en 5 minutos)

1. En el nodo afectado: ejecuta pvecm status. Haz captura de pantalla o copia la salida en el registro del incidente.
2. Ejecuta pvecm nodes para confirmar la membresía esperada.
3. Ejecuta corosync-cfgtool -s para ver quién está desconectado.
4. Revisa journalctl -u corosync -n 50 por mensajes de enlace caído.
5. Desde el nodo, haz ping a las IPs del anillo de los pares faltantes. Si el ping falla, para y arregla red o energía.
6. Si el ping funciona, ejecuta tcpdump -ni <ring-if> udp port 5405 mientras pruebas desde el par también.

Checklist 2: “¿Debería usar pvecm expected?” (puerta de decisión)

1. ¿Los nodos faltantes están confirmados apagados (IPMI) o fenceados? Si no: no lo hagas.
2. ¿Existe almacenamiento compartido escribible que podría montarse por ambas particiones? Si sí: no lo hagas a menos que el almacenamiento esté fenceado/bloqueado.
3. ¿Necesitas hacer escrituras a nivel de clúster (delnode, arreglar corosync.conf vía pmxcfs, ajustar HA) inmediatamente? Si no: espera y arregla la red.
4. ¿Tienes un plan explícito para revertir los votos esperados cuando los nodos vuelvan? Si no: escribe el plan primero.

Checklist 3: Restauración controlada del quórum (flujo de trabajo relativamente seguro)

1. Estabilizar la membresía: arregla la red del anillo hasta que corosync-cfgtool -s muestre peers conectados y los logs dejen de flappear.
2. Confirmar quórum: pvecm status muestra Quorate: Yes con votos esperados que coincidan con el tamaño real del clúster.
3. Validar escrituras en /etc/pve: crea y elimina un archivo de prueba en /etc/pve (o verifica ediciones de configuración vía UI).
4. Comprobar HA: asegúrate de que los servicios HA estén sanos y no haya acciones inesperadas pendientes.
5. Sólo entonces: realiza cambios de clúster (eliminar nodos muertos, cambiar configuración de almacenamiento, modificar reglas de firewall).

Checklist 4: Si debes ejecutar un solo nodo temporalmente

1. Confirma que los otros nodos están caídos vía IPMI o desconectados físicamente de la red del anillo.
2. Si existe almacenamiento compartido: asegúrate de que solo este nodo pueda escribir (deshabilitar exportaciones, eliminar mappings de LUN o imponer fencing).
3. Ajusta los votos esperados solo el tiempo necesario. Documenta el cambio en la línea temporal del incidente.
4. Evita hacer ediciones de configuración de gran escala en el estado forzado; haz lo mínimo para restaurar cargas críticas.
5. Cuando los otros nodos vuelvan, revierte los votos esperados y observa la convergencia de la membresía antes de reactivar HA y la automatización.

Preguntas frecuentes (FAQ)

1) ¿“No quorum” significa que mis VMs están corruptas?

Usualmente no. Significa que la coordinación del clúster no es segura. Las VMs pueden seguir ejecutándose, especialmente en almacenamiento local.
El riesgo de corrupción aumenta si inicias/detienes la misma VM desde particiones diferentes o si el almacenamiento compartido es escribible desde ambos lados.

2) ¿Puedo simplemente reiniciar corosync para arreglarlo?

Reiniciar corosync puede ayudar si el proceso está atascado, pero rara vez arregla la causa raíz (partición de red, MTU, firewall, par caído).
Además, reiniciar un componente durante flapping puede causar más inestabilidad. Diagnostica primero; reinicia con intención.

3) ¿Qué hace exactamente “pvecm expected”?

Establece el recuento total de votos esperado usado para calcular el quórum. Bajar ese valor puede hacer que una partición más pequeña sea quórum.
Es poderoso y peligroso: puedes crear la situación donde dos particiones crean ambas ser la mayoría si lo haces en ambos lados.

4) ¿Por qué los clústeres de dos nodos son tan problemáticos?

Porque la mayoría de 2 es 2. Si un nodo es inalcanzable, ninguno puede probar que tiene la mayoría.
Sin un desempate, el comportamiento más seguro es detener las escrituras del clúster. Eso es lo que estás viendo.

5) ¿Necesito un qdevice?

Si tienes dos nodos y quieres comportamiento limpio de quórum, sí: añade un qdevice (o un tercer nodo) para proporcionar un tercer voto.
Si tienes tres o más nodos, un qdevice es opcional, aunque puede ayudar en ciertos diseños.

6) ¿Por qué /etc/pve es especial?

Es pmxcfs: un sistema de archivos de clúster montado vía FUSE, respaldado por estado distribuido. Está diseñado para prevenir escrituras inseguras cuando la membresía es incierta.
Trátalo como una base de datos, no como una carpeta local.

7) Después de que vuelve el quórum, ¿por qué todo se siente “lento” por un rato?

La membresía se reforma, el estado converge, HA recalcula y los servicios restablecen conexiones.
Si hubo flapping, puede haber una cola de reintentos. Dale un minuto, pero vigila los logs por si persiste la inestabilidad.

8) ¿Cómo sé si estoy en riesgo de split-brain?

Si no puedes probar que solo una partición puede acceder a recursos compartidos escribibles, estás en riesgo.
Otra señal de alarma: diferentes nodos muestran distinta membresía o diferentes votos esperados. Ahí es donde el split-brain comienza—silenciosamente.

9) ¿Es seguro editar corosync.conf directamente?

Es seguro solo cuando tienes un clúster quórum (así el cambio se propaga de forma consistente) o durante una recuperación controlada de un solo nodo donde entiendes
que estás creando una nueva fuente de verdad. Las ediciones aleatorias durante no quórum son una gran manera de producir estado de clúster inconsistente.

10) ¿Y si solo queda un nodo y necesito la UI para gestionar VMs?

Puedes usar votos esperados para recuperar quórum en ese nodo, pero solo después de haber confirmado que los otros nodos están caídos o fenceados.
Luego mantén los cambios al mínimo y planea cómo reintroducir otros nodos limpiamente.

Conclusión: siguientes pasos prácticos

La pérdida de quórum es Proxmox haciéndote un favor: se niega a dejarte crear un estado de clúster inconsistente.
Tu trabajo es restaurar la conectividad y la membresía primero, y solo entonces restaurar la conveniencia.

Siguientes pasos que realmente ayudan:

1. Ejecuta el guion de diagnóstico rápido e identifica si la falla es de energía, red o divergencia de configuración.
2. Arregla la estabilidad de la red del anillo Corosync antes de cambiar votos. Trata el flapping como un incidente de red, no solo de Proxmox.
3. Si debes usar pvecm expected, hazlo como una acción controlada, documentada y con tiempo limitado y con hechos de fencing.
4. Una vez estable, reduce el dolor futuro: evita clústeres de dos nodos sin desempate, mantén Corosync en una red limpia y documenta la topología como si realmente importara.

Si te llevas una cosa de esto: no “forces quorum” hasta que puedas explicar adónde fue cada otro voto.
Esa explicación es la diferencia entre recuperación y arqueología.