Hay una clase de problema en Proxmox que me fastidia bastante porque invita a perder tiempo de forma absurda.
Abres la interfaz web y algo no termina de cuadrar. Tarda demasiado en cargar. Devuelve un error raro. Te echa de una vista. O sencillamente no responde como debería y te deja con la duda de siempre. ¿Se ha roto el panel web o lo que está mal es otra cosa?
En ese momento yo intento no ponerme creativo. Hago una comprobación muy simple.
systemctl status pveproxy
No es un comando espectacular. Justo por eso me gusta. Me lleva directo al servicio que expone la API y la interfaz web de Proxmox en el puerto 8006. Si esa pieza está muerta, ya sé por dónde empezar. Si está viva, ya sé que me toca mirar otra capa y dejar de insultar al navegador antes de tiempo.
Suena básico, sí. También es de las comprobaciones que más rodeos me ahorran.
qué hace exactamente pveproxy#
La propia documentación oficial lo resume bastante bien. pveproxy es el daemon que expone toda la API de Proxmox VE por HTTPS en el puerto 8006. Corre como www-data, tiene permisos limitados y reenvía a pvedaemon las operaciones que necesitan más privilegios.
Dicho en castellano normal, pveproxy es la puerta de entrada del panel web y de la API que usas a diario.
Eso tiene dos consecuencias prácticas.
La primera es obvia. Si pveproxy no está levantado, el panel no va a ir fino por arte de magia.
La segunda es más interesante. Si pveproxy sí está levantado, eso no significa que todo esté perfecto. Solo significa que la puerta de entrada sigue ahí. Luego ya habrá que ver si el problema está en certificados, en red, en el propio nodo, en pvedaemon, en pve-cluster o en cualquier otra capa del invento.
Pero empezar por aquí tiene lógica. Antes de construir una teoría preciosa sobre quorum, DNS, Cloudflare o mala suerte, yo prefiero confirmar si el servicio del panel sigue respirando.
la salida real que me interesa leer#
He preparado esta captura a partir de una salida real de uno de mis nodos Proxmox, sin hostnames privados ni nada que aporte poco fuera del lab.
Lo que me gusta de esta salida es que no intenta impresionar a nadie. No hay gráficas, no hay colorines, no hay falsa sensación de control. Hay justo lo necesario para orientarme.
Veo que el servicio está cargado. Veo que está activo. Veo cuándo arrancó. Veo el proceso principal. Veo varios workers. Y, en este caso concreto, veo además un detalle muy interesante en ExecStartPost que sería facilísimo interpretar mal si uno viene con prisa.
Ese tipo de matices son justo por lo que prefiero mirar el estado de systemd antes de tocar nada más.
por qué este comando me resulta tan rentable#
Porque reduce muchísimo el ruido mental.
Cuando la web de Proxmox falla, es tentador abrir cinco pestañas y empezar a repartir culpas a ciegas. Que si el reverse proxy. Que si el navegador. Que si el certificado. Que si el cluster. Que si ese nodo está raro. Que si igual el problema es más abajo. Al final llevas diez minutos abriendo cosas y todavía no has respondido a la pregunta más simple de todas.
¿El servicio web de Proxmox está activo en este nodo o no?
systemctl status pveproxy me responde eso en segundos.
No arregla nada por sí solo, claro. Pero pone orden. Y a estas alturas he aprendido que en homelab el orden mental vale casi tanto como el comando correcto.
cómo leo la salida sin volverme loco#
No necesito analizar cada línea como si estuviera desactivando una bomba. Voy a por unas pocas señales muy concretas.
Loaded#
Aquí quiero confirmar que el servicio existe donde debe, que systemd lo tiene bien cargado y que está enabled.
No parece gran cosa. Lo es.
Si una máquina viene tocada por paquetes raros, por una actualización a medias o por un arranque poco fino, ver esta línea normal me da una primera capa de tranquilidad. No demuestra que todo esté bien, pero sí que estoy mirando un servicio reconocido, habilitado y gestionado como toca.
Active#
Esta es la línea que más rápido me importa.
Si veo active (running), ya sé que pveproxy no está muerto. Eso no cierra la investigación, pero sí descarta una causa obvia.
También me fijo mucho en el tiempo que lleva activo. En la captura real, el servicio lleva más de una semana arriba. Eso me dice que no estoy ante un reinicio reciente ni ante una recuperación improvisada de hace cinco minutos. Hay continuidad.
Ese detalle cambia bastante la lectura. No es lo mismo un panel que falla con un servicio que acaba de volver que un panel que falla mientras el servicio lleva días estable.
ExecStartPre#
Esta línea me parece interesante porque suele recordar algo que a veces se olvida. Antes de arrancar pveproxy, Proxmox ejecuta pvecm updatecerts --silent.
A mí esto me gusta porque deja claro que la capa de certificados no está totalmente separada del arranque del servicio web. Cuando algo huele a certificados o a nodos desalineados, ya tengo aquí una pista útil de la secuencia real.
No hace falta dramatizarlo. Simplemente me ayuda a recordar que el panel no vive aislado del resto del cluster.
ExecStart#
Aquí no busco misterio. Solo quiero ver que pveproxy start salió con status=0/SUCCESS.
Si esta línea ya viniera rota, perfecto. Investigación enfocada desde el minuto uno.
ExecStartPost#
Esta parte me hizo sonreír la primera vez que la vi en la captura real porque es el tipo de detalle que provoca lecturas torpes.
Sale así.
ExecStartPost=sh -c [ ! -e /var/log/pveam.log ] && /usr/bin/pveupdate (code=exited, status=1/FAILURE)
Y claro, si alguien se queda con el FAILURE a secas, puede salir corriendo a declarar el nodo en llamas. Pero la línea importante está más arriba. El servicio está activo y corriendo.
Esto es justo lo que me gusta de mirar systemctl status con calma. Me obliga a distinguir entre una acción auxiliar que no salió como esperaba y el estado real del servicio principal.
No estoy diciendo que todo FAILURE secundario sea irrelevante. Digo que leer status de forma histérica es una forma fantástica de engañarse solo.
Main PID y workers#
Ver el proceso principal pveproxy es justo lo esperable. Pero lo que me interesa de verdad es que aparezcan también los pveproxy worker.
Eso me confirma algo muy práctico. El servicio no solo está arriba en abstracto. Está levantando sus workers y presentando una pinta razonable de servicio en funcionamiento real.
Cuando el panel va raro, ver los workers me ayuda a no quedarme en la lectura binaria de vivo o muerto. Hay bastante diferencia entre un proceso principal suelto y una estructura de workers que parece normal.
Tampoco me vuelvo místico con el número exacto. Solo quiero ver que hay actividad coherente.
Tasks, Memory y CPU#
Estas métricas no me dan la respuesta definitiva, pero nunca las ignoro.
En la captura, el consumo de memoria y CPU me parece totalmente normal para un servicio que lleva tiempo corriendo y atendiendo peticiones. No veo nada que me grite fuga, bucle o comportamiento absurdo.
Esto me sirve sobre todo para una cosa. Si la web va lenta y aquí el servicio parece cómodo, ya me inclino menos a pensar que el problema es un pveproxy ahogado y más a sospechar de la ruta entre cliente y nodo, de otro servicio por debajo o de un problema puntual del propio cluster.
cuándo lo lanzo yo sin pensarlo demasiado#
Hay varios casos donde este comando me sale automático.
cuando el panel no carga o carga raro#
Este es el caso obvio. Si el 8006 se pone tonto, esta es de las primeras comprobaciones que hago. No porque me dé toda la película, sino porque me evita mirar quince cosas antes de confirmar la más básica.
después de tocar certificados o actualizaciones#
Si he metido mano a actualizaciones del nodo, certificados o piezas que pueden afectar al acceso web, revisar pveproxy me parece casi obligatorio. Es rápido, barato y suele contarme enseguida si voy bien orientado.
cuando un nodo responde por SSH, pero la web no inspira confianza#
Este caso me gusta mucho porque es muy de homelab. Entras por SSH sin problema. El host parece vivo. Pero el panel del nodo concreto se comporta raro. Ahí es donde systemctl status pveproxy me ayuda a separar dos preguntas.
¿El servicio web local está arriba?
¿O el problema está en el camino desde fuera hasta ese servicio?
No es lo mismo. Y conviene saberlo pronto.
cuando quiero decidir si sigo con pveproxy o salto de capa#
Si el servicio está bien, salto rápido a otras comprobaciones.
systemctl status pvedaemonsi sospecho de la capa de acciones privilegiadassystemctl status pve-clustersi la parte de configuración compartida huele rarapvecm statussi el problema parece de quorum o de cluster como talss -ltnp | grep 8006si quiero confirmar de forma muy directa quién escucha en el puerto
Tener ese orden me ahorra bastante improvisación mediocre.
lo que este comando sí me dice#
Me dice si el servicio está cargado.
Me dice si está activo.
Me dice desde cuándo.
Me dice qué proceso principal y qué workers veo.
Me deja una primera lectura de consumo de recursos.
Y me enseña detalles del arranque que a veces contienen pistas muy buenas.
Para una primera pasada me parece muchísimo valor por muy poco esfuerzo.
lo que este comando no me dice, y conviene recordar#
Aquí viene la parte importante para no sobreactuar.
Que pveproxy esté active (running) no significa que el panel funcione perfecto desde tu navegador.
No me confirma que el puerto 8006 sea accesible desde donde estás entrando.
No me confirma que un firewall intermedio no esté molestando.
No me confirma que el certificado sea el que toca.
No me confirma que pvedaemon esté fino.
No me confirma que pve-cluster esté sano.
No me confirma que Corosync vaya bien.
No me confirma siquiera que el propio navegador no esté tragándose una historia extraña de sesión, caché o TLS.
Lo que sí hace es decirme si el servicio web del nodo está arriba y con qué pinta general está arriba.
Eso no lo resuelve todo. Pero filtra muchísimo.
un matiz que me parece clave, web caída no siempre significa cluster roto#
Esto lo he aprendido a base de dar demasiadas vueltas a problemas tontos.
Si un nodo tiene pveproxy caído, puedes tener un problema muy local de acceso web y un cluster que por debajo sigue razonablemente sano.
Y al revés también. Puedes tener pveproxy vivo y el cluster sufriendo por otra capa.
Por eso me gusta tanto arrancar por este comando. Me obliga a separar el panel del resto del sistema. A veces están alineados. A veces no. Pero mezclar ambas cosas desde el principio solo sirve para perder tiempo.
cómo encaja con otros posts de esta serie#
Si vienes siguiendo la racha de comandos de Proxmox que estoy publicando estos días, este me parece una pieza muy natural entre varias capas.
- systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
- pvesh get /cluster/status en Proxmox: la vista cruda que miro cuando la interfaz parece demasiado tranquila
- corosync-cfgtool -s en Proxmox: cómo confirmo si los enlaces del cluster siguen vivos de verdad
Cada uno responde a una pregunta distinta.
pveproxy me habla de la puerta de entrada web y API.
pve-cluster me habla del filesystem compartido del cluster.
pvesh get /cluster/status me enseña la foto administrativa del conjunto.
corosync-cfgtool -s me lleva más abajo, a la red del cluster.
Tener claras esas capas me parece medio troubleshooting hecho.
mi lectura práctica en menos de un minuto#
Cuando lanzo systemctl status pveproxy, hago siempre una secuencia muy simple.
Primero miro si está active (running).
Luego miro desde cuándo.
Después veo si el proceso principal y los workers tienen buena pinta.
Luego reviso si hay líneas de arranque que me den una pista útil.
Y por último echo un vistazo rápido a memoria y CPU, solo para detectar algo groseramente raro.
Esa mini rutina me sirve para responder a la pregunta que más me importa al principio.
¿Sigo persiguiendo el panel web o cambio ya de capa?
La mayoría de las veces, la respuesta sale de ahí bastante rápido.
mi conclusión#
systemctl status pveproxy no es un comando heroico ni una bala de plata, pero me parece de los más rentables cuando la interfaz web de Proxmox empieza a dar mala espina. Me deja confirmar en segundos si el servicio que expone el panel y la API sigue arriba, desde cuándo lo hace y con qué pinta general está funcionando.
Lo mejor no es solo la información que da. Lo mejor es la disciplina que impone. Me obliga a comprobar la capa correcta antes de inventarme historias más sofisticadas de la cuenta.
Y eso, en un homelab donde la mitad de los problemas se agrandan por mirar donde no toca, vale muchísimo.
Si el panel de Proxmox te va raro y todavía no tienes este comando en la rutina, yo lo incorporaría ya. No te va a resolver todos los fallos. Pero sí te va a ahorrar bastantes diagnósticos torpes.
referencias#
- Documentación oficial de pveproxy
- Documentación oficial de Proxmox VE sobre Cluster Manager
- 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/resources –type node en Proxmox: la tabla que uso para ver CPU, RAM y uptime de todos los nodos de un golpe
- Post relacionado: pvesh get /cluster/status en Proxmox: la vista cruda que miro cuando la interfaz parece demasiado tranquila