Proxmox GPU Passthrough on PVE 9: Setup and Troubleshooting

  • Post author:Frank Joseph
  • Post published:
  • Post last modified:
  • Post category:Proxmox
  • Reading time:9 mins read

Proxmox GPU passthrough hands a physical PCIe graphics card to one virtual machine, so the VM gets near-native performance and the host stops using the card. On Proxmox VE 9, IOMMU is on by default, so it’s four steps: optionally add iommu=pt to the kernel command line, load three VFIO modules, check your IOMMU groups, and add the GPU to the VM.

Proxmox VE 9.2 (May 21, 2026, kernel 7.0) is current as of October 2026, and the steps below, from Proxmox’s 9.2 wiki, cover Proxmox 9 GPU passthrough on every 9.x release. I passed a ZOTAC GeForce RTX 5070 Ti through to a Windows 11 VM on Proxmox VE 9.1 for my old-PC build video (published May 2026).

How to Set Up Proxmox GPU Passthrough

You’ll need:

  • VT-d (Intel) or AMD-Vi / IOMMU (AMD) enabled in the BIOS.
  • A VM on the q35 machine type (PCIe passthrough is q35 only).
  • Other video output for the host, since a passed-through GPU is gone from the host and every other VM.
  • RDP, VNC or a monitor on the card, because the noVNC console can’t show the GPU’s output.
  • A power supply that can handle the GPU.

The power supply is the big one, and a home server runs 24/7, so don’t skimp. Integrated graphics can help, because then you aren’t passing through the host’s only video source (going into my old-PC build, none of my Proxmox nodes had a dedicated GPU). If you’re new to Proxmox, start with How to Install Proxmox VE.

Step 1: Enable IOMMU in GRUB or systemd-boot

Proxmox’s wiki says IOMMU is on by default on AMD, and on Intel from kernel 6.8, which every PVE 9 kernel is past. So the intel_iommu=on and amd_iommu=on flags most guides list aren’t needed. The only one left is iommu=pt, which the wiki says might increase performance, so this step is optional.

Where it goes depends on your bootloader. Proxmox uses systemd-boot for ZFS-root installs on UEFI without Secure Boot and GRUB for everything else. In the node’s Shell, this tells you which you have:

efibootmgr -v

In the Boot#### line matching BootCurrent, systemd-bootx64.efi means systemd-boot and grubx64.efi or shimx64.efi means GRUB, as does an “EFI variables are not supported” error, even on a ZFS install.

If You’re on GRUB

1. Open the GRUB configuration file.

nano /etc/default/grub

2. Add iommu=pt inside the quotes on the GRUB_CMDLINE_LINUX_DEFAULT line, so a stock one reads:

GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt"

3. Save the file, then update GRUB.

update-grub

That’s the file I edited in the build video, where the stock line on 9.1 was just quiet.

If You’re on systemd-boot

1. Open the kernel command line file.

nano /etc/kernel/cmdline

2. Add iommu=pt to the end of its single line, with a space before it, and save.

3. Apply it to every boot entry.

proxmox-boot-tool refresh

Step 2: Load the VFIO Modules

VFIO lets Proxmox pass a PCIe device through to a VM, and its modules aren’t loaded by default. The wiki now lists three: vfio_virqfd (the fourth line in older guides) was folded into vfio in kernel 6.2.

1. Create the modules file.

nano /etc/modules-load.d/vfio.conf

2. Add these three lines and save it.

vfio
vfio_iommu_type1
vfio_pci

3. Refresh the initramfs, then reboot the host.

update-initramfs -u -k all

4. After the reboot, run both checks.

dmesg | grep -e DMAR -e IOMMU -e AMD-Vi
lsmod | grep vfio

dmesg should report IOMMU, Directed I/O or Interrupt Remapping as enabled, and lsmod should include all three modules. I used /etc/modules in the video, which still works, but on 9.1 that file calls itself obsolete.

Step 3: Check Your IOMMU Groups

When you pass a device through, you’re actually passing its entire IOMMU group, so if your GPU is grouped with other things you care about, that’s a problem.

1. Run the command below and note the GPU’s address (for example, 01:00.0) and IOMMU group, usually two entries: the video device and its HDMI audio.

lspci -v
Older lspci -v output on a Proxmox host listing an NVIDIA Quadro K4200 at 01:00.0 in IOMMU group 16

2. List every group, and check what shares the GPU’s (lspci -s <address> names each one).

find /sys/kernel/iommu_groups/ -type l
IOMMU group listing in a Proxmox shell with the GPU at 01:00.0 and its audio function at 01:00.1 alone in group 16

The GPU sharing a group with its audio function or a PCIe bridge is fine, but anything the host needs is not, and the wiki’s first fix is moving the card to another slot.

Past that, there are workarounds, but I truthfully treat those as last resorts. The usual one is pcie_acs_override=downstream,multifunction, a patch the Proxmox kernel carries. Add it to the kernel command line as in Step 1, reboot, and re-run the group listing. The patch’s own text says it makes the kernel assume ACS support, and without real ACS, peer-to-peer DMA can bypass IOMMU isolation. The allow_unsafe_interrupts=1 option older guides add doesn’t split groups at all, and the wiki warns it can make your system unstable. Security guidance changes, so nothing here is guaranteed.

Step 4: Add the GPU to the VM

Set the VM to q35, OVMF (UEFI) and CPU type host, as mine was. The wiki says q35, OVMF and PCI-Express give the best compatibility, and to use SeaBIOS if your GPU has no UEFI-capable ROM. Leave ballooning on, which Proxmox’s admin guide recommends. Turn on RDP before adding the card (How to Install Windows 11 on Proxmox covers the VM itself).

Older Proxmox VM Hardware tab with 16 GiB of memory, OVMF (UEFI) BIOS, the q35 machine type and a VirtIO SCSI controller

1. Select the VM, then Hardware, then Add, and finally, PCI Device.

2. Select Raw Device, then pick your GPU under Device.

3. Tick All Functions so its HDMI audio goes with it.

4. Tick Advanced, then PCI-Express, and leave ROM-Bar on.

5. Tick Primary GPU only if the card should be the VM’s main display (Proxmox then ignores the VM’s own display setting).

6. Select Add, start the VM and install the GPU driver in the guest.

For my build I used Raw Device with All Functions and Primary GPU ticked and PCI-Express left off, and Windows Task Manager showed the RTX 5070 Ti. The plan for that VM was remote video editing with real GPU acceleration.

This is plain Proxmox PCI passthrough, so it works for an HBA too (passing an HBA through to TrueNAS on Proxmox), and USB devices and single disks have simpler routes.

Resource Mappings on a Cluster

Mapped Device is for clusters. A named mapping means HA won’t start the guest with the wrong device on another node, and Proxmox can detect hardware changes.

1. Select Datacenter, then Resource Mappings, and select Add in the PCI Devices panel.

2. Enter a Name, pick the node under Mapping on Node, tick the GPU’s Pass through all functions as one device row under Device, and select Create.

3. For each other node with the same GPU, select the + (Add new host mapping) in the mapping’s Actions column and repeat step 2’s choices.

4. In the VM’s Add: PCI Device dialog, choose Mapped Device, pick the mapping and carry on from Advanced above.

Live Migration Capable is experimental and, per Proxmox, only known to work on NVIDIA GPUs with a recent kernel.

NVIDIA, AMD and Intel iGPU Passthrough

For Proxmox NVIDIA GPU passthrough, NVIDIA says it has supported GeForce passthrough to a Windows VM since its R465 driver in 2021 (as a beta, one VM per GPU). The hidden=1 Error 43 workaround in older guides predates that. I went with NVIDIA because I’ve had good luck with NVIDIA GPUs for passthrough in the past.

On AMD, vendor-reset is for cards that need a vendor-specific reset sequence. It’s a community kernel module, not in Proxmox’s docs, covering Polaris 10/11/12, Vega 10/20 and Navi 10/12/14.

Proxmox iGPU passthrough works like any other PCI device on q35, and the host loses that output. On 5th to 7th gen Intel Core, GVT-g can split the iGPU instead, and newer chips with SR-IOV usually mean the community i915-sriov-dkms module, which isn’t affiliated with Intel and calls itself highly experimental.

Proxmox GPU Passthrough Not Working? Troubleshooting

If it doesn’t work on the first try, that’s when you’d come back and blacklist host drivers, but I treat that as a troubleshooting step and not a required step. For GPU passthrough, Proxmox tries to take the device from the host, and these are the wiki’s fixes when it can’t.

1. After starting the VM, check the GPU’s Kernel driver in use line, which should say vfio-pci, not nvidia, nouveau or amdgpu.

lspci -nnk

2. If it doesn’t, bind the GPU and its audio function by the [vendor:device] IDs step 1 printed, replacing both examples.

echo "options vfio-pci ids=1234:5678,4321:8765" > /etc/modprobe.d/vfio.conf

3. Or blacklist the driver step 1 showed (nouveau here).

echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
Older nano screenshot of /etc/modprobe.d/blacklist.conf on a Proxmox host with blacklist lines for radeon, nouveau and nvidia

4. Either way, refresh the initramfs and reboot.

update-initramfs -u -k all

If the host still grabs it, add softdep <driver> pre: vfio-pci to /etc/modprobe.d/<driver>.conf and repeat step 4. If the card is bound but the guest driver won’t install, check the ROM, since OVMF needs a UEFI-capable one. And if it broke after an update, re-run the lspci, dmesg and lsmod checks before changing anything.

Frequently Asked Questions

Can I pass through a GPU to a Linux VM instead of Windows?

Yes. The Proxmox steps are the same, and for compute-only use (CUDA or OpenCL) you don’t need a display or remote desktop.

Can you pass a GPU through to an LXC container instead of a VM?

Not as PCI passthrough. A container gets the GPU’s device nodes through a dev entry, so the host driver keeps the card and Linux containers can share it (LXC vs. virtual machines covers the trade-off). I used a VM because GPU passthrough to an LXC container, while possible, can cause a lot more problems, and for Windows or strong isolation, a VM is the one to use.

Frank Joseph

I'm Frank, founder of WunderTech. I've been working in enterprise IT for 15+ years and running home labs for nearly a decade — every tutorial on this site is tested on hardware I actually own, including Synology NAS units, a DIY TrueNAS server, a Proxmox cluster, a full UniFi network, and more. I hold a BS in Computer Information Systems and an MBA, but most of what you'll read here comes from my home lab, not a classroom. You can also find video versions of these tutorials on my YouTube channel.