Un modelo mental útil: por qué las interrupciones causan tartamudeos “aleatorios”

Tu problema de tartamudeos en la VM suele ser un problema de distribución de latencia, no de rendimiento máximo.
Las interrupciones son un factor principal de la latencia de cola porque abren agujeros en el tiempo de CPU.
Cuando el agujero cae en el momento equivocado—durante la ejecución de una vCPU, un ráfaga de recepción de red, o una oleada de completaciones de almacenamiento—no ves “más lento”,
ves picos.

Qué cambia MSI/MSI‑X en comparación con el INTx heredado

Las interrupciones PCI heredadas (INTx) son líneas activadas por nivel compartidas entre dispositivos. “Compartidas” es el término educado.
En la práctica puede convertirse en un chat grupal ruidoso: un dispositivo activa la línea y la CPU tiene que preguntar a varios dispositivos
“¿fuiste tú?” hasta encontrar al correcto. Ese trabajo extra es jitter.

MSI (Message Signaled Interrupts) reemplazó “activar un pin” por “escribir un mensaje en una dirección APIC específica.”
MSI‑X fue más allá con muchos vectores, permitiendo a un dispositivo repartir la carga entre colas (piensa en NICs multiqueue y NVMe).
Usado correctamente, MSI‑X es uno de los héroes silenciosos detrás del I/O de baja latencia moderno.

Dónde entra el remapeo de interrupciones

En virtualización y passthrough, no solo entregas interrupciones al host.
Las entregas deben ir al guest correcto, de forma segura, sin permitir que un dispositivo escriba interrupciones a destinos arbitrarios.
Esa traducción—mapear un mensaje MSI/MSI‑X generado por un dispositivo a un objetivo de interrupción permitido—es el remapeo de interrupciones,
típicamente provisto por el IOMMU (Intel VT-d o AMD‑Vi).

Sin remapeo de interrupciones, el kernel puede negarse a habilitar MSI/MSI‑X en algunos escenarios de passthrough,
o puede volver a INTx heredado o a rutas menos eficientes. Incluso cuando “funciona”, puedes acabar con:

• Tormentas de interrupciones concentradas en una CPU
• Acumulación de softirqs y thrash de ksoftirqd
• Encolamiento dentro de vhost-net, virtio o la capa de bloques
• Preempción impredecible de vCPU (el tartamudeo que percibes)

Verdad seca y graciosa: la CPU es excelente en matemáticas y terrible en ser interrumpida por todo el mundo a la vez—como un cirujano a quien le piden además contestar el teléfono de la oficina.

Cómo se ve un “tartamudeo aleatorio” a nivel de interrupciones

El patrón clásico son picos de latencia breves pero severos correlacionados con:

• Ráfagas de red (completaciones RX/TX)
• Colas de completación NVMe
• Controladores USB (sí, en serio) que disparan el manejo de IRQ en el host
• Rarezas en la entrega de interrupciones de GPU en passthrough
• Interacciones del tick del temporizador y del planificador cuando el host está ligeramente sobreasignado

El host puede mostrar bajo uso de CPU en general, pero un núcleo está siendo golpeado por interrupciones y softirqs mientras otros están ociosos.
Por eso “promedio de CPU” es la gráfica equivocada para mirar.

Una matización práctica más: “interrupciones” incluyen tanto el contexto de IRQ duro como el procesamiento de softirq/NAPI.
Una NIC puede generar interrupciones que desencadenan softirq en la misma CPU, y eso puede robar tiempo a los hilos vCPU de KVM.
Verás tartamudeos incluso con mucho margen disponible.

Cita (idea parafraseada) de Werner Vogels: Construyes, lo ejecutas—la responsabilidad operacional cambia cómo diseñas y depuras sistemas.
Si ejecutas hipervisores, las interrupciones no son “cosas de hardware”. Son tu producto.

Hechos e historia que realmente importan

No necesitas un tour de museo, pero algunos hechos concretos te ayudan a dejar de asumir mal:

1. MSI apareció ampliamente con el hardware de la era PCI 2.2 para reducir líneas de interrupción compartidas y mejorar la escalabilidad.
2. MSI‑X llegó con PCI 3.0 y aumentó significativamente el número de vectores, habilitando interrupciones por cola para dispositivos de alto rendimiento.
3. INTx heredado es activado por nivel y compartible; es propenso al escaneo de “quién activó la línea?” y a interacciones extrañas bajo carga.
4. Las NICs y NVMe modernos asumen MSI‑X; volver a INTx puede destruir silenciosamente el paralelismo y añadir jitter.
5. El remapeo de interrupciones es tanto una característica de seguridad como de rendimiento; evita que los dispositivos apunten CPUs/guests arbitrarios con escrituras MSI.
6. Los IOMMU VT-d/AMD‑Vi suelen venir habilitados para aislamiento DMA, pero el remapeo de interrupciones puede estar desactivado o no disponible según firmware/flags.
7. Los logs DMAR de Intel son tus amigos; el kernel te dirá cuándo el remapeo de interrupciones está apagado, forzado o roto—si te tomas la molestia de mirar.
8. x2APIC e interrupciones publicadas cambiaron el juego para escalar la entrega de interrupciones y reducir el overhead de VM-exit en algunas rutas de virtualización.
9. irqbalance no es una herramienta de rendimiento; es un compromiso; puede ayudar o perjudicar según la cola, el pinning de CPU y la estrategia de aislamiento.

Segundo chiste corto: Si alguien te dice “las interrupciones no pueden causar tartamudeos porque el uso de CPU es solo 20%,” han inventado una nueva unidad de negación.

Guía rápida de diagnóstico (primero/segundo/tercero)

Primero: demuestra que es latencia de IRQ/softirq, no CPU cruda o rendimiento de almacenamiento

• Revisa la distribución de IRQ por CPU y la presión de softirq.
• Correlaciona picos con un dispositivo (NIC, NVMe, USB, HBA, GPU).
• Busca fallback a INTx y ausencia de MSI/MSI‑X.

Segundo: valida que IOMMU + remapeo de interrupciones estén realmente habilitados

• Confirma flags de arranque del kernel: Intel intel_iommu=on, AMD amd_iommu=on.
• Confirma que los logs DMAR/IVRS muestran remapeo de interrupciones habilitado.
• Si haces passthrough con VFIO: asegúrate de que la plataforma lo soporte y que el kernel lo esté usando.

Tercero: arregla la topología de interrupciones (afinidad, aislamiento, colas)

• Reparte vectores MSI‑X entre CPUs intencionadamente, no “lo que pasó al arrancar”.
• Haz que el pinning de CPU y la afinidad de IRQ coincidan (no pongas vCPUs en el mismo núcleo que maneja todas las interrupciones de la NIC).
• Vuelve a comprobar el tartamudeo: tu objetivo es una cola de latencia más ajustada, no necesariamente mayor rendimiento.

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

Estas son las comprobaciones que realmente ejecuto en un host Linux KVM (Proxmox, Ubuntu, Debian, RHEL-ish).
Están ordenadas para que puedas parar pronto si encuentras el arma humeante.
Cada tarea incluye: comando, salida realista, qué significa y la decisión que tomas.

Task 1: Confirmar que IOMMU está habilitado en la línea de comando del kernel

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.8.0 root=/dev/mapper/vg0-root ro quiet intel_iommu=on iommu=pt

Qué significa: intel_iommu=on habilita VT-d IOMMU. iommu=pt usa el modo passthrough para dispositivos del host para reducir overhead manteniendo la traducción disponible.

Decisión: Si no ves intel_iommu=on o amd_iommu=on, agrégalo y reinicia. Si usas VFIO, normalmente quieres tenerlo activado. Si usas solo virtio, a menudo también ayuda para la sanidad del remapeo de interrupciones.

Task 2: Revisar logs DMAR/IVRS para el estado del remapeo de interrupciones

cr0x@server:~$ dmesg -T | egrep -i 'dmar|ivrs|iommu|interrupt remapping' | head -n 30
[Mon Feb  3 10:12:11 2026] DMAR: IOMMU enabled
[Mon Feb  3 10:12:11 2026] DMAR: Interrupt remapping enabled
[Mon Feb  3 10:12:11 2026] DMAR: x2apic enabled
[Mon Feb  3 10:12:12 2026] pci 0000:3b:00.0: DMAR: Skip IOMMU disabling for graphics

Qué significa: Este es el indicador de “no te compliques”: si dice interrupt remapping enabled, la plataforma + firmware + kernel están cooperando.

Decisión: Si ves Interrupt remapping disabled o errores, para y arregla eso antes de sintonizar afinidad de IRQ. No puedes sintonizar fuera de características faltantes.

Task 3: Confirmar que existen los grupos IOMMU (sanidad para usuarios de VFIO)

cr0x@server:~$ find /sys/kernel/iommu_groups/ -maxdepth 2 -type l | head
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/2/devices/0000:00:02.0

Qué significa: La existencia de grupos implica fuertemente que el IOMMU está activo.

Decisión: Si el directorio está vacío/falta, no estás en una configuración real de IOMMU. Arregla la BIOS/UEFI (VT-d/AMD‑Vi) y los flags del kernel.

Task 4: Identificar qué dispositivos PCI usan MSI/MSI‑X vs INTx

cr0x@server:~$ lspci -nnk | egrep -A3 -i 'ethernet|nvme|usb|sata|raid|vga|3d'
3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
	Subsystem: Intel Corporation Device [8086:0000]
	Kernel driver in use: i40e
	Kernel modules: i40e
5e:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]
	Kernel driver in use: nvme
0a:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
	Kernel driver in use: xhci_hcd

Qué significa: Esto muestra quién importa. NIC + NVMe + USB son fuentes comunes de tartamudeos.

Decisión: A continuación, inspecciona cada dispositivo para ver “MSI/MSI‑X enabled” y el conteo de vectores.

Task 5: Para un dispositivo, comprobar si MSI/MSI‑X está habilitado y cuántos vectores

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | egrep -i 'msi|msi-x|interrupt'
	Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
	Interrupt: pin A routed to IRQ 16

Qué significa: MSI‑X está habilitado con 64 vectores. MSI está presente pero deshabilitado (normal cuando se usa MSI‑X). La línea “Interrupt pin … IRQ 16” puede existir incluso cuando MSI‑X está en uso; no te alarmes.

Decisión: Si ves MSI-X: Enable- y esperabas rendimiento multiqueue, encontraste un probable culpable. Investiga por qué está deshabilitado (ajustes del driver, quirks del kernel, problemas VFIO/IR).

Task 6: Detectar uso de INTx heredado mediante patrones en /proc/interrupts

cr0x@server:~$ cat /proc/interrupts | head -n 15
           CPU0       CPU1       CPU2       CPU3
  16:     91233          3          1          2   IO-APIC   16-fasteoi   i40e
  24:    501223          0          0          0   PCI-MSI 524288-edge   nvme0q0
  25:    198772          0          0          0   PCI-MSI 524289-edge   nvme0q1
  26:     77211          0          0          0   PCI-MSI 524290-edge   nvme0q2

Qué significa: Las líneas IO-APIC suelen indicar interrupciones heredadas o basadas en pin; PCI-MSI indica vectores MSI/MSI‑X. También observa la distribución por CPU: todo amontonado en CPU0 es una trampa de latencia.

Decisión: Si los dispositivos calientes están en IO-APIC y mayormente en CPU0, muévete a MSI/MSI‑X y/o ajusta la afinidad. Si son MSI pero siguen concentrados en CPU0, ajusta afinidad y irqbalance.

Task 7: Revisar la presión de softirq (el “efecto colateral” oculto de las interrupciones)

cr0x@server:~$ cat /proc/softirqs
                    CPU0       CPU1       CPU2       CPU3
          HI:          3          0          0          0
       TIMER:   1123456    902233     877112     889001
      NET_TX:      8221      9102      8455      8601
      NET_RX:   9981234     21002     19511     20110
       BLOCK:    302112     88011     90122     89300
    IRQ_POLL:          0          0          0          0
     TASKLET:      1022       1101       1002       1010
       SCHED:    512001     490002     488901     487112
     HRTIMER:        42         39         41         40
         RCU:    980002     910001     905551     907221

Qué significa: CPU0 tiene un NET_RX masivo comparado con las demás. Ese es exactamente el perfil de tartamudeo “un núcleo queda destrozado”.

Decisión: Reparte las colas de la NIC (RSS), ajusta afinidad IRQ o modifica RPS/XPS. Si fijas vCPUs, mantén los CPUs con muchas IRQ lejos de los hilos vCPU sensibles a la latencia.

Task 8: Ver qué IRQs pertenecen a las colas de la NIC y dónde se ejecutan

cr0x@server:~$ grep -iE 'i40e|mlx|ixgbe|bnxt|ena' /proc/interrupts | head
  16:     91233          3          1          2   IO-APIC   16-fasteoi   i40e
  98:    501223          0          0          0   PCI-MSI 327680-edge   i40e-TxRx-0
  99:    498877          0          0          0   PCI-MSI 327681-edge   i40e-TxRx-1
 100:    490112          0          0          0   PCI-MSI 327682-edge   i40e-TxRx-2

Qué significa: Las interrupciones de las colas están atascadas en CPU0. O la afinidad está por defecto mal, o irqbalance las ha fijado allí.

Decisión: Establece explícitamente la afinidad para estos IRQs, o configura irqbalance para evitar tus núcleos de vCPU.

Task 9: Inspeccionar las máscaras de afinidad IRQ actuales

cr0x@server:~$ sudo cat /proc/irq/98/smp_affinity
1

Qué significa: La máscara 1 significa solo CPU0.

Decisión: Cámbiala para repartir entre CPUs (ejemplo: CPUs 0-3 es la máscara f; CPUs 4-7 es f0 en un sistema de 8 núcleos). Márcalo según la topología de CPU y tu plan de pinning.

Task 10: Establecer afinidad IRQ (con cuidado) para un IRQ de cola

cr0x@server:~$ echo f | sudo tee /proc/irq/98/smp_affinity
f

Qué significa: Permitiste que IRQ 98 se ejecute en CPUs 0–3. Es una herramienta burda, pero es una validación rápida.

Decisión: Si los tartamudeos disminuyen inmediatamente, validaste el diagnóstico. Luego, haz una configuración durable (unidad systemd, perfil tuned o política de irqbalance).

Task 11: Comprobar si irqbalance está en ejecución y qué podría estar haciendo

cr0x@server:~$ systemctl status irqbalance --no-pager
● irqbalance.service - irqbalance daemon
     Loaded: loaded (/lib/systemd/system/irqbalance.service; enabled)
     Active: active (running) since Mon 2026-02-03 10:12:38 UTC; 1h 3min ago
   Main PID: 812 (irqbalance)
      Tasks: 1
     Memory: 2.4M
        CPU: 1.231s

Qué significa: irqbalance está activo. Puede mejorar la distribución, o puede pelear con tu aislamiento de CPU y deshacer tu pinning cuidado.

Decisión: Si usas pinning/aislamiento de CPU para VMs, considera configurar bans en irqbalance, o deshabilitarlo y gestionar afinidad explícitamente.

Task 12: Comprobar si el kernel está forzando PCI MSI off globalmente

cr0x@server:~$ cat /proc/cmdline | grep -o 'pci=.*' || true

Qué significa: No aparece pci=nomsi. Bien.

Decisión: Si encuentras pci=nomsi en la cmdline (sí, gente copia-pega esto de posts antiguos), elimínalo. Es una fábrica de tartamudeos en dispositivos modernos.

Task 13: Comprobar si el kernel ha deshabilitado el remapeo de interrupciones por quirks

cr0x@server:~$ dmesg -T | egrep -i 'remapping.*(off|disable)|no IR|intremap' | head

Qué significa: Nada alarmante encontrado en esta muestra. En sistemas rotos podrías ver mensajes que indican que IR está deshabilitado debido a bugs de BIOS o limitaciones de la plataforma.

Decisión: Si ves deshabilitaciones forzadas, actualiza BIOS/UEFI y microcode primero. Si sigue fallando, puede que necesites hardware distinto para comportamiento estable con VFIO/MSI.

Task 14: Ver ubicación de los hilos KVM y si las vCPUs comparten núcleos con tormentas de IRQ

cr0x@server:~$ ps -eLo pid,psr,comm | egrep 'kvm|qemu-system' | head
  2311   0 qemu-system-x86
  2315   0 CPU 0/KVM
  2316   1 CPU 1/KVM
  2317   2 CPU 2/KVM
  2318   3 CPU 3/KVM

Qué significa: Los hilos vCPU están en CPUs 0–3. Si tus interrupciones también están concentradas ahí, estás programando peleas.

Decisión: O mueve IRQs lejos de los núcleos vCPU, o mueve vCPUs fuera de núcleos con mucha IRQ. No “compartan amablemente” y esperes lo mejor.

Task 15: Vista rápida del uso de softirq por CPU en tiempo real

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (server)  02/03/2026  _x86_64_  (8 CPU)

11:21:01 AM  CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
11:21:02 AM  all  7.11  0.00  6.33    0.12  0.10  3.52   0.00 82.82
11:21:02 AM    0  4.00  0.00  9.00    0.00  0.60 18.40   0.00 68.00
11:21:02 AM    1  8.00  0.00  6.00    0.00  0.00  1.00   0.00 85.00
11:21:02 AM    2  9.00  0.00  5.00    0.00  0.00  0.90   0.00 85.10
11:21:02 AM    3  8.00  0.00  5.00    0.00  0.00  0.80   0.00 85.20

Qué significa: CPU0 tiene alto %soft que a menudo se correlaciona con backlog de NET_RX. Ese es un generador clásico de jitter en VMs.

Decisión: Si una CPU muestra softirq elevado, dirige tus esfuerzos a las colas de dispositivo mapeadas a ella y redistribuye.

La solución de 5 minutos: qué cambiar y por qué

“5 minutos” asume que tienes acceso a la consola y puedes reiniciar una vez. Si no puedes reiniciar, aún puedes validar y mitigar parcialmente con afinidad.
La idea central es simple: asegúrate de que MSI/MSI‑X esté habilitado, y de que el remapeo de interrupciones esté activado para que la entrega MSI sea segura y rápida en rutas virtualizadas.

Paso 1: Habilitar IOMMU y remapeo de interrupciones en el firmware

En la BIOS/UEFI, habilita:

• Intel: VT-d (a veces “Intel Virtualization Technology for Directed I/O”)
• AMD: AMD‑Vi / IOMMU

También busca opciones como “Interrupt Remapping” o “DMA Remapping” si el firmware las expone.
Las UIs del firmware varían de pulidas a malditas. Buscas cualquier cosa que suene a IOMMU/VT-d/AMD‑Vi.

Paso 2: Habilitar IOMMU en los parámetros de arranque del kernel

Añade uno de estos en tu gestor de arranque:

• intel_iommu=on iommu=pt
• amd_iommu=on iommu=pt

iommu=pt suele ser un buen valor por defecto para hosts que no están poniendo “todo detrás de traducción todo el tiempo.”
Puede reducir overhead mientras mantiene la maquinaria del IOMMU disponible para remapeo y asignación de dispositivos.

Paso 3: Reiniciar, verificar que DMAR/IVRS diga “Interrupt remapping enabled”

Si no está habilitado, detente. No hagas afinamientos elaborados de IRQ encima de una configuración de plataforma rota.
Arregla BIOS/UEFI, actualiza firmware/microcode, o cambia hardware si es necesario.

Paso 4: Verificar que los dispositivos realmente usen MSI/MSI‑X y tengan los vectores de cola esperados

Para NICs esperas múltiples colas Tx/Rx. Para NVMe esperas múltiples colas de completación.
Si ves un vector único, o MSI‑X presente pero deshabilitado, los tartamudeos bajo ráfaga son previsibles.

Paso 5: Repartir las interrupciones lejos de tus núcleos vCPU

El truco de rendimiento no es “repartir todo por todas partes.” Es la separación de responsabilidades:

• Elige núcleos de CPU para trabajo de IRQ/softirq del host (red, almacenamiento)
• Elige núcleos de CPU para vCPUs de VM (guests sensibles a latencia)
• Haz que las políticas de afinidad coincidan con esas decisiones

Si no haces nada más, al menos deja de defaultar todas las interrupciones de cola en CPU0. CPU0 ya tiene tareas de housekeeping en muchos sistemas.
Déjalo respirar.

Tres mini-historias corporativas desde las trincheras de las interrupciones

Incidente: la suposición equivocada (“el almacenamiento debe ser el problema”)

Una empresa mediana operaba un clúster de virtualización que alojaba CI interno, un par de bases de datos y una granja VDI.
Los usuarios se quejaban de que “las VMs se congelan por un segundo” varias veces por hora. Predeciblemente, el equipo de almacenamiento fue el primero en recibir la alarma,
porque el almacenamiento siempre recibe la alarma primero.

La suposición inicial era familiar: tartamudeos = latencia de almacenamiento. El equipo miró gráficas del SAN, estadísticas de multipath,
y retransmisiones iSCSI. Nada. Latencia plana. Rendimiento con margen. El proveedor de SAN estaba educadamente aburrido.

Un SRE hizo una comprobación simple: /proc/softirqs y /proc/interrupts. CPU0 tenía conteos NET_RX descomunales.
La NIC 10GbE era “capaz de multiqueue”, pero sus vectores IRQ estaban efectivamente pegados a un solo núcleo.
También descubrieron que el remapeo de interrupciones estaba deshabilitado en firmware después de que una actualización de plataforma reseteó un perfil de BIOS.

Con el remapeo de interrupciones apagado, el host había tomado una ruta menos óptima de entrega de interrupciones para un subconjunto de dispositivos.
Bajo tráfico VDI con ráfagas, el manejo de IRQ/softirq del host brevemente empequeñecía los hilos vCPU de KVM.
Los usuarios percibieron que “la VM se congeló”.

La solución fue aburrida: reactivar VT-d/IOMMU + remapeo de interrupciones, confirmar MSI‑X habilitado, luego distribuir las interrupciones de cola lejos de los núcleos vCPU.
El SAN nunca cambió. Los tickets se detuvieron. El equipo de almacenamiento no recibió una disculpa, pero sí llamadas en espera más tranquilas.

Optimización que salió mal: “deshabilitar IOMMU por rendimiento”

Otra organización operaba un clúster de cómputo denso: muchas VMs, red intensa, NVMe local moderado.
Alguien leyó que IOMMU añade overhead y propuso un cambio para deshabilitarlo en toda la flota. Se presentó como “rendimiento gratis.”
El cambio se aplicó durante una ventana rutinaria de actualización del kernel.

Las pruebas de rendimiento parecían bien. Esa es la trampa: los promedios casi no se movieron.
Pero una semana después, el soporte comenzó a ver “micro-congelamientos” en sesiones remotas, además de extraños picos de pérdida de paquetes dentro de guests.
No era consistente. Era peor en nodos con ciertas revisiones de firmware de NIC. Naturalmente, esto se convirtió en un debate inter-equipos.

El postmortem encontró dos problemas. Primero: sin IOMMU, el remapeo de interrupciones no estaba disponible, y algunos casos de passthrough volvían por rutas feas.
Segundo: su estrategia de pinning de CPU asumía que las IRQs se balancearían fuera de los núcleos vCPU aislados. irqbalance hizo lo contrario en algunos nodos,
y sin las características de interrupciones esperadas, la distribución fue aún peor.

El rollback fue directo: reactivar IOMMU con iommu=pt para evitar traducción innecesaria para dispositivos del host,
verificar remapeo de interrupciones en dmesg, y luego revalidar la afinidad de IRQ. La “optimización de rendimiento gratis” había entregado jitter gratis en su lugar.

La lección perdurable: un cambio que mejora el rendimiento medio puede arruinar la latencia de cola.
Para sistemas orientados al usuario (VDI, voz, juegos, trading, latencia de commit de bases de datos), la latencia de cola es el producto.

Práctica aburrida pero correcta que salvó el día: “perfiles de hardware y aserciones en el arranque”

Un equipo de servicios financieros operaba un entorno KVM pequeño pero crítico. Su trabajo no era glamuroso: servicios internos,
trabajos por lotes, unos pocos componentes sensibles a latencia y restricciones de cumplimiento que hacían los cambios dolorosos.
Aprendieron temprano que “mismo modelo de servidor” no significa “mismas opciones de firmware.”

Estandarizaron una base para hosts:
VT-d/IOMMU habilitado, remapeo de interrupciones habilitado, perfiles de BIOS consistentes exportados y versionados,
y una comprobación en el arranque que alertara si dmesg no contenía la línea esperada “Interrupt remapping enabled”.
Además fijaron IRQs de housekeeping y colas NIC en cores designados, dejando un conjunto limpio para vCPUs.

Un trimestre tuvieron que cambiar una placa base fallida bajo presión de tiempo. La sustituta volvió con un perfil de BIOS por defecto:
características de virtualización parcialmente deshabilitadas. El host arrancó “bien”. Las VMs arrancaron “bien”. Y luego las gráficas de latencia empezaron a susurrar.

Su aserción en el arranque lo detectó en minutos. Arreglaron ajustes de firmware antes de que los usuarios lo notaran.
Sin llamada de incidente, sin war room, sin culpas. Solo un ticket con una lista y un bucle cerrado.

Esta es la realidad poco sexy de la fiabilidad: las prácticas aburridas no previenen todo problema,
pero previenen los costosos—los que solo detectas cuando tu CEO está en la sesión VDI congelada.

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

1) Síntoma: “Congelamientos aleatorios de 200–800 ms, CPU baja”

Causa raíz: Punto caliente de IRQ/softirq en una CPU (a menudo CPU0), que deja sin tiempo a los hilos vCPU intermitentemente.

Solución: Verifica MSI‑X habilitado; redistribuye afinidad de IRQ; separa núcleos de IRQ de núcleos vCPU; considera ajustar RPS/XPS.

2) Síntoma: “Passthrough VFIO funciona pero la latencia es horrible bajo carga”

Causa raíz: Remapeo de interrupciones deshabilitado/no disponible; las interrupciones del dispositivo se entregan por rutas de fallback o uso restringido de MSI.

Solución: Habilita VT-d/AMD‑Vi + remapeo de interrupciones en firmware y kernel. Actualiza BIOS/microcode. Re-prueba con confirmación en dmesg.

3) Síntoma: “La NIC es 10/25/40GbE pero se comporta como 1GbE en ráfagas”

Causa raíz: MSI‑X no habilitado, o solo una cola/vector activo; multiqueue no funcionando.

Solución: Confirma MSI-X: Enable+ y el conteo de vectores; revisa ajustes del driver (ethtool -l), firmware y parámetros del kernel que deshabiliten MSI.

4) Síntoma: “Los tartamudeos comenzaron tras una actualización de BIOS”

Causa raíz: El perfil de BIOS se reseteó y deshabilitó VT-d/IOMMU o remapeo de interrupciones; a veces x2APIC se cambió.

Solución: Re-aplica el perfil de BIOS conocido bueno; verifica logs DMAR/IVRS; añade aserciones en el arranque.

5) Síntoma: “Todo mejoró excepto una VM sigue tartamudeando”

Causa raíz: Las vCPUs de esa VM están fijadas al mismo CPU que maneja interrupciones NVMe o NIC; o un dispositivo en passthrough usa una ruta IRQ distinta.

Solución: Alinea el pinning de vCPU con la afinidad de IRQ; aísla núcleos de IRQ del host; confirma el MSI‑X y el estado de IR del dispositivo pasado.

6) Síntoma: “Deshabilitar irqbalance lo empeoró”

Causa raíz: Deshabilitaste el balanceo pero no lo reemplazaste con un plan deliberado de afinidad; las interrupciones volvieron a los valores por defecto.

Solución: O configura irqbalance con CPUs vedadas para proteger vCPUs, o gestiona afinidad con reglas persistentes (unidad systemd) por grupo de IRQ.

7) Síntoma: “Una actualización del kernel cambió el comportamiento”

Causa raíz: El driver cambió los valores por defecto de colas; los quirks de MSI/MSI‑X cambiaron; el manejo de topología/NUMA cambió; la política de irqbalance cambió.

Solución: Vuelve a ejecutar las comprobaciones de la sección de tareas. No asumas que la distribución de interrupciones de ayer persiste después de actualizaciones.

Listas de verificación / plan paso a paso

Checklist A: Triage de “tartamudeo” en un host (15 minutos)

1. Ejecuta dmesg filtrado por DMAR/IVRS y confirma “Interrupt remapping enabled.”
2. Revisa /proc/interrupts y /proc/softirqs buscando puntos calientes en CPU.
3. Para dispositivos sospechosos (NIC/NVMe/USB/HBA), confirma que MSI/MSI‑X esté habilitado vía lspci -vv.
4. Comprueba si los hilos vCPU de la VM están en las mismas CPUs que el punto caliente de IRQ.
5. Temporalmente, reparte la afinidad IRQ para los IRQs calientes y observa la reducción de tartamudeos.

Checklist B: Solución durable para un nodo de virtualización (control de cambios)

1. Estandariza el perfil de BIOS: habilita VT-d/AMD‑Vi y remapeo de interrupciones.
2. Establece flags del kernel: intel_iommu=on iommu=pt (o equivalente AMD).
3. Reinicia; registra logs DMAR/IVRS en el inventario del nodo.
4. Confirma conteos de vectores MSI‑X en NICs y NVMe; asegura que multiqueue esté activo.
5. Define la asignación de CPU: qué cores son para IRQ/softirq del host y cuáles para vCPUs.
6. Implementa política persistente de afinidad IRQ (bans en irqbalance o máscaras explícitas).
7. Re-prueba bajo tráfico representativo; mide latencia p99, no solo rendimiento medio.

Checklist C: Prevención a nivel de clúster

1. Añade una comprobación en el arranque que alerte cuando el remapeo de interrupciones no esté habilitado.
2. Rastrea versiones de firmware y deriva de ajustes de BIOS; no confíes en “mismo modelo”.
3. Tras actualizaciones de kernel/driver, revalida la habilitación de MSI‑X y los conteos de colas en un nodo canario.
4. Documenta una ruta de rollback que incluya cmdline del kernel y perfiles de BIOS.

Preguntas frecuentes

1) ¿Es obligatorio el remapeo de interrupciones para buen rendimiento?

No universalmente, pero para VFIO/passthrough y algunas rutas modernas de entrega de interrupciones, a menudo marca la diferencia entre uso limpio de MSI/MSI‑X y comportamiento de fallback.
También es un límite de seguridad. Si te importa la latencia de cola y la corrección, actívalo.

2) Activé IOMMU. ¿Por qué sigo viendo tartamudeos?

Tener IOMMU activado no garantiza que tus interrupciones estén bien distribuidas. Puedes tener remapeo perfecto y aun así canalizar todas las interrupciones de cola hacia CPU0.
Revisa /proc/interrupts, /proc/softirqs y las máscaras de afinidad IRQ.

3) ¿Cuál es la diferencia práctica entre MSI y MSI‑X?

MSI suele ofrecer un pequeño número de vectores; MSI‑X soporta muchos vectores. Muchos vectores permiten interrupciones por cola, lo que deja que NIC/NVMe escalen con cores y reduzcan la contención.
Para I/O de alta velocidad moderno, MSI‑X es el estado objetivo normal.

4) ¿Hace inseguro usar iommu=pt?

Reduce el overhead de traducción para dispositivos que no están aislados, pero no “apaga” la existencia del IOMMU. Para dispositivos VFIO aún obtienes aislamiento.
La postura de seguridad depende de tu configuración completa; no lo uses como sustituto de comprender tu modelo de amenaza.

5) ¿Debería deshabilitar irqbalance?

Si ejecutas aislamiento/pinning de CPU para VMs, al menos deberías controlar irqbalance. Un irqbalance sin control puede sabotear el aislamiento.
O configúralo para evitar tus núcleos vCPU o desactívalo y establece afinidad IRQ explícita y persistente.

6) ¿Por qué CPU0 siempre parece culpable?

CPU0 a menudo maneja tareas de housekeeping y recibe afinidad por defecto para muchas interrupciones. No es malvada; es conveniente.
La conveniencia es un mal plan de rendimiento.

7) ¿Puede un controlador USB realmente causar tartamudeos en VMs?

Sí. Un controlador USB ruidoso (o un dispositivo conectado a él) puede generar interrupciones que roben tiempo de CPU, especialmente si esas interrupciones se concentran en un núcleo que ejecuta vCPUs.
Es menos común que NIC/NVMe, pero real y merece comprobarse.

8) ¿Cómo sé si estoy cayendo a INTx?

Mira /proc/interrupts para líneas IO-APIC ligadas a tu dispositivo, y confirma la habilitación de MSI/MSI‑X en lspci -vv.
Si MSI‑X muestra Enable- o ves solo una línea de interrupción donde esperabas muchas colas, sospecha fallback.

9) Mi VM usa solo virtio. ¿Me sigue importando?

Sí, porque el host sigue manejando interrupciones de los dispositivos físicos (NICs, NVMe, HBAs) que respaldan virtio.
Incluso sin passthrough, una mala distribución de interrupciones puede dejar sin tiempo a hilos vhost y ejecución de vCPU.

10) ¿Cuál es la confirmación más rápida de que tus cambios funcionaron?

Quieres ver: DMAR dice interrupt remapping enabled, los dispositivos muestran MSI‑X habilitado con el conteo de vectores esperado, y la carga IRQ/softirq se distribuye entre las CPUs previstas.
Luego valida con una medida de latencia de cola: p99/p999 en el guest, no solo el rendimiento medio en el host.

Conclusión: próximos pasos que puedes implementar hoy

Los tartamudeos aleatorios en VMs suelen ser problemas de topología de interrupciones disfrazados. MSI/MSI‑X y el remapeo de interrupciones no son características de nicho;
son la plomería que permite que los dispositivos modernos escalen sin convertir una CPU en la sala del pánico.

Pasos prácticos:

1. En un host que tartamudea, confirma que DMAR/IVRS muestre “Interrupt remapping enabled.” Si no, arregla firmware + flags del kernel.
2. Confirma que tus dispositivos calientes (NIC/NVMe) tengan MSI‑X habilitado y múltiples vectores.
3. Revisa /proc/interrupts y /proc/softirqs buscando puntos calientes en CPU; no aceptes “CPU está baja” como evidencia.
4. Alinea la afinidad IRQ con el pinning de vCPU: dedica cores para interrupciones del host, mantén limpios los cores de VM.
5. Hazlo durable: versiona perfiles de BIOS, añade aserciones en el arranque y vuelve a comprobar tras actualizaciones.

Haz esto una vez, correctamente, y dejarás de tratar el “tartamudeo” como una historia de fantasmas. Es solo enrutamiento.