How to Virtualize TrueNAS SCALE Under Proxmox With an HBA Passed Through (September 2026)?

I run my home lab on a Dell R720 with TrueNAS SCALE virtualized under Proxmox, and the single biggest unlock was passing an LSI HBA through to the VM. In this guide I’ll walk you through how to virtualize TrueNAS SCALE under Proxmox with an HBA passed through, so the VM gets direct control of your physical disks and ZFS behaves exactly like it would on bare metal.

If you’ve been debating whether to run TrueNAS as a separate box or as a VM, you’re not alone. Proxmox gives you snapshots, easy backups, and the ability to host other VMs alongside your NAS. With HBA passthrough, you keep every benefit ZFS offers, including S.M.A.R.T. monitoring and full SMART testing. The setup is technical but completely repeatable once you understand the moving pieces.

Why Virtualize TrueNAS SCALE Under Proxmox With HBA Passthrough?

Virtualizing TrueNAS SCALE under Proxmox with HBA passthrough gives you the best of both worlds. Proxmox handles scheduling, networking, and other VMs while the TrueNAS guest owns the disks directly. This is the approach the Proxmox staff themselves recommend for homelab storage when you need ZFS-grade reliability.

The most common alternative is “disk passthrough,” where you add individual SATA disks to the VM one at a time. It works, but you lose ZFS’s ability to manage the controller, monitor S.M.A.R.T. data uniformly, and handle multipath or hot-swap cleanly. HBA passthrough hands the entire controller to TrueNAS, so the NAS sees raw disks and builds pools the way it was designed to.

Two reasons I prefer this setup in 2026:

• I can snapshot other VMs freely without worrying about ZFS transaction groups on the host.

• I can reboot TrueNAS for updates without taking down the rest of my lab.

You only need an extra PCIe slot for the HBA and a CPU/motherboard that supports IOMMU. Most servers from the last decade do, and most modern desktop boards do too.

Hardware Requirements and Prerequisites

Before you start touching config files, confirm your hardware is up to the job. Skipping this step is the most common cause of boot loops and unstable VMs later on.

CPU and Motherboard

You need an IOMMU-compatible CPU and chipset. On Intel, look for VT-d support. On AMD, look for AMD-Vi. Server chips such as Xeon E5 v2/v3 and consumer chips like Ryzen generally work, but cheap boards sometimes disable IOMMU in the BIOS even when the CPU supports it.

RAM and Boot Disk

TrueNAS SCALE needs at least 16 GB of RAM for ZFS to be comfortable, more if you plan to run dedup. The boot disk for the TrueNAS VM should be a virtual disk on Proxmox storage (ZFS pool, thin LVM, or directory), not on the HBA you’re passing through.

The HBA Card

LSI HBAs (now sold under Broadcom) are the workhorses of this community. Cards like the LSI 9211-8i, H310, H710, and HBA2304 are common. For Proxmox HBA passthrough, you want the card flashed into IT mode (Initiator Target), not IR mode. IT mode presents raw disks to the OS without any RAID interference, which is what ZFS expects.

Drives connected to the HBA should be physically separate from the drives Proxmox boots from. Mixing boot and pool disks on the same controller creates confusion during PCI passthrough because the host loses access to disks it may still need.

Enabling IOMMU in Proxmox BIOS and GRUB

IOMMU is the hardware feature that lets the CPU safely hand a PCIe device to a VM. Without it, PCI passthrough simply will not work. The configuration has two halves: BIOS settings and GRUB kernel parameters.

BIOS Settings to Enable

Reboot your server and enter the BIOS. Look for these settings and turn them on:

• Intel VT-d or AMD-Vi (varies by platform)

• SRIOV if listed (not required but harmless)

• Above 4G Decoding / Large BAR support

• IOMMU (sometimes listed under “System Security” or “Virtualization”)

On Dell servers, IOMMU lives under System Security → Virtualization. On HPE, look in RBSU under Virtualization Options. Save and exit.

GRUB Kernel Parameters

Boot Proxmox and edit /etc/default/grub. Find the GRUB_CMDLINE_LINUX_DEFAULT line and add the IOMMU flags. For Intel, use intel_iommu=on iommu=pt. For AMD, use amd_iommu=on iommu=pt. The iommu=pt flag enables pass-through mode and reduces overhead.

After saving, run update-grub and reboot. Verify IOMMU is active with dmesg | grep -i -e DMAR -e IOMMU. You should see lines confirming that IOMMU is enabled and that the DMAR table has been parsed.

Confirming VFIO Modules Load

VFIO is the kernel framework that performs the actual passthrough. Run lspci -nn to confirm your HBA is visible and note its PCI address and vendor/device IDs. The output will look like 01:00.0 Serial bus controller [0c06]: LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097].

Preparing the HBA Card (IT Mode and Option ROM)

An HBA flashed in IR mode will try to manage your drives as a RAID controller, which breaks ZFS. Worse, the Option ROM can stall the TrueNAS VM at boot and cause the dreaded boot loop. This section fixes both issues.

Crossflashing to IT Mode

If your HBA shipped in IR mode (common on Dell H310 and H710 cards), flash it to IT mode firmware. The community maintains the “LSI 9211-8i IT firmware” package, and for Dell cards, the crossflash procedure using sas2flash or sas3flash is well documented. You flash from a DOS USB stick or from a Linux live environment with the card temporarily installed in a non-RAID system.

After flashing, reboot and verify with sas2flash -list (or sas3flash -list). The IR/IT mode line should say “IT” rather than “IR.” If it does, the card will pass raw SATA/SAS disks through to TrueNAS without interference.

Removing the Option ROM

The Option ROM on some HBAs confuses SeaBIOS during VM boot. The fix that has worked for many users is wiping the Option ROM with sas2flash using the -o -e 7 flags, or the equivalent for your firmware version. One community member with a Dell R720 and an H710 in IT mode reported that wiping the Option ROM solved the TrueNAS installer hanging at the splash screen.

After wiping, reboot and confirm the HBA still enumerates disks correctly when plugged into the host. Only proceed to passthrough once you have seen the disks appear under /dev/sd* on the Proxmox host.

Configuring PCI Passthrough in Proxmox

With IOMMU on and the HBA ready, the Proxmox side is straightforward. You map the HBA to a resource, then attach that resource to your TrueNAS VM.

Isolating the HBA in Its Own IOMMU Group

The Proxmox wiki is clear: you can only pass through entire IOMMU groups, not arbitrary devices. Run find /sys/kernel/iommu_groups/ -type l and inspect the group containing your HBA. If other devices share the group, you either need to use a different PCIe slot (so the HBA sits alone on a CPU-attached lane) or apply ACS override patches. On most server boards, slot choice solves it.

Creating the IOMMU Mapping

Open the Proxmox web UI and go to Datacenter → Resource Mappings → Add → PCI Device. Pick your HBA from the list and give it a name like “TrueNAS-HBA.” Proxmox will write the VFIO binding so the host kernel stops claiming the device.

Verify the binding with lspci -nnk -s 01:00. The “Kernel driver in use” line should show vfio-pci. If it still shows mpt3sas, the HBA driver claimed it on boot. Add the device IDs to /etc/modprobe.d/vfio.conf and rebuild initramfs with update-initramfs -u -k

all.

Creating the TrueNAS SCALE VM

Now build the VM. The choices you make here matter, especially the BIOS type and machine version.

VM Hardware Settings

In the Proxmox UI, click Create VM and use these starting values:

• Machine: q35 (gives you PCIe-native topology and is the default for modern guests)

• BIOS: SeaBIOS (the OVMF path works too, but SeaBIOS is what most forum-tested guides use)

• CPU: host, with the AES flag enabled if your CPU supports it

• Memory: 16 GB or more, and importantly, do not enable ballooning

• Network: VirtIO (paravirtualized), bridged to your storage VLAN

Ballooning deserves a special warning. ZFS uses RAM aggressively for the ARC, and dynamically shrinking the VM’s RAM at runtime has been known to corrupt ZFS metadata and crash the VM. Disable the Ballooning Device under VM → Hardware → Memory.

Attaching the HBA and Boot Disk

Under the VM’s Hardware tab, click Add → PCI Device and select the HBA mapping you created earlier. Then add a virtual disk (SCSI or SATA, VirtIO Block) on Proxmox storage to serve as the TrueNAS boot drive. The pool disks come from the HBA and will be detected by the installer automatically.

Boot the VM with the TrueNAS SCALE ISO attached and walk through the installer. The boot virtual disk shows up as vda; the HBA-attached disks appear as sda, sdb, and so on. Install the OS onto vda and reserve the HBA disks for your ZFS pool.

Boot Configuration and Common Troubleshooting

Even with everything configured correctly, TrueNAS VM boot issues can surface. The most common ones fall into a small set of patterns.

Boot Loop After Adding the HBA

If your TrueNAS VM enters a boot loop once the HBA is attached, the Option ROM is almost always to blame. Confirm by removing the HBA, rebooting successfully, and then re-attaching. If the loop returns, boot a live Linux ISO in the same VM to verify SeaBIOS is the actual boot device (sometimes SeaBIOS gets confused by extra Option ROMs from passed-through devices).

The fix that consistently works for H710 IT mode cards is wiping the Option ROM with sas2flash before passing the card through. Another option is disabling the ROM Bar on the PCI device in Proxmox: VM → Hardware → PCI Device → Edit → uncheck “ROM-Bar.” Both approaches prevent the card’s firmware from running during VM POST.

TrueNAS Stalls at Installer Splash

If the installer hangs after detecting disks, check dmesg inside the live environment for “IOMMU fault” errors. These usually mean another device shares your HBA’s IOMMU group and needs to be moved or ACS-overridden.

ZFS Pool Will Not Import

If TrueNAS refuses to import a pool created on a previous controller, the issue is almost always disk order. After PCI passthrough, the controller presents disks in PCIe enumeration order rather than SATA port order. Use the disk ID (UUID) rather than device name when importing.

RAM Ballooning Crashes

If TrueNAS crashes after periods of high memory pressure on the host, disable ballooning on the VM. This is mentioned across the Proxmox forum as a hard requirement for stable TrueNAS VMs.

Performance Tips and Backup Strategy

With the VM stable, focus on getting the most out of your pool. Users with RAIDZ1 on spinning disks over a 2.5 GbE network routinely report around 280 MB/s sequential throughput. RAIDZ2 on SSDs scales higher.

Set the ZFS ashift to match your drives (usually 12 for 4Kn advanced format), enable autotrim for SSDs, and use VirtIO for the network. Avoid nested ZFS, meaning, do not put Proxmox’s boot ZFS pool on disks that TrueNAS is also exporting. A common pattern is to keep Proxmox on mirrored SSDs and let TrueNAS own the spinning rust entirely.

For backups, snapshot the VM from Proxmox for the TrueNAS boot disk and back up the data pools with ZFS send/receive to a separate machine. PCI passthrough means TrueNAS owns the disks, so file-level backups and ZFS scrubs work just like on bare metal.

Frequently Asked Questions

Conclusion

That covers how to virtualize TrueNAS SCALE under Proxmox with an HBA passed through, end to end. You enable IOMMU, prepare the HBA in IT mode, map it through VFIO, and run TrueNAS as a VM with its own virtual boot disk. The configuration is one-time work, and once it is in place, you get bare-metal ZFS performance with Proxmox’s flexibility on top.

If you are starting from scratch, I recommend flashing the HBA to IT mode and wiping its Option ROM before installing Proxmox. That sequence avoids the most common boot loops and gives you a clean foundation. Once your pool is created, set up ZFS send/receive to a backup host and you have a NAS that is easy to manage for years to come.