Uso zpool list como vistazo rápido al pool ZFS de un nodo Proxmox. Me ayuda a ver capacidad, espacio libre, fragmentación y salud antes de meterme con diagnósticos más largos.
Uso zpool status como primera lectura de salud en los nodos Proxmox con ZFS. No arregla nada por sí solo, pero me dice rápido si el pool está sano o si tengo que dejar de mirar VMs y empezar a mirar discos.
Uso pvesh para leer la red de un nodo Proxmox desde terminal antes de tocar bridges, MTU, VLANs o migraciones. La salida cruda evita muchas suposiciones tontas.
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.