Hay fallos en Proxmox que se ven clarísimos y hasta tienen algo de dignidad.
Se cae un servicio. Un nodo desaparece. El quorum se rompe. Perfecto. Molesta, pero al menos sabes que tienes un problema de verdad delante.
Luego están los otros.
Los que empiezan con detalles pequeños y bastante irritantes. Un storage que aparece intermitente. Una cifra que no cuadra. Un nodo que sigue vivo, pero transmite esa sensación fea de que por dentro hay algo torcido. La web aún carga. El SSH también. No parece una caída limpia. Parece más bien que alguna pieza del sistema sigue haciendo trabajo, pero lo hace arrastrando una zapatilla.
En ese terreno raro, uno de los comandos que más me ayuda es este.
systemctl status pvestatd
No es vistoso y no suele salir en los tutoriales bonitos. A mí me da igual. Me parece de esos comandos rentables porque me enseña rápido si el daemon que refresca buena parte del estado del nodo sigue trabajando con normalidad o si lleva rato mascando errores repetidos que luego se cuelan por toda la interfaz.
qué hace pvestatd y por qué me importa tanto#
pvestatd es el PVE Status Daemon. Dicho sin el envoltorio de manual, es una de las piezas que mantiene al día información que luego ves en Proxmox sobre nodos, recursos y storages.
Por eso me parece bastante más importante de lo que su nombre sugiere.
Cuando esta capa va bien, la plataforma te transmite una cierta coherencia. Los storages aparecen con su estado correcto. Las métricas tienen una pinta razonable. Las pantallas del nodo no te hacen dudar a cada clic.
Cuando va mal, no siempre lo hace con un estallido épico. A veces simplemente empieza a escupir avisos de forma repetitiva, tarda más de la cuenta en resolver comprobaciones o se queda tropezando con un storage viejo que ya no existe, una configuración a medias o un backend remoto que está respondiendo fatal.
Y eso contamina mucho la lectura del nodo.
A mí me gusta mirarlo pronto porque me ayuda a responder una pregunta muy práctica.
¿Estoy viendo un problema puntual de una vista de Proxmox o una pieza de fondo que lleva rato chocando contra algo cada pocos segundos?
La diferencia importa.
la captura real que me hizo parar y mirar dos veces#
Esta captura sale de un nodo real de mi laboratorio, saneada para no enseñar nombres internos ni rutas que no aportan nada fuera de casa.
Me gusta porque enseña justo el tipo de caso que me interesa de verdad.
El servicio no está caído. De hecho sale active (running). Eso ya rompe una tentación muy común, que es mirar una interfaz rara y asumir que el daemon responsable está muerto.
No. Puede estar vivo y, aun así, estar dejando un rastro bastante feo.
En la captura se ven dos señales que yo no ignoraría.
La primera es que cuelga un proceso smbclient desde el propio pvestatd. Eso ya te dice que el daemon no vive en el vacío y que está haciendo comprobaciones reales sobre un recurso remoto.
La segunda es la parte que más me interesa. Los mensajes repetidos.
storage 'backup-cifs' is not onlineno such logical volume pve/data
Ese tipo de repetición me pone inmediatamente en modo práctico. No me pongo a filosofar sobre el cluster. Pienso en cosas concretas. Un storage CIFS que ya no responde como debería. Una referencia vieja a local-lvm. Un nodo arrastrando configuración heredada que nadie ha limpiado. O, peor todavía, una combinación de dos o tres pequeñas chapuzas que por separado parecen poca cosa y juntas te dejan la sensación de nodo raro.
por qué este comando me ahorra más tiempo del que parece#
Porque me obliga a mirar la capa correcta cuando el síntoma todavía es borroso.
Eso en Proxmox pasa muchísimo.
El panel enseña algo raro y enseguida la cabeza quiere montar una teoría grande. Que si el cluster. Que si red. Que si certificados. Que si el navegador. Que si Ceph. Que si algún bug misterioso. A veces sí. Muchas veces no.
A veces el problema es menos cinematográfico. El nodo lleva días intentando comprobar un storage remoto que responde mal. O arrastra un volumen lógico que ya no existe. O un backend antiguo sigue declarado y pvestatd lo tropieza una y otra vez. La máquina sigue funcionando, pero ya no huele limpia. Y esa suciedad aparece en sitios distintos.
systemctl status pvestatd me sirve justo para detectar esa clase de mugre operativa.
No lo resuelve por sí solo, claro. Pero me ayuda a no perder veinte minutos persiguiendo fantasmas en capas más altas cuando abajo ya tengo un aviso repetido gritándome en la cara.
cómo leo yo esta salida#
No necesito ponerme a interpretar cada byte. Voy a unas cuantas señales muy concretas.
Loaded#
Lo primero es confirmar que el servicio está donde toca y habilitado.
Parece básico. Lo es. Pero precisamente por eso lo quiero bien desde el principio.
Si aquí ya hubiera algo raro, ni siquiera seguiría leyendo con calma. Un servicio mal cargado o no habilitado cambia el tipo de avería que tienes delante.
Active#
Esta línea manda mucho.
En la captura sale active (running) desde hace más de una semana. Eso me dice que pvestatd no está muerto ni acaba de reiniciar por los pelos hace cinco minutos.
Ese detalle temporal me importa bastante.
No es lo mismo un daemon que reapareció hace un momento después de un susto que uno que lleva tiempo arriba, pero conviviendo con errores repetidos. El segundo caso me suele señalar más bien un problema arrastrado, un roce continuo, una configuración fea que nadie ha terminado de arreglar.
Y esas son justo las averías más pesadas porque no rompen del todo. Solo degradan la experiencia del nodo hasta que un día te hartas.
Main PID#
Aquí quiero ver lo evidente. Que el proceso principal es pvestatd y que systemd no está fingiendo una normalidad que en realidad no existe.
No tiene misterio. A veces lo que más ayuda es confirmar una obviedad y seguir con la siguiente pista.
el CGroup#
Aquí es donde la captura se pone interesante.
No solo veo el daemon. Veo además un smbclient colgando de él. Eso me da un contexto muy concreto. El daemon está intentando hablar con un storage remoto CIFS en este momento.
Esto me gusta porque aterriza el problema.
Ya no estoy pensando en “algo va raro” de forma abstracta. Estoy viendo una comprobación real contra un backend real. Si encima al lado me aparecen mensajes de storage offline, la película se ordena sola bastante rápido.
A mí este tipo de detalle me parece oro puro porque separa un nodo “misteriosamente lento” de un nodo que está perdiendo tiempo con una comprobación remota bastante concreta.
las líneas del journal al final#
Aquí es donde suelo quedarme más rato.
Las repeticiones importan. Mucho.
En la captura tengo dos patrones distintos.
Uno me dice que un storage remoto no está online. El otro me dice que no existe el volumen lógico pve/data.
Yo no leo eso como dos simples errores sueltos. Lo leo como dos roces que se están repitiendo y que probablemente ya forman parte del paisaje diario del nodo.
Eso cambia por completo la forma de trabajar.
Si veo una línea aislada, puedo pensar en una incidencia puntual. Si veo el mismo mensaje cada pocos segundos, dejo de tratarlo como anécdota. Ahí ya estoy ante una fuente de ruido constante.
Y el ruido constante en infra acaba pagando intereses.
cuándo lanzo este comando sin pensarlo mucho#
Hay varios escenarios donde me sale automático.
cuando el nodo se siente raro aunque siga vivo#
Este es el caso clásico.
El panel no está muerto. El SSH entra. Incluso puedes hacer cosas. Pero algo huele mal. Una vista tarda. El almacenamiento tarda en refrescar. Un resumen no cuadra. No veo un incendio, pero tampoco veo limpieza.
Ahí pvestatd es una de las primeras capas que reviso.
cuando un storage aparece intermitente#
Si un recurso CIFS, NFS o similar aparece y desaparece, o tarda en resolver, me interesa muchísimo ver si pvestatd lleva rato topándose con él.
No solo por el error en sí. También porque esos backends remotos pueden ir añadiendo fricción a la lectura general del nodo.
cuando sospecho de restos viejos en la configuración#
Lo de no such logical volume pve/data me parece el ejemplo perfecto.
Ese mensaje suele oler a referencia antigua, almacenamiento definido que ya no coincide con la realidad o residuos de una configuración que nadie terminó de limpiar.
Este tipo de cosas no siempre rompe el nodo. Pero sí lo ensucia. Y en Proxmox un nodo sucio suele tomar peores decisiones operativas de lo que parece a simple vista.
después de tocar storage#
Si he cambiado un backend, quitado un volumen, retocado un mount o rehecho una parte del almacenamiento, mirar pvestatd me parece obligatorio. No quiero enterarme por casualidad tres días después de que el daemon sigue tropezando con algo que yo mismo he dejado torcido.
lo que me dice esta salida en el caso real#
A mí me cuenta algo bastante concreto.
El daemon está levantado y parece estable como servicio.
No estoy ante una caída de pvestatd.
Pero el nodo tiene al menos dos frentes de rozamiento. Uno con un storage remoto CIFS que no está online. Otro con una referencia a pve/data que no existe.
Eso no me autoriza a decir que el nodo está roto. Sería exagerado.
Sí me autoriza a decir que el nodo no está limpio. Y para mí esa diferencia es muy importante.
Un nodo puede seguir sirviendo VMs, responder por web y aguantar producción mientras arrastra mensajes de este tipo. Lo he visto muchas veces. El problema es que luego normalizas el ruido, y cuando llega una incidencia de verdad ya no distingues lo esperado de lo anómalo.
Esa es otra razón por la que me gusta revisar pvestatd. Me obliga a limpiar fricción vieja antes de que se convierta en parte de la decoración.
lo que este comando sí me aporta#
Me confirma si el daemon está arriba.
Me enseña desde cuándo.
Me deja ver si hay procesos hijos relevantes colgando del servicio.
Me da una lectura rápida del consumo de memoria y CPU.
Y, sobre todo, me muestra errores recientes que afectan a la capa de estado y almacenamiento del nodo.
Para un primer diagnóstico me parece muchísimo.
lo que este comando no me puede prometer#
Tampoco conviene fliparse.
Que pvestatd salga active (running) no significa que todo el nodo esté perfecto.
No me garantiza que los storages remotos respondan bien.
No me garantiza que el panel se vea fino.
No me garantiza que pveproxy o pvedaemon estén sanos.
No me garantiza que un backup vaya a ir rápido.
No me garantiza que una VM no tenga su propio problema aparte.
Lo que sí hace es enseñarme si la capa que actualiza buena parte del estado visible del nodo está limpia o está tragando errores repetidos. Para mí eso ya cambia mucho la siguiente decisión.
qué suelo mirar justo después#
Si pvestatd me enseña señales feas, suelo seguir por un camino bastante simple.
pvesm statuspara ver el estado del storage desde otra perspectivasystemctl status pveproxy --no-pagersi sospecho que el panel también está sufriendosystemctl status pvedaemon --no-pagersi las acciones del nodo van lentas o raras- revisar
/etc/pve/storage.cfgpara confirmar si sigo arrastrando definiciones viejas - comprobar conectividad real al storage remoto si el error apunta a CIFS o NFS
No hay glamour en esa secuencia. Mejor así. El glamour suele ser enemigo de arreglar cosas.
una opinión poco sexy, el ruido crónico hay que tratarlo como avería#
Aquí tengo una postura bastante clara.
Si pvestatd te repite el mismo error cada pocos segundos o cada pocos minutos, yo no lo trataría como un aviso cosmético. Lo trataría como una avería pendiente, aunque el nodo siga medio funcionando.
¿Por qué?
Porque esos errores repetidos te gastan dos veces.
Primero, porque consumen tiempo real del sistema en comprobaciones inútiles o fallidas.
Segundo, porque te ensucian la observabilidad. Te acostumbras a ver mensajes feos y acabas ignorando demasiado.
Y el día que algo nuevo se rompe, lo pasas por alto porque tu umbral de tolerancia ya está deformado.
A mí esa forma de trabajar me parece una trampa bastante peligrosa.
cómo encaja con otros posts de esta serie#
Si estás siguiendo la racha de comprobaciones de Proxmox que llevo publicando estos días, este comando encaja muy bien entre varias capas que se complementan.
- systemctl status pveproxy en Proxmox: cómo separo un panel web caído de un cluster que en realidad sigue bien
- systemctl status pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras
- pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro
- local-lvm en Proxmox: por qué en un nodo está activo y en otro no, y cómo no sacar conclusiones torpes
Cada uno me responde a una pregunta distinta.
pveproxy me habla del acceso web.
pvedaemon me habla de la ejecución de acciones privilegiadas.
pvesm status me deja ver el storage con una lectura muy directa.
pvestatd me enseña si la propia capa que refresca estado y comprueba recursos está trabajando limpia o mascando errores una y otra vez.
Para mí, juntarlos es una forma bastante sensata de no hacer troubleshooting como un pollo sin cabeza.
mi conclusión#
systemctl status pvestatd me parece de los comandos más útiles cuando Proxmox no está roto del todo, pero ya empieza a tener ese olor raro de nodo con fricción interna. No siempre señala una caída clara. Muchas veces señala algo más valioso, que es un problema repetido de storage o configuración que lleva tiempo contaminando el estado del sistema.
Y prefiero mil veces eso.
Las caídas obvias molestan, pero se ven. Lo peligroso son las piezas que siguen vivas mientras trabajan mal y te van degradando el nodo poco a poco. Ahí pvestatd suele decir bastante más de lo que parece.
Si tu Proxmox se siente extraño y todavía no miras esta salida, yo la metería en la rutina. No tiene épica. Tiene utilidad. En homelab, con eso me sobra.
referencias#
- Documentación oficial de pvestatd
- Documentación oficial de pvesm
- Post relacionado: pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro
- 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 pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras