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.
Para una primera lectura uso este comando.
| |
No es la vista más bonita, pero sí una de las más útiles. Me dice qué storage ve ese nodo, si está activo, qué tipo tiene, cuánto espacio libre queda, si es compartido y qué contenido acepta.
la captura real de este post#
La salida viene de un nodo real de mi laboratorio. He saneado nombres, rutas y cualquier pista que no aporta nada. Mantengo los tipos y los números de uso porque ahí está la gracia.
Hay una línea especialmente buena para explicar por qué uso esta comprobación.
| |
Y luego, justo después, Proxmox lista los storages. Esto parece contradictorio si vienes con prisa. No lo es. Lo que está pasando es que el nodo tiene configurado local-lvm, pero en ese nodo concreto no hay volumen lógico detrás. El storage existe en la configuración del cluster, pero no está activo ahí.
Este matiz me ha evitado bastante ruido mental.
active es el campo que miro primero#
La primera columna real es esta.
| |
O esta.
| |
Si active está a 1, el nodo puede usar ese storage ahora mismo. Si está a 0, el storage está definido pero no disponible desde ese nodo. No significa siempre desastre. Puede ser normal. Puede ser un storage local que no existe en todos los nodos. Puede ser un montaje caído. Puede ser una configuración antigua que nadie limpió.
El error tonto es ver el storage en el panel y asumir que está bien. Yo ya no hago eso. Antes de migrar una VM, antes de decidir dónde mover discos, antes de tocar backups, miro si el nodo ve el storage activo.
En un homelab con varios nodos pequeños esto importa mucho. No todos los nodos tienen la misma historia. Uno nació con LVM thin, otro con ZFS, otro se reinstaló, otro heredó una configuración vieja. El cluster enseña una vista común, pero los nodos tienen cicatrices distintas.
enabled no es lo mismo que active#
Este campo también confunde.
| |
enabled me dice que el storage está habilitado en la configuración. No me garantiza que funcione en ese nodo. Un storage puede estar habilitado y no activo.
Esta diferencia parece menor hasta que estás debuggeando. Si enabled está a 0, alguien lo desactivó o el storage no debería participar. Si enabled está a 1 pero active está a 0, tengo una pregunta distinta: por qué el nodo no puede usar algo que el cluster cree habilitado.
Ahí empiezo a mirar tipo de storage, montaje, red, credenciales si es CIFS o NFS, estado de Ceph si es RBD, o existencia real del volumen si es LVM.
Es una lectura muy seca, pero ordena la investigación.
shared decide si puedo pensar en migraciones#
Otro campo que cambia bastante el plan.
| |
Un storage compartido puede ser visible por varios nodos. En la captura aparecen ejemplos típicos: RBD sobre Ceph, PBS y un recurso CIFS del NAS.
Un storage no compartido es otra liga.
| |
local suele ser local al nodo. Puede contener ISOs, plantillas, snippets o backups puntuales. No quiero dejar discos de VMs importantes ahí si pretendo moverlas alegremente entre nodos.
Mi regla mental es simple. Si una VM necesita poder migrar sin baile raro, sus discos tienen que estar en storage compartido o tengo que aceptar una migración con copia de disco. Si una ISO está en local, no pasa nada. Si el disco principal de algo crítico está en local porque un día lo hice rápido, eso sí me molesta.
shared no me dice toda la historia, pero me obliga a hacer la pregunta correcta.
content: el storage puede estar sano y aun así no servir para lo que quiero#
Este campo es de los que más se ignoran.
| |
O este.
| |
No todos los storages aceptan lo mismo. Algunos son para discos de VMs y contenedores. Otros son para ISOs, plantillas y snippets. Otros son para backups. Si intento usar un storage para algo que no acepta, Proxmox no está siendo caprichoso cuando se queja.
Esto se nota mucho al crear máquinas rápido. Quieres levantar una VM, eliges un storage que aparece en el desplegable y luego algo no cuadra. O intentas guardar un backup en un sitio pensado para imágenes. O quieres poner snippets de cloud-init donde no toca.
Cuando miro content, separo mentalmente los almacenes por función.
local para ISOs y plantillas pequeñas.
vm-storage para discos de VMs y contenedores.
backup-pbs para backups.
nas-archive para archivo, plantillas, backups o cosas menos calientes.
No digo que esa sea la única estructura válida. Digo que cada storage tiene que tener un trabajo claro. Si todo vale para todo, acabas sin saber dónde vive nada.
type: aquí se ve el carácter del almacenamiento#
La salida mezcla varios tipos.
| |
Cada uno tiene sus manías.
dir es sencillo. Una ruta en el sistema de ficheros. Perfecto para ISOs, snippets y cosas locales. No le pediría alta disponibilidad.
rbd normalmente apunta a Ceph. Me gusta para discos de VMs porque es compartido y encaja bien con migraciones dentro del cluster. También exige que Ceph esté sano. Si Ceph está raro, ese storage no es mágico.
pbs es Proxmox Backup Server. No lo trato como un disco más. Es mi destino de backups, con su propia lógica, deduplicación y retención.
lvmthin es muy útil cuando existe de verdad. Cuando no existe en un nodo, como en la captura, conviene no fingir que sí.
cifs es cómodo para conectar un NAS, pero tiene su propia fragilidad. Red, credenciales, permisos y disponibilidad del NAS. Si falla, puede parecer un problema de Proxmox cuando en realidad es un montaje que no responde.
Leer el tipo me ayuda a no diagnosticar todo igual.
espacio libre: miro porcentaje, pero también contexto#
La salida da números en bytes.
| |
used_fraction es lo más rápido de leer. En ese caso, más o menos un 14% usado. Cómodo.
Pero no me quedo solo con el porcentaje. Un PBS al 95% no significa lo mismo que un local al 95%. Un storage de backups puede tener retención, pruning y garbage collection. Un disco local lleno puede romper tareas mucho más tontas. Un NAS grande al 37% quizá todavía tiene decenas de terabytes libres, pero puede ir lento si el montaje está saturado o si el propio NAS está ocupado.
El porcentaje responde a una pregunta: cuánto queda.
No responde a estas otras: si el storage es rápido, si está sano, si tiene latencia rara, si está montado por una red decente o si ese espacio libre es apropiado para lo que voy a meter.
Por eso uso este comando como primera lectura, no como diagnóstico final.
el caso feo: backup al 95%#
En la captura hay un PBS bastante lleno.
| |
Esto no lo ignoro. Un backup storage cerca del límite no siempre va a romper hoy, pero ya está pidiendo atención. Puede que haya retenciones demasiado generosas. Puede que falte una pasada de garbage collection. Puede que haya backups antiguos que ya no tienen sentido. Puede que simplemente toque ampliar.
Lo que no hago es seguir metiendo backups nuevos como si nada.
Antes reviso desde PBS o desde Proxmox.
| |
O miro tareas y retenciones desde la interfaz de PBS. No borro a ciegas. En backups, borrar rápido es una forma elegante de fabricarte un problema peor que el espacio lleno.
Si el storage de backups está alto, mi siguiente pregunta es cuándo fue el último backup bueno y qué política de retención está aplicada. El espacio libre importa, pero recuperar importa más.
local-lvm inactivo no siempre es una avería#
Este bloque es el que más me interesa de la captura.
| |
Visto con nervios, parece mal. Visto con contexto, puede ser normal. Hay nodos donde local-lvm existe y otros donde no. Hay instalaciones que conservaron la entrada en el cluster aunque el layout real del disco cambió. Hay nodos que arrancan de ZFS o de otro esquema y no tienen ese thin pool.
El problema aparece cuando una VM apunta a ese storage en un nodo donde no existe. O cuando una plantilla antigua espera encontrarlo. O cuando tú, con sueño, eliges local-lvm porque te sonaba bien.
Por eso me gusta que el comando lo deje tan claro. Activo cero. Total cero. No hay mucho que interpretar.
Si fuera un entorno más ordenado, limpiaría la configuración para que no aparezca donde no debe. En homelab a veces lo dejo si no molesta, pero lo documento. La deuda pequeña no mata, pero la deuda invisible sí.
cómo lo cruzo con otros comandos#
Esta salida no vive sola.
Si el storage es Ceph, miro salud.
| |
Si sospecho de un montaje CIFS o NFS, miro mounts y logs.
| |
Si quiero ver la configuración global del cluster, reviso.
| |
Y si estoy preparando mantenimiento, combino storage con recursos del nodo.
| |
La idea es no mirar storage como si fuera una isla. El almacenamiento toca red, CPU, backups, migraciones, HA y estado del cluster. Si falla, casi nunca falla solo.
mi rutina antes de mover una VM#
Cuando voy a mover una VM o tocar un nodo, hago una pasada corta.
Primero miro qué storage ve el nodo origen.
| |
Luego miro el nodo destino. No asumo simetría.
| |
Después compruebo si los discos de la VM están en storage compartido.
| |
Si están en RBD o en otro storage compartido sano, la migración suele ser más limpia. Si están en local, ya sé que hay copia de disco o decisión pendiente.
Y si veo algo al 95%, paro. No porque no se pueda hacer nada, sino porque no quiero meter más cambios encima de un storage que ya está gritando bajito.
lo que este comando no te cuenta#
No te dice si un disco físico está muriendo. Para eso necesitas SMART, ZFS, Ceph o la herramienta que toque.
No te dice si el NAS está saturado. Solo te dice si el storage aparece activo y con espacio.
No te dice si PBS ha hecho garbage collection correctamente.
No te dice si una VM tiene snapshots enormes que explican parte del consumo.
Y no te dice si el rendimiento es bueno. Un storage puede estar activo, tener espacio libre y aun así ir fatal por latencia o red.
Pero como primera comprobación es muy buena. En menos de diez segundos separa tres situaciones que no conviene mezclar: storage sano y usable, storage configurado pero inactivo, y storage casi lleno.
por qué prefiero verlo así#
El panel de Proxmox está bien. Lo uso todos los días. Pero para mantenimiento me gusta tener salidas que pueda copiar, comparar y guardar. pvesh get /nodes/<nodo>/storage me da una lectura cruda y bastante honesta del nodo.
No decide por mí. Mejor. Solo me enseña lo que hay.
Y en almacenamiento, saber lo que hay antes de tocar nada vale más que cualquier intuición. Las intuiciones no restauran backups, no migran discos y no arreglan un PBS lleno. Este comando tampoco, pero al menos me pone mirando al sitio correcto.