Build a FreeNAS iSCSI SAN for VMware Home Labs

A home lab SAN gives VMware administrators a practical way to learn shared storage, VMFS datastores, multipathing, and storage troubleshooting without buying enterprise hardware. FreeNAS, now continued as TrueNAS CORE, can turn a modest server with suitable disks into an iSCSI target for an ESXi host or small vSphere cluster.

This design is useful for testing vMotion, HA, backup workflows, storage policies, and infrastructure automation. It also exposes important operational details that are easy to miss in a production environment, including ZFS pool planning, network isolation, block sizes, permissions, and recovery procedures.

The goal is not to reproduce an enterprise array feature for feature. Instead, the lab should provide reliable shared block storage, predictable performance, and enough flexibility to rebuild the environment repeatedly. Practitioners looking for related systems administration projects can also find useful guidance through IT Diversified resources.

Choose Hardware for Storage Workloads

A FreeNAS iSCSI server does not need a high-end CPU, but it benefits from adequate memory and dependable network hardware. A modern four- or eight-core processor, 16 GB of ECC RAM, and a 1 GbE or 10 GbE network adapter make a solid starting point. ECC memory is especially valuable because ZFS relies heavily on memory for caching and metadata operations.

Use a separate boot device, such as a small SSD, rather than placing the operating system on the storage pool. The data pool should use NAS-rated or enterprise disks where possible. Mixing random consumer drives can work for experimentation, but disk health, power-loss behavior, and sustained write performance may vary significantly.

For a basic lab, four disks in a RAIDZ1 vdev provide usable capacity with single-disk fault tolerance. A mirrored vdev offers better IOPS and easier expansion in small environments. RAIDZ is not a replacement for backups, and an iSCSI datastore should never be treated as the only copy of important virtual machines.

Design the ZFS Pool and Network

Create the storage pool before configuring iSCSI. Give the pool a clear name, enable compression, and avoid using deduplication unless the lab specifically exists to test it. Compression is generally safe for VM workloads and can reduce disk activity when virtual machine data compresses well.

A dedicated storage network improves stability and makes troubleshooting easier. Ideally, connect the FreeNAS server and ESXi host to a separate VLAN or physical switch. Use static IP addresses, consistent MTU settings, and clear hostnames. Jumbo frames can improve efficiency on a controlled network, but they should only be enabled when every device in the path supports the same frame size.

For a single-host lab, one storage interface may be sufficient. A more advanced setup uses two interfaces and separate iSCSI portals. This enables multipathing practice, but it requires correct VMware port group, VMkernel, switch, and target configuration. A mismatched VLAN or MTU often causes intermittent storage failures that look like ZFS or ESXi problems.

Configure iSCSI Targets and Extents

In FreeNAS, configure the iSCSI service with a base name, portal, initiator restrictions, and target. The exact menu names vary by release, but the concepts remain consistent. The portal identifies the IP address and TCP port, while the target represents the logical SCSI endpoint that ESXi will discover.

An extent provides the backing storage. A file extent is convenient for a quick demonstration, but a device extent or zvol usually provides a more appropriate block-storage model for a VMware datastore. Create a dedicated zvol with a sensible reservation, compression enabled, and a block size suited to the workload. Avoid consuming the entire pool; ZFS performance and management become less predictable when space is nearly exhausted.

Use CHAP authentication when practicing secure configurations, even on an isolated network. Limit initiator access to the ESXi IQN where practical, and document the target IQN, portal IP, and authentication settings. These details make host replacement and troubleshooting much faster.

Component	Practical Home Lab Choice	Purpose
Boot device	Small SSD	Keeps the operating system separate from VM storage
Memory	16 GB ECC or more	Supports ZFS caching and metadata
Storage layout	Mirrors or RAIDZ1	Balances capacity, resilience, and performance
Network	Dedicated 1 GbE or 10 GbE VLAN	Isolates iSCSI traffic
VMware backing store	Zvol or device extent	Presents block storage to ESXi
Protection	Separate backup target	Prevents storage failure from becoming data loss

Connect ESXi to the Shared Datastore

Create a VMkernel adapter dedicated to iSCSI traffic. Assign it an address on the storage VLAN and confirm that the ESXi host can reach the FreeNAS portal. In the Software iSCSI adapter settings, add the target portal and rescan storage adapters.

When discovery succeeds, ESXi should display the iSCSI LUN as an available device. Use the datastore wizard to create a VMFS datastore, selecting the detected LUN and allowing ESXi to format it. Verify that the datastore capacity matches the extent and that the device identifier remains stable after a reboot.

For multipathing, bind the iSCSI VMkernel adapters to the software iSCSI adapter and configure separate target paths. Do not simply add multiple IP addresses and assume redundancy exists. VMware path binding, switch VLANs, FreeNAS portals, and physical interfaces must align. Check the path state in ESXi and confirm that a disconnected interface does not take the datastore offline.

Validate Performance and Failure Recovery

Testing should begin with basic functionality: create a virtual machine, install an operating system, reboot it, and migrate its files within the datastore. Monitor latency, IOPS, throughput, CPU usage, memory pressure, and pool capacity on the storage server. VMware performance charts and FreeNAS reporting provide useful evidence when tuning the environment.

Run controlled failure tests after the baseline is stable. Disconnect one network path in a multipath design, stop and restart the iSCSI service, and simulate a disk failure only if the hardware and backups support the exercise. Observe whether ESXi maintains access, changes paths, or reports datastore connectivity errors.

Snapshots can help with short-term rollback, but they are not a backup strategy. Configure replication or copy critical VMs to another system. Keep enough free space for ZFS metadata, snapshots, and temporary workloads, and establish alerts for disk health, pool degradation, temperature, and capacity.

Common Configuration Mistakes

The most frequent problems come from combining several small errors. An incorrect initiator IQN prevents access, a wrong VLAN blocks discovery, and inconsistent MTU settings create unstable sessions. Checking each layer separately—from physical link to IP connectivity, iSCSI login, LUN visibility, and VMFS mounting—usually narrows the issue quickly.

A few design practices make the lab easier to operate:

• Keep management, virtual machine, and iSCSI traffic on separate networks where possible.
• Record every IP address, IQN, portal, zvol name, and authentication setting.
• Leave free capacity in the ZFS pool instead of filling it to the last gigabyte.
• Test restore procedures before trusting snapshots or replication.
• Use monitoring alerts for disk failures, degraded pools, and rising datastore latency.

A FreeNAS-based VMware SAN is most valuable when it is treated as an operational training platform rather than a disposable storage box. Rebuilding the target, documenting the process, and testing failure scenarios develop skills that transfer directly to enterprise SAN and virtualization environments.

Start with a single ESXi host and one carefully planned datastore, then expand to VLAN isolation, multipathing, replication, and automation as the basics become reliable. Build the lab deliberately, measure each change, and use the resulting environment to practice the storage administration tasks that production systems demand.