Time-outs de NFS en Proxmox: opciones de montaje que mejoran la estabilidad

Cómo se ven los “timeouts de NFS” en Proxmox (y por qué asustan)

“Timeout de NFS” suele ser un eufemismo. El sistema no está haciendo un timeout cortés; está bloqueándose.
En Linux, un sistema de archivos NFS montado en modo hard seguirá reintentando operaciones hasta que el servidor responda.
Esto es el comportamiento correcto para la integridad de datos, pero es un tipo especial de miseria cuando ese montaje contiene
discos de VM o destinos de backup.

En Proxmox, el radio de impacto depende de lo que haya en NFS:

• Almacenamiento de ISO/plantillas: molesto pero soportable. Las lecturas fallan, las operaciones reintentan.
• Destino de backup (vzdump): los trabajos se quedan colgados, los archivos de bloqueo perduran, el monitoring alerta como loco.
• Discos de VM en NFS: el host puede quedarse atascado en E/S. La E/S de los invitados se congela, a veces QEMU se pausa, a veces tienes sensaciones de split-brain sin realmente tenerlo.
• Almacenamiento compartido para migración: las migraciones se estancan a mitad de camino. Ahora tienes dos máquinas discutiendo sobre quién tiene el problema.

La razón por la que los timeouts de NFS son operativamente desagradables es que las fallas a menudo son parciales:
un path hace flap, una NIC cae, un buffer del switch se ahoga, un hilo del servidor se queda colgado. El cliente sigue intentando.
No obtienes un “down” limpio. Obtienes una casa encantada.

Dos verdades rápidas antes de empezar a ajustar

• Las opciones de montaje no arreglan una red rota. Pueden hacer que el comportamiento ante fallos sea más sensato y reducir bloqueos, pero no pueden vencer a la física.
• La estabilidad vence a la velocidad para el almacenamiento de Proxmox. Un almacenamiento rápido que se detiene ocasionalmente es más lento que uno modesto que nunca miente.

Datos interesantes y contexto histórico (porque el pasado sigue facturando)

1. NFS nació a mediados de los 80 en Sun Microsystems para compartir archivos entre estaciones de trabajo sin un bus de disco compartido.
2. NFSv3 es sin estado por diseño (el servidor no rastrea mucho el estado del cliente), lo que facilita la recuperación de reinicios de servidor pero desplaza la complejidad a otros lados.
3. NFSv4 introdujo estado (locks, sesiones, delegaciones). Mejores semánticas, más piezas móviles.
4. NFS sobre UDP solía ser común por rendimiento; TCP ganó en la práctica porque se comporta mejor en redes con pérdida y con offloads modernos de NIC.
5. El montaje “hard” es el predeterminado en muchos entornos porque la corrupción silenciosa de datos es peor que un bloqueo. Sí, es una elección sombría.
6. El cliente NFS de Linux usa timeouts RPC y backoff exponencial; “server not responding” no significa necesariamente que el servidor esté caído—a veces está congestionado.
7. Los patrones de E/S de discos de VM son hostiles para protocolos charlatanes: pequeñas lecturas/escrituras aleatorias, operaciones de metadata, fsyncs. NFS se estresa, quieras o no.
8. pNFS existe para escalar NFS, pero la mayoría de las configuraciones de Proxmox no lo usan; están en una sola cabeza y se preguntan por qué se comporta como una sola cabeza.

Una cita que debería estar pegada sobre cada panel de control de almacenamiento:
“La esperanza no es una estrategia.” — General Gordon R. Sullivan

Broma #1: NFS es como el Wi‑Fi de la oficina—cuando funciona, nadie se da cuenta; cuando falla, todos se convierten en ingenieros de red.

Playbook de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Cuando aparecen timeouts de NFS, tienes minutos para decidir: ¿es un problema del servidor, de la red,
o del comportamiento del cliente? Aquí está el orden que encuentra el cuello de botella más rápido en entornos reales.

Primero: confirma el modo de fallo (E/S bloqueada vs E/S lenta vs permiso/bloqueo)

• Busca “server not responding” en el registro del kernel en el nodo Proxmox. Si está ahí, estás en territorio de transporte/RPC.
• Comprueba si procesos están en estado D. Si ves QEMU, vzdump o hilos del kernel en D, tienes E/S bloqueada.
• Confirma si es un nodo o todos los nodos. Un solo nodo sugiere path NIC/switch; todos los nodos sugieren bloqueo en el servidor o fallo en el segmento de red compartido.

Segundo: prueba si el servidor NFS está sano ahora mismo

• Carga del servidor y latencia de disco: si el servidor está saturado o su almacenamiento de respaldo se está deteniendo, los clientes harán timeout.
• Capacidad de respuesta del servicio RPC: si rpcbind/hilos nfsd están atascados, incluso un servidor “pingable” no responderá llamadas NFS.
• Sanidad de la configuración de exportaciones: una exportación mal configurada puede comportarse como una falla intermitente cuando diferentes clientes negocian rutas/versiones distintas.

Tercero: valida el path de red como si no confiaras en él (porque no deberías)

• La pérdida y reordenación de paquetes importan más que el ancho de banda bruto. NFS es sensible a la latencia y odia los microbursts.
• Las discordancias de MTU provocan comportamientos de “funciona la mayor parte del tiempo” que arruinan tardes.
• Las malas configuraciones de LACP y el enrutamiento asimétrico causan paradas periódicas que se parecen exactamente a problemas del servidor NFS.

Punto de decisión

Si tienes tareas en estado D + “server not responding” en el kernel + retrans en subida, prioriza opciones de estabilidad
que eviten bloqueos en todo el clúster (y luego arregla el problema subyacente). Si no hay retrans pero
las operaciones son lentas, revisa la latencia de disco del servidor y la saturación de hilos NFS.

Opciones de montaje que realmente mejoran la estabilidad

Las opciones de montaje son donde importan las opiniones. Algunas elecciones son sobre rendimiento. Muchas tratan sobre cómo se comporta tu sistema
cuando el mundo se incendia. Proxmox vive en la categoría de “cuando el mundo se incendia” con más frecuencia de la que admitimos.

La recomendación base (valores predeterminados estables para NFS en Proxmox)

Para la mayoría de entornos Proxmox que usan NFS como destino de backup o almacén de ISO, comienza aquí:

cr0x@server:~$ cat /etc/pve/storage.cfg
nfs: nas-backup
        export /export/proxmox-backup
        path /mnt/pve/nas-backup
        server 10.10.20.10
        content backup,iso,vztmpl
        options vers=4.1,proto=tcp,hard,timeo=600,retrans=2,noatime,nodiratime,rsize=1048576,wsize=1048576
...output...

Desglosemos las partes importantes:

• vers=4.1: v4.1 añade sesiones y mejores semánticas de recuperación que v4.0, y evita algunas rarezas de la época v3. Es un buen “valor predeterminado moderno” cuando el servidor lo soporta.
• proto=tcp: TCP maneja pérdida y congestión con menos caos que UDP. Si aún usas UDP, admiro tu confianza y temo tu ventana de cambios.
• hard: mantenlo hard para almacenamiento de discos de VM y para backups si la corrección importa. Los montajes soft pueden devolver errores de E/S a mitad de escritura. Eso no es “manejo de timeouts”, es “ruleta de corrupción”.
• timeo=600,retrans=2: aumenta el timeout RPC (en décimas de segundo, así que 600 = 60s para muchas operaciones), reduce el número de reintentos antes de reportar. Esta combinación reduce el spam de logs y el thrash durante cortes. Aún bloqueas en montajes hard, pero lo haces con más educación.
• noatime,nodiratime: reduce escrituras de metadata. No soluciona timeouts, pero elimina ruido innecesario.
• rsize/wsize: usar 1M puede reducir overhead RPC en redes modernas. Si ves fragmentación o problemas raros de NIC, reduce el tamaño.

Hard vs soft: elige el fallo con el que puedes vivir

Esta es la decisión que la gente intenta evitar. No puedes.

• hard significa: las operaciones NFS reintentan indefinidamente. Tus procesos pueden colgarse. Tus datos están más seguros.
• soft significa: tras algunos reintentos, NFS devuelve un error. Tus procesos pueden fallar rápido. Tus datos pueden quedar inconsistentes si la aplicación no esperaba fallos de E/S en vuelo.

Para discos de VM en NFS, prefiero fuertemente hard. Un montaje soft puede causar corrupción del sistema de archivos invitado si las escrituras fallan.
Para destinos de backup, hard sigue siendo generalmente correcto—a menos que tu modelo operativo requiera que los trabajos fallen rápido y se reintenten más tarde
y aceptes fallos parciales de backup como “normales”. La mayoría de las empresas no lo dice en voz alta, pero algunas lo hacen.

intr y “¿puedo interrumpir un montaje colgado?”

Históricamente, intr permitía que señales interrumpieran operaciones NFS. En kernels Linux modernos, su comportamiento varía o se ignora según la versión y el protocolo NFS.
No apuestes tu plan de respuesta a incidentes a ello. Planifica rutas seguras de reinicio/evacuación en su lugar.

timeo y retrans: qué hacen realmente (y qué no hacen)

timeo es el timeout base RPC; retrans es cuántas veces el cliente retransmitirá una petición RPC antes de reportar un timeout al registro del kernel.
Con hard, incluso después de reportar un timeout, sigue reintentando. ¿Entonces por qué afinarlos?

• Reducir comportamiento de tormenta: retrans agresivos pueden generar tormentas RPC durante fallos del servidor, haciendo la recuperación más lenta.
• Mejorar observabilidad: un timeo mayor reduce falsos “server not responding” durante microbursts breves.
• Hacer failover menos dramático: si tienes NFS HA (o movimiento de VIP), quieres que los clientes toleren la transición sin derretirse.

actimeo / cacheo de atributos: un control de rendimiento que puede volverse un problema de corrección

El cacheo de atributos reduce viajes de metadata. Puede ayudar al rendimiento, especialmente con operaciones intensas en directorios.
Pero para directorios compartidos donde múltiples clientes modifican las mismas rutas (piense: caches de plantillas, algunas rotaciones de backup),
un cacheo demasiado agresivo puede crear momentos de “¿dónde está mi archivo?”.

Para destinos de backup de Proxmox, normalmente no necesitas cacheo de atributos sofisticado. Si lo ajustas, hazlo con cautela y mide.

lookupcache=positive y por qué puede reducir el dolor

En NFSv3/v4, lookupcache=positive puede reducir efectos de cache negativo de búsquedas (donde el cliente recuerda “archivo no encontrado” con demasiada agresividad).
Puede ayudar cuando las aplicaciones crean archivos y los buscan inmediatamente desde otros nodos.
No es magia, pero es uno de los pocos controles que puede arreglar problemas de “percepción obsoleta” sin cambiar el servidor.

nconnect: más conexiones, menos bloqueos por head-of-line (a veces)

Linux soporta nconnect para NFSv4.x en kernels recientes, abriendo múltiples conexiones TCP por montaje.
Puede mejorar el rendimiento y reducir bloqueos por head-of-line cuando una conexión sufre pérdida.
También puede amplificar la carga en un servidor con problemas y hacer llorar a los buffers de tu switch.

Úsalo solo después de verificar que CPU, NIC y almacenamiento del servidor tienen margen. Comienza con nconnect=4, no con 16.

Opciones a evitar (a menos que disfrutes escribir postmortems)

• soft para discos de VM: es un camino rápido a daños silenciosos bajo el fallo adecuado.
• proto=udp en redes modernas: no es 1999, y tus switches no lo adoran.
• noac como “arreglo” para vistas obsoletas: puede arrasar el rendimiento y aumentar la carga en el servidor; trátalo como quimioterapia.
• timeo excesivamente bajo: convierte la congestión transitoria en tormentas RPC autoinfligidas.

Broma #2: Si configuras soft,timeo=1,retrans=1 para “evitar bloqueos,” enhorabuena—tu almacenamiento ahora falla rápido, como la primera rotación on-call de una startup.

Elige la versión NFS adecuada (v3 vs v4.1) con intención

A Proxmox no le importa tu preferencia filosófica. Le importa que la E/S se complete.
La elección de versión afecta el locking, la recuperación y cómo se ve un “timeout”.

Cuándo NFSv4.1 es la opción por defecto correcta

• Namespace de exportación único y firewalling más limpio (típicamente solo 2049, dependiendo del servidor).
• Mejores semánticas de sesión que pueden hacer que fallos de red transitorios sean menos catastróficos.
• Locks con estado que suelen ser más previsibles en escenarios multi-cliente.

Cuándo NFSv3 sigue siendo razonable

• Appliances NAS legacy con implementaciones v4 poco fiables.
• Restricciones específicas de interoperabilidad (algunos arrays empresariales tienen ideas “especiales” sobre características v4).
• Preferencia por la depuración: v3 puede ser más fácil de razonar en ciertos trazados de paquetes porque es más simple.

Consideraciones de locking

Si almacenas imágenes de VM en NFS, el locking importa. Para qcow2 especialmente, el acceso concurrente es un desastre.
Asegúrate de que tu configuración garantice exclusividad: Proxmox hace su parte, pero las semánticas de bloqueo de NFS aún pueden influir,
particularmente en escenarios de failover.

Una regla práctica

Si puedes ejecutar NFSv4.1 de forma limpia de extremo a extremo, hazlo. Si no puedes, ejecuta v3 de forma limpia y acepta que eliges “simple y estable” sobre “con más funciones.”
La peor opción es “v4 a veces”, donde los clientes negocian comportamientos diferentes entre nodos.

Realidades de red: pérdidas, MTU, pause frames y por qué “hace ping” es irrelevante

Ping es una postal. NFS es transporte de mercancías con documentación. Puedes tener ping perfecto y NFS terrible.
Los timeouts suelen provenir de microbursts, agotamiento de buffers o retransmisiones que se hacen bola bajo carga.

Qué suele provocar “server not responding” de NFS en centros de datos estables

• Pérdida de paquetes bajo carga (cable malo, óptica marginal, ToR sobre suscrito, uplink congestionado).
• Discordancia de MTU (jumbo frames en un lado, no en el otro). Funciona hasta que deja de funcionar y entonces falla como truco de magia.
• Weirdness de flow control / pause frames que lleva a cortas paradas que disparan cascadas de timeout RPC.
• Problemas de hashing de LACP donde un miembro del enlace se satura mientras otros están inactivos.
• Errores en offloads de NIC (menos comunes ahora, pero reales). Problemas con TSO/GRO pueden manifestarse como picos extraños de latencia.

Postura operativa

Trata NFS como tráfico de almacenamiento, no como “solo red”. Ponlo en un path predecible:
VLAN dedicada, MTU consistente, configuración de bonding consistente, QoS consistente si la usas.
Si no puedes aislarlo, al menos mídelo.

Modos de fallo específicos de Proxmox: backups, migración y dolor en clúster

Backups vzdump a NFS: por qué se cuelgan de forma distinta a lo que esperas

Las copias de seguridad de Proxmox pueden implicar snapshots, compresión, escrituras fragmentadas y operaciones sync.
Cuando el destino NFS se detiene, el proceso de backup puede bloquearse en E/S del kernel.
Si ejecutas múltiples backups en paralelo, puedes amplificar la parada hasta una manada estruendosa autoinducida.

Enfoque práctico: limita la concurrencia, mantén el montaje estable y evita ajustes que creen tormentas de reintentos.
Si los backups deben “siempre terminar”, usa montajes hard y control operativo (planificación, límites de concurrencia).
Si los backups deben “fallar rápido”, acepta el riesgo y construye lógica de reintento y limpieza automatizada.

Discos de VM en NFS: los picos de latencia se convierten en incidentes para los invitados

Incluso pequeñas paradas de NFS se traducen en latencia en los invitados. Las bases de datos lo notan. Los sistemas de archivos lo notan. Los humanos lo notan.
Si colocas discos de VM en NFS, estás firmando:

• control estricto sobre el comportamiento de la red,
• rendimiento del servidor predecible,
• y opciones de montaje elegidas por corrección más que por “no colgarse”.

Efectos en clúster: un nodo malo puede arruinar la reunión

En un clúster Proxmox, problemas con almacenamiento NFS compartido pueden presentarse como:

• múltiples nodos registrando timeouts simultáneamente,
• operaciones de migración atascadas,
• operaciones de GUI esperando refresco de estado de almacenamiento,
• y la divertida: “todo parece sano excepto que no hace nada”.

Tu objetivo es hacer el modo de fallo predecible. Predecible es depurable. Depurable es solucionable.

12+ tareas prácticas con comandos, salidas y decisiones

Estas son tareas de campo. Cada una incluye: un comando, una salida de ejemplo, qué significa y qué decisión tomar.
Ejecútalas en el nodo Proxmox salvo que se indique lo contrario.

Task 1: Confirma lo que Proxmox cree que es el almacenamiento NFS

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        196540280        90581232       96023420   46.07%
nas-backup        nfs     active       7812500000      2123456789     5600000000   27.18%
...output...

Qué significa: El almacenamiento está “active” desde el punto de vista de Proxmox. Eso no garantiza que sea accesible; solo significa que el montaje existe y parece usable.

Decisión: Si el estado cambia entre active/inactive durante el incidente, sospecha flap del montaje o problemas de disponibilidad del servidor.

Task 2: Inspecciona las opciones de montaje efectivas

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/pve/nas-backup
10.10.20.10:/export/proxmox-backup /mnt/pve/nas-backup nfs4 rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.21,local_lock=none
...output...

Qué significa: Confirma las opciones efectivas. “relatime” aparece porque el kernel normaliza el comportamiento de atime.

Decisión: Si no ves hard/timeo/vers como esperas, ajusta storage.cfg o fstab y vuelve a montar deliberadamente.

Task 3: Observa el kernel quejarse en tiempo real

cr0x@server:~$ journalctl -kf | grep -i nfs
Dec 26 10:14:21 pve1 kernel: nfs: server 10.10.20.10 not responding, still trying
Dec 26 10:14:52 pve1 kernel: nfs: server 10.10.20.10 OK
...output...

Qué significa: Esto es comportamiento clásico de retrans/timeout con recuperación.

Decisión: Si “still trying” se repite durante minutos sin “OK”, trátalo como una interrupción real. Empieza a aislar: salud del servidor vs red.

Task 4: Encuentra tareas bloqueadas (estado D) e identifica quién está atascado

cr0x@server:~$ ps -eo pid,state,comm,wchan:32,args | awk '$2=="D"{print}' | head
23145 D qemu-system-x86  nfs_wait_bit_killable       /usr/bin/kvm -id 102 -name vm102 ...
30411 D vzdump           rpc_wait_bit_killable       vzdump 102 --compress zstd --storage nas-backup
...output...

Qué significa: Procesos en estado D esperan E/S no interrumpible. Matarlos usualmente no funciona; están atascados en el kernel.

Decisión: Si QEMU está bloqueado, asume impacto en invitados. Considera mover cargas fuera de este nodo tras la recuperación de NFS; no uses “kill -9” y esperes lo mejor.

Task 5: Revisa estadísticas RPC del cliente NFS para retrans y timeouts

cr0x@server:~$ nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
189432     814        0

Client nfs v4:
null         read         write        commit       open         open_conf    ...
0            48212        27111        135          324          0            ...
...output...

Qué significa: Las retransmisiones son una fuerte pista de pérdida de red o problemas de capacidad de respuesta del servidor.

Decisión: Si retrans sube rápidamente durante carga normal, prioriza investigación de red. Si retrans es bajo pero el rendimiento es malo, revisa disco/CPU del servidor.

Task 6: Revisa el estado por montaje y edad (útil para narrativas de “stale handle”)

cr0x@server:~$ cat /proc/mounts | grep nas-backup
10.10.20.10:/export/proxmox-backup /mnt/pve/nas-backup nfs4 rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.21 0 0
...output...

Qué significa: Confirma que es NFSv4 y muestra opciones clave. Esta es una comprobación rápida de “¿qué estamos ejecutando realmente?”.

Decisión: Si esperas v4.1 y ves v3 (o viceversa), has encontrado una desviación de configuración o un problema de negociación.

Task 7: Verifica exportaciones del servidor NFS desde la perspectiva del cliente

cr0x@server:~$ showmount -e 10.10.20.10
Export list for 10.10.20.10:
/export/proxmox-backup 10.10.20.0/24
/export/iso            10.10.20.0/24
...output...

Qué significa: Confirma visibilidad de exportaciones. Esto no valida completamente el comportamiento del namespace de NFSv4, pero detecta cambios obvios.

Decisión: Si la exportación no aparece o el acceso se restringe inesperadamente, deja de ajustar montajes y arregla exportaciones/ACLs.

Task 8: Prueba el comportamiento de E/S directamente en el montaje (test simple de latencia)

cr0x@server:~$ time sh -c 'dd if=/dev/zero of=/mnt/pve/nas-backup/.iotest bs=1M count=256 conv=fdatasync status=none'
real    0m5.842s
user    0m0.012s
sys     0m0.221s
...output...

Qué significa: Esto incluye un sync para forzar que el servidor confirme. Si esto pasa de segundos a minutos, estás viendo el problema, no imaginándolo.

Decisión: Si esto es lento pero retrans es bajo, sospecha latencia de disco del servidor o agotamiento de hilos del servidor NFS.

Task 9: Revisa contadores de errores de red en el nodo Proxmox

cr0x@server:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210 12345678  0       124      0       112233
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109 11223344  0       0        0       0
...output...

Qué significa: Drops en RX para tráfico de almacenamiento son malas noticias. Paquetes descartados pueden producir retrans/timeouts.

Decisión: Si los drops aumentan durante ventanas de backup, tienes congestión o problemas de buffers en NIC/switch. Considera QoS, VLAN separada o arreglos de capacidad.

Task 10: Valida MTU extremo a extremo (la trampa de jumbo frames)

cr0x@server:~$ ping -c 3 -M do -s 8972 10.10.20.10
PING 10.10.20.10 (10.10.20.10) 8972(9000) bytes of data.
8972 bytes from 10.10.20.10: icmp_seq=1 ttl=64 time=0.431 ms
8972 bytes from 10.10.20.10: icmp_seq=2 ttl=64 time=0.438 ms
8972 bytes from 10.10.20.10: icmp_seq=3 ttl=64 time=0.422 ms

--- 10.10.20.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
...output...

Qué significa: Esto confirma que jumbo frames funcionan entre cliente y servidor. Si falla con “Frag needed”, tienes un desajuste de MTU.

Decisión: Si jumbo falla, arregla MTU de forma consistente en todos los saltos o baja todo a 1500. MTU mixto es un impuesto a la fiabilidad.

Task 11: Confirma que el servidor NFS responde a probes RPC/NFS

cr0x@server:~$ rpcinfo -t 10.10.20.10 nfs 4
program 100003 version 4 ready and waiting
...output...

Qué significa: El servicio NFS es accesible sobre TCP. Si esto bloquea o falla durante el incidente, es o bien red o bien la pila RPC del servidor.

Decisión: Si rpcinfo falla desde múltiples clientes, céntrate en el servidor o en el segmento de red compartido en lugar de ajustar clientes.

Task 12: Traza un proceso colgado para confirmar que está atascado en E/S NFS

cr0x@server:~$ cat /proc/30411/stack
[<0>] rpc_wait_bit_killable+0x1d/0x60
[<0>] __rpc_execute+0x3a/0x90
[<0>] rpc_execute+0x44/0x50
[<0>] nfs4_call_sync+0x6a/0xa0
[<0>] nfs4_proc_write+0xa1/0x140
[<0>] nfs_file_write+0x10a/0x2a0
[<0>] vfs_write+0x1b4/0x2a0
[<0>] ksys_write+0x67/0xe0
[<0>] do_syscall_64+0x5b/0x110
...output...

Qué significa: La pila muestra el proceso esperando en la ruta RPC/NFS de escritura. Esto no es “lentitud de la app.” Es falta de respuesta en la ruta de almacenamiento.

Decisión: Deja de debatir ajustes de la aplicación. Estabiliza el path NFS y considera pausar nuevos trabajos de backup hasta la recuperación.

Task 13: Volver a montar con opciones más seguras (cambio controlado)

cr0x@server:~$ umount /mnt/pve/nas-backup
umount: /mnt/pve/nas-backup: target is busy.
...output...

cr0x@server:~$ fuser -vm /mnt/pve/nas-backup | head
                     USER        PID ACCESS COMMAND
/mnt/pve/nas-backup: root      30411 f.... vzdump
/mnt/pve/nas-backup: root      23145 f.... qemu-system-x86
...output...

Qué significa: No puedes desmontar porque procesos activos lo están usando, potencialmente atascados.

Decisión: No fuerces el unmount de un montaje que contiene discos de VM. Si es solo un destino de backup, considera detener/gestionar los trabajos primero y volver a montar en una ventana tranquila.

Task 14: Revisa logs de tareas de Proxmox por stalls relacionados con almacenamiento

cr0x@server:~$ tail -n 30 /var/log/pve/tasks/active
UPID:pve1:000076CB:0012ABCD:676D0B31:vzdump:102:root@pam:
status: running
starttime: 1766743800
...output...

Qué significa: La tarea está “running” pero no progresa. Combínalo con chequeos de estado D para confirmar que está bloqueada en almacenamiento.

Decisión: Si está bloqueada y el montaje es hard, planifica la recuperación: restaura la disponibilidad de NFS en lugar de intentar matar la tarea.

Task 15: Chequeo en el servidor (en el servidor NFS): saturación de hilos nfsd

cr0x@server:~$ ps -eLo pid,cls,pri,rtprio,stat,comm | grep -E 'nfsd|rpc'
  8123 TS  19      - S    nfsd
  8124 TS  19      - R    nfsd
  8125 TS  19      - D    nfsd
...output...

Qué significa: Si hilos nfsd están en estado D, probablemente están bloqueados en el almacenamiento del servidor (disco local, ZFS, controlador RAID, etc.).

Decisión: Si los hilos nfsd del servidor se bloquean, ninguna opción de montaje en el cliente te salvará. Arregla la latencia de almacenamiento del servidor o reduce la carga.

Tres microhistorias del mundo corporativo (todas anonimizadas, todas plausibles)

1) Incidente causado por una suposición errónea: “El NAS tiene enlaces redundantes, así que la red no puede ser”

Una empresa mediana ejecutaba un clúster Proxmox con backups en NFS. El NAS tenía NICs duales bondadas con LACP.
El equipo asumió que la redundancia significaba resiliencia. Las copias se programaban por la noche y “funcionaban la mayor parte del tiempo” hasta que una carga de fin de trimestre
aumentó y de repente los backups empezaron a colgarse en dos de cinco nodos.

La primera suposición: si el NAS es accesible, está bien. El ping funcionaba. La GUI cargaba. El dashboard del NAS mostraba “healthy.”
Pero en los nodos Proxmox, los registros del kernel mostraban repetidos “not responding” de NFS. Algunos procesos vzdump estaban en estado D.

Pasaron horas afinando opciones de montaje—bajar timeouts, subir timeouts, añadir soft en un nodo “solo para probar.”
Ese nodo dejó de colgarse… y empezó a producir backups parciales con errores de E/S. Casi promovieron un backup roto como “exitoso” porque el trabajo terminó.
El sistema de backup no corrompió datos silenciosamente; falló de forma ruidosa. Esa fue la única parte buena.

La causa real fue un desajuste de hashing de LACP: el switch hasheaba por L3/L4, el NAS hasheaba diferente, y la mayor parte del tráfico NFS cayó en un enlace físico.
Bajo pico de carga, ese enlace perdía ráfagas de paquetes. TCP recuperó, pero la latencia RPC subió lo suficiente para disparar retrans y “not responding”.

La solución fue aburrida: alinear políticas de hashing de LACP, validar con contadores de interfaz y mantener NFS en una VLAN predecible.
Solo después de que la red estuvo estable las opciones de montaje importaron—y entonces solo algo.

2) Optimización que se volvió en contra: jumbo frames + “nconnect en todas partes”

Otro equipo quería migraciones de VM más rápidas y backups más ágiles. Activaron jumbo frames (MTU 9000) en nodos Proxmox y el servidor NFS,
y activaron nconnect=8 porque alguien vio un benchmark. El primer día fue glorioso.
Luego aparecieron timeouts intermitentes de NFS durante ventanas de backup intensas.

Lo complicado: no fue una ruptura limpia. La mayor parte del tiempo volaba. A veces se detenía.
Las retrans subieron, pero solo durante picos. El equipo culpó al NAS.
El equipo del NAS culpó a Proxmox. El equipo de red culpó a “tráfico desconocido.” Todos tenían parte de la razón, lo cual es la peor clase de razón.

El problema oculto fue inconsistencia de MTU: los switches ToR soportaban jumbo, pero un enlace entre switches en el path se quedó en 1500.
La mayoría del tráfico evitaba ese enlace. Algunos flujos no. Esos flujos sufrieron fragmentación/blackholing según el manejo de ICMP.
Con nconnect, había más flujos, aumentando la probabilidad de que alguno tomara el path malo. La optimización facilitó el fallo.

Arreglaron MTU extremo a extremo y bajaron nconnect a 4 tras observar mayor uso de CPU en el servidor.
El rendimiento se mantuvo. Los timeouts pararon. Nadie pudo seguir con la narrativa de “solo hay que afinar más”.

3) Práctica aburrida pero correcta que salvó el día: montajes conservadores + límite de concurrencia

Una empresa ejecutaba backups nocturnos de muchas VMs a un destino NFS. Al principio notaron que el NAS a veces se pausaba por tareas de mantenimiento
y respondía lentamente durante uno o dos minutos. Aceptaron eso como realidad e ingenierizaron alrededor.

Hicieron tres cosas que no eran lo suficientemente emocionantes para una charla de conferencia:
NFSv4.1 estable sobre TCP con hard,timeo=600,retrans=2, una ventana de backup dedicada y un límite estricto de concurrencia para que solo pocas VMs hagan backup a la vez.
También tenían un dashboard que mostraba retrans de cliente y latencia de disco del servidor lado a lado.

Cuando un switch empezó a descartar paquetes bajo carga meses después, los backups se ralentizaron pero no implosionaron.
Los logs mostraron timeouts, pero el sistema se recuperó sin cascadas de tareas colgadas.
El on-call tuvo margen para identificar aumentos en drops RX y mover tráfico antes de que fuera crisis.

El postmortem fue refrescantemente aburrido: confirma drops, reemplaza una óptica sospechosa, valida MTU y LACP, listo.
El sistema de backups nunca fue titular. Ese es el objetivo.

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

1) Síntoma: “server not responding, still trying” durante backups; trabajos colgados horas

Causa raíz: montaje hard + parada del servidor o pérdida de paquetes. El cliente está haciendo lo correcto (reintenta indefinidamente).

Solución: mantén hard, sube timeo (p. ej., 600), mantén retrans bajo (2–3), arregla pérdida de red y/o latencia de almacenamiento del servidor. Reduce concurrencia de backups.

2) Síntoma: backups “terminan” pero la restauración falla o faltan archivos

Causa raíz: montajes soft devolviendo errores de E/S a mitad de escritura; las herramientas de backup no siempre interpretan los escritos parciales como esperas.

Solución: evita soft para destinos de backup a menos que tengas verificación y lógica de reintento explícita. Prefiere hard y planificación operativa.

3) Síntoma: solo un nodo Proxmox tiene problemas NFS

Causa raíz: problemas por nodo: NIC, configuración de bonding, cableado/óptica, bugs en el driver o problema en un puerto de switch.

Solución: compara contadores con ip -s link entre nodos; cambia cables/puertos; valida modo de bonding y hashing; verifica MTU.

4) Síntoma: los problemas aparecen solo en picos

Causa raíz: congestión, microbursts, drops en colas, saturación de CPU del servidor o picos de latencia en discos de respaldo.

Solución: mide retrans y drops RX; ajusta concurrencia de backups; considera VLAN/QoS separadas; soluciona cuellos de botella del servidor (disco, CPU, NIC).

5) Síntoma: errores “stale file handle” tras mantenimiento del servidor

Causa raíz: la exportación se movió, el sistema de archivos se recreó, rollback de snapshot o cambios de inode bajo la ruta exportada.

Solución: evita operaciones destructivas bajo exports; usa datasets/rutas estables; remonta clientes tras cambios disruptivos del servidor; para v4, asegura exports con pseudo-root consistentes.

6) Síntoma: migración se cuelga aunque el almacenamiento está “compartido”

Causa raíz: el almacenamiento compartido está presente pero sufre picos de latencia o stalls RPC intermitentes; la migración impacta E/S síncrona.

Solución: estabiliza NFS (red, servidor), usa NFSv4.1/TCP y evita ajustes heroicos. Si debes migrar durante inestabilidad, detén y arregla almacenamiento primero.

7) Síntoma: operaciones de GUI lentas, comprobaciones de estado de almacenamiento tardan

Causa raíz: operaciones de management que tocan paths montados; los cuelgues de NFS pueden propagarse a herramientas en espacio de usuario.

Solución: mantiene montajes NFS problemáticos fuera de rutas críticas; monta solo donde se necesite; asegura opciones de montaje y estabilidad del servidor; no pongas “todo” en un NFS inestable.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar un montaje NFS de backup existente en Proxmox

1. Identifica el alcance: ¿un nodo o muchos? Usa logs del kernel y nfsstat -c.
2. Confirma opciones de montaje reales: findmnt. Deja de confiar solo en archivos de configuración.
3. Asegura sanidad de protocolo: prefiere vers=4.1,proto=tcp salvo que haya razón en contrario.
4. Establece comportamiento de timeout conservador: hard,timeo=600,retrans=2 como base para estabilidad.
5. Reduce churn de metadata: noatime,nodiratime.
6. Verifica MTU extremo a extremo: jumbo o funciona en todas partes o no pertenece a ninguna parte.
7. Chequea drops: ip -s link en clientes; contadores de interfaz en switches (sí, míralos de verdad).
8. Limita concurrencia de backups: menos trabajos vzdump paralelos, especialmente en ventanas en que el NAS está ocupado.
9. Mide tendencias de retrans: si retrans sube con la carga, deja de culpar opciones de montaje y arregla transporte/servidor.
10. Prueba con escrituras sync forzadas: dd ... conv=fdatasync para detectar latencia de commit.
11. Planifica tareas de servidor disruptivas: scrubs, snapshots, replicación, dedupe—no las superpongas con picos de backup si te gusta apostar.
12. Documenta la semántica elegida: “montaje hard; timeouts significan bloqueo; la respuesta a incidentes es restaurar servicio, no matar procesos.” Hazlo explícito.

Checklist: cuando almacenas discos de VM en NFS (sé honesto contigo)

• Path de red de almacenamiento dedicado (VLAN o físico), MTU consistente.
• NFSv4.1 sobre TCP; considera nconnect solo después de baseline estable.
• Montaje hard. Siempre. Si quieres soft, necesitas otro diseño de almacenamiento.
• El servidor debe tener latencia predecible bajo cargas de sync de escritura.
• Monitoring incluye retrans, latencia de disco del servidor y drops en switches.
• Respuesta planificada para outage de NFS: qué pasa con los invitados, qué haces primero, qué nunca haces.

Checklist: monitoreo mínimo que detecta el problema real

• Tasa de conteo de retrans de cliente (desde nfsstat -c o equivalentes de node exporter).
• Drops y errores RX/TX en el cliente (desde ip -s link).
• Latencia de disco del servidor y profundidad de cola (herramientas según stack del servidor).
• Salud de hilos del servidor NFS (nfsd no bloqueado).
• Duración de trabajos de backup y concurrencia.

Preguntas frecuentes

1) ¿Debo usar soft para evitar que Proxmox se congele?

No para discos de VM. Para backups, solo si aceptas explícitamente fallos parciales y verificas backups de extremo a extremo.
De lo contrario, mantén hard y arregla la inestabilidad subyacente.

2) ¿Cuál es un timeo y retrans sensatos para Proxmox?

Una base pragmática es timeo=600,retrans=2 para montajes enfocados en estabilidad. Luego mide.
Si tienes failover rápido y quieres detección más rápida, baja timeo con cautela, pero no crees tormentas de reintentos.

3) ¿NFSv4 siempre es mejor que NFSv3?

No. NFSv4.1 suele ser mejor cuando está bien implementado, especialmente para recuperación de sesiones y firewalling simplificado.
Pero un servidor NFSv3 sólido vence a un NFSv4 defectuoso cualquier día.

4) ¿rsize/wsize arreglan timeouts?

No directamente. Pueden reducir overhead RPC y mejorar throughput, lo que puede reducir stalls relacionados con congestión.
Pero si tienes pérdida de paquetes o stalls del servidor, tamaños mayores pueden agudizar los síntomas.

5) Mi montaje NFS aparece “active” en Proxmox, pero las operaciones se cuelgan. ¿Por qué?

“Active” significa montado y accesible a un nivel básico. NFS puede estar montado y ser no responsivo para ciertas operaciones.
Usa logs del kernel, chequeos de estado D y nfsstat -c para confirmar el bloqueo.

6) ¿Puedo desmontar y montar de nuevo NFS durante un incidente de forma segura?

Si contiene discos de VM: generalmente no, ni de forma segura ni rápida. Si es solo un destino de backup y puedes detener trabajos limpiamente, a veces sí.
Tu objetivo es restaurar el servicio NFS, no jugar al tira y afloja con la capa VFS.

7) ¿Qué provoca “stale file handle” y cómo evitarlo?

Cambios en el servidor bajo la ruta exportada: rollback, recreación, mover datasets o cambiar raíces de exportación.
Evítalo manteniendo rutas de exportación estables y evitando operaciones destructivas bajo exports activos.

8) ¿Debería activar nconnect?

Solo después de probar una estabilidad base (sin drops, latencia sensata, servidor con margen de CPU).
Puede mejorar throughput y reducir bloqueos por head-of-line, pero también puede amplificar carga del servidor y exponer inconsistencias en path de red.

9) ¿Necesito una red de almacenamiento dedicada para NFS?

Si NFS aloja discos de VM o backups críticos, sí—al menos una VLAN dedicada con MTU predecible y vecinos ruidosos limitados.
Las redes “todo compartido” son donde la fiabilidad va a humillarse.

10) ¿Cuál es la mejor acción cuando los timeouts empiezan a mitad de un backup?

Deja de iniciar nuevos trabajos de backup. Reduce la carga mientras diagnosticas. Luego confirma si el problema son retrans/drops (red) o bloqueo de disco/CPU (servidor).

Conclusión: próximos pasos que sobreviven al contacto con producción

Si Proxmox sufre timeouts con NFS, no lo trates como una cacería de opciones de montaje. Las opciones importan, pero no son tu causa raíz.
Úsalas para modelar el comportamiento ante fallos: menos tormentas, señales más claras, semánticas más seguras.

Pasos prácticos siguientes:

1. Fija una línea base de montaje estable: vers=4.1,proto=tcp,hard,timeo=600,retrans=2,noatime,nodiratime, más rsize/wsize sensatos.
2. Ejecuta el playbook de diagnóstico rápido en el próximo incidente: confirma estado D, confirma retrans, revisa drops/MTU y luego la latencia del servidor.
3. Limita la concurrencia de backups y evita superponer mantenimiento intensivo del servidor con ventanas de backup.
4. Instrumenta retrans y drops de interfaz como métricas de primera clase. Si no ves retrans subir, estás depurando a ciegas.
5. Cuando necesites más rendimiento, añade capacidad o corrige topología antes de añadir ingeniosidades como cacheo agresivo o nconnect alto.

NFS puede ser estable en Proxmox. Solo necesita adultos en la sala: semánticas conservadoras, afinamiento medido y una red que no improvise.