If you're running a storage-focused VM inside Proxmox VE — TrueNAS Scale, Unraid, a ZFS-on-root NAS build, or anything else that wants to manage disks directly — putting that VM's storage behind Proxmox's own virtual disk layer is usually the wrong call. Virtual disks add a translation layer between the guest and the physical drive, and storage operating systems like TrueNAS specifically want raw, unmediated access to the underlying device so their own filesystem (ZFS, in TrueNAS's case) can see real SMART data, issue TRIM commands correctly, and make its own decisions about caching and redundancy. The fix is to hand the VM the physical NVMe drive directly, bypassing Proxmox's storage stack entirely.
There are two ways to do this, and picking the right one matters. PCIe passthrough (via VFIO) gives the VM the entire NVMe controller, as if it were plugged into the guest directly — the guest sees the real vendor, model, and SMART data, and can issue low-level commands the host never touches. Raw disk passthrough is a lighter-weight alternative that hands the VM a block device without dedicating an entire PCIe function to it, at the cost of some of that transparency. This guide walks through both, plus the IOMMU setup, driver binding, and hardware quirks that catch people out the first time they try this.
What You Will Learn
- The difference between PCIe (VFIO) passthrough and raw disk passthrough for NVMe drives, and when to use each
- How to enable and verify IOMMU support on Intel and AMD hosts
- How to identify IOMMU groups and confirm your NVMe drive can be isolated safely
- How to bind an NVMe device to the
vfio-pcidriver without accidentally grabbing your boot drive - How to attach the device to a VM through the web UI and the command line
- How to set up raw disk passthrough as a simpler alternative
- Performance tuning options and verification steps inside the guest
- Common failure modes — device reset bugs, shared IOMMU groups, and why passthrough disables live migration
Prerequisites
- A Proxmox VE 8.x or 9.x host with a CPU and motherboard that support IOMMU (Intel VT-d or AMD-Vi) — most desktop and server boards from the last decade qualify, but budget consumer boards sometimes disable it in firmware
- A dedicated NVMe SSD that is not your Proxmox boot drive and does not hold any data you need the host to see directly
- Root or SSH access to the Proxmox host
- Comfort editing bootloader configuration and rebooting the host at least twice
- A VM already created (or ready to create) to receive the device — Proxmox VE 8.x/9.x, machine type
q35recommended for PCIe passthrough
PCIe Passthrough vs. Raw Disk Passthrough
Before touching any configuration, decide which method fits your situation:
| Method | Guest sees | Requires IOMMU | Live migration | Best for |
|---|---|---|---|---|
| PCIe (VFIO) passthrough | Real vendor, model, firmware, SMART data | Yes | No | TrueNAS/Unraid VMs that need genuine disk identity and full command set |
| Raw disk passthrough | A generic virtio/SCSI block device | No | No (disk is host-local) | Simpler setups where you just want a physical disk's raw bytes handed to a VM |
If you're building a TrueNAS or Unraid VM specifically because you want ZFS or the array controller to interact with the physical drive the way it would on bare metal — including reading real SMART attributes for early failure warnings — PCIe passthrough is the correct choice. If you just want a VM to own a spare drive's storage without caring whether the guest sees the real controller identity, raw disk passthrough is faster to set up and doesn't require touching IOMMU groups at all.
Step 1: Enable IOMMU
IOMMU (I/O Memory Management Unit) is what lets the hypervisor safely hand a physical PCIe device to a guest without the guest being able to use DMA to read or write arbitrary host memory. It has to be enabled at three levels: in firmware, in the kernel command line, and (implicitly) via the vfio-pci driver later on.
Enable VT-d / AMD-Vi in Firmware
Reboot into your motherboard's BIOS/UEFI setup and look for a setting called Intel VT-d, AMD-Vi, or sometimes just IOMMU, usually under an "Advanced" or "Chipset" menu. Enable it and save.
Enable IOMMU on the Kernel Command Line
Proxmox VE installs with either GRUB or systemd-boot depending on whether the root filesystem is ZFS. Check which one you have:
efibootmgr -v | grep -i proxmox
ls /sys/firmware/efi 2>/dev/null && echo "UEFI system" || echo "Legacy BIOS"
cat /etc/kernel/cmdline 2>/dev/null && echo "Using systemd-boot" || echo "Likely using GRUB"
If you're using GRUB (the default for ext4/LVM installs), edit /etc/default/grub:
# Intel CPUs
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"
# AMD CPUs
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"
Then apply it:
update-grub
If you're using systemd-boot (common on ZFS-root installs), edit /etc/kernel/cmdline instead and add the same parameters to the existing line, then refresh:
proxmox-boot-tool refresh
The iommu=pt ("passthrough mode") option tells the kernel not to bother with IOMMU translation overhead for devices that stay attached to the host, which is a small but free performance win for everything except the device you're about to hand off.
Load the VFIO Modules
Add the required kernel modules so they load at boot:
cat >> /etc/modules /etc/modprobe.d/vfio.conf /etc/systemd/system/vfio-bind-nvme.service