Storage

zpool get es una lectura seca y útil para saber cómo está configurado un pool ZFS en Proxmox. No arregla nada, pero evita tocar a ciegas.

Uso zfs get como lectura segura antes de tocar datasets o discos de VM en Proxmox. Me permite ver propiedades heredadas, valores locales y diferencias que explican comportamientos raros.

Uso zpool history cuando el storage de Proxmox se comporta raro y necesito dejar de adivinar. No arregla nada, pero enseña qué comandos se ejecutaron sobre el pool y cuándo ocurrió cada cambio.

Uso zpool scrub como mantenimiento preventivo de ZFS en Proxmox. No arregla una mala estrategia de backups, pero me ayuda a detectar corrupción y discos problemáticos a tiempo.

Uso zpool iostat cuando necesito saber si ZFS está trabajando de verdad, si un mirror carga más que otro o si una VM lenta tiene detrás un problema de I/O.

Uso zfs list para bajar del storage genérico de Proxmox al detalle real de datasets, subvolúmenes y zvols. Es la forma rápida de ver quién ocupa espacio antes de tocar VMs o snapshots.

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.

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 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.

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.