Hay un tipo de avería en Proxmox que me pone de mal humor bastante rápido.
No hablo del desastre evidente, cuando un nodo se cae de verdad y todo el mundo se da cuenta. Hablo de esa capa más sutil donde la web va rara, /etc/pve tarda en responder, una configuración no aparece donde debería o el cluster transmite una sensación fea de “algo no está fino” aunque todavía no haya explotado nada serio.
En esos momentos hay un comando que saco enseguida.
systemctl status pve-cluster
No porque sea mágico, sino porque me lleva directo al servicio que sostiene pmxcfs, el filesystem de cluster de Proxmox. Y cuando esa pieza no está bien, todo lo demás empieza a oler raro muy deprisa.
Me sorprende que se hable menos de esto de lo que esperaba. Hay muchísima discusión sobre quorum, sobre Corosync, sobre Ceph, sobre HA. Todo eso importa, claro. Pero si la capa de configuración compartida va coja, puedes pasarte una hora culpando a la interfaz, a la red o a tus ojos cuando el primer sitio serio al que deberías mirar es este.
qué es pve-cluster y por qué me importa tanto#
Según la propia documentación de Proxmox, pmxcfs es el Proxmox Cluster File System. Es un filesystem basado en base de datos, replicado en tiempo real entre nodos usando Corosync, y montado en /etc/pve.
Traducido a la práctica, ahí vive una parte enorme de lo que hace que Proxmox sea Proxmox en modo cluster.
- configuración del datacenter
corosync.confstorage.cfg- configuraciones de VMs y CTs
- certificados
- reglas de firewall
- recursos de HA
- jobs de backup
No es un detalle menor. Es la carpeta que abrimos y damos por sentada todos los días.
Y el servicio que pone eso en pie es pve-cluster.
De hecho, el propio manual de pmxcfs lo dice tal cual. El servicio se arranca y se gestiona con systemd como pve-cluster. Así que cuando quiero saber si la base del filesystem compartido está sana, este es mi primer salto.
la salida real que me interesa leer#
He preparado esta captura a partir de una salida real de uno de mis nodos, manteniendo lo importante y recortando lo que no aporta nada fuera del lab.
No parece gran cosa. Justo por eso me gusta.
Sale el servicio. Sale que está cargado. Sale que está activo. Sale el proceso principal, que es pmxcfs. Sale memoria, CPU y el cgroup. Y poco más.
Pero con ese poco más yo ya saco bastante contexto.
por qué este comando me parece tan rentable#
Porque aterriza la conversación.
Cuando Proxmox se pone raro, es muy fácil entrar en espiral. Abres la web, ves comportamientos extraños, pruebas dos cosas, una responde y la otra no, miras /etc/pve, dudas si el problema es local o de cluster, te asomas a otro nodo, te distraes con Corosync, vuelves a la interfaz y al final llevas veinte minutos sin haber mirado todavía si el servicio del filesystem está vivo y estable.
Con systemctl status pve-cluster corto ese ruido enseguida.
No me cuenta toda la historia, pero me responde una pregunta básica que necesito tener clara antes de seguir. En este nodo, ¿el servicio que sostiene pmxcfs está levantado y aparentemente sano o no?
cómo leo la salida línea por línea#
No la exprimo entera. Voy a lo importante.
Loaded#
Aquí busco dos cosas.
Primero, que el servicio exista donde debe y se haya cargado bien. Parece una tontería, pero cuando un sistema viene tocado por actualizaciones raras, paquetes rotos o estados medio zombis, cualquier confirmación sencilla suma.
Segundo, me fijo en que esté enabled. No porque eso arregle un problema hoy, sino porque me recuerda si el servicio está preparado para arrancar solo como toca.
En un nodo sano, ver loaded y enabled es justo lo esperable. Si ya aquí hubiese algo raro, frenaría bastante.
Active#
Esta es la línea que más rápido me importa.
Si sale active (running), respiro mejor. No doy el tema por cerrado, pero sé que no estoy ante un servicio muerto o claramente caído.
Si saliera failed, inactive o cualquier estado dudoso, la investigación ya cambiaría por completo. Ahí dejaría de mirar menús y me pondría directo con logs, dependencias y contexto del nodo.
También me fijo mucho en desde cuándo está activo.
Si lleva una semana levantado, sé que no ha reiniciado hace un rato. Si lleva cinco minutos, ya tengo contexto. Igual se ha caído y vuelto. Igual alguien lo ha reiniciado. Igual el nodo viene de un arranque reciente. En troubleshooting ese detalle cuenta más de lo que parece.
Main PID y pmxcfs#
Esta parte me encanta porque quita ambigüedad.
No es un servicio abstracto. El proceso principal que está corriendo es pmxcfs. Y eso me confirma que estoy mirando exactamente la pieza que quería mirar.
Cuando un problema huele a /etc/pve, ver pmxcfs ahí y verlo activo me ayuda a no inventarme teorías demasiado rápido. La pieza sigue viva. Bien. Ahora ya puedo preguntar si vive bien o si vive regular.
Tasks, Memory y CPU#
Estas métricas no son mi diagnóstico principal, pero nunca las ignoro.
Si de repente viera un consumo de memoria disparado, una CPU absurda o un comportamiento claramente raro respecto a lo habitual, me lo apuntaría. No porque esa línea explique sola una avería, sino porque ayuda a detectar un servicio que sigue arriba pero no precisamente cómodo.
En la captura, la memoria y la CPU me parecen completamente razonables para un nodo que lleva días funcionando. Eso no demuestra perfección, pero sí me aleja de la sospecha de un proceso desbocado.
CGroup#
No necesito leer mucho aquí. Solo me gusta confirmar la ruta y que todo parezca normal dentro del servicio de systemd.
Es una línea de contexto más que de diagnóstico, pero no sobra.
el aviso del journal rotado#
Esta línea aparece bastante a menudo y no me preocupa por sí sola.
Lo que me dice es que el journal ya rotó desde que el servicio arrancó, así que systemctl status no me va a enseñar toda la película histórica en una sola pantalla. Perfecto. No le pido eso.
Si necesito historia, ya sé que me toca tirar de journalctl -u pve-cluster.
por qué esta comprobación encaja tan bien con síntomas raros de /etc/pve#
El manual de pmxcfs deja claro que /etc/pve no es una carpeta corriente. Es un filesystem FUSE con base de datos detrás, replicado en RAM y en disco, y además con comportamiento especial cuando un nodo pierde quorum. Por ejemplo, pasa a modo lectura.
Eso es potentísimo. Y también significa que cuando esa capa viene torcida, los síntomas pueden ser confusos.
He visto comportamientos como estos.
- configuraciones que parecen tardar en aparecer
- sensación de lentitud extraña al navegar la parte de cluster
- dudas sobre si un archivo en
/etc/pveestá realmente accesible - cambios que no se sienten tan inmediatos como deberían
- sospecha de que el problema está en la web cuando la raíz va más abajo
No digo que todo eso sea siempre culpa de pve-cluster. Ni mucho menos. Pero sí digo que, si aparecen, mirar este servicio temprano me parece una decisión bastante sensata.
lo que me aporta antes de culpar a la interfaz web#
Proxmox tiene una interfaz muy buena, pero cuando algo va mal es muy fácil enfadarse con el navegador antes de comprobar capas más fundamentales.
La web es solo una de las caras del sistema. Si la configuración compartida debajo viene tocada, la experiencia en la interfaz puede volverse rara aunque el navegador no tenga culpa de nada.
Por eso me gusta tanto este comando. Me ayuda a decidir si la rareza viene de arriba o si merece la pena empezar desde abajo.
Si pve-cluster sale sano y tranquilo, sigo investigando otras piezas con más criterio.
Si aquí ya hay señales malas, perfecto. Tengo una pista de verdad y no una rabieta contra la UI.
cuándo lo lanzo yo sin pensarlo demasiado#
Hay varios casos donde me sale casi automático.
cuando /etc/pve me inspira desconfianza#
Si entro a revisar algo en /etc/pve y la sensación es rara, este comando aparece rápido. No necesito esperar a que el problema se haga más grande. Quiero saber si el servicio base sigue arriba.
después de un reinicio o una actualización delicada#
Tras tocar kernel, paquetes o cualquier mantenimiento que afecte al nodo, me gusta confirmar que pve-cluster volvió como debe. Es una comprobación muy barata y bastante tranquilizadora.
cuando la capa de cluster parece sana, pero no tanto#
Aquí entra ese tipo de día en el que pvecm status no grita desastre, Corosync parece seguir respirando y sin embargo hay algo turbio en el comportamiento general. En ese punto revisar pve-cluster me ayuda a no saltar por encima de una capa importante.
cuando sospecho del nodo, no del cluster entero#
Esto también me gusta mucho de systemctl status. La pregunta es local. ¿Cómo está este servicio en este nodo?
Esa perspectiva es valiosa. Porque a veces el problema no es una crisis global del cluster. A veces es un nodo concreto que está viviendo peor la situación.
cómo lo combino con otros comandos#
Solo, ayuda bastante. Acompañado, ayuda mucho más.
Mi secuencia corta suele ser esta.
systemctl status pve-cluster --no-pagerjournalctl -u pve-cluster -n 100 --no-pagerpvecm statuspvesh get /cluster/status- si hay sospecha de red,
corosync-cfgtool -s
La lógica me parece bastante limpia.
Primero confirmo el servicio local del filesystem. Luego miro el log cercano si algo no cuadra. Después subo al estado de quorum y cluster. Y solo luego me meto con red o capas más específicas.
Ese orden evita bastante ruido.
una cosa importante, active (running) no significa “todo perfecto”#
Esto conviene repetirlo porque es justo donde más fácil es pasarse de optimista.
Que pve-cluster salga activo significa que el servicio está corriendo. Bien. Muy bien, de hecho. Pero no significa que todo lo que depende de él vaya fino.
No me garantiza quorum.
No me garantiza que Corosync no haya tenido flaps.
No me garantiza que una lectura concreta de /etc/pve vaya a estar libre de problemas si el nodo viene con otra avería alrededor.
No me garantiza tampoco que una configuración esté replicando exactamente como tú esperas en ese instante.
Lo que sí hace es descartar rápido una causa bastante obvia. El servicio no está muerto.
Y eso, cuando estás orientándote, ya vale mucho.
lo que sí me haría preocuparme en serio#
Hay varios patrones que me harían bajar el ritmo bastante.
- el servicio no está activo
- aparece como
failed - el proceso principal no es el esperado o ni siquiera está
- hay reinicios demasiado recientes que no esperaba
- el consumo de recursos me resulta anómalo respecto al comportamiento habitual del nodo
- el journal cercano enseña errores repetidos relacionados con
pmxcfs, FUSE o la sincronización del cluster
Aquí ya no seguiría como si nada. Primero estabilizar, luego tocar lo demás.
Porque si la base de configuración compartida no está clara, meter cambios encima me parece una receta estupenda para complicarse la vida.
una nota importante del propio diseño de pmxcfs#
El manual de pmxcfs menciona dos detalles que a mí me parecen muy útiles para pensar en problemas reales.
El primero es que una copia de los datos reside en RAM, con un límite global de tamaño. Eso explica por qué hablamos de una pieza ligera pero crítica.
El segundo es que, cuando un nodo pierde quorum, el filesystem pasa a solo lectura. Esto es importantísimo. A veces alguien ve que no puede escribir donde esperaba y empieza a sospechar de permisos, de un archivo raro o del panel. Igual el problema es que la capa compartida está protegiéndose porque el nodo ha perdido quorum.
Por eso nunca intento interpretar síntomas de /etc/pve sin tener en mente esta arquitectura. Si no entiendes qué está montando pve-cluster, es fácil leer mal el síntoma.
también me gusta porque obliga a empezar por lo simple#
Hay una tendencia muy de homelab a buscar causas sofisticadas demasiado pronto. La entiendo. Yo también caigo. Un cluster Proxmox da para teorías bonitas.
Pero muchas veces lo primero que necesitamos es confirmar que el servicio base del filesystem sigue arriba, que el proceso es el correcto y que el nodo no está contando una historia extraña desde systemd.
Eso no es glamuroso. Y funciona.
mi conclusión#
systemctl status pve-cluster me parece uno de esos comandos humildes que conviene tener muy a mano si administras Proxmox en serio, aunque sea en casa. No arregla por sí solo una avería compleja y no sustituye al resto de comprobaciones del cluster. Pero sí responde rápido a una pregunta esencial. ¿La pieza que levanta pmxcfs y sostiene /etc/pve sigue viva y razonablemente sana en este nodo?
Cuando la web va rara, cuando /etc/pve me transmite mala espina o cuando el cluster no termina de inspirarme confianza, este es uno de mis primeros pasos. Porque antes de culpar a la interfaz, a la red o a la mala suerte, prefiero confirmar si el cimiento más básico de la configuración compartida está donde debe.
Y, sinceramente, eso me ha evitado más de un rodeo tonto.
referencias#
- Manual de pmxcfs en Proxmox VE
- Documentación oficial de Proxmox Cluster File System
- Documentación oficial de Proxmox VE sobre Cluster Manager
- Post relacionado: systemctl status corosync en Proxmox: cómo confirmo si el servicio del cluster está bien antes de tocar red o quorum
- Post relacionado: pvesh get /cluster/status en Proxmox: la vista cruda que miro cuando la interfaz parece demasiado tranquila
- Post relacionado: corosync-cfgtool -s en Proxmox: cómo confirmo si los enlaces del cluster siguen vivos de verdad