Hay una escena bastante común en un homelab con Proxmox. Abres el panel, algo tarda más de la cuenta, una consola no entra, una tarea se queda rara o un nodo aparece con datos que no parecen frescos. La tentación es culpar a la web. Total, es lo que tienes delante.
Yo intento no hacerlo. El panel de Proxmox es solo la cara visible de varias piezas distintas. Puede fallar el acceso HTTP y el cluster seguir bien. Puede cargar la web y estar pmxcfs medio tocado. Puede ir todo bien en apariencia y tener pvedaemon tragándose errores justo debajo.
La diferencia importa. Si culpas al componente equivocado, arreglas el síntoma y dejas el problema real preparando otra visita.
Este es el orden que sigo cuando el panel se comporta raro. No es una ceremonia. Es una forma de no perder media tarde mirando donde no toca.
primero separo acceso de servicio local#
Si el panel no abre desde mi navegador, lo primero que quiero saber es si pveproxy responde en el propio nodo. Para eso uso una prueba local contra el puerto 8006.
| |
Si eso responde, el servicio web está vivo. Entonces miro red, DNS, proxy, firewall o el camino desde mi equipo hasta el nodo. Si no responde, ya no pierdo tiempo con el navegador. El problema está dentro del nodo o en el propio servicio.
Luego confirmo que alguien escucha en el puerto correcto.
| |
Aquí busco una cosa muy simple: que pveproxy esté escuchando. Si no aparece, el panel no está caído por misterio. No hay proceso atendiendo ese puerto. Ya tengo una pista bastante más limpia.
después miro pveproxy sin sacar conclusiones demasiado pronto#
El siguiente paso es mirar el servicio.
| |
systemctl status me da la foto rápida. journalctl me cuenta la película reciente. Reinicios, workers muertos, errores TLS, problemas al leer configuración o quejas repetidas. Esa segunda parte suele ser la importante.
Ojo con esto: que pveproxy esté mal no significa que el cluster esté mal. Significa que la puerta web va mal. Puedes tener VMs corriendo, quorum sano y almacenamiento normal mientras el panel está dando guerra. Por eso no empiezo a tocar HA ni reiniciar nodos solo porque la interfaz no cargue.
Si pveproxy responde pero el panel enseña datos raros, paso a la siguiente capa.
pmxcfs es la pieza que no conviene ignorar#
Proxmox guarda mucha configuración del cluster bajo /etc/pve. Eso no es una carpeta normal. Está respaldada por pmxcfs, el filesystem de configuración del cluster. Cuando esa capa va mal, la web puede cargar pero oler raro.
Lo primero es confirmar que /etc/pve está montado.
| |
También miro qué nodos expone.
| |
Si un nodo no aparece donde debería, o si /etc/pve no está montado como toca, el problema ya no es cosmético. Ahí miro pve-cluster.
| |
Cuando pmxcfs se queja, no me gusta seguir tocando configuración. Prefiero entender primero si hay un problema de quorum, de Corosync o de arranque del servicio. Cambiar cosas mientras la capa que guarda la configuración está rara es una forma bastante elegante de complicarse la vida.
pvedaemon explica muchas tareas fantasma#
Hay otra categoría de problemas que no son exactamente del panel. La web carga, puedes navegar, pero las acciones van mal. Una consola no abre. Una tarea se queda colgada. Un cambio de hardware no aplica. Una operación de storage devuelve un error poco útil.
Ahí miro pvedaemon.
| |
Este servicio está muy cerca de las acciones que lanzas desde la interfaz. Si hay errores de permisos, tareas recientes que petan o llamadas internas que no responden, suele aparecer aquí antes que en una pantalla bonita.
Mi regla es sencilla. Si la web carga pero las acciones fallan, no reinicio el nodo como primera opción. Miro pvedaemon. Un reinicio puede tapar el problema, pero no me dice qué pasó.
pvestatd es el sospechoso cuando las métricas no cuadran#
A veces el panel no está roto. Solo enseña datos que parecen viejos o incoherentes. Uso de CPU que no refresca, almacenamiento que no actualiza bien, nodos que parecen quedarse en una foto antigua.
En esos casos miro pvestatd.
| |
No es el servicio más famoso de Proxmox, pero se nota cuando no hace bien su trabajo. Si las métricas no cuadran, prefiero revisar esta capa antes de asumir que el storage está roto o que el nodo está saturado.
También cruzo con pvesm status si el olor viene del almacenamiento. Muchas veces el panel solo refleja tarde un problema que el CLI ya enseña con más claridad.
el orden que me evita liarla#
Cuando algo va raro, sigo este orden:
- Prueba local al panel con
curl -k https://127.0.0.1:8006/. - Confirmar escucha con
ss -ltnp | grep 8006. - Revisar
pveproxysi el acceso web falla. - Revisar pmxcfs con
mount,/etc/pve/nodesypve-clustersi la configuración parece rara. - Revisar
pvedaemonsi fallan tareas o acciones. - Revisar
pvestatdsi los datos del panel no refrescan o no cuadran. - Solo después miro cluster, HA o storage con más profundidad.
Esto no arregla mágicamente Proxmox. Lo que hace es algo más útil: evita que empieces por el final.
cuándo sí reinicio servicios#
Reiniciar servicios no es pecado. Lo que no me gusta es hacerlo como reflejo.
Si tengo claro que pveproxy está caído y el resto del nodo está sano, reiniciar pveproxy puede tener sentido. Si pvedaemon está acumulando errores tras una actualización, puedo reiniciarlo con cuidado. Pero si pmxcfs o quorum ya vienen raros, no voy servicio por servicio dando golpes a ver qué pasa.
Antes de reiniciar nada, miro tres cosas:
- si el cluster tiene quorum
- si hay tareas en curso
- si el nodo sostiene algo crítico en ese momento
Parece prudencia básica. Lo es. También es justo lo que uno se salta cuando lleva veinte minutos mirando una web que no carga.
señales de que no es solo la web#
Hay señales que me hacen subir el nivel de sospecha:
/etc/pveno monta bien o aparece vacío.- Los nodos visibles en
/etc/pve/nodesno coinciden con lo esperado. journalctl -u pve-clusterenseña problemas repetidos.pveproxyresponde, pero las acciones fallan en varios nodos.- Las métricas no refrescan y
pvestatdacumula errores. - El problema aparece justo después de tocar red, DNS o certificados.
Cuando veo dos o más de esas señales juntas, dejo de pensar en “panel roto”. Pienso en capa de cluster, configuración o servicios internos. Es menos cómodo, pero suele ser más verdad.
conclusión: el panel es el síntoma, no el diagnóstico#
Proxmox tiene una interfaz muy buena, pero cuando algo falla no conviene mirarla como si fuera el sistema entero. El panel es la puerta. Detrás están pveproxy, pmxcfs, pvedaemon, pvestatd, Corosync, HA y el almacenamiento.
Mi forma de trabajar es separar capas. Primero acceso. Después servicio web. Luego configuración compartida. Después acciones y métricas. Solo entonces empiezo a tocar piezas más delicadas.
Desde que sigo ese orden, tardo menos en encontrar el problema y, sobre todo, rompo menos cosas intentando arreglar la equivocada.
tres casos típicos y cómo los separo#
El primer caso es el más simple: el navegador no entra, pero el nodo responde por SSH. Ahí no miro VMs todavía. Lanzo la prueba local contra 127.0.0.1 y confirmo si el puerto 8006 está escuchando. Si funciona en local, tengo casi descartado que Proxmox esté roto por dentro. Me voy a red, DNS, proxy inverso, certificado o firewall. Es una diferencia pequeña, pero ahorra muchísimo ruido.
El segundo caso es más traicionero. El panel carga, pero algunas acciones fallan. Puedes abrir la lista de VMs, pero una consola no entra o una tarea se queda a medias. Aquí pveproxy puede estar sano y aun así la experiencia ser mala. Por eso paso a pvedaemon y a los logs de tareas. Si el problema es una operación interna, reiniciar la web solo te dará una falsa sensación de avance.
El tercer caso es el que menos me gusta: el panel carga y las acciones medio funcionan, pero la configuración parece inconsistente. Nodos que aparecen raro, /etc/pve que no enseña lo esperado o cambios que no se reflejan. En ese punto ya no hablo de interfaz. Hablo de pmxcfs y de la salud del cluster. Si esa capa está rara, no quiero tocar configuración hasta entenderla.
lo que no hago aunque tenga prisa#
No reinicio el nodo como primera respuesta. Es tentador, lo sé. Reiniciar tiene ese encanto falso de “algo hará”. Pero en un cluster puede mover recursos, cortar tareas y convertir un problema pequeño en otro más difícil de leer.
Tampoco reinicio todos los servicios uno detrás de otro. Si haces eso y el problema desaparece, sigues sin saber qué lo arregló. Peor aún: si vuelve dentro de dos días, empiezas desde cero.
Y no mezclo síntomas. Si el panel no carga, investigo acceso y pveproxy. Si las tareas fallan, miro pvedaemon. Si las métricas no cuadran, miro pvestatd. Si /etc/pve está raro, miro pmxcfs y quorum. Cada capa tiene su sitio.
Esta disciplina parece aburrida. Precisamente por eso funciona. Un homelab ya tiene suficientes variables como para añadirle improvisación cada vez que una pantalla tarda en cargar.