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.
Hay días en los que Proxmox te mira con cara de niño bueno. Todo verde, ninguna alarma fea, la interfaz carga rápido y uno empieza a pensar que quizá hoy sí puede tocar cosas sin pagar peaje. A mí ese momento me da exactamente la reacción contraria. Cuando un cluster parece demasiado tranquilo, me obligo a revisar lo básico antes de hacer nada que pueda mover piezas importantes.
Lo digo porque ya he aprendido que el desastre raro casi nunca empieza con una explosión cinematográfica. Empieza con una confianza tonta. Un reinicio que parecía inocente. Una actualización lanzada deprisa. Una VM que mueves de nodo porque sí. Dos minutos después estás preguntándote por qué HA no se comporta como esperabas o por qué Corosync decide ponerse estupendo justo hoy.
Hay una discusión que aparece cada poco en cualquier grupo de Proxmox. LXC o VM. Como si hubiera que casarse con una sola cosa y defenderla hasta el final de los tiempos. Yo hace tiempo que me bajé de esa pelea porque en la práctica no me sirve para nada. En mi homelab uso las dos. Y cuanto más tiempo llevo con Proxmox, más claro tengo que la decisión buena no sale de una religión técnica. Sale de saber qué servicio tienes delante y cuánto castigo te puede devolver si eliges mal.
Hay una fase bastante cutre en casi todo homelab con Proxmox. La de decirte a ti mismo que levantar una VM nueva son cinco minutos y luego echar media hora repitiendo siempre lo mismo. Crear la máquina, montar ISO o importar imagen, tocar red, meter clave SSH, actualizar paquetes, instalar cuatro utilidades, corregir alguna tontería del hostname y cruzar los dedos para no haber dejado un usuario raro o una configuración vieja de otra prueba. No es un drama, pero tampoco es serio.
Una de las ideas más engañosas cuando montas un cluster de Proxmox en casa es pensar que repartir cargas significa dejar todos los nodos parecidos. Mismo número de máquinas, memoria parecida, CPU más o menos compensada y una satisfacción estética bastante sospechosa cuando miras la interfaz. Yo he pasado por ahí y no lo recomiendo demasiado.
Con el tiempo he acabado prefiriendo otra cosa. Menos simetría bonita y más intención. Un nodo puede ser el más fuerte y cargar con lo pesado. Otro puede quedarse con servicios persistentes pero tranquilos. Otro puede ser el comodín para mantenimiento, failover o experimentos. Eso, en la práctica, me ha dado un cluster mucho más cómodo que intentar jugar a la igualdad perfecta.
Hay una fase muy concreta en cualquier homelab con Proxmox en la que uno se viene arriba. Montas el cluster, ves los nodos juntos en la interfaz, pruebas una migración y piensas que ya está, que lo serio era llegar hasta ahí. Luego pasan unas semanas, metes más carga, empiezas a mover backups, storage, tráfico de servicios, alguna copia pesada, algún reinicio tonto de switch, y descubres la parte menos sexy del asunto. El cluster no vive de la ilusión. Vive de red estable.