ZFS on SAN LUNs in Proxmox is one of those things that sounds great until you actually try it. I set up a TrueNAS iSCSI target, attached it to Proxmox, and put ZFS on top. Here’s what I found.
The setup
TrueNAS exports a 100GB iSCSI LUN. Proxmox connects to it as a normal disk. Then you run zpool create on that disk. That’s it. No magic.
iscsiadm -m discovery -t st -p 192.168.1.100
iscsiadm -m node --login
zpool create tank /dev/sdcIt works. I created a VM on the pool, installed Debian, ran some fio benchmarks. Performance was fine for a homelab.
What breaks
Snapshots. ZFS snapshots work fine, but Proxmox snapshots don’t. The Proxmox storage plugin sees the pool as a directory, not as ZFS. So no integrated snapshots, no rollback from the web UI. You have to use zfs snapshot manually.
Also, if the iSCSI connection drops, ZFS will start throwing errors. It doesn’t handle transient failures well. A brief network blip can cause a pool to go into a degraded state. For a homelab, that’s annoying but recoverable. For anything important, it’s a problem.
Why you might skip it
Honestly, for a homelab, just use NFS or SMB. Proxmox has native support for those. You get snapshots, backups, and live migration. ZFS on a LUN adds complexity without much benefit. The only reason to do it is if you need ZFS features like compression or checksums on the Proxmox side, and you can’t run ZFS locally.
If you do run ZFS locally, check out this post on mixed vdev paths for a common gotcha.
My take
It’s a fun experiment, but I wouldn’t run it long-term. The lack of Proxmox integration is a dealbreaker. If you need shared storage, NFS is simpler and more reliable. If you need ZFS, run it on local disks.
