Proxmox “cannot initialize CMAP service”: Lista de verificación para solucionar Corosync/pmxcfs

El error aparece en el peor momento: reiniciaste un nodo (o se reinició solo) y ahora el clúster parece “medio vivo”.
pve-cluster no funciona correctamente, /etc/pve está vacío o en solo lectura, y los registros de corosync repiten:
cannot initialize CMAP service.

Esta es una de esas fallas de Proxmox donde almacenamiento, red y sistemas distribuidos votan al mismo tiempo. Si solo escuchas a uno de ellos,
no arreglarás nada y aprenderás nuevas malas palabras. Abajo hay una lista de verificación digna de entornos de producción: diagnóstico rápido primero, luego
aislamiento sistemático y finalmente recuperación segura.

Qué significa realmente “cannot initialize CMAP service”

CMAP es la base de datos interna de configuración y estado en tiempo de ejecución de corosync. Piénsalo como “la interfaz de memoria compartida del clúster”
para ajustes y estado: IDs de nodo, pertenencia al anillo, bits de quórum, temporización de totem, registros, y más. Cuando un proceso dice que cannot initialize CMAP service,
está fallando al conectar con la API CMAP de corosync—habitualmente porque corosync no se está ejecutando, está bloqueado, se está reiniciando o sus sockets IPC no son accesibles.

En clústeres Proxmox, esto suele aparecer en estos patrones:

• Corosync está caído → pve-cluster no puede leer la pertenencia al clúster → /etc/pve se comporta de forma extraña.
• Corosync no puede formar un anillo (red/MTU/firewall) → sin quórum → el sistema de archivos del clúster puede quedar en solo lectura o no montarse.
• Desajuste de configuración de corosync o nombre/IP de nodo incorrectos → corosync arranca pero no puede unirse a los pares → CMAP no es utilizable para los demonios dependientes.
• Deriva temporal o bloqueos de planificación extremos → timeouts de token → fluctuaciones de pertenencia → los consumidores de CMAP fallan intermitentemente.

La traducción práctica: trata los errores de CMAP como “corosync no está lo bastante sano para proporcionar estado de ejecución del clúster.” Arregla primero la salud de corosync, luego pmxcfs,
y solo entonces toca los servicios de nivel superior de Proxmox.

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

Primero: decide si tienes un problema de clúster o un problema de nodo único

La victoria más rápida es saber si estás depurando un fallo de un demonio local o una situación de cerebro dividido / quórum.
Ejecuta estos tres comandos en el nodo roto y en uno sano (si tienes uno).

cr0x@server:~$ systemctl is-active corosync pve-cluster
inactive
active

Significado: Si corosync está inactivo/fallado, los errores CMAP son un síntoma, no la enfermedad.
Si corosync está activo pero los consumidores aún se quejan, buscas problemas de anillo/quórum/configuración.
Decisión: Arregla corosync primero. No reinicies pvedaemon, pveproxy ni servicios al azar “a ver qué pasa.”

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

Quorum information
------------------
Date:             Thu Dec 25 12:07:21 2025
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.52
Quorate:          No

Significado: “Quorate: No” es el titular. Sin quórum, pmxcfs puede rechazar escrituras y algunas operaciones de clúster fallarán.
Decisión: Determina si los nodos faltantes están realmente caídos, aislados por la red o mal configurados. No fuerces quórum a la ligera.

cr0x@server:~$ journalctl -u corosync -b --no-pager | tail -n 40
Dec 25 12:05:12 pve1 corosync[1789]:   [TOTEM ] A processor failed, forming new configuration.
Dec 25 12:05:14 pve1 corosync[1789]:   [KNET  ] link: host: 2 link: 0 is down
Dec 25 12:05:18 pve1 corosync[1789]:   [QUORUM] Members[1]: 1
Dec 25 12:05:18 pve1 corosync[1789]:   [QUORUM] This node is within the non-primary component and will NOT provide any services.

Significado: Esto es una partición de red clásica o un par muerto. KNET dice que el enlace está caído.
Decisión: Olvídate de CMAP y piensa en la red de corosync: enrutamiento, VLANs, MTU, firewall, estado del enlace.

Segundo: demuestra que la ruta de red del clúster está limpia (no solo “ping funciona”)

Corosync usaba multicast en configuraciones antiguas y unicast (knet) en Proxmox moderno, típicamente sobre UDP, con temporización estricta.
Una sola regla de firewall, enrutamiento asimétrico o desajuste de MTU puede mantener ICMP feliz mientras corosync falla en silencio.

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.10.11/24
eno2             UP             172.16.20.11/24

Significado: Identifica la(s) interfaz(es) que corosync debería usar. Muchos clústeres dedican una NIC/VLAN para corosync—hasta que alguien “lo simplifica”.
Decisión: Compáralo con /etc/pve/corosync.conf (o una copia local si pmxcfs está inestable) y verifica que la dirección del anillo coincida con la realidad.

Tercero: confirma el estado de pmxcfs y si estás atascado en solo lectura

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

Significado: Si este montaje falta, está obsoleto o está en solo lectura, Proxmox se comportará como si tuviera amnesia.
Decisión: Si corosync está roto, pmxcfs puede no montarse o montarse pero rechazar escrituras. No edites /etc/pve directamente si no está montado correctamente.

Hechos interesantes y contexto histórico (por qué es así)

• El nombre corosync viene de “coros”, una línea de proyectos antigua ligada a comunicación de grupos y pertenencia a clústeres—esto son décadas de cicatrices en sistemas distribuidos.
• CMAP reemplazó enfoques de configuración anteriores para que los demonios puedan leer y reaccionar al estado del clúster mediante una API consistente en lugar de parsear archivos repetidamente.
• El protocolo Totem (usado por corosync) fue diseñado para mantener la entrega ordenada de mensajes y la pertenencia pese a fallos—genial cuando está sano, implacable cuando la temporización falla.
• Proxmox eligió un sistema de archivos FUSE (pmxcfs) para distribuir rápidamente estados pequeños de configuración, no para ser un almacén de datos general.
• pmxcfs guarda la configuración “autorizada” en archivos SQLite/DB bajo /var/lib/pve-cluster/; /etc/pve es la vista montada, no el origen original.
• Las reglas de quórum vienen de la seguridad del consenso clásico: es mejor rechazar escrituras que aceptar actualizaciones en conflicto que no puedas reconciliar después.
• El transporte knet se convirtió en la ruta estándar para mejorar el manejo de enlaces y las capacidades multi-enlace frente a patrones multicast antiguos.
• Muchos “problemas de corosync” son en realidad problemas de reloj: el membership basado en tokens es extremadamente sensible a jitter, starvation de CPU y saltos de tiempo.

Corosync + CMAP + pmxcfs: las piezas que estás depurando

Corosync: pertenencia, mensajería, quórum

Corosync es el motor de pertenencia del clúster. Decide quién está dentro, quién está fuera y cuán seguro está de esa declaración.
Su configuración vive en corosync.conf. Su estado en tiempo de ejecución está detrás de CMAP. Si corosync no puede ejecutarse o estabilizar la pertenencia, todo lo que hay encima
se vuelve decorativo.

CMAP: interfaz de estado en tiempo de ejecución

CMAP es donde corosync expone configuración y estado a clientes. Los componentes de Proxmox y las propias herramientas de corosync lo consultan.
Cuando ves “cannot initialize CMAP service”, el cliente falló al conectar con la interfaz de ejecución de corosync—frecuentemente vía sockets IPC.
Por eso el error puede aparecer incluso en un “clúster” de nodo único después de una actualización o por permisos/SELinux/AppArmor (poco frecuente en Proxmox), o tras un crash que dejó sockets obsoletos.

pmxcfs: el sistema de archivos del clúster Proxmox

pmxcfs es un sistema de archivos FUSE montado en /etc/pve. Es donde Proxmox espera que viva la configuración a nivel de clúster:
definiciones de almacenamiento, configuración de firewall, configuraciones de VM, configuración del clúster, realms de usuario. Depende de corosync para la pertenencia y decisiones de quórum.

Si corosync está caído o no tienes quórum, pmxcfs puede:

• no montarse en absoluto, dejando /etc/pve como un directorio vacío o un montaje obsoleto,
• montarse en solo lectura, provocando fallos de escritura de forma confusa,
• montarse pero mostrar solo el estado local del nodo si estás aislado, según cómo haya ocurrido la falla.

Idea parafraseada de Werner Vogels (CTO de Amazon): Todo falla, todo el tiempo; construye sistemas que lo esperen y se recuperen rápido.

Chiste #1: Corosync es como una invitación a una reunión. Si la mitad de los asistentes no puede conectarse, nadie puede editar la agenda.

Tareas prácticas (comandos, salida esperada, decisiones)

Estas son las tareas que realmente ejecuto cuando alguien escribe “CMAP service” a las 02:00. Cada una incluye lo que significa la salida y qué decisión tomar después.
Ejecútalas en el nodo afectado primero, luego compara con un nodo sano si está disponible.

Tarea 1: Comprobar estados de servicios y fallos recientes

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-25 12:01:03 UTC; 4min ago
       Docs: man:corosync
    Process: 1732 ExecStart=/usr/sbin/corosync -f $COROSYNC_OPTIONS (code=exited, status=1/FAILURE)

Significado: Corosync no se está ejecutando; los errores CMAP son esperables.
Decisión: Ve directo a los logs y a la validación de configuración. No reinicies todo; arregla la primera ficha.

Tarea 2: Leer logs de corosync con contexto, no solo la última línea

cr0x@server:~$ journalctl -u corosync -b --no-pager -n 200
Dec 25 12:00:58 pve1 corosync[1732]:   [CFG   ] Parsing config file '/etc/corosync/corosync.conf'
Dec 25 12:00:58 pve1 corosync[1732]:   [CFG   ] No valid name found for nodeid 1
Dec 25 12:00:58 pve1 corosync[1732]:   [MAIN  ] Corosync Cluster Engine exiting with status 8 at main.c:1835.

Significado: Desajuste de configuración: mapeo nodeid o nodelist equivocado.
Decisión: Valida nodelist, nombres de nodos y direcciones del anillo. No toques aún las opciones de quórum; tienes un error de configuración determinista.

Tarea 3: Confirmar qué corosync.conf estás usando realmente

En un clúster sano, la configuración canónica suele estar bajo /etc/pve/corosync.conf (vista del sistema de archivos del clúster), y corosync lee
/etc/corosync/corosync.conf que normalmente es un enlace simbólico hacia /etc/pve. Cuando pmxcfs está roto, ese enlace puede apuntar al vacío.

cr0x@server:~$ ls -l /etc/corosync/corosync.conf /etc/pve/corosync.conf
lrwxrwxrwx 1 root root 17 Dec 25 11:58 /etc/corosync/corosync.conf -> /etc/pve/corosync.conf
-rw-r----- 1 root www-data 512 Dec 25 11:57 /etc/pve/corosync.conf

Significado: El enlace simbólico es correcto y el archivo existe en /etc/pve.
Decisión: Si /etc/pve/corosync.conf falta o no se puede leer, necesitas restaurarlo desde las bases de datos locales del clúster o desde copias de seguridad.

Tarea 4: Validar la sintaxis de la configuración de corosync

cr0x@server:~$ corosync -t
Parsing of config file successful

Significado: La sintaxis es correcta. Esto no demuestra que la configuración sea correcta; solo que se puede parsear.
Decisión: Si el parseo falla, arregla la sintaxis antes que nada. Si tiene éxito, céntrate en la semántica: IPs, node IDs, enlaces, crypto, MTU.

Tarea 5: Comprobar pertenencia y estado de quórum con herramientas de Proxmox

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

Quorum information
------------------
Nodes:            3
Node ID:          0x00000001
Quorate:          Yes

Significado: Si esto devuelve limpio y dice quorate, CMAP probablemente funciona, y tu error podría venir de un servicio dependiente que arrancó demasiado pronto.
Decisión: Si corosync está sano, pivota a pmxcfs y al orden de arranque de servicios; revisa los logs de pve-cluster.

Tarea 6: Consultar corosync en tiempo de ejecución desde herramientas CMAP directamente

cr0x@server:~$ corosync-cmapctl | head
runtime.config.totem.token (u32) = 3000
runtime.config.totem.token_retransmits_before_loss_const (u32) = 10
runtime.config.totem.consensus (u32) = 3600
runtime.totem.pg.mrp.srp.members (str) = 1 2 3

Significado: Si esto funciona, CMAP es accesible. Si falla con un error de inicialización CMAP, corosync no es accesible vía IPC.
Decisión: Si CMAP es inaccesible pero corosync muestra “active”, sospecha problemas de permisos/sockets, directorio de runtime obsoleto o bucles de reinicio rápido.

Tarea 7: Inspeccionar sockets y permisos de runtime de corosync

cr0x@server:~$ ls -ld /run/corosync /run/corosync/* 2>/dev/null | head
drwxr-xr-x  2 root root  80 Dec 25 12:06 /run/corosync
srwxrwx---  1 root root   0 Dec 25 12:06 /run/corosync/corosync.sock
srwxrwx---  1 root root   0 Dec 25 12:06 /run/corosync/cmap.sock

Significado: Los sockets existen. Si faltan, los clientes CMAP no pueden conectar. Si los permisos son demasiado estrictos, clientes no root pueden fallar.
Decisión: Sockets ausentes → corosync no se está ejecutando realmente o se quedó atascado pronto. Permisos raros → revisa la integridad del paquete y cambios de hardening locales.

Tarea 8: Confirmar salud del montaje de pmxcfs y mensajes de error

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 Thu 2025-12-25 12:03:11 UTC; 3min ago
   Main PID: 2011 (pmxcfs)

Significado: pmxcfs está en ejecución, pero aún podría estar en solo lectura debido a falta de quórum.
Decisión: Verifica el quórum y prueba la capacidad de escritura de forma segura (crea un archivo temporal en un lugar seguro como /etc/pve/nodes/<node>/ si procede).

Tarea 9: Detectar sistema de archivos del clúster en solo lectura (sin adivinar)

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

Significado: pmxcfs está montado pero rechaza escrituras. Eso suele corresponder a falta de quórum o modo de protección local.
Decisión: Restaura el quórum (preferible) o usa una anulación de quórum controlada solo si realmente tienes un único nodo superviviente y aceptas el riesgo.

Tarea 10: Comprobar deriva temporal y salud de NTP

cr0x@server:~$ timedatectl status
Local time: Thu 2025-12-25 12:08:30 UTC
Universal time: Thu 2025-12-25 12:08:30 UTC
RTC time: Thu 2025-12-25 12:08:29
System clock synchronized: yes
NTP service: active

Significado: Bien. Si el reloj no está sincronizado o da saltos, la temporización de tokens de corosync se vuelve peligrosa rápidamente.
Decisión: Si no está sincronizado, arregla NTP/chrony/systemd-timesyncd. Luego reinicia corosync para estabilizar la pertenencia.

Tarea 11: Verificar ruta de red y MTU (porque “ping funciona” miente)

cr0x@server:~$ ping -M do -s 1472 -c 3 172.16.20.12
PING 172.16.20.12 (172.16.20.12) 1472(1500) bytes of data.
1480 bytes from 172.16.20.12: icmp_seq=1 ttl=64 time=0.352 ms
1480 bytes from 172.16.20.12: icmp_seq=2 ttl=64 time=0.339 ms
1480 bytes from 172.16.20.12: icmp_seq=3 ttl=64 time=0.347 ms

Significado: PMTU para tramas de 1500 bytes está bien. Si esto falla pero un ping más pequeño funciona, tienes problemas de MTU/fragmentación.
Decisión: Arregla la consistencia de MTU en switches, bonds, VLANs y NICs. Corosync/knet no tolera pozos negros de fragmentación silenciosos.

Tarea 12: Comprobar reglas de firewall que suelen romper corosync en silencio

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

cr0x@server:~$ iptables -S | grep -E 'corosync|5405|5404|knet' | head

Significado: El firewall de Proxmox está activado. Corosync con knet suele usar UDP y puertos dinámicos; corosync antiguo usaba UDP 5405 por defecto.
El grep vacío no prueba que esté permitido; solo prueba que no etiquetes reglas claramente (lo cual es común).
Decisión: Si activaste firewall recientemente, permite explícitamente el tráfico del clúster en la red dedicada de corosync. También revisa firewalls del host fuera de la herramienta Proxmox.

Tarea 13: Inspeccionar estado de enlace de corosync y alcanzabilidad de peers

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 172.16.20.11
        status  = ring 0 active with no faults

Significado: El anillo local está activo. Si muestra fallos o down, tienes un problema a nivel de enlace o bindnetaddr/direcciones de anillo incorrectas.
Decisión: Si el anillo está defectuoso, verifica que la red correcta se esté usando, revisa el etiquetado VLAN y confirma que las IPs de peer coincidan con la topología física.

Tarea 14: Buscar split brain / particiones múltiples

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1 (local)
         2          1 pve2

Significado: Solo dos nodos visibles. Si esperabas tres, puede que tengas un nodo caído o una partición.
Decisión: Si un nodo está permanentemente perdido, elimínalo de forma ordenada (después de estabilizar). No mantengas un nodo muerto en la configuración “por si acaso.”

Tarea 15: Reinicio de corosync (solo tras tener una hipótesis)

cr0x@server:~$ systemctl restart corosync

cr0x@server:~$ systemctl is-active corosync
active

Significado: El reinicio tuvo éxito. Ahora verifica inmediatamente quórum y acceso a CMAP.
Decisión: Si pasa de active a failed, estás en un bucle de crash—vuelve a logs y a la validación de configuración. No sigas reiniciando; solo agravarás la situación.

Tarea 16: Revisar logs de pve-cluster por pistas específicas de pmxcfs

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager | tail -n 60
Dec 25 12:03:12 pve1 pmxcfs[2011]: [status] notice: cpg_initialize failed: 2
Dec 25 12:03:12 pve1 pmxcfs[2011]: [status] notice: retrying in 1 seconds
Dec 25 12:03:18 pve1 pmxcfs[2011]: [status] notice: resolved node name 'pve1' to '172.16.20.11'

Significado: pmxcfs no puede inicializar su comunicación de grupo corosync (CPG), típicamente porque corosync no está listo o la pertenencia no es estable.
Decisión: Trata esto como otra señal de “primero la salud de corosync”. Arregla el anillo/quórum y entonces pmxcfs dejará de quejarse.

Tarea 17: Verificar que la resolución de nombres del nodo sea estable y coincida con la configuración de corosync

cr0x@server:~$ hostname -f
pve1.prod.example

cr0x@server:~$ getent hosts pve1
172.16.20.11     pve1.prod.example pve1

Significado: El hostname resuelve a la IP del clúster esperada. Si un día resuelve a la red de gestión y al siguiente a la de almacenamiento,
corosync lo pasará mal.
Decisión: Fija entradas correctas en DNS o en /etc/hosts para los nombres del clúster; evita DNS “inteligente” que devuelva diferentes direcciones según el origen.

Tarea 18: Si debes operar sin quórum (controlado, temporal)

Aquí es donde puedes empeorar las cosas con convicción. Haz esto solo si realmente tienes un único nodo superviviente y necesitas acceso a configuraciones
para recuperar cargas. Tan pronto el clúster esté sano otra vez, deshaz la operación.

cr0x@server:~$ pvecm expected 1
expected votes set to 1

Significado: Has dicho al clúster que espere 1 voto, lo que puede restaurar el estado quórum en el nodo único.
Decisión: Úsalo para desbloquearte, no para operar indefinidamente. Si el nodo “faltante” vuelve inesperadamente, ahora estás en tierra de verdades en conflicto.

Chiste #2: Forzar quórum es como hacer tus impuestos con un lanzallamas. Puede funcionar, pero lo olerás después.

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

1) Síntoma: “cannot initialize CMAP service” y corosync aparece como “active”

• Causa raíz: corosync está fluctuando (reinciando), o los sockets IPC bajo /run/corosync faltan/tienen permisos incorrectos.
• Solución: Revisa journalctl -u corosync -b por bucles de crash; verifica que los sockets existan; reinstala/repara paquetes de corosync si hace falta; corrige la semántica de la configuración.

2) Síntoma: /etc/pve está vacío, y la UI de Proxmox muestra rarezas tipo “node has no valid subscription”

• Causa raíz: pmxcfs no está montado (montaje FUSE ausente), a menudo porque pve-cluster falló o corosync no está disponible.
• Solución: Empieza por la salud de corosync, luego reinicia pve-cluster. Verifica el montaje con mount | grep /etc/pve.

3) Síntoma: pmxcfs montado pero en solo lectura; tocar archivos falla

• Causa raíz: sin quórum o nodo aislado en una partición no primaria.
• Solución: Restaura la conectividad del clúster/quórum. Si la pérdida de nodo es permanente, elimina el nodo muerto correctamente y restablece quórum. Solución temporal: pvecm expected 1 solo cuando estés realmente aislado y planificado.

4) Síntoma: Corosync falla con quejas de nodeid/nombre tras un cambio de IP

• Causa raíz: La configuración de corosync aún referencia direcciones de anillo antiguas; el hostname resuelve a una IP distinta de la listada en nodelist.
• Solución: Actualiza las entradas ring0_addr en el nodelist (en la configuración autorizada del clúster), alinea DNS/hosts y reinicia corosync en todos los nodos en orden controlado.

5) Síntoma: Todo funciona hasta que se hacen backups o migraciones, luego corosync fluctúa

• Causa raíz: Starvation de CPU, espera de IO o saturación de red causando timeouts de token. Corosync es sensible al tiempo; la red del clúster puede “estar bien” hasta que no lo está.
• Solución: Mueve el tráfico de corosync a una red/VLAN más tranquila; arregla MTU; reserva CPU (evita oversubscription en el host); investiga bonding/controladores de NIC.

6) Síntoma: Tras un reinicio, el clúster no se forma; los logs mencionan “wrong authkey”

• Causa raíz: authkey desajustada entre nodos, frecuentemente por restauración parcial o copia manual incorrecta.
• Solución: Re-sincroniza la clave de autenticación de corosync entre nodos desde una fuente conocida buena, luego reinicia corosync en todos los nodos.

7) Síntoma: Un clúster de nodo único aún muestra fallos CMAP

• Causa raíz: fallo local del servicio corosync; no es realmente un problema de “clúster”. Causas comunes: archivo de configuración corrupto, estado de paquete dañado, disco fallando o permisos erróneos.
• Solución: Valida la configuración, asegúrate de que existan los directorios de runtime, revisa salud del disco y logs, reinstala corosync si es necesario.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana tenía un clúster Proxmox de tres nodos limpio. “Limpio” aquí significa que funcionaba con suficiente frecuencia como para que nadie se pusiera nervioso.
Durante una ventana de cambios rutinaria, un ingeniero actualizó registros DNS para estandarizar nombres: pve1, pve2, pve3 ahora resolvían a la red de gestión,
no a la red de corosync. La suposición parecía inofensiva: “los nombres deberían apuntar a la interfaz primaria.”

A corosync no le gustó. Tras el reinicio del primer nodo, corosync arrancó, intentó enlazarse y anunciarse en una red, y otros nodos lo esperaban en otra.
Aparecieron timeouts de token, el quórum rebotó y pmxcfs quedó en solo lectura justo cuando una migración de VM estaba en vuelo.
La migración falló de una manera que parecía corrupción de almacenamiento—porque la UI no podía comprometer actualizaciones de configuración de forma fiable.

La solución no fue mágica. Fijaron resolución específica del clúster en /etc/hosts para los nombres usados por corosync, de modo que pve1 siempre mapeara a la dirección del anillo.
También dejaron de usar hostnames “genéricos” para clústeres multinetwork; introdujeron nombres explícitos para tráfico de clúster y tráfico de gestión.
Fue aburrido. Funcionó. La mayor lección fue psicológica: los cambios en DNS son cambios de infraestructura, no “solo limpieza.”

Microhistoria 2: La optimización que salió mal

Otro equipo tenía una VLAN dedicada para corosync y decidió “optimizar” combinándola con la VLAN de almacenamiento para reducir la complejidad de switches.
Su red de almacenamiento era 10GbE y generalmente estable. La suposición: red más rápida = corosync más feliz.
También habilitaron jumbo frames en la red de almacenamiento—porque al almacenamiento le gusta.

Un mes después, empezaron a ver reportes intermitentes de “cannot initialize CMAP service” durante noches de backups intensos.
No de forma continua; solo lo suficiente para crear confusión. Corosync no estaba realmente caído, pero fluctuaba en la pertenencia por unos segundos,
que es todo lo que necesita pmxcfs para lanzar errores y a la gente para entrar en pánico.

El culpable fue una inconsistencia de MTU en un par de puertos de trunk y una configuración de bond en un nodo. Los pings ICMP funcionaban porque eran pequeños.
El tráfico de almacenamiento en su mayoría funcionaba porque TCP retransmitía y seguía adelante. Corosync, usando UDP y asunciones de temporización, sufrió.
La “optimización” creó un modo de fallo que no existía cuando corosync tenía una red pequeña, tranquila y controlada.

La remediación fue separar de nuevo el tráfico de corosync en una VLAN dedicada con MTU=1500 extremo a extremo y limitar el ritmo de dominios de broadcast ruidosos.
No necesitaban una red más rápida. Necesitaban una predecible.

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

Una organización financiera ejecutaba un clúster Proxmox de cuatro nodos. Sin heroísmos. Pero tenían una práctica que parecía anticuada: después de cada cambio en el clúster
(añadir/quitar nodos, cambios de IP, ajustes de corosync), archivaban instantáneas de /etc/pve y /var/lib/pve-cluster en cada nodo,
y mantenían un registro corto de cambios con marcas de tiempo y “por qué”.

Una mañana, el filesystem raíz de un nodo desarrolló errores. El nodo se reinició, corosync falló, luego pmxcfs falló y /etc/pve parecía incorrecto.
El on-call no comenzó a adivinar. Compararon la configuración local archivada de corosync con la actual, vieron que el archivo actual estaba truncado,
y sospecharon inmediatamente corrupción de disco local en lugar de “raruras del clúster.”

Reconstruyeron el nodo limpiamente, lo volvieron a unir con la configuración conocida buena del clúster y restauraron servicios sin empeorar el quórum.
La práctica correcta no fue glamorosa. Redujo el tiempo de decisión cuando todo parecía sospechoso.

Listas de verificación / plan paso a paso

Lista A: Estabilizar corosync primero (haz esto antes de tocar pmxcfs)

1. Confirma salud de servicios.

   cr0x@server:~$ systemctl is-active corosync
   active
   

   Decisión: Si no está activo, lee logs y arregla config/red antes que nada.

2. Valida que la configuración parsea.

   cr0x@server:~$ corosync -t
   Parsing of config file successful
   

   Decisión: Fallo de parseo significa que paras y arreglas sintaxis, no “intentas reiniciar otra vez.”

3. Verifica direcciones de anillo y resolución de nombres.

   cr0x@server:~$ grep -E 'ring0_addr|name|nodeid' -n /etc/pve/corosync.conf | head -n 40
   12:        name: pve1
   13:        nodeid: 1
   14:        ring0_addr: 172.16.20.11
   

   Decisión: Si la IP del anillo no existe en el host, corrige ese desajuste antes de proseguir.

4. Comprueba estado del anillo y fallos.

   cr0x@server:~$ corosync-cfgtool -s
   Printing ring status.
   Local node ID 1
   RING ID 0
           id      = 172.16.20.11
           status  = ring 0 active with no faults
   

   Decisión: Los fallos apuntan a MTU/firewall/enrutamiento/VLAN. Ve allí, no a la UI de Proxmox.

5. Confirma que CMAP responde.

   cr0x@server:~$ corosync-cmapctl totem.cluster_name
   totem.cluster_name (str) = prod-cluster
   

   Decisión: Si la consulta CMAP falla, corosync no está sano. Resuelve eso antes de pmxcfs.

Lista B: Restaurar quórum de forma segura

1. Comprueba estado de quórum.

   cr0x@server:~$ pvecm status | grep -E 'Quorate|Nodes|Node ID'
   Nodes:            2
   Node ID:          0x00000001
   Quorate:          No
   

   Decisión: Si “No”, identifica los votantes faltantes y si realmente son alcanzables.

2. Valida la alcanzabilidad de peers en la red de corosync (no la de gestión).

   cr0x@server:~$ ping -c 3 172.16.20.12
   PING 172.16.20.12 (172.16.20.12) 56(84) bytes of data.
   64 bytes from 172.16.20.12: icmp_seq=1 ttl=64 time=0.301 ms
   64 bytes from 172.16.20.12: icmp_seq=2 ttl=64 time=0.287 ms
   64 bytes from 172.16.20.12: icmp_seq=3 ttl=64 time=0.294 ms
   

   Decisión: Si ping falla, arregla la red. Si ping tiene éxito, aún revisa MTU y firewall.

3. Sólo si un nodo está permanentemente muerto: planifica su eliminación, no lo quites en pánico.

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

   Decisión: Confirma qué nodo está muerto y por qué. Si puede volver, arréglalo en lugar de eliminarlo.

4. Modo de supervivencia temporal (solo un nodo): ajusta expected votes.

   cr0x@server:~$ pvecm expected 1
   expected votes set to 1
   

   Decisión: Úsalo para acceder a configuraciones y recuperar. Deshazlo cuando el quórum normal esté restaurado.

Lista C: Volver a un estado montado sano de pmxcfs

1. Verifica el montaje.

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

   Decisión: Sin montaje, pve-cluster no funciona; revisa sus logs y la salud de corosync.

2. Reinicia pmxcfs solo después de que corosync esté estable.

   cr0x@server:~$ systemctl restart pve-cluster
   

   Decisión: Si inmediatamente da errores con CPG/CMAP, aún no has terminado con corosync.

3. Chequeo de cordura: lista directorios de nodo.

   cr0x@server:~$ ls -1 /etc/pve/nodes
   pve1
   pve2
   pve3
   

   Decisión: Nodos faltantes pueden significar partición, vista sin quórum o inconsistencia de configuración. Contrasta con pvecm nodes.

Preguntas frecuentes (FAQ)

1) ¿Es “cannot initialize CMAP service” un bug de Proxmox?

Usualmente no. Es una señal de salud de corosync. Proxmox lo muestra porque sus componentes dependen del estado en tiempo de ejecución de corosync. Arregla el servicio/ring/quórum subyacente de corosync y los errores CMAP normalmente desaparecen.

2) ¿Puedo reiniciar todo: corosync, pve-cluster, pvedaemon, pveproxy?

Puedes, pero es como reiniciar el detector de humo para apagar un incendio en la cocina. Reiniciar corosync sin entender por qué está descontento puede hacer que la pertenencia fluctúe más, lo que hace que pmxcfs sea más terco y la UI/API más confusa.

3) ¿Por qué /etc/pve actúa como si estuviera vacío o en solo lectura?

Porque es un montaje FUSE proporcionado por pmxcfs. Si pmxcfs no está montado, estás viendo un directorio normal. Si no tienes quórum, pmxcfs puede montarse pero rechazar escrituras.
Verifica siempre el montaje y el estado de quórum antes de editar nada.

4) ¿Cuál es el orden más seguro para reiniciar servicios?

Corosync primero (pero solo después de comprobar config/red). Luego pve-cluster. Luego los demonios de UI/API (pveproxy, pvedaemon) si están fallando.
Empezar desde la cima hace perder tiempo.

5) ¿Necesito multicast para corosync?

La mayoría de clústeres Proxmox modernos usan el transporte knet (unicast). Multicast fue común históricamente pero suele estar bloqueado o mal soportado en redes empresariales.
No persigas multicast a menos que tu configuración lo use explícitamente.

6) ¿Es seguro forzar quórum con pvecm expected 1?

Es una herramienta, no un estilo de vida. Puede ser segura en una situación real de supervivencia de nodo único, cuando entiendes que estás anulando reglas de seguridad
para recuperar manejabilidad. Es inseguro si otros nodos aún pueden estar vivos y escribiendo configuración en conflicto en otro lugar.

7) ¿Los problemas de almacenamiento pueden causar errores CMAP?

Indirectamente, sí. Si el host está en un IO wait severo (disco de arranque muriendo, pool ZFS sobrecargado, OSD de CEPH saturado en el mismo nodo),
corosync puede perder ventanas de temporización, la pertenencia puede fluctuar y los clientes CMAP fallar. A corosync no le impresionan tus gráficas de latencia.

8) ¿Qué pasa si cambié las IPs de la red del clúster?

Espera dolor de corosync hasta que todos los corosync.conf nodelist y la resolución de nombres de cada nodo coincidan. Cambios parciales causan pertenencia asimétrica.
Planifica cambios de IP como una migración: actualiza la configuración de forma consistente, valida MTU, valida firewall y reinicia en orden controlado.

9) ¿Por qué funciona un tiempo tras un reinicio y luego falla otra vez?

Eso es clásico por temporización o jitter de red: timeouts de token, pozos negros de MTU bajo carga o starvation de CPU durante backups. También puede indicar un enlace que fluctúa
(bonding, LACP, puertos de switch). Busca patrones: “falla bajo carga” no es coincidencia.

10) ¿Cómo sé si es una partición vs un nodo muerto?

Compara la salida de pvecm nodes en varios nodos. Si nodos diferentes ven membresías distintas, tienes una partición.
Si todos los nodos sanos coinciden en que falta un nodo y es inalcanzable en la red de corosync, probablemente esté muerto o aislado.

Conclusión: siguientes pasos que no provoquen un segundo incidente

Cuando Proxmox lanza “cannot initialize CMAP service”, no lo trates como un cambio de humor misterioso de Proxmox. Es corosync diciéndote que no puede proporcionar
un estado de ejecución estable. Tu trabajo es estabilizar el anillo, restaurar el quórum y solo entonces esperar que pmxcfs y la UI se comporten.

Pasos prácticos siguientes:

• Ejecuta la guía de diagnóstico rápido: salud de servicios → quórum → red/anillo/MTU → estado de montaje de pmxcfs.
• Recolecta evidencias antes de reiniciar cosas: logs de corosync, estado del anillo, consulta CMAP y estado de sincronización de reloj.
• Arregla primero las causas aburridas: desajustes IP/nombre, inconsistencias de MTU, reglas de firewall y deriva de reloj.
• Si debes forzar quórum, hazlo deliberadamente, documéntalo y deshazlo tan pronto como puedas.
• Tras la recuperación, planifica una mejora: red dedicada para corosync, resolución de nombres consistente y copias de seguridad de configuración confiables.