Problema

En entornos de virtualización con Proxmox VE, es frecuente encontrarse con mensajes en el Visor de Eventos de Windows como “The IO operation at logical block address xxxx for disk x (PDO name xxxx) was retried.”. Cuando el mismo VM ejecuta copias de seguridad “app‑aware”, aparecen también VSS timeouts que hacen fallar la tarea. Los síntomas típicos son:

  • Avisos de “IO operation retried” que aparecen de forma intermitente, sin correlación directa con la carga de usuarios.
  • Fallos de VSS durante backups, especialmente cuando se usan soluciones como Nakivo o Veeam.
  • Incremento de latencia percibida en aplicaciones críticas (ERP, bases de datos) que no se había notado antes de una actualización de Proxmox o del driver VirtIO.

El problema no está limitado a una versión concreta de Proxmox; cualquier combinación de cambios en el bus de disco (IDE → SCSI), versión del driver VirtIO y parámetros de caché puede desencadenar este patrón.

Causa

1. Incompatibilidad del driver VirtIO con el bus SCSI

Los drivers VirtIO 0.1.285 introdujeron cambios en la capa de SCSI que, en algunos kernels de Proxmox 9, provocan resets de comando cuando el host intenta usar discard o write‑back en discos qcow2 con aio=io_uring. El reset se traduce en el mensaje de “IO operation retried”.

2. Configuración de caché no alineada con el tipo de almacenamiento

Usar cache=none (no cache) en discos qcow2 sobre un RAID5 de mdadm obliga a que cada operación de escritura pase directamente al subsistema RAID. En presencia de latencia de escritura del RAID (por ejemplo, cuando se ejecutan snapshots o backups), Windows interpreta la demora como un fallo y reintenta la operación.

3. VSS depende de la capacidad del host para congelar I/O

VSS necesita que el hipervisor pueda detener momentáneamente los I/O del disco. Si el driver VirtIO está enviando resets o si el host está saturado por operaciones de discard y trim, VSS no logra completar el “freeze” y termina con timeout.

4. QoS del RAID5 y escritura de metadatos

RAID5 en mdadm realiza cálculos de paridad en cada escritura. Cuando varios VMs comparten el mismo pool y se habilita aio=io_uring, el número de operaciones simultáneas puede superar la capacidad de cálculo del RAID, generando cuellos de botella que se reflejan como retries en el guest.

Solución

A. Revertir a una versión estable del driver VirtIO

Si la actualización a 0.1.285 coincidió con la aparición de los síntomas, volver a 0.1.248 (o a la versión que estaba en producción) suele eliminar los resets de SCSI. La instalación se hace dentro del VM:

# Descargar versión anterior
wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/virtio-win-0.1.248.iso -O /tmp/virtio-win.iso
# Montar y ejecutar el instalador
mount -o loop /tmp/virtio-win.iso /mnt
cd /mnt/viostor
setup.exe

B. Cambiar el bus de disco a VirtIO‑Block (no SCSI) para VMs Windows

VirtIO‑Block es menos propenso a los resets de SCSI y funciona bien con aio=io_uring. En la configuración del VM (/etc/pve/qemu-server/<vmid>.conf), sustituir:

scsi0: local-lvm:vm-100-disk-0,size=120G,cache=none,iothread=1,discard=off,aio=io_uring

por:

virtio0: local-lvm:vm-100-disk-0,size=120G,cache=writeback,iothread=1,discard=on,aio=native

C. Ajustar la política de caché

Para discos críticos (ERP, bases de datos) usar cache=writeback o cache=writeback,discard=on. Esto permite que el hipervisor mantenga un búfer de escritura y reduzca la latencia percibida por el guest. En VMs donde la consistencia absoluta es prioritaria (por ejemplo, servidores de dominio), mantener cache=none está bien, pero combinarlo con iothread=0 y aio=native evita la sobrecarga de io_uring.

D. Desactivar discard temporalmente en el host

Si el RAID5 no soporta trim de forma nativa, desactivar discard=off en la línea de disco elimina la generación de comandos de “trim” que pueden colisionar con VSS. En el host:

pvesh set /nodes/<node>/qemu/<vmid>/config -scsi0 local-lvm:vm-<vmid>-disk-0,discard=off

E. Optimizar el RAID5

  • Añadir un cache SSD (bcache o LVM cache) delante del mdadm RAID5 para absorber escrituras de metadatos.
  • Incrementar el número de discos a 4 o 5 para reducir la carga de cálculo de paridad.
  • Verificar que el stripe size del RAID coincida con el tamaño de bloque de los discos (por defecto 64 KB en la mayoría de SSD SAS).

F. Configurar VSS en el host

Proxmox permite habilitar el VSS proxy mediante el paquete pve-qemu-kernel. Asegúrate de que el paquete está instalado y que la opción vss=1 está presente en la configuración del VM:

vss: 1

Si la opción no existe, añádela manualmente.

Cuándo aplicar esta solución

  • Aparecen mensajes “IO operation retried” de forma recurrente y no se limitan a los primeros minutos después del arranque.
  • Los backups app‑aware fallan con VSS timeout aunque la red y el almacenamiento estén sanos.
  • Se ha actualizado Proxmox o el driver VirtIO en los últimos 30 días.
  • El RAID está configurado como mdadm RAID5 y se usan discos SSD de alta velocidad (SAS/NVMe) sin caché adicional.
  • No se requiere una migración completa a otro tipo de almacenamiento; la solución busca ajustes no destructivos.

No aplicar si:

  • El VM usa exclusivamente discos RAW con cache=writeback; los problemas suelen estar en otro nivel (hardware, firmware).
  • Los logs del host indican fallos de hardware (SMART crítico, errores de controlador RAID).

Código

# 1. Verificar versión del driver VirtIO dentro del VM
wmic path Win32_PnPEntity where "Name like '%VirtIO%'" get Name,DriverVersion

# 2. Cambiar configuración del disco a VirtIO‑Block y writeback
pvesh set /nodes/pve1/qemu/101/config \
  -virtio0 local-lvm:vm-101-disk-0,cache=writeback,iothread=1,discard=on,aio=native \
  -delete scsi0

# 3. Desactivar discard en caso de incompatibilidad
pvesh set /nodes/pve1/qemu/101/config -virtio0 local-lvm:vm-101-disk-0,discard=off

# 4. Habilitar VSS proxy
pvesh set /nodes/pve1/qemu/101/config -vss 1

Verificación

  1. Reinicia la VM y abre el Visor de Eventos. Busca que desaparezcan los warnings “IO operation at logical block address … was retried”.
  2. Ejecuta una copia de seguridad app‑aware (Nakivo, Veeam, etc.). El job debe completarse sin VSS timeout.
  3. Mide la latencia con winsat disk dentro del VM. Los valores de “Average Disk Write Speed” deben estar dentro del rango esperado para el SSD subyacente.
  4. Monitorea el RAID con mdadm --detail /dev/md0 y verifica que no haya degradaciones ni aumentos de tiempo de respuesta (iostat -x 5 3).

Notas adicionales

  • En algunos casos, combinar aio=io_uring con cache=none genera una sobrecarga de interrupciones en el kernel de Proxmox. Cambiar a aio=native suele ser más estable.
  • Si el entorno permite migrar a ZFS en lugar de mdadm, el manejo de snapshots y VSS mejora significativamente, pero implica una re‑planificación de almacenamiento.
  • Mantener una copia de la configuración original (cp /etc/pve/qemu-server/101.conf 101.conf.bak) antes de aplicar cambios evita sorpresas en caso de revertir.
  • Las versiones de VirtIO para Windows se actualizan cada pocos meses; revisar el changelog antes de aplicar una nueva versión ayuda a anticipar problemas de compatibilidad.