Hay comandos que uso para diagnosticar un problema. Y luego hay comandos que uso para no perder el tiempo antes de que el problema exista de verdad.
pvesh get /cluster/resources --type node pertenece clarísimamente al segundo grupo.
No es el más famoso de Proxmox. No tiene el aura de pvecm status, que sigue siendo el rey cuando quiero hablar de quorum. Tampoco tiene el punto bruto de pveperf, que ya conté en pveperf en Proxmox: la prueba rápida que hago para leer CPU, disco y fsync antes de culpar al nodo. Pero este comando tiene una virtud muy concreta que me encanta. Me enseña la foto corta de todos los nodos a la vez.
Hay días en los que la interfaz web de Proxmox me parece demasiado educada.
Carga. Responde. Todo sigue más o menos en su sitio. Los nodos aparecen. Las VMs no se han caído. Y sin embargo noto esa sensación fea de que la foto está demasiado limpia para lo que ha pasado hace cinco minutos. Igual ha habido un reinicio raro. Igual una migración tardó más de la cuenta. Igual un nodo respondió lento y no me apetece fiarme solo de lo bonita que venga la web hoy.
Cuando una VM va torpe y hay storage compartido de por medio, la tentación es preciosa. Todo el mundo mira a Ceph, pone cara grave y empieza a hablar de latencia como si ya supiera qué pasa. Yo intento no entrar tan rápido en esa película.
Antes de abrir la interfaz, antes de ponerme a revisar gráficas y antes de culpar al cluster entero, lanzo ceph -s.
No porque el comando me vaya a explicar toda la historia. No lo hace. Pero sí porque me da en pocos segundos una lectura muy útil del tono real del cluster. Si está limpio, si viene tocado, si hay PGs degradadas, si hay OSDs en un estado raro o si el problema ya lleva rato dejando huellas bastante visibles.
Hay comandos que no parecen gran cosa hasta que te ahorran media tarde de diagnósticos torpes. pveperf está en esa categoría.
No es bonito. No es moderno. No sirve para enseñar una captura impresionante en redes. Pero a mí me resulta muy útil porque me da en segundos una foto bastante honesta del nodo Proxmox antes de hacer dos cosas que salen caras cuando las haces mal. Actualizar confiado y culpar al cluster de algo que en realidad es culpa del host.
Hay días en los que abro pvecm status porque quiero una foto completa del cluster. Y hay días en los que no necesito toda la película. Necesito saber una cosa muy concreta y la necesito ya. Qué nodos siguen dentro del cluster, con qué voto aparecen y desde cuál estoy consultando. Para eso pvecm nodes me parece bastante mejor de lo que mucha gente le concede.
No vende humo. No da métricas elegantes. No pretende ser un panel de salud. Es una comprobación corta, seca y muy útil cuando el objetivo no es admirar el cluster, sino evitar una tontería antes de tocarlo.
Hay comandos que parecen un trámite y luego están los que te evitan una noche de mierda. pveversion -v está en el segundo grupo.
Yo lo uso antes de actualizar un nodo Proxmox, antes de reiniciarlo y también cuando algo ya huele raro y quiero saber si el problema viene de una capa más aburrida de lo que me gustaría admitir. Porque sí, en homelab nos encanta echarle la culpa a Ceph, a Corosync, al storage compartido o a esa VM caprichosa que siempre aparece en el momento menos elegante. Pero muchas veces el drama empieza antes, en algo tan poco glamuroso como una versión que no cuadra, un kernel viejo todavía dando vueltas o un paquete medio roto que nadie miró con calma.
Hay reinicios que dan pereza y hay reinicios que me ponen de mal humor antes de empezar. Los segundos suelen ser los de Proxmox cuando sé que el nodo lleva varios kernels instalados, una tanda de paquetes reciente y un contexto de arranque que no tengo fresco en la cabeza.
No porque Proxmox arranque mal. Suele arrancar bastante bien. El problema es otro. El problema es que en homelab es facilísimo pensar que conocer el kernel en uso ya es suficiente. No lo es.
La alta disponibilidad en homelab tiene una capacidad especial para volvernos optimistas cuando no toca. Montas HA, ves que una VM arranca en otro nodo, te vienes arriba y empiezas a pensar que el cluster ya se cuida solo. Luego llega una noche cualquiera, abres una shell, ves cuatro líneas en verde y decides reiniciar un host porque total, para eso está la magia. Ahí suele empezar la parte divertida.
Hay comandos poco glamourosos que acaban siendo los más rentables del homelab. qm list y pct list están muy arriba en esa categoría. No salen en casi ningún tutorial bonito, no sirven para presumir en una captura con lucecitas y, aun así, me han evitado más reinicios torpes que muchas herramientas más sofisticadas.
Yo los uso sobre todo antes de tocar un nodo. Da igual si voy a actualizar, reiniciar, revisar almacenamiento o simplemente quitarme una duda. Antes quiero saber qué máquinas virtuales y qué contenedores viven ahí en ese momento. No lo que creo recordar, no lo que imaginé ayer, no lo que “seguro que ya estaba apagado”. Lo que está de verdad.
No me preocupa actualizar Proxmox. Lo que me preocupa es hacerlo con esa falsa tranquilidad de quien ve cuatro checks verdes y piensa que ya está todo bajo control. En un nodo suelto ya hay margen para liarla. En un cluster pequeño, todavía más. No porque Proxmox sea frágil, sino porque en casa solemos mezclar infra razonable con decisiones que tomamos medio dormidos.
Mi experiencia con esto es bastante simple. Los upgrades salen bien cuando llegas con contexto. Se tuercen cuando entras con prisa, ejecutas apt full-upgrade porque hoy te viene bien y solo después descubres que había un paquete raro, un nodo con quorum justo o una VM donde no tocaba.
Una de las cosas que más me gustan de Proxmox es que te deja ver bastante verdad si preguntas bien. Una de las cosas que más me fastidian es que también te deja interpretar mal esa verdad si vas demasiado deprisa. local-lvm es un ejemplo perfecto.
Esta madrugada estuve comparando el estado de almacenamiento de tres nodos del mismo cluster. En dos de ellos, local-lvm aparecía activo, con su thin pool funcionando y varios discos locales viviendo ahí. En el tercero, la historia era otra. local-lvm salía inactivo y el sistema escupía un mensaje bastante poco ambiguo. no such logical volume pve/data.
Hay comandos que parecen poca cosa y luego te acaban enseñando medio estado del sistema si los lees con un poco de mala leche. pvesm status es uno de esos. Mucha gente lo abre, confirma que hay varios active, ve porcentajes que no dan miedo inmediato y pasa a otra cosa. Yo ya no lo hago así.
Con los años he aprendido que el almacenamiento en Proxmox rara vez te avisa con un único dramatismo limpio. Más bien va dejando señales pequeñas. Un storage que sigue activo pero ya va demasiado lleno. Un local-lvm que aparece inactivo y no sabes si es normal o una chapuza heredada. Un backup server que aún aguanta, pero está más cerca del borde de lo que te gustaría admitir. Nada de eso suena a tragedia instantánea. Precisamente por eso conviene mirar bien.