El almacenamiento en Proxmox tiene una forma especial de mentirte sin mentirte. El panel puede enseñar un storage como configurado, el cluster puede tenerlo definido en /etc/pve/storage.cfg, las VMs pueden apuntar a él y aun así, en un nodo concreto, ese storage puede no estar usable.
Esto se nota mucho en clusters caseros. Tienes discos locales, Ceph o RBD, un PBS, algún recurso CIFS o NFS en el NAS, quizá un local-lvm que solo existe de verdad en algunos nodos. Todo parece ordenado hasta que intentas arrancar una VM, hacer backup o migrar algo y Proxmox te responde con un error que suena mucho más grave de lo que realmente es.
Hay una zona de Proxmox que mucha gente mira solo cuando algo ya ha explotado. Las tareas recientes.
Yo intento mirarlas antes.
Cuando un nodo se comporta raro, una VM aparece apagada, un backup falla o una acción del panel no termina como esperaba, una de las primeras cosas que lanzo es esto.
1 pvesh get /nodes/proxmox-node-3/tasks --limit 12 --output-format yaml Es una forma rápida de preguntarle al nodo qué ha pasado hace poco. No lo que yo creo que pasó. No lo que recuerdo haber tocado mientras tenía tres pestañas abiertas. Lo que Proxmox ha registrado como tarea.
Hay días en los que no quiero abrir el panel de Proxmox. No porque la interfaz sea mala, sino porque a veces necesito una lectura más seca del nodo antes de contaminarme con colores, gráficas y esa falsa tranquilidad que da ver una pantalla cargada.
Para eso uso bastante este comando.
1 pvesh get /nodes/proxmox-node-3/status --output-format yaml pvesh es de esas herramientas que parecen feas hasta que te salva media tarde. Es la API de Proxmox desde la terminal. Lo que ves en la web, con más o menos capas, sale de ahí. Y cuando estoy tocando un nodo concreto, me gusta tener una foto rápida de CPU, memoria, kernel, versión de PVE, disco raíz, swap y uptime sin depender de que el navegador esté fino.
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.
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 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.
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 fallos que se agradecen porque son honestos. El servicio no arranca, el nodo se cae o el storage sale claramente inactivo y ya sabes que toca arreglar algo. Luego están los otros, los que te miran a la cara con media verdad. Esta madrugada me encontré justo uno de esos en Proxmox.
Tenía un storage CIFS configurado en el cluster para usarlo con ISOs, backups puntuales y algún archivo compartido. Nada exótico. Lo raro fue esto. En dos nodos el recurso seguía apareciendo montado, el mount lo enseñaba sin rubor y, si te quedabas en la superficie, podías pensar que el problema era menor. Pero en cuanto intentaba tocar ese punto de montaje con df -h, la respuesta era bastante menos diplomática. Host is down.
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.