Fallos de passthrough PCI en Proxmox: Grupos IOMMU y las trampas clásicas

Guía rápida de diagnóstico

Si estás de guardia y una VM no arranca después de habilitar el passthrough, no necesitas filosofía. Necesitas encontrar el cuello de botella rápido.
Aquí está la guía corta que uso en producción, en el orden que revela más con el menor esfuerzo.

1) Confirma que IOMMU está realmente habilitado (BIOS + kernel)

La mayoría de los tickets “VFIO está roto” son “IOMMU nunca se activó”. O está en la BIOS pero no en el kernel, o al revés.
Revisa los logs del kernel y la línea de comandos activa primero; no adivines.

2) Comprueba el grupo IOMMU del dispositivo objetivo

Si la GPU comparte grupo con un controlador SATA, eso no es una situación de “ajústalo después”. Ese es el problema.
Decide pronto si puedes vivir pasando el grupo entero, si el ACS override es aceptable, o si necesitas hardware distinto.

3) Comprueba quién posee el dispositivo ahora mismo

Si el host usa la GPU para salida de consola, o la NIC está reclamada por un módulo del kernel, la VM no podrá tomarla.
Vincula a vfio-pci y pon en blacklist al controlador competidor. Verifica con lspci -k.

4) Valida las opciones de configuración de la VM que te sabotean silenciosamente

Tipo de máquina, tamaño del ROM BAR, selección de GPU primaria, UEFI vs SeaBIOS y los quirks de reset causan el 80% de los casos de “pantalla negra”.
Aquí es donde dejas de “probar cosas aleatorias del foro” y comienzas a tomar decisiones intencionales.

5) Solo entonces: persigue rarezas específicas del proveedor

NVIDIA Code 43, bugs de reset en AMD, alternativas Intel iGPU GVT y dispositivos multifunction reales existen—pero no vayas allí hasta que
lo fundamental esté limpio.

Una idea parafraseada de Leslie Lamport aplica aquí: Idea parafraseada: Un sistema distribuido falla por un componente que ni siquiera sabías que existía. — Leslie Lamport

Grupos IOMMU: qué son y por qué importan

Un IOMMU es la frontera hardware que permite al host controlar cómo los dispositivos PCIe acceden a la memoria. Sin él, el passthrough es básicamente
“por favor no hagas DMA en mi hipervisor”, que no es un modelo de seguridad—más bien una esperanza y oración.
Con IOMMU, puedes entregar un dispositivo a una VM y aun así hacer cumplir el aislamiento de memoria.

Los grupos IOMMU son la consecuencia práctica de la topología PCIe. Los dispositivos detrás del mismo puente ascendente sin aislamiento adecuado
(ACS: Access Control Services) no pueden separarse limpiamente. Linux los agrupa, lo que significa: si pasas un dispositivo, debes tratar
al grupo entero como potencialmente capaz de husmear o interferir con los demás.

Los operadores a menudo malentienden esto de forma muy específica: piensan que los grupos son una sugerencia. No lo son.
Son el kernel describiendo qué hardware puede aislarse de forma segura. A veces puedes hacer trampa con ACS override; a veces no deberías.

Los tres grandes tipos de fallo en passthrough

• Fallo de aislamiento: el dispositivo está en un grupo con cosas que no puedes sacrificar (p. ej., controlador de almacenamiento, USB del host, NIC primaria).
• Fallo de propiedad: el controlador del kernel del host posee el dispositivo (o servicios de Proxmox lo hacen), por lo que VFIO no puede enlazarlo.
• Fallo en tiempo de ejecución: la VM arranca pero el dispositivo no se inicializa (problemas de reset, quirks del ROM, incompatibilidades de firmware, tamaño de BAR, detección del driver de GPU).

Trata esos buckets como un árbol de decisiones ramificado. No “sigas ajustando” sin saber en qué categoría estás.

Broma #1: Los grupos IOMMU son como organigramas: todo parece separable hasta que intentas mover a una persona y descubres que tres equipos colapsan.

Hechos e historia que explican el dolor actual

Puedes hacer passthrough sin conocer la historia, pero conocerla te ayuda a predecir qué plataformas se comportarán bien y cuáles te harán perder tiempo.
Aquí puntos concretos que importan operativamente.

1. VT-d (Intel) y AMD-Vi (AMD) llegaron como la versión “DMA” de la virtualización, no la versión de cómputo. La virtualización de CPU (VT-x/AMD-V) no basta para passthrough PCI.
2. Los chipsets de consumo tempranos a menudo implementaron IOMMU pobremente o con aislamiento limitado; las plataformas servidoras tendieron a hacerlo correctamente primero.
3. PCIe ACS se convirtió en la pieza clave para la separación de grupos; muchas placas de consumo omiten características ACS en puertos descendentes, creando grupos gigantes.
4. VFIO reemplazó métodos antiguos de asignación de dispositivos (históricamente KVM usó una mezcla de mecanismos). VFIO estandarizó el acceso seguro a dispositivos y es la base moderna.
5. El passthrough de GPU creció en la sombra de políticas de proveedores; los drivers a veces se comportaban diferente en VMs y la comunidad construyó soluciones alternativas.
6. La adopción de UEFI cambió cómo se cargan los option ROM y cómo se inicializan las GPUs. Muchos incidentes de “pantalla negra” son realmente desajustes del firmware/pipeline de arranque.
7. Resizable BAR es excelente para rendimiento en metal desnudo, pero puede complicar el passthrough y el mapeo de BAR en VMs según la plataforma y el firmware.
8. Los kernels modernos endurecen la seguridad; lo que “funcionaba” con defaults permisivos años atrás puede requerir flags explícitos ahora (y eso es bueno).
9. Los parches de ACS override se hicieron populares precisamente porque el ecosistema hardware no priorizó aislamiento limpio para entusiastas—útil, pero un compromiso.

Tareas prácticas (comandos, salidas, decisiones)

El objetivo aquí no es volcar comandos. Es hacer que cada comando se gane su lugar: ejecútalo, interpreta la salida y luego toma una decisión.
Los ejemplos de host asumen un nodo Proxmox basado en Debian.

Task 1: Confirmar virtualización de CPU y capacidad IOMMU

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name|Vendor ID'
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) CPU E-2246G @ 3.60GHz
Virtualization:        VT-x

Qué significa: VT-x/AMD-V está presente, pero esto no confirma que VT-d/AMD-Vi esté habilitado.
Decisión: procede a las comprobaciones de kernel/IOMMU; no asumas que VT-d existe solo porque VT-x sí.

Task 2: Comprobar parámetros de arranque del kernel para IOMMU

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=ZFS=rpool/ROOT/pve-1 ro quiet intel_iommu=on iommu=pt

Qué significa: intel_iommu=on habilita IOMMU de Intel; iommu=pt usa el mapeo pass-through para dispositivos del host (a menudo reduce overhead).
Decisión: si estos flags no están presentes, agréguelos y reinicie antes de hacer cualquier otra cosa.

Task 3: Verificar que IOMMU realmente se inicializó

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 15
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.112345] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.112678] DMAR: Initialized

Qué significa: el kernel ve y ha habilitado el IOMMU.
Decisión: si no ves “IOMMU enabled/Initialized”, ve a la BIOS (VT-d/AMD-Vi) y arregla la plataforma primero.

Task 4: Listar dispositivos PCI con IDs (los necesitarás)

cr0x@server:~$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87]
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8]
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Qué significa: tienes IDs de dispositivo como 10de:1e87 (GPU) y 10de:10f8 (su función de audio).
Decisión: planifica pasar todo el conjunto multifunción (GPU + audio) a menos que tengas una buena razón para no hacerlo.

Task 5: Imprimir grupos IOMMU (la prueba “¿puedo aislarlo?”)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; lspci -nns "$(basename -a $g/devices/*)"; echo; done
Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f]

Group 7
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87]
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8]

Group 8
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Qué significa: la GPU está en un grupo pequeño con su función de audio—bien.
Decisión: si tu dispositivo objetivo comparte grupo con dispositivos críticos del host (controlador SATA, controlador USB que necesitas para el teclado, la única NIC),
debes pasar el grupo entero, cambiar de ranura/ajustes de BIOS, usar ACS override con ojos abiertos, o cambiar de hardware.

Task 6: Identificar qué controlador posee actualmente el dispositivo

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2080]
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3751
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Qué significa: el driver NVIDIA del host está cargado; VFIO no puede tomar la tarjeta sin des-enlazar/re-enlazar.
Decisión: elimina el uso del host de la GPU (sin consola, sin Xorg), pon en blacklist el driver si es necesario, y enlaza a vfio-pci.

Task 7: Asegurarse de que los módulos VFIO estén disponibles y cargados

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          94208  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   40960  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             372736  0
kvm                  1036288  1 kvm_intel

Qué significa: VFIO está presente.
Decisión: si faltan módulos VFIO, instala los paquetes de kernel adecuados y asegúrate de que el kernel de Proxmox coincida con las expectativas.

Task 8: Vincular un dispositivo a vfio-pci usando IDs de dispositivo

cr0x@server:~$ sudo sh -c 'echo "options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1" > /etc/modprobe.d/vfio.conf'
cr0x@server:~$ cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1

Qué significa: en el siguiente arranque, VFIO reclamará las funciones de la GPU temprano.
Decisión: haz esto cuando quieras que el passthrough sea estable entre reinicios. Los trucos de des-enlazar temporales están bien para experimentar, no para producción.

Task 9: Poner en blacklist controladores GPU conflictivos (nouveau suele colarse)

cr0x@server:~$ sudo tee /etc/modprobe.d/blacklist-gpu.conf >/dev/null <<'EOF'
blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist nvidia_drm
blacklist nvidia_modeset
EOF
cr0x@server:~$ cat /etc/modprobe.d/blacklist-gpu.conf
blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist nvidia_drm
blacklist nvidia_modeset

Qué significa: evitas que el host cargue “amistosamente” un driver que robe tu dispositivo de passthrough.
Decisión: pon en blacklist solo lo necesario. Si el host necesita una GPU para la consola, usa iGPU o una tarjeta secundaria barata y pasa la otra.

Task 10: Actualizar initramfs para que el enlace temprano/blacklists se apliquen

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve

Qué significa: tu entorno de arranque temprano ahora contiene las nuevas configuraciones de módulo.
Decisión: si omites esto, pasarás una larga tarde mirando un driver equivocado cargado “misteriosamente” antes de montar rootfs.

Task 11: Después del reinicio, confirma que vfio posee el dispositivo

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2080]
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3751
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Qué significa: propiedad correcta. Ten en cuenta que “Kernel modules” puede listar candidatos; lo que importa es “driver in use”.
Decisión: si todavía no es vfio-pci, revisa blacklists, initramfs y si el dispositivo se usa como VGA de arranque.

Task 12: Confirmar que Proxmox/QEMU ve los nodos de dispositivo IOMMU

cr0x@server:~$ ls -l /dev/vfio/
total 0
crw------- 1 root root 240,   0 Dec 26 09:12 0
crw------- 1 root root 240,   7 Dec 26 09:12 7
crw------- 1 root root 240, 255 Dec 26 09:12 vfio

Qué significa: existen nodos de grupo (aquí el grupo 7 está presente).
Decisión: si el nodo de grupo no está presente, tu agrupamiento IOMMU no está activo o el kernel no expone VFIO correctamente.

Task 13: Comprueba si el dispositivo soporta reset limpio (trampa común en GPUs)

cr0x@server:~$ sudo dmesg | egrep -i 'vfio|reset|FLR|D3' | tail -n 20
[  112.334455] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[  112.334890] vfio-pci 0000:01:00.0: not capable of FLR, device reset may be unreliable

Qué significa: no hay Function Level Reset (FLR). Esto suele aparecer como “funciona una vez, luego falla al reiniciar la VM” porque el dispositivo nunca se reinicia.
Decisión: planifica en torno a ello: ciclo de energía del host entre ejecuciones de VM, usar módulos de reset de proveedor si procede, o elegir hardware con resets fiables.

Task 14: Validar la configuración de la VM para PCIe y OVMF (qm config de Proxmox)

cr0x@server:~$ qm config 110
agent: 1
bios: ovmf
boot: order=scsi0;ide2;net0
machine: q35
memory: 16384
name: win11-gpu
ostype: win11
scsi0: local-lvm:vm-110-disk-0,size=200G
hostpci0: 01:00.0,pcie=1,x-vga=1
hostpci1: 01:00.1,pcie=1
efidisk0: local-lvm:vm-110-disk-1,size=1M,efitype=4m,pre-enrolled-keys=1

Qué significa: esta es la base sensata para muchas GPUs: q35 + OVMF + pcie=1 y x-vga=1 para GPU primaria.
Decisión: si usas i440fx para una GPU moderna y tienes rarezas, cambia a q35 salvo que tengas una razón específica para no hacerlo.

Task 15: Si la VM no arranca, lee el mensaje real de error en los logs de QEMU

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:server:00004A2C:0001D2B1:676D5B2A:qmstart:110:root@pam:
cr0x@server:~$ journalctl -u pvedaemon -n 80 --no-pager
Dec 26 09:20:11 server pvedaemon[1324]: start VM 110: UPID:server:00004A2C:0001D2B1:676D5B2A:qmstart:110:root@pam:
Dec 26 09:20:11 server pvedaemon[1324]: VM 110 qmp command failed - unable to open /dev/vfio/7: Device or resource busy

Qué significa: “busy” suele ser propiedad o un proceso colgado.
Decisión: encuentra quién sostiene el grupo VFIO y mátalo limpiamente (o para la VM que ya lo está usando).

Task 16: Encontrar qué proceso está reteniendo el dispositivo/grupo

cr0x@server:~$ sudo lsof /dev/vfio/7
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
qemu-syst 991 root   25u   CHR  240,7      0t0  165 /dev/vfio/7

Qué significa: un proceso QEMU ya tiene el grupo.
Decisión: detén la VM propietaria. Si es un QEMU colgado, termínalo e investiga por qué no liberó VFIO.

Task 17: Inspeccionar la topología PCIe para entender problemas de agrupamiento

cr0x@server:~$ lspci -t
-[0000:00]-+-00.0
           +-01.0-[01]----00.0
           |            \-00.1
           \-02.0-[02]----00.0

Qué significa: la GPU está detrás del bus 01; el NVMe detrás del bus 02. Una separación limpia suele significar grupos limpios.
Decisión: si todo está bajo un único puerto descendente, espera grupos desordenados. Considera mover tarjetas a ranuras distintas (conexas a root ports distintos).

Task 18: Si debes, prueba ACS override y observa qué grupos emergen (con consciencia del riesgo)

cr0x@server:~$ sudo sed -i 's/quiet/quiet pcie_acs_override=downstream,multifunction/' /etc/default/grub
cr0x@server:~$ grep -n '^GRUB_CMDLINE_LINUX_DEFAULT' /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_acs_override=downstream,multifunction intel_iommu=on iommu=pt"
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
done

Qué significa: le estás pidiendo al kernel que finja que existe aislamiento ACS donde puede no existir.
Decisión: usa esto solo si aceptas el compromiso de seguridad/aislamiento. En entornos multi-tenant o de cumplimiento, evítalo.

Broma #2: El ACS override es como quitar la cinta de “no pasar” porque te ralentiza—hasta que recuerdas por qué estaba la cinta.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

Un equipo desplegó nodos Proxmox para alojar VMs Windows aceleradas por GPU para una unidad de negocio que necesitaba una app legacy con renderizado GPU.
Probaron en una “estación dorada” y funcionó. Compraron otra revisión de placa base porque era “equivalente”.
“Equivalente” es una palabra peligrosa en infraestructuras.

En las nuevas placas, el grupo IOMMU de la GPU también contenía un controlador USB y el audio integrado. El equipo asumió:
“Solo pasamos la GPU, así que el controlador USB no debería importar.” Habilitaron ACS override para dividir grupos,
se felicitaron y pasaron a producción.

Semanas después, VMs aleatorias comenzaron a congelarse durante picos de uso. No se caían; se congelaban. El host seguía arriba, pero los procesos QEMU entraban en estados
que requerían kill forzado. La tasa de congelamientos subió con mayor actividad USB: lectores de tarjetas inteligentes, cámaras USB, periféricos extraños.
Probablemente ya imaginas el final.

Los “grupos” IOMMU divididos no eran aislamiento real; eran límites impuestos por software. Bajo carga, dispositivos que compartían el mismo camino físico
aún interactuaban de formas que VFIO no podía vigilar completamente. El resultado no fue una brecha de seguridad limpia; fue una pesadilla operativa:
resets poco fiables, interrupciones inestables y bloqueos de VM que parecían problemas de driver.

La solución no fue glamorosa: cambiaron a placas con aislamiento ACS adecuado en los root ports PCIe y dejaron de anular la realidad.
La línea clave del postmortem: la suposición de que los grupos IOMMU son “solo agrupamiento de Linux” en lugar de “límites de contención de hardware”.
Esa frase probablemente les ahorró un año de incidentes recurrentes.

Microhistoria 2: La optimización que salió mal

Otra organización quiso exprimir rendimiento. Leyeron que iommu=pt reduce overhead para dispositivos del host, así que lo añadieron por todas partes.
Luego fueron más lejos: tocaron parámetros del kernel, reorganizaron interrupciones y aplicaron defaults agresivos de gestión de energía en la BIOS porque
la eficiencia energética quedaba bien en la presentación.

El passthrough funcionó—en su mayoría. Pero tras ventanas de mantenimiento, algunas VMs arrancaban con la GPU ausente, o la NIC pasada a una VM firewall
no tenía link hasta que reiniciaban la VM. El equipo lo trató como “raras hardware transitorias”.
Esas palabras son cómo los incidentes se convierten en recurrentes.

El culpable fue una combinación de gestión de energía (dispositivos cayendo a estados D profundos), comportamiento de firmware y capacidad de reset.
Algunos dispositivos no toleraron los nuevos defaults; otros necesitaban manejo explícito de reset. La “optimización” no era mala en general.
Era mala para su mezcla específica de dispositivos y patrones de disponibilidad.

Revirtieron las funciones de ahorro de energía para la tela PCIe, dejaron de perseguir micro-optimizaciones sin medición y documentaron una regla estricta:
los nodos de passthrough de producción tienen ajustes conservadores de energía PCIe y solo parámetros de kernel probados.
El rendimiento mejoró un poco menos de lo esperado, pero la fiabilidad mejoró dramáticamente—y eso es lo que paga tu salario a largo plazo.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un equipo pequeño de plataforma gestionaba una flota de nodos Proxmox con cargas mixtas. Algunas VMs usaban NICs en passthrough; otras usaban GPUs.
Su práctica era terriblemente aburrida: cada nodo tenía una nota de “topología hardware” actualizada tras cualquier cambio físico—mapas de ranuras, grupos IOMMU,
y qué VM consumía cada grupo.

Un fin de semana, un nodo falló y un técnico lo reemplazó con un chasis de repuesto, moviendo tarjetas rápidamente para restaurar servicio.
Las VMs arrancaron, pero una VM de almacenamiento que usaba un HBA pasado por hardware empezó a dar errores, mientras otra VM con passthrough de NIC
no arrancaba en absoluto.

En lugar de experimentar en producción, sacaron la nota de topología. Mostraba que en el chasis de repuesto, el HBA y la NIC estaban en el mismo grupo.
Eso no era un problema de configuración de Linux; era un desajuste de ranura/topología. Apagaron el nodo, movieron una tarjeta a la ranura correcta,
y restauraron servicios sin una larga interrupción.

Nada heroico. No parcheo de kernel. No ACS override a ciegas. Solo documentación y mapeo disciplinado de “esta ranura PCIe conduce a este root port
y a este grupo IOMMU.” La práctica era lo suficientemente aburrida como para que nadie la quisiera hacer—hasta que salvó un fin de semana y evitó un daño reputacional.

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

1) La VM no arranca: “unable to open /dev/vfio/X: Device or resource busy”

Causa raíz: un proceso ya mantiene el grupo VFIO (otra VM, QEMU atascado o estado de enlace residual).

Solución: identifica el propietario con lsof /dev/vfio/X, para la VM propietaria y limpia procesos QEMU obsoletos. Confirma que la propiedad del grupo es única.

2) La VM arranca, pero la GPU muestra pantalla negra

Causa raíz: firmware/tipo de máquina incorrecto (SeaBIOS vs OVMF, i440fx vs q35), ROM de GPU faltante, o la GPU no está marcada como primaria.

Solución: usa bios: ovmf, machine: q35, hostpci0: ...,pcie=1,x-vga=1. Asegúrate de pasar todas las funciones (audio de GPU).

3) La GPU funciona una vez y luego falla tras reiniciar la VM

Causa raíz: bug de reset o falta de soporte FLR; el dispositivo no se reinicializa limpiamente.

Solución: prefiere hardware con FLR; de lo contrario planifica operativamente (reinicio del host para reset limpio) o usa un módulo de workaround de reset cuando proceda.

4) El dispositivo no se liga a vfio-pci; el driver del host lo sigue cogiendo

Causa raíz: el driver se carga en initramfs antes de que vfio-pci reclame el dispositivo; las blacklists no se aplican temprano.

Solución: configura /etc/modprobe.d/vfio.conf + archivo blacklist, luego update-initramfs -u. Reinicia y verifica con lspci -k.

5) Los grupos IOMMU son enormes; la GPU comparte grupo con SATA/USB/NIC

Causa raíz: topología PCIe de la placa base y falta de aislamiento ACS; a veces ajustes de BIOS lo empeoran.

Solución: prueba ranuras distintas, desactiva “above 4G decoding” solo si demuestra cambiar el agrupamiento (a menudo necesitas tenerlo activado), considera otra placa.
Usa ACS override solo cuando aceptes la reducción de aislamiento.

6) La VM Windows muestra error de GPU (p. ej., el driver no carga, dispositivo deshabilitado)

Causa raíz: desajuste en la configuración de la VM (GPU primaria), falta de UEFI, o detección del proveedor/driver.

Solución: corrige la configuración q35/OVMF primero; luego maneja problemas específicos del proveedor solo si persisten.

7) La NIC en passthrough pierde enlace aleatoriamente

Causa raíz: estados de gestión de energía, quirks de remapeo de interrupciones o comportamiento de reset inestable en esa NIC/ranura.

Solución: fija ajustes conservadores de energía PCIe en la BIOS, actualiza firmware y valida logs de remapeo de interrupciones. Considera mover de ranura/root port.

8) El host Proxmox se vuelve inestable cuando se habilita ACS override

Causa raíz: dividiste grupos en software que no están aislados en hardware; las rutas DMA/interrupciones aún colisionan.

Solución: quita ACS override, rediseña la topología hardware, o pasa grupos enteros (y acepta perder esos dispositivos para el host).

Listas de verificación / plan paso a paso

Paso a paso: poner en marcha passthrough sin drama

1. BIOS primero: habilita VT-d (Intel) o AMD-Vi (AMD). Desactiva CSM si puedes y mantén la gestión de energía PCIe conservadora.
2. Flags del kernel: configura intel_iommu=on iommu=pt (o amd_iommu=on iommu=pt) en tu gestor de arranque.
3. Verificar inicialización IOMMU: revisa dmesg para “IOMMU enabled/Initialized.”
4. Mapear tu dispositivo objetivo: registra su dirección PCI y IDs mediante lspci -nn.
5. Inspeccionar grupos IOMMU: si el grupo contiene algo que no puedes perder, detente y rediseña (mueve ranura o cambia hardware).
6. Vincular a vfio-pci: añade options vfio-pci ids=... y pon en blacklist drivers competidores.
7. Actualizar initramfs y reiniciar: hace que el enlace temprano sea real.
8. Confirmar el enlace: lspci -k debe mostrar Kernel driver in use: vfio-pci.
9. Configurar la VM intencionalmente: q35 + OVMF para GPUs modernas, incluye todas las funciones, establece pcie=1.
10. Validar con logs: si falla, lee los logs de QEMU/daemon; no adivines.
11. Probar ciclos de reinicio: no solo “arrancó una vez”, sino “sobrevive reinicios invitado, apagado/arranque y políticas de migración.”
12. Documentar la topología: registra ranura → dirección PCI → grupo IOMMU → VM consumidora. El tú del futuro te lo agradecerá.

Checklist operativo: antes de declarar “listo para producción”

• El host arranca sin necesitar la GPU de passthrough para salida de consola (o tiene GPU/iGPU de consola separada).
• Todos los dispositivos en el grupo IOMMU o bien se pasan juntos o están sin uso por el host.
• La VM sobrevive 10+ ciclos de arranque/parada y al menos 3 reinicios invitados sin pérdida de dispositivo.
• Las actualizaciones de kernel del host tienen un plan de rollback (y has probado VFIO tras al menos una actualización).
• No hay ACS override en entornos que requieran aislamiento fuerte (multi-tenant, compliance, modelo de amenaza adversarial).
• Puedes explicar el dominio de fallo en una frase: “Si el grupo 7 falla, afecta a la VM 110 y a nada más.”

Preguntas frecuentes

1) ¿Por qué mi GPU debe pasarse con su dispositivo de audio?

Porque suele ser un dispositivo PCI multifunción: función GPU en 01:00.0 y audio HDMI/DP en 01:00.1.
A menudo comparten inicialización y comportamiento de reset. Pasa ambas a menos que tengas una razón probada para no hacerlo.

2) ¿El ACS override es “seguro”?

“Seguro” depende de tu modelo de amenaza. ACS override puede hacer que Linux muestre grupos más pequeños, pero no puede añadir aislamiento hardware faltante.
Para un laboratorio en casa suele ser aceptable. Para entornos que requieren aislamiento DMA estricto, evítalo y arregla la topología con hardware.

3) Mi grupo IOMMU incluye el controlador SATA. ¿Ahora qué?

No pases ese grupo a menos que estés preparado para perder el acceso de almacenamiento del host. Prueba otra ranura PCIe, revisa opciones de BIOS,
o ve a una placa/CPU con mejor aislamiento de root ports.

4) ¿Por qué Proxmox dice que el dispositivo VFIO está ocupado cuando no hay ninguna VM corriendo?

A menudo hay un proceso QEMU colgado, una tarea de gestión manteniendo el dispositivo, o una VM parcialmente iniciada.
Usa lsof /dev/vfio/X para encontrar el proceso. Luego para la VM limpiamente o mata el proceso colgado y revisa logs.

5) ¿Debería usar q35 o i440fx para passthrough?

Para GPUs modernas y dispositivos PCIe, usa q35. Modela PCIe de forma más natural y evita algunas rarezas legacy.
Usa i440fx solo si tienes una dependencia invitada legacy o una razón específica de compatibilidad.

6) ¿Necesito OVMF (UEFI) para passthrough de GPU?

No siempre, pero a menudo sí. Muchas GPUs modernas y setups Windows 11 se comportan mejor con OVMF.
Si ves pantallas negras o rarezas de inicialización, cambiar a OVMF es un cambio de alto impacto.

7) ¿Qué implica “not capable of FLR”?

FLR es un mecanismo de reset estandarizado. Sin él, un dispositivo puede no reiniciarse limpiamente entre ejecuciones de VM.
Los síntomas incluyen “funciona una vez” y “falla tras reinicio”. La solución operativa puede ser tan contundente como reiniciar el host entre ejecuciones, o tan real como nuevo hardware.

8) ¿Puedo pasar dispositivos a contenedores (LXC) en lugar de VMs?

Algunos accesos a dispositivos pueden concederse a contenedores, pero el verdadero passthrough PCI es una historia de VM porque necesitas aislamiento hardware y comportamiento VFIO.
Si necesitas separación fuerte y control total del dispositivo, usa una VM.

9) ¿Por qué cambian los grupos IOMMU después de una actualización de BIOS?

Las actualizaciones de BIOS pueden cambiar el ruteo PCIe, la exposición de ACS y cómo se enumeran los bridges. Eso puede remodelar los grupos.
Trata las actualizaciones de BIOS como un cambio que debe validarse en nodos de passthrough, no como un parche “rutinario”.

10) ¿Puedo pasar un controlador USB en lugar de dispositivos USB individuales?

Sí, y a menudo es más fiable para cargas USB intensas (dongles, cámaras, lectores de tarjetas inteligentes).
Pero revisa su grupo IOMMU cuidadosamente; los controladores USB suelen compartir grupo con otros dispositivos del chipset.

Conclusión: pasos siguientes que realmente importan

Cuando el passthrough PCI falla en Proxmox, el camino más rápido para salir es dejar de tratarlo como magia y empezar a tratarlo como topología más propiedad más firmware.
Comprueba la inicialización IOMMU, lee los grupos, vincula dispositivos a VFIO temprano y configura las VMs intencionalmente (q35 + OVMF es la postura por defecto para GPUs modernas).

Pasos prácticos siguientes:

• Ejecuta el volcado de grupos IOMMU y guárdalo junto a la documentación del nodo. Trátalo como un diagrama de cableado.
• Verifica el enlace con lspci -k después de cada actualización de kernel y tras cualquier cambio de BIOS.
• Si dependes de ACS override en algo parecido a producción, planifica una migración de hardware/topología. Es deuda técnica con filo PCIe.
• Prueba ciclos de reinicio, no solo “primer arranque”. La mayoría de fallos están relacionados con reset y ciclo de vida.

El passthrough no es difícil porque Linux sea complicado. Es difícil porque el hardware es complicado—y muy confiado en sí mismo.
Alinea con el hardware, y Proxmox te parecerá aburrido. Aburrido es la meta.