Proxmox «pve-cluster.service failed»: Cómo recuperar la pila de clúster

Qué significa realmente «pve-cluster failed»

pve-cluster es el servicio que ejecuta el sistema de archivos del clúster de Proxmox (pmxcfs). pmxcfs es un filesystem basado en FUSE montado en /etc/pve. Si no está montado y sano, Proxmox pierde el acceso a la configuración del clúster tal como la espera. Eso incluye:

• Configuración de clúster, definiciones de almacenamiento, estado HA a nivel de clúster
• Configuración del firewall (ámbito de clúster)
• Pertenencia de nodos y distribución de la configuración de Corosync
• Archivos de configuración de VM y CT (en modo clúster)

En el fondo, pmxcfs depende en gran medida de Corosync (pertenencia al clúster, quorum, mensajería). Corosync no es solo «agradable de tener». Es el árbitro. Si no tienes quorum, pmxcfs se vuelve conservador para evitar escrituras en split-brain.

Ahí es donde duele: puedes tener «un nodo perfectamente bien» con VMs en ejecución y discos sanos, pero si Corosync no puede formar la pertenencia, pmxcfs puede negarse a escribir —o no arrancar— y entonces cada acción de gestión se convierte en un error críptico.

Postura operativa recomendada: trata pve-cluster.service failed como un síntoma, no como un diagnóstico. El diagnóstico real suele entrar en uno de estos grupos:

• Fallo de quorum/pertenencia (red, número de nodos, desajuste de configuración de Corosync)
• Restricción local del sistema (disco lleno, agotamiento de inodos, presión de memoria, límites de descriptores)
• Problemas de tiempo (deriva NTP que molesta a Corosync; TLS falla; los logs engañan)
• Configuración de clúster corrupta o inconsistente (corosync.conf malo, actualizaciones parciales, certificados de nodo obsoletos)
• Errores inducidos por el operador (flags de fuerza usados en el momento equivocado, «arreglos rápidos» que crean split-brain silenciosamente)

Una cita que conviene tener en mente: La esperanza no es una estrategia. —General Gordon R. Sullivan. No es una cita de Proxmox, pero debería estar en cada rotación de on-call.

Guion de diagnóstico rápido

Si tienes tiempo limitado, no reinicies servicios aleatoriamente. Tu objetivo es encontrar el cuello de botella rápido: ¿es un problema del nodo local o un problema de quorum del clúster?

Primero (60 segundos): determina si /etc/pve está montado y si Corosync tiene quorum

• Comprueba si pmxcfs está montado: findmnt /etc/pve
• Comprueba Corosync/quorum: pvecm status y corosync-quorumtool -s
• Comprueba la razón exacta de fallo: systemctl status pve-cluster + journalctl -u pve-cluster -b

Segundo (2–5 minutos): valida los «fundamentales aburridos» que matan servicios de clúster

• Espacio en disco/inodos: df -h, df -i
• Presión de memoria: free -h, dmesg -T | tail
• Sincronización de tiempo: timedatectl, chronyc tracking (o systemctl status systemd-timesyncd)
• Alcance de red en los enlaces de Corosync: comprobaciones de ping/MTU entre nodos

Tercero (5–15 minutos): decide tu modo de recuperación

• Si se puede restaurar el quorum: arregla la red/config/tiempo y levanta Corosync normalmente. Luego reinicia pve-cluster.
• Si no se puede restaurar el quorum rápido: elige entre operaciones seguras solo lectura o un modo controlado de un solo nodo temporal (solo si entiendes las consecuencias).
• Si es un clúster de dos nodos: decide si usar un qdevice (lo mejor), o un ajuste temporal de expected-votes (arriesgado pero a veces necesario).

Broma #1: Si tu primer paso de recuperación es «reiniciar todo», no estás haciendo diagnóstico —estás realizando una danza interpretativa para los dioses de las interrupciones.

Datos interesantes y contexto histórico (que realmente te ayudan a depurar)

1. pmxcfs es un sistema de archivos FUSE. Eso significa que el «directorio» /etc/pve que ves es un montaje en espacio de usuario; si está caído, tus archivos reales en disco están en otra parte y el comportamiento cambia.
2. Proxmox se orientó pronto hacia la configuración centrada en clúster. La decisión hace que la gestión multinodo sea coherente, pero también implica que la salud del clúster afecta operaciones básicas en un solo nodo.
3. El diseño de Corosync prioriza el quorum. Prefiere rechazar escrituras antes que arriesgar un split-brain. Por eso los fallos a menudo parecen «excesivamente estrictos».
4. Los clústeres de dos nodos son inherentemente incómodos. Sin un tercer voto (qdevice o testigo), siempre estás a una falla de discutir filosóficamente quién es «el clúster».
5. Quorum no es sobre la mayoría de servicios activos —es sobre una pertenencia segura. Puedes tener el 99% de servicios funcionando y aun así ser «inseguro para escribir estado de clúster».
6. La deriva de reloj puede hacerse pasar por fallo de red. Corosync y TLS se comportan mal cuando el tiempo está mal; los logs engañan y los reintentos se disparan.
7. Los problemas por disco lleno afectan más a los clústeres. Un filesystem raíz lleno puede impedir escrituras de estado, registros o internals de pmxcfs, provocando fallos en cascada que parecen «Corosync muerto».
8. Los errores de la interfaz de Proxmox a menudo reflejan el estado de pmxcfs. La interfaz web puede seguir cargando pero las operaciones fallan porque no puede escribir configuraciones en /etc/pve.

Tareas prácticas de recuperación (comandos, salidas, decisiones)

Estas son tareas reales que ejecutas en un nodo. Cada tarea incluye: comando, qué significa la salida y la decisión que tomas a continuación. No las ejecutes todas a ciegas; sigue el orden del guion de diagnóstico rápido.

Task 1: Confirmar la falla del servicio y capturar la razón real

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: failed (Result: exit-code) since Tue 2025-12-25 09:41:02 UTC; 2min 3s ago
    Process: 1832 ExecStart=/usr/bin/pmxcfs (code=exited, status=255/EXCEPTION)
     Memory: 1.6M
     CPU: 43ms

Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: starting pmxcfs
Dec 25 09:41:02 server pmxcfs[1832]: [main] crit: unable to initialize cluster communication
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

Significado: pmxcfs arrancó pero no pudo inicializar la comunicación del clúster —muy a menudo Corosync/quorum. No es un fallo genérico.

Decisión: Comprueba inmediatamente el estado de Corosync y el quorum antes de tocar flags de pmxcfs o reiniciar todo.

Task 2: Leer el journal de pve-cluster para la cadena de fallo precisa

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 25 09:40:59 server systemd[1]: Starting The Proxmox VE cluster filesystem...
Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: starting pmxcfs
Dec 25 09:41:02 server pmxcfs[1832]: [dcdb] notice: data verification successful
Dec 25 09:41:02 server pmxcfs[1832]: [main] crit: unable to initialize cluster communication
Dec 25 09:41:02 server pmxcfs[1832]: [main] notice: exit now
Dec 25 09:41:02 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=255/EXCEPTION

Significado: La base de datos local (dcdb) parece estar bien. El fallo es de red/pertenencia más que de corrupción local.

Decisión: Concéntrate en Corosync y quorum, no en reinstalar paquetes o «reparar» archivos todavía.

Task 3: Comprobar si /etc/pve está montado (pmxcfs)

cr0x@server:~$ findmnt /etc/pve

Significado: Normalmente, sin salida significa que no está montado. Si está montado, verás un montaje FUSE (pmxcfs).

Decisión: Si no está montado y pve-cluster ha fallado, estás en territorio de «sistema de archivos de clúster caído». No edites /etc/pve esperando que persista a nivel de clúster.

Task 4: Verificar el estado de Corosync y quorum con las herramientas de Proxmox

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

Quorum information
------------------
Date:             Tue Dec 25 09:43:18 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.152
Quorate:          No

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

Significado: No hay quórum. Con solo 1 de 3 votos visible, los servicios de clúster actuarán a la defensiva.

Decisión: Necesitas restaurar la conectividad al menos a otro nodo (o qdevice) antes de esperar que pmxcfs se comporte normalmente.

Task 5: Contrastar la propia vista de Corosync

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Tue Dec 25 09:43:46 2025
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          1
Ring ID:          152.209
Quorate:          No

Votequorum information
----------------------
Expected votes:   3
Total votes:      1
Quorum:           2
Flags:            None

Significado: Confirma que no es solo la herramienta de Proxmox; Corosync verdaderamente carece de pertenencia.

Decisión: Deja de pensar «pve-cluster está roto.» Empieza a pensar «el clúster está roto.»

Task 6: Comprobar el servicio de Corosync y logs recientes

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:41:10 UTC; 2min 50s ago
       Docs: man:corosync
   Main PID: 1904 (corosync)
      Tasks: 9
     Memory: 29.8M
     CPU: 2.214s

cr0x@server:~$ journalctl -u corosync -b --no-pager -n 80
Dec 25 09:41:10 server corosync[1904]:   [KNET  ] link: host: 2 link: 0 is down
Dec 25 09:41:10 server corosync[1904]:   [KNET  ] link: host: 3 link: 0 is down
Dec 25 09:41:10 server corosync[1904]:   [QUORUM] This node is within the non-primary component and will NOT provide service.

Significado: Corosync está en ejecución, pero el enlace knet no puede alcanzar a los pares. Normalmente es red, MTU, VLAN, firewall o IP incorrecta en corosync.conf.

Decisión: Verifica la ruta de la red del anillo de extremo a extremo antes de hacer cualquier edición de configuración.

Task 7: Validar que corosync.conf esté presente y consistente en este nodo

cr0x@server:~$ sed -n '1,200p' /etc/pve/corosync.conf
sed: can't read /etc/pve/corosync.conf: No such file or directory

Significado: Si pmxcfs está abajo, /etc/pve puede estar vacío/no montado, por lo que el archivo no se leerá. Eso no significa que esté «perdido», significa que el montaje no está.

Decisión: Lee la copia local de reserva en /etc/corosync/corosync.conf (no es perfecta, pero indica lo que este nodo cree).

cr0x@server:~$ sed -n '1,220p' /etc/corosync/corosync.conf
totem {
  version: 2
  cluster_name: prod-clu
  transport: knet
  interface {
    linknumber: 0
    bindnetaddr: 10.10.50.0
    mcastport: 5405
  }
}
nodelist {
  node {
    name: pve1
    nodeid: 1
    ring0_addr: 10.10.50.11
  }
  node {
    name: pve2
    nodeid: 2
    ring0_addr: 10.10.50.12
  }
  node {
    name: pve3
    nodeid: 3
    ring0_addr: 10.10.50.13
  }
}
quorum {
  provider: corosync_votequorum
}

Significado: Este nodo espera pares en 10.10.50.0/24. Si tu equipo de red «optimizó» VLANs, aquí es donde lo detectas.

Decisión: Confirma que 10.10.50.x es alcanzable L2/L3 como está diseñado y que la interfaz del nodo está realmente en esa subred.

Task 8: Confirmar que la IP y el enrutamiento del nodo coinciden con la red del anillo de Corosync

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.50.11/24
eno2             DOWN
vmbr0            UP             192.168.10.11/24

cr0x@server:~$ ip route
default via 192.168.10.1 dev vmbr0
10.10.50.0/24 dev eno1 proto kernel scope link src 10.10.50.11
192.168.10.0/24 dev vmbr0 proto kernel scope link src 192.168.10.11

Significado: La red del anillo de Corosync está directamente conectada en eno1. Eso es bueno. Si no fuera así, verías enrutamiento extraño.

Decisión: Prueba conectividad y MTU con los pares en la red del anillo a continuación.

Task 9: Probar alcance de pares y MTU (a Corosync no le gustan las pérdidas silenciosas)

cr0x@server:~$ ping -c 2 10.10.50.12
PING 10.10.50.12 (10.10.50.12) 56(84) bytes of data.

--- 10.10.50.12 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1016ms

cr0x@server:~$ ping -M do -s 1472 -c 2 10.10.50.12
PING 10.10.50.12 (10.10.50.12) 1472(1500) bytes of data.

--- 10.10.50.12 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1013ms

Significado: Pérdida total sugiere problema de enlace/VLAN/firewall/puerto, no solo MTU. Si un ping pequeño funciona pero el ping con MTU falla, sospecha de desajuste de MTU o un camino con fragmentación bloqueada.

Decisión: Si el ping falla, para. Arregla la ruta de red (puerto del switch, etiquetado VLAN, reglas de firewall, enrutamiento). Reiniciar servicios no cambia la física.

Task 10: Comprobar si el firewall bloquea tráfico de Corosync en el host

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

cr0x@server:~$ iptables -S | head
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Significado: El firewall de Proxmox puede estar activado y aun así no bloquear Corosync según el conjunto de reglas. El fragmento de iptables aquí muestra ACCEPT por defecto, lo que sugiere que el firewall del host no es el problema.

Decisión: Si ves DROP por defecto o descartes explícitos en UDP 5405/5404, arregla las reglas. Si no, enfócate en la red upstream.

Task 11: Comprobar espacio en disco y agotamiento de inodos (sí, en serio)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        48G   47G  180M 100% /

cr0x@server:~$ df -i /
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2     3145728 3120000   25728   100% /

Significado: Disco lleno y inodos agotados son asesinos clásicos de clúster. Los servicios no pueden escribir estado, logs o archivos temporales. pmxcfs puede fallar de formas creativas.

Decisión: Libera espacio de forma segura (logs, kernels viejos, ISOs). No borres archivos de clúster al azar por rabia.

Task 12: Comprobación de tiempo (porque los sistemas distribuidos son quisquillosos)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-25 09:46:10 UTC
           Universal time: Tue 2025-12-25 09:46:10 UTC
                 RTC time: Tue 2025-12-25 09:46:09
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

cr0x@server:~$ chronyc tracking
Reference ID    : 192.0.2.10
Stratum         : 3
Last offset     : +3.421 seconds
RMS offset      : 1.922 seconds
Frequency       : 34.112 ppm fast
Leap status     : Not synchronised

Significado: Estás derivando segundos. Eso es suficiente para que componentes distribuidos actúen de forma extraña —especialmente durante cambios de pertenencia y validación TLS.

Decisión: Arregla la sincronización de tiempo primero (alcance NTP, configuración de chrony). Luego vuelve a intentar Corosync/pve-cluster.

Task 13: Levantar Corosync limpiamente (tras arreglar la causa subyacente)

cr0x@server:~$ systemctl restart corosync

cr0x@server:~$ pvecm status | sed -n '1,40p'
Cluster information
-------------------
Name:             prod-clu
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Tue Dec 25 09:49:02 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.154
Quorate:          Yes

Significado: Quorum ha vuelto. Ahora pmxcfs tiene una oportunidad de arrancar correctamente.

Decisión: Reinicia pve-cluster y verifica el montaje.

Task 14: Reiniciar pve-cluster y validar el montaje de pmxcfs + lecturas básicas

cr0x@server:~$ systemctl restart pve-cluster

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 Tue 2025-12-25 09:49:20 UTC; 4s ago
   Main PID: 2488 (pmxcfs)

cr0x@server:~$ findmnt /etc/pve
TARGET   SOURCE  FSTYPE OPTIONS
/etc/pve pmxcfs  fuse   rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other

cr0x@server:~$ ls -la /etc/pve | head
total 0
drwxr-xr-x 2 root www-data 0 Dec 25 09:49 .
drwxr-xr-x 1 root root     0 Dec 25 09:49 ..
-rw-r----- 1 root www-data 0 Dec 25 09:49 .members
-rw-r----- 1 root www-data 0 Dec 25 09:49 corosync.conf
drwxr-xr-x 2 root www-data 0 Dec 25 09:49 nodes

Significado: Está montado y la configuración del clúster es visible otra vez. Ese es el indicador de «la pila volvió».

Decisión: Verifica pvedaemon y pveproxy a continuación si la interfaz sigue dando errores.

Task 15: Validar servicios del backend de la interfaz una vez que el FS de clúster está sano

cr0x@server:~$ systemctl status pvedaemon pveproxy --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:40 UTC; 9s ago
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:42 UTC; 7s ago

Significado: La pila de API está en ejecución. Si la GUI sigue fallando, probablemente sea por auth/cert o caché del navegador o algún nodo que todavía no está quórate.

Decisión: Comprueba la pertenencia del clúster y la lista de nodos en todos los nodos.

Task 16: Confirmar la pertenencia y buscar «nodos fantasma»

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1
         2          1 pve2
         3          1 pve3

Significado: La pertenencia está limpia. Si ves nodos que desmantelaste hace meses, tu configuración de clúster está obsoleta y puede causar matemáticas de quorum extrañas o intentos de conexión.

Decisión: Si existen nodos fantasma, planifica una eliminación adecuada del clúster, no una edición improvisada durante una interrupción.

Task 17: Si pmxcfs está montado pero las escrituras fallan, prueba una operación segura de escritura

cr0x@server:~$ touch /etc/pve/.pmxcfs-write-test
touch: cannot touch '/etc/pve/.pmxcfs-write-test': Read-only file system

Significado: pmxcfs montado en solo lectura. Esto a menudo se correlaciona con pérdida de quorum o modo de protección interno.

Decisión: Revisa el quorum (pvecm status). Si quorate es «No», deja de intentar forzar escrituras. Restaura el quorum o elige deliberadamente el modo de un solo nodo con ojos abiertos (ver listas de verificación).

Task 18: Confirmar señales de salud de la base de datos de configuración local

cr0x@server:~$ systemctl status pve-cluster --no-pager -l
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Tue 2025-12-25 09:49:20 UTC; 1min 22s ago
   Main PID: 2488 (pmxcfs)
     CGroup: /system.slice/pve-cluster.service
             └─2488 /usr/bin/pmxcfs

Significado: Estás verificando principalmente que se mantenga arriba y no entre en crash-loop. Si hace flapping, todavía está peleando con Corosync, disco o tiempo.

Decisión: Si hace flapping, deja de reiniciarlo. Vuelve a los logs de Corosync y comprobaciones de recursos del host.

Causas raíz según el síntoma (cómo pensar, no solo qué teclear)

Síntoma: pve-cluster falla inmediatamente con «unable to initialize cluster communication»

Posibles causas: Corosync caído, Corosync arriba pero sin quorum, red del anillo equivocada, UDP bloqueado, desajuste de MTU o deriva temporal que provoca inestabilidad de pertenencia.

Enfoque: Verifica quorum y logs de Corosync primero. Si Corosync no ve a los pares, pmxcfs normalmente no formará una vista coherente.

Síntoma: /etc/pve existe pero está vacío o faltan archivos esperados

Posibles causas: pmxcfs no está montado; estás viendo el directorio subyacente (o un montaje roto).

Enfoque: Usa findmnt. Si no está montado, no «recrees» archivos en /etc/pve manualmente. Así es como creas una futura interrupción con pasos extra.

Síntoma: pmxcfs se monta en solo lectura

Posibles causas: Falta de quorum. A veces modo de protección local tras inestabilidad.

Enfoque: Restaura el quorum si es posible. Si no es posible, decide si necesitas escribir lo suficiente como para aceptar el riesgo de split-brain (normalmente: no).

Síntoma: Corosync está «active (running)» pero el clúster no es quórate

Posibles causas: Partición de red, nodos pares caídos, desajuste de configuración entre nodos o las matemáticas de «expected votes» no coinciden con la realidad (común después de la eliminación de nodos o diseño de dos nodos).

Enfoque: Lee los logs de Corosync, comprueba la alcanzabilidad, confirma la versión de configuración consistente y valida la lista de nodos.

Síntoma: Todo iba bien hasta que alguien cambió VLAN/MTU/teaming

Posibles causas: Tráfico de Corosync dropeado, fragmentado o reenrutado. knet es robusto pero no mágico.

Enfoque: Valida MTU de extremo a extremo, comprueba etiquetas de puerto del switch y asegúrate de que la red del anillo no esté accidentalmente en un segmento congestionado o filtrado.

Síntoma: La pila del clúster falla tras un corte de energía

Posibles causas: Deriva de tiempo (RTC mal), orden de arranque inconsistente, nodos arrancando sin red lista o problemas parciales de disco por cierres abruptos.

Enfoque: Confirma sincronización de tiempo, comprueba discos, y luego levanta Corosync antes de esperar que pmxcfs esté contento.

Broma #2: El quorum es como una reunión que necesita a dos personas para aprobar una decisión —hasta que una persona falta y de repente nadie recuerda cómo hacer su trabajo.

Tres micro-historias corporativas (porque el dolor enseña)

Micro-historia 1: El incidente provocado por una suposición errónea

Ejecutaban un clúster de tres nodos en una empresa mediana: nodos de cómputo en un rack, almacenamiento en otra plataforma, red «estandarizada». Una tarde, la interfaz de gestión de un nodo empezó a lanzar errores de clúster y pve-cluster.service pasó a estado failed. Un ingeniero junior hizo lo que muchos hacemos bajo presión: «Es solo la UI; las VMs están en marcha, así que el clúster debe estar bien».

La suposición errónea fue sutil: asumieron que el estado de clúster solo se necesitaba para acciones a nivel de clúster. Pero sus backups de VM, cambios de firewall y definiciones de almacenamiento vivían en /etc/pve vía pmxcfs. Cuando pmxcfs falló, los trabajos de backup empezaron a fallar silenciosamente al principio (las configuraciones no se podían leer de forma consistente), y luego ruidosamente (las operaciones API fallaban). El informe posterior usó la frase «interrupción secundaria», que en corporativo significa «lo empeoramos».

La causa raíz fue un cambio en la red del VLAN de Corosync. Se actualizó el perfil de puerto de un switch para un «MTU estándar», lo que en la práctica significó que la red de Corosync perdió jumbo frames mientras parte del camino aún los enviaba. Corosync no murió; simplemente no pudo mantener la pertenencia estable. pmxcfs se negó a participar, prefiriendo con razón la seguridad frente al desorden.

Lo que lo arregló no fueron los reinicios. Fue verificar la red del anillo extremo a extremo con pings de MTU y luego alinear el MTU de forma consistente. Tras eso, Corosync recuperó quorum, pmxcfs se montó en lectura-escritura y la UI volvió a comportarse como una interfaz en lugar de un acertijo.

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

Otra organización decidió que su red de clúster era «demasiado ruidosa». Tenían redes separadas para almacenamiento, VMs y gestión. Así que «optimizó» consolidando Corosync sobre el puente de gestión porque «ya tiene conectividad a todas partes». El cambio se hizo en horas de oficina porque el ingeniero creía que Corosync se reconectaría rápido y pmxcfs sería tolerante. El optimismo es un recurso renovable.

La red de gestión tenía reglas de firewall, límites de tasa y picos ocasionales por monitorización, parches y gestión de configuración. La pertenencia de Corosync comenzó a temblar bajo carga, lo que significó pérdida intermitente de quorum. pmxcfs alternaba entre usable y defensivo. Su UI de Proxmox se convirtió en una máquina tragamonedas: pulsa «arrancar VM», quizá funcione, quizá falle.

El daño real apareció después. El estado HA y las escrituras de configuración se produjeron durante breves «ventanas quórum», pero fueron bloqueadas en las «ventanas no quórum», creando expectativas operativas inconsistentes. La gente empezó a «arreglar» síntomas: reiniciar daemons, desactivar firewalls, añadir hacks a expected votes. El entorno se volvió ruidoso operativamente —el peor tipo de inestable, porque parece vivo.

La recuperación fue deshacer la optimización. Corosync obtuvo una red dedicada con latencia estable y MTU uniforme, y dejaron de tratar la pertenencia del clúster como «solo otro servicio UDP». Después añadieron un qdevice porque el clúster ocasionalmente operaba con dos nodos durante mantenimientos. Elecciones aburridas. Muy efectivas.

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

Un equipo de servicios financieros tenía un clúster Proxmox que rara vez fallaba —porque practicaban disciplina poco llamativa. Documentaban la topología del anillo de Corosync, mantenían un script simple de «salud del clúster» monitorizado y aplicaban la sincronización de tiempo como si fuera un control de seguridad (porque lo es).

Una mañana, pve-cluster falló en un nodo tras una actualización del kernel. El ingeniero on-call no empezó reiniciando servicios. Empezó capturando evidencia: pvecm status, journalctl, df, timedatectl. En minutos, vio que el reloj del nodo estaba mal y NTP no se sincronizaba. La actualización había restablecido una política de red y bloqueado el egress de NTP en esa VLAN.

Porque tenían una checklist conocida y valida, arreglaron la regla de firewall, confirmaron que chronyc tracking se estabilizara, y luego reiniciaron Corosync y pmxcfs en el orden correcto. El clúster se recuperó sin hacks de configuración. Las VMs siguieron corriendo. La UI volvió. Nadie tuvo que «forzar» nada.

El postmortem fue casi aburrido. Ese es el punto. No ganaron por ser más listos; ganaron por ser consistentes.

Listas de verificación / plan paso a paso

Checklist A: Recuperación segura cuando se puede restaurar el quorum

1. Congela operaciones riesgosas. No migres VMs, no cambies definiciones de almacenamiento, no edites la configuración del clúster mientras esté inestable.
2. Captura el estado. Guarda salidas de systemctl status pve-cluster corosync, pvecm status y las últimas ~100 líneas de logs de ambos servicios.
3. Arregla lo básico primero:
   • Espacio en disco/inodos
   • Sincronización de tiempo
   • Alcance de red en los enlaces del anillo (incluyendo MTU)
4. Reinicia Corosync tras la corrección subyacente. No lo reinicies por superstición.
5. Confirma que quorate = Yes. Si no, para y sigue trabajando el problema de red/pertenencia.
6. Reinicia pve-cluster. Valida que findmnt /etc/pve muestre pmxcfs.
7. Valida comportamiento de lectura/escritura. Si está en solo lectura, aún no tienes quorum o estabilidad.
8. Luego valida servicios de API. pvedaemon, pveproxy.
9. Solo entonces reanuda operaciones normales.

Checklist B: Operación controlada de un solo nodo (último recurso, temporal)

Aquí es donde la gente se hace daño. Si ejecutas un solo nodo como si fuera «el clúster» mientras otros nodos pueden volver más tarde, arriesgas configuración en split-brain. Si no entiendes esa frase, no lo hagas.

1. Confirma que los otros nodos están realmente caídos o aislados. Si pueden volver inesperadamente, estás jugando a la ruleta de configuración.
2. Comunica. Informa a tu equipo que entras en modo degradado y que los cambios de configuración pueden requerir reconciliación más tarde.
3. Prefiere acciones solo lectura. Mantén las cargas de trabajo en ejecución. Evita editar la configuración a nivel de clúster.
4. Si debes recuperar capacidad de escritura, usa una estrategia deliberada de quorum (qdevice o ajuste temporal de expected-votes) y documenta lo que cambiaste.
5. Planifica el retorno a la normalidad. Lo difícil no es entrar en modo degradado —es salir de él limpiamente.

Checklist C: Plan de supervivencia para clúster de dos nodos

1. Mejor: añade un qdevice/testigo en un tercer dominio de fallo (no en el mismo host, evita el mismo switch si puedes).
2. Durante el incidente: si un nodo está caído, espera pérdida de quorum a menos que lo hayas planificado.
3. No «hackees» permanentemente los expected votes. Los cambios temporales se vuelven permanentes en la práctica y entonces aprenderás cómo sabe el split-brain.
4. Después de la recuperación: invierte en el tercer voto. Es más barato que la siguiente interrupción.

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

1) «pve-cluster falló, así que edité /etc/pve manualmente»

Síntoma: Tras la recuperación, los cambios de configuración desaparecieron o solo existían en un nodo.

Causa raíz: pmxcfs no estaba montado; editaste el directorio subyacente o una vista local stub.

Solución: Verifica findmnt /etc/pve antes de cualquier edición. Haz cambios solo cuando pmxcfs esté montado y con quorum.

2) Corosync está en ejecución, pero quorate es «No», así que reinicié pve-cluster 20 veces

Síntoma: pmxcfs hace flapping; los errores de UI persisten.

Causa raíz: Problema de pertenencia (partición de red, pares ausentes, desajuste de expected votes).

Solución: Restaura la conectividad de red y una configuración de Corosync consistente; reinicia Corosync una vez tras arreglar la causa subyacente; luego reinicia pve-cluster.

3) «Tenemos tres nodos, así que siempre tendremos quorum»

Síntoma: Un nodo cae y de repente el clúster no es quórate.

Causa raíz: Dos nodos no se están comunicando realmente (partición silenciosa), dejando solo un voto visible.

Solución: Valida la conectividad entre todos los nodos en la red del anillo. Un clúster es un grafo, no un recuento de cabezas.

4) Desajuste de MTU causa pérdida intermitente de quorum

Síntoma: Pertenencia de Corosync hace flapping, especialmente bajo carga o tras cambios de red.

Causa raíz: MTU mixto a través del camino, fragmentación bloqueada o inconsistencia en el puerto del switch.

Solución: Estandariza MTU de extremo a extremo. Usa pruebas con ping -M do -s entre interfaces de anillo.

5) Disco lleno provoca fallos que parecen «comunicación de clúster»

Síntoma: Servicios se caen o se niegan a arrancar; los logs pueden estar truncados; comportamiento extraño tras actualizaciones.

Causa raíz: Filesystem raíz o inodos agotados.

Solución: Libera espacio/inodos de forma segura y luego reinicia servicios. También corrige retención de logs y housekeeping para que no vuelva a ocurrir.

6) Deriva de tiempo hace que todo parezca un problema de red

Síntoma: Errores TLS, estado de clúster extraño, logs inconsistentes, inestabilidad de pertenencia.

Causa raíz: NTP no sincronizado; RTC incorrecto; NTP bloqueado.

Solución: Restaura la sincronización de tiempo, confirma seguimiento estable y luego reevalúa la pertenencia de Corosync.

7) Eliminar un nodo «borrándolo»

Síntoma: Aparecen nodos fantasma; expected votes incorrectos; las matemáticas de quorum te sorprenden.

Causa raíz: El nodo fue desmantelado sin los pasos correctos de eliminación del clúster.

Solución: Usa los procedimientos correctos de eliminación de nodos cuando el clúster esté sano; no improvises durante una interrupción.

Preguntas frecuentes

1) ¿Qué es exactamente pve-cluster.service?

Ejecuta pmxcfs, el sistema de archivos de clúster de Proxmox montado en /etc/pve. Si está abajo, el acceso a la configuración del clúster se rompe de formas que hacen que la UI y la API parezcan poco fiables.

2) ¿Mis VMs en ejecución se ven afectadas cuando pve-cluster está caído?

Normalmente las VMs siguen en ejecución. El problema es en las operaciones de gestión: arrancar/detener desde la UI, migraciones, backups, acciones HA y escrituras de configuración pueden fallar o volverse inseguras.

3) ¿Por qué /etc/pve aparece vacío?

Porque pmxcfs no está montado. Estás viendo el directorio subyacente, no el montaje FUSE. Confírmalo con findmnt /etc/pve.

4) Corosync está en ejecución. ¿Por qué no funciona el clúster?

Corosync puede estar «en ejecución» pero sin quorum. Sin quorum, pmxcfs puede negarse a escribir o fallar al arrancar. Revisa pvecm status y los logs de Corosync.

5) ¿Puedo simplemente reiniciar pve-cluster y corosync hasta que funcione?

Puedes, pero es una estrategia débil. Si la causa raíz es alcance de red, MTU, disco lleno o deriva de tiempo, los reinicios solo añaden ruido y pueden empeorar la inestabilidad.

6) ¿Cuál es la forma más rápida de saber si esto es red vs. nodo local?

Si df -h y timedatectl parecen correctos, entonces pvecm status + journalctl -u corosync normalmente apuntarán directamente a red/pertenencia.

7) Tengo un clúster de dos nodos. ¿Es normal perder quorum cuando un nodo cae?

Sí. El quorum en dos nodos es incómodo por diseño. Si quieres un comportamiento de fallo limpio, usa un qdevice/testigo para que el clúster aún pueda tomar una decisión de mayoría.

8) pmxcfs está montado en solo lectura. ¿Cómo lo fuerzo a lectura-escritura?

La mayoría de las veces, solo lectura indica pérdida de quorum o inestabilidad. La «solución» es restaurar el quorum. Forzar escrituras sin quorum arriesga la configuración en split-brain.

9) La GUI de Proxmox dice «cluster not ready» pero los servicios parecen arriba. ¿Qué hago ahora?

Verifica el montaje de /etc/pve, el quorum y si los servicios de API están sanos. Muchos errores de la GUI son solo problemas de pmxcfs/quorum reflejados a través de la API.

10) Después de la recuperación, un nodo todavía muestra configuración antigua. ¿Es posible?

Sí —especialmente tras particiones o si alguien hizo ediciones locales mientras pmxcfs estaba abajo. Confirma la pertenencia, la versión de configuración y evita reconciliar manualmente a menos que estés seguro de cuál estado es autoritativo.

Siguientes pasos para evitar reinci­dencias

Poner pve-cluster de nuevo en marcha es la mitad del trabajo. Mantenerlo aburrido es la otra mitad.

• Da a Corosync una ruta de red estable. VLAN dedicada si es posible, MTU consistente de extremo a extremo, sin «sorpresas» de firewall.
• Arregla el tiempo como si fuera crítico para producción (porque lo es). Monitorea la sincronización NTP; alerta por deriva.
• Monitoriza quorum y montaje de pmxcfs. Alerta cuando Quorate: No o cuando findmnt /etc/pve no muestre pmxcfs.
• Deja de montar clústeres de dos nodos sin testigo. Si el presupuesto permite dos nodos, añade un pequeño tercer voto.
• Escribe el orden de recuperación. Corosync/quorum primero, luego pve-cluster, luego servicios API. No improvises durante una interrupción.

Si tomas un solo hábito operativo de esto: antes de tocar la configuración, confirma que /etc/pve esté montado y que el clúster sea quórate. Esa única comprobación evita una cantidad notable de daños autoinfligidos.