Almacenamiento de Proxmox “no disponible en el nodo”: por qué existe pero no puedes usarlo

noviembre 21, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 9

¿Te fue útil?

Abres la interfaz de Proxmox, ves tu almacenamiento listado y luego—bam—«no disponible en el nodo». El almacenamiento está ahí, como una plaza de aparcamiento reservada con un cono de tráfico encima. No puedes usarlo, las migraciones fallan, las copias de seguridad se bloquean, y la próxima ventana de mantenimiento empieza a parecer una negociación por rehenes.

Este error es Proxmox hablando claro: la configuración del clúster conoce un ID de almacenamiento, pero este nodo no puede acceder a él ahora mismo (o no debe). El truco es separar “la definición existe” de “el almacenamiento es accesible, está montado, autenticado y soporta la operación solicitada”. Esa separación es donde viven la mayoría de los incidentes.

Qué significa realmente “not available on node”

En Proxmox VE, las definiciones de almacenamiento son objetos de configuración con alcance de clúster, almacenados en /etc/pve/storage.cfg (un archivo servido por el sistema de ficheros del clúster). Cuando defines un almacenamiento llamado fast-nfs, Proxmox lo recuerda en todos lados. Eso no significa que cada nodo pueda realmente usarlo. Proxmox distingue entre:

La definición de almacenamiento existe: el ID está presente en la configuración y aparece en la interfaz.
El almacenamiento está activo en un nodo: el nodo puede alcanzar el backend (el montaje existe, el pool importado, Ceph sano, la autenticación funciona, la ruta existe, permisos correctos).
El almacenamiento admite el contenido solicitado: intentas poner discos de VM en un almacenamiento que solo acepta ISO/plantillas, o viceversa.
El almacenamiento está permitido en el nodo: el almacenamiento está restringido por la opción nodes, o el nombre del nodo no coincide con lo que espera la configuración.

El mensaje “not available on node” es la forma de Proxmox de decir: para este nodo, la verificación de activación falló o el almacenamiento está deliberadamente excluido. Proxmox a menudo tiene suficiente información para mostrar el almacenamiento en la lista, pero no suficiente tubería funcional para realizar operaciones de forma segura.

Las categorías raíz comunes

La mayoría de los casos encajan en uno de estos cubos:

Problemas de alcance / direccionamiento: el almacenamiento está configurado para un subconjunto de nodos, o hay un desajuste de nombre de nodo tras reinstalar/renombrar.
Problemas de montaje / ruta: NFS/CIFS no montado, punto de montaje ausente, ruta incorrecta, fstab no persistente, problemas de orden con systemd.
Autenticación/permisos: keyrings de Ceph, credenciales SMB, permisos de exportación NFS, problemas de propiedad/modo Unix.
Backend no sano: Ceph degradado/caído, pool ZFS no importado, VG LVM ausente, sesión iSCSI muerta, multipath roto.
Desajuste de contenido y formato: intentar almacenar images en un dir sin el formato adecuado, o usar almacenamiento local para suposiciones de migración HA.

El almacenamiento en Proxmox no es magia. Es un conjunto de adaptadores alrededor de primitivas de almacenamiento de Linux, y Linux es muy literal. Si tu nodo no puede montarlo, importarlo, iniciar sesión o verlo, Proxmox no fingirá.

Broma #1: El almacenamiento es como una máquina de café: todo el mundo nota cuando está rota, y nadie recuerda quién la instaló.

Guía de diagnóstico rápido (primero/segundo/tercero)

Si estás de guardia, no quieres una lección de filosofía. Quieres el camino más corto a “¿esto es una restricción de configuración, un problema de montaje o una caída del backend?”. Aquí está el orden que minimiza tiempo perdido.

Primero: confirma si está intencionadamente excluido

¿El almacenamiento está restringido a ciertos nodos en storage.cfg?
¿Coincide el nombre del nodo con la configuración (especialmente tras una reinstalación)?
¿Estás en un split-brain / problema de comunicaciones del clúster donde /etc/pve difiere?

Si está excluido, la solución es de configuración, no de infraestructura.

Segundo: confirma que el SO puede ver/montar/importar el backend

NFS/CIFS: ¿está montado? ¿resuelve DNS? ¿puede el kernel alcanzar el servidor?
ZFS: ¿está el pool importado? ¿Errores de E/S?
LVM: ¿existe el VG? ¿están presentes los PV?
Ceph: ¿ceph -s parece sano? ¿Tenemos monitores/cuórum?
iSCSI: ¿las sesiones están logueadas? ¿Multipath sano?

Si el SO no puede usarlo, Proxmox tampoco. No depures Proxmox hasta que Linux funcione.

Tercero: confirma tipos de contenido y expectativas de ruta

¿El almacenamiento permite images, rootdir, backup, etc.?
Para dir: ¿existe el directorio y es escribible por root?
Para almacenamiento basado en ficheros: ¿hay espacio? ¿Se han agotado los inodos?

Aquí es donde “se monta bien” aún falla porque Proxmox se niega a colocar discos de VM en un almacenamiento solo para ISO, o porque la ruta es de solo lectura.

Tipos de almacenamiento y sus modos de fallo específicos

Dir storage (directorio local, NFS montado en un directorio, etc.)

Por qué falla: punto de montaje ausente, opciones de montaje incorrectas, montaje en solo lectura, problemas de permisos, desajuste de ruta, manejadores NFS obsoletos, o el directorio existe pero está en el filesystem equivocado (pensabas que era NFS; en realidad es la raíz local).

Qué verifica Proxmox: que la ruta exista, sea accesible y que el nodo esté permitido. No hará una comprobación exhaustiva de que montaste “la cosa correcta”—así que debes hacerlo tú.

NFS storage

Por qué falla: permisos de exportación, firewall, DNS, servidor caído, cliente atrapado en montajes “soft”, o montajes systemd no listos en el arranque. Las fallas de NFS suelen ser “funciona” hasta que dejan de funcionar, porque la metadata en caché enmascara problemas.

Opinión operativa: usa montajes hard para discos de VM, pero entiende que la E/S colgada bloqueará procesos. Ese es el trade-off: integridad de datos vs. disponibilidad. Para backups puedes ser más flexible.

CIFS/SMB storage

Por qué falla: credenciales expiradas/rotadas, incompatibilidad de dialecto SMB, problemas con AD, o falta del helper de montaje. También: los servidores Windows adoran los cambios “útiles”.

Qué falla silenciosamente: el montaje puede existir pero estar desconectado; solo lo descubres cuando las escrituras empiezan a fallar.

ZFS (local)

Por qué falla: pool no importado tras reinicio, renombrado de dispositivos, rutas by-id faltantes, pool degradado con errores de E/S, o creaste el pool en un nodo y esperas verlo en otro (eso no es almacenamiento compartido; es optimismo).

Realidad HA: ZFS local es excelente. No es almacenamiento compartido. Si quieres migración en vivo sin storage compartido, necesitas replicación o Ceph—y aceptar el coste operativo.

LVM / LVM-thin (bloque local)

Por qué falla: VG faltante porque disco no presente, cambio de UUID de PV, reglas de filtro en lvm.conf, o problemas de activación. Los thin pools también fallan de formas emocionantes si la metadata se llena.

Ceph (RBD/CephFS)

Por qué falla: monitores sin cuórum, OSDs caídos, problemas de red, keyrings desajustados, ceph.conf en la ruta equivocada, o estás apuntando un nodo al nombre/fSID de clúster incorrecto. Ceph también falla cuando está “casi sano” pero lento: puedes ver disponibilidad pero no usabilidad.

Opinión: Ceph es maravilloso cuando lo gestionas como un producto, no como una misión secundaria.

iSCSI (a menudo con LVM encima)

Por qué falla: sesiones caen, desajuste CHAP, multipath mal configurado, IDs de LUN cambian, o olvidas la persistencia tras reinicio. iSCSI tiende a fallar a las 02:00, porque claro que sí.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estos son los chequeos de grado producción que ejecuto cuando aparece “storage not available on node”. Cada tarea incluye (a) un comando, (b) qué significa una salida típica, y (c) la decisión que tomas a continuación. Ejecútalos en el nodo afectado primero.

Task 1: Ask Proxmox what it thinks is active

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active        102334976       22110208        75053056    21.61%
fast-nfs         nfs      inactive               0              0               0     0.00%
ceph-rbd         rbd      active                0              0               0     0.00%

Meaning: Proxmox storage manager (pvesm) declares fast-nfs inactive on this node. That’s the canonical signal: Proxmox can’t activate it.

Decision: move to mount/backend checks. If the status is active but GUI says unavailable, suspect node restrictions or cluster config inconsistency.

Task 2: Confirm the storage definition and node restrictions

cr0x@server:~$ grep -A5 -n "nfs: fast-nfs" /etc/pve/storage.cfg
27:nfs: fast-nfs
28:        export /exports/proxmox
29:        path /mnt/pve/fast-nfs
30:        server 10.20.30.40
31:        content images,backup,iso
32:        nodes pve01,pve02

Meaning: This storage is explicitly limited to pve01,pve02. If you’re on pve03, it will be “not available” by design.

Decision: either add the node to the list (if it should access it) or stop trying to use it from this node.

Task 3: Verify the node name Proxmox uses

cr0x@server:~$ hostname
pve03

Meaning: Node name is pve03. If storage.cfg says pve3 or the old hostname, restrictions won’t match.

Decision: fix storage node list or correct hostname consistently (host rename in Proxmox is non-trivial; prefer fixing config).

Task 4: Check if the mountpoint exists and what filesystem it is

cr0x@server:~$ findmnt /mnt/pve/fast-nfs
TARGET            SOURCE             FSTYPE OPTIONS
/mnt/pve/fast-nfs 10.20.30.40:/exports/proxmox nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys

Meaning: It’s mounted and it’s actually NFS4 from the expected server/export. Good sign.

Decision: if findmnt shows nothing, mount is missing; if it shows ext4 or zfs, you mounted the wrong thing or didn’t mount at all.

Task 5: If it’s missing, check systemd mount and fstab ordering

cr0x@server:~$ systemctl status mnt-pve-fast\\x2dnfs.mount
● mnt-pve-fast\x2dnfs.mount - /mnt/pve/fast-nfs
     Loaded: loaded (/etc/fstab; generated)
     Active: failed (Result: exit-code) since Fri 2025-12-26 07:12:20 UTC; 3min ago
      Where: /mnt/pve/fast-nfs
      What:  10.20.30.40:/exports/proxmox
      Docs:  man:fstab(5)
             man:systemd-fstab-generator(8)
    Process: 1442 ExecMount=/usr/bin/mount 10.20.30.40:/exports/proxmox /mnt/pve/fast-nfs (code=exited, status=32)

Meaning: The mount unit failed; status 32 usually means mount failure (network, permission, server).

Decision: check network reachability and NFS export permissions next.

Task 6: Verify network reachability and name resolution

cr0x@server:~$ ping -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=0.462 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.417 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1012ms
rtt min/avg/max/mdev = 0.417/0.439/0.462/0.022 ms

Meaning: Basic connectivity is fine. This does not prove NFS works, but it eliminates “the server is gone” quickly.

Decision: check TCP/UDP ports and export access.

Task 7: Query NFS exports from the client side

cr0x@server:~$ showmount -e 10.20.30.40
Export list for 10.20.30.40:
/exports/proxmox 10.20.30.0/24

Meaning: Export exists and is offered to your subnet. If your node is in another subnet/VLAN, you just found your problem.

Decision: if the export list is empty or access denied, fix server-side NFS exports/firewall.

Task 8: Try a manual mount with verbose errors

cr0x@server:~$ mount -v -t nfs4 -o vers=4.2 10.20.30.40:/exports/proxmox /mnt/pve/fast-nfs
mount.nfs4: timeout set for Fri Dec 26 07:17:40 2025
mount.nfs4: trying text-based options 'vers=4.2,addr=10.20.30.40,clientaddr=10.20.30.53'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting 10.20.30.40:/exports/proxmox

Meaning: Classic: network is fine, export exists, but server denies this client (wrong export rules, root_squash issues combined with expectations, or missing host allowlist).

Decision: adjust exports on the NFS server; Proxmox config changes won’t help.

Task 9: Confirm the directory is writable and not lying to you

cr0x@server:~$ touch /mnt/pve/fast-nfs/.pve-write-test && echo "ok" || echo "fail"
ok

Meaning: The mount is writable as root (or at least this write succeeded). If it fails with “Read-only file system” or “Permission denied,” Proxmox will have a bad day.

Decision: fix mount options, server export permissions, or underlying filesystem health.

Task 10: Check permissions/ownership for dir storage paths

cr0x@server:~$ ls -ld /mnt/pve/fast-nfs
drwxr-xr-x 9 root root 4096 Dec 26 07:11 /mnt/pve/fast-nfs

Meaning: Root has access. That’s typically sufficient because Proxmox storage operations run as root. If you see weird ownership due to squashing or ACLs, expect failures creating subdirs like dump or template.

Decision: ensure the NFS export and filesystem permissions allow root writes (or align to Proxmox’s expectations with proper UID/GID mapping).

Task 11: Verify content types match what you’re trying to do

cr0x@server:~$ pvesm config fast-nfs
content images,backup,iso
export /exports/proxmox
path /mnt/pve/fast-nfs
server 10.20.30.40
type nfs

Meaning: This storage permits VM disk images, backups, and ISOs. If your failure was “unable to create CT volume,” you might be missing rootdir.

Decision: adjust content appropriately. Don’t over-permit content types unless you actually want them there (it reduces guardrails).

Task 12: Look for Proxmox logs that explain activation failures

cr0x@server:~$ journalctl -u pvedaemon -u pve-storage -n 80 --no-pager
Dec 26 07:12:21 pve03 pvedaemon[1321]: storage 'fast-nfs' is not online
Dec 26 07:12:21 pve03 pvedaemon[1321]: mount error: permission denied for 10.20.30.40:/exports/proxmox
Dec 26 07:12:22 pve03 pvedaemon[1321]: TASK ERROR: storage 'fast-nfs' is not available on node 'pve03'

Meaning: You get the real reason: mount permission denied. The GUI rarely tells you this cleanly.

Decision: fix the backend. Stop poking at the UI.

Task 13: If it’s ZFS, confirm pool import and health

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          nvme0n1p3 ONLINE       0     0     0

errors: No known data errors

Meaning: Pool is healthy. If your storage is a ZFS pool called tank and it’s not listed, it’s not imported.

Decision: if missing, attempt zpool import and investigate device paths and by-id stability.

Task 14: If it’s ZFS and missing, list importable pools

cr0x@server:~$ zpool import
  pool: tank
    id: 1234567890123456789
 state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          sdb       ONLINE

Meaning: The pool exists but isn’t imported. After reboot, this usually means auto-import didn’t happen or devices arrived late.

Decision: import it (zpool import tank) and then fix boot ordering or device naming to prevent recurrence.

Task 15: If it’s LVM-thin, confirm VG and thinpool presence

cr0x@server:~$ vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  pve          1   2   0 wz--n-  930.00g  10.00g

Meaning: The VG exists. If Proxmox says LVM storage unavailable and vgs shows nothing, the disk/VG isn’t present or filtered out.

Decision: check pvs, disk visibility, and /etc/lvm/lvm.conf filters.

Task 16: If it’s Ceph, check cluster health quickly

cr0x@server:~$ ceph -s
  cluster:
    id:     2f1d3b0a-6f6d-4a7b-a6b3-9a7b4a0d1c2e
    health: HEALTH_WARN
            1 mons down, quorum mon1,mon2
  services:
    mon: 3 daemons, quorum mon1,mon2
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   3 pools, 128 pgs
    usage:   2.1 TiB used, 4.9 TiB / 7.0 TiB avail
    pgs:     128 active+clean

Meaning: Ceph is mostly fine; a mon is down but quorum exists and PGs are clean. Proxmox should generally still use RBD.

Decision: if health is HEALTH_ERR, or you see many PGs not active+clean, treat it as backend incident, not Proxmox UI drama.

Task 17: Confirm Proxmox can list volumes on the storage

cr0x@server:~$ pvesm list fast-nfs | head
Volid                             Format  Type              Size VMID
fast-nfs:iso/debian-12.iso        iso     iso           657457152    0
fast-nfs:backup/vzdump-qemu-100.vma.zst vma.zst backup  1812034560  100

Meaning: If listing works, storage is at least reachable and readable. If listing fails with an error, it often includes the specific backend failure.

Decision: if list works but create fails, suspect permission, space, content types, or locking issues.

Task 18: Check disk space and inodes (yes, inodes)

cr0x@server:~$ df -h /mnt/pve/fast-nfs && df -i /mnt/pve/fast-nfs
Filesystem                         Size  Used Avail Use% Mounted on
10.20.30.40:/exports/proxmox       20T   19T  800G  96% /mnt/pve/fast-nfs
Filesystem                         Inodes  IUsed   IFree IUse% Mounted on
10.20.30.40:/exports/proxmox       120M    119M    1M   99% /mnt/pve/fast-nfs

Meaning: Space is tight, but inodes are basically gone. That can break backups, ISO uploads, and container storage in ways that look like permission errors.

Decision: clean up, expand filesystem, or reduce tiny-file churn. If inodes are near 100%, treat it as full.

Errores comunes (síntoma → causa raíz → solución)

Estos no son “errores teóricos”. Son los que se repiten porque parecen razonables en el momento.

1) El almacenamiento aparece en la UI, pero en un nodo dice “no disponible”

Síntoma: Almacenamiento listado a nivel de clúster; solo un nodo no puede usarlo.

Causa raíz: restricción de nodo en storage.cfg o desajuste de hostname (nodo reinstalado con nombre distinto).

Solución: actualiza la opción nodes para ese almacenamiento o corrige la identidad del nodo de forma consistente. Verifica con pvesm status en cada nodo.

2) El almacenamiento NFS “funciona” hasta el reinicio, luego queda no disponible

Síntoma: Tras un reinicio, Proxmox dice que el almacenamiento no está disponible; un montaje manual lo arregla.

Causa raíz: montaje no persistente o que arranca antes que la red; falta _netdev o problemas de orden en systemd; a veces DNS no listo.

Solución: asegúrate de que fstab incluya _netdev, considera unidades de montaje systemd y verifica con systemctl status mnt-pve-*.mount. Mantén montajes deterministas.

3) “Permission denied” al montar aunque la exportación exista

Síntoma: showmount -e muestra la exportación, pero el montaje falla con acceso denegado.

Causa raíz: las reglas de exportación no incluyen la IP del nodo, o las expectativas de idmapping de NFSv4 difieren, o el firewall bloquea puertos relacionados con NFS.

Solución: corrige la lista de permitidos en el servidor NFS, confirma la versión de NFS, y valida desde el cliente con un montaje verbose.

4) El almacenamiento está montado, pero Proxmox sigue diciendo no disponible

Síntoma: findmnt muestra el montaje, pero pvesm status indica inactivo.

Causa raíz: Proxmox espera el almacenamiento en /mnt/pve/<storageid> pero lo montaste en otro lugar, o la path en storage.cfg es incorrecta, o el montaje está obsoleto/colgado.

Solución: alinea la path con el punto de montaje real; comprueba si NFS está obsoleto con un simple ls que pueda colgar; remonta si es necesario.

5) No se crean discos de VM en el almacenamiento, pero las ISOs se suben bien

Síntoma: El contenido ISO funciona, pero crear un disco falla.

Causa raíz: falta images en content, o el tipo de almacenamiento no soporta el formato solicitado.

Solución: añade los tipos de contenido adecuados, o mueve discos a almacenamiento en bloque (LVM/RBD) si necesitas ciertas garantías.

6) Ceph storage “no disponible” solo en un nodo

Síntoma: Dos nodos pueden usar RBD; uno no.

Causa raíz: paquetes Ceph faltantes, keyring ausente, ceph.conf incorrecto, o ruta de red a monitores bloqueada en ese nodo.

Solución: valida ceph -s en ese nodo; compara /etc/ceph y keyrings; confirma reglas de firewall y accesibilidad a monitores.

7) LVM-thin desaparece tras una “limpieza”

Síntoma: Almacenamiento basado en LVM inactivo; vgs vacío.

Causa raíz: alguien removió/cambió un disco, modificó filtros LVM, o cambió nombres de dispositivo sin usar IDs estables.

Solución: restaura la visibilidad del disco, usa rutas by-id estables cuando sea posible, y mantén filtros LVM conservadores y explícitos.

Listas de verificación / plan paso a paso

Checklist A: Triaje rápido en nodo único “storage not available” (10 minutos)

Ejecuta pvesm status. Identifica qué IDs de almacenamiento están inactivos en ese nodo.
Revisa /etc/pve/storage.cfg por restricciones nodes y configuraciones de ruta.
Verifica el nombre del nodo con hostname y compáralo con la configuración.
Si es almacenamiento basado en ficheros: verifica el montaje con findmnt.
Prueba E/S básica: ls y touch en la ruta de almacenamiento (atento a colgados).
Revisa logs: journalctl -u pvedaemon -u pve-storage para errores explícitos.
Si es NFS/CIFS: prueba montaje manual con salida verbose.
Si es Ceph: ceph -s en ese nodo y verifica keyrings.
Si es ZFS/LVM: verifica visibilidad y salud del pool/VG.
Sólo tras pasar las comprobaciones a nivel de SO: revisa la GUI de Proxmox e intenta la operación de nuevo.

Checklist B: Comprobación de sanidad a nivel de clúster (30–60 minutos, previene repeticiones)

En cada nodo: ejecuta pvesm status y compara salidas.
Valida que cada almacenamiento compartido tenga la misma semántica de montaje en todos los nodos (misma ruta, mismas opciones).
Estandariza supuestos de red: VLANs, reglas de firewall, DNS, MTU, enrutamiento.
Para NFS: asegúrate de que las exportaciones incluyan explícitamente todos los nodos Proxmox; evita sorpresas de “funciona desde una subred”.
Para Ceph: confirma que cada nodo tenga los configs y keyrings correctos en /etc/ceph; verifica accesibilidad a monitores.
Revisa los tipos de contenido por almacenamiento: mantenlos ajustados. “Todo en todas partes” se convierte en “todo roto en todas partes”.
Añade un paso de validación post-reinicio en tu proceso de cambios: montajes importados, VGs activos, Ceph OK.

Checklist C: Antes de habilitar HA o programar migraciones

Identifica qué cargas requieren almacenamiento compartido (verdadero HA, migración en vivo sin downtime).
Confirma que el almacenamiento es accesible desde todos los nodos que podrían ejecutar esas cargas.
Prueba una migración en vivo y una migración de almacenamiento durante horario laboral con un plan de rollback.
Para cargas con almacenamiento local, diseña explícitamente rutas de replicación/backup y documenta los límites.

Tres micro-historias del mundo corporativo

Micro-historia 1: El incidente causado por una suposición equivocada

Tenían un clúster de tres nodos y un único servidor NFS. El almacenamiento se definió una vez, era visible en todas partes, y el equipo asumió que eso significaba “compartido”. Funcionaba la mayor parte del tiempo—hasta la primera emergencia.

Un host empezó a lanzar errores ECC. El de guardia hizo lo correcto: evacuar VMs a los nodos restantes. Pero varias VMs se negaron a migrar. La interfaz decía amablemente que el nodo destino no podía usar el almacenamiento. Confuso, porque el almacenamiento “estaba ahí”.

La causa raíz no fue que Proxmox fallara. El servidor NFS exportaba la compartición solo a una subred específica, y uno de los nodos Proxmox vivía en una VLAN diferente por un cambio de red “temporal” anterior. La definición de almacenamiento existía, pero el nodo nunca estuvo realmente autorizado.

La solución fue aburrida: actualizar la lista de permitidos en el export NFS, alinear la colocación de red y añadir una simple comprobación “montar + tocar archivo” como parte del comisionado de nodos. Tras eso, las migraciones funcionaron—y el equipo dejó de tratar la GUI como prueba de la realidad.

También aprendieron la verdad dura: configuración visible en el clúster no es lo mismo que infraestructura accesible por el clúster. Es una distinción que sólo olvidas una vez.

Micro-historia 2: La optimización que salió mal

Otra compañía quiso discos de VM más rápidos, así que “optimizó” opciones de montaje NFS. Cambiaron a timeouts agresivos y añadieron opciones para reducir colgados bajo pérdida de paquetes. Sobre el papel sonaba responsable: evitar procesos bloqueados, mantener el nodo reactivo.

Las primeras semanas fueron bien. Luego un mantenimiento de red rutinario causó una interrupción breve—segundos, no minutos. Tras eso, un subconjunto de VMs empezó a registrar errores de filesystem. Las copias de seguridad empezaron a fallar de forma inconsistente. Algunas operaciones informaban almacenamiento no disponible, otras se completaban parcialmente. El patrón de fallo fue teatral y difícil de reproducir.

El culpable fue el comportamiento del montaje bajo fallo transitorio. Las opciones convirtieron un blip temporal en errores visibles para la aplicación. Para discos de VM, eso no es una “pequeña molestia”. Es un evento de integridad de datos con papeleo asociado.

Revirtieron a semánticas de montaje más seguras para cargas de disco y dividieron el uso: un NFS para backups (donde reintentos ocasionales son aceptables) y otro backend de almacenamiento para discos de VM. La optimización había sido una idea inteligente aplicada al problema equivocado.

Broma #2: Nada dice “alta disponibilidad” como ajustar timeouts hasta que tu almacenamiento se convierte en el sistema de archivos de Schrödinger.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Otro equipo usaba RBD de Ceph para discos de VM y un NFS separado para backups. También tenían la costumbre dolorosamente aburrida: después de cada actualización de Proxmox o reinicio de nodo, ejecutaban un script de validación corto y repetible—pvesm status, una pequeña prueba de crear/borrar RBD y una prueba de escritura de backup en NFS.

Una mañana, un nodo reinició tras una actualización de kernel y volvió con reglas de firewall sutilmente diferentes debido a una deriva en la gestión de configuración. El nodo se unió al clúster y parecía sano en la GUI, pero las operaciones RBD fallaban y el almacenamiento se mostraba no disponible solo en ese nodo.

Como ejecutaron la validación de inmediato, lo detectaron antes de que el scheduler moviera cargas allí. Nada de migraciones nocturnas sorpresivas, ni VMs medio muertas, ni tickets de “funciona en el nodo A”. Solo una corrección controlada: restaurar las reglas de firewall correctas para acceso a monitores Ceph, volver a comprobar y seguir.

Esta es la verdad poco glamorosa: la fiabilidad es en su mayoría practicar las mismas pequeñas comprobaciones hasta que te canses de ellas, y luego practicarlas de nuevo. Se siente lento. Es más rápido que los incidentes.

Datos interesantes y un poco de historia (que realmente ayuda)

Dato 1: Proxmox almacena la configuración a nivel de clúster en un sistema de ficheros especial bajo /etc/pve, respaldado por un mecanismo de replicación parecido a una base de datos. Por eso los IDs de almacenamiento aparecen en todas partes rápidamente.
Dato 2: Los puntos de montaje bajo /mnt/pve son gestionados convencionalmente por los plugins de almacenamiento de Proxmox; desajustar la ruta es una herida autoinfligida común.
Dato 3: NFS existe desde los años 80, y sigue impulsando pilas de virtualización modernas porque es simple, depurable y “suficientemente bueno” si se diseña con cuidado.
Dato 4: El cambio de discos VM basados en fichero a discos en bloque (LVM, RBD, iSCSI) se dio por latencia predecible y semánticas de bloqueo bajo contención.
Dato 5: Ceph se popularizó en virtualización porque ofrece bloque compartido sin un SAN tradicional, pero cambia simplicidad de hardware por complejidad operativa.
Dato 6: “El almacenamiento está definido” vs. “el almacenamiento está montado” refleja una clásica división de sistemas: plano de control vs. plano de datos. Muchos incidentes son un plano mintiendo al otro.
Dato 7: El agotamiento de inodos es un modo de fallo real en producción en shares NFS con muchas copias y retenciones, especialmente cuando las políticas generan muchos ficheros pequeños.
Dato 8: La consistencia de hostname importa en clústeres porque la identidad aparece en control de acceso, targeteo de nodos, certificados y a veces en listas de permitidos de almacenamiento. Renombrar raramente es “solo cosmético”.
Dato 9: La generación de unidades de montaje por systemd desde /etc/fstab puede cambiar el orden de arranque de formas que sorprenden a quienes vienen de init antiguos.

Una cita sobre fiabilidad que deberías interiorizar

Idea parafraseada, atribuida a John Allspaw: no se obtiene fiabilidad culpando a las personas; se obtiene mejorando el sistema que permitió la falla.

Cuando el almacenamiento está “no disponible en el nodo”, resiste la tentación de buscar a una persona. Busca la suposición que el sistema permitió existir.

Preguntas frecuentes

1) ¿Por qué el almacenamiento aparece en la GUI si es inutilizable?

Porque la GUI muestra objetos de configuración a nivel de clúster. El ID de almacenamiento existe en /etc/pve/storage.cfg. La disponibilidad es específica del nodo y depende de montajes, dispositivos, autenticación y salud.

2) ¿“not available on node” es siempre una caída real?

No. Puede ser deliberado: el almacenamiento está restringido a ciertos nodos mediante la opción nodes. Pero si se supone que es compartido, trátalo como un incidente de producción hasta que se demuestre lo contrario.

3) ¿Cuál es la forma más rápida de ver el error real detrás del mensaje de la GUI?

Revisa los logs en el nodo afectado: journalctl -u pvedaemon -u pve-storage. A menudo contiene el error subyacente de montaje/autenticación/backend.

4) ¿Puedo arreglarlo reiniciando servicios de Proxmox?

A veces enmascara problemas transitorios, pero suele ser el movimiento equivocado como primera acción. Si el SO no puede montar o ver el backend, reiniciar servicios solo repetirá el fallo con más confianza.

5) ¿Por qué ocurre solo después de reiniciar?

Orden de arranque y persistencia. La red puede no estar lista cuando inician los montajes, los pools ZFS pueden no auto-importarse por el timing de dispositivos, las sesiones iSCSI pueden no auto-login, o las reglas de firewall cambian al reiniciar.

6) Puedo `ping` al servidor NFS, ¿por qué sigue no disponible?

ping prueba casi nada más que alcance ICMP. NFS necesita servicios RPC funcionando, exportaciones correctas, autenticación correcta y puertos abiertos. Usa showmount -e y un mount -v verbose.

7) Para HA y migración en vivo, ¿necesito almacenamiento compartido?

Para migración en vivo sin mover almacenamiento, sí. De lo contrario necesitas una estrategia: replicación (replicación ZFS), migración de almacenamiento con downtime, o un backend distribuido (Ceph). Elige una intencionalmente.

8) ¿Por qué Proxmox dice que un almacenamiento está activo pero las operaciones fallan?

“Activo” puede significar que se montó y pasaron chequeos básicos. Las operaciones aún pueden fallar por permisos en subdirectorios, inodos llenos, remontajes en solo lectura, manejadores NFS obsoletos o restricciones de tipo de contenido.

9) ¿Es seguro poner discos de VM en NFS dir storage?

Puedes, si está diseñado correctamente (red estable, opciones de montaje adecuadas, configuración del servidor correcta y expectativas realistas). Pero si quieres latencia consistente y menos casos extremos, el almacenamiento en bloque (Ceph RBD, LVM en SAN) tiende a comportarse mejor bajo contención.

10) ¿Cómo prevengo que este tipo de problema se repita?

Estandariza el comisionado de nodos: verifica montajes/importaciones, verifica activación de almacenamiento con pvesm status y prueba una operación de lectura/escritura. Luego automatízalo como una comprobación post-reinicio.

Conclusión: próximos pasos que funcionan en producción

“Not available on node” es un mensaje preciso con abrigo vago. La definición de almacenamiento existe; el nodo no puede activarlo—o no está autorizado. Tu tarea es dejar de adivinar y probar qué capa está rota: alcance de configuración, acceso a nivel de SO o salud del backend.

Haz esto a continuación, en orden:

Ejecuta pvesm status en el nodo afectado y confirma qué está inactivo.
Revisa /etc/pve/storage.cfg por restricciones nodes y rutas correctas.
Valida el backend desde Linux: montajes, pools, VGs, salud de Ceph, sesiones iSCSI.
Usa logs para encontrar la cadena de error real y arregla el backend, no la UI.
Tras arreglar, valida listando contenido del almacenamiento y haciendo una pequeña prueba de escritura.
Institucionaliza la comprobación aburrida: validación post-reinicio de almacenamiento en cada nodo.

Si quieres menos sorpresas a las 02:00, trata el almacenamiento como un sistema de producción de primera clase: acceso de nodo explícito, rutas consistentes, montajes deterministas y cheques de salud que se ejecuten cuando nadie está mirando.