TrueNAS storage ownership guide
Proxmox Disk Passthrough to TrueNAS: HBA or Individual Disks?
A TrueNAS VM on Proxmox can receive storage in more than one way, and the method changes what the guest can see and control. Passing an entire HBA gives TrueNAS direct ownership of a controller and its disks. Passing individual disks can be practical when an extra HBA is unavailable, but it introduces host-side mapping that must remain stable. The right choice depends on whether the storage VM is a convenience layer or the authoritative owner of a serious ZFS pool.
Quick answer
Whole HBA or individual disks?
Prefer whole-HBA passthrough when TrueNAS is the long-term owner of a multi-disk ZFS pool and the platform can isolate the controller cleanly. Individual-disk passthrough is better treated as a constrained alternative for small systems where a dedicated controller is not practical. Whichever method you choose, preserve stable disk identity, SMART visibility and a recovery procedure that does not depend on guessing Linux device names.
Live Amazon hardware
Current controllers, cables and storage devices for this decision
These listings come from Sprint 4B's dedicated catalogue. HBA generations, connector families, breakout cables, cooling hardware and enterprise SSD candidates are separated. A marketplace phrase such as “IT mode” is treated as listing evidence, not proof of firmware state.
Buying decision
Make disk identity survive reboots and replacements
Do not build a storage process around /dev/sdX names. Use persistent identifiers and record drive serials, bays and mapping. The recovery question is not “can the VM see a disk today?” but “can you identify the failed physical device correctly six months from now after hardware changes?”
Interactive decision tool
TrueNAS Passthrough Method Planner
Use this planner to screen controller class, ports, PCIe bandwidth, passthrough ownership, ZFS cache/allocation-device roles or expansion headroom before buying hardware. Results are planning guidance, not a substitute for motherboard lane/IOMMU documentation, exact HBA firmware verification, current OpenZFS behavior or independent backups.
Compatibility checklist
Four checks before adding an HBA or expanding storage
Decide who owns the disks
Proxmox-owned ZFS and a TrueNAS VM passed an entire HBA are different architectures. Do not let both layers manage the same disks.
Match ports and connectors
Count final drive lanes and verify SFF-8087, SFF-8643, backplane and breakout-cable direction before ordering.
Check PCIe lanes and IOMMU
A full-length slot may run electrically at fewer lanes. Passthrough also depends on platform IOMMU support and usable isolation.
Plan cooling and recovery
HBAs need airflow, and more attached disks increase the data you must protect with an independent backup and documented replacement map.
Treat TrueNAS as the owner of its pool
Once a ZFS pool is created inside TrueNAS, avoid simultaneously importing or managing that pool from the Proxmox host. One storage stack should own the metadata and lifecycle.
This boundary keeps snapshots, scrubs, alerts and replacement procedures consistent. Proxmox consumes storage exported by the VM rather than trying to manage the same physical disks directly.
Whole-HBA passthrough gives the clearest hardware boundary
With controller passthrough, TrueNAS sees the HBA and attached disks through the guest PCIe device. This resembles a physical TrueNAS server more closely than mapping disks one by one.
It also moves controller resets, disk enumeration and health visibility into the storage VM. The cost is reduced VM portability and the need for an isolated IOMMU group.
Individual-disk passthrough can solve small-system constraints
A mini tower may have no free PCIe slot for a dedicated HBA. In that case, individual physical-disk mapping can provide TrueNAS with access to selected drives while the host keeps other devices.
The operational burden is higher. Persistent device identifiers must be used carefully, SMART/serial behavior should be tested, and every disk replacement must update the mapping without accidentally targeting the wrong device.
Never map disks by transient sdX names
Linux device letters can change when hardware is added, removed or enumerated in a different order. A mapping that points at /dev/sdb can therefore become dangerous if a reboot assigns that letter to another disk.
Use persistent paths or IDs that encode stable hardware identity, and document the serial number. Then confirm inside TrueNAS that the guest sees the expected serial before creating or importing a pool.
Keep the Proxmox boot path independent
Do not put the hypervisor boot disk on a controller or physical disk path that belongs to TrueNAS. The host needs to start and expose its management interface even when the storage VM is broken.
This separation makes recovery possible from the Proxmox console. You can repair the guest, change passthrough configuration or restore backups without depending on the VM being healthy.
SMART visibility is part of the design
A storage appliance needs health information, not just read/write access. Test whether TrueNAS can read useful disk identity and SMART data through the chosen passthrough method.
If individual mapping obscures the information you rely on for alerts or replacement, that is a strong reason to move to whole-controller passthrough.
ZFS redundancy still belongs inside TrueNAS
Passing physical disks does not create redundancy. Mirror, RAIDZ and spare design remains a TrueNAS/ZFS decision.
Size the pool for failures, replacement time and backups rather than simply attaching every available disk. The HBA only transports I/O; ZFS defines the data-protection topology.
Host backups and storage-VM backups are different
Back up the TrueNAS VM configuration separately from the data stored in its pool. A VM backup does not automatically mean the physical ZFS pool is backed up, and a ZFS snapshot does not preserve the Proxmox VM definition.
Keep at least one recovery copy outside the same HBA, chassis and pool. This matters most when the reason for recovery is a controller, power or chassis failure.
Plan startup dependencies
Other VMs may rely on SMB, NFS or iSCSI exported by TrueNAS. Configure start ordering and realistic delays so dependent guests do not race the storage VM during boot.
Also plan shutdown order. The storage VM should remain available until clients have stopped writing, then shut down cleanly before the host powers off.
A passed-through HBA reduces cluster portability
The TrueNAS VM is now attached to physical controller and disk topology. Another Proxmox node cannot simply start it unless equivalent hardware and the same physical storage are available.
For a single-node home lab this may be acceptable. For a cluster, decide whether direct passthrough or shared external storage better matches the availability goal.
Replacement procedures should be written before failure
Record which bay corresponds to each serial and how the device appears inside TrueNAS. If a drive fails, confirm serial, power down if the chassis is not hot-swap safe, replace only that disk and follow the ZFS replacement workflow.
Do not let the Proxmox layer obscure the physical procedure. The person replacing the drive should be able to move from an alert to the correct bay without guessing.
Choose simplicity over cleverness
A dedicated HBA passed through to TrueNAS is attractive because the boundary is simple: Proxmox owns the hypervisor; TrueNAS owns the HBA and pool. Individual mapping can be entirely workable, but every extra mapping layer is another thing to remember during recovery.
Pick the simplest architecture your hardware permits, validate it under reboot and replacement scenarios, then document it. The best design is the one you can recover when you are tired and a disk has actually failed.
Questions people ask
Proxmox Disk Passthrough to TrueNAS questions
Is HBA passthrough better for TrueNAS than disk passthrough?
Usually when TrueNAS is the authoritative owner of a multi-disk pool. Whole-HBA passthrough gives the guest a clearer hardware boundary and often better disk visibility.
Can I pass individual SATA disks to TrueNAS?
Yes, but use stable identifiers rather than /dev/sdX and test serial/SMART visibility before building the pool.
Can the same disk be used by Proxmox and TrueNAS?
Do not give both storage stacks write ownership of the same physical pool or disk.
Should TrueNAS boot from the passed-through HBA?
The TrueNAS VM boot disk can remain a virtual disk on Proxmox storage; the passed-through HBA can then be dedicated to the data pool.
Where should Proxmox itself boot from?
Use motherboard SATA, NVMe or another controller that is not passed through to the storage VM.
Does individual-disk passthrough preserve SMART?
Behavior depends on the mapping and hardware path. Test it. If health visibility is incomplete, whole-HBA passthrough is usually cleaner.
Can a TrueNAS VM with an HBA be migrated?
Hardware passthrough reduces migration flexibility because the target node needs equivalent hardware and access to the same disks.
Should ZFS be on Proxmox or TrueNAS?
Either can own ZFS, but avoid making both manage the same pool. Choose one authoritative storage layer.
How do I identify the failed physical disk?
Maintain a serial-to-bay map and confirm the serial reported by TrueNAS before replacement.
Is RAID on the HBA useful with TrueNAS?
For a ZFS data pool, direct disk visibility is preferred over hiding drives behind hardware RAID virtual disks.
Official references and methodology
Verify controller, passthrough and OpenZFS behavior before deployment
This page treats controller ownership, stable identity and recovery behavior as the deciding factors. It does not assume that individual-disk mapping provides the same health visibility on every platform. Users are told to verify serial and SMART behavior before creating a pool.
- Proxmox VE PCI(e) Passthrough
- Proxmox VE Storage Manager
- OpenZFS VDEVs
- Broadcom LSI SAS 9207-8i User Guide
- Broadcom LSI SAS 9300-8i User Guide
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, seller claims, controller firmware, IT-mode status, exact board revisions, cable direction, enterprise SSD features and marketplace conditions can change. Verify the exact delivered hardware before deployment.