Pantalla negra al pasar GPU en Proxmox: 10 causas y soluciones

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

Cuando la pantalla está negra, no te desesperes. La canalización de passthrough de GPU es larga. Tu objetivo es encontrar qué segmento está roto:
aislamiento del dispositivo en el host, inicialización del firmware de la VM, controlador del invitado o enrutamiento de pantalla.

Primero: confirma que el host realmente entregó la GPU a VFIO

• Verificar enlace: la GPU debe estar ligada a vfio-pci, no a nvidia, amdgpu o nouveau.
• Verificar que IOMMU esté activo: si el remapeo DMA está desactivado, el passthrough puede funcionar a medias y luego fallar de forma extraña.
• Verificar grupos IOMMU: si tu GPU está en un grupo con otros dispositivos que no pasaste, tendrás fallos inconsistentes.

Segundo: confirma que la VM puede inicializar el dispositivo (firmware + tipo de máquina)

• OVMF vs SeaBIOS: las GPUs modernas suelen necesitar UEFI (OVMF). Algunas tarjetas antiguas funcionan mejor con SeaBIOS. Elige con deliberación.
• Q35 vs i440fx: Q35 es el predeterminado por una razón (PCIe). Muchos problemas de passthrough desaparecen con Q35.
• Configuración de GPU primaria: si la VM espera un dispositivo de pantalla pero lo quitaste, puedes estar viendo nada porque no pediste nada.

Tercero: confirma que el controlador del invitado está sano y la salida está enrutada correctamente

• Windows: revisa errores en el Administrador de dispositivos (Código 43, Código 31) y el registro de eventos.
• Invitados Linux: revisa dmesg para la inicialización de amdgpu/nvidia y confirma qué salida está activa.
• Enrutamiento de pantalla: prueba puertos diferentes (DP vs HDMI) y desactiva alta tasa de refresco + HDR mientras depuras.

Una cita que vale la pena tener en mente mientras depuras: idea parafraseada de Richard Feynman:
“La realidad debe primar sobre las relaciones públicas.” En términos de operaciones: confía en lo que dice el kernel, no en lo que sugiere la interfaz.

Hechos interesantes y breve historia (por qué es tan quisquilloso)

• Intel VT-d (remapeo DMA) se difundió años después de la virtualización de CPU; los primeros hipervisores podían ejecutar VMs pero no pasar dispositivos de forma segura.
• VFIO reemplazó marcos anteriores de passthrough PCI en Linux porque es más seguro e integra correctamente IOMMU.
• OVMF es esencialmente firmware UEFI para VMs; a medida que las GPUs se volvieron más centradas en UEFI, las rutas BIOS legacy empezaron a fallar más.
• Las GPUs no son “solo dispositivos PCIe”: muchas son pequeñas computadoras con su propio firmware, entrenamiento de memoria y estado en tiempo de arranque.
• El “Código 43” de NVIDIA se convirtió en un rito de iniciación para usuarios de passthrough; ahora es menos común pero aún aparece en casos límite.
• Los bugs de reset son reales: algunas GPUs no se reinician completamente tras apagar la VM, así que el siguiente arranque hereda un dispositivo en mal estado.
• ACS (Access Control Services) afecta el aislamiento PCIe; las placas de consumidor pueden agrupar dispositivos juntos aunque tú quieras separarlos.
• Resizable BAR es una característica de rendimiento que puede cambiar cómo se mapea la memoria; es genial hasta que no lo es, especialmente entre límites de firmware.
• El entrenamiento de enlace DisplayPort puede fallar tras reinicios en caliente; una “pantalla negra” puede ser un problema de negociación con el monitor, no un problema PCI.

Modelo mental: dónde ocurre la pantalla negra

Una “pantalla negra” no es un solo problema; es un síntoma. La pila de passthrough de GPU tiene capas, y cada capa puede fallar de forma que parezca idéntica
desde tu silla.

1. Aislamiento de hardware: IOMMU debe traducir DMA, y la topología PCIe debe permitir aislar la GPU claramente.
2. Enlace del controlador en el host: el host no debe reclamar la GPU con un controlador nativo. VFIO debe poseerla antes de iniciar la VM.
3. Firmware de la VM + modelo de máquina: OVMF/Q35 debe enumerar PCIe, asignar BARs e inicializar las rutas del option ROM correctamente.
4. Controlador del invitado: Windows/Linux deben cargar un controlador que pueda manejar el entorno, gestión de energía e inicialización de pantalla.
5. Salida de pantalla: la GPU puede estar bien, pero la salida está en otro puerto, la negociación del monitor falló o la GPU espera un modo de pantalla.

Verdad seca y graciosa: la GPU es inocente hasta que se demuestre lo contrario, pero aun así arruinará tu día como un gato con acceso a un teclado.

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

Estas son las tareas que ejecuto aproximadamente en este orden. Cada una tiene: comando, qué significa la salida y qué decisión tomar a continuación.
Están escritas para un host Proxmox VE (basado en Debian).

Tarea 1: Confirmar que IOMMU está realmente habilitado

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.012345] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.045678] DMAR: DRHD base: 0x000000fed90000 flags: 0x1

Significado: Quieres ver “IOMMU enabled” (Intel DMAR) o “AMD-Vi: IOMMU enabled”.

Decisión: Si no lo ves, detente. Arregla la configuración del BIOS y los parámetros del kernel antes de tocar la configuración de la VM.

Tarea 2: Verificar los parámetros de la línea de comandos del kernel

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

Significado: intel_iommu=on o amd_iommu=on debe estar presente. iommu=pt se usa comúnmente por rendimiento.

Decisión: Si falta, edita GRUB, update-grub, reinicia. No “esperes que esté bien”.

Tarea 3: Identificar los IDs PCI de la GPU (y la función de audio)

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display|audio' 
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)

Significado: Las GPUs suelen ser dispositivos multifunción. La función de audio importa para los resets y la estabilidad del controlador en Windows.

Decisión: Planea pasar ambas funciones a menos que tengas una razón para no hacerlo.

Tarea 4: Comprobar qué controlador posee actualmente la GPU

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] TU104 [1462:3751]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau

Significado: “Kernel driver in use: vfio-pci” es lo que deseas.

Decisión: Si dice nouveau, nvidia o amdgpu, arregla el enlace antes de ejecutar la VM.

Tarea 5: Confirmar que los módulos VFIO están cargados

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          69632  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   57344  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             425984  0
kvm                  1376256  1 kvm_intel

Significado: Si VFIO no está presente, el passthrough será inestable o fallará por completo.

Decisión: Carga los módulos, arregla la configuración de initramfs, reinicia si es necesario.

Tarea 6: Inspeccionar el aislamiento del grupo IOMMU para la GPU

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do echo "$(basename "$(dirname "$d")") $(basename "$d")"; done | sort -n | egrep '01:00'
12 0000:01:00.0
12 0000:01:00.1

Significado: Idealmente, la GPU y su función de audio están en un grupo por sí solas (o solo con lo que también pasas).

Decisión: Si el grupo incluye dispositivos del chipset o un NVMe que necesitas en el host, probablemente necesites cambiar de ranura o usar ACS override con precaución.

Tarea 7: Verificar la configuración de la VM en Proxmox para máquina/firmware correctos

cr0x@server:~$ qm config 120
agent: 1
bios: ovmf
boot: order=scsi0;net0
cores: 8
cpu: host,hidden=1,flags=+pcid
machine: q35
memory: 16384
name: win11-gpu
ostype: win11
scsi0: local-lvm:vm-120-disk-0,discard=on,iothread=1
hostpci0: 0000:01:00.0,pcie=1,x-vga=1
hostpci1: 0000:01:00.1,pcie=1

Significado: bios: ovmf y machine: q35 suelen ser correctos. x-vga=1 puede ayudar si quieres la GPU como primaria.

Decisión: Si estás en i440fx/SeaBIOS con una GPU moderna, cambia a Q35/OVMF a menos que tengas evidencia en contra.

Tarea 8: Leer el registro de QEMU para errores de asignación de dispositivo

cr0x@server:~$ journalctl -u pve-qm@120 --no-pager -n 120
... qemu-system-x86_64: vfio-pci 0000:01:00.0: BAR 1: can't reserve [mem 0x...] ...
... qemu-system-x86_64: vfio-pci 0000:01:00.0: failed to setup container for group 12: Failed to set iommu for container: Operation not permitted
... VM 120 start failed: QEMU exited with code 1

Significado: Los problemas de reserva de BAR, errores de grupo y problemas de permisos aparecen aquí primero.

Decisión: Si QEMU no puede arrancar, no persigas controladores del invitado. Arregla la capa host/firmware.

Tarea 9: Buscar si el host tomó la consola (conflictos de framebuffer)

cr0x@server:~$ dmesg | egrep -i 'fbcon|efifb|simplefb|vesafb|nouveau|amdgpu' | head -n 60
[    1.234567] efifb: framebuffer at 0xe1000000, using 3072k, total 3072k
[    1.234890] fbcon: Deferring console take-over

Significado: Si el host enlaza un framebuffer a la GPU, el enlace a VFIO puede competir o fallar.

Decisión: Si ves que el host agarra la GPU objetivo, pon en lista negra los módulos relevantes y considera desactivar el framebuffer EFI para ese dispositivo.

Tarea 10: Confirmar que la VM ve la GPU desde dentro (Windows sin agente como indicio)

cr0x@server:~$ qm monitor 120
(qemu) info pci
  Bus  0, device  1, function 0:
    VGA controller: PCI device 10de:1e87
      BAR0: 64 bit memory at 0x00000000f6000000 [0x01000000]
      BAR1: 64 bit memory at 0x00000000e0000000 [0x10000000]

Significado: QEMU enumera el dispositivo y mapea los BARs. Esto no prueba que los controladores funcionen, pero demuestra que pasaste la enumeración básica.

Decisión: Si falta, vuelve a la configuración de la VM (líneas hostpci, pcie=1) y a las comprobaciones de grupo IOMMU.

Tarea 11: Detectar problemas relacionados con reset (GPU atascada tras shutdown)

cr0x@server:~$ dmesg | egrep -i 'vfio-pci|reset|FLR|D3' | tail -n 60
[  912.345678] vfio-pci 0000:01:00.0: not ready 1023ms after bus reset; waiting
[  913.369012] vfio-pci 0000:01:00.0: not ready 2047ms after bus reset; giving up

Significado: La GPU no se reinició limpiamente. Eso con frecuencia produce una pantalla negra en el siguiente arranque de la VM.

Decisión: Aplica una solución de restablecimiento (vendor-reset para algunas AMD, reinicio completo del host, o elige una GPU conocida por resetear limpiamente).

Tarea 12: Comprobar remapeo de interrupciones y advertencias del kernel

cr0x@server:~$ dmesg | egrep -i 'interrupt remapping|IR:|x2apic|ATS|posted interrupt' | head -n 80
[    0.123456] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.123789] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.

Significado: El remapeo de IRQ reduce “bloqueos misteriosos de dispositivos bajo carga” y mejora el aislamiento.

Decisión: Si ves advertencias sobre remapeo de IRQ deshabilitado, espera inestabilidad. Arregla BIOS/firmware o considera flags de kernel apropiados para tu plataforma.

Tarea 13: Confirmar la situación del ROM de la GPU (solo si hace falta)

cr0x@server:~$ echo 1 | sudo tee /sys/bus/pci/devices/0000:01:00.0/rom >/dev/null
cr0x@server:~$ sudo cat /sys/bus/pci/devices/0000:01:00.0/rom | head -c 16 | hexdump
0000000 55 aa 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000010

Significado: Un encabezado ROM empieza con 55 aa. Algunas GPUs necesitan un ROM volcado para inicializar en una VM, especialmente si no son la GPU primaria.

Decisión: Si las lecturas ROM están bloqueadas o son basura, considera proporcionar un archivo ROM conocido en la configuración de la VM (solo entonces).

Tarea 14: Verificar que hugepages / respaldo de memoria no rompan DMA

cr0x@server:~$ grep -H . /proc/meminfo | egrep 'HugePages|Hugepagesize' 
/proc/meminfo:HugePages_Total:       8192
/proc/meminfo:HugePages_Free:        8000
/proc/meminfo:Hugepagesize:          2048 kB

Significado: Las hugepages están bien, pero un mal dimensionamiento o dejar al host sin memoria puede causar fallos raros que parecen problemas de GPU.

Decisión: Si el host sufre presión de memoria o las hugepages están fragmentadas, revierte los “ajustes de rendimiento” hasta que la VM funcione de forma fiable.

10 causas y soluciones (edición pantalla negra)

1) El host sigue usando la GPU (enlace de controlador incorrecto)

Este es el clásico. Pasaste la GPU, pero el host cargó nvidia, amdgpu o nouveau primero.
La VM arranca, pero la GPU está medio poseída y se comporta como si la tiraran en dos direcciones. La pantalla negra es un resultado común.

Solución: liga el dispositivo a vfio-pci temprano (initramfs) y pon en lista negra los módulos en conflicto.

cr0x@server:~$ cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1

cr0x@server:~$ cat /etc/modprobe.d/blacklist-gpu.conf
blacklist nouveau
blacklist nvidia
blacklist nvidiafb

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

Decisión: Tras reiniciar, vuelve a comprobar con lspci -nnk. Si no es vfio-pci, no has terminado.

2) Los grupos IOMMU están “sucios” (no puedes aislar la GPU)

Si la GPU está en un grupo IOMMU con otros dispositivos (controladores USB, SATA, a veces vecinos de la ranura PCIe),
VFIO no puede asignar solo la GPU de forma segura. Podrías obtener “arranca una vez, luego pantalla negra” o “funciona hasta que se carga el controlador”.

Solución: mueve la GPU a otra ranura, desactiva “Above 4G decoding” solo si realmente rompe el agrupamiento (raro), o usa ACS override con cautela.

cr0x@server:~$ pvesh get /nodes/$(hostname)/hardware/pci --pci-class-blacklist ""
... 

Decisión: Si mover de ranura te da un grupo limpio, hazlo. Si debes usar ACS override, trátalo como un parche, no como una victoria.

3) Firmware/tipo de máquina equivocado (desajuste OVMF/Q35)

SeaBIOS más i440fx aún puede funcionar, pero es la opción “corrió en mi portátil en 2017”.
Las GPUs modernas y los instaladores de OS modernos están más contentos con OVMF + Q35.

Solución: configura bios: ovmf y machine: q35. Añade también un disco EFI si es necesario (Proxmox lo hace en la UI).

Decisión: Si estás atascado en SeaBIOS por una razón heredada, puede que necesites proporcionar un archivo ROM y aceptar que algunas GPUs no cooperarán.

4) Estás mirando la salida de pantalla equivocada (puerto y negociación del monitor)

Este es humillante porque es real. Diferentes puertos pueden comportarse distinto bajo passthrough: entrenamiento de enlace DP,
peculiaridades EDID HDMI y estados de ahorro de energía del monitor pueden parecer “la GPU está muerta”.

Solución: mientras depuras, usa un solo monitor, configúralo a una tasa básica (60 Hz), desactiva HDR y prueba otro puerto.

Decisión: Si la VM es accesible por RDP/SSH pero la salida local está negra, probablemente la GPU está bien; el problema es la ruta de pantalla.

5) Falta la función de audio de la GPU (passthrough multifunción)

Muchas GPUs exponen una función de audio HDMI/DP. Algunos controladores asumen que existe. Algunos resets funcionan mejor cuando se pasan todas las funciones.
Pasar solo la función VGA puede provocar que el controlador se cargue… y luego no haya imagen en pantalla.

Solución: pasa tanto 01:00.0 como 01:00.1 como entradas hostpci separadas.

Decisión: Si no puedes pasar la función de audio porque está agrupada con otro dispositivo, vuelve al agrupamiento IOMMU y la elección de ranura.

6) Código 43 de NVIDIA / detección de hipervisor (menos común, pero real)

En algunos entornos, Windows + controladores NVIDIA deciden que no les gustan los invitados virtualizados y se niegan a inicializar correctamente la GPU.
Los síntomas varían: pantalla negra, error de dispositivo, controladores que instalan pero nunca producen salida.

Solución: usa cpu: host,hidden=1 en la configuración de la VM y evita enmascarar flags CPU exóticos a menos que lo necesites por licencias o compatibilidad.

Decisión: Si haces cargas tipo VDI, prueba versiones del controlador. Esto no es superstición; ocurren regresiones.

7) El bug de reset (la GPU no se reinicia tras reboot/shutdown de la VM)

Algunas GPUs no se reinician completamente sin un ciclo de energía completo. Apagas la VM, la arrancas otra vez y obtienes pantalla negra.
El primer arranque funciona, lo que te hace culpar al invitado. La GPU es la que guarda rencor.

Opciones de solución:

• Intenta un reinicio completo del host como diagnóstico. Si eso “arregla” el problema, probablemente sea un problema de reset.
• Para algunas tarjetas AMD, un módulo auxiliar de reset puede restaurar la función adecuada (dependiente de la plataforma).
• Prefiere GPUs que se reinicien limpiamente para producción. “Funciona si nunca reinicio” no es una estrategia.

Broma #2: Si tu GPU solo funciona tras reiniciar el host, felicidades: has construido un interruptor de luz muy caro.

8) Tamaño de BAR / Above 4G decoding / peculiaridades Resizable BAR

Las GPUs modernas mapean grandes regiones de memoria (BARs). Si el firmware no puede asignar espacio con limpieza, verás errores de reserva de BAR,
fallos aleatorios de QEMU o una VM que arranca pero nunca muestra salida cuando el controlador intenta mapear la VRAM.

Solución:

• Activa “Above 4G decoding” en el BIOS para asignaciones grandes de BAR (comúnmente requerido).
• Desactiva temporalmente Resizable BAR mientras depuras (especialmente si mezclas OS o firmware antiguos).
• Mantente en Q35 y OVMF para un comportamiento PCIe sensato.

Decisión: Si tus registros muestran fallos de asignación de BAR, no pierdas tiempo en el invitado.

9) Confusión sobre la GPU primaria: x-vga, vBIOS y “sin pantalla emulada”

Si quitas el dispositivo VGA emulado y esperas que la GPU pasada sea primaria, el firmware del invitado debe usarla como pantalla de arranque.
A veces no lo hace, especialmente si la GPU no expone un option ROM compatible con lo que la VM espera.

Solución:

• Prueba x-vga=1 en el dispositivo de passthrough de la GPU.
• Mantén una pantalla emulada básica temporalmente (como VGA estándar) para instalar/depurar, luego quítala cuando sea estable.
• Si es necesario, suministra un archivo ROM que coincida con tu modelo exacto de GPU.

Decisión: Si puedes ver las pantallas de arranque mediante VGA emulado pero pierdes salida al cambiar a la GPU, estás en territorio de firmware/option-ROM.

10) Gestión de energía y estados de suspensión (D3cold, ASPM y amigos)

Algunas plataformas ponen agresivamente los dispositivos en estados de bajo consumo. En metal desnudo, los controladores lo manejan.
Bajo passthrough, las transiciones de estado de energía pueden ser menos tolerantes. El controlador del invitado se carga, cambia el estado de energía de la GPU,
y tu pantalla se queda en negro.

Solución: desactiva PCIe ASPM en el BIOS para pruebas y evita suspender/hibernar dentro del invitado hasta demostrar estabilidad.

Decisión: Si la GPU funciona hasta que el invitado entra en reposo o la pantalla se apaga, sospecha de gestión de energía en lugar de problemas básicos de VFIO.

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

• Síntoma: La VM arranca, la consola de Proxmox está en negro, el monitor está en negro, pero la VM responde al ping.
  Causa raíz: La salida está en otro puerto de la GPU o el invitado está usando otro adaptador de pantalla.
  Solución: Conéctate por RDP/SSH, configura la GPU pasada como pantalla primaria, prueba otro puerto físico, reduce la tasa de refresco/HDR.
• Síntoma: La VM no arranca; QEMU sale con errores de grupo/contenedor.
  Causa raíz: Grupo IOMMU no aislado o IOMMU deshabilitado/mal configurado.
  Solución: habilita VT-d/AMD-Vi, arregla flags del kernel, mueve la GPU de ranura, y solo entonces considera ACS override.
• Síntoma: Funciona una vez tras reiniciar el host, luego pantalla negra tras reinicio de la VM.
  Causa raíz: Bug de reset de la GPU / FLR no soportado.
  Solución: evita paradas/inicios frecuentes, usa soluciones vendor-reset cuando aplique, o elige una GPU con resets limpios.
• Síntoma: Windows muestra la GPU pero el controlador falla; pantalla negra cuando se carga el controlador.
  Causa raíz: desajuste controlador/hipervisor, falta la función de audio, o desajuste de firmware.
  Solución: pasa todas las funciones, usa OVMF+Q35, configura cpu: host,hidden=1, prueba una rama de controladores estable.
• Síntoma: El host pierde video tras ligar la GPU a VFIO; ya no ves la consola.
  Causa raíz: Has pasado la única GPU que el host utiliza para pantalla.
  Solución: usa una iGPU o una GPU secundaria barata para la consola del host, o trabaja sin interfaz local con IPMI/serial y acepta la compensación.
• Síntoma: Congelaciones aleatorias bajo carga; a veces termina en pantalla negra.
  Causa raíz: remapeo de interrupciones deshabilitado, BIOS con bugs o transiciones de gestión de energía problemáticas.
  Solución: actualiza BIOS, habilita remapeo de IRQ, desactiva ASPM para pruebas, mantén el kernel actualizado.
• Síntoma: El registro de QEMU menciona fallos de reserva de BAR.
  Causa raíz: interacción Above 4G decoding/Resizable BAR o agotamiento de espacio de direcciones.
  Solución: habilita Above 4G decoding, desactiva Resizable BAR temporalmente, mantente en Q35/OVMF.

Tres microhistorias corporativas desde el campo

Incidente #1: La caída causada por una suposición errónea

Un equipo quería “aceleración GPU barata” para una carga de trabajo CAD en Windows. Construyeron un nodo Proxmox con una GPU grande y supusieron:
“La VM usa la GPU, el host no la necesita.” Incluso desactivaron la VGA emulada porque parecía más limpio.

La VM arrancó bien—una vez. Tras un reinicio de mantenimiento, volvió con pantalla negra. El on-call intentó lo habitual:
reinstalar controladores, cambiar cables de pantalla, togglear ajustes OVMF. Sin suerte. La VM estaba viva en la red, pero la salida local nunca volvió.

La suposición oculta fue que la GPU siempre presentaría una pantalla de arranque usable a OVMF. En realidad, la ruta del option ROM de la tarjeta
no era consistente en esa configuración. Sin pantalla emulada, no había nada que ver durante el arranque temprano y la inicialización del controlador fallaba en silencio.

La solución fue aburrida: volver a añadir una pantalla emulada para instalación y resolución de problemas, mantener Q35+OVMF, pasar ambas funciones de la GPU,
y solo quitar el adaptador emulado tras confirmar que la GPU es estable tras múltiples reinicios. También añadieron una GPU secundaria pequeña para la consola del host.
La “aceleración barata” se volvió menos cara en horas humanas de inmediato.

Incidente #2: La optimización que salió mal

Otra organización perseguía latencia y decidió “optimizar todo”: hugepages, fijación de CPU, ahorro de energía agresivo, ASPM activado,
y una línea de kernel personalizada copiada de un hilo de foro que parecía autoritativa.

La VM con passthrough GPU arrancaba, mostraba salida y luego se ponía negra bajo carga—usualmente cuando empezaba un trabajo de render.
Su primera intuición fue los controladores. Fijaron más núcleos. Cambiaron perfiles de energía en Windows. Incluso cambiaron monitores.
La pantalla negra seguía volviendo como una secuela que nadie pidió.

Finalmente miraron dmesg y encontraron que el remapeo de interrupciones no hacía efectivamente lo que pensaban debido a la interacción de la BIOS con x2APIC.
El sistema era lo bastante estable para uso ligero, inestable bajo mucho tráfico DMA/interrupt. La “optimización” (gestión de energía agresiva + flags cuestionables del kernel) convirtió una configuración mayormente correcta en una problemática.

La solución fue volver a una línea base conocida: parámetros de kernel Proxmox por defecto para IOMMU, actualizar BIOS,
desactivar ASPM durante la validación y solo entonces reintroducir ajustes uno por uno con plan de reversión.
El rendimiento mejoró porque el sistema dejó de caerse. Eso es una optimización subestimada.

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

Un tercer equipo ejecutaba passthrough GPU para una pequeña canalización CI interna que necesitaba compilaciones CUDA. No era llamativo, pero casi producción.
Tenían una regla: cada cambio de infraestructura tenía un snapshot previo de la config de la VM y un volcado de “estado conocido” en el host.
También mantenían un registro de IDs PCI de GPU, grupos IOMMU y la versión exacta del kernel Proxmox en uso.

Una mañana tras una actualización rutinaria de kernel, las VMs empezaron a arrancar con pantallas negras. El pánico empezó a formarse—esa canalización alimentaba liberaciones.
Pero el equipo tenía recibos: compararon qm config antes y después, confirmaron que los IDs PCI no cambiaron,
y vieron de inmediato que la GPU se había vinculado de nuevo a un controlador del host después de la actualización de initramfs.

Porque tenían una checklist, no discutieron teorías. Regeneraron initramfs, confirmaron el enlace VFIO, reiniciaron una vez
y recuperaron rápidamente. Sin heroicidades. No “reinstales el invitado.” Solo verificación disciplinada.

La práctica no era sexy, pero acortó el incidente. En operaciones, la solución más rápida suele ser “probar qué cambió” y luego revertirlo limpiamente.

Listas de verificación / plan paso a paso

Checklist A: Preparación del host (haz esto antes de tocar la VM)

1. Habilita VT-d/AMD-Vi y (si está disponible) el remapeo de interrupciones en el BIOS.
2. Activa Above 4G decoding para GPUs modernas; desactiva Resizable BAR temporalmente si depuras.
3. Arranca el host y verifica que IOMMU esté habilitado en dmesg.
4. Confirma los IDs PCI de la GPU y el aislamiento del grupo IOMMU.
5. Vincula GPU + función de audio a vfio-pci en initramfs; pon en lista negra los controladores nativos de GPU.
6. Reinicia y vuelve a comprobar lspci -nnk para el enlace a vfio-pci.

Checklist B: Configuración de VM en Proxmox (valores predeterminados estables)

1. Usa Q35 como tipo de máquina y OVMF como BIOS para la mayoría de GPUs modernas.
2. Añade disco EFI (vars UEFI) para OVMF.
3. Pasa la GPU y su función de audio con pcie=1.
4. Empieza con una pantalla emulada presente para instalar/depurar; elimínala más tarde si hace falta.
5. Configura el tipo de CPU a host; para NVIDIA/Windows, considera hidden=1.
6. Arranca una vez, instala controladores, reinicia varias veces para validar el comportamiento de reset.

Checklist C: Plan de respuesta para pantalla negra (cuando se rompe a las 2 a.m.)

1. Confirma que la VM está viva en la red (ping, RDP/SSH). Si está viva, sospecha de salida/driver en vez de fallo de arranque.
2. Revisa journalctl -u pve-qm@VMID por errores VFIO/BAR/grupo.
3. Comprueba el enlace de GPU en el host y los mensajes de reset en dmesg.
4. Si es el bug de reset, haz un reinicio controlado del host para restaurar la GPU y luego planifica una solución real (no “nunca reiniciar”).
5. Documenta qué cambió desde el último estado bueno: actualización de kernel, ajuste BIOS, actualización de controladores, configuración de hardware de la VM.

Preguntas frecuentes

1) ¿Por qué mi VM arranca bien, pero la pantalla se pone negra cuando se instalan los controladores de GPU?

Eso suele ser la transición desde el framebuffer VGA/UEFI básico al modo completo del controlador. Sospecha de desajuste de firmware/tipo de máquina,
falta de la función de audio, gestión de energía o una rareza controlador/hipervisor (incluyendo comportamiento Código 43 en algunas configuraciones).

2) ¿Debería usar OVMF o SeaBIOS para passthrough de GPU?

Usa OVMF para la mayoría de GPUs modernas y sistemas invitados modernos. SeaBIOS es para casos legacy específicos o para depuración,
y reduce tus opciones con hardware más nuevo.

3) ¿Q35 o i440fx?

Q35 salvo que tengas una razón para no usarlo. Las GPUs son dispositivos PCIe; Q35 modela PCIe de forma más natural y evita mucha rareza.

4) ¿Realmente necesito pasar la función de audio de la GPU?

En la práctica: sí, la mayoría de las veces. Mejora la estabilidad del controlador y puede reducir casos límite con resets e inicialización.
Si la omites, eliges una configuración más frágil.

5) Mi host solo tiene una GPU. ¿Puedo pasarla y aún así gestionar Proxmox?

Sí, pero espera gestionarlo sin interfaz local (headless) y acepta que la salida de consola local pueda desaparecer.
Si valoras tu presión arterial, usa una iGPU, IPMI o una GPU secundaria barata para el host.

6) ¿Cuál es la forma más rápida de saber si esto es un problema del host o del invitado?

Si los registros de QEMU muestran errores VFIO/grupo/BAR, es host/firmware. Si la VM responde por la red pero no tiene pantalla, es controlador/salida.
Si solo se rompe tras reiniciar la VM, probablemente sea un problema de reset.

7) ¿“iommu=pt” causa pantallas negras?

Normalmente no; es un ajuste común de rendimiento. Pero si tu plataforma ya tiene comportamiento IOMMU inestable, cualquier ajuste puede exponerlo.
Si depuras, simplifica: mantén los flags IOMMU necesarios y elimina ajustes no esenciales.

8) ¿Cómo sé si tengo un bug de reset?

El patrón es: el primer arranque de la VM funciona, los arranques posteriores tras apagar la VM producen pantalla negra, y dmesg muestra timeouts de reset de VFIO.
Un reinicio completo del host “lo arregla” temporalmente. Ese es el indicio.

9) ¿Es seguro usar ACS override?

Es un parche que intercambia garantías de aislamiento por conveniencia. Para laboratorio suele ser aceptable.
Para producción, prefiere hardware que ofrezca grupos IOMMU limpios sin trucos.

10) ¿Por qué la consola de Proxmox no muestra nada aunque haya pasado la GPU?

La consola de Proxmox es para el dispositivo de pantalla emulado. Si dependes de la salida de la GPU pasada, la consola puede estar en blanco por diseño.
Mantén un adaptador emulado durante la depuración para tener visibilidad dentro de la VM.

Conclusión: próximos pasos prácticos

Trata una pantalla negra como un problema de enrutamiento, no de humor. Empieza en el host: IOMMU habilitado, grupo IOMMU limpio, enlace vfio-pci.
Luego valida el firmware y el modelo de máquina de la VM (OVMF + Q35 es la base sensata). Solo entonces persigue controladores del invitado y peculiaridades del monitor.

Pasos siguientes que rinden de inmediato:

• Captura un “estado conocido” con: /proc/cmdline, lspci -nnk, grupos IOMMU y qm config.
• Prueba el enlace VFIO después de cada actualización de kernel (los cambios en initramfs pueden devolverte a controladores del host).
• Valida los resets haciendo múltiples ciclos de apagado/arranque de la VM antes de darlo por terminado.
• Si encuentras un bug de reset, deja de negociar con esa GPU y cambia el plan: módulo workaround, modelo distinto o aceptar reinicios del host.