Proxmox SMB/CIFS es lento para discos de VM: por qué es malo y qué usar en su lugar

Cómo se manifiesta realmente “SMB es lento” en Proxmox

Cuando la gente dice “SMB es lento”, normalmente se refiere a una de tres cosas:
el rendimiento secuencial es bajo, la latencia es alta, o el rendimiento es irregular.
A los discos de VM les importan más las dos últimas. Una VM puede arrancar con un rendimiento secuencial mediocre.
No tolerará latencias de escritura aleatorias de 500 ms mientras el hipervisor espera por semánticas síncronas.

La realidad en on-call no es “copiar un archivo es lento”. Es:

• Arrancar una VM tarda 4–10 minutos y luego, de repente, vuelve a la normalidad cuando las cachés se calientan.
• Las bases de datos se bloquean. Los diarios esperan. Aparecen mensajes “fsync() taking too long” en los logs.
• Latencia interactiva: sesiones SSH se quedan congeladas un segundo y luego se ponen al día.
• Las operaciones del clúster parecen embrujadas: migraciones se cuelgan, las copias de seguridad agotan el tiempo, procesos qemu quedan en estado D.
• Lo peor: todo está bien hasta que deja de estarlo, y entonces es un incidente de host completo.

Los discos respaldados en SMB suelen fallar la “prueba de previsibilidad”. Una pila de almacenamiento que entrega 5 ms la mayor parte del día pero 800 ms
cada vez que el antivirus escanea el servidor de archivos no es “rápida”, es “generadora de sorpresas”.

Broma #1: usar SMB para discos de VM es como usar un camión de reparto como coche de carreras. Se mueve, pero nadie está contento con los tiempos por vuelta.

Por qué SMB/CIFS es una mala opción para discos de VM

1) El I/O de discos de VM es pequeño, síncrono y sensible a la latencia

Mucho del I/O de las VM es lectura/escritura aleatoria de 4K–64K, además del churn de metadatos.
Los sistemas invitados y las aplicaciones también usan mucho fsync(), barreras y commits de diario.
Incluso cuando tu aplicación es “asíncrona”, el sistema de archivos invitado normalmente no lo es.

SMB es un protocolo de sistema de archivos remoto. Eso significa:
cada confirmación de escritura es una conversación de red más trabajo en el servidor más las semánticas de durabilidad que aplique el servidor.
Puedes optimizar parte de eso con características de SMB3, pero no puedes eliminar la física.

2) Capas extra añaden esperas extra (y formas extras de bloquearse)

Con discos VM sobre SMB, la ruta de I/O típicamente es:

• Filesystem del invitado → capa de bloque del invitado → virtio-scsi/virtio-blk
• QEMU en Proxmox → kernel del host → cliente CIFS
• Pila de red → switch → NIC → NIC del servidor de archivos
• Servidor Samba/SMB → sistema de archivos local en el servidor → almacenamiento del servidor

Cualquiera de esas capas puede introducir bloqueo por cabeza de línea. Los montajes CIFS pueden colgarse al reconectarse.
El sistema de archivos del servidor puede pausar por snapshots. El antivirus puede bloquear archivos.
Una escritura “simple” se convierte en reunión de comité.

3) Bloqueos, leases, oplocks y cachés están diseñados para archivos; los discos VM se comportan como bloques calientes

SMB es excelente para coordinar acceso a archivos compartidos. Los discos de VM no son “archivos compartidos” en el sentido feliz del camino.
Son grandes imágenes con patrones intensos de I/O aleatorio, a menudo accedidas por un solo proceso del hipervisor que espera semánticas estables y latencia constante.

Las funciones de caché y bloqueo de SMB (oplocks/leases) pueden ayudar cargas de trabajo normales de archivos.
Pero cuando ejecutas una base de datos dentro de una VM dentro de un archivo, estás construyendo una torre Jenga de cachés.
Un retraso transitorio de bloqueo se convierte en “MySQL se congeló” y ahora estás depurando la capa equivocada.

4) Las semánticas de conmutación por error y reconexión no son lo que esperan tus VM

SMB puede reconectarse. Suena bien hasta que ves cómo se ve una “reconexión” para un disco de VM:
largas pausas de I/O. Hilos de QEMU atascados. Timeouts en el invitado. A veces corrupción del sistema de archivos si la pila miente sobre durabilidad.

Sí, SMB3 tiene durable handles, witness, multichannel y más.
En la práctica, aún estás apostando todo al buen comportamiento de la pila SMB del servidor de archivos bajo fallos parciales.
Esa apuesta pierde más a menudo de lo que la gente admite en los postmortems.

5) Las semánticas de escrituras síncronas pueden dejarte fuera de combate en silencio

Los discos de VM, especialmente con los valores por defecto de QEMU y comportamiento del invitado, pueden generar muchas escrituras síncronas.
En el lado del servidor, eso puede mapear a comportamiento “write-through”, forzando commits en almacenamiento estable.
Si el almacenamiento subyacente del servidor no tiene caché en write-back con protección (BBU/flash-backed),
tus IOPS quedan limitados por latencia rotacional o por amplificación de escritura en SSDs de gama baja.

Incluso con buenos discos, SMB añade viajes de ida y vuelta. La latencia domina.
Puedes tener un enlace 10GbE y aun así obtener IOPS basura si cada I/O requiere múltiples esperas serializadas.

6) El beneficio de “permisos fáciles” es irrelevante para discos de VM

A la gente le gusta SMB porque las ACLs se integran con sistemas de identidad corporativa.
Eso importa para recursos de usuario. Rara vez importa para imágenes de disco de VM.
Para almacenamiento de VM quieres: rendimiento predecible, fallos predecibles y recuperación predecible.
La elegancia de las ACLs no te ayuda a las 3 a.m. cuando la VM ERP del CEO está colgada en estado D.

Idea parafraseada (John Allspaw, operaciones/confiabilidad): “Los sistemas complejos fallan de formas complejas; la fiabilidad viene del aprendizaje y la resiliencia, no de configuraciones esperanzadas.”

Hechos e historia interesante (corto, concreto y relevante)

1. SMB nació en los años 80 como protocolo de compartición de archivos en red; su ADN es “archivos”, no “dispositivos de bloque virtuales”.
2. CIFS fue básicamente la marca SMB1 y se hizo famoso por su chatarrería; SMB2/3 mejoraron mucho, pero la reputación está ganada.
3. SMB2 redujo viajes de ida y vuelta e introdujo control de flujo basado en créditos; eso ayudó en WANs, pero los discos VM siguen castigando la latencia.
4. SMB3 añadió cifrado y multichannel; genial para seguridad y throughput, pero el cifrado puede costar CPU e incrementar la variabilidad bajo carga.
5. Los servidores de archivos Windows popularizaron “la share como plataforma de almacenamiento”; la virtualización empujó a la industria de nuevo hacia almacenamiento en bloque o distribuido para discos.
6. NFS se convirtió en básico para virtualización en parte porque sus semánticas e implementaciones encajaron mejor con patrones de acceso a imágenes VM (especialmente en arrays empresariales).
7. iSCSI sobrevivió porque es aburrido: dispositivo de bloque, historia de multipath clara, semánticas predecibles para hipervisores.
8. El diseño RADOS Block Device (RBD) de Ceph se moldeó por la necesidad de servir I/O aleatorio tipo VM a escala con replicación y manejo de fallos incorporado.
9. Los debates “NAS vs SAN” han ciclado durante décadas; los discos VM siguen arrastrando a todos de vuelta a la latencia y al ordenamiento de escrituras.

Guía rápida de diagnóstico: encuentra el cuello de botella en minutos

Este es el orden que uso cuando un host Proxmox ejecuta VMs desde SMB y los usuarios dicen “todo el clúster está lento”.
El objetivo no es un benchmark perfecto. Es localizar el limitador dominante rápido para decidir: afinar, migrar o reemplazar.

Primero: confirma que es latencia de almacenamiento, no presión de CPU o memoria

• Revisa carga del host y espera de I/O. Si iowait sube con las VM congeladas, estás en el vecindario correcto.
• Confirma procesos qemu atascados en estado D (uninterruptible sleep). Eso suele ser esperas de almacenamiento.

Segundo: aisla dónde se introduce la latencia

• ¿Se está bloqueando el propio montaje SMB? Busca reconexiones CIFS, timeouts o “server not responding”.
• ¿La red está perdiendo paquetes o negociando parámetros incorrectos (MTU desajustada, control de flujo extraño)?
• ¿El subsistema de disco del servidor de archivos está saturado o forzando escrituras síncronas a medios lentos?

Tercero: valida las semánticas que configuraste accidentalmente

• Opciones de montaje SMB: modo de caché, actimeo, vers, multichannel, signing, encryption.
• Samba/servidor: strict sync, sync always, oplocks/leases, ajustes aio.
• Proxmox/QEMU: modo de caché del disco, hilo IO, backend aio, ajustes discard.

Cuarto: decide si afinar es un callejón sin salida

Si la carga es bases de datos, runners de CI, servidores de correo, o cualquier cosa con muchas escrituras síncronas pequeñas, deja de afinar SMB y empieza a planear migración.
Si son VMs de escritorio ligeras y la latencia es “solo” moderadamente mala, podrías aguantar con cambios temporales.

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

Estas son comprobaciones operacionales reales que puedes ejecutar en un host Proxmox y, donde corresponda, en el servidor SMB.
Cada tarea incluye: el comando, qué significa una salida típica y la decisión que tomarás a partir de ello.

Task 1: Confirmar iowait y cola de ejecución durante la ventana “lenta”

cr0x@pve1:~$ mpstat -P ALL 1 5
Linux 6.8.12-pve (pve1)  12/26/2025  _x86_64_ (32 CPU)

12:01:10 PM  CPU   %usr  %nice   %sys %iowait  %irq %soft  %steal  %idle
12:01:11 PM  all   12.3   0.0     4.1   38.7    0.0  0.6    0.0     44.3

Significado: 38.7% de iowait es una alerta roja: las CPU están inactivas pero esperando la finalización de I/O.
Decisión: trata esto como latencia de almacenamiento, no “necesita más CPU”. Pasa a comprobaciones de la ruta de I/O.

Task 2: Identificar qué dispositivos están realmente lentos

cr0x@pve1:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.52    0.00    3.90   36.10    0.00   49.48

Device            r/s     w/s   rMB/s   wMB/s  await  aqu-sz  %util
sda              0.2     1.1     0.0     0.1   2.10    0.00   0.3
dm-5            55.0   420.0     4.2    31.8  180.4   22.10  99.2

Significado: dm-5 está saturado con ~180 ms de espera media. Eso es “las VM se sienten aturdidas”.
Decisión: mapea dm-5 al almacenamiento subyacente del montaje SMB (a menudo un loop, un archivo o una capa FUSE).
Si es el montaje CIFS, procede a comprobaciones específicas de CIFS.

Task 3: Ver si los procesos qemu están bloqueados en I/O

cr0x@pve1:~$ ps -eo pid,stat,comm,args | grep -E "qemu-system|D " | head
21133 D    qemu-system-x86_64 /usr/bin/kvm -id 101 -name vm101 ...

Significado: El estado D indica sueño no interrumpible, comúnmente esperas de almacenamiento.
Decisión: confirma en qué sistema de archivos/montaje golpean esos I/O; busca bloqueos CIFS y latencia en el servidor.

Task 4: Confirmar que el disco de la VM está en almacenamiento SMB en Proxmox

cr0x@pve1:~$ qm config 101 | sed -n '1,120p'
boot: order=scsi0;ide2;net0
memory: 8192
name: vm101
scsi0: smbstore:101/vm-101-disk-0.qcow2,size=80G
scsihw: virtio-scsi-single

Significado: El disco es un archivo qcow2 en un almacenamiento llamado smbstore.
Decisión: espera doble indirección (metadatos qcow2 + semánticas del sistema de archivos SMB). Planifica migración a raw-on-block o RBD.

Task 5: Inspeccionar opciones de montaje CIFS en el host Proxmox

cr0x@pve1:~$ mount | grep cifs
//filesrv01/vmstore on /mnt/pve/smbstore type cifs (rw,relatime,vers=3.1.1,cache=strict,username=svc_pve,uid=0,gid=0,soft,nounix,serverino,mapposix,nofail)

Significado: soft puede causar errores de I/O ante salidas transitorias; cache=strict puede aumentar viajes de metadatos.
Decisión: elimina opciones “bonitas”. Evita soft para discos de VM; mejor aún: deja de usar SMB para discos de VM.

Task 6: Comprobar estadísticas del cliente CIFS por reconexiones y timeouts

cr0x@pve1:~$ cat /proc/fs/cifs/Stats
Resources in use
CIFS Session: 1
Share (unique mount targets): 1
SMB Request/Response Buffer: 1 Pool size: 5
SMB Small Req/Resp Buffer: 3 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects 17
Total vfs operations: 121044
Total timeouts: 9
Total retries: 203

Significado: reconexiones/timeouts durante horario laboral son riesgo de rendimiento e integridad de datos.
Decisión: trata la estabilidad de red y servidor como requisito. Si no puedes llevar las reconexiones a cero, migra fuera de SMB.

Task 7: Buscar errores CIFS en el registro del kernel

cr0x@pve1:~$ dmesg -T | grep -i cifs | tail -n 8
[Thu Dec 26 12:03:18 2025] CIFS: VFS: Server filesrv01 has not responded in 60 seconds. Reconnecting...
[Thu Dec 26 12:04:19 2025] CIFS: VFS: cifs_reconnect: server reconnect succeeded

Significado: Esos 60 segundos son una eternidad para discos de VM. Los invitados se colgarán; algunos se bloquearán.
Decisión: deja de fingir que esto es aceptable para almacenamiento de VM en producción. Arregla red/servidor o mueve el almacenamiento.

Task 8: Confirmar salud de la ruta de red (pérdidas, errores, sorpresas de MTU)

cr0x@pve1:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9123349901  9812331  0       214      0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    8331990021  8441122  0       0        0       0

Significado: Hay drops en RX. Pueden ser inofensivos o pueden correlacionar con picos.
Decisión: si las pérdidas aumentan durante las paradas, investiga buffers del switch, tamaños de anillos NIC, control de flujo y consistencia MTU extremo a extremo.

Task 9: Medir latencia al servidor de archivos bajo carga (no solo un ping)

cr0x@pve1:~$ ping -c 20 -i 0.2 filesrv01
PING filesrv01 (10.20.0.10) 56(84) bytes of data.
64 bytes from 10.20.0.10: icmp_seq=1 ttl=63 time=0.380 ms
64 bytes from 10.20.0.10: icmp_seq=2 ttl=63 time=0.412 ms
64 bytes from 10.20.0.10: icmp_seq=9 ttl=63 time=12.881 ms
64 bytes from 10.20.0.10: icmp_seq=10 ttl=63 time=0.401 ms

--- filesrv01 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3810ms
rtt min/avg/max/mdev = 0.362/1.104/12.881/2.776 ms

Significado: picos ocasionales de 10–15 ms ya son malos para I/O síncrono pesado. SMB amplifica esos picos.
Decisión: si existe jitter de latencia, no pongas discos de VM en un sistema de archivos remoto que dependa de viajes de ida y vuelta consistentes.

Task 10: Prueba rápida de I/O en el montaje SMB (la latencia cuenta la historia)

cr0x@pve1:~$ fio --name=randwrite --directory=/mnt/pve/smbstore --size=2G --bs=4k --rw=randwrite --iodepth=16 --numjobs=1 --runtime=30 --time_based --direct=1
randwrite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, ioengine=psync, iodepth=16
...
  write: IOPS=420, BW=1680KiB/s (1720kB/s)(50.0MiB/30500msec)
    lat (usec): min=2100, max=980000, avg=38000.12, stdev=92000.55

Significado: promedio 38 ms con latencias máximas cercanas a 1 s. Eso no es “un poco lento”. Eso es “pausas de VM”.
Decisión: deja de usar SMB para discos de VM con esta carga. Puedes afinar, pero no podrás eliminar latencias cola de 980 ms.

Task 11: Revisar configuración de almacenamiento Proxmox (qué entiende por “smbstore”)

cr0x@pve1:~$ cat /etc/pve/storage.cfg | sed -n '1,200p'
dir: local
        path /var/lib/vz
        content iso,vztmpl,backup

cifs: smbstore
        path /mnt/pve/smbstore
        server filesrv01
        share vmstore
        content images,backup
        username svc_pve
        vers 3.1.1

Significado: Proxmox trata esto como almacenamiento basado en archivos apto para imágenes y backups.
Decisión: mantiene SMB para backups/ISOs si es necesario; elimina images del contenido SMB si quieres menos incidentes.

Task 12: Inspeccionar modo de caché del disco QEMU (puede empeorar o solo cambiar el comportamiento)

cr0x@pve1:~$ qm config 101 | grep -E '^scsi0:'
scsi0: smbstore:101/vm-101-disk-0.qcow2,cache=writeback,discard=on,size=80G

Significado: cache=writeback puede mejorar la sensación de velocidad pero aumenta el radio de destrucción en caídas del host y paradas de SMB.
Decisión: no uses el modo de caché como curita para almacenamiento malo. Si necesitas writeback para ser “suficientemente rápido”, el backend está mal.

Task 13: Revisar políticas de escrituras síncronas en Samba (lado servidor)

cr0x@filesrv01:~$ testparm -sv 2>/dev/null | grep -E 'strict sync|sync always|aio read size|aio write size'
        aio read size = 1
        aio write size = 1
        strict sync = Yes
        sync always = Yes

Significado: sync always = Yes es un precipicio de rendimiento para discos de VM: obliga semánticas de almacenamiento estable en cada escritura.
Decisión: si este servidor es para documentos, mantén durabilidad. Si intentabas usarlo como SAN, detente y rediseña.

Task 14: Verificar que el sistema de archivos y almacenamiento del servidor no sean el verdadero limitador

cr0x@filesrv01:~$ iostat -x 1 3
Device            r/s     w/s   rMB/s   wMB/s  await  aqu-sz  %util
nvme0n1         120.0   980.0    22.4   110.8   3.20    1.90  72.0
md0              10.0   320.0     1.1    38.0  45.00   18.50  99.0

Significado: Un dispositivo está bien (NVMe), el dispositivo RAID/md está al 99% de util y 45 ms de espera.
Decisión: incluso si SMB fuera perfecto, el backend no lo es. Los discos VM castigarán este diseño. Mueve el almacenamiento VM a algo más rápido y orientado a VM.

Qué usar en su lugar: opciones de almacenamiento sensatas para Proxmox

Si recuerdas una cosa: los discos VM quieren almacenamiento de bloque o semánticas tipo bloque con latencia predecible.
También quieren una historia de recuperación que no implique “esperar que el servidor de archivos se reconecte rápido”.

Opción A: NVMe/SSD local con ZFS (rápido, predecible y sorprendentemente operable)

Para muchas tiendas Proxmox, la mejor respuesta es también la menos glamurosa:
coloca los discos de VM en NVMe/SSD locales y usa ZFS para integridad y snapshots.
Pierdes “almacenamiento compartido” para migración en caliente a menos que replique o uses replicación ZFS.
Ganas cola de latencia que no parece un monitor cardiaco.

Cuando ZFS local gana:

• Puedes tolerar migraciones planificadas o failover basado en replicación.
• Tu carga es sensible a la latencia y valoras la consistencia sobre la centralización.
• Quieres checksums de integridad fuertes y herramientas de snapshot sensatas.

La clave: almacena discos VM como ZVOLs (dispositivos de bloque) o archivos raw en ZFS, no qcow2 sobre SMB. Dale RAM a ZFS. Vigila la amplificación de escritura.

Opción B: Ceph RBD (almacenamiento compartido hecho de la manera difícil, que es la correcta)

Si necesitas almacenamiento compartido y migración en caliente a escala, Ceph es la respuesta nativa de Proxmox.
No es “fácil”. Es un sistema de almacenamiento con sus propios modos de fallo y requisitos operativos.
Pero está diseñado para lo que haces: servir dispositivos de bloque a hipervisores con replicación y recuperación incorporadas.

Cuando Ceph gana:

• Necesitas discos VM compartidos entre nodos.
• Necesitas tolerancia a fallos sin un servidor de archivos único como cuello de botella.
• Estás dispuesto a operar el almacenamiento como un sistema de primera clase: monitorización, planificación de capacidad y disciplina de upgrades.

Si tu clúster es pequeño y no tienes madurez operativa para Ceph, no lo fuerces. El almacenamiento compartido no es gratis.

Opción C: iSCSI + LVM (almacenamiento de bloque aburrido, funciona bien y con semánticas predecibles)

iSCSI es una elección frecuente de “adultos en la sala”: un array de almacenamiento exporta LUNs, los hosts ven dispositivos de bloque y multipath maneja fallos de camino.
Puedes poner LVM o LVM-thin encima en Proxmox.
El rendimiento suele ser sólido y el comportamiento bajo carga es más fácil de razonar que con SMB.

Donde iSCSI brilla:

• Tienes un array real o un target bien construido con caché y redundancia adecuada.
• Quieres almacenamiento central y rendimiento consistente.
• Necesitas una historia de multipath clara.

Opción D: NFS (mejor que SMB para imágenes VM, aunque no es la primera opción para cargas con muchas escrituras)

NFS se usa comúnmente para imágenes VM y puede funcionar bien cuando está respaldado por un NAS empresarial afinado para virtualización.
Tiende a tener menos “equipaje de servidor Windows” y semánticas orientadas a UNIX más simples en muchos entornos.
Aun así: es un sistema de archivos de red. La latencia y el comportamiento del servidor todavía importan.

Si usas NFS, utiliza un appliance de almacenamiento construido y soportado para almacenamiento de hipervisor,
y valida la latencia bajo carga de escrituras síncronas.

Opción E: SMB está bien para backups, ISOs, plantillas y almacenamiento frío

SMB no es maligno. Simplemente le estás pidiendo que sea algo que no es.
Úsalo para:

• Repositorios ISO
• Datastores de Proxmox Backup Server (mejor en discos locales, pero SMB puede ser aceptable para copias secundarias)
• Exportar backups a otro sistema
• Plantillas y artefactos “no sensibles a latencia”

Mantén los discos VM fuera de SMB a menos que la carga y el impacto de una outage sean triviales.
Si ambos son triviales, probablemente tampoco necesitabas Proxmox—pero aquí estamos.

Broma #2: La forma más rápida de acelerar el almacenamiento SMB para VM es dejar de usar almacenamiento SMB para VM.

Tres micro-historias corporativas del mundo de “parecía estar bien”

Micro-historia 1: El incidente causado por una suposición errónea (“10GbE significa que es rápido”)

Una empresa mediana tenía un clúster Proxmox para servicios internos: Git, CI, algunos servidores de aplicaciones Windows y una base de datos que todos fingían que no era crítica.
El almacenamiento era un recurso SMB en un servidor Windows porque el servidor ya tenía “mucho espacio” y el equipo de infraestructura gustaba de las herramientas de ACL.
También tenían uplinks 10GbE, lo que hacía a todos sentirse modernos y por tanto seguros.

El primer incidente serio empezó durante un escaneo de seguridad rutinario. El escáner golpeó el share del datastore de VM.
El antivirus del servidor de archivos vio miles de cambios a nivel de bloque dentro de archivos qcow2 como “interesantes”.
La CPU del servidor de archivos se disparó, la cola de disco creció y los tiempos de respuesta SMB pasaron de sub-milisegundos a “eventualmente”.

En el lado Proxmox, los procesos qemu se apilaron en estado D. Los invitados no murieron inmediatamente—simplemente dejaron de responder.
La monitorización reportó VMs saludables porque los procesos existían y los hosts estaban arriba. Los usuarios reportaron “todo está congelado”.
El equipo reinició un nodo Proxmox, lo que empeoró el problema: escrituras en caché que no se habían comprometido de forma segura se convirtieron en checks de sistema de archivos del invitado y en corrupción parcial.

La suposición errónea fue simple: 10GbE de throughput equivale a rendimiento de almacenamiento VM.
Tenían ancho de banda. No tenían latencia baja y estable bajo escrituras aleatorias síncronas.
Tras el postmortem, movieron los discos VM a mirrors ZFS locales y usaron replicación para el puñado de VMs que necesitaban recuperación más rápida.
El servidor de archivos volvió a lo que sabía hacer: archivos.

Micro-historia 2: La optimización que salió mal (modos de caché y “simplemente poner writeback”)

Otra organización ejecutaba una pequeña granja Proxmox donde alguien notó que las VMs con respaldo SMB eran lentas durante los inicios de sesión matutinos.
Un ingeniero bienintencionado cambió el modo de caché de disco de QEMU a writeback para “mejorar el rendimiento”.
Funcionó. Las tormentas de inicio de sesión fueron más suaves. El volumen de tickets bajó. Todos siguieron adelante.

Dos meses después un evento de energía golpeó el rack. El UPS aguantó y luego no. Los hosts cayeron abruptamente.
Al reiniciar, la mayoría de las VMs volvieron. Algunas no. Una VM de base de datos arrancó, pero la aplicación lanzó errores de integridad más tarde ese día.
Nadie tenía una cifra clara de “perdimos X segundos de escrituras” porque la ruta de almacenamiento implicaba múltiples cachés con semánticas de durabilidad distintas.

El problema no fue que writeback sea siempre malo. Fue que se usó writeback para ocultar un backend que no podía satisfacer las necesidades de latencia síncrona de la carga.
Optimizaron el síntoma y aumentaron la ambigüedad del fallo.
La solución posterior fue aburrida: moverse a iSCSI desde un pequeño array con caché protegido y configurar multipath correctamente.
El rendimiento se volvió estable y los fallos comprensibles.

Existe una deuda operativa especial en la que “aceleras las cosas” disminuyendo con qué frecuencia pides la verdad.
Parece éxito hasta el día en que la realidad presenta una queja.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día (medir latencia cola, no promedios)

Una compañía tipo fintech (el tipo que ama los dashboards) planificó una expansión Proxmox y quería almacenamiento compartido para migraciones.
SMB se propuso porque ya había un par de servidores de archivos altamente disponibles y el equipo de almacenamiento prometió “es enterprise”.
El equipo SRE no discutió por gusto. Pidieron una ventana de pruebas.

Ejecutaron fio desde un nodo Proxmox al montaje SMB propuesto con una carga modelada como discos VM: escrituras aleatorias de 4K, motor semi-síncrono, iodepth ajustado para simular contención.
La latencia media no fue terrible. El percentil 99.9 era un desastre, con picos periódicos de cientos de milisegundos.
Luego repitieron la prueba mientras disparaban actividad operacional normal en el servidor de archivos: snapshots, rotación de logs y un job de backup.
La cola empeoró.

El resultado fue políticamente incómodo pero operacionalmente perfecto: SMB fue aprobado solo para backups y almacenamiento ISO.
Los discos VM fueron a Ceph RBD porque la organización ya tenía apetito para operar un sistema distribuido y quería tolerancia a fallos a nivel de nodo.
Cuando más tarde un switch top-of-rack se comportó mal y causó pérdida transitoria de paquetes, Ceph degradó pero siguió usable; SMB probablemente lo habría convertido en paradas de VM a nivel cluster.

La práctica que los salvó no fue magia. Fue medir lo correcto (latencia cola) y probar durante ruido de fondo realista.
Aburrido, correcto, y evitó un incidente que habría sido achacado a “inestabilidad random de Proxmox”.

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

1) Síntoma: Las VM “se congelan” pero la CPU del host está mayormente inactiva

Causa raíz: alta latencia de almacenamiento y I/O bloqueado (qemu en estado D), a menudo durante reconexiones CIFS o pausas del servidor.

Solución: confirma con mpstat, iostat, dmesg y estadísticas CIFS; luego migra discos VM fuera de SMB (Ceph RBD, iSCSI o ZFS local).

2) Síntoma: Las copias de seguridad están bien, pero las cargas interactivas son horribles

Causa raíz: el throughput está bien, la latencia cola no. Las copias de seguridad son secuenciales; los discos VM son aleatorios y con muchas escrituras síncronas.

Solución: realiza benchmarks con I/O aleatorio de pequeño bloque y examina máximos/percentiles. No confíes en velocidad de copia de archivos como proxy.

3) Síntoma: El rendimiento es excelente tras un reinicio y luego empeora

Causa raíz: la calidez de caché oculta la latencia del backend hasta que el working set crece; caches de metadatos SMB y writeback enmascaran la realidad.

Solución: prueba frío y caliente. Observa la expulsión de caché del servidor, comportamiento de writeback y colas de disco. Prefiere almacenamiento con latencia consistente.

4) Síntoma: Errores aleatorios “Input/output error” dentro de los invitados

Causa raíz: CIFS montado con soft o comportamientos agresivos de timeout/reintento ante fallos transitorios.

Solución: evita soft para almacenamiento VM; arregla la estabilidad de la red; mejor aún, deja de usar SMB para discos de VM.

5) Síntoma: La migración se atasca o tarda una eternidad

Causa raíz: el almacenamiento SMB compartido se convierte en punto de serialización; operaciones de metadatos y bloqueos ralentizan bajo carga; el jitter de red perjudica.

Solución: usa Ceph/disco compartido en bloque para migración en vivo, o usa almacenamiento local con replicación y acepta ventanas planificadas.

6) Síntoma: Todo va mal cuando “alguien ejecuta un escaneo” o “arranca el backup”

Causa raíz: tareas de fondo del servidor de archivos (AV, snapshots, backups) compiten con I/O de VM e introducen picos de latencia.

Solución: separa responsabilidades. El almacenamiento de discos VM no debe compartir el mismo appliance y políticas que los shares de usuario.

7) Síntoma: Buena latencia en ping, mala latencia en I/O de disco

Causa raíz: las operaciones SMB no son ICMP; implican CPU del servidor, bloqueos de sistema de archivos, journaling y commits de almacenamiento.

Solución: mide lo que importa: latencia de I/O y comportamiento cola con fio y trazas reales de carga de VM.

Listas de comprobación / plan paso a paso

Checklist A: Si ya estás en SMB y sufres

1. Confirma que el síntoma es latencia de I/O: ejecuta mpstat y iostat -x durante el incidente.
2. Revisa la salud del cliente CIFS: busca reconexiones/timeouts en /proc/fs/cifs/Stats y logs del kernel.
3. Valida lo básico de red: pérdidas/errores, consistencia MTU y jitter de latencia al servidor.
4. Inspecciona restricciones del servidor: cola de disco, políticas de sync, jobs de snapshot, escaneos AV.
5. Detén la hemorragia: mueve las VMs más ruidosas (bases de datos, CI, correo) primero a SSD locales o almacenamiento en bloque.
6. Cambia el uso de almacenamiento en Proxmox: elimina images del SMB y úsalo para backups/plantillas.
7. Construye el reemplazo: elige Ceph/iSCSI/ZFS local según la realidad operativa, no la aspiración.
8. Migra con plan: programa ventanas de mantenimiento, prueba restores y valida integridad del sistema de archivos invitado tras los movimientos.

Checklist B: Elegir la alternativa correcta

• ¿Necesitas migración en vivo y discos compartidos? Prefiere Ceph RBD o un SAN iSCSI/FC adecuado.
• ¿Buscas el rendimiento fiable más simple? Mirrors NVMe locales con ZFS, más replicación para cargas críticas.
• ¿Ya tienes un NAS empresarial diseñado para VM? NFS puede ser aceptable; prueba la latencia cola primero.
• ¿Usas un servidor Windows porque existe? Úsalo para archivos y exportes de backup, no para discos VM primarios.

Checklist C: Movimientos seguros de migración (porque cambiar almacenamiento es donde las carreras van a morir)

1. Toma un backup fresco y haz una restauración de prueba de al menos una VM al almacenamiento destino.
2. Mueve una VM no crítica primero y valida rendimiento y logs durante un día laboral completo.
3. Monitorea latencia cola (99th/99.9th), no solo promedios, antes y después.
4. Documenta rollback: dónde está la imagen antigua, cómo volver a engancharla y dependencias DNS/aplicación.
5. Solo entonces migra las cargas ruidosas.

Preguntas frecuentes

1) ¿SMB siempre es lento, o solo lo es para discos de VM?

Mayormente es inestable (o lento) para discos de VM. SMB puede ser perfectamente válido para archivos de usuario, medios, backups y artefactos.
Los discos VM convierten latencia y jitter en outages.

2) ¿Y si uso SMB3.1.1 con multichannel y un servidor Windows rápido?

Puedes mejorar throughput y resiliencia, pero sigues usando un sistema de archivos de red para I/O sensible a la latencia similar a bloques.
Si tu carga es ligera, puede ser aceptable. Para bases de datos y servidores concurridos, sigue siendo la herramienta equivocada.

3) ¿Puedo hacer que SMB sea aceptable con opciones de montaje?

Puedes reducir el daño. No puedes hacerlo comportarse como un backend diseñado para discos VM.
Si tu “arreglo” es una pila de opciones de montaje más una hoja de cálculo de políticas de no tocar, ya perdiste.

4) ¿qcow2 sobre SMB es peor que raw sobre SMB?

Por lo general sí. qcow2 añade lecturas/escrituras de metadatos y comportamiento de fragmentación que amplifica latencia en sistemas de archivos remotos.
Raw reduce sobrecarga, pero no arregla las semánticas fundamentales de latencia y fallo de SMB.

5) ¿NFS es realmente mejor que SMB para discos de Proxmox?

A menudo sí, especialmente en almacenamiento diseñado para virtualización. Pero NFS sigue siendo un sistema de archivos de red.
Puede ser excelente, mediocre o terrible según el servidor y la red. Mide la latencia cola bajo carga real.

6) ¿Debería correr Ceph en un clúster pequeño de 3 nodos?

Quizá. Proxmox hace Ceph más accesible, pero sigue siendo un sistema distribuido.
Si puedes comprometerte con monitorización, disciplina de capacidad y redes predecibles, puede funcionar bien.
Si tu equipo tiene problemas con higiene básica de almacenamiento, ZFS local más replicación suele ser la victoria más segura.

7) ¿Cuál es la arquitectura “sencilla y suficiente” para almacenamiento fiable de VM?

Mirrors NVMe locales en cada nodo con ZFS, más replicación programada para VMs críticas y buenos backups.
No es tan glamoroso como almacenamiento compartido, pero es extremadamente efectivo y fácil de razonar cuando las cosas fallan.

8) ¿Por qué los congelamientos de VM correlacionan con “tareas de mantenimiento del servidor de archivos”?

Porque esas tareas provocan picos de latencia: snapshots, antivirus, dedupe, tiering, sincronizaciones en la nube y agentes de backup compiten por I/O y locks.
Los discos VM experimentan esos picos como escrituras detenidas e hilos I/O bloqueados.

9) Si SMB es malo para discos VM, ¿por qué Proxmox soporta almacenamiento CIFS?

Porque es útil para otros tipos de contenido: ISOs, backups, plantillas y compartición de archivos general.
“Soportado” no significa “buena idea para toda carga”.

10) ¿Cuál es la única métrica en la que debo alertar para este problema?

Latencia de disco a nivel host (await) y latencia visible en el invitado para fsync si puedes recolectarla.
También alerta en reconexiones/timeouts CIFS—son señales tempranas de humo antes de que los usuarios empiecen a gritar.

Próximos pasos que puedes hacer esta semana

Si hoy ejecutas discos VM sobre SMB y te importa la disponibilidad, trata esto como deuda técnica con intereses.
Tu objetivo no es “hacer SMB más rápido”. Tu objetivo es “dejar de depender del humor del servidor de archivos para la ruta de almacenamiento de VM”.

1. Ejecuta la guía rápida de diagnóstico durante tu próximo periodo lento y captura iowait, iostat, estadísticas CIFS y extractos de dmesg.
2. Clasifica las cargas: identifica las 5 VMs principales por IOPS de escritura y sensibilidad a fsync (bases de datos, CI, correo, servicios de directorio).
3. Elige tu destino:
   • ZFS local si quieres previsibilidad rápido.
   • Ceph RBD si necesitas almacenamiento compartido y puedes operarlo.
   • iSCSI si tienes un array y quieres semánticas de bloque aburridas.
4. Mueve una VM, valida latencia cola y estabilidad durante un día completo, luego mueve el resto por lotes.
5. Despromociona SMB a backups/plantillas/ISOs. Déjalo hacer lo que sabe hacer bien.

El beneficio es inmediato: menos “congelamientos aleatorios”, menos reinicios a medianoche y menos reuniones donde tienes que explicar que el almacenamiento “estuvo técnicamente arriba”.
Los sistemas en producción no se preocupan por lo “técnicamente”.