Hay comandos que no arreglan nada, pero te ahorran hacer el idiota.
ls -la /etc/pve/nodes es uno de ellos.
No tiene épica. No luce bien en una charla. No impresiona a nadie. Pero cuando un cluster Proxmox empieza a ir raro y no te apetece sacar todavía la caja de herramientas pesada, esta comprobación corta me parece de las más agradecidas.
¿Por qué? Porque me enseña qué nodos sigue exponiendo pmxcfs dentro de la vista compartida de /etc/pve.
Y eso, aunque parezca poca cosa, tiene mucha miga.
Una cosa es el cluster ideal que tú crees tener en la cabeza. Otra muy distinta es la foto que la capa compartida de Proxmox sigue publicando en ese momento. Cuando ambas coinciden, perfecto. Cuando no coinciden, mejor enterarte en veinte segundos que después de media hora culpando al sitio equivocado.
El comando es este.
| |
Sí, ya está. No hay truco. Y precisamente por eso me gusta.
por qué miro esta ruta tan a menudo#
La documentación oficial de Proxmox explica que pmxcfs es el filesystem de cluster que replica configuración en tiempo real entre nodos usando Corosync. Eso significa que /etc/pve no es un directorio cualquiera. Es una vista especial, montada, compartida y bastante más interesante de lo que parece cuando solo entras a leer qemu-server o lxc.
Dentro de esa vista, nodes/ me da una respuesta muy práctica. ¿Qué nodos está exponiendo ahora mismo esta capa?
No he dicho “qué nodos están sanos”. No he dicho “qué nodos tienen quorum”. Tampoco he dicho “qué nodos deberían seguir en el cluster según mis sueños”.
He dicho qué nodos está exponiendo pmxcfs.
A mí esa precisión me parece importante porque evita lecturas torpes.
la captura real que quería usar aquí#
La salida que ves abajo sale de un nodo real de mi laboratorio, saneada para no enseñar nombres internos.
Y justo por eso me gusta tanto como ejemplo. No sale una foto perfecta de manual. Sale algo más útil.
Sale un cluster donde hay nodos activos que sigo usando y también directorios de nodos antiguos que todavía forman parte de la vista que estoy mirando.
Eso te obliga a leer el comando con la cabeza encendida.
Si alguien ve esto y asume que todos esos nombres son nodos online, está leyendo mal. Si alguien lo ve y piensa que la ruta no sirve porque mezcla historia y presente, también está leyendo mal. El valor real está en entender qué te cuenta y qué no.
lo primero que leo#
cuántos directorios salen#
Lo primero que hago es contar visualmente cuántos nombres hay debajo de . y ...
No porque ese número sea la verdad absoluta, sino porque ya me da una pista de si el mapa que sigo viendo desde pmxcfs coincide con lo que esperaba. Si yo juraba que aquí solo iban a aparecer tres nodos y me salen seis, ya tengo una conversación abierta.
No una conclusión. Una conversación.
Y eso ya vale bastante.
si los nombres me resultan familiares o huelen a pasado#
Este detalle me parece mucho más importante de lo que suele admitirse. Hay nodos que ves y dices, sí, este existe y sigue pintando algo. Y hay otros que tienen toda la pinta de ser restos de otra etapa del laboratorio.
Cuando aparecen esos restos, mi reacción no es entrar en pánico. Mi reacción es dejar de asumir cosas.
Porque aquí hay una trampa muy habitual. Muchos homelabs van mutando con el tiempo. Cambias hardware, renombras máquinas, sacas un nodo del cluster, montas otro para pruebas, luego lo jubila alguien, luego llega otra ñapa. Meses después abres /etc/pve/nodes y ya no estás viendo un dibujo limpio de diapositiva. Estás viendo la biografía real del invento.
Eso no vuelve inútil el comando. Al revés. Lo vuelve honesto.
qué me dice este comando bastante bien#
Me dice qué nombres de nodo sigue exponiendo la vista compartida.
Me deja ver si la capa pmxcfs sigue publicando directorios para nodos que yo daba por retirados.
Me ayuda a detectar desalineación entre mi modelo mental del cluster y la estructura que sigue apareciendo bajo /etc/pve.
Y me da un punto de partida muy bueno para decidir el siguiente paso.
Eso, para algo tan pequeño, me parece una barbaridad de valor.
qué no me dice#
No me dice si el nodo está online.
No me dice si hay quorum.
No me dice si Corosync está perdiendo enlaces.
No me dice si el nodo responde bien por red.
No me dice si un directorio antiguo es un simple resto inocente o una pista de limpieza incompleta que merece cariño.
Y este matiz es clave.
Si tratas ls /etc/pve/nodes como un monitor de salud, la vas a liar. Si lo tratas como una foto útil de la vista compartida del cluster, entonces sí empieza a tener mucho sentido.
por qué me gusta más de lo que parece#
Porque es el tipo de comprobación que baja el humo mental.
Cuando algo falla en Proxmox, es facilísimo empezar a construir una novela. Que si el nodo se habrá quedado a medias. Que si la web engaña. Que si igual el problema es solo del navegador. Que si yo recordaba que ese host ya estaba fuera. Que si tal vez el cluster sigue teniendo una referencia vieja. Todo eso se mezcla muy rápido.
Esta ruta no resuelve la novela. Pero te obliga a mirar el decorado real.
Y en diagnóstico, eso vale oro.
cómo leo esta salida sin contarme cuentos#
si aparecen más nodos de los que esperaba#
No asumo nada heroico. Lo que pienso es muy simple. Vale, pmxcfs sigue exponiendo estos directorios. Ahora toca cruzarlo con otras vistas para saber si estoy viendo miembros activos, restos viejos o una mezcla de ambas cosas.
Mi siguiente paso suele ser mirar cat /etc/pve/.members en Proxmox: cómo veo el mapa rápido de nodos, IPs y quorum que maneja pmxcfs.
Ese JSON me dice mucho mejor qué miembros cree vivos la capa de cluster en ese momento, qué IP asocia a cada uno y si considera que hay quorum. Juntar ambos comandos me da una lectura buenísima. Uno me enseña la estructura visible bajo /etc/pve. El otro me enseña la membresía que está manejando esa capa.
Si ambos cuentan historias que no encajan, ahí es donde el tema se pone interesante.
si falta un nodo que yo daba por hecho#
Esto sí me hace levantar una ceja.
Que un nombre no aparezca donde esperabas es una señal bastante más seria que ver algún resto antiguo. Porque aquí ya no estás discutiendo si hay historia vieja en la ruta. Estás viendo que la vista compartida no está exponiendo algo que tú dabas por presente.
En ese caso suelo subir de nivel rápido. Voy a pvecm status, miro journalctl -u pve-cluster -n 40 --no-pager y, si la cosa huele a red de cluster, salto a journalctl -u corosync -n 40 --no-pager.
si salen nombres antiguos y nombres actuales mezclados#
Esto es bastante de laboratorio real y poco de tutorial bonito. A mí no me escandaliza. Lo que hago es no simplificarlo.
Esa mezcla me recuerda que la vista de /etc/pve no es un listado comercial de “nodos en perfecto estado”. Es una capa compartida que puede arrastrar contexto, estructura y rastro de cómo ha ido creciendo o cambiando el cluster.
Por eso me niego a leer esta salida como si fuera una tabla de salud. Me parece el error clásico.
una opinión bastante clara que tengo aquí#
No conviene tocar nada dentro de /etc/pve/nodes solo porque el listado te parezca feo.
Lo digo así de claro porque es la clase de tentación que aparece rápido. Ves directorios antiguos. Piensas que sobran. El cerebro ya está fantaseando con borrar “basura” y dejarlo limpio.
Mala idea.
Primero entiendes por qué están ahí. Luego decides si hay que hacer algo. Y si hay que hacer algo, se hace desde el procedimiento correcto, no a machete contra la vista compartida del cluster.
Con pmxcfs me parece importante recordar siempre esto. No estás en un directorio corriente de tu Debian favorito. Estás mirando una parte sensible de la configuración compartida del cluster. Conviene comportarse como tal y no como si estuvieras ordenando la carpeta Descargas.
el detalle de permisos y fechas#
Mucha gente pasa por encima de esto, pero yo a veces los miro de reojo.
No porque vaya a sacar una conclusión forense solo con eso. Sería ridículo. Pero sí porque a veces ayudan a ubicar la historia.
Ver fechas distintas entre directorios puede recordarte qué nodos llevan más tiempo en juego y cuáles aparecieron después. También te deja ver que esta estructura no necesariamente nació toda a la vez. De nuevo, no es prueba de salud. Es contexto.
Y cuando estás intentando entender si miras un cluster vivo, rehecho, reciclado o medio heredado, el contexto ayuda.
dónde me parece más útil este comando#
cuando el cluster se tuerce pero todavía no sabes por dónde#
Ahí me gusta empezar por cosas baratas. ls /etc/pve/nodes es de lo más barato que hay y me da orientación.
cuando sospecho que mi mapa mental está desfasado#
Pasa bastante. Sobre todo en homelabs que crecen a base de cacharrear y no siempre con una disciplina monástica. Tú recuerdas tres nodos. El sistema todavía expone seis directorios. Uno de los dos está viviendo en el pasado. Mejor detectarlo pronto.
cuando quiero leer /etc/pve como estructura, no como estado#
Esto también me parece clave. Hay comandos para estado vivo. Hay comandos para leer estructura. Este es de los segundos. Y esa es justo su gracia.
con qué lo suelo encadenar#
Mi secuencia típica cuando algo me huele raro alrededor de pmxcfs suele ser esta.
ls -la /etc/pve/nodescat /etc/pve/.memberspvecm statusjournalctl -u pve-cluster -n 40 --no-pagerjournalctl -u corosync -n 40 --no-pagersi ya sospecho red o quorum
No siempre necesito llegar al final. A veces la primera combinación ya me aclara bastante. Otras veces me confirma que el problema no es una sensación rara, sino una desalineación real entre estructura visible, membresía y estado del cluster.
errores que intento no cometer#
confundir estructura con salud#
Este es el gran clásico. Que un directorio exista no significa que ese nodo esté sano. Que no veas algo limpio tampoco significa desastre automático. La salida hay que leerla por lo que es.
borrar antes de entender#
Muy mala costumbre. Si un nombre parece antiguo, primero averigua por qué sigue ahí y cómo encaja con el resto de vistas del cluster.
asumir que una lista más larga siempre es un bug#
A veces sí apunta a historia vieja o a limpieza pendiente. Otras veces solo te está recordando que el laboratorio real no es un render de marketing. No todo lo que incomoda es un fallo.
mirar solo esta ruta y dar el caso por cerrado#
No. Este comando orienta. No sentencia.
dónde sí me ha ahorrado tiempo de verdad#
A mí me ha servido sobre todo en dos situaciones.
La primera es cuando estaba tentado de culpar a la web. Si veo que /etc/pve/nodes ya refleja una estructura rara o inesperada, dejo de pensar en un simple problema de panel.
La segunda es cuando yo mismo estaba recordando mal la topología. Esto pasa más de lo que me gusta admitir. Cambias nodos, reaprovechas hardware, migras cosas y, de repente, lo que tú juras que es el cluster actual no coincide del todo con lo que la capa compartida sigue enseñando. Este comando pincha esa arrogancia enseguida.
Y sinceramente, mejor así.
mi conclusión#
ls -la /etc/pve/nodes no va a salir en ninguna lista de comandos espectaculares de Proxmox. Pero me parece un mando muy serio para una tarea concreta. Ver qué nodos sigue exponiendo pmxcfs en la vista compartida del cluster antes de contarme una película demasiado cómoda.
No me dice quién tiene quorum. No me dice quién está online. No me dice por qué un enlace de Corosync va mal. Pero sí me enseña la estructura visible que Proxmox sigue publicando bajo /etc/pve, y esa estructura muchas veces ya te avisa de si tu cabeza va alineada con el sistema o va por libre.
Yo no le pido más. Para eso ya están otros comandos.
Le pido justo eso. Una lectura corta, barata y honesta.
Y para un homelab que evoluciona a golpes de cacharreo, esa honestidad me parece bastante valiosa.
referencias#
- Documentación oficial de Proxmox Cluster File System
- Proxmox Cluster File System en la wiki oficial
- Post relacionado: cat /etc/pve/.members en Proxmox: cómo veo el mapa rápido de nodos, IPs y quorum que maneja pmxcfs
- Post relacionado: systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
- 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