How to Enable IOMMU (VT-d / AMD-Vi) in Your BIOS and Proxmox VE for PCI Passthrough

If you've tried to pass a GPU or a network card through to a virtual machine in Proxmox VE, you've probably run into this message somewhere in your logs: "IOMMU not found" or "No IOMMU detected, please activate it." It's one of the most common walls new Proxmox users hit, and it trips people up because the fix lives in two different places at once — your motherboard's BIOS and Proxmox's own boot configuration.

This guide walks through both halves. We'll enable the right setting in your BIOS, edit the correct kernel command line for your bootloader, load the modules Proxmox needs, and confirm everything actually turned on before you go build anything on top of it. None of this is hard once you know where to look — it's just scattered.

What You Will Learn

• What IOMMU, VT-d, and AMD-Vi actually mean, and why they're not optional for passthrough
• How to turn on the right BIOS setting on Intel and AMD systems
• How to tell whether your Proxmox install boots with GRUB or systemd-boot, and edit the kernel command line for each
• Which kernel modules to load, and how to confirm IOMMU is really active
• How to read IOMMU groups so you know what you can actually pass through
• What to do when it still doesn't work

What Is This Feature?

IOMMU stands for Input-Output Memory Management Unit. Think of it as a bouncer that sits between your physical hardware (a GPU, a NIC, a USB controller) and your computer's memory. Normally, when you hand a piece of hardware directly to a virtual machine, that hardware could — in theory — read or write to any part of system memory, including memory that belongs to your Proxmox host or to other VMs. The IOMMU boxes each device into its own protected memory region, so a passed-through device can only touch the memory it's actually supposed to.

Intel calls its implementation VT-d (Virtualization Technology for Directed I/O). AMD calls theirs AMD-Vi. They do the same job, they just come from different vendors, and you'll see both names used depending on your BIOS and your CPU.

Don't confuse this with VT-x or AMD-V (sometimes shown as "SVM Mode" in BIOS). Those are the base CPU virtualization extensions that make any VM possible at all — Proxmox already needs those just to boot a virtual machine, passthrough or not. IOMMU/VT-d/AMD-Vi is a separate, additional feature that's only required when you want a VM to talk to real hardware directly instead of through Proxmox's emulated devices.

Why Would You Use It?

The most common reason homelab users end up here is GPU passthrough — giving a Windows VM full access to a graphics card for gaming, or handing a dedicated GPU to a VM running Plex or Jellyfin for hardware transcoding. Right behind that is passing through a whole network card so a firewall VM like pfSense or OPNsense gets direct access to a physical port instead of a virtual bridge.

There's a real performance argument here too. Emulated or even virtio devices add a layer of translation between the guest and the hardware. A passed-through device skips that layer entirely — the VM talks to the silicon almost as if it were bare metal. For a GPU doing video encoding or a 10-gigabit NIC pushing serious traffic, that difference is noticeable.

If none of that describes what you're doing, you honestly don't need this. Most homelab VMs run perfectly fine on Proxmox's default virtio devices, and enabling IOMMU with no plan to use it doesn't buy you anything.

Prerequisites

• A CPU and motherboard that actually support VT-d or AMD-Vi — check your CPU model on Intel ARK or AMD's spec pages if you're not sure, since some budget/low-end SKUs leave it out entirely
• Proxmox VE already installed (this guide assumes 8.x or 9.x)
• Root shell access to the host, either via SSH or the built-in web console
• A way to get into your system's BIOS/UEFI setup screen (usually Del, F2, or F10 at boot — check your motherboard manual)
• Roughly 10 minutes and one reboot

Step-by-Step Tutorial

Step 1: Enable the setting in BIOS

Reboot the physical host and enter BIOS setup. The exact menu location depends entirely on your motherboard vendor, but you're looking for one of these labels:

• Intel systems: "VT-d", "Intel VT for Directed I/O", or occasionally just "IOMMU" — usually under Advanced > CPU Configuration or Advanced > Chipset
• AMD systems: "IOMMU" or "AMD-Vi" — often under Advanced > AMD CBS > NBIO, or sometimes right next to "SVM Mode"

Set it to Enabled, save, and reboot. On modern AMD boards, IOMMU is frequently on by default — but it's still worth checking, since some vendors ship it off out of the box.

Step 2: Check which bootloader you're using

Proxmox VE boots one of two ways depending on how it was installed — GRUB, or systemd-boot managed through proxmox-boot-tool. You need to know which one before you touch the kernel command line, because they use different files. Run:

efibootmgr -v

Look at the boot entry paths. If you see File(\EFI\proxmox\grubx64.efi) or a shim path, you're on GRUB. If you see File(\EFI\systemd\systemd-bootx64.efi), you're on systemd-boot. If efibootmgr errors out because EFI variables aren't available, you're running legacy BIOS boot with GRUB. You can also cross-check with:

proxmox-boot-tool status

Step 3: Add the kernel parameter

For GRUB, edit /etc/default/grub and find the GRUB_CMDLINE_LINUX_DEFAULT line. Add the parameter for your CPU vendor:

# Intel
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

# AMD
GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt"

Then apply it:

update-grub

For systemd-boot, the file is different — you edit /etc/kernel/cmdline directly, and it holds the entire command line as one plain line (no quotes, no variable name):

root=ZFS=rpool/ROOT/pve-1 boot=zfs intel_iommu=on iommu=pt

Keep whatever was already in that file (your root= and boot= settings) and just append the IOMMU flags. Then run:

proxmox-boot-tool refresh

A quick note on kernels: Proxmox VE 8.2 and later ship kernel 6.8 or newer, and on those kernels Intel systems often enable IOMMU automatically without intel_iommu=on. Setting it explicitly anyway doesn't hurt and saves you from guessing whether your specific kernel build turned it on by default. AMD IOMMU has been on by default for even longer.

The iommu=pt flag is a performance option — it tells the kernel to use passthrough mode for devices that aren't being passed to a VM, so your host doesn't pay the IOMMU translation cost for hardware it's using directly. It's safe to include and generally recommended.

Step 4: Load the VFIO modules

VFIO is the framework that actually lets a device be handed to a VM instead of the host kernel. Add these lines to /etc/modules:

vfio
vfio_iommu_type1
vfio_pci

Then rebuild your initramfs so the modules load early enough at boot:

update-initramfs -u -k all

Step 5: Reboot and verify

Reboot the host. Once it's back up, check that the modules loaded:

lsmod | grep vfio

You should see vfio, vfio_iommu_type1, and vfio_pci in the output. Next, confirm IOMMU is actually active at the hardware level:

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

On Intel you're looking for a line like "DMAR: IOMMU enabled." On AMD it'll mention AMD-Vi directly. If this comes back empty, IOMMU isn't on yet — go back and double-check the BIOS setting and the kernel parameter.

Step 6: Check your IOMMU groups

Devices don't get passed through individually — they get passed through by IOMMU group, and everything sharing a group has to go to the same VM (or stay on the host). List your groups with:

for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/*}; n=${n%%/*}
  printf 'IOMMU group %s ' "$n"
  lspci -nns "${d##*/}"
done

This is the part that catches people off guard. On some consumer boards, your GPU and its onboard audio device land in the same group as an unrelated USB controller or PCIe bridge — meaning you'd have to pass through all of it or none of it. Desktop boards with good IOMMU grouping (most modern Intel and AMD boards) usually split this cleanly; some cheaper or older boards don't.

Commands Explained

Command	What it does
efibootmgr -v	Shows your EFI boot entries so you can identify GRUB vs systemd-boot
update-grub	Regenerates the GRUB config from /etc/default/grub; also triggers proxmox-boot-tool refresh automatically on Proxmox
proxmox-boot-tool refresh	Rewrites the boot entries on every configured ESP (EFI System Partition) for systemd-boot installs
update-initramfs -u -k all	Rebuilds the initial ramdisk for every installed kernel so new modules load at boot time
lsmod | grep vfio	Confirms the VFIO kernel modules are actually loaded
dmesg | grep -e DMAR -e IOMMU -e AMD-Vi	Pulls the boot-time kernel messages that confirm IOMMU initialized

Common Errors

"IOMMU not found. Please activate in BIOS." This is the error Proxmox throws when you try to add a PCI device to a VM and the kernel never saw an active IOMMU. Nine times out of ten it's one of two things: the BIOS setting is still off, or you edited the wrong bootloader file (GRUB when you're actually on systemd-boot, or vice versa).

Group has multiple devices you didn't expect. Not really an "error" — this is normal on many boards. It only becomes a blocker if the group mixes a device you want to pass through with one the host still needs, like the boot drive's SATA controller.

Kernel parameter looks right but dmesg shows nothing. Usually means the initramfs wasn't rebuilt, or the wrong ESP got updated on a systemd-boot system with multiple boot partitions. Re-run proxmox-boot-tool refresh and check proxmox-boot-tool status to confirm all ESPs are in sync.

Troubleshooting

Start by re-verifying the basics in order, because it's almost always one of these three things. First, go back into BIOS and confirm the setting actually saved — some boards silently revert changes if you exit without a proper save, especially after a firmware update. Second, re-run efibootmgr -v to make sure you edited the file that matches your actual bootloader; editing /etc/default/grub on a systemd-boot system does nothing at all. Third, check cat /proc/cmdline after reboot — this shows you the kernel command line the running system actually booted with, which tells you immediately whether your parameter made it through.

If /proc/cmdline shows your flag but dmesg still shows nothing, the CPU or motherboard genuinely may not support it, or it's disabled at a level BIOS doesn't expose (this happens on a few OEM/prebuilt desktop boards). At that point, checking your exact CPU model against the vendor's ARK/spec sheet is worth five minutes before you keep troubleshooting software that's working correctly against hardware that isn't cooperating.

One more thing worth checking: some older Intel boards need "VT-d" enabled at a top BIOS menu level in addition to a duplicate toggle buried in chipset settings. If your board has both, they both need to say Enabled.

Best Practices

Only enable iommu=pt once you've confirmed base IOMMU is working — add one thing at a time so you know which change fixed (or broke) something. Keep a note of your exact BIOS menu path once you find it; motherboard BIOS menus are inconsistent enough between vendors that you'll thank yourself the next time you reinstall or update firmware.

Before you commit to a passthrough plan, run the IOMMU group listing first and actually read it. It's much less frustrating to discover your GPU shares a group with your motherboard's USB controller before you've built a VM around the assumption that it won't.

Snapshot or back up your Proxmox host configuration before making bootloader changes. It's a low-risk edit, but a mistyped kernel parameter can occasionally leave a system that won't boot cleanly, and having a way back saves a bad night.

Frequently Asked Questions

Do I need IOMMU for every VM?

No. Only VMs using PCI passthrough (a GPU, NIC, or other physical device handed directly to the VM) need it. Regular VMs using Proxmox's built-in virtio disk and network devices don't touch IOMMU at all.

My CPU supports VT-d but I don't see the option in BIOS. What now?

Some motherboard vendors don't expose every feature their chipset supports, especially on budget boards. Check for a BIOS update first — vendors sometimes add the option in a later firmware revision. If it's genuinely missing, that board just won't support passthrough.

Is enabling IOMMU risky for a system that's already running VMs?

It's a low-risk change and doesn't affect existing VMs that aren't using passthrough. The main risk is a bootloader typo, which is why double-checking your GRUB vs systemd-boot file before editing matters.

Why does AMD-Vi seem to already be on by default?

AMD has shipped IOMMU support enabled by default in the kernel for longer than Intel has. You still need the BIOS setting on, but you may not need an explicit kernel flag the way Intel systems historically did.

Can I use this with an unprivileged LXC container instead of a VM?

PCI passthrough in the sense covered here is a VM feature. LXC containers can access some devices differently (through device passthrough into the container's namespace), which is a separate mechanism and worth its own guide.

Conclusion

Getting IOMMU turned on is really two small edits and a reboot — the confusing part is just knowing which file to touch and which BIOS label to look for on your specific board. Once dmesg confirms it's active and you've read through your IOMMU groups, you're in a good position to actually start passing devices to a VM, whether that's a GPU for Plex transcoding or a NIC for a firewall VM. Take the group listing seriously before you build anything around it — it's the one step that saves you from planning around hardware that can't be split the way you assumed.