Hay días en Proxmox en los que el panel carga y, aun así, todo transmite una sensación terrible.
Entras. Ves los nodos. Navegas por las vistas. Parece que la web no está caída del todo. Pero cuando intentas hacer algo serio empiezan los gestos raros. Arrancar una VM tarda demasiado. Una acción queda colgada. La consola no termina de abrir. Una tarea se siente más lenta de lo razonable. Y de pronto aparece la duda incómoda.
Si la web vive, ¿qué demonios está yendo mal?
En esos momentos uno de los comandos que saco bastante rápido es este.
systemctl status pvedaemon
No es tan popular como otras comprobaciones de cluster. No tiene el glamour de quorum, ni el aura dramática de Corosync, ni el punto solemne de Ceph. Pero me parece una pieza muy útil porque me deja mirar de frente una capa que a menudo está implicada justo cuando el panel parece medio sano, pero las acciones reales del nodo ya empiezan a oler raro.
Y esa situación pasa más de lo que me gustaría.
qué es pvedaemon y por qué le hago caso#
La documentación de pveproxy cuenta una cosa importante que a mí me ayudó bastante a ordenar mentalmente Proxmox. El panel y la API que expones en 8006 corren bajo pveproxy, pero las operaciones que necesitan más permisos se reenvían al pvedaemon local.
Eso encaja perfectamente con la experiencia real.
Una cosa es cargar la interfaz. Otra muy distinta es ejecutar acciones con chicha.
Ahí es donde pvedaemon me importa mucho.
No lo pienso como un concepto abstracto. Lo pienso como una pieza de backend local que conviene revisar cuando la entrada web no está totalmente caída, pero el comportamiento práctico ya deja de ser de confianza.
Dicho más claro, si pveproxy es la cara visible, pvedaemon es una parte importante del trabajo sucio.
Y cuando el trabajo sucio va raro, el panel puede seguir ahí dándote una falsa sensación de normalidad.
la captura real que me sirve de referencia#
He preparado esta captura a partir de una salida real de uno de mis nodos Proxmox, dejando fuera cualquier dato interno que no aporte nada fuera del laboratorio.
A simple vista no parece una imagen emocionante. Mejor.
Me enseña exactamente lo que quiero en una primera pasada.
- el servicio está cargado
- el servicio está activo
- lleva bastante tiempo arriba
- hay proceso principal
- hay workers
- el consumo de memoria y CPU parece razonable
No resuelve el caso por sí sola, pero sí me deja descartar una avería bastante tonta o, por el contrario, poner el foco justo donde tocaba.
por qué este comando me ahorra bastantes vueltas#
Porque ataca una trampa muy común en Proxmox.
Confundir “el panel carga” con “el nodo funciona bien”.
No es lo mismo. En absoluto.
He visto situaciones en las que la interfaz seguía bastante presentable, pero las operaciones reales ya iban con una pesadez rara o con errores intermitentes. Si no separas esas capas, es facilísimo echarle la culpa a la web, al navegador o al cluster entero cuando el problema real está en una pieza más concreta del nodo.
systemctl status pvedaemon me ayuda precisamente con eso. No me deja quedarme solo en la apariencia del panel. Me obliga a mirar la parte que ejecuta mucha de la actividad de verdad.
Y eso me parece sanísimo.
cuándo lo lanzo yo sin pensarlo demasiado#
Hay varios escenarios donde me sale automático.
cuando la web carga, pero arrancar o parar VMs va raro#
Este es el caso más claro.
Si entro al panel sin drama, pero las acciones sobre VMs o CTs no transmiten confianza, revisar pvedaemon me parece una reacción muy lógica. No digo que siempre sea el culpable. Digo que es una capa demasiado cercana a ese tipo de operaciones como para ignorarla al principio.
cuando una tarea se queda con una pinta fea#
A veces no hay una caída limpia. Solo una sensación de atasco. Un job tarda más de la cuenta. Una orden parece quedarse pensativa. Una acción responde, pero con un retraso que no encaja con lo habitual. Ahí es justo donde me gusta mirar el estado del daemon antes de imaginar una avería barroca.
cuando la consola o ciertas acciones del nodo no van finas#
Si la consola web se abre mal, si una acción administrativa tarda o si los cambios aplicados desde la interfaz parecen tener un comportamiento raro, otra vez lo mismo. No doy por hecho que pvedaemon sea la causa, pero sí que merece una mirada temprana.
cuando quiero separar un problema de entrada de un problema de ejecución#
Esto me parece clave. Si ya he comprobado pveproxy y veo que el servicio web está arriba, el siguiente paso lógico muchas veces es pvedaemon.
Esa secuencia tan simple me ordena media investigación.
- primero confirmo la puerta de entrada
- luego confirmo la capa de ejecución local
Suena simple porque lo es. Y funciona.
cómo leo la salida de systemctl status pvedaemon#
No necesito sacarle filosofía. Solo unas cuantas señales útiles.
Loaded#
Lo primero que quiero ver es que el servicio esté cargado donde toca y habilitado.
Parece de perogrullo, pero no sobra. Cuando un nodo viene tocado de paquetes, reinicios o cambios a medias, cualquier señal básica de normalidad cuenta.
Si aquí ya hubiese algo raro, pararía bastante antes de seguir.
Active#
Esta es la línea que más rápido importa.
En la captura real sale active (running) desde hace más de una semana. Eso me dice dos cosas.
La primera, que el daemon no está muerto.
La segunda, que no estoy viendo un arranque reciente o un servicio que acaba de levantarse tras algún susto.
Ese contexto temporal me importa mucho. Me ayuda a decidir si tengo delante una pieza inestable o una pieza que, al menos desde fuera, lleva tiempo plantada.
Main PID#
Quiero ver exactamente lo que espero ver. Un proceso principal pvedaemon.
Esto me confirma que systemd tiene arriba la pieza correcta y no una situación rara a medio camino.
No parece una gran revelación, ya. Pero una investigación técnica bien hecha se apoya mucho en confirmar obviedades antes de construir teorías más listas de la cuenta.
los pvedaemon worker#
Aquí está una de las partes que más me gustan.
En la salida real aparecen varios workers colgando del proceso principal. Eso es buena señal. No solo tengo el daemon levantado de nombre. Tengo además workers activos, que es bastante más tranquilizador cuando estoy intentando entender si la capa de ejecución está viva de verdad.
No me obsesiono con el número exacto. Lo que busco es una estructura coherente.
Si viera un servicio activo pero sin esa pinta general de funcionamiento, ya me pondría mucho más desconfiado.
Tasks, Memory y CPU#
Como casi siempre con systemctl status, no convierto estas cifras en una religión. Pero tampoco las dejo pasar.
En la captura, el consumo de memoria y CPU tiene una pinta totalmente razonable para un daemon que lleva tiempo corriendo y atendiendo trabajo normal. No veo nada explosivo ni especialmente sospechoso.
Eso me ayuda mucho porque, si la capa de tareas va lenta y aquí el daemon parece cómodo, me inclino menos a pensar en un proceso ahogado y más en otros sospechosos.
Por ejemplo.
- almacenamiento lento
- red tocada
- otro servicio del nodo
- bloqueo más abajo en cluster
- un problema puntual de la tarea concreta
pvedaemon vivo y tranquilo no me resuelve el caso, pero sí me ayuda a repartir mejor la desconfianza.
por qué me parece tan útil en problemas “a medias”#
Lo que más valoro de este comando es que sirve muy bien cuando el fallo todavía no se ha decidido a ser obvio.
Si todo estuviera totalmente roto, seguramente no necesitarías mucha sutileza. Pero en Proxmox abundan más los problemas intermedios. Ese terreno feo donde algo funciona lo suficiente para despistarte, pero no lo bastante para darte confianza real.
Ahí es donde pvedaemon entra muy bien.
No me dice “todo está perfecto”. Me dice algo más humilde y más útil. “Esta pieza concreta está arriba y tiene esta pinta”.
Y a mí eso me basta muchas veces para decidir el siguiente paso con bastante mejor criterio.
un error muy habitual, culpar al cluster entero demasiado pronto#
Lo entiendo porque yo también caigo a veces.
Algo va raro en Proxmox y enseguida pensamos en cluster, quorum, Corosync, pmxcfs, almacenamiento compartido, la luna en Capricornio y cualquier otra teoría con buena estética.
Pero no siempre toca empezar tan arriba.
A veces el problema está más cerca del nodo concreto y de cómo está respondiendo la capa que ejecuta ciertas acciones locales. No digo que pvedaemon sea siempre el malo. Digo que saltárselo por completo es una forma muy eficaz de complicarse la vida.
Este comando me recuerda justo eso. Primero confirma la capa local que estás usando de verdad. Luego ya subes al resto del edificio.
cómo lo combino con otras comprobaciones#
Mi secuencia corta suele ser bastante terrenal.
systemctl status pveproxy --no-pagersystemctl status pvedaemon --no-pagersystemctl status pve-cluster --no-pagerpvecm status- si hace falta,
journalctl -u pvedaemon -n 100 --no-pager
El orden tiene bastante sentido para mí.
Primero miro la entrada web. Después la capa de ejecución local. Luego la configuración compartida. Luego la salud de cluster. Y solo después me voy a logs o a capas más profundas si todavía no veo claro el problema.
Eso me evita dos cosas que odio bastante.
La primera es dar palos de ciego.
La segunda es pasar media hora en capas exóticas cuando un systemctl status bien leído ya te estaba diciendo por dónde seguir.
lo que este comando sí me aporta#
Me confirma si el servicio está levantado.
Me confirma desde cuándo.
Me deja ver si hay workers.
Me da una lectura muy rápida de consumo de recursos.
Y me dice si, al menos desde systemd, la pieza central de esta capa tiene pinta sana o no.
Para un primer filtrado me parece muchísimo.
lo que este comando no puede contarme#
Aquí conviene no fliparse.
Que pvedaemon salga active (running) no significa que todas las tareas de Proxmox vayan a ejecutarse bien.
No me garantiza que el storage responda rápido.
No me garantiza que una migración no se vaya a atascar por red.
No me garantiza que pve-cluster esté sano.
No me garantiza que Corosync no haya tenido un mal día.
No me garantiza que una operación concreta no dependa de otra capa rota.
Tampoco me garantiza que el problema no venga de permisos, certificados, una tarea previa, un lock o un recurso de hardware que está dando guerra.
Lo que sí hace es descartar rápido que esta capa esté directamente caída. Y eso ya me parece media victoria cuando el síntoma es borroso.
un matiz que a mí me ayuda mucho, panel presente no es backend sano#
Quiero insistir en esto porque me parece la mejor razón para usar este comando.
La presencia del panel web engaña muchísimo.
Si puedes entrar en Proxmox, tu cabeza ya quiere creer que el nodo está bastante bien. Pero a veces solo está bien la puerta. Por dentro, otra historia.
pvedaemon me sirve justo para discutirle esa falsa tranquilidad al panel.
Lo miro y me pregunto algo muy simple.
Vale, puedo entrar. Pero la capa que debería ejecutar acciones con normalidad, ¿sigue sana o no?
Esa pregunta me parece mucho mejor que quedarse en “la web abre, así que no será nada grave”. Esa frase ha hecho perder horas a bastante gente. Me incluyo.
en qué tipo de síntomas me parece especialmente valioso#
No quiero venderlo como remedio universal, pero sí hay patrones donde me gusta mucho.
tareas que arrancan pero no transmiten normalidad#
No hablo del fallo limpio con mensaje clarísimo. Hablo de esa tarea que arranca, pero tarda, se atasca un rato o deja una sensación fea. Ahí una mirada a pvedaemon ayuda bastante.
acciones administrativas que responden raro#
Cambios desde la interfaz, operaciones sobre recursos del nodo, pequeños gestos administrativos que no terminan de comportarse con la agilidad habitual. Otra vez, es un buen sitio donde mirar.
problemas que parecen locales, no globales#
Si un nodo concreto hace cosas raras mientras el resto del cluster transmite calma, me interesa mucho separar la película local de la película global. pvedaemon me encaja muy bien ahí.
también me gusta porque no necesita dramatismo#
En homelab hay mucha afición a convertir cualquier síntoma raro en una saga épica. Lo entiendo, porque mola sentirse en una película de infraestructura. Pero la mayoría de las veces lo que hace falta es menos cine y más comprobaciones baratas.
systemctl status pvedaemon es justo eso.
No vende humo. No es bonito. No te da una falsa sensación de observabilidad total. Solo te dice cómo está una pieza importante del nodo. Y ese tipo de modestia técnica suele ser bastante rentable.
mi conclusión#
systemctl status pvedaemon me parece una de esas comprobaciones que conviene tener muy interiorizadas si trabajas bastante con Proxmox. Sobre todo cuando el panel no está muerto del todo, pero las acciones reales del nodo ya han empezado a comportarse como si algo dentro no terminara de estar fino.
No reemplaza a logs, ni a quorum, ni a pve-cluster, ni a revisar storage o red cuando toca. Pero sí me da algo muy valioso al principio. Una lectura rápida y bastante honesta de la capa que ejecuta buena parte del trabajo real detrás de la interfaz.
Y eso me ayuda a no quedarme hipnotizado por el hecho de que la web todavía abra.
Si te pasa a menudo eso de “puedo entrar, pero esto no me gusta nada”, yo metería este comando en la rutina. No resuelve todos los marrones. Pero sí evita bastantes diagnósticos mediocres, que ya es bastante.
referencias#
- Documentación oficial de pveproxy
- Documentación oficial de Proxmox VE sobre Cluster Manager
- Post relacionado: systemctl status pveproxy en Proxmox: cómo separo un panel web caído de un cluster que en realidad sigue bien
- Post relacionado: systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
- Post relacionado: pvesh get /cluster/status en Proxmox: la vista cruda que miro cuando la interfaz parece demasiado tranquila