Problema

En entornos de virtualización donde la carga es mayormente tráfico de voz, la latencia y la consistencia del I/O son críticos. Al migrar de un hipervisor que abstrae automáticamente la gestión de discos y redes a Proxmox, muchos administradores descubren que:

  • El rendimiento del almacenamiento cae drásticamente con configuraciones RAID tradicionales (RAID 5, RAID 6) y con políticas de I/O por defecto.
  • Las operaciones de mantenimiento – migraciones en vivo, backups y restores – compiten por ancho de banda, provocando jitter y pérdida de paquetes en los flujos de VoIP.
  • La asignación de colas de red (multi‑queue) no se adapta automáticamente al número de vCPUs, lo que genera cuellos de botella en NICs de 10 GbE o superiores.

El síntoma típico es aumento de MOS bajo carga, retransmisiones de RTP y, en casos extremos, caída de llamadas mientras se ejecutan tareas de infraestructura.

Causa

Almacenamiento

  1. RAID 5/6 y escritura de pequeños bloques – Los algoritmos de paridad añaden latencia de cálculo y escrituras de lectura‑modifica‑escritura (RMW). En workloads con muchos paquetes de audio (≈ 20 KB) el overhead se vuelve visible.
  2. Controladores de disco sin colas (queue depth) ajustado – El driver default suele quedar en 32 I/Os, insuficiente para cientos de VM que generan I/O simultáneo.
  3. Falta de QoS a nivel de storage – Proxmox expone io y mbps por disco, pero sin políticas de prioridad los backups saturan el backend.

Red

  1. Multi‑queue desactivado o sub‑dimensionado – Cada vCPU necesita al menos una cola de transmisión y recepción. Si la VM tiene 8 vCPU y la NIC está configurada con 2 colas, el kernel de la VM se queda sin interrupciones para procesar paquetes.
  2. Interrupt coalescing agresivo – Reduce la carga de CPU pero aumenta la latencia, algo que el tráfico de voz no tolera.
  3. Sin shaping de tráfico – Cuando una migración usa todo el ancho de banda, el flujo de VoIP comparte la misma interfaz sin limitación.

Solución

Una estrategia de tres capas suele ser suficiente:

1. Optimizar el backend de almacenamiento

  • Migrar a RAID 10 o a un pool ZFS con recordsize=4K y logbias=throughput. Elimina la penalización de paridad y permite escrituras alineadas con paquetes de audio.
  • Ajustar el queue depth del controlador mediante modprobe o parámetros del firmware. Por ejemplo, para un controlador LSI: 
    echo 256 > /sys/block/sdX/device/queue_depth
  • Aplicar QoS por disco en Proxmox usando qm set o pct set. Limita los backups a 50 MB/s y reserva al menos 150 MB/s para los discos de las VM de VoIP: 
    qm set 101 --io 0 --mbps 150
qm set 101 --backup 0 --mbps 50
    (Reemplazar 101 por el ID de la VM).

2. Configurar límites de ancho de banda en migraciones y backups

Proxmox permite establecer migration_speed y backup_rate. En el archivo datacenter.cfg:

migration_speed: 64   # MB/s, ajusta según capacidad del backbone
backup_rate: 32       # MB/s por nodo

Para migraciones puntuales, el comando qm migrate acepta --bandwidth:

qm migrate 101 target-node --bandwidth 32

Esto evita que una migración consuma todo el enlace de 10 GbE.

3. Habilitar y dimensionar multi‑queue en NICs

  • Activar colas en la NIC física con ethtool: 
    ethtool -L eth0 combined 16
    El número de colas debe ser al menos vCPU * 2 para evitar saturación.
  • Pasar la configuración a la VM usando virtio-net-pci con mq=on y vectors=...: 
    qm set 101 --net0 virtio,bridge=vmbr0,queues=8,mq=on
  • Desactivar coalescing agresivo si la latencia supera 2 ms: 
    ethtool -C eth0 rx-usecs 20 rx-frames 1 tx-usecs 20 tx-frames 1

4. Automatizar con hooks

Proxmox permite scripts hook que se ejecutan antes y después de backups o migraciones. Un ejemplo sencillo para reducir la prioridad de I/O durante un backup:

#!/bin/bash
# /etc/pve/local/hooks.d/backup_io_limit.sh
if [[ "$1" == "backup-start" ]]; then
  echo 32 > /sys/block/sdX/device/queue_depth
elif [[ "$1" == "backup-end" ]]; then
  echo 256 > /sys/block/sdX/device/queue_depth
fi

Colócalo en /etc/pve/local/hooks.d/ y habilítalo en la VM con --hookscript.

Cuándo aplicar esta solución

Aplica cuando:

  • La carga de VoIP supera los 500 concurrentes y el MOS cae bajo 3.5 durante operaciones de mantenimiento.
  • Se observan picos de I/O > 200 MB/s en discos compartidos.
  • Las métricas de netstat -s muestran pérdida de paquetes o retransmisiones en momentos de migración.

No aplica si:

  • El entorno es de pruebas con menos de 50 usuarios simultáneos; la sobrecarga de tuning puede no justificar el esfuerzo.
  • Se usa almacenamiento en la nube con latencias inherentes que no pueden ser mitigadas con RAID o queue depth.

Código

# Ajustar queue depth del disco
echo 256 > /sys/block/sdX/device/queue_depth

# Limitar I/O de una VM (ID 101)
qm set 101 --io 0 --mbps 150
qm set 101 --backup 0 --mbps 50

# Configurar ancho de banda de migración
qm migrate 101 target-node --bandwidth 32

# Habilitar 16 colas en NIC física
ethtool -L eth0 combined 16

# Configurar multi‑queue en la VM
qm set 101 --net0 virtio,bridge=vmbr0,queues=8,mq=on

# Reducir coalescing para latencia <2 ms
ethtool -C eth0 rx-usecs 20 rx-frames 1 tx-usecs 20 tx-frames 1

Verificación

  1. Monitoreo de I/O – Usa iostat -x 5 o pveperf antes y después del ajuste. La latencia de escritura debe bajar de > 10 ms a < 3 ms bajo carga.
  2. Prueba de latencia de VoIP – Ejecuta rtpengine o cualquier SIP benchmark y verifica MOS con pjsua mientras se lanza un backup. El MOS no debe caer más de 0.2 puntos.
  3. Revisar colas activas – ethtool -l eth0 debe mostrar el número configurado. Dentro de la VM, ethtool -l eth0 también debe reflejar las colas asignadas.
  4. Análisis de tráfico – Con tc -s qdisc confirma que el shaping de migración está limitando el ancho de banda al valor configurado.

Notas adicionales

  • ZFS vs LVM – Si ya usas ZFS, habilita logbias=throughput y asigna un SLOG SSD dedicado; esto reduce la latencia de escritura de los paquetes de audio.
  • CPU pinning – Para cargas de VoIP, asignar vCPUs a núcleos físicos libres de interrupciones de backup mejora la consistencia del jitter.
  • Backup strategy – Prefiere snapshots incrementales (vzdump --mode snapshot) en lugar de backups a nivel de archivo cuando la ventana de mantenimiento es estrecha.
  • Documentar cambios – Mantén un registro de los valores de queue_depth y mbps por nodo; los ajustes pueden necesitar revisión tras actualizaciones de kernel o firmware de la NIC.