Proxmox «No se puede activar el almacenamiento»: diagnostica LVM, NFS y CIFS correctamente

Qué significa realmente “unable to activate storage” en Proxmox

En Proxmox, “almacenamiento” es una abstracción impulsada por plugins sobre realidades muy diferentes: un grupo de volúmenes LVM local, una exportación NFS montada, un montaje CIFS, LUNs iSCSI, pools ZFS, rutas de directorios, etc. Cuando Proxmox dice que no puede “activar” un almacenamiento, generalmente significa una de estas cosas:

• El backend no está presente (VG no encontrado, montaje no montado, ruta ausente).
• El backend está presente pero no es utilizable (permisos, handle obsoleto, sólo lectura, opciones erróneas, fallo de autenticación).
• Proxmox no puede ejecutar el paso de activación (herramienta ausente, comando falla, orden de servicios, contención de bloqueos).
• El nodo cree que está a cargo cuando no lo está (desajuste en la configuración del clúster, definiciones de almacenamiento específicas del nodo, síntomas de split-brain).

La clave es tratarlo como un incidente SRE: definir el radio de impacto (un nodo o todos), aislar el backend que falla, recopilar evidencia y luego cambiar una variable a la vez.

Una cita que vale la pena tener en la pared:

“La esperanza no es una estrategia.” — General Gordon R. Sullivan

La resolución de problemas de almacenamiento es donde la esperanza va a morir. Eso es bueno. Te obliga a medir.

Broma #1: Las caídas de almacenamiento son como los niños pequeños: cuanto más ruidosos se ponen, más probable es que el problema sea algo básico que ignoraste.

Guion rápido de diagnóstico (primero/segundo/tercero)

Si estás de guardia y necesitas señal rápido, no empieces editando configuraciones aleatorias de Proxmox. Haz esto:

Primero: confirma el alcance y el ID de almacenamiento específico

• ¿Es un nodo o varios?
• ¿Es una entrada de almacenamiento o todas?
• ¿Es sólo al iniciar VMs, o también contenedores y backups?

Objetivo: nombra el almacenamiento que falla exactamente (su ID de almacenamiento en Proxmox) e identifica el/los nodo(s) afectados.

Segundo: valida la verdad a nivel OS (montajes/VGs/rutas), no los sentimientos del GUI

• Para NFS/CIFS: ¿está realmente montado en la ruta esperada?
• Para LVM: ¿existe el VG y son visibles las LVs?
• Para todo: ¿puedes leer/escribir la ruta como root?

Objetivo: demuestra si el backend existe y es utilizable desde la shell del nodo.

Tercero: mira los logs de tareas de Proxmox y el journal para la cadena de error real

• Proxmox envuelve errores del backend. El mensaje contenedor rara vez es la solución.
• Encuentra el comando subyacente que falló (mount, vgchange, lvcreate, etc.).

Objetivo: obtener el error preciso: “permission denied”, “no such device”, “protocol not supported”, “unknown filesystem type”, “wrong fs type”, “stale file handle”, “timed out”. Esa cadena determina el siguiente paso.

Datos y contexto interesantes (porque la historia se repite)

1. LVM2 se convirtió en el estándar en Linux tras lecciones de LVM1 y gestores de volúmenes de proveedores; es estable, pero la activación depende del descubrimiento de dispositivos y del timing de udev.
2. NFSv3 es sin estado (en su mayor parte), por eso puede “funcionar” hasta que de repente deja de hacerlo y luego se recupera de maneras extrañas; NFSv4 cambió el modelo con sesiones con estado.
3. “Stale file handle” es un clásico de NFS que data de hace décadas; básicamente el cliente mantiene una referencia de inode que el servidor ya no reconoce.
4. SMB1 (CIFS) fue un desastre de seguridad y los sistemas modernos a menudo lo deshabilitan; la negociación de dialectos SMB desajustada es una causa silenciosa de fallos en montajes.
5. systemd cambió el orden de montaje para muchos administradores que crecieron con sysvinit; lo que “funcionaba al arrancar” antes puede fallar ahora a menos que las dependencias estén declaradas.
6. Los sistemas de archivos en clúster y el almacenamiento compartido son problemas distintos; Proxmox puede compartir configuración vía corosync, pero tu almacenamiento aún tiene que ser accesible y consistente.
7. Multipath y LVM no se aman automáticamente; si activas VGs sobre dispositivos subyacentes erróneos, puedes crear detección duplicada de PVs o comportamiento extraño de “dispositivo desincronizado”.
8. El tuning de rendimiento NFS puede romper la corrección cuando la gente se pone creativa con caching o timeouts; el bug más rápido sigue siendo un bug.

Triagem: identificar el backend y el alcance del fallo

Antes de profundizar: identifica qué tipo de almacenamiento Proxmox cree que está activando. Las entradas de almacenamiento de Proxmox viven en la configuración del clúster, pero la activación ocurre en cada nodo. Por eso un nodo puede fallar mientras otros están bien.

Regla práctica: si el almacenamiento de Proxmox es “Directory”, “NFS” o “CIFS”, las fallas suelen corresponder a problemas de montaje o permisos. Si el almacenamiento es “LVM” o “LVM-thin”, las fallas suelen corresponder a descubrimiento de dispositivos, activación de VG o bloqueos.

También decide si estás en modo “restaurar servicio” o en modo “preservar evidencia forense”. En modo restauración priorizas poner VMs en marcha sin empeorar la próxima caída. En modo forense preservas evidencia y cambias menos. Elige uno; no osciles cada 10 minutos.

LVM: fallos de activación que parecen problemas de Proxmox

Los fallos de LVM suelen ser aburridos y locales: el nodo no ve el dispositivo de bloque, el VG no está activo o LVM está confundido sobre qué dispositivo es el PV “real”. Proxmox lo informa como “unable to activate storage” porque desde su perspectiva el plugin LVM no puede hacer su trabajo.

Categorías comunes de fallo en LVM

• VG no encontrado: el dispositivo PV no está presente (disco ausente, iSCSI no conectado, multipath no listo).
• VG existe pero inactivo: la activación no ocurrió en el arranque o falló por bloqueo.
• PV duplicados: mismo LUN visible por múltiples rutas sin configuración multipath adecuada.
• Problemas en thin pool: metadata de thin llena, pool en solo lectura o activación bloqueada por errores.
• Problemas de filtro: device filters en lvm.conf excluyen los dispositivos reales, por lo que el descubrimiento es inconsistente.

Qué significa “activar” para LVM en términos de Proxmox

Para almacenamiento LVM-thin, Proxmox espera que el volume group sea detectable y que el thin pool LV esté activo. Ejecutará comandos de LVM internamente. Si esos comandos devuelven distinto de cero, Proxmox te da el error paraguas.

Si estás solucionando LVM, tu primera pregunta debe ser: “¿Ve el nodo el dispositivo de bloque, y LVM está de acuerdo?” No “¿qué dice la GUI?”.

NFS: montajes que fallan, se bloquean o engañan

NFS es popular en Proxmox porque es simple: monta una exportación y trátala como un directorio. También falla de maneras que parecen bugs de Proxmox pero son realmente problemas de red, DNS, firewall, exports del servidor o negociación de versión.

Categorías de fallo NFS que disparan “unable to activate storage”

• El montaje nunca ocurre: dirección del servidor errónea, ruta de exportación equivocada, firewall, servicios RPC bloqueados.
• El montaje ocurre pero es sólo lectura: opciones de exportación o mapeo de permisos del servidor (root squash, mapeo de UID).
• Stale file handle: cambios en el servidor (remontado del filesystem, failover, promoción de snapshot) invalidan handles.
• Timeouts que parecen bloqueos: I/O NFS atascada puede bloquear tareas de Proxmox y hacer que el nodo parezca “lento” en lugar de “caído”.
• Versión NFS equivocada: el cliente intenta v4 pero el servidor sólo soporta v3 (o viceversa), o v4 requiere un layout de export distinto.

Con NFS, “activar” es básicamente “asegurar que el montaje está presente y responde”. Un punto de montaje que existe pero no responde es peor que un fallo limpio porque hace que los procesos queden en sleep de I/O no interrumpible.

CIFS/SMB: autenticación, dialectos y la cruel alegría de los permisos

CIFS en Proxmox es simplemente “montar un share SMB y tratarlo como un directorio”. Lo que significa que cada matiz de SMB se vuelve tu problema: negociación de dialectos (SMB2/3), NTLM vs Kerberos, trust de dominio, rotación de contraseñas y semántica de propiedad de archivos.

Categorías de fallo en CIFS

• Fallas de autenticación: credenciales erróneas, contraseña expirada, problemas de dominio, cambios en políticas NTLM.
• Desajuste de dialecto: el servidor deshabilita versiones antiguas de SMB; el cliente elige por defecto otra; el hardening rompe montajes.
• Extrañezas en el mapeo de permisos: montado pero root no puede escribir por ACLs del servidor o opciones de montaje.
• Sorpresas de DFS/referrals: montaste una ruta que redirige y ahora no funciona.
• “Funciona manualmente, falla en Proxmox”: porque Proxmox usa opciones de montaje específicas o lee credenciales desde un archivo con permisos incorrectos.

Broma #2: Los permisos SMB son como la política de oficina: todos insisten en que es “simple”, y luego nada funciona a menos que Carol lo apruebe.

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

Estas tareas están ordenadas aproximadamente de “señal rápida” a “detalle profundo”. Ejecútalas en el nodo afectado primero. Si es un clúster, compara un nodo que funciona con uno que falla—diferenciar la realidad está subvalorado.

Task 1: Confirmar qué almacenamiento cree Proxmox que falla

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active       1024000000        12345678       987654321        1.2%
nfs-backup        nfs     inactive              0               0               0          0%
lvm-thin          lvmthin inactive              0               0               0          0%

Qué significa: “inactive” aquí es la vista de Proxmox, no un diagnóstico. Te dice qué IDs de almacenamiento enfocarte (p. ej., nfs-backup, lvm-thin).

Decisión: Elige un ID de almacenamiento que falla y sigue la sección correspondiente al backend. No intentes arreglar todo a la vez.

Task 2: Inspecciona la definición de almacenamiento tal como la ve Proxmox

cr0x@server:~$ pvesm config nfs-backup
nfs-backup: nfs
        export /exports/proxmox-backup
        path /mnt/pve/nfs-backup
        server 10.20.30.40
        content backup,iso
        options vers=4.1

Qué significa: Obtienes el punto de montaje y los parámetros de server/export que Proxmox usará.

Decisión: Valida que el punto de montaje exista y si está montado, y valida la conectividad de red al IP/hostname del servidor.

Task 3: Revisa los logs de tareas de Proxmox para el error real

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:pve01:0000A1B2:0001C3D4:676D0F00:vzdump::root@pam:
UPID:pve01:0000A1B3:0001C3D5:676D0F10:mount::root@pam:storage=nfs-backup:

cr0x@server:~$ journalctl -u pvedaemon -u pvestatd -u pve-storage -n 200 --no-pager
Dec 26 10:11:12 pve01 pvestatd[1234]: storage 'nfs-backup' is not online
Dec 26 10:11:13 pve01 pvedaemon[2345]: storage activate failed: mount error(13): Permission denied

Qué significa: Estás cazando el errno subyacente: aquí es permission denied (error(13)) desde semánticas tipo CIFS o control de acceso del servidor.

Decisión: Para. “Permission denied” no se arregla reiniciando. Ve a comprobar credenciales/permisos del export.

Task 4: Valida el estado del punto de montaje (NFS/CIFS/dir)

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

Qué significa: Si findmnt no devuelve nada, no está montado. Si devuelve NFS/CIFS pero el sistema sigue dando errores, el montaje puede estar obsoleto o con permisos incorrectos.

Decisión: Si no está montado, intenta un montaje controlado y captura el error exacto. Si está montado, prueba la capacidad de I/O.

Task 5: Prueba lectura/escritura y detecta “montaje colgado” rápido

cr0x@server:~$ timeout 5 bash -c 'ls -la /mnt/pve/nfs-backup >/dev/null; echo OK'
OK

Qué significa: Si este comando expira, el montaje está colgado. Eso es un problema de red/servidor (o una sesión muerta), no de Proxmox.

Decisión: Para montajes colgados, no lances trabajos de backup “para ver si se arregla”. Arregla la conectividad o desmonta/remonta de forma segura.

Task 6: Comprueba la conectividad básica de red (no lo compliques)

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.482 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.455 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Qué significa: Ping no prueba la salud de NFS/SMB, pero fallar es una pista fuerte de que estás persiguiendo la capa equivocada.

Decisión: Si ping falla, revisa routing/VLAN/firewall antes de tocar la configuración de almacenamiento.

Task 7: NFS específico: verifica que las exports sean visibles desde el cliente

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

Qué significa: Si la export no aparece (o showmount se queda colgado), la configuración del servidor NFS/RPC/firewall es el problema.

Decisión: Arregla la configuración de export del servidor NFS o las reglas de firewall; no “arregles” Proxmox por un servidor que te rechaza.

Task 8: NFS específico: intenta un montaje manual con versión/opciones explícitas

cr0x@server:~$ umount /mnt/pve/nfs-backup 2>/dev/null || true
cr0x@server:~$ mount -t nfs -o vers=4.1,proto=tcp,timeo=600,retrans=2 10.20.30.40:/exports/proxmox-backup /mnt/pve/nfs-backup
cr0x@server:~$ dmesg | tail -n 8
[123456.789012] nfs: server 10.20.30.40 OK

Qué significa: Un montaje manual aísla a Proxmox de la ecuación. Si el montaje manual falla, el backend es el problema. Si tiene éxito, compara las opciones con la configuración de Proxmox.

Decisión: Si el montaje manual sólo funciona con un vers= u opciones distintas, actualiza las opciones de almacenamiento en Proxmox en consecuencia.

Task 9: CIFS específico: valida permisos y contenido del archivo de credenciales

cr0x@server:~$ ls -l /etc/pve/priv/storage/cifs-prod.pw
-rw------- 1 root root 64 Dec 26 09:55 /etc/pve/priv/storage/cifs-prod.pw
cr0x@server:~$ sed -n '1,5p' /etc/pve/priv/storage/cifs-prod.pw
username=svc_proxmox
password=REDACTED
domain=CORP

Qué significa: Proxmox espera archivos de credenciales legibles solo por root. Permisos erróneos pueden causar fallos de montaje o fuga de secretos.

Decisión: Si los permisos no son 600, corrígelos. Si las credenciales cambiaron, actualízalas y considera procedimientos de rotación de contraseñas.

Task 10: CIFS específico: montaje manual con dialecto SMB y seguridad explícitos

cr0x@server:~$ umount /mnt/pve/cifs-prod 2>/dev/null || true
cr0x@server:~$ mount -t cifs //fileserver01/proxmox -o credentials=/etc/pve/priv/storage/cifs-prod.pw,vers=3.0,sec=ntlmssp,uid=0,gid=0,file_mode=0660,dir_mode=0770 /mnt/pve/cifs-prod
cr0x@server:~$ findmnt /mnt/pve/cifs-prod
TARGET           SOURCE                    FSTYPE OPTIONS
/mnt/pve/cifs-prod //fileserver01/proxmox  cifs   rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=svc_proxmox,uid=0,gid=0,file_mode=0660,dir_mode=0770

Qué significa: Si añadir vers=3.0 lo arregla, tu servidor probablemente deshabilitó dialectos antiguos. Si sec= importa, la política de dominio cambió.

Decisión: Alinea las opciones de almacenamiento de Proxmox con lo que funciona, y coordina con el equipo del servidor de archivos para que no te “endurezcan” hacia una indisponibilidad.

Task 11: LVM: comprueba si el VG y el thin pool existen

cr0x@server:~$ vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  pve        1   7   0  wz--n-  930.00g  12.00g
  vg_vmdata  1   2   0  wz--n-    3.64t  120.00g

cr0x@server:~$ lvs -a -o +devices vg_vmdata
  LV          VG        Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  thinpool    vg_vmdata twi-aotz--  3.40t             62.10  4.20                             /dev/sdb(0)
  thinpool_tmeta vg_vmdata ewi-aotz-- 8.00g                                                   /dev/sdb(870912)
  thinpool_tdata vg_vmdata ewi-aotz-- 3.40t                                                   /dev/sdb(2048)

Qué significa: El VG existe, y el thin pool está activo (twi-a). Si ves twi--- sin la a, no está activo. Si falta el VG, el dispositivo de bloque subyacente no es visible o no se descubrió.

Decisión: Si falta el VG: comprueba discos/iSCSI/multipath. Si el thin pool está inactivo: intenta activarlo e inspecciona los errores.

Task 12: LVM: intenta una activación controlada y captura errores

cr0x@server:~$ vgchange -ay vg_vmdata
  1 logical volume(s) in volume group "vg_vmdata" now active

Qué significa: La activación exitosa es inmediata y explícita. Si falla, LVM te dirá por qué (bloqueo, PVs faltantes, duplicados).

Decisión: Si la activación tiene éxito, vuelve a comprobar pvesm status. Si falla, sigue la cadena de error—no improvises.

Task 13: LVM: detecta PVs faltantes o rutas de dispositivo duplicadas

cr0x@server:~$ pvs -o+pv_uuid,pv_name,vg_name,dev_size
  PV         VG        Fmt  Attr PSize  PFree  PV UUID                                DevSize
  /dev/sdb   vg_vmdata lvm2 a--  3.64t 120.00g 9Hk3vS-9Qb8-1x2c-7y5n-ABCD-ef01-2345  3.64t

Qué significa: Si ves el mismo PV UUID en múltiples dispositivos (común con multipath mal configurado), LVM se negará a proceder o se comportará de forma impredecible.

Decisión: Arregla multipath para que sólo se use una ruta (normalmente /dev/mapper/mpathX), luego actualiza filtros de LVM si es necesario.

Task 14: Revisa logs del kernel y systemd alrededor de montajes y LVM

cr0x@server:~$ journalctl -b -p warning..alert --no-pager | tail -n 60
Dec 26 09:42:01 pve01 systemd[1]: mnt-pve-nfs\x2dbackup.mount: Mount process exited, code=exited, status=32/n/a
Dec 26 09:42:01 pve01 kernel: CIFS: VFS: cifs_mount failed w/return code = -13
Dec 26 09:42:02 pve01 lvm[987]: device-mapper: thin: Data device (dm-3) discard granularity larger than a block: disabling discards

Qué significa: systemd te da estados de salida, los logs del kernel muestran códigos de retorno de montaje y LVM emite pistas del device-mapper que pueden indicar problemas en la capa de bloque subyacente.

Decisión: Si la unidad de montaje systemd falló, comprueba opciones de montaje y el orden; si CIFS devuelve -13, son permisos; si el kernel muestra errores de I/O, para e investiga disco/almacenamiento en red.

Task 15: Confirma que Proxmox pueda activar ahora (y que se mantenga)

cr0x@server:~$ pvesm set nfs-backup --disable 0
cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
nfs-backup        nfs     active        2048000000       123456789      1920000000       6.0%

Qué significa: Esto confirma que el plugin de almacenamiento de Proxmox puede ver y usar el backend de nuevo.

Decisión: Arranca una VM y realiza una acción ligera de almacenamiento (crear un disco pequeño, listar backups). Verifica que sobreviva a un reinicio si esto era un problema de orden de arranque.

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

1) “Almacenamiento inactivo” sólo en un nodo

Síntoma: El clúster muestra el almacenamiento offline en pve02, bien en pve01.

Causa raíz: Problema local del nodo: ruta de red, montaje no presente, sesión iSCSI no iniciada, o disco ausente.

Solución: Diagnostica en el nodo que falla con findmnt/vgs; compara con el nodo que funciona; arregla red/montaje/iSCSI antes de tocar la configuración del clúster.

2) El montaje NFS existe pero las operaciones de Proxmox se bloquean

Síntoma: Inicio de VM, backup o “browse storage” se atascan; SSH a veces parece lento; procesos inmatables.

Causa raíz: I/O NFS colgada; el montaje “está” pero no responde debido a problemas de servidor/red.

Solución: Usa la prueba timeout; revisa la red; considera remontar tras restaurar conectividad. Evita montajes “soft” para almacenamiento de VM—la corrupción es peor.

3) Montaje CIFS falla tras rotación de contraseña

Síntoma: “mount error(13): Permission denied” de repente tras meses estables.

Causa raíz: Rotación de contraseña de cuenta de servicio; archivo de credenciales obsoleto; o la política de dominio cambió el método de auth requerido.

Solución: Actualiza el archivo de credenciales; asegura permisos 600; fija vers=3.0 y sec=ntlmssp si la política lo exige.

4) Almacenamiento LVM-thin inactivo tras reinicio

Síntoma: Tras reinicio, almacenamiento LVM inactivo; vgchange -ay manual lo arregla.

Causa raíz: Orden de arranque: el dispositivo subyacente aparece tarde (multipath, iSCSI), por lo que la activación de LVM en el arranque lo pasa por alto.

Solución: Asegura que los servicios iSCSI/multipath arranquen antes de la activación de LVM; arregla el descubrimiento de dispositivos; evita depender del reinicio como “estrategia de activación”.

5) “Volume group not found” pero los discos parecen presentes

Síntoma: vgs no lista el VG; pero lsblk muestra el disco.

Causa raíz: El filtro de dispositivo de LVM lo excluye; o las firmas PV están en una ruta de dispositivo distinta a la esperada.

Solución: Revisa /etc/lvm/lvm.conf filters; estandariza rutas de dispositivo estables (by-id, mapper para multipath).

6) Export NFS funciona desde una subred pero no desde otra

Síntoma: Un nodo Proxmox monta; otro recibe “access denied by server”.

Causa raíz: Restricciones de export por IP/subnet; nuevo nodo en VLAN distinta; expectativas de reverse DNS.

Solución: Corrige la lista de acceso del export en el servidor; mantén los nodos Proxmox en las subredes esperadas; evita depender de reverse DNS si puedes.

7) CIFS monta manualmente pero Proxmox aún afirma inactivo

Síntoma: Puedes montar el share, pero el plugin Proxmox informa inactivo.

Causa raíz: Desajuste en el punto de montaje esperado por Proxmox, opciones diferentes, o Proxmox espera que esté bajo /mnt/pve/<storageid>.

Solución: Confirma la ruta en pvesm config; asegura que el montaje esté en esa ruta exacta; evita montajes personalizados fuera de los directorios esperados de Proxmox a menos que sepas las implicaciones.

8) “Stale file handle” tras mantenimiento de almacenamiento

Síntoma: La ruta NFS existe; operaciones fallan con stale handle; a veces se arregla remontando.

Causa raíz: El servidor cambió el filesystem subyacente, el export fue remapeado, o un failover movió el backing store sin preservar la identidad de los inodos.

Solución: Coordina el mantenimiento; remonta clientes; asegura que HA/failover preserve la identidad del export cuando sea posible.

Tres microhistorias corporativas desde las trincheras del almacenamiento

Incidente causado por una suposición errónea: “Es un bug de Proxmox”

Tuvieron un clúster pequeño de Proxmox y un share NFS “fiable” para backups. Un lunes por la mañana, los backups fallaron con “unable to activate storage”. El primer movimiento del equipo fue planear una actualización de Proxmox, porque la GUI decía que el almacenamiento estaba inactivo y por tanto Proxmox debía haber roto algo.

Mientras tanto, el servidor NFS había sido puesto detrás de un nuevo conjunto de reglas de firewall. Ping funcionaba. DNS funcionaba. Incluso SSH funcionaba. Eso fue suficiente para que todos asumieran que el almacenamiento también funcionaría. No fue así. El firewall bloqueaba el tráfico relacionado con NFS y los intentos de montaje hacían timeout.

La actualización se pospuso cuando alguien finalmente ejecutó showmount -e y se quedó colgado. Esa fue la pista. No “almacenamiento Proxmox inactivo”, sino “el nodo no puede hablar NFS con ese servidor”. La solución fue ajustar una regla de firewall y remontar. Los backups se reanudaron.

La lección incómoda no era sobre puertos NFS. Era sobre el proceso: nadie tenía un playbook de primer respondededor, así que por defecto eligieron “cambiar la aplicación” en lugar de “probar la dependencia”.

Optimización que salió mal: tunear NFS como un coche de carrera

Otra organización usaba NFS para ISOs y templates de contenedores. Funcionaba bien. Entonces alguien decidió “optimizar” con opciones agresivas sacadas de un foro: timeouts más cortos, montajes “soft” y varios ajustes de caching, porque “es sólo almacenamiento de ISO”.

Funcionó durante semanas. Luego un fallo de red ocurrió durante la extracción de un template. El comportamiento “soft” devolvió errores de I/O en lugar de esperar la recuperación. El resultado no fue sólo una descarga de template fallida—produjo archivos parciales que parecían válidos para su uso posterior.

Ahora tenían un heisenbug: contenedores a veces fallaban al arrancar, a veces lo hacían con archivos faltantes, y la capa de almacenamiento parecía “activa” todo el tiempo. Cuando finalmente probaron la integridad de archivos, encontraron artefactos corruptos que habían sido cacheados y reutilizados silenciosamente.

La solución fue volver a valores sensatos: montajes “hard” para todo lo que afecte la corrección, pinchar la versión de NFS explícitamente y una política de “optimización con plan de reversión”. Tunear sin pruebas de fallo es apostar con pasos extra.

Práctica aburrida pero correcta que salvó el día: comparar nodos y registrar el error real

Una empresa mediana ejecutaba LVM-thin sobre almacenamiento conectado por multipath. Una mañana tras un cambio de firmware de almacenamiento, un nodo no activaba el almacenamiento LVM. El resto del clúster estaba bien. Empezó el pánico. Se culpó al proveedor de almacenamiento. Se culpó al equipo de hypervisor. Todos practicaron su deporte favorito: la certeza inútil.

El ingeniero de guardia hizo algo poco sexy: comparó un nodo que funcionaba con el que estaba roto. Mismo Proxmox. Misma configuración de almacenamiento. Ejecutaron pvs y notaron que el nodo roto veía el LUN tanto como /dev/sdX como /dev/mapper/mpathY. Firmas PV duplicadas. LVM se negó a activar porque no podía garantizar que no iba a corromper nada.

El ingeniero no “forzó” nada. Arregló multipath para que sólo se usaran los dispositivos mapper, luego ajustó filtros LVM para ignorar /dev/sd* crudos para ese SAN. La activación funcionó. Sin pérdida de datos. Sin heroísmos.

El día se salvó por dos prácticas: siempre captura la cadena de error real, y siempre diff entre nodos que funcionan y los que fallan antes de tocar settings en producción. Es aburrido. También es cómo mantienes tus fines de semana.

Listas de verificación / plan paso a paso

Checklist A: Primeros 10 minutos (detener la hemorragia)

1. Ejecuta pvesm status e identifica los ID(s) de almacenamiento que fallan y sus tipos.
2. Revisa logs de tareas y journal para el error subyacente: journalctl -u pvedaemon -u pvestatd -u pve-storage.
3. Para NFS/CIFS: verifica presencia de montaje con findmnt y capacidad de respuesta con una lectura con timeout.
4. Para LVM: verifica visibilidad de VG/LV con vgs/lvs.
5. Si es sólo un nodo: compara con un nodo que funcione antes de cambiar nada.

Checklist B: NFS paso a paso

1. Confirma configuración de Proxmox: pvesm config <storageid>.
2. Comprueba montaje actual: findmnt <path>.
3. Comprueba visibilidad del export: showmount -e <server>.
4. Montaje manual con versión explícita: mount -t nfs -o vers=4.1 ....
5. Prueba I/O: crea y borra un archivo pequeño bajo el punto de montaje.
6. Si ves stale handles: remonta y coordina con el propietario del servidor NFS sobre comportamiento de mantenimiento/failover.

Checklist C: CIFS paso a paso

1. Confirma la configuración de Proxmox y la ruta de montaje.
2. Verifica que el archivo de credenciales exista y sea 600.
3. Montaje manual con vers= y sec= explícitos.
4. Revisa logs del kernel para códigos de retorno CIFS: dmesg | tail.
5. Verifica permisos de escritura creando un archivo como root en el punto de montaje.
6. Tras arreglar, refresca la vista de almacenamiento de Proxmox comprobando pvesm status; no confíes en la caché del GUI.

Checklist D: LVM paso a paso

1. Verifica existencia del VG: vgs. Si falta, mira la capa de bloque (discos/iSCSI/multipath).
2. Verifica estado de LV/thin pool: lvs -a -o +devices.
3. Intenta activación: vgchange -ay <vg>.
4. Si sospechas duplicados: pvs -o+pv_uuid y arregla multipath/filtros LVM.
5. Comprueba uso del thin pool; si la metadata está llena, arréglalo antes de crear más volúmenes.
6. Una vez estable, valida persistencia tras reinicio (orden de arranque, dependencias de servicios).

Preguntas frecuentes

1) ¿Por qué Proxmox dice “unable to activate storage” sin detalles?

Porque es un error envoltorio desde la capa del plugin de almacenamiento. El detalle real está en la salida de la tarea y en los logs del sistema. Revisa siempre journalctl y los logs de tareas de Proxmox.

2) ¿Puedo simplemente reiniciar el nodo para arreglar problemas de activación?

A veces, pero es una mala costumbre. Los reinicios pueden enmascarar carreras en el orden de arranque (iSCSI/multipath) y dificultar el diagnóstico de problemas intermitentes de NFS. Reinicia solo después de haber capturado la cadena de error.

3) El montaje NFS está presente pero Proxmox sigue reportando inactivo—¿por qué?

Si el montaje está obsoleto o no responde, Proxmox puede marcarlo offline porque las llamadas de estadísticas hacen timeout o devuelven errores. Usa una lectura con timeout para detectar bloqueos.

4) ¿Cuál es la forma más rápida de saber si el problema es LVM, NFS o CIFS?

pvesm status te dice el tipo de almacenamiento. Luego valida el estado a nivel OS: findmnt para NFS/CIFS, vgs/lvs para LVM.

5) ¿Debería usar CIFS para discos de VM?

En producción, lo evito para discos de VM. Las semánticas de CIFS y la variabilidad de latencia pueden producir casos límite desagradables. Úsalo para ISO/backup si es necesario y prueba el comportamiento ante fallos.

6) ¿Qué significa operacionalmente “stale file handle”?

El cliente referencia un objeto del servidor que ya no existe con la misma identidad. Suele ocurrir tras cambios en el filesystem del servidor o failover. Normalmente requiere remount; prevenirlo exige consistencia en el backing del export.

7) Mi VG LVM falta tras reinicio, pero el disco está allí. ¿Por qué?

LVM puede estar filtrando el dispositivo, o puede verlo bajo una ruta distinta a la esperada. Multipath también puede presentar duplicados. Verifica con pvs y estandariza el nombrado de dispositivos.

8) ¿Cuál es la forma más segura de arreglar un montaje NFS colgado?

Primero restaura la disponibilidad de red/servidor si es posible. Luego desmonta y remonta. Ten cuidado: procesos pueden quedar en D-state; los desmontajes forzados son disruptivos. Prefiere remounts planificados en una ventana controlada si hay I/O de VM involucrado.

9) ¿Por qué un nodo Proxmox monta CIFS y otro no?

Diferencias en paquetes instalados, DNS, sincronización de tiempo (Kerberos) o comportamiento del kernel/módulo. Compara opciones de montaje y revisa códigos de retorno en dmesg en ambos nodos.

10) ¿Cómo prevengo que esto vuelva a suceder?

Haz determinísticos los montajes y la activación LVM: fija versiones de protocolo, asegura el orden de servicios (iSCSI/multipath antes de LVM), monitoriza la capacidad de respuesta del montaje y el uso de metadata de thin pool, y documenta las dependencias de almacenamiento como si importaran—porque importan.

Conclusión: pasos siguientes para prevenir la secuela

“Unable to activate storage” es Proxmox diciéndote que el backend falló una comprobación básica de realidad. Trátalo así. Identifica el ID de almacenamiento, valida la verdad a nivel OS y luego usa logs para localizar la cadena de error subyacente. Arregla el backend, no la interfaz.

Pasos siguientes que merecen la pena:

• Escribe un runbook de una página para tu entorno con los IDs de almacenamiento exactos, puntos de montaje y opciones NFS/CIFS esperadas.
• Estandariza montajes: versión NFS explícita, dialecto SMB/seguridad explícita, rutas consistentes bajo /mnt/pve.
• Haz explícito el orden de arranque cuando el almacenamiento dependa de iSCSI/multipath, para que la activación LVM no compita con el universo.
• Monitoriza lo correcto: capacidad de respuesta del montaje (no solo “está montado”), uso de metadata de thin pool y errores de kernel recurrentes en montajes.

Haz eso y la próxima vez que Proxmox se queje, será un arreglo de cinco minutos en lugar de una tarde de reinicios rituales y ruleta de culpables.