Hay un punto en cualquier avería de Proxmox donde deja de tener sentido refrescar la web.
Si /etc/pve empieza a comportarse raro, si un nodo parece estar dentro del cluster pero no termina de convencerte, o si el servicio pve-cluster sale activo y aun así todo huele regular, yo dejo de pedirle respuestas a la interfaz. Quiero saber qué viene diciendo pmxcfs de verdad.
Ahí es donde tiro de este comando.
| |
No sustituye a systemctl status pve-cluster --no-pager. Lo completa.
systemctl me dice si el servicio está arriba. El journal me cuenta si esa pieza viene chocándose con Corosync, perdiendo quorum o intentando inicializar subsistemas del cluster sin éxito.
Cuando el problema está en la capa compartida de Proxmox, esa diferencia vale bastante dinero en tiempo y en disgustos.
por qué este comando me parece tan útil justo después de systemctl status pve-cluster#
Porque el estado corto de systemd es buenísimo para una pregunta concreta.
¿Está el servicio levantado?
Perfecto.
Pero con pve-cluster esa respuesta se queda corta más veces de las que me gustaría. Puedes tener el servicio activo y, al mismo tiempo, arrastrar errores feos contra Corosync o contra el propio mecanismo de quorum. El journal es el sitio donde esa contradicción deja de ser invisible.
Y en Proxmox esa contradicción importa mucho.
pve-cluster no es una pieza decorativa. Es el servicio que levanta pmxcfs, el Proxmox Cluster File System. O sea, la capa que sostiene /etc/pve y buena parte de la configuración compartida del cluster.
Si esa base empieza a cojear, lo demás puede tardar un rato en admitirlo, pero la avería ya está dentro.
la captura real que yo querría ver si un nodo empieza a oler mal#
Esta salida sale de un nodo real de mi laboratorio, saneada para no enseñar nombres internos ni detalles que aquí sobran.
Esta sí que no tiene pinta amable.
Aquí no veo un warning simpático. Veo una ráfaga bastante seria.
Aparecen fallos de cmap_dispatch, de quorum_dispatch, de cpg_dispatch, luego varios failed to connect to corosync, después can't initialize service, y finalmente varios CS_ERR_BAD_HANDLE al cerrar o limpiar contexto.
Traducido a lenguaje de persona cansada a las dos de la mañana, lo que yo leo es esto.
pmxcfs está intentando hablar con piezas clave del cluster y no puede hacerlo con normalidad.
Eso ya no es una simple rareza del panel.
lo que me cuentan estas líneas sin necesidad de saber de memoria todas las siglas#
Lo primero que hago es no fingir que disfruto leyendo siglas como cmap, cpg o CS_ERR_LIBRARY.
No hace falta.
No necesito memorizar cada subsistema para entender la historia general. Lo que busco es la dirección del problema.
Y aquí la dirección es bastante clara.
failed to connect to corosync#
Esta es la línea más agradecida de todas porque no intenta ponerse creativa. Si pmxcfs dice que falla al conectar con Corosync, yo dejo de perder tiempo en hipótesis sobre navegador, cookies o caprichos de la interfaz.
Estoy en terreno de cluster.
Corosync es la pieza que mantiene la comunicación de cluster y sostiene, entre otras cosas, la lógica de quorum. Si esa relación se rompe, pmxcfs se queda sin una base fiable para comportarse como filesystem compartido con cara de cluster sano.
Y eso se nota.
quorum_initialize failed#
Esta línea me gusta poco, pero me gusta que exista.
Porque pone nombre al problema. No habla solo de conectividad vaga. Habla del mecanismo de quorum. O dicho de otra forma, la parte que decide si el nodo sigue teniendo base para participar con normalidad en el cluster.
Cuando aquí falla la inicialización, ya me cuesta mucho seguir pensando en un susto superficial.
can't initialize service#
Esto me importa bastante por acumulación.
Una sola línea críptica a veces no significa mucho. Cuando el journal empieza a encadenar failed to connect, initialize failed y can't initialize service, la historia cambia. Ya no es un detalle técnico escondido. Es la secuencia de un arranque o una reconexión que no consigue ponerse de pie.
CS_ERR_BAD_HANDLE#
Estas líneas finales no suelen ser las protagonistas, pero ayudan a leer el tono.
A mí me suenan a limpieza fea después de que lo anterior ya haya salido mal. No las tomo como causa raíz. Las tomo como parte de las consecuencias de una inicialización fallida y un contexto que queda medio roto.
por qué esto me preocupa mucho más que un active (running) bonito#
Porque active (running) solo me dice que el servicio existe y sigue levantado desde el punto de vista de systemd.
No me jura que viva feliz.
No me garantiza que pmxcfs mantenga una relación sana con Corosync.
No me dice que el nodo conserve quorum.
No me dice que /etc/pve esté funcionando fino.
Aquí el journal sí me está enseñando el lado feo. Y se agradece. Prefiero mil veces una verdad áspera a una sensación falsa de normalidad.
Esto es justo lo que hace tan valioso a journalctl -u pve-cluster -n 40 --no-pager. Te enseña la película reciente de una pieza que puede seguir levantada mientras por dentro ya ha empezado a resquebrajarse la parte importante.
una nota clave sobre /etc/pve, no es una carpeta normal#
Esto conviene recordarlo siempre que hablamos de pve-cluster.
/etc/pve no es un directorio corriente del sistema como cualquier otro. Según la documentación de Proxmox, pmxcfs monta ahí un filesystem FUSE con comportamiento específico de cluster. Es una capa compartida, con replicación y reglas muy particulares cuando el nodo pierde ciertas garantías.
Por ejemplo, cuando un nodo pierde quorum, pmxcfs puede pasar a modo solo lectura.
Ese detalle me parece importantísimo porque explica muchos síntomas raros que, vistos desde fuera, parecen tonterías desconectadas. Un cambio de configuración que no guarda. Un archivo que no se comporta como esperabas. Una discrepancia entre nodos. Una sensación rara en la interfaz.
Si el journal de pve-cluster te viene gritando que no puede conectar bien con Corosync, ya no estás tocando una carpeta normal ni una pequeña rareza local. Estás discutiendo con la base compartida del cluster.
Y eso merece bastante respeto.
lo que yo leo en esta captura, sin florituras#
Lo que veo aquí es un nodo que, en ese momento, no puede sostener con normalidad la relación entre pmxcfs y Corosync.
No sé todavía si el origen fue una caída de red, un reinicio mal encadenado, un problema del servicio corosync, una partición temporal o alguna otra joya de infraestructura. Pero sí sé algo útil.
No tocaría configuración compartida alegremente mientras estas líneas estén frescas.
Ese es el tipo de conclusión que quiero sacar pronto.
No cerrar el caso. Solo dejar claras las manos que no pienso meter donde no debo hasta entender mejor el estado del cluster.
errores que evito cometer cuando veo una salida así#
no culpo primero a la web#
Llegados a este punto, la web me da igual. Puede abrir, no abrir o abrir a medias. El problema interesante está bastante más abajo.
no me pongo a editar cosas en /etc/pve como si nada#
Si pmxcfs va mal con Corosync, ponerse a tocar configuración compartida con confianza ciega me parece una receta estupenda para empeorar el día.
no reinicio servicios al azar#
Reiniciar por ansiedad es uno de los clásicos del homelab. A veces ayuda. Otras veces convierte un síntoma en dos. Si el journal ya me está apuntando a Corosync y quorum, prefiero seguir esa línea antes que ir dando manotazos.
no doy por hecho que el nodo está fuera del cluster solo por una línea#
Esto también importa. Una ráfaga fea de journal no sustituye a comprobar estado real de cluster. Me orienta. No me autoriza a sacar conclusiones maximalistas sin mirar más.
cuáles suelen ser mis siguientes pasos después de leer esto#
Cuando veo algo parecido, mi secuencia corta suele ser esta.
systemctl status corosync --no-pagerpvecm statuscorosync-cfgtool -ssystemctl status pve-cluster --no-pager- si sigo con dudas, revisar
journalctl -u corosync
El orden no es casual.
Primero confirmo si el servicio de Corosync sigue vivo.
Después miro quorum y estado de cluster.
Luego compruebo enlaces.
Y vuelvo a pve-cluster con más contexto.
Este comando, por tanto, no me da toda la resolución del caso. Lo que me da es el giro correcto de la historia. Me saca de la capa estética y me mete en la capa real.
lo que diferencia un problema local de uno de cluster aquí#
Este punto me parece muy importante.
Si un nodo tiene un problema local de storage, CPU, disco o una tarea concreta, muchas veces el journal de pvedaemon o de otros servicios te deja pistas más específicas y menos relacionadas con quorum.
Cuando lo que ves son fallos reiterados al hablar con Corosync, inicializaciones fallidas de quorum y errores en pmxcfs, el tono cambia por completo. Ya no pienso en una VM concreta, un backup atascado o un recurso aislado. Pienso en la base que mantiene coherente al cluster.
No es lo mismo.
Y esa distinción, cuando estás cansado, vale oro.
por qué me gusta tanto que aparezcan varios subsistemas fallando a la vez#
Suena raro decirlo así, pero es verdad.
En la captura no falla solo una cosa. Fallan confdb, quorum, dcdb y status en cadena. Eso, lejos de confundirme, me orienta bastante. No parece el capricho de una llamada concreta ni una operación aislada. Parece una rotura de dependencia común.
Y cuando la dependencia común que aparece mencionada es Corosync, la lectura se vuelve bastante directa.
No me obsesiona tanto cada línea como el patrón completo. Muchas piezas intentando inicializarse. Muchas piezas tropezando con la misma base rota. Ese dibujo es más importante que cualquier error aislado.
lo que este comando sí me aporta#
Me enseña la historia reciente de pmxcfs.
Me deja ver si el problema es con Corosync, con quorum o con capas relacionadas.
Me ayuda a separar un nodo con síntomas superficiales de un nodo con base de cluster tocada.
Me da contexto temporal. Si hay una ráfaga de errores en pocos segundos, lo sé. Si reaparece más tarde, también.
Y sobre todo me impide trivializar cosas que no debería trivializar.
Eso me parece muchísimo para un comando tan barato.
lo que este comando no me resuelve por sí solo#
No me dice exactamente por qué Corosync dejó de ser accesible.
No me confirma si el problema fue red, proceso, reinicio, partición o una mezcla simpática de varias cosas.
No me sustituye pvecm status.
No me dice cuántos nodos ven el mismo problema al mismo tiempo.
No me evita revisar enlaces y latencia si sospecho red.
Y tampoco me autoriza a declarar muerto el cluster solo porque he visto una ráfaga fea de logs.
Lo que sí me deja claro es que estoy mirando la zona correcta del edificio. A veces eso es justo lo que necesitaba.
cuando lo lanzo yo casi por reflejo#
cuando /etc/pve me transmite mala espina#
Si noto rarezas al leer o tocar configuración compartida, este comando entra rápido en la secuencia.
cuando systemctl status pve-cluster está demasiado limpio para lo que estoy viendo#
Hay veces que el estado no parece dramático, pero el comportamiento del nodo no acompaña. El journal suele ser bastante menos diplomático.
después de una pérdida de quorum o una incidencia de red del cluster#
Aquí me parece obligatorio. Quiero ver si pmxcfs se recompuso bien o si se quedó dejando cadáveres en el journal.
cuando un nodo vuelve, pero no transmite confianza#
Ese caso lo conozco bien. El nodo ha vuelto. El servicio existe. Todo parece más o menos vivo. Aun así, el cuerpo te dice que no está fino. journalctl -u pve-cluster -n 40 --no-pager suele contestar mejor que la intuición.
cómo encaja con otros posts de esta serie#
Este post se entiende mucho mejor junto a varias comprobaciones que ya he publicado.
- systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
- systemctl status corosync en Proxmox: cómo confirmo si el servicio del cluster está bien antes de tocar red o quorum
- pvecm status en Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo
- corosync-cfgtool -s en Proxmox: cómo confirmo si los enlaces del cluster siguen vivos de verdad
Para mí forman una secuencia muy natural.
Primero confirmo que pve-cluster vive.
Después leo su historia reciente.
Luego confirmo Corosync, quorum y enlaces.
Y solo entonces decido si el problema está en proceso de recuperación, si fue un susto puntual o si toca intervenir de verdad.
mi conclusión#
journalctl -u pve-cluster -n 40 --no-pager me parece uno de los comandos más útiles cuando sospechas que el problema real de Proxmox ya no está en la interfaz, sino en la base compartida del cluster. No arregla nada por sí solo, pero sí te cuenta rápido si pmxcfs viene peleándose con Corosync y quorum de una forma que no deberías ignorar.
La captura que uso aquí no deja mucho espacio para autoengañarse. Cuando ves failed to connect to corosync, varios can't initialize service y una ráfaga de errores en cadena, ya sabes que no estás frente a una tontería cosmética.
Y esa claridad, aunque escueza un poco, es justo lo que quiero de un comando de diagnóstico.
Mejor una verdad fea en el journal que una falsa calma en la web.
referencias#
- Documentación oficial de
journalctl - Documentación oficial de
pmxcfs - Documentación oficial de Proxmox Cluster File System
- Post relacionado: systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
- Post relacionado: pvecm status en Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo
- Post relacionado: corosync-cfgtool -s en Proxmox: cómo confirmo si los enlaces del cluster siguen vivos de verdad