PCI passthrough en Proxmox: pasar una GPU o dispositivo PCIe a una VM

El PCI passthrough permite que una máquina virtual acceda directamente a un dispositivo físico del servidor, como si lo hubiera enchufado en su placa base. En Proxmox VE, esto se traduce en VMs con rendimiento casi nativo para gráficas, NVMe o tarjetas de red, a cambio de requisitos firmes y un puñado de pasos previos que conviene no saltarse.

---

1. Qué es el PCI passthrough y qué cambia para tu servidor

Cuando activas PCI passthrough, Proxmox aísla un dispositivo PCIe del host y lo entrega en exclusiva a una VM usando el módulo del kernel vfio. Una vez entregado, ese dispositivo deja de estar disponible para el anfitrión, así que no se puede compartir entre varias VMs en paralelo (salvo usando SR-IOV o vGPU, que son casos aparte).

Los principales efectos prácticos son:

• Rendimiento prácticamente nativo para gráficas, abriendo la puerta a juegos, CAD o inferencia local.
• Latencia mínima para tarjetas de red Intel o Mellanox usadas en firewalls o routers.
• Acceso directo a NVMe internos, lo que permite instalar Windows en unidades dedicadas.

Es importante saber que las VMs con dispositivos passthrough no se pueden migrar en vivo entre nodos: el hardware es físico, no abstracto. Y, por supuesto, toca planificar muy bien qué dispositivo se entrega y por qué.

2. Requisitos: CPU, placa base y firmware

Antes de comprar o reconfigurar nada, conviene comprobar tres patas: CPU, placa base y dispositivo.

2.1. CPU con IOMMU

La CPU debe soportar virtualización por hardware e IOMMU.

• AMD: cualquier CPU de la generación Bulldozer en adelante sirve. Las K10 más antiguas requieren placa 890FX o 990FX.
• Intel: lista de CPUs con VT-d disponible en la wiki oficial de Intel; las gamas medias de los últimos años lo traen.

2.2. Placa base con IOMMU y opciones en BIOS

La placa debe permitir activar IOMMU. La mayoría de placas modernas lo incluyen, aunque las listas de la wiki de Xen y Wikipedia suelen ir atrasadas. En la BIOS hay que activar IOMMU o VT-d explícitamente; dejar la opción en Auto no siempre equivale a activado.

Para GPU passthrough, también resulta útil desactivar Legacy Boot / CSM cuando Proxmox se instaló en modo UEFI. La razón es evitar la inicialización VGA heredada de la GPU, que más tarde impide re-inicializarla para la VM. Si la placa no soporta UEFI, déjalo como está.

2.3. Dispositivo compatible

Casi todas las GPUs modernas y tarjetas de red recientes funcionan. La wiki de Proxmox reporta compatibilidad estable con:

• AMD RADEON serie 5xxx, 6xxx, 7xxx y superiores.
• NVIDIA GeForce GTX 4xx-9xx, GTX 10xx, GTX 16xx, RTX 20xx, RTX 30xx, RTX 40xx y RTX 50xx.
• AMD Navi 5xxx(XT) y 6xxx(XT) sufren el “AMD reset bug”, documentado más adelante; funcionan, pero con caveats.

Para usar OVMF (UEFI) en la VM, la GPU debe exponer su ROM como UEFI. La mayoría de GPUs modernas lo hacen. En caso de duda, la rom-parser tool de Alex Williamson permite comprobarlo volcando la ROM:

cd /sys/bus/pci/devices/0000:01:00.0/
echo 1 > rom
cat rom > /tmp/image.rom
echo 0 > rom
./rom-parser /tmp/image.rom

Se necesita un type 3 en la salida para confirmar UEFI.

3. Activar IOMMU en GRUB y cargar vfio

Una vez confirmados los requisitos, toca preparar el kernel de Proxmox. En sistemas UEFI modernos se usa proxmox-boot-tool para editar la línea de arranque; en sistemas BIOS clásicos se edita /etc/default/grub.

Añade intel_iommu=on o amd_iommu=on según fabricante al parámetro GRUB_CMDLINE_LINUX_DEFAULT, por ejemplo:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

iommu=pt activa passthrough y solo aísla dispositivos efectivamente asignados, dejando menos huella en rendimiento. Después regeneramos la configuración:

update-grub
proxmox-boot-tool refresh

Verificamos que el kernel reconoce IOMMU tras reiniciar:

dmesg | grep -e DMAR -e IOMMU

Si aparece DMAR: IOMMU enabled o el equivalente AMD, todo está correcto. La ausencia de este mensaje es indicio de que la BIOS no tiene IOMMU activo o la CPU no lo soporta.

3.1. Comprobar el reasignado de interrupciones

Sin reasignado de interrupciones, Proxmox devuelve Operation not permitted al asignar el dispositivo. Lo verificamos así:

dmesg | grep 'remapping'

Una línea tipo DMAR-IR: Enabled IRQ remapping in x2apic mode o AMD-Vi: Interrupt remapping enabled confirma que está disponible. En sistemas antiguos sin soporte basta con permitir interrupciones inseguras como workaround, aunque no es recomendable para producción:

echo "options vfio_iommu_type1 allow_unsafe_interrupts=1" > /etc/modprobe.d/iommu_unsafe_interrupts.conf

4. Identificar grupos IOMMU

Cada dispositivo pertenece a un IOMMU group. Para passthrough, hay que garantizar un grupo dedicado para los dispositivos a entregar. La página de hardware de Proxmox lista los grupos desde el panel web, o desde la CLI:

pvesh get /nodes/<nombre-nodo>/hardware/pci --pci-class-blacklist ""

La salida es una tabla con columnas como class, device, id, iommugroup, vendor y device_name. Si ves una gráfica acompañada de un puerto SATA o un USB, el grupo está mezclado y la GPU no podrá aislarse por completo.

¿Cómo arreglarlo?

1. Cambiar la tarjeta a otra ranura PCIe. Suele ser suficiente porque el topology del chipset segmenta los grupos.
2. Si no funciona, habilitar ACS (Access Control Services) en la BIOS.
3. Último recurso: usar el parche de Alex Williamson que añade pcie_acs_override=downstream al kernel, integrado en el kernel de Proxmox. Úsalo con cuidado porque relaja el aislamiento.

5. Impedir que el host toque la GPU

Cuando la BIOS muestra mensajes por la GPU que queremos entregar, o cuando el kernel intenta cargar un driver gráfico sobre ella, el passthrough falla. La solución estándar es añadir los drivers a la lista negra:

echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
echo "blacklist nvidia*" >> /etc/modprobe.d/blacklist.conf
echo "blacklist amdgpu" >> /etc/modprobe.d/blacklist.conf
echo "blacklist radeon" >> /etc/modprobe.d/blacklist.conf
echo "blacklist i915" >> /etc/modprobe.d/blacklist.conf
update-initramfs -u -k all

Tras blacklisting, el driver del host deja de reclamar el dispositivo y queda libre para vfio-pci. Tras esto hay que reiniciar.

6. Crear la VM y asignarle el dispositivo

Proxmox permite hacerlo desde la GUI o por CLI. La opción más cómoda es la GUI: editamos la VM, abrimos Hardware → Add → PCI Device y seleccionamos la GPU. Marcar All Functions, Primary GPU (si es la única GPU passthrough) y revisar el PCI-Express si necesitamos más ancho de banda.

Por CLI sería algo similar a:

qm set 101 -hostpci0 01:00,x-vga=on,pcie=1

Si la tarjeta está mezclada con un audio HDMI en el mismo dispositivo, marca también Advanced → Sub-device 0.1.

6.1. BIOS virtual

Para GPUs modernas suele usarse OVMF (UEFI) como BIOS de la VM, seleccionable al crearla o desde Options → BIOS. Proxmox también puede añadir un disco EFI desde Hardware → Add → EFI Disk. Para sistemas invitados antiguos puede dejarse SeaBIOS; la elección depende de la ROM del dispositivo y del sistema operativo.

Algunos chipsets shadow el vBIOS durante el arranque y no dejan pasar la ROM limpia. Si pasa esto, vuelca la ROM en el slot donde sí funciona, guárdala en /usr/share/kvm/vbios.bin y pásala con:

hostpci0: 01:00,x-vga=on,romfile=vbios.bin

7. Riesgos y precauciones

Antes de pasar un dispositivo a una VM conviene tener claras las consecuencias para poder mitigarlas:

Riesgo	Mitigación
Pérdida de acceso al host si la VM monopoliza la única GPU	Mantener una iGPU o usar KVM remoto para gestionar el servidor
Inestabilidad del reset bug en GPUs AMD Navi	Aplicar vendor-reset o planificar reboot entre VMs
VMs no migrables a otro nodo	Limitar el uso de passthrough a cargas donde la migración no aporta valor
Actualizaciones de kernel que rompen binding	Probar el cambio antes en un nodo sin producción
Códigos 43 de Windows con GPUs modernas	Desactivar Resizable BAR en la BIOS como primer paso

Haz backup de la configuración de la VM y de /etc/pve/qemu-server/.conf antes de tocar nada. Si algo sale mal, restaurar ese fichero recupera el estado anterior de inmediato.

8. Troubleshooting habitual

8.1. “BAR 3: can’t reserve [mem]”

Indica que el firmware del host toca una región de memoria de la GPU. Lo desactivamos en la línea del kernel con video=efifb:off. Si la VM ya está creada, edita /etc/pve/qemu-server/.conf o usa el panel web.

8.2. “BAR0 is 0M” o Error 12 en Windows

Aparece en GPUs con mucha VRAM (24 GB o más) porque OVMF reserva 32 GB de espacio MMIO64 por defecto. La solución ordenada por preferencia es:

• Cambiar el tipo de CPU a host en qm set --cpu host.
• Si no puedes, fijar phys-bits=host y la flag +pdpe1gb. Por ejemplo: qm set --cpu x86-64-v2-AES,phys-bits=host,flags=+pdpe1gb.
• Aumentar manualmente la ventana MMIO con qm set --args '-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536' (valores válidos: 65536 = 64 GB, 131072 = 128 GB, 262144 = 256 GB).

8.3. Pantalla en negro con NoVNC/SPICE

Cuando hay GPU passthrough activa, SPICE presenta una tarjeta gráfica “virtual” que a veces interfiere con los drivers reales. Desactivar SPICE en la VM y entrar directamente por HDMI u otro stream del propio dispositivo suele resolver el corte de señal.

8.4. Audio HDMI con glitches

Si notas chasquidos en el audio sobre HDMI, activa MSI:

echo "options snd-hda-intel enable_msi=1" >> /etc/modprobe.d/snd-hda-intel.conf

Para comprobar que MSI está activo usa lspci -vv y busca en el dispositivo una línea Capabilities: [...] MSI: Enable+.

8.5. Código 43 de NVIDIA en Windows

El clásico. Pasos recomendados por la wiki:

1. Probar la GPU en otra ranura o en otra máquina. Si ni siquiera pasa de POST, puede haber hardware fault real.
2. Comprobar los logs de seguridad del invitado y los mensajes del host con dmesg.
3. Volcar otra ROM y probar con romfile=.
4. Apagar Resizable BAR / Smart Access Memory en la BIOS.
5. En GPU móviles o configuraciones poco comunes, buscar una solución específica del modelo antes de alterar IDs del dispositivo; un ID incorrecto puede impedir que el driver cargue.

8.6. GPUs AMD con reset bug

Las Navi 5xxx/6xxx no se resetean al apagar la VM. Si es un modelo afectado y reiniciar el servidor no es opción, instala el vendor-reset (vendor-reset en GitHub) o el parche mantenido por la comunidad que ya integra Proxmox en kernels recientes.

9. Passthrough de otros dispositivos

No solo las GPUs se benefician de esta técnica. Las NICs Intel i350 o Mellanox ConnectX pasan enteros a un firewall virtual, que es justamente el siguiente paso de la serie: combinar OPNsense, ZFS y PCI passthrough en el mismo servidor. Si tu objetivo es un homelab con varios servicios, repasa el artículo sobre servicios para correr en casa y planifica qué NICs WAN y LAN vas a dedicar.

Para mapear puertos USB concretos a una VM, Proxmox tiene una herramienta propia: Hardware → USB Device → USB Physical Port Mapping. Sirve para que solo un conector vaya a la VM, no todos los dispositivos conectados al controlador raíz.

Conclusiones

PCI passthrough abre la puerta a VMs con IO y gráfica casi nativas, algo impensable hace pocos años en entornos domésticos. La clave está en preparar el hardware (IOMMU, ACS, BIOS moderna) antes de comprar tarjetas concretas, y en documentar cada cambio: una VM con GPU passthrough sigue siendo un servidor crítico y como tal hay que tratarlo.

No prometas compatibilidad universal: cada modelo de GPU, de placa y de chipset tiene sus quirks. Antes de desplegar nada en producción, valida el flujo completo (instalar la VM, actualizar drivers, apagar y encender varias veces) y ten siempre a mano la receta de recuperación para los códigos de error más frecuentes.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux