I set up TrueNAS on Proxmox the way iXsystems recommends, and it works surprisingly well

Published Jul 28, 2026, 8:00 PM EDT Ayush Pande is a PC hardware and gaming writer. When he's not working on a new article, you can find him with his head stuck inside a PC or tinkering with a server operating system. Besides computing, his interests include spending hours in long RPGs, yelling at his friends in co-op games, and practicing guitar. When it comes to my home lab, I’m a firm believer in running my virtualization platforms, routers, storage servers, and other essential systems separately on different machines. So, rather than consolidating my NAS server and productivity-driven virtual guests on the same Proxmox guest, I’ve relied on a bare-metal rig for my TrueNAS workloads for a long time. After all, considering the wacky experiments I partake in, I’d say I’m fairly justified in keeping my PVE nodes away from my central backup server. That said, I recently worked on a project where I deployed TrueNAS within a Proxmox virtual machine, and it worked surprisingly well. Of course, if I crashed my Proxmox node, my TrueNAS VM would go down as well. But as long as I don’t go too overboard with my experiments, I have to admit that iXsystems’ recommended method for a virtualized TrueNAS instance is reliable enough for a hybrid Proxmox-powered TrueNAS workstation. Deploying a TrueNAS VM like a conventional Linux distro is a recipe for disaster Even if it works at first, this NAS setup would be quite risky Let’s say I want to spin up any Linux-flavored virtual machine that’s not a ZFS-powered storage platform like TrueNAS. Well, the procedure is fairly straightforward: I’d grant the new VM a name and allocate the right CPU, memory, and storage resources to it via the virtual machine creation wizard on Proxmox. If I wanted to assign more storage disks to it, I’d simply assign them to the VM as virtual disks from the Hardware tab and call it a day. Or, in case I wanted more space, I’d head to the Proxmox shell and execute some commands to grant the entire drive to the VM. While this procedure would work even for dev VMs, it’s far from ideal for a TrueNAS virtual machine. You see, TrueNAS uses the uber-powerful ZFS as the underlying file system, which requires direct control over the physical disks. Assigning them to a TrueNAS VM would add extra virtualization layers to the mix, which could break write caching. And if the order of write operations gets scrambled during a crash, the data integrity of my storage pools is bound to get compromised. Heck, these virtualization layers are still present even if I were to pass raw disks to my TrueNAS VM via shell commands, and my virtualized backup system wouldn’t be able to track the S.M.A.R.T. stats, check the disk information, or flush the disk cache properly. Sure, things may work fine at first, but without hardware-level access to the disks, you could end up with broken storage pools on a TrueNAS virtual machine. Fortunately, there’s still a way to get a virtualized TrueNAS instance up and running on Proxmox… PCI(e) passthrough is the hack that makes this project possible It’s fairly straightforward once you know what you’re going Since exposing just the disks to TrueNAS involves extra hypervisor layers, the safest way to get a Proxmox-powered NAS server involves passing the entire SATA controller to the VM. That way, my TrueNAS VM (and by extension, ZFS) would get complete access to my hard drives, and I won’t have to deal with the quirks of virtual HDD-based storage pools. The caveat, of course, is that it can seem a bit convoluted for beginners. But if you’re somewhat well-versed in PCI passthrough on Proxmox, passing the SATA controller shouldn’t take too long. For reference, I conducted this experiment on a TerraMaster F4-425 Pro, which already has a good CPU and enough RAM for a hybrid Proxmox-based TrueNAS setup. I’ve created dedicated guides on PCI passthrough, but here’s a short version for folks looking to follow along. First, I edited the GRUB_CMDLINE_LINUX_DEFAULT="quiet" line within the /etc/default/grub configuration file by adding intel_iommu=on right after the quiet flag and ran update-grub to enable IOMMU provisions. Since the /etc/modules file also needed a couple of additional parameters, I added the following code to it: vfiovfio_iommu_type1vfio_pcivfio_virqfd With that, editing the /etc/modprobe.d/vfio.conf file to include the device IDs of my SATA controllers was all that was left. So, I ran the lspci -nn command to check the device IDs and entered them in /etc/modprobe.d/vfio.conf in the options vfio-pci ids=Device_1,Device_2 format. Now that PCI passthrough for my SATA controllers was complete, I quickly headed to the TrueNAS VM’s Hardware tab and added them as PCI devices. The TrueNAS VM also requires a lot of RAM I blame that on the memory-hungry ZFS pools My TrueNAS VM still needed some memory adjustment to make it battle-ready. ZFS is infamous for its memory-hogging tendencies, so I assigned 8GB out of the 16GB RAM on my NAS to the VM. I’ve got a couple of other virtual guests running on this system, so I’ll probably have to upgrade the amount of RAM in the future to avoid overprovisioning my memory resources. All that said, I’ve gotten this virtualized NAS setup running for well over a month now, and it hasn’t let me down. I’ll still need to pull back on my tinkering urges, as I don’t want to bring the TrueNAS setup down with the Proxmox host. But I have to say, running a hybrid Proxmox + TrueNAS configuration on the same machine is pretty darn impressive, even if it’s somewhat frowned upon by the general home lab community. TrueNAS SCALE