Problema

En entornos de virtualización con Proxmox VE es frecuente montar directorios NFS desde un NAS para backups, medios o almacenamiento de contenedores. Cuando el cliente NFS deja de responder, el daemon pvestatd entra en bucle de reintentos y el propio host pierde conectividad de la GUI/API. El síntoma típico es un nodo Proxmox “colgado”: no se pueden crear ni migrar máquinas, los servicios web de la interfaz desaparecen y la única salida es un reinicio forzado. El problema no siempre se refleja en los logs del NAS; a veces sólo aparecen mensajes de timeout en el cliente.

Este patrón se repite en instalaciones con:

  • Proxmox VE sobre hardware estándar (CPU, RAM, NVMe).
  • Varios VMs y LXCs que acceden a shares NFS simultáneamente.
  • NAS de consumo (Synology, QNAP) con discos mecánicos y RAID.
  • Conexión de 1 GbE sin errores visibles en la capa física.

El objetivo es proporcionar una metodología genérica para detectar la causa raíz y aplicar correcciones que eviten que el host quede inoperativo.

Causa

Los cuelgues de NFS pueden originarse en varios puntos:

  1. Timeouts de red y pérdida de paquetes
    En una red de 1 GbE, una única pérdida de paquetes prolongada (por ejemplo, una congestión temporal del switch) hace que el cliente NFS marque el servidor como “no responding”. Si el montaje está configurado como hard, el kernel bloquea la llamada de I/O hasta que el servidor responda, lo que congela cualquier proceso que intente acceder al share.

  2. Opciones de montaje inadecuadas
    Los valores por defecto (hard,intr,timeo=600,retrans=3) son seguros para datos críticos, pero en entornos donde la disponibilidad de la GUI es esencial, un hard sin intr impide que el proceso sea interrumpido. Un soft permite que la llamada falle después de varios intentos, devolviendo EIO al proceso y evitando el bloqueo total.

  3. Problemas del NAS

    • Sleep/Power‑saving: discos de 5400 rpm pueden entrar en modo de bajo consumo y tardar varios segundos en volver a estar disponibles, provocando timeouts.
    • Límites de nfsd: un número insuficiente de threads (nfsd = 8 por defecto) se saturan bajo carga de varios VMs, generando respuestas tardías.
    • Firmware/Kernel bugs: versiones antiguas de Synology DSM pueden perder paquetes bajo alta carga NFSv4.1.

  4. Configuración de la interfaz de red

    • Auto‑negotiation fallida: la NIC del host o del NAS puede renegociar velocidad/duplex, creando breves periodos sin enlace.
    • Buffers de NIC agotados: en entornos con tráfico intenso (backups + streaming) los buffers pueden llenarse y provocar pérdida de paquetes.

  5. Contención de recursos en el host

    • Bloqueos de LVM‑thin: cuando el backend LVM se queda sin espacio libre, las operaciones de escritura en los discos pueden bloquearse, y cualquier acceso NFS que dependa de esos discos se vuelve latente.
    • OOM silencioso: aunque no haya kills explícitos, la presión de memoria puede forzar al kernel a swapear procesos críticos, ralentizando la respuesta NFS.

Solución

Una estrategia de mitigación se compone de tres capas: prevención, detención rápida y recuperación.

1. Ajustar los parámetros de montaje

Para la mayoría de los casos donde la disponibilidad de la GUI es prioritaria, convierta los mounts críticos a soft con tiempos de espera más agresivos. Un ejemplo práctico:

mount -t nfs -o rw,vers=4.1,soft,timeo=30,retrans=2,intr nas_ip:/share/backup /mnt/backup
  • soft permite que la llamada falle después de retrans intentos.
  • timeo=30 reduce el timeout a 3 s (valor en decisegundos).
  • intr permite que señales como SIGINT interrumpan la operación bloqueada, evitando que pvestatd quede atrapado.

Si el share contiene datos críticos, mantenga hard pero añada intr y reduzca timeo:

mount -t nfs -o rw,vers=4.1,hard,soft,timeo=50,retrans=5,intr nas_ip:/share/media /mnt/media

2. Configurar watchdog y timeouts en Proxmox

Proxmox permite definir un watchdog de hardware o software que reinicie el nodo si el proceso pve-cluster deja de responder. Edite /etc/pve/datacenter.cfg:

watchdog: 1
watchdog_timeout: 120

Esto fuerza un reinicio controlado después de 2 minutos de inactividad, evitando la pérdida de 13 h observada.

3. Optimizar el NAS

  • Desactivar sleep en los discos del NAS (Synology → Storage Manager → HDD Hibernation → Disabled).
  • Incrementar nfsd threads: en DSM, sudo synoservice --restart nfsd después de editar /etc/sysconfig/nfs con RPCNFSDCOUNT=32.
  • Actualizar firmware a la última versión estable, que suele incluir correcciones para NFSv4.1.

4. Mejorar la capa de red

  • Forzar velocidad/duplex en ambas NICs (ethtool -s eth0 speed 1000 duplex full autoneg off).
  • Aumentar buffers: sysctl -w net.core.rmem_max=12582912 y net.core.wmem_max=12582912.
  • Habilitar jumbo frames solo si todo el hardware lo soporta; de lo contrario, mantenga MTU = 1500.

5. Monitoreo proactivo

Instale un agente de monitoreo ligero (Prometheus node_exporter o Zabbix) que recoja:

  • nfsstat -c cada minuto.
  • pveproxy y pvestatd status (systemctl is-active).
  • Latencia de ping al NAS y contadores de errores de la NIC (ethtool -S).

Configure alertas cuando los contadores de nfs: server X not responding superen 3 en 5 min.

Cuándo aplicar esta solución

Aplicable cuando:

  • El host Proxmox pierde la GUI/API y los logs muestran nfs: server … not responding.
  • Los mounts son críticos para backups, medios o contenedores LXC.
  • No hay evidencia de fallos de hardware físico (CPU, RAM, discos locales).

No aplicable si:

  • El problema se reproduce sin usar NFS (por ejemplo, solo discos locales).
  • Los logs del NAS indican fallos de hardware (SMART errors, discos defectuosos).
  • La red muestra errores de capa física persistentes (cableado dañado, switch defectuoso).

Código

# 1. Remontar con opciones soft y timeout reducido
umount /mnt/backup
mount -t nfs -o rw,vers=4.1,soft,timeo=30,retrans=2,intr nas_ip:/share/backup /mnt/backup

# 2. Aumentar nfsd threads en el NAS (Synology)
echo "RPCNFSDCOUNT=32" >> /etc/sysconfig/nfs
synoservice --restart nfsd

# 3. Forzar velocidad de la NIC del host
ethtool -s eno1 speed 1000 duplex full autoneg off

# 4. Ajustar buffers del kernel
sysctl -w net.core.rmem_max=12582912
sysctl -w net.core.wmem_max=12582912

Verificación

  1. Comprobar montaje: mount | grep nas_ip debe mostrar soft,timeo=30,retrans=2,intr.
  2. Simular caída: desconecta temporalmente el cable del NAS y verifica que los procesos que acceden al share retornan EIO en lugar de bloquearse (dmesg | grep nfs).
  3. Monitorear pvestatd: systemctl status pvestatd debe permanecer active (running) durante la simulación.
  4. Revisar métricas: en Prometheus, la serie nfs_client_requests_total no debe acumular errores críticos; los alertas de timeout deben desaparecer.
  5. Test de watchdog: fuerza un bloqueo con kill -STOP pveproxy y observa que el watchdog reinicia el nodo después del timeout configurado.

Notas adicionales

  • En entornos con alta concurrencia, considera usar NFSv4.2 o SMB 3.0 como alternativa; ambos manejan mejor la recuperación de errores.
  • Si el NAS es de alta disponibilidad (HA), monta los shares a través de un virtual IP gestionado por el propio NAS; esto evita que una única IP falle por problemas de red.
  • Cuando uses soft en datos críticos, implementa scripts de reintento a nivel de aplicación (por ejemplo, rsync --partial --inplace) para que los fallos de I/O no provoquen pérdida de datos.
  • Mantén siempre un snapshot local de los discos LVM‑thin antes de aplicar cambios en la configuración de NFS; así puedes volver rápidamente si una opción rompe la consistencia.