You assign a GPU to a Proxmox VM, hit start, and the task bombs out with "IOMMU not present" or a flat refusal to assign the device. Frustrating, but predictable. GPU or drive passthrough failing in Proxmox nearly always traces back to one missing piece: the IOMMU is either switched off in the BIOS or never enabled on the kernel command line.
Quick Answer
Passthrough needs IOMMU active in two places. First, enable VT-d (Intel) or AMD-Vi, usually just labelled IOMMU, in your BIOS, and set it to Enabled rather than Auto. Second, on Intel hosts add intel_iommu=on to the kernel command line. The device must also sit in its own IOMMU group. Confirm it all worked with dmesg | egrep -i 'DMAR|AMD-Vi'.
Step one, the BIOS switch everyone skips
The most common failure is that virtualisation extensions look enabled but IOMMU itself is not. These are two different settings, and motherboard menus love to blur them. VT-x is CPU virtualisation; VT-d is Intel's IOMMU for passing devices through. People enable the first, miss the second, and wonder why the GPU will not assign.
Go into the BIOS and find the IOMMU toggle. On Intel boards it is often labelled VT-d, on AMD boards usually just IOMMU (the underlying tech is AMD-Vi). Set it explicitly to Enabled. Auto is not the same thing and frequently leaves it off. While you are in there, update to the latest BIOS for your board, because IOMMU grouping and passthrough support genuinely improve in later firmware. A well-supported platform from the mini PC and small-system range at Evetech makes this far less painful than fighting an old board.
Step two, the kernel command line
With the BIOS sorted, Proxmox still needs to be told to use IOMMU at boot. On Intel hosts this means adding intel_iommu=on to the kernel command line. It is always required on Intel, even on recent kernels, so do not assume a modern kernel handles it for you.
AMD users have a quirk worth knowing. The flag amd_iommu=on is actually invalid and gets ignored, because IOMMU is already on by default for AMD systems once you enable it in the BIOS. So an AMD host needs the BIOS toggle and usually nothing extra on the command line. After editing, update the bootloader and reboot, then verify with dmesg | egrep -i 'DMAR|AMD-Vi'. Seeing DMAR or AMD-Vi lines means IOMMU is live.
Step three, IOMMU groups
Even with everything enabled, passthrough can still fail if your device shares an IOMMU group with others. Proxmox passes through a whole group at once, so a GPU lumped in with critical host devices will not assign cleanly. Check your groups, and if the GPU is not isolated, a different PCIe slot or a BIOS update that improves grouping often separates it. This is exactly why the latest firmware matters so much for passthrough.
Frequently Asked Questions
What is the most common reason Proxmox passthrough fails?
IOMMU being disabled. Either the BIOS toggle (VT-d or AMD-Vi) is off or set to Auto, or the Intel kernel flag intel_iommu=on is missing. Fixing those two resolves the majority of failures.
Do I need intel_iommu=on on a modern kernel?
Yes. On Intel hosts it is always required, even on current kernels. Do not assume a recent kernel enables it automatically; add the flag to the command line and reboot.
Why does amd_iommu=on not work on my AMD system?
Because it is invalid and ignored. AMD enables IOMMU by default once you switch it on in the BIOS, so you usually need only the BIOS toggle and no extra kernel flag.
How do I confirm IOMMU is actually enabled?
Run dmesg | egrep -i 'DMAR|AMD-Vi' after rebooting. Lines mentioning DMAR (Intel) or AMD-Vi mean IOMMU is active. No output means it is still off somewhere.
My GPU still will not pass through after enabling IOMMU. Now what?
Check its IOMMU group. Proxmox passes a whole group at once, so a GPU grouped with host-critical devices fails. Moving it to another PCIe slot or updating the BIOS often isolates it.
Setting up a homelab that needs clean passthrough? Start with hardware that plays nicely with IOMMU from the mini PC range at Evetech, so virtualisation works the first time rather than after a weekend of BIOS spelunking.