Proxmox GPU Passthrough Guide (2026)

Disclosure: This article contains affiliate links. If you buy through them, HomelabAddiction may earn a commission at no extra cost to you.

Key Takeaways

Proxmox GPU passthrough is easiest when the host keeps an iGPU and the VM gets the discrete GPU.
On modern Proxmox installs, you need to know whether you are using GRUB or systemd-boot before touching kernel parameters.
Most failures come from three boring problems: bad IOMMU grouping, the host binding the GPU before VFIO does, or a guest VM config that is almost right.
NVIDIA still creates more drama than AMD or Intel for passthrough, even if the situation is better than it used to be.
ACS override can rescue awful consumer motherboard grouping, but it is not a free lunch and should not be your first move.

After running Proxmox in production for years, I can say this with a straight face: GPU passthrough is not hard because the commands are complicated. It is hard because every guide makes it sound cleaner than it really is.

Most walkthroughs give you a neat checklist, then quietly leave you alone with a black screen, a VM that sees the GPU but refuses to load drivers, or a host that just stole the card back on boot (which is always a fun way to spend a Sunday). I have done all three.

This is the version I wish I had the first time. Not the "copy these six commands and good luck" version. The version that tells you which hardware path is least annoying, how to verify each layer before moving on, and when to stop pasting magic flags from forum threads.

If you are still planning the rest of your Proxmox build, read my guide to the best mini PCs for Proxmox first. If your host storage is still in flux, my Proxmox ZFS setup guide will save you some future regret.

What GPU passthrough is actually good for

In a homelab, GPU passthrough makes sense when a VM needs real hardware acceleration instead of whatever fake video adapter QEMU gives it.

That usually means one of four jobs:

1. A Windows VM for gaming or CAD.

2. A Linux VM for AI workloads, CUDA, or local inference.

3. A media VM doing hardware transcoding.

4. A workstation VM you want to feel close to bare metal.

If you just want Plex or Jellyfin transcoding, I would seriously consider whether full VM passthrough is overkill. Sometimes an LXC container with an iGPU or direct device mapping is enough. Sometimes the clever answer is just the complicated answer wearing a fake mustache.

Choose the least painful hardware path first

This matters more than any kernel flag.

Best path: iGPU for the host, discrete GPU for the guest

This is the cleanest setup by far.

The Proxmox host keeps local console output through integrated graphics, while the VM gets the dedicated card. You still manage the host through the web UI and SSH, but you are not one boot mistake away from blind recovery.

If I were building for passthrough today, I would still favor a CPU with usable integrated graphics for exactly this reason.

Acceptable path: headless host, discrete GPU for the guest

This works fine if you are comfortable treating the Proxmox host like a headless server.

Just be honest with yourself before you start. If you rely on plugging a monitor into the box every time something goes sideways, this path is going to teach you new vocabulary.

Worst path: one GPU expected to serve host and guest cleanly

You can find threads where people try to make this work elegantly.

You can also find people rebuilding initramfs at 2 AM because it did not work elegantly. I do not recommend starting here unless you enjoy avoidable suffering.

Before you touch Proxmox, check the BIOS

You need these features enabled:

Intel VT-d or AMD-Vi / IOMMU
CPU virtualization support (VT-x or SVM)
Above 4G Decoding enabled
CSM disabled if your hardware behaves with pure UEFI

Resizable BAR can also complicate passthrough on some combinations of hardware, firmware, and guest drivers.

If you get weird BAR allocation errors later, disable ReBAR first before you start rewriting half your config. It is one of those settings that feels modern and helpful right until it is not.

Figure out your bootloader before editing kernel parameters

This is the first place many guides get lazy.

Some Proxmox hosts use GRUB. Others use systemd-boot, especially on newer installs. If you edit the wrong place, nothing changes, you reboot confidently, and the machine ignores you with impressive professionalism.

Check what you are using

bootctl status

If bootctl shows active entries, you are likely on systemd-boot.

If not, GRUB may be the path. On many systems, checking whether /etc/kernel/cmdline exists is also a useful clue.

Enable IOMMU on the host

If you are using GRUB

Edit /etc/default/grub.

For Intel:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

For AMD:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

Then apply it:

update-grub\nreboot

If you are using systemd-boot

Edit /etc/kernel/cmdline and append the correct IOMMU flags to the existing line.

Intel:

intel_iommu=on iommu=pt

AMD:

amd_iommu=on iommu=pt

Then refresh the boot entries and reboot:

proxmox-boot-tool refresh\nreboot

Verify it actually worked

After the host comes back:

dmesg | grep -E 'DMAR|IOMMU|AMD-Vi'

On Intel, you want to see something like DMAR: IOMMU enabled.

On AMD, you want AMD-Vi messages showing the IOMMU came up correctly.

Also verify interrupt remapping:

dmesg | grep remapping

If interrupt remapping is missing, passthrough is already on shaky ground.

Load VFIO modules

Add the required modules to /etc/modules:

vfio\nvfio_iommu_type1\nvfio_pci

Then rebuild initramfs and reboot:

update-initramfs -u -k all\nreboot

Some older guides still tell you to add vfio_virqfd. On newer kernels, that advice is often stale. This is why blindly following old passthrough posts is a hobby inside the hobby.

Check IOMMU groups before you do anything clever

This is the checkpoint that tells you whether your motherboard is going to behave like a grown-up.

Run:

for d in /sys/kernel/iommu_groups/*/devices/*; do\n  g=${d#*/iommu_groups/*}\n  g=${g%%/*}\n  echo "IOMMU Group $g"\n  lspci -nns "${d##*/}"\n  echo\n done

You want the GPU and its audio function grouped together, ideally without a pile of unrelated junk attached.

A healthy example looks something like this:

IOMMU Group 17\n01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:xxxx]\n01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:yyyy]

The mistake I made

On one consumer board, I saw the GPU grouped with a USB controller and a SATA controller. My first instinct was to jump straight to ACS override because the internet told me it was fine.

It was not fine. It was merely available.

When to use ACS override

If your grouping is bad and you have exhausted firmware updates, BIOS options, and slot changes, ACS override can help:

pcie_acs_override=downstream,multifunction

But treat it as a workaround, not as best practice.

It weakens isolation. For a lab, you may accept that tradeoff. For anything you pretend is production, think twice.

Identify the GPU and audio device IDs

List your PCI devices:

lspci -nn | grep -Ei 'vga|3d|display|audio'

You are looking for both the GPU and its companion audio function.

Example:

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117 [10de:1fb2]\n01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10fa]

Those bracketed IDs are what you bind to VFIO.

Bind the GPU to VFIO before the host grabs it

Create /etc/modprobe.d/vfio.conf:

options vfio-pci ids=10de:1fb2,10de:10fa disable_vga=1

Replace those IDs with your own.

If the host is still grabbing the card, blacklist the native drivers.

For NVIDIA, that often means:

blacklist nouveau

For AMD, you may need to keep the host from binding amdgpu if the card is supposed to belong exclusively to the guest.

Then rebuild initramfs and reboot again:

update-initramfs -u -k all\nreboot

Verify VFIO owns the device:

lspci -nnk -d 10de:1fb2

You want to see:

Kernel driver in use: vfio-pci

If you still see nouveau, nvidia, or amdgpu, stop there. Do not move on to VM configuration yet. Passthrough fails fast when the host never actually gave up the card.

Build the VM with settings that do not sabotage you

Use these defaults unless you have a reason not to:

Machine: q35
BIOS: OVMF (UEFI)
CPU type: host
Display: none or a non-primary virtual adapter if the passthrough GPU is the real display target
Memory ballooning: disabled for consistency

In the Proxmox UI, add the GPU as a PCI Device and pass all functions if the GPU audio device is paired with it.

If you prefer editing the config directly, the VM file at /etc/pve/qemu-server/VMID.conf ends up looking roughly like this:

bios: ovmf\nmachine: q35\ncpu: host\nhostpci0: 0000:01:00,pcie=1,x-vga=1

For some cards, you may also need a second passthrough line for the audio function if you are not using the all-functions toggle.

If the passthrough GPU is supposed to be the guest's main display, set the VM display thoughtfully. A lot of "black screen" reports are just the guest output going to the physical GPU while the admin keeps staring at noVNC like it personally offended them.

Windows guest notes

Windows is still the path where most people notice passthrough first, because it is the path where a broken driver setup complains loudly.

If you are building a Windows VM:

Use OVMF.
Keep the VM on q35.
Install VirtIO drivers.
Expect the real output to appear on the passed-through GPU, not in noVNC.

NVIDIA and Error 43

This is less common than it used to be on newer drivers, but it still shows up often enough to deserve its own paragraph.

If the guest sees the card but the NVIDIA driver throws Error 43, the first things I check are:

whether the host really bound the card to vfio-pci,
whether the VM is using q35 and OVMF,
whether the GPU audio function was included,
whether the card needs a cleaner UEFI path or a ROM file,
whether someone copied an old workaround that no longer applies.

On stubborn setups, hiding the hypervisor can still help, but I do not start there anymore. The boring checks fail more often than the exotic ones.

Code 12 and BAR errors

If you see Code 12 or BAR allocation issues, look at these in order:

1. Above 4G Decoding in BIOS

2. ReBAR disabled

3. OVMF in the guest

4. clean q35 machine type

5. whether the motherboard firmware is ancient and unhelpful

Linux guest notes

Linux guests are often less theatrical than Windows, which I appreciate.

You still need correct driver support inside the guest, but once VFIO ownership and VM config are right, Linux tends to make its complaints in a more readable tone.

For compute workloads, I usually verify from inside the VM with something basic first:

lspci -nn

Then vendor tooling:

nvidia-smi

or, for Intel and AMD stacks, the appropriate driver and render-node checks.

Homelab realities most guides skip

This part matters more than people admit.

Passthrough and high availability do not mix well

If a VM has a physical GPU attached, your life gets less portable.

Live migration is no longer the easy button. HA expectations need to be adjusted accordingly. If that is new territory, read my Proxmox cluster setup guide before you promise yourself features the hardware cannot deliver.

Backups still matter, even if the workload is "special"

A passed-through GPU does not make the VM sacred. It just makes the restore plan more specific.

Back up the VM like you actually expect a disk to fail someday. My full approach is in Proxmox backup strategies.

Networking still matters

If the guest is doing streaming, AI, or remote desktop, network bottlenecks become much more visible once the GPU side is fast.

If your bridges, VLANs, and firewall rules are still improvised, fix that too. My write-ups on Proxmox networking and homelab firewall rules pair well with this one.

Troubleshooting checklist in the order I actually use

When passthrough fails, I go through this exact order:

1. Did BIOS settings stick? Check VT-d / AMD-Vi and Above 4G again.

2. Did the kernel parameters apply? Verify with dmesg.

3. Are IOMMU groups usable? If not, stop and solve that first.

4. Did VFIO actually claim the GPU? Confirm with lspci -nnk.

5. Is the VM using q35 + OVMF + host CPU? Fix the obvious config mismatches.

6. Did I pass the audio function too? Forgetting this is very common.

7. Am I looking at the wrong display? Use the physical GPU output if it is the primary guest display.

8. Only then do I start chasing vendor quirks, ROM files, or hidden hypervisor flags.

That order sounds unglamorous because it is unglamorous. It also saves a lot of wasted time.

Recommended gear if you are building around passthrough

You do not need any of this to make passthrough work, but these are the kinds of parts I recommend because they reduce friction instead of adding it.

Intel Core i5-14500 - a very practical host CPU if you want the Proxmox host on the iGPU and the VM on a discrete card: check price on Amazon
Intel Arc A380 - a decent low-power option for media or lab workloads where AV1 support and modern transcode capability matter: check price on Amazon
NVIDIA T400 - still one of the least ridiculous low-profile cards for compact homelab builds and light workstation use: check price on Amazon

I am not saying these are the only sensible choices. I am saying they tend to create fewer weird side quests than whatever random eBay special people found after reading one too many forum success stories.

The official docs you should keep open

Even if you follow this guide, keep the vendor references nearby:

Those are where I go when I need exact wording on an error, not when I want life advice.

Final verdict

GPU passthrough on Proxmox is absolutely worth doing when the workload genuinely needs direct hardware access.

But it rewards clean planning more than brute-force troubleshooting. If you pick the right hardware path, verify every layer, and resist the urge to throw ACS override and mystery flags at the problem too early, it becomes very manageable.

If you do the opposite, it becomes one of those projects where you technically learn a lot but mostly about your own decision-making.

Frequently Asked Questions

Do I need a second GPU for Proxmox GPU passthrough?

No. You can run a single-GPU setup and manage the host headlessly through the Proxmox web UI and SSH. That said, the cleanest setup is still host on iGPU, guest on discrete GPU. It reduces recovery pain when something goes wrong.

Should I use GRUB or /etc/kernel/cmdline on Proxmox?

Use whichever matches your actual bootloader. GRUB installs use /etc/default/grub plus update-grub. Many modern Proxmox installs use systemd-boot, which means editing /etc/kernel/cmdline and then running proxmox-boot-tool refresh.

What causes NVIDIA Error 43 in a passthrough VM?

Usually one of the boring problems: the host never fully handed the GPU to VFIO, the VM is not using q35 and OVMF correctly, or the audio function was skipped. I only reach for older hypervisor-hiding tricks after those checks are clean.

When should I use pcie_acs_override?

Only when your motherboard's IOMMU grouping is genuinely unusable and you have already tried safer fixes. ACS override can help split groups, but it comes with weaker isolation and should not be your default answer.

Is GPU passthrough a good fit for Plex, Jellyfin, or AI workloads?

Yes, but not always in the same way. For AI and workstation VMs, full passthrough makes obvious sense. For media transcoding, you should compare full passthrough with lighter-weight options like container device mapping or iGPU-based acceleration before choosing the more complex path.