Si me pilla un problema de cluster en Proxmox y necesito una respuesta rápida a la pregunta importante, suelo ir a una frase muy concreta.
¿Hay quorum o no lo hay?
Todo lo demás viene después.
Por eso corosync-quorumtool -s me gusta tanto. No tiene el barniz cómodo de pvecm status. No intenta ser amable. Te suelta la información bastante en seco y se acabó.
Y, sinceramente, a ciertas horas eso me parece perfecto.
Hay comandos que no arreglan nada, pero te ahorran hacer el idiota.
ls -la /etc/pve/nodes es uno de ellos.
No tiene épica. No luce bien en una charla. No impresiona a nadie. Pero cuando un cluster Proxmox empieza a ir raro y no te apetece sacar todavía la caja de herramientas pesada, esta comprobación corta me parece de las más agradecidas.
¿Por qué? Porque me enseña qué nodos sigue exponiendo pmxcfs dentro de la vista compartida de /etc/pve.
Cuando un cluster Proxmox empieza a oler raro, hay una tentación muy humana y muy mala.
Abrir corosync.conf, ver muchas llaves, ponerse serio y empezar a tocar cosas sin haber leído antes el mapa.
Yo intento no hacerlo.
Antes de pensar en cambios, lo que quiero es una lectura corta del cableado lógico del cluster. Qué nodo es cuál. Qué nodeid tiene cada uno. Qué dirección ring0_addr usa el cluster para hablar con él. Y si el nombre que aparece ahí sigue correspondiendo con la historia que yo me estoy contando.
Hay comandos que parecen poca cosa hasta que una noche te ahorran una media hora de tonterías.
cat /etc/pve/.members entra de lleno en esa categoría.
No es el comando más famoso de Proxmox. No sale mucho en tutoriales para principiantes. No tiene ese aire heroico de pvecm status ni el dramatismo de journalctl -u corosync. Pero a mí me gusta muchísimo por una razón muy simple. Me da una foto corta, directa y muy útil de lo que pmxcfs cree que está pasando con el cluster.
Hay una clase de susto de Proxmox que siempre llega mal.
No tienes un error bonito. No tienes un botón rojo. No tienes una frase útil que te diga “mira aquí”. Lo que tienes es una sensación rara. Un nodo tarda. El cluster parece vivo pero no termina de sonar limpio. pvecm status da una foto, sí, pero te falta la película.
Por eso tiro mucho de esto.
1 journalctl -u corosync -n 40 --no-pager No es el comando con mejor marketing de la serie. Tampoco el más cómodo de leer. Pero cuando quiero entender qué está haciendo la red del cluster en los últimos segundos o minutos, pocas cosas me resultan más útiles.
Hay comandos que no arreglan nada, pero te ahorran media hora de estupideces.
Este es uno de ellos.
1 mount | grep "on /etc/pve " Cuando Proxmox empieza con comportamientos grises, yo no siempre salto primero a la web ni a pvecm status. Muchas veces hago esta comprobación antes que nada porque me responde una pregunta muy básica.
/etc/pve sigue siendo el filesystem del cluster o ya estoy mirando otra cosa con cara de carpeta normal.
Hay un punto en cualquier avería de Proxmox donde deja de tener sentido refrescar la web.
Si /etc/pve empieza a comportarse raro, si un nodo parece estar dentro del cluster pero no termina de convencerte, o si el servicio pve-cluster sale activo y aun así todo huele regular, yo dejo de pedirle respuestas a la interfaz. Quiero saber qué viene diciendo pmxcfs de verdad.
Ahí es donde tiro de este comando.
Hay averías de Proxmox que son bastante honestas.
Fallan, te sueltan un mensaje claro y listo. No hace falta montar una tesis.
Y luego están las otras. Las que se presentan con una consola que tarda, una tarea que responde raro, un storage que a veces sale y a veces no, o una acción desde la web que no termina de cuadrar con la sensación del nodo. Ahí es donde systemctl status pvedaemon me da una foto útil, sí, pero muchas veces se me queda corto. Quiero historia reciente. Quiero saber qué ha pasado hace cinco minutos, no solo si el servicio sigue levantado.
Hay momentos en los que Proxmox no está caído, pero tampoco transmite precisamente paz.
El panel carga a medias. Responde raro. Hace un amago extraño después de tocar certificados. O simplemente alguien te dice que hace un rato iba y ahora va distinto. En ese punto, si ya confirmé que el puerto 8006 escucha y que el nodo responde por HTTPS localmente, suelo ir a una pieza que me gusta bastante más que refrescar la web diez veces.
Hay una comprobación que hago muchísimo cuando el panel web de Proxmox se pone raro y todavía no sé si estoy delante de una avería seria o de una pérdida de tiempo con mucho teatro.
La hago desde el propio nodo.
1 curl -k -s -o /dev/null -D - https://127.0.0.1:8006/ A veces la versión corta que tengo en la cabeza es simplemente esta.
1 curl -k https://127.0.0.1:8006/ Luego le añado -s, -o /dev/null y -D - porque lo que quiero ver de verdad son las cabeceras y el código de respuesta, no el HTML entero del login. Pero la idea es la misma. Le estoy preguntando al propio nodo si su panel responde por HTTPS desde dentro.
Hay una pregunta bastante simple que, por algún motivo, mucha gente tarda demasiado en hacer cuando el panel web de Proxmox se pone tonto.
¿Hay algo escuchando en el puerto 8006 o no?
Parece una obviedad. Justamente por eso vale tanto.
Cuando la interfaz falla es muy fácil empezar por donde no toca. El navegador. El certificado. El túnel. El proxy inverso. La VPN. El firewall. El DNS. El cluster entero, ya puestos. Todo eso puede influir, sí. Pero antes de montar una novela prefiero comprobar si el propio nodo está escuchando en el puerto del panel.
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.