Proxmox “node not in cluster”: qué ocurrió y cómo reincorporarlo correctamente

Qué significa realmente “node not in cluster”

En Proxmox VE, “node not in cluster” suele aparecer cuando un nodo cree que debería estar en un clúster, pero no puede ver (o validar) el estado del clúster. Ese estado lo entrega Corosync y se almacena/distribuye a través de pmxcfs (el sistema de archivos de clúster de Proxmox) montado en /etc/pve.

El mensaje puede significar una de estas realidades prácticas:

• Corosync no se está ejecutando (o no puede enlazar la red del clúster).
• Sin quórum, por lo que pmxcfs pasa a solo lectura o no se monta completamente, y la configuración del clúster no es confiable.
• La identidad del nodo en el clúster está obsoleta (corosync.conf incorrecto, ID de nodo equivocado, direcciones de anillo incorrectas, o mapeo de hostname/IP erróneo).
• Split brain: el nodo formó o mantuvo una vista diferente del clúster y ahora es incompatible.
• Deriva de tiempo rompe la autenticación de Corosync o provoca que los tokens expiren de maneras creativas.
• Cambiaste la red (VLAN, MTU, bonding, firewall) y ahora el tráfico de Corosync está triste.

La parte opinable: trata el mensaje como un fusible de seguridad. Es Proxmox diciéndote: “No puedo demostrar el estado del clúster; no voy a fingir.” Tu trabajo es averiguar por qué no puede demostrarlo y luego elegir la vía de recuperación menos destructiva.

También: nunca “soluciones” esto copiando archivos aleatorios a /etc/pve desde otro nodo a menos que entiendas exactamente lo que haces. /etc/pve no es un directorio normal. Es una base de datos distribuida con criterio propio.

Hechos y contexto que explican la rareza

Esto no es trivia. Son minas históricas pequeñas que explican por qué Proxmox se comporta así.

1. Corosync proviene del ecosistema HA de Linux y hereda una visión donde “membresía y quórum primero”. Si la membresía es incierta, prefiere detenerse antes que adivinar.
2. Proxmox guarda la mayor parte de la configuración de clúster en pmxcfs, un sistema FUSE respaldado por una base de datos en memoria replicada vía Corosync. Por eso perder Corosync a menudo rompe tareas de configuración “simples”.
3. /etc/pve no es como /etc. Se monta dinámicamente. Si no está montado, los servicios de Proxmox que lo esperan pueden comportarse como si hubieras eliminado el plano de control.
4. Las reglas de quórum existen para prevenir split brain, no para molestarte. También explican por qué un clúster de dos nodos es incómodo operativamente a menos que añadas un tercer votante (qdevice) o aceptes limitaciones.
5. La identidad del nodo en el clúster depende de IDs y nombres transportados en la configuración de Corosync y el estado interno; un hostname desajustado puede parecer otra máquina en el mismo uniforme.
6. Proxmox históricamente optimizó para fiabilidad on‑prem donde “un nodo desapareció” suele ser un problema de cableado o switch, no un evento de autoescalado. La UI y los valores por defecto reflejan eso.
7. El multicast en red solía ser importante en clústeres. Corosync moderno suele usar unicast, pero la regla “la red del clúster debe ser aburrida y predecible” sobrevivió por buenas razones.
8. La sincronización horaria es una dependencia de clúster porque la mensajería autenticada y los timeouts son suposiciones del protocolo de membresía. Problemas de NTP pueden disfrazarse de problemas de red.
9. La pila HA de Proxmox asume que el fencing importa. Sin una vista de membresía fiable, evita acciones que puedan arrancar la misma VM dos veces.

Una idea para poner en cada pared de operaciones: “La esperanza no es una estrategia; diseña para que las fallas sean esperadas y recuperables.”

Guía rápida de diagnóstico

Esta es la secuencia “deja de desplazarte y encuentra el cuello de botella”. Intentas responder tres preguntas: ¿Tenemos quórum? ¿Está Corosync sano? ¿Está /etc/pve montado y consistente?

1) Primero: verifica si el nodo está simplemente aislado

• ¿Puede alcanzar a los otros nodos en las IPs del anillo de Corosync?
• ¿Está la interfaz de red del clúster arriba, con VLAN/MTU correctos y sin firewall que bloquee?
• ¿La hora es razonable?

2) Segundo: comprueba quórum y membresía desde un nodo sano

• Si el clúster tiene quórum en otro lado, el nodo “no en clúster” es el problema.
• Si el clúster no tiene quórum, no “reúnas” nada aún. Estabiliza el quórum primero.

3) Tercero: decide la vía de recuperación

• Pista A (mejor): la identidad del nodo sigue siendo válida; arregla red/hora/Corosync y se reincorpora automáticamente.
• Pista B (común): el nodo fue eliminado o su estado divergió; debes borrarlo y añadirlo usando pvecm delnode y luego pvecm add.
• Pista C (peor): split brain o estados de clúster en conflicto; debes elegir una “fuente de verdad” y limpiar cuidadosamente el otro lado.

Regla operativa corta: si aún tienes VMs ejecutándose en el nodo afectado, trátalo como un dominio de falla separado hasta confirmar la membresía del clúster. Evita acciones de HA que puedan arrancar cargas duplicadas.

Cómo funciona el clustering de Proxmox (las partes que importan)

Corosync: el oráculo de membresía

Corosync es la capa de comunicaciones del clúster. Decide quién está en el club. También aplica la política de quórum: si hay menos votos de los requeridos, el clúster se vuelve conservador. El clúster puede seguir ejecutando cargas existentes, pero las operaciones del plano de control pueden bloquearse o quedar en solo lectura.

Cuando Corosync está caído o no puede comunicarse, los servicios de Proxmox se ven forzados a una postura de “no puedo verificar el estado”. Ahí es donde suele originarse “node not in cluster”.

pmxcfs: tu configuración es un sistema de archivos replicado

pmxcfs provee /etc/pve. Allí están las configuraciones de VMs, definiciones de almacenamiento, reglas de firewall y metadatos del clúster. No es solo un directorio que editas; es una máquina de estados distribuida vestida de sistema de archivos.

Si /etc/pve no está montado (o está montado pero bloqueado), verás síntomas extraños:

• Archivos de configuración de VMs “faltantes” aunque las VMs aún existan en disco.
• La interfaz mostrando estado del clúster obsoleto o vacío.
• Ediciones a la configuración del clúster que fallan o revierten.

Quórum: por qué dos nodos son una trampa a menos que lo planifiques

En un clúster de tres nodos, perder uno normalmente deja quórum. En un clúster de dos nodos, perder cualquiera de los nodos suele hacer perder el quórum a menos que añadas un dispositivo de quórum (qdevice) o aceptes restricciones. No es que Proxmox sea dramático; es matemáticas.

Verdad seca y graciosa: un clúster de dos nodos sin tercer votante es como una reunión con dos ejecutivos y sin acta; quien hable último cree tener la razón.

Split brain: el modo de fallo que debes evitar

Split brain significa que dos mitades del clúster creen ser autoritarias. Si ambos escriben al almacenamiento compartido o ambos arrancan la misma VM, obtienes corrupción de datos o duplicados. El comportamiento de quórum de Proxmox intenta evitar esto con ahínco. Tu trabajo no es engañarlo con “parches temporales”.

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas concretas que puedes ejecutar. Cada una incluye (1) un comando, (2) qué significa una salida plausible y (3) qué decisión tomar después. Ejecútalas en el nodo afectado y al menos en un nodo sano cuando sea posible.

Task 1: Confirmar cómo Proxmox cree que se llama el nodo

cr0x@server:~$ hostnamectl --static
pve03

Significado: Proxmox espera que el nombre del nodo coincida con la configuración del clúster. Si el clúster conoce este nodo como pve03 pero tu host ahora se llama pve3, has creado una nueva identidad.

Decisión: Si el hostname cambió, arréglalo de vuelta al nombre conocido por el clúster antes de hacer cualquier otra cosa.

Task 2: Validar la resolución de nombres (el tráfico del clúster a menudo usa nombres)

cr0x@server:~$ getent hosts pve01 pve02 pve03
10.10.10.11   pve01
10.10.10.12   pve02
10.10.10.13   pve03

Significado: Los nombres resuelven a las IPs del anillo esperadas. Si esto está mal (IPs antiguas, subnet equivocada), la membresía de Corosync se rompe.

Decisión: Corrige DNS o la consistencia de /etc/hosts en todos los nodos; no lo remiendes solo en uno.

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

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

Significado: Si ves pmxcfs, el sistema de archivos del clúster está montado. Si no, Proxmox opera “a ciegas”.

Decisión: Si no está montado, céntrate en Corosync y el estado del servicio pve-cluster a continuación.

Task 4: Comprobar los servicios pve-cluster y Corosync

cr0x@server:~$ systemctl status pve-cluster corosync --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running)
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: failed (Result: exit-code)

Significado: Corosync falló: no hay vista de membresía, probablemente sin quórum. pve-cluster puede seguir corriendo localmente pero sin un estado de clúster válido.

Decisión: Inspecciona los logs y la configuración de Corosync; no saltes a “reunir” aún.

Task 5: Leer los logs de Corosync para ver el error real

cr0x@server:~$ journalctl -u corosync -b --no-pager | tail -n 25
Dec 25 10:11:12 pve03 corosync[1321]: [TOTEM ] Token has not been received in 2730 ms
Dec 25 10:11:12 pve03 corosync[1321]: [TOTEM ] A processor failed, forming new configuration.
Dec 25 10:11:14 pve03 corosync[1321]: [KNET  ] link: host: 2 link: 0 is down
Dec 25 10:11:15 pve03 corosync[1321]: [MAIN  ] Corosync Cluster Engine exiting with status 1

Significado: Falla de ruta de red (knet link down) o pérdida severa de paquetes/desajuste de MTU. A Corosync no le gustan las redes inestables.

Decisión: Valida la interfaz de red, MTU, etiquetado VLAN y el firewall. No toques la membresía del clúster hasta que los paquetes fluyan.

Task 6: Confirmar conectividad del anillo de Corosync (ICMP no es suficiente, pero ayuda)

cr0x@server:~$ ping -c 3 10.10.10.11
PING 10.10.10.11 (10.10.10.11) 56(84) bytes of data.
64 bytes from 10.10.10.11: icmp_seq=1 ttl=64 time=0.356 ms
64 bytes from 10.10.10.11: icmp_seq=2 ttl=64 time=0.331 ms
64 bytes from 10.10.10.11: icmp_seq=3 ttl=64 time=0.342 ms

--- 10.10.10.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2034ms

Significado: La conectividad básica existe. Si ping falla, el clúster no puede funcionar. Si ping tiene éxito pero Corosync falla, revisa MTU, firewall o asimetrías.

Decisión: Si ping está bien, prueba MTU y comportamiento UDP a continuación.

Task 7: Comprobar consistencia MTU (asesino silencioso para knet)

cr0x@server:~$ ip -br link show
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eno1             UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr0            UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr1            UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>

cr0x@server:~$ ip link show vmbr1 | grep -E 'mtu|state'
2: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Significado: Si este nodo usa MTU 9000 pero el switch o los pares usan 1500, obtienes comportamiento “funciona a veces” que Corosync penaliza.

Decisión: Haz el MTU uniforme de extremo a extremo. Si no puedes garantizar jumbo frames, mantén 1500.

Task 8: Verificar sincronización horaria (la autenticación y timeouts de Corosync odian la deriva)

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

Significado: “synchronized: yes” es lo que quieres. Si está “no”, arregla NTP antes de culpar a Corosync.

Decisión: Restaura NTP (chrony/systemd-timesyncd) y vuelve a comprobar la membresía.

Task 9: Comprobar estado del clúster desde un nodo sano (vista autorizada)

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

Quorum information
------------------
Date:             Thu Dec 25 10:15:10 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.6
Quorate:          Yes

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

Significado: El clúster está sano en otro lado. El nodo con problemas está fuera de la membresía.

Decisión: Centra la solución en la configuración/red del nodo problemático en lugar de hacer cirugía a todo el clúster.

Task 10: Comprobar la lista de membresía y si el nodo está “conocido”

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 pve01
0x00000002          1 pve02
0x00000003          1 pve03

Significado: Si el clúster aún lista el nodo, debería poder reincorporarse sin eliminarlo, suponiendo que la identidad coincida y la red funcione.

Decisión: Si el nodo falta aquí, probablemente necesites pvecm add después de limpiar.

Task 11: Inspeccionar la configuración local de Corosync en el nodo con problemas

cr0x@server:~$ grep -E 'cluster_name|ring0_addr|nodeid|bindnetaddr' -n /etc/pve/corosync.conf
2:  cluster_name: prod-cluster
12:     bindnetaddr: 10.10.10.0
18:         ring0_addr: pve01
23:         nodeid: 1
28:         ring0_addr: pve02
33:         nodeid: 2
38:         ring0_addr: pve03
43:         nodeid: 3

Significado: Los IDs de nodo y las direcciones del anillo deben coincidir con lo que el clúster espera. Si este archivo falta o difiere, no estás viendo la misma realidad del clúster.

Decisión: Si el archivo difiere del /etc/pve/corosync.conf de un nodo sano, tienes deriva de configuración o /etc/pve no está correctamente montado.

Task 12: Verificar que exista la clave de autenticación de Corosync y que coincida (solo si sabes que debería)

cr0x@server:~$ ls -l /etc/corosync/authkey
-r-------- 1 root root 128 Dec 10 09:02 /etc/corosync/authkey

Significado: Authkey ausente = no puede autenticar tráfico del clúster. Clave equivocada = no puede unirse.

Decisión: Si el nodo fue reinstalado o reconstruido parcialmente, puede tener una clave distinta; deberías reañadir el nodo correctamente en lugar de copiar claves a ciegas.

Task 13: Ver si el nodo cree que está en un clúster en absoluto

cr0x@server:~$ test -f /etc/pve/.members && echo "members file exists" || echo "members file missing"
members file exists

Significado: La presencia sugiere que existen metadatos del clúster, pero pueden estar obsoletos o en solo lectura.

Decisión: Si /etc/pve no está montado pero este archivo existe, podrías estar viendo un estado local antiguo; resuelve primero los problemas de servicio/montaje.

Task 14: Comprobar si /etc/pve está en solo lectura (síntoma de pérdida de quórum)

cr0x@server:~$ touch /etc/pve/test-write 2>&1 || true
touch: cannot touch '/etc/pve/test-write': Read-only file system

Significado: No tienes quórum desde la perspectiva de este nodo, o pmxcfs está protegiendo el estado.

Decisión: No fuerces cambios. Arregla el quórum/membresía primero. Si esto es una situación de supervivencia de nodo único, puedes ajustar temporalmente las expectativas de quórum (con cuidado y con un plan para revertir).

Task 15: Confirmar que el firewall no bloquee el tráfico de Corosync

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

cr0x@server:~$ iptables -S | grep -E 'DROP|REJECT' | head
-A INPUT -j PVEFW-INPUT
-A PVEFW-INPUT -j DROP

Significado: Si el firewall está activado y las reglas son estrictas, el tráfico UDP de Corosync puede ser descartado.

Decisión: Confirma que la red del clúster esté en una zona de confianza o permite explícitamente Corosync. No desactives el firewall de forma permanente; arregla las reglas.

Task 16: Confirmar que Ceph (si se usa) no sea el verdadero incidente

cr0x@server:~$ ceph -s
cluster:
  id:     7d2c1c2a-9b9c-4e5b-9a65-1f9b6c1a1b11
  health: HEALTH_WARN
          1 osds down

services:
  mon: 3 daemons, quorum a,b,c
  mgr: x(active), standbys: y
  osd: 12 osds: 11 up, 12 in

Significado: Un nodo que sale del clúster de Proxmox puede coincidir con advertencias de Ceph, pero el quórum de Ceph puede seguir estando bien. Separa la membresía del plano de control de la salud del plano de almacenamiento.

Decisión: Arregla primero la membresía del clúster si necesitas la gestión centralizada; arregla la recuperación de OSD de Ceph en paralelo si está afectando al I/O.

Segundo chiste corto (solo tienes dos): Si tu primera idea es “reinstalar el nodo”, felicidades—has inventado la versión TI de apagar y encender con una grúa.

Listas de verificación / plan paso a paso: reincorporar correctamente, según lo que haya pasado

No existe un único procedimiento de “reunión”. Hay tres, y solo uno es seguro para tu situación. Elige según los hechos que verificaste arriba.

Plan 0: Detener y proteger las cargas (haz esto siempre primero)

• Identifica si hay VMs/CT ejecutándose en el nodo afectado y si usan almacenamiento compartido (Ceph, NFS, iSCSI, ZFS compartido).
• Si HA está habilitado, considera desactivar temporalmente las acciones de HA para los servicios afectados mientras estabilizas la membresía para evitar arranques duplicados.
• Si el nodo está aislado pero sigue ejecutando cargas, trátalo como “degradado y autónomo”. No permitas que otro nodo inicie las mismas cargas.

Plan A: El nodo sigue en la membresía del clúster, solo desconectado (mejor caso)

Usar cuando: el quórum del clúster está sano en otro lado; pvecm nodes lista el nodo; y la identidad del nodo (hostname, mapeo IP, authkey) no ha cambiado.

1. Arregla la red: VLAN/MTU/bonding, puertos del switch, reglas de firewall.
2. Arregla la sincronización de hora.
3. Reinicia Corosync y pve-cluster en el nodo afectado, en ese orden si Corosync estaba caído.

cr0x@server:~$ systemctl restart corosync
cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Quorate:          Yes

Significado: Si pasa a quorate y la membresía vuelve, has terminado. Ahora valida almacenamiento y estado de HA.

Decisión: Si Corosync no arranca o sigue sin poder unirse, detente y pasa al Plan B o C según lo que descubras.

Plan B: El nodo debe ser añadido de nuevo limpiamente (común tras reinstalación o deriva de identidad)

Usar cuando: el clúster está sano en otro lado, pero el estado del nodo en el clúster está obsoleto, ausente o desajustado (reinstalación del SO, authkey nuevo, hostname cambiado, IPs cambiadas).

Paso 1: En un nodo sano, elimina la entrada de membresía muerta (si existe)

cr0x@server:~$ pvecm delnode pve03
Removed node pve03 from cluster

Significado: Esto elimina los metadatos de membresía del clúster para ese nodo. No borra mágicamente sus discos, pero cambia el estado del clúster.

Decisión: Si la eliminación falla por falta de quórum, no forces; restaura el quórum primero.

Paso 2: Limpiar la configuración del clúster en el nodo que vas a reincorporar (sé preciso)

Esta es la parte que la gente apresura y luego lamenta. Estás eliminando la antigua identidad del nodo para que pueda unirse como miembro nuevo.

cr0x@server:~$ systemctl stop pve-cluster corosync
cr0x@server:~$ rm -f /etc/corosync/corosync.conf
cr0x@server:~$ rm -f /etc/corosync/authkey
cr0x@server:~$ rm -rf /etc/pve/corosync.conf /etc/pve/nodes /etc/pve/.members
cr0x@server:~$ systemctl start pve-cluster

Significado: Estás borrando archivos locales de identidad del clúster. Esto no debería eliminar discos de VMs. Puede dejar huérfanas configuraciones locales de VMs si solo estaban en /etc/pve y no respaldadas en otro sitio—confirma primero dónde viven las configs de VM.

Decisión: Si el nodo aloja configs de VM únicas no replicadas que necesitas, detente y haz copia de seguridad de /etc/pve antes de borrar nada.

Paso 3: Unirse al clúster desde el nodo que añades

cr0x@server:~$ pvecm add 10.10.10.11
Please enter superuser (root) password for '10.10.10.11':
Establishing API connection with host '10.10.10.11'
The authenticity of host '10.10.10.11' can't be established.
Fingerprint: SHA256:0mJ0QwqN7ZpVtJcXxq0b3oYzYl6s9Qx9fYqVQ4oSx2s
Are you sure you want to continue connecting (yes/no)? yes
Successfully added node 'pve03' to cluster.

Significado: Proxmox copió la configuración/auth material de Corosync correcta y registró el nodo.

Decisión: Verifica inmediatamente la membresía y el quórum desde ambos lados.

Paso 4: Verificar el estado después de unirse

cr0x@server:~$ pvecm status | grep -E 'Name:|Quorate:|Nodes:'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes

Significado: El plano de control volvió. Ahora debes validar montajes de almacenamiento, configuraciones de VM y trabajos de replicación.

Plan C: Split brain o estados de clúster en conflicto (la cirugía cuidadosa)

Usar cuando: sospechas que existen dos estados de clúster independientes: por ejemplo, alguien ejecutó pvecm create en el nodo aislado, o se restauró /etc/pve desde una copia en un lado sin coordinación.

Cómo se ve esto en la práctica:

• Mismo nombre de clúster, diferentes IDs de nodo.
• Los nodos aparecen duplicados o con IDs extraños.
• Los logs de Corosync mencionan versiones de configuración incompatibles o fallos de autenticación persistentes incluso con la red correcta.
• /etc/pve/corosync.conf difiere entre nodos cuando no debería.

El enfoque seguro: elige una fuente de verdad (el lado con quórum y el estado más consistente). Luego trata al otro lado como un nodo que debe ser reañadido (Plan B) después de asegurar que las cargas en ese lado estén detenidas o aisladas de forma segura.

En escenarios de split brain, también debes tener en cuenta el almacenamiento compartido:

• Si ambos lados pueden escribir en el mismo datastore, detente. Asegura que solo un lado esté activo sobre el almacenamiento compartido.
• Si usas Ceph, confirma el quórum de MONs y asegura que el nodo aislado no esté creando un segundo clúster de Ceph.
• Si usas replicación ZFS, confirma los GUIDs de dataset y la dirección de replicación antes de reactivar trabajos.

Plan C es donde el control de cambios paga las cuentas. Si puedes programar downtime, hazlo. Si no puedes, al menos acuerda silencio de todos excepto la persona con el teclado.

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

1) Síntoma: “node not in cluster” tras un reinicio; los otros nodos están bien

Causa raíz: Corosync no pudo enlazar la interfaz correcta tras un cambio de red (cambio de nombre del bridge, reordenamiento de bond, VLAN no subida a tiempo).

Solución: Verifica las direcciones del anillo y que las interfaces estén listas; corrige /etc/network/interfaces o systemd-networkd; reinicia Corosync; confirma que los logs muestran membresía.

2) Síntoma: /etc/pve está montado en solo lectura

Causa raíz: Sin quórum (a menudo un clúster de dos nodos con uno caído) o el nodo no ve suficientes pares.

Solución: Restaura el quórum trayendo nodos de vuelta o añadiendo un dispositivo de quórum; no fuerces escrituras. Si debes operar temporalmente como nodo único, hazlo con estrategia de quórum explícita y un plan para revertir.

3) Síntoma: Logs de Corosync muestran “token has not been received” y knet link se cae

Causa raíz: Pérdida de paquetes en la red, desajuste de MTU o filtrado del firewall del tráfico UDP entre pares del clúster.

Solución: Haz MTU consistente, arregla switch/VLAN, permite tráfico de Corosync, evita enrutar el tráfico del clúster por firewalls “inteligentes” que hagan cosas stateful raras.

4) Síntoma: Nodo fue reinstalado y ahora no puede unirse; errores de autenticación

Causa raíz: La instalación nueva tiene una authkey de Corosync diferente y posiblemente un hostname/clave SSH diferente. Es un nodo distinto aunque el hardware sea el mismo.

Solución: Elimina la entrada antigua del nodo del clúster, limpia la identidad del nodo en la instalación nueva y añádelo de nuevo con pvecm add.

5) Síntoma: El clúster muestra nodos duplicados o IDs extraños

Causa raíz: Split brain o copia manual de archivos en /etc/pve; bases de datos de membresía en conflicto.

Solución: Elige una fuente de verdad del clúster y reañade los demás limpiamente. No intentes fusionar manualmente salvo que disfrutes la arqueología.

6) Síntoma: La GUI muestra clúster pero la CLI dice no quórum (o viceversa)

Causa raíz: Cache de UI obsoleta, montaje parcial de pmxcfs o servicios reiniciados en orden incorrecto.

Solución: Confía en la CLI (pvecm status, journalctl). Reinicia servicios en orden controlado; confirma montaje de /etc/pve y estado de lectura/escritura.

7) Síntoma: Todo funcionó hasta que alguien “optimizó” la red del clúster

Causa raíz: Jumbo frames habilitados en algunos puertos pero no en todos; cambio en hashing de LACP; cambios en offload; o la red del clúster movida detrás de un appliance firewall.

Solución: Haz la red del clúster aburrida: MTU consistente, middleboxes mínimos, latencia estable. Pon la sofisticación en otro lugar.

Tres minicedas del mundo corporativo (anonimizadas, plausibles y dolorosamente familiares)

Minicrónica 1: El incidente causado por una suposición equivocada

Tenían un clúster Proxmox de tres nodos en una oficina regional, ejecutando una mezcla de VMs Windows y un par de appliances Linux. Un día, un nodo quedó muerto. Facilities dijo que fue “solo un ciclo de energía”. El administrador junior asumió que el nodo se reincorporaría al arrancar.

Arrancó, pero Proxmox mostró “node not in cluster”. El administrador hizo lo que mucha gente hace bajo presión: copió /etc/pve/corosync.conf desde un nodo sano al nodo roto y reinició servicios. Pareció mejor durante unos cinco minutos. Luego Corosync empezó a oscilar.

La suposición equivocada fue sutil: creyeron que /etc/pve era un sistema de archivos normal. No lo era. Su copia aterrizó en un lugar gestionado por pmxcfs, y el estado de pmxcfs del nodo no estaba sano aún. Básicamente pegaron una configuración sobre un objetivo en movimiento.

Lo que lo arregló fue aburrido: revertieron la copia manual, verificaron la red del anillo y encontraron que el puerto del switch había sido movido a otra VLAN durante un trabajo no relacionado. Una vez corregida la VLAN y confirmada la sincronización horaria, el nodo se reincorporó sin cirugía de membresía.

La conclusión del postmortem fue clara: trata “node not in cluster” primero como un problema de conectividad y quórum, no como un problema de archivos. Un clúster es un sistema, no una carpeta.

Minicrónica 2: La optimización que salió mal

Una empresa mediana decidió que la red del clúster Proxmox debía ser “rápida”. Alguien habilitó MTU 9000 en la VLAN de almacenamiento y pensó, por qué no también en el anillo de corosync. La mitad de los switches soportaban jumbo frames de extremo a extremo, la otra mitad “más o menos”, y un par de NICs antiguas necesitaban ajustes de drivers.

No explotó de inmediato. Así empiezan estas historias. En unas semanas, hubo cambios intermitentes en la membresía del clúster. Cortos. Un nodo caía, volvía, caía otra vez. HA dudaba. Los logs mencionaban tokens faltantes. Todos culparon a “Proxmox inestable”.

El revés fue que el patrón de tráfico de Corosync no le importa tu ancho de banda teórica; le importa la predictibilidad. La inconsistencia de jumbo frames introdujo micro-bursts y caídas ocasionales que el tráfico de aplicaciones ordinarias no notaba. Corosync sí lo notó. Y ruidosamente.

Lo arreglaron volviendo la red de Corosync a MTU 1500 y dejando jumbo frames solo donde podían garantizar soporte end-to-end (y donde tenía un impacto medible). El clúster volvió a ser aburrido. El rendimiento cambió poco. El tiempo de actividad sí mejoró.

Minicrónica 3: La práctica aburrida pero correcta que salvó el día

Otra organización ejecutaba un clúster Proxmox de cinco nodos con Ceph y control de cambios estricto. Cada cambio de red incluía una lista de chequeo previa: confirmar resolución de nombres, confirmar sincronización NTP, confirmar alcanzabilidad del anillo de Corosync, confirmar pvecm status quórate y registrar la versión actual de corosync.conf.

Una tarde, un reboot de switch provocó una corta interrupción en la red del clúster. Un nodo volvió mostrando “node not in cluster”. El equipo no improvisó. Sacaron la checklist.

Vieron de inmediato que la sincronización horaria en el nodo afectado estaba rota: NTP quedó colgado porque la ruta por defecto cambió durante el arranque y no podía alcanzar los servidores NTP. El reloj derivó lo suficiente como para que la autenticación y los timeouts de Corosync se fueran al garete. Arreglar el routing y NTP restauró la membresía limpiamente.

Nadie “reunió” nada. Nadie eliminó estado del clúster. Nadie copió archivos por todos lados. La mejor respuesta a incidentes a veces es negarse a entrar en pánico y tener las evidencias de lo que cambió.

Preguntas frecuentes

1) ¿“node not in cluster” significa que mis VMs se perdieron?

No. Significa que el plano de control no puede validar el estado del clúster. Los discos de VM suelen estar en almacenamiento local, compartido o Ceph; no se evaporan porque Corosync esté disgustado. Pero las configuraciones de VM almacenadas en /etc/pve pueden no ser visibles si pmxcfs no está montado.

2) ¿Puedo simplemente ejecutar pvecm add y listo?

Sólo si estás seguro de que el nodo fue eliminado limpiamente o es una instalación nueva que quieres añadir. Si el clúster aún cree que el nodo existe, unirse sin limpieza puede crear conflictos. Verifica con pvecm nodes desde un nodo sano primero.

3) ¿Cuál es la acción inicial más segura cuando esto ocurre?

Comprueba quórum y el estado de Corosync desde un nodo sano. Si el clúster está quórate, tu problema es localizado. Si no lo está, arregla el quórum antes de hacer algo destructivo.

4) ¿Por qué /etc/pve a veces pasa a solo lectura?

Porque Proxmox se niega a aceptar escrituras cuando la membresía del clúster no es confiable (a menudo por pérdida de quórum). Esto previene split brain y divergencia de configuración.

5) ¿Cómo manejar esto en un clúster de dos nodos?

O añades un tercer votante (qdevice) o aceptas que perder un nodo probablemente haga perder quórum. Los clústeres de dos nodos pueden funcionar, pero debes diseñar para la matemática del quórum en lugar de discutir con ella durante incidentes.

6) ¿Es seguro copiar corosync.conf desde otro nodo?

Normalmente no. Si pmxcfs está sano y el clúster está sano, la configuración ya está replicada. Si pmxcfs no está sano, copiar archivos puede empeorar la divergencia. Usa pvecm add para distribuir de forma controlada después de limpiar estado cuando sea necesario.

7) Después de reunirme, ¿por qué faltan mis almacenamientos en la UI?

Porque las definiciones de almacenamiento están en la configuración del clúster (/etc/pve/storage.cfg). Si pmxcfs no está montado o te uniste incorrectamente, el nodo puede no tener la configuración replicada. Verifica el montaje de /etc/pve y compara storage.cfg entre nodos.

8) ¿Ceph complica la reincorporación de un nodo Proxmox?

Complica el radio de explosión, no las mecánicas centrales de reincorporación. La membresía del clúster de Proxmox es un sistema; Ceph es otro. Debes asegurarte de que el nodo no cause doble montaje u OSDs en conflicto, pero sigues arreglando Corosync/quórum primero.

9) ¿Y si el nodo fue renombrado y quiero conservar el nombre nuevo?

No renombres in situ esperando que el clúster te siga. Elimina el nodo del clúster, limpia su estado de clúster, establece el nuevo hostname de forma consistente y añádelo de nuevo como miembro. Planifica el impacto en las configuraciones de VM y en la monitorización.

10) ¿Cuándo es realmente apropiado reinstalar?

Cuando el SO está comprometido, irremediablemente mal configurado o no puedes confiar en el estado del nodo —y tienes un proceso limpio para eliminar/añadir nodos. Reinstalar como primera respuesta suele ser impaciencia disfrazada de decisión.

Próximos pasos que deberías hacer realmente

Si tienes ahora mismo un ticket de incidente, haz esto en orden:

1. Establece el estado de quórum desde un nodo sano con pvecm status. Si no hay quórum, arregla quórum antes de “reunir”.
2. En el nodo con problemas: confirma hostname, resolución de nombres, sincronización horaria y que /etc/pve esté montado.
3. Lee los logs de Corosync. Rara vez son poéticos, pero suelen ser honestos.
4. Arregla los problemas de red aburridos: desajuste MTU, etiquetado VLAN, drops de firewall, cambios de nombre de interfaz.
5. Elige el plan de recuperación correcto:
   • Plan A si la identidad está intacta y el nodo sigue listado.
   • Plan B si la identidad está obsoleta (reinstalado/renombrado/clave nueva).
   • Plan C si sospechas split brain: elige una fuente de verdad y reañade con cuidado.
6. Después de recuperar: valida el almacenamiento, el estado de HA y los trabajos de replicación. No declares victoria hasta que las comprobaciones aburridas pasen.

Luego hazle un favor a tu yo futuro:

• Documenta la red del clúster (interfaces, VLANs, MTU, zonas de firewall) y hazla intencionalmente aburrida.
• Si operas dos nodos, añade un dispositivo de quórum o acepta explícitamente las limitaciones operativas.
• Practica el procedimiento de eliminar/añadir en un laboratorio una vez. Los incidentes no son el mejor momento para aprender qué es pmxcfs.