A 4k write from a Proxmox VM to an NFS datastore took 6.2 ms at the median in our lab. The same write over iSCSI with LVM on top took 1.27 ms. Both datastores sat on the same target, pool and SSD. The gap most likely came from the sync settings on the NFS export, not the hardware. For VM disks, choose the protocol first and then the best NAS for Proxmox that serves it well.
The numbers come from a nested two-node cluster (measured October 2026 on Proxmox VE 9.2) with a Debian target serving NFS, LVM over iSCSI and ZFS over iSCSI. They measure protocols, not NAS models. We own none of the boxes below, so the picks are spec-verified against maker pages and the Amazon US listings on October 21, 2026. For the full list of Proxmox storage types, our Proxmox storage comparison covers the setup side.
NFS vs iSCSI results at a glance
We report the round-two medians from three runs per job. Round two started on a quiet host, but the load climbed as the cells ran, so the table gives the host load at the start of each column. Latency is fio completion latency inside the VM, and it includes two virtio layers and the network path:
| fio job | LVM over iSCSI | ZFS over iSCSI (LIO) | NFS, qcow2 | RAM LUN floor |
|---|---|---|---|---|
| Host load at start (1-minute) | 2.9 | 9.8 | 15.6 | 12.0 |
| 4k random write QD1, p50 | 1.27 ms (441 IOPS) | 1.19 ms (329 IOPS) | 6.19 ms (66 IOPS) | 0.42 ms |
| 4k random write QD1 + fsync | 148 IOPS | 133 IOPS | 64 IOPS | 930 IOPS |
| 4k random read QD1, p50 | 1.20 ms (777 IOPS) | 1.11 ms (575 IOPS) | 2.06 ms (411 IOPS) | 0.42 ms |
| 4k random read QD32 x4 jobs | 7,683 IOPS | 6,830 IOPS | 2,363 IOPS | 17,681 IOPS |
| 70/30 mix QD16 x4, read / write | 1,088 / 474 IOPS | 985 / 414 IOPS | 274 / 112 IOPS | 12,294 / 5,197 IOPS |
| 1M sequential read QD16 | 421 MB/s | 259 MB/s | 396 MB/s | 715 MB/s |
The write result holds regardless of load. Every NFS queue-depth-1 write cell ran at 5.7 to 6.3 ms median latency at host loads from 5.2 to 17.4. Both iSCSI backends ran at about 1.2 ms in round two. The read and deep-queue rows are less clean. The NFS column ran at a host load of 15.6 and the LVM column at 2.9, and load moved one volume by up to 30x. Treat the NFS read gap as indicative, not as a measured ratio. Sequential reads were close between NFS and LVM, at 396 and 421 MB/s. The RAM LUN row is the floor the lab itself imposes, measured through the same iSCSI path with no disk behind it.
How the numbers were collected
Everything ran as virtual machines on one Proxmox host, which keeps the test repeatable but limits what the numbers mean. This is the method, with each limit stated next to it:
- Cluster: two nested Proxmox VE 9.2 nodes (kernel 7.0.14) in one cluster, on a physical host running Proxmox VE 8.4. A separate storage subnet carried NFS and iSCSI at MTU 1500.
- Target: Debian 13 with ZFS 2.3.9, the kernel NFS server and targetcli (LIO). One ZFS vdev, compression on, no SLOG, ARC capped at 1 GiB.
- Workload: fio 3.39 inside a guest VM against a raw 24 GiB test disk, direct I/O, 5 s ramp and 20 s per job, 3 repeats, median reported.
- Disk under everything: one SATA SSD on the physical host. The round-two disk-backed cells wrote 1M sequential at 20 to 39 MB/s, while the RAM LUN wrote 660 MB/s through the same iSCSI path, so those rows measure the SSD, not the protocol, and the table leaves them out.
- Read caching: the host ARC (6.27 GiB) caches the target virtual disk, so part of every read result can come from host RAM. NFS raw read 541 MB/s sequential in round one from an SSD that wrote at tens of MB/s.
- No physical wire: the target and the nodes shared one host bridge. Real 10GbE adds switch and NIC latency that this lab does not have.
The host was shared with other labs, and its load moved the results more than any protocol did. The same LVM volume gave 25 IOPS at 4k QD1 read with the host load at 10 to 21, and 777 IOPS with the load at 2.9. That is a 30x swing from host load, which includes this lab’s own IO wait, so we reran the main cells once the host went quiet and use only that second round. If you benchmark your own NAS, record the host load next to every run.
Step 1: Choose between NFS and iSCSI
NFS is the simpler datastore and iSCSI the faster one for VM writes, and the snapshot features decide the rest. In our lab every NFS queue-depth-1 write cell, in both rounds and with raw or qcow2 images, ran at 5.7 to 6.3 ms median latency, about five times the iSCSI figure.
Configuration is the likely cause, not the protocol on the wire. The export was sync on a ZFS dataset with sync=standard. Proxmox opens the image with direct IO, so each guest write became a stable write on the target. We could not run the sync=disabled control before the lab ended, so treat that explanation as an inference. It matches the one public test we found. A Proxmox forum user measured a VM install on TrueNAS over NFS at 8 min 58 s without a SLOG and 1 min 55 s with one, on two different TrueNAS hosts. Over iSCSI the same install took 2 min 41 s and 1 min 43 s.
The features differ as much as the speed. The Proxmox storage documentation lists them per backend:
| Backend | Shared | Snapshots | Clones | What the NAS must provide |
|---|---|---|---|---|
| NFS | Yes | Yes, through qcow2 | Yes | An NFS export |
| LVM over iSCSI | Yes | Only as a PVE 9 tech preview (volume chains) | Full clones only | One iSCSI LUN with multi-initiator access |
| ZFS over iSCSI | Yes | Yes | No | Root SSH and a supported target: LIO, IET, istgt or Comstar |
Thick LVM over iSCSI has no snapshots by default. Proxmox VE 9 added snapshots as volume chains (qcow2 layers on LVM) as a technology preview, and its roadmap still lists moving them out of preview as future work. Blockbridge, which sells a competing storage plugin, measured a 30 to 90 percent loss for qcow2 on LVM against raw disks in its analysis, and its note says the feature is not recommended for production.
ZFS over iSCSI gives snapshots on raw zvols, but no consumer NAS operating system is a supported target. DSM, QTS, QuTS hero, UGOS Pro, TOS and ADM are not on the list, and TrueNAS uses the SCST target, which the built-in plugin does not drive. In practice it means a DIY Debian or Ubuntu box with ZFS and LIO, like our lab target.
We would use NFS for a small cluster where snapshots and simplicity matter more than write latency. LVM over iSCSI suits write-heavy VMs that you back up with Proxmox Backup Server instead of snapshots, and ZFS over iSCSI belongs only on a box you build yourself.
Step 2: Check what the NAS has to offer
Most NAS spec sheets list features that do nothing for Proxmox, and leave out the ones that decide a cluster datastore. These are the checks we applied to every pick:
- Two 10GbE ports: iSCSI multipath needs two NAS ports on separate subnets. One port works, but it is a single path and a single point of failure.
- Multi-initiator iSCSI: shared LVM needs every node logged in read-write at once. Synology has an “Allow multiple sessions” setting, ASUSTOR lists MPIO and SCSI-3 persistent reservations, and the UGREEN cluster guidance sets LUNs read-only.
- Thin LUNs with space reclaim: the Proxmox docs say volume-chain snapshots need thin provisioning and discard on the backing storage to be efficient. Synology says snapshots and space reclamation are not supported on thick-provisioned LUNs.
- NFS sync behaviour: on a ZFS-based NAS (TrueNAS, QuTS hero), an NFS datastore is sync-write heavy, so plan a SLOG with power-loss protection or accept the latency.
- ECC memory: a datastore for several nodes is the wrong place for silent memory errors.
VMware VAAI and Windows ODX appear on many NAS spec sheets and do nothing for Proxmox, so we ignored them. Drive policy matters too: the Synology rules are in our small business NAS guide, and the drive choice itself is in our Proxmox NVMe guide for flash and NAS hard drive guide for disks.
Step 3: Pick the NAS
Five boxes and one DIY build pass those checks in different ways. Each entry states which protocol it suits, because no single box here is best at all three backends.
| Pick | Best for | Network | ECC | iSCSI for a cluster | Price band |
|---|---|---|---|---|---|
| Synology DS1823xs+ | iSCSI datastore, 5-year warranty | 1x 10GbE + 2x 1GbE, slot for more | Yes | Yes, multiple sessions | $2,000 to $2,100 |
| ASUSTOR Lockerstor 6 Gen3 | Multipath on a budget | 2x 10GbE + 2x 5GbE | Yes, 16 GB included | Yes, MPIO listed | $1,750 to $1,800 |
| QNAP TS-473A | Lowest box price | 2x 2.5GbE, 10GbE by card | Supported, ships non-ECC | Yes, MPIO listed | $850 to $900, about $1,200 to $1,250 with a 10GbE card |
| UGREEN DXP6800 Pro | NFS datastore | 2x 10GbE | No | Not for shared LVM | $1,080 to $1,120 |
| TrueNAS Mini X+ | ZFS with the TrueNAS plugin | 2x 10GbE | Yes | Through the TrueNAS plugin (community-ready) | about $2,150 to $2,200 direct |
Synology DS1823xs+
We pick the DS1823xs+ for an iSCSI datastore that has to stay supported for years. It has a 4-core Ryzen V1780B, 8 GB of ECC memory (32 GB maximum) and eight bays. One 10GbE port sits next to two 1GbE ports, and a PCIe Gen3 slot with an x4 link takes a 10GbE or 25GbE card. SAN Manager supports multiple iSCSI sessions per LUN, and the warranty is 5 years.
Synology publishes its own figures for this model with an SSD pool: 228,462 read and 85,438 write IOPS at 4k random over iSCSI, against 193,012 and 72,288 over NFS. Those are vendor numbers from an all-SSD pool, and the iSCSI tests ran from a Windows client while the NFS tests ran from Ubuntu, so they are not a clean protocol comparison. One onboard 10GbE port means multipath needs a second port on a card. As a 2023 model it sits outside the 2025 Synology drive policy change, and NASCompares notes that its compatibility list holds only Synology drives, with third-party drives flagged as unverified.
ASUSTOR Lockerstor 6 Gen3 (AS6806T)
Among the Amazon picks, only the AS6806T has two 10GbE ports and ECC memory in the box. It runs a 4-core Ryzen V3C14 with 16 GB of ECC DDR5 (64 GB maximum), six bays, four M.2 slots, and two 5GbE ports next to the two 10GbE. ASUSTOR lists MPIO, SCSI-3 persistent reservations and thin LUNs up to 1,024 TB, which covers multipath and shared LVM on paper.
Three caveats keep it from the top spot. Each M.2 slot is PCIe 4.0 x1, so NVMe is a cache tier and not a fast pool. ASUSTOR does not state NFS 4.1 support or whether UNMAP reaches the disks from a Linux initiator. And on the check date Amazon had it only from a third-party seller, Platinum Micro, with two left, so check the seller before you order.
QNAP TS-473A
QNAP sells the cheapest way into a Proxmox datastore with ZFS and MPIO, provided you add a network card. It has a 4-core Ryzen V1500B, 8 GB of RAM (64 GB maximum), four bays, two M.2 slots, two 2.5GbE ports and two PCIe Gen3 x4 slots. It boots QTS or QuTS hero, and QNAP publishes its own Proxmox how-to for QTS 5.2 and Proxmox VE 8.2 or later.
Budget for the card from the start, for example the QNAP QXG-10G2T-X710 adds two 10GBASE-T ports for about $340 to $360, and gives multipath its second path. The ECC support needs replacing the stock non-ECC memory, because QNAP says ECC and non-ECC modules cannot be mixed. On QuTS hero, an NFS datastore is the sync-write case from Step 1, and a LUN set to “Synchronous I/O: None” trades that latency for data loss on a power cut.
UGREEN NASync DXP6800 Pro
UGREEN makes the pick for an NFS datastore, and only that. It has a 10-core Core i5-1235U, 8 GB of DDR5 (64 GB maximum, non-ECC), six bays, two M.2 slots, two 10GbE ports and a PCIe x4 slot. UGOS Pro can export NFS with no_root_squash, which matters because Proxmox writes its image files as root.
Its iSCSI is the wrong fit for a cluster. The UGREEN cluster guidance sets LUNs read-only, and ITPro reported in its October 2026 DXP8800 Ultra review that UGOS Pro SAN Manager does not support MPIO, so shared LVM over iSCSI is out. The DXP6800 Ultra, at about $1,430 to $1,470, adds a PCIe Gen4 x4 slot with the bandwidth for a dual 25GbE card, though UGREEN publishes no 25GbE driver support, and it has the same software limits.
TrueNAS Mini X+
TrueNAS sells the ZFS appliance in this list. The Mini X+ has an 8-core Atom C3758, 32 GB of ECC memory, five 3.5-inch and two 2.5-inch bays, IPMI and two 10GbE ports in the configuration we priced. The built-in Proxmox ZFS-over-iSCSI plugin cannot drive its SCST target, but iXsystems publishes a separate TrueNAS plugin for Proxmox that manages zvols over the API, with iSCSI or NVMe/TCP. It needs TrueNAS 25.10 or later, and NVMe/TCP needs Proxmox VE 9. In September 2026 iXsystems described it as ready for Community users and still under testing for Enterprise.
It was out of stock on Amazon on the check date, so the link goes to TrueNAS directly. The CPU dates from 2017, the base warranty is 1 year, and an NFS datastore on it is the sync-write case again, so a SLOG belongs in the plan. Our TrueNAS build guide covers SLOG sizing for NFS and iSCSI.
A DIY Debian box with ZFS and LIO
You build the only target in this list that the stock ZFS-over-iSCSI plugin drives. Our lab target was exactly that: Debian 13, ZFS from contrib, targetcli for LIO and the kernel NFS server, so one box served all three backends. The hardware side is in our DIY NAS guide, and the iSCSI target guide walks through targetcli.
Each Proxmox node needs root SSH to the target, with its key at /etc/pve/priv/zfs/<target_ip>_id_rsa, because the plugin creates a zvol and a LUN for every VM disk. We created the key on one node, since /etc/pve is shared across the cluster:
mkdir -p /etc/pve/priv/zfs && ssh-keygen -q -t ed25519 -N "" -f /etc/pve/priv/zfs/10.0.1.62_id_rsa && ls -l /etc/pve/priv/zfs/Add the .pub file to root’s authorized keys on the target, then connect once from every node so each one records the target host key:
ssh -i /etc/pve/priv/zfs/10.0.1.62_id_rsa -o StrictHostKeyChecking=accept-new [email protected] "hostname; targetcli version"Each node got the same answer back from the target:
tgt-lio
/usr/bin/targetcli version 2.1.53Without this step, Proxmox cannot reach the pool on the target, and VM disk creation fails. The target is also a single point of failure, which the Proxmox documentation says plainly.
Step 4: Build the storage network
Put storage on its own subnet and keep corosync off it. The Proxmox cluster docs call corosync a time-critical application and recommend separating it from other traffic. Our lab showed the other side: when a DHCP conflict took a node management address, we moved corosync to the storage subnet to keep the cluster quorate. Avoid that arrangement in production.
For iSCSI multipath, each node needs two sessions to two portals. The Proxmox multipath wiki recommends lowering the iSCSI replacement timeout from 120 to 15 seconds, and keeping find_multipaths "strict" with each LUN WWID added by hand. We changed only replacement_timeout, on both nodes; the two noop_out values are the Debian defaults. On pve-n1 the three lines read:
grep -E "^node.session.timeo.replacement_timeout|^node.conn\[0\].timeo.noop_out" /etc/iscsi/iscsid.confAll three are the values we ran with:
node.session.timeo.replacement_timeout = 15
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5With multipath-tools installed and both portals logged in, the multipath device showed two active paths to the same LUN:
multipath -llBoth paths report active ready running, which is what you want before you put LVM on /dev/mapper/mpatha:
mpatha (36001405d32012233e5244e8aaf2d50ca) dm-0 LIO-ORG,lunmp
size=8.0G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
|- 4:0:0:0 sdd 8:48 active ready running
`- 5:0:0:0 sde 8:64 active ready runningOur two paths were two IPs on one target NIC and one subnet. That proves the configuration but not redundancy, and we did not get to the failover test. The Proxmox multipath wiki asks for at least two dedicated NICs, separate networks and separate switches. The multipath configuration is not replicated between cluster nodes, so repeat it on every node. Jumbo frames belong only on a dedicated storage network and only end to end, because a single MTU mismatch between a node, a switch port and the NAS breaks storage traffic. The node side of the 10GbE network is in our Proxmox 10GbE NIC guide.
Step 5: Add the datastores to Proxmox
Each backend is added with pvesm add on any one node, since the storage configuration is cluster-wide; LVM over iSCSI takes two commands. The NFS datastore pins the NFS version, which avoids surprises when a NAS and a kernel disagree on the default. Our Debian target served 4.2; pin the highest version your NAS lists, which is 4.1 on Synology, where QNAP marks 4.2 as beta:
pvesm add nfs nfs-lio --server 10.0.1.62 --export /tank/pve --content images --options vers=4.2For LVM over iSCSI, add the iSCSI target first with content none, list its LUNs, then put a shared volume group on the LUN:
pvesm add iscsi lio-a --portal 10.0.1.62 --target iqn.2003-01.org.linux-iscsi.tgt-lio:pve --content noneOn a node with no iSCSI records yet, the first add printed two iscsiadm: No records found errors before the login succeeded. They are harmless, and the LUN appeared in the storage list right after:
iscsiadm: No records found
command '/usr/bin/iscsiadm --mode node' failed: exit code 21
iscsiadm: No records found
command '/usr/bin/iscsiadm --mode node' failed: exit code 21
Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.tgt-lio:pve, portal: 10.0.1.62,3260] successful.List the LUNs to get the volume ID that the LVM storage needs:
pvesm list lio-aThe 40 GiB zvol LUN is the first entry; the 3 GiB one is the RAM disk used for the floor test:
Volid Format Type Size VMID
lio-a:0.0.0.scsi-36001405fdf615c551734783a357498dc raw images 42949672960
lio-a:0.0.1.scsi-360014058d995fbf78b94a86bd5a67118 raw images 3221225472The volume group goes on the LUN by that volume ID, marked shared so Proxmox applies cluster-wide locking:
pvesm add lvm lvm-iscsi --vgname vg_iscsi --base lio-a:0.0.0.scsi-36001405fdf615c551734783a357498dc --shared 1 --content images --saferemove 1That --base form is the single-path setup. With multipath we used the CLI route from the Proxmox multipath wiki: pvcreate and vgcreate on /dev/mapper/mpatha, then an LVM storage with no base. The wiki also allows picking the iSCSI storage as the base, which makes Proxmox activate the iSCSI storage before the LVM storage. ZFS over iSCSI takes the provider, the target pool and the block size for each zvol it creates:
pvesm add zfs zfs-lio --iscsiprovider LIO --portal 10.0.1.62 --target iqn.2003-01.org.linux-iscsi.tgt-lio:zfs --pool tank/zvols --lio_tpg tpg1 --blocksize 16k --sparse 1 --content imagesEvery one of these showed active in pvesm status on both nodes, except in the trunking case below.
Step 6: Avoid the errors we hit
Four errors cost us time in the lab, and each has a fix you can apply before it happens. The NFS one is the most likely to reach a production cluster:
- Two NFS storages on one server collapse into one: a second storage pointing at the same export through the second target IP, with
nconnect=4, mounted with the address of the first storage and withoutnconnect, and showedinactive. The kernel treated both IPs as one NFSv4 server. Use one NFS storage per server, unmount every mount from it, then setnconnectand remount. pvecm addfails on an IPv6 link-local prefix: the join stopped withError: any valid prefix is expected rather than "fe80::be24:11ff:fe1b:96ea%eth0/32". cloud-init had rewritten/etc/hostswith the old hostname. Write/etc/hostswith the real IPv4 address of each node and disable cloud-init before joining.- GRUB stops the Proxmox kernel install on a cloud image:
grub-pcfailed its post-install script until the install device was set withdebconf-set-selectionsanddpkg --configure -awas rerun. - A thin host pool can fill: our nested nodes grew their thin disks on the physical host until its pool reached 0 bytes free, and every VM writing to it paused. A NAS datastore behaves the same way when thin LUNs overcommit it, and the Proxmox docs warn that all guests on a full storage receive IO errors.
nconnect itself gave no consistent gain in our lab: it helped queue-depth-1 reads and hurt deep random writes, with one client and no physical wire. Test it on your own network before you rely on it.
Step 7: Measure your own NAS
Our numbers set the direction, and your NAS, network and drives set the values. This is the latency job file we ran inside the guest, with the test device, ramp and runtime passed as variables:
; Latency jobs: one outstanding I/O, so clat is the round trip guest -> storage -> guest.
[global]
filename=${DEV}
ioengine=libaio
direct=1
time_based
ramp_time=${RAMP}
runtime=${RUNTIME}
norandommap
randrepeat=0
percentile_list=50:90:99:99.9
group_reporting
[randread-4k-qd1]
rw=randread
bs=4k
iodepth=1
numjobs=1
[randwrite-4k-qd1]
stonewall
rw=randwrite
bs=4k
iodepth=1
numjobs=1
[randwrite-4k-qd1-fsync]
stonewall
rw=randwrite
bs=4k
iodepth=1
numjobs=1
fsync=1fio fills the variables from the environment, so a run against the test disk looks like this, with the 15 s ramp and 120 s runtime we would use on a quiet host:
DEV=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 RAMP=15 RUNTIME=120 fio --output-format=json 10-lat-4k-qd1.fioPoint it only at an empty, dedicated test disk, never at a disk with data: the write jobs overwrite the device, and one of our own smoke tests wiped a guest boot disk that way. Run each datastore three times, keep the median, and log the host load next to it. If the NFS write latency sits several times above iSCSI on your box too, a SLOG or an iSCSI datastore is the fix; past one NAS, our 25GbE NIC guide covers the next network step.
