Hay comandos que parecen poca cosa hasta que una noche te ahorran una media hora de tonterías.
cat /etc/pve/.members entra de lleno en esa categoría.
No es el comando más famoso de Proxmox. No sale mucho en tutoriales para principiantes. No tiene ese aire heroico de pvecm status ni el dramatismo de journalctl -u corosync. Pero a mí me gusta muchísimo por una razón muy simple. Me da una foto corta, directa y muy útil de lo que pmxcfs cree que está pasando con el cluster.
Y cuando digo útil, quiero decir útil de verdad. No útil en plan “mira qué curioso”. Útil en plan “vale, ya sé si el nodo que falta sigue apareciendo, si está marcado offline, cuántos nodos ve ahora mismo el cluster y qué IP está asociando a cada uno”.
Cuando Proxmox empieza a oler raro, yo suelo intentar responder preguntas pequeñas antes de meterme en preguntas grandotas. ¿Qué nodos ve este nodo como miembros del cluster? ¿Los marca online u offline? ¿Está quorate? ¿La lista encaja con la película que yo tengo en la cabeza o ya hay una grieta entre ambas?
Este archivo me ayuda justo con eso.
| |
Si además tengo jq a mano, mejor. Pero incluso en bruto ya dice bastante.
por qué me gusta tanto este comando#
Porque me ahorra solemnidad.
pvecm status es fantástico. Lo uso muchísimo. Ya le dediqué un post entero porque cuando quiero leer quorum, votes y membership formal, sigue siendo el mando bueno. Pero hay veces en las que no quiero empezar por ahí. Quiero algo más terrenal.
Quiero ver qué mapa rápido de nodos tiene delante pmxcfs en este momento.
La documentación oficial de Proxmox explica que pmxcfs es el filesystem de cluster, replicado en tiempo real entre nodos usando Corosync. Eso ya coloca a /etc/pve en un sitio muy distinto al de un directorio normal. No estoy mirando un etc cualquiera. Estoy mirando una vista montada sobre la base compartida del cluster.
Por eso .members me interesa tanto. No es una lista decorativa. Es una vista compacta de membresía y estado tal y como la está viendo esta capa del sistema.
Y cuando una pieza tan central te regala un resumen corto, lo sensato es aprovecharlo.
la captura real que yo quería tener para este post#
Esta salida sale de un nodo real de mi laboratorio, saneada para no enseñar nombres internos ni direcciones que aquí no aportan nada.
A mí esta salida me encanta porque concentra mucha información en muy poco espacio.
Sin abrir la web, sin entrar todavía en el journal y sin empezar a sospechar cosas demasiado sofisticadas, aquí ya veo varias piezas importantes:
- el nodo desde el que estoy mirando
- la versión de la vista de membresía
- el nombre del cluster
- cuántos nodos ve
- si ahora mismo lo considera quorate
- qué nodos aparecen en la lista
- qué
idtiene cada uno - qué
ipasocia a cada nodo - cuáles están online y cuáles no
Eso, para un JSON oculto que casi nadie menciona, no está nada mal.
lo primero que leo siempre#
nodename#
| |
Esto parece obvio, pero lo miro siempre. Quiero saber desde qué perspectiva estoy viendo la película.
Cuando un cluster anda fino, da igual. Cuando no anda fino, importa mucho.
No es lo mismo mirar la membresía desde el nodo que sospechas que está aislado que mirarla desde uno sano. Si el nodo actual se cree centro del universo, o si tiene una visión parcial del cluster, esta línea me recuerda desde qué asiento estoy leyendo los datos.
cluster#
| |
Aquí ya se pone interesante.
name no suele darme pista de salud, pero sí me sirve para confirmar que no estoy leyendo algo extraño ni un nodo suelto con otra historia. version me interesa menos en diagnóstico rápido, aunque puede venir bien si estás comparando vistas entre nodos distintos y una no avanza.
Las dos claves que más miro son nodes y quorate.
Si pone nodes: 3, este nodo cree que el cluster tiene tres miembros. Bien.
Si pone quorate: 1, mejor todavía. En ese instante, la capa que me está enseñando esta vista considera que hay quorum.
Ojo con esto. No trato .members como sustituto de pvecm status. Ni de broma. Pero para una lectura corta, ver quorate: 1 ya me baja bastante la tensión. Si saliera 0, mi siguiente paso sería bastante menos relajado.
la parte jugosa de verdad, nodelist#
Aquí es donde el comando gana.
| |
Esto es una maravilla para orientarse rápido.
Aquí no necesito interpretar votos, ring IDs ni mensajes de journal con cara de jeroglífico. Veo tres nodos. Veo sus id. Veo la IP que esta vista les asocia. Y veo algo crucial. Uno de ellos está marcado con online: 0.
Eso ya me cambia la conversación.
No me demuestra todavía por qué ha caído. No me dice si perdió red, si Corosync está sufriendo o si simplemente ese nodo está apagado. Pero me da una respuesta inmediata a una pregunta práctica: desde este nodo, ese miembro no está siendo considerado online ahora mismo.
Y esa clase de claridad suele valer bastante más que un montón de teoría bonita.
por qué el campo online me gusta tanto#
Porque corta discusiones tontas.
En cluster hay muchísimas incidencias que arrancan así:
- “yo juraría que el nodo sigue ahí”
- “la web tardó pero luego cargó”
- “igual solo fue un susto”
- “desde otro nodo parecía medio vivo”
Muy bien. Todo eso puede pasar. Pero si en .members veo online: 0, ya tengo una señal concreta de que esta capa del cluster no lo está viendo sano en ese momento.
No es un juicio filosófico. Es una señal operativa.
Yo no cierro el caso con eso, claro. Lo que hago es ordenar el siguiente paso. Si el nodo aparece offline aquí, ya no voy a empezar culpando al navegador o a un capricho de la interfaz. Voy a mirar quorum, Corosync y la visión global del cluster con bastante menos inocencia.
las IPs también cuentan una historia#
Este punto me parece muy útil y muy poco comentado.
En .members veo la IP que el sistema está asociando a cada nodo en esta vista. Y eso, cuando algo no cuadra, puede ahorrar tiempo.
No digo que esta IP tenga que ser la respuesta absoluta a todo. De hecho, hay escenarios donde la IP que ves aquí no es la que tenías mentalmente como red principal de Corosync, y eso no siempre significa catástrofe inmediata. Pero si ves una dirección que no esperabas, conviene parar un segundo y entender por qué.
A mí me ha servido varias veces para detectar desalineación entre la película que yo tenía del cluster y la película que el sistema estaba enseñando realmente.
Ese tipo de desalineación es peligrosísima porque te hace diagnosticar una red mientras el sistema está jugando con otra referencia distinta.
Por eso me gusta cruzar esta salida con el contenido de corosync.conf. Si aquí veo IPs que no me encajan, mi siguiente parada suele ser algo como:
- el post de
pvecm statusen Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo - el post de journalctl -u corosync -n 40 –no-pager en Proxmox: cómo leo knet, quorum y nodos que se quedan sin enlaces
- y el de mañana sobre
corosync.conf, porque ahí es donde suelo confirmar el mapa lógico de nombres, nodeid yring0_addr
qué creo que es realmente .members#
Mi lectura práctica es esta.
No lo trato como un archivo de configuración. Lo trato como una vista especial y de solo lectura que resume la membresía que maneja la capa de cluster en ese momento.
En el foro oficial de Proxmox hay varias respuestas del equipo diciendo justo eso en esencia. No es un archivo para editar ni una palanca mágica que puedas forzar. Si el contenido sale raro, lo normal no es “arreglar .members”. Lo normal es arreglar la configuración o la salud del cluster que hay por debajo.
Y esta diferencia importa muchísimo.
Porque cuando una ruta vive bajo /etc/pve, el cerebro pide abrirla y arreglarla a mano. Con .members, eso es pensar mal. Aquí lo correcto es leer, no retocar.
A mí me gusta verlo como el panel pequeño del salpicadero. Si marca raro, no golpeas el panel. Miras el motor.
qué me dice este comando muy bien#
Me dice si este nodo cree que el cluster tiene quorum.
Me dice cuántos miembros está viendo.
Me dice qué nodos concreta esa visión.
Me dice cuáles salen online y cuáles no.
Me dice qué IP está asociando a cada miembro dentro de esta vista.
Y me deja detectar enseguida si la membresía que yo tenía en la cabeza coincide con la que está manejando esta capa del sistema.
Para un primer corte, me parece una barbaridad de información útil.
lo que no le pido nunca#
No le pido que me explique la causa raíz.
No le pido que me diga si la red del cluster tiene pérdida, jitter o un switch haciendo el gracioso.
No le pido que me sustituya pvecm status.
No le pido que me diga si el nodo offline está apagado, aislado o simplemente en una transición fea.
No le pido tampoco que me diga si pmxcfs está arrastrando errores internos contra Corosync. Para eso sigo tirando del post de journalctl -u pve-cluster -n 40 –no-pager en Proxmox: cómo leo pmxcfs cuando Corosync se rompe y /etc/pve deja de inspirar confianza.
El gran error con este comando sería pedirle más de lo que puede dar. El segundo gran error sería infravalorarlo y no mirarlo nunca.
errores que intento no cometer al leer .members#
tratarlo como si fuera una fuente definitiva y completa#
No lo es. Es una vista compacta. Buenísima, sí. Definitiva, no.
pensar que si quorate vale 1 ya todo está perfecto#
Ni de lejos. Puedes tener quorum y seguir arrastrando cosas torcidas en la red, en un nodo concreto o en alguna capa de servicio.
intentar editarlo#
No. Aquí no se toca. Si la foto sale mal, se arregla lo que genera la foto.
asumir que la IP que sale aquí te cuenta toda la historia de Corosync#
No siempre. Te da una pista muy útil, pero conviene contrastarla con corosync.conf, con estado real de enlaces y con el journal si la cosa pinta seria.
cuándo lo uso yo casi por reflejo#
cuando el cluster se siente raro, pero todavía no tengo una hipótesis clara#
Me gusta empezar por cosas cortas. .members es muy bueno para eso.
cuando un nodo parece medio vivo y no me fío#
Si el panel abre a ratos o si otro comando no me deja una lectura limpia, aquí obtengo una señal simple. Sale online o no sale online.
cuando quiero una confirmación rápida antes de meterme en el barro#
Antes de abrir journalctl, antes de revisar enlaces y antes de discutir conmigo mismo si el problema es solo percepción, miro esta vista.
cuando noto que mi modelo mental del cluster puede estar desfasado#
Esto pasa más de lo que nos gusta admitir. Tú crees que el cluster está en una situación y el sistema está operando sobre otra. .members es muy bueno para pinchar esa burbuja rápido.
cómo lo encadeno yo con el resto de comandos#
Mi secuencia típica, si algo me huele mal, suele ser esta:
cat /etc/pve/.memberspvecm statusjournalctl -u corosync -n 40 --no-pagerjournalctl -u pve-cluster -n 40 --no-pager
A veces también meto systemctl status pve-cluster --no-pager o corosync-cfgtool -s, según el caso. Pero casi siempre empiezo agradeciendo este JSON pequeño porque me coloca muy rápido.
Es un poco la diferencia entre entrar a una avería con un mapa en la cabeza o entrar a ciegas. El mapa no arregla la carretera. Pero ayuda una barbaridad a no perder el tiempo en la salida equivocada.
mi conclusión#
cat /etc/pve/.members me parece una de esas joyas discretas de Proxmox que no impresionan en una demo, pero que en el día real valen bastante. No sustituye los comandos grandes del diagnóstico de cluster, pero me da una lectura compacta y muy honesta de lo que pmxcfs cree que está pasando con la membresía, el quorum y el estado online de cada nodo.
Cuando un nodo aparece con online: 0, yo ya no sigo contando una historia amable. Cuando el JSON me enseña quorate: 1 y una lista de miembros coherente, respiro un poco. Cuando las IPs no encajan con lo que esperaba, sé por dónde seguir.
En resumen, no es un comando espectacular. Es mejor que eso. Es un comando útil. Y en un homelab con Proxmox, eso suele ser bastante más valioso.
referencias#
- Documentación oficial de Proxmox Cluster File System
- Documentación oficial de Cluster Manager en Proxmox VE
- Post relacionado: pvecm status en Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo
- Post relacionado: journalctl -u corosync -n 40 –no-pager en Proxmox: cómo leo knet, quorum y nodos que se quedan sin enlaces
- Post relacionado: journalctl -u pve-cluster -n 40 –no-pager en Proxmox: cómo leo pmxcfs cuando Corosync se rompe y /etc/pve deja de inspirar confianza