NFS vs. iSCSI vs. vSAN: Choosing Storage for Your VMware ESXi Home Lab in 2026

If you’re starting a VMware home lab in 2026 with no hardware constraints yet, you’re making this decision at a genuinely different moment than anyone who wrote a “NFS vs iSCSI vs vSAN” comparison before early 2024. The technology trade-offs are mostly unchanged but the licensing landscape around them has been rebuilt from the ground up by Broadcom, and that now matters just as much as the technical comparison for a home lab budget. This guide covers both.

Before the Storage Comparison: The Licensing Reality You’re Actually Building Against

This isn’t a tangent it directly shapes which storage technology makes sense for you, especially vSAN. Broadcom completed its VMware acquisition in November 2023 and, within months, revoked the free version of ESXi in February 2024, discontinued perpetual licensing, and collapsed VMware’s sprawling SKU list into a small number of subscription bundles. For a long stretch, “start a VMware home lab for free” simply stopped being an option in any straightforward sense.

Broadcom quietly reintroduced a free ESXi hypervisor via ESXi 8.0 Update 3e’s release notes, downloadable from the Broadcom Support Portal. It’s real, but limited the free tier supports an unlimited number of VMs within your hardware limits and includes the vSphere Host Client, but disables automation/orchestration features, restricts networking to the Standard vSwitch, and comes with no support entitlement. Critically for this guide: the free tier does not include vCenter, vMotion, DRS, HA, or vSAN. It gets you a single standalone ESXi host with local or directly-attached NFS/iSCSI storage — nothing cluster-related.

For anything beyond a single host — which includes any real vSAN deployment — your realistic options are:

1. VMUG Advantage (~$200/year) includes licenses for vSphere, vSAN, and NSX for up to 6 CPUs, and remains the standard, cost-effective path the home lab community uses for a full-featured multi-node lab.
2. Certification-linked free licenses — passing a VCP-VVF exam unlocks a 1-year vSphere Standard Edition license (32 cores), while VCP-VCF plus an active VMUG Advantage membership unlocks a 3-year VMware Cloud Foundation license (128 cores). This is a real path to free multi-year licensing, but it requires passing a paid certification exam first not a trivial cost or time investment if you don’t already need the cert.
3. An alternative hypervisor (Proxmox is the community’s overwhelming default alternative) if you want to avoid VMware licensing costs entirely.

One practical home lab rule worth internalizing before you spend anything if your homelab hardware costs under $500, ESXi licensing will typically cost more than the hardware itself a genuinely useful gut-check before you commit to the VMware stack for a small lab.

Core Architecture: How Each Technology Works with ESXi

NFS

ESXi mounts a file-level export from an external NFS server (a NAS, filer, or software-defined storage box) directly into its datastore namespace. The array’s own file system does the heavy lifting; ESXi is just a client. Setup is a GUI wizard: point at an IP/hostname and export path, done.

iSCSI

ESXi’s software or hardware initiator connects to a block-level iSCSI target, which presents a raw LUN. ESXi formats that LUN with VMFS VMware’s own clustered file system which is what actually provides multi-host locking and datastore semantics.

vSAN

Fundamentally different from the other two: vSAN is hyperconverged. It pools local disks (NVMe/SSD/HDD) across cluster hosts into a single distributed datastore, with data mirrored or erasure-coded across hosts for resilience. There’s no external storage array at all the ESXi hosts are the storage. This is also why vSAN has a hard structural requirement the other two don’t vSAN requires a minimum host count typically three nodes for standard vSAN, four for stretched clusters and each host must carry both compute and storage roles. A single-node vSAN “cluster” exists (more on that below) but isn’t resilient in any meaningful sense.

Cost and Budget Comparison

	NFS	iSCSI	vSAN
Minimum topology	1 host + any NAS	1 host + any iSCSI target	3 nodes for real resilience (2-node + witness is a documented minimum-viable variant)
Licensing needed	Free ESXi is enough for single-host	Free ESXi is enough for single-host	Requires vCenter + vSAN licensing — no path around this
Cheapest legal full-featured path	N/A (free tier sufficient)	N/A (free tier sufficient)	VMUG Advantage, ~$200/year, up to 6 CPUs
Hardware reuse potential	High — any NAS or old server with a NIC	High — any iSCSI target software (TrueNAS, StarWind) or old server	Lower — needs local disks in every node, ideally on the vSAN HCL
Typical entry hardware cost	$150–400 (used Synology/QNAP, or repurposed PC)	Similar to NFS — same hardware, different target software	3x the compute hardware cost, since you need 3 capable nodes minimum

The practical upshot: NFS and iSCSI let you defer or entirely sidestep VMware’s post-2024 licensing complexity if you stay on a single free-tier ESXi host. vSAN cannot — it structurally requires vCenter and cluster licensing the moment you want real fault tolerance, which means budgeting for VMUG Advantage (or the certification path) as a fixed line item, not an optional extra.

A useful, if extreme, historical data point on vSAN’s “three-node tax” an early enterprise vSAN pricing estimate for a modest all-flash 3-node cluster came to roughly $23,000–30,000 once licensing and desktop VDI licenses were included and that’s before multiplying anything by three, since three is the minimum node count. Home lab hardware today is vastly cheaper than that 2014-era estimate, but the structural “you must buy three of everything” dynamic hasn’t changed, and it’s the single biggest cost driver separating vSAN from the other two options.

Ease of Setup and Management

NFS — Easiest

Point ESXi at an export, done. If you’re using a consumer NAS (Synology, QNAP, TrueNAS), enabling NFS is usually a checkbox in the NAS’s own storage UI. Troubleshooting stays approachable it behaves like a network file share, and most home lab operators already have some familiarity with NAS administration.

iSCSI — Moderate

Requires configuring a software/hardware initiator on ESXi, setting up discovery (dynamic or static target IPs), and formatting the LUN with VMFS. Slightly more moving parts than NFS, and troubleshooting requires comfort with block-storage concepts (LUN masking, target IQNs, CHAP). Very achievable for an intermediate home labber, but a step up in complexity from NFS.

vSAN — Most Complex Initially, Simplest Long-Term

Cluster formation, disk group configuration (cache tier + capacity tier), network requirements (a dedicated vSAN VMkernel port, and ideally 10GbE between nodes), and licensing all need to be right before the cluster will even form. Once running, though, vSAN’s ongoing management is arguably the simplest of the three there’s no separate storage appliance to patch, monitor, or troubleshoot independently; it’s fully integrated into vCenter’s UI and health-check tooling.

Performance on Consumer-Grade Hardware

NFS

Realistic home lab throughput is dominated by your NIC speed and the NAS’s own CPU/RAM, not the protocol. A 1GbE NAS caps you around 110MB/s regardless of disks behind it; 2.5GbE or 10GbE NICs (increasingly affordable and common on modern NAS units and used enterprise switches) meaningfully change this picture. NFS v3’s lack of native multipathing (single TCP connection per mount, pre-nconnect) means a single NIC bottleneck unless you’re specifically on a build recent enough to use nconnect.

iSCSI

Similar real-world ceiling to NFS on the same network hardware the protocol-level differences rarely dominate at home lab scale. iSCSI’s native multipathing (MPIO) is more mature than NFS v3’s, which can matter if you’re running multiple NICs and want genuine load-balanced redundancy rather than just NIC-teaming failover.

vSAN

This is where local NVMe changes the equation entirely. Because vSAN keeps data local to each host (with network replication for resilience, not for every read), well-configured all-flash vSAN nodes with a fast local NVMe cache tier can dramatically outperform either NFS or iSCSI over a shared NAS on the same network you’re not bottlenecked by a single NAS’s controller or a shared network path for every I/O operation. The trade-off is that vSAN’s performance is much more sensitive to getting the underlying hardware right (cache-tier device speed and endurance in particular) a mismatched or consumer-grade cache-tier SSD can bottleneck an entire vSAN disk group in a way that doesn’t have a direct NFS/iSCSI equivalent.

Redundancy and Fault Tolerance

	NFS	iSCSI	vSAN
Redundancy source	Whatever the NAS/array provides (RAID, snapshots)	Whatever the target array provides (RAID, snapshots)	Built into the protocol itself — data mirrored/erasure-coded across hosts
Single point of failure	The NAS itself, unless it has its own HA	The iSCSI target itself, unless it has its own HA	None at the storage layer, provided you meet the minimum node count
Home lab realistic redundancy	NAS-level RAID only; no host-level storage redundancy	Same as NFS	Genuine host-failure tolerance — a host can go down without losing the datastore

This is the fundamental trade-off in one line: NFS and iSCSI centralize your single point of failure in one external box; vSAN distributes it across your compute nodes, at the cost of needing several of them. For a single-host lab, this distinction is moot you have a single point of failure either way (the NAS, or the one vSAN node with no peers to replicate to). Redundancy is a multi-node conversation.

Common Failure Modes and Recovery

NFS: Most common issues are network-layer (subnet mismatches, VLAN misconfiguration, /etc/hosts errors) or export-permission problems (root squash, client ACLs). Recovery is usually a straightforward remount once the underlying network or permission issue is fixed data itself is rarely at risk unless the NAS’s own RAID has failed.

iSCSI: Failure modes cluster around initiator/target session state, CHAP misconfiguration, and MPIO path issues. VMFS adds a layer of complexity NFS doesn’t have a corrupted VMFS volume (rare, but possible after an ungraceful power loss) is a more involved recovery than an NFS mount issue.

vSAN: The most operationally sensitive of the three. A disk group failure, a network partition between nodes, or critically for a home lab an ungraceful power loss during a resync or vMotion can produce genuinely difficult recovery scenarios. This is exactly why home lab guidance repeatedly emphasizes power protection never connect a lab server directly to a wall outlet without a UPS, since a power cut mid-vMotion or during a vSAN rebuild can corrupt datastores or invalidate snapshot chains a $100–150 UPS is considered one of the most impactful infrastructure dollars you’ll spend after the server itself</cite>. NFS/iSCSI setups care about this too, but vSAN’s distributed-state nature makes it materially more exposed to a bad power event mid-operation.

Decision Framework

Single-Node ESXi Host

NFS or iSCSI, not vSAN. A single host can technically form a one-node vSAN “cluster,” but you get none of vSAN’s actual value proposition (host-failure tolerance) you’re just adding vSAN’s complexity and licensing requirement for no redundancy benefit. On a single host, point at any NAS or iSCSI target you already own or can pick up cheaply, and use the free ESXi tier if you don’t need vCenter-dependent features.

Multi-Node Cluster

This is where the real decision lives:

• If you want the closest-to-production experience real vMotion between physical nodes, real HA, real distributed storage behavior vSAN is the most representative of what you’d encounter in an actual enterprise VMware deployment, and is genuinely the best choice if your goal is building transferable, job-relevant skills.
• If you want a multi-node cluster without the licensing and hardware-uniformity overhead of vSAN, run NFS or iSCSI against a dedicated NAS/storage box shared across your ESXi hosts. You still get shared storage, vMotion, and HA (HA depends on vCenter regardless of storage protocol) — you just don’t get vSAN’s distributed-storage-specific behavior to practice against.

By Workload Type

• Databases / latency-sensitive workloads: vSAN on all-flash local NVMe typically gives the best realistic home lab performance, assuming you invest in a decent cache-tier device. iSCSI is a reasonable second choice if your NAS/target has fast local SSDs and a solid network path.
• Virtual desktops (VDI-style testing): vSAN’s distributed I/O handling scales better under many-small-VM concurrent access patterns than a single shared NAS export, mirroring why it’s popular in production VDI deployments.
• General-purpose VMs, labs, templates, ISOs: NFS is genuinely the most convenient here — easy to browse, easy to back up, and performance is rarely the bottleneck for general-purpose lab VMs.

Migration Paths Between Technologies

• NFS/iSCSI → vSAN: Storage vMotion your VMs from the existing datastore onto the new vSAN datastore once the cluster is formed and licensed the standard, low-risk migration mechanism, same as any cross-datastore migration.
• vSAN → NFS/iSCSI: Same mechanism in reverse Storage vMotion off vSAN onto a newly mounted NFS or iSCSI datastore before decommissioning the vSAN cluster.
• NFS ↔ iSCSI: Also just Storage vMotion between two mounted datastores neither protocol requires an in-place conversion process, since you’re always moving VM files/disks to a genuinely different datastore, not converting the same one.

The unifying point: none of these transitions require rebuilding your VMs from scratch. Storage vMotion is the consistent mechanism across every combination the planning effort is really about licensing, hardware, and cluster formation, not VM-level migration risk.

Practical Home Lab Configurations That Work

• Budget single-host NFS lab: One repurposed desktop/used enterprise server running free ESXi 8.0 U3e, pointed at a Synology or QNAP NAS over NFS on 1GbE or 2.5GbE. This is the most common, lowest-friction home lab starting point in the current community, and sidesteps the post-2024 licensing question almost entirely.
• Budget single-host iSCSI lab: Same hardware profile, but using TrueNAS or a similar software iSCSI target instead of NFS — a reasonable choice if you specifically want to practice block-storage/SAN skills relevant to enterprise environments.
• Multi-node NFS/iSCSI cluster: Two to three used enterprise rack servers (Dell PowerEdge R730 and HP ProLiant DL380 Gen9 are frequently cited as current sweet-spot used-hardware picks) sharing a single beefier NAS over NFS or iSCSI, licensed via VMUG Advantage to unlock vCenter/HA/DRS.
• Full vSAN lab: Three (or more) matched nodes, each with local NVMe/SSD, ideally on the vSAN Hardware Compatibility List or at least vSAN-ReadyNode-adjacent specs, connected via 10GbE, licensed through VMUG Advantage or the certification-linked license path.

Common Pitfalls

• Underestimating vSAN’s licensing floor. People plan the hardware for a 3-node vSAN cluster and forget that vCenter + vSAN licensing is a hard requirement, not an optional add-on budget the ~$200/year VMUG Advantage cost (or the cert-exam cost for a free path) from day one, not as an afterthought.
• Assuming the free ESXi tier covers cluster features. It doesn’t no vCenter, no vMotion, no HA, no vSAN. If your plan involves any of those, you need a licensing path beyond the free standalone hypervisor.
• Skipping a UPS on a vSAN lab. Given vSAN’s sensitivity to ungraceful power loss during rebuilds/resyncs, this is a disproportionately high-value purchase relative to its cost for anyone running vSAN specifically.
• Mismatched vSAN cache-tier hardware. Throwing a slow or consumer-grade SSD into the cache tier of an otherwise-decent vSAN node is one of the most common home lab performance complaints the cache tier device matters far more than most people budget for.
• Relying on outdated “Personal/Education license” guidance. Older home lab guides reference a legacy free-ESXi tier limited to one host and 4 vCPUs this tier no longer exists; it was a feature of the pre-2024 free ESXi that Broadcom discontinued, and guides (including some AI-generated ones) still incorrectly reference it . If you read this claim anywhere, treat it as stale.

Can You Reuse Existing Hardware?

• NFS: Almost anything with an Ethernet port and enough CPU/RAM to run an NFS daemon works — old desktops, used enterprise servers repurposed as file servers, or any consumer NAS. This is the most hardware-forgiving of the three.
• iSCSI: Similarly forgiving the same repurposed hardware running TrueNAS, StarWind, or another software iSCSI target works fine. iSCSI HBAs exist for CPU offload but aren’t required at home lab scale; software initiators are the norm.
• vSAN: More particular. Every node needs local disks meeting vSAN’s requirements (a cache-tier device plus capacity-tier devices, ideally NVMe or SATA/SAS SSD), and while vSAN’s hardware requirements have loosened over time as of November 2025, vSAN ReadyNodes profiles were updated with much lower hardware minimums than in earlier years you’re still constrained to hardware that can actually claim local storage devices for vSAN, which rules out most thin clients and some older/lower-end used servers with limited internal drive bays.

Monitoring and Troubleshooting Tools in ESXi

Regardless of which protocol you choose, the same core ESXi tooling applies:

• vCenter’s Datastore and Host > Monitor views for space usage, latency graphs, and alarms available for all three protocols once vCenter is in play.
• esxtop for real-time storage latency (DAVG, KAVG, GAVG columns) invaluable for diagnosing whether a slowdown is array-side, network-side, or host-side, regardless of protocol.
• esxcli storage nfs list / esxcli storage core path list — protocol-specific CLI checks for NFS mount state and iSCSI/VMFS path status respectively.
• vSAN Health Service (in the vSAN cluster’s Monitor tab) vSAN-specific, and genuinely worth learning even in a home lab, since it surfaces disk group, network, and cluster-health issues proactively rather than reactively.
• vmkernel.log — the first place to check for any storage-layer connectivity or mount failure, across all three protocols.

Bottom Line

There’s no single right answer here, which is really the point of your original question but here’s how the trade-offs collapse for the four dimensions you asked to weigh equally:

• Cost: NFS and iSCSI win clearly for a single host; vSAN’s licensing floor makes it the most expensive entry point regardless of hardware cost.
• Ease of setup/management: NFS wins for initial simplicity; vSAN wins for long-term integrated management once it’s running.
• Performance: vSAN wins on well-matched all-flash hardware; NFS and iSCSI are roughly comparable to each other and network-bottlenecked either way.
• Scalability/future growth: vSAN scales the most “production-like” way (add nodes, not just disks) and migration between all three is low-risk via Storage vMotion regardless of which you start with so this dimension arguably matters least for your starting choice, since you’re not locking yourself in.

Given you’re starting with zero hardware constraints: if your goal is learning transferable, production-relevant VMware skills and you’re willing to budget ~$200/year for VMUG Advantage, a 3-node vSAN cluster is the most representative real-world experience. If your goal is the lowest-friction, lowest-cost path to a working lab that you can expand later without regret, start single-host with free ESXi and NFS against a NAS you may already own and migrate to vSAN later via Storage vMotion if and when the licensing and hardware investment feel justified.

Sources and Currency Notes

Licensing information in this guide (free ESXi’s 2024 discontinuation and 2025 partial return via 8.0 U3e, VMUG Advantage pricing, VCP-linked license paths) is drawn from current Broadcom release notes, VMUG/Broadcom program documentation, and home-lab community sources dated between April 2025 and August 2026 this is one of the fastest-moving areas in the entire VMware ecosystem right now, so treat any source older than early 2024 on VMware home lab licensing as obsolete, including the “free ESXi with no licensing needed” assumption that dominated home lab guidance for the prior decade. Technical/architectural claims about NFS, iSCSI, and vSAN protocol behavior are comparatively stable and less time-sensitive, but vSAN hardware minimums specifically have also shifted (loosened) as recently as November 2025 per current vSAN FAQ documentation, so don’t rely on older vSAN ReadyNode hardware guidance either.

Click here to read about NFS 3 vs. NFS 4.1 for VMware ESXi: A Decision and Migration Guide