Home | Contact
whichnas.com

Setting Up NAS iSCSI Storage for Virtual Machines

Running virtual machines from a NAS can give a small office, home lab, or growing business a practical alternative to dedicated storage hardware. Instead of keeping virtual disks on an internal drive, an iSCSI target presents NAS capacity to a hypervisor as a block device, much like a locally installed disk.

QNAP and Synology systems support this arrangement through their storage management applications. Once configured, VMware ESXi, Microsoft Hyper-V, Proxmox VE, and some other platforms can create a datastore or volume on the NAS for virtual machine files.

The appeal is straightforward: centralised storage, easier capacity expansion, snapshots, RAID protection, and the ability to move workloads between hosts. The trade-off is that performance depends on the complete network path, from NAS disks and controllers to Ethernet switches, cabling, and the virtualisation host.

Australian users also need to account for local conditions. An NBN connection does not improve the speed of storage traffic inside the home or office, while regional sites may have fewer options for fast business-grade networking. A sensible design therefore prioritises local Ethernet performance and reliable power rather than assuming that internet speed equals storage speed.

Why iSCSI suits virtual machine workloads

iSCSI carries SCSI commands over TCP/IP, allowing a NAS to act as a storage target and a server to act as an initiator. The hypervisor generally sees the resulting LUN as block storage, which can be formatted with VMFS, NTFS, ReFS, ZFS-related storage, or another supported datastore format depending on the platform.

This differs from an SMB or NFS file share. File-based protocols are useful for ISO images, backups, media, and shared documents, but iSCSI can provide a storage presentation that is more familiar to many hypervisors. It may also simplify features such as clustered storage, although compatibility must be checked carefully before deployment.

A one-gigabit network can support light workloads, but several virtual machines competing for storage may quickly expose its limits. A 2.5GbE or 10GbE link is a better fit for busy labs and business systems. Low latency matters as much as headline throughput, particularly when several guests generate random read and write operations at the same time.

Plan the storage path before creating a target

Start by deciding how many virtual machines the NAS will host, how much capacity they require, and whether their workloads are light, moderate, or demanding. An office file server, domain controller, and monitoring appliance may run comfortably on modest hardware, while databases, virtual desktops, and development systems need substantially more IOPS and memory.

Choose a RAID layout that suits the risk and capacity requirements. RAID 1 is simple for two drives, RAID 6 offers stronger protection for larger arrays, and RAID 10 can provide good random-write performance where usable capacity is less important. RAID is not a backup, so critical virtual machines still need a separate backup destination.

Before buying disks, review the drive shucking risks associated with removing drives from external enclosures. Shucked disks may be cheaper, but their warranty terms, firmware behaviour, vibration tolerance, and suitability for NAS workloads can vary.

Keep storage traffic on a wired network. Wi-Fi is unsuitable for dependable iSCSI operation, and powerline adapters can introduce inconsistent latency. A managed switch with separate VLANs for management, virtual machine traffic, backups, and iSCSI can improve organisation. In a Sydney office this may be easy to arrange, while a regional Queensland workshop might need a simpler but carefully documented single-switch design.

Create the iSCSI target and LUN

On a Synology NAS, the usual workflow is found in SAN Manager. On a QNAP system, Storage & Snapshots provides the relevant iSCSI tools. The names vary between operating system versions, but the concepts remain similar: create a target, assign an IQN, create a LUN, and map that LUN to the target.

The IQN is the iSCSI Qualified Name used to identify the target. Give it a clear name that includes the NAS, site, and purpose, such as a production or laboratory label. If the NAS offers thin or thick provisioning, choose deliberately. Thin provisioning saves space initially, but it requires regular monitoring so the underlying pool does not fill unexpectedly.

Use CHAP authentication when the platform supports it, especially if storage traffic crosses a shared network. Restrict access by initiator name or IP address where possible. Avoid exposing iSCSI services directly to the public internet; remote access should use a properly secured VPN or another managed private connection.

A dedicated LUN for a group of related virtual machines is usually easier to monitor than one large, anonymous volume. Separate high-priority workloads from test systems when practical. This makes snapshot schedules, capacity alerts, and recovery decisions less confusing when someone is trying to fix an issue during a busy arvo.

Connect the hypervisor and build the datastore

First configure the NAS network interface and confirm that the hypervisor can reach the iSCSI service. On the host, add the NAS as a storage target using its IP address or DNS name. The initiator should discover the target and display the available LUN after authentication succeeds.

For a single host, one reliable Ethernet path may be enough. For better resilience, use multiple network interfaces, separate switch ports, and multipath I/O if both the NAS and hypervisor support it. MPIO is more than simply plugging in two cables: it requires compatible configuration, correct network separation, and testing under failure conditions.

After the LUN is visible, allow the hypervisor to initialise or format it as the required datastore. Do not format the LUN from the NAS and then format it again from the host unless the platform specifically requires that process. Formatting the wrong device is a destructive mistake, so verify the target identifier and capacity carefully.

Run a small test VM before migrating production systems. Measure boot time, random I/O, latency, and behaviour while another guest is active. A NAS that feels fast when copying a large video file may still perform poorly with several virtual disks issuing small, synchronised writes.

Tune performance and protect the virtual machines

SSD caching can help some NAS workloads, but it is not an automatic cure for slow virtual machine storage. Cache effectiveness depends on access patterns, available cache capacity, write protection, and the NAS model. A faster Ethernet link, more RAM, a suitable RAID layout, or enterprise-grade SSD storage may deliver a more predictable improvement.

Jumbo frames should be introduced only when every device in the path supports the same MTU correctly. A mismatched MTU can cause confusing packet loss and intermittent storage failures. In many homes and small businesses, standard 1500-byte frames with a clean 2.5GbE or 10GbE configuration are safer than an ambitious but poorly tested network.

Use NAS snapshots as a rapid recovery tool, not as the only copy of a VM. Snapshots can consume substantial capacity when virtual disks change heavily, and ransomware or an administrator mistake may affect accessible snapshots. Back up important guests to another NAS, external disk, cloud repository, or business backup platform, and test restoring an entire VM.

Australian power conditions also deserve attention. A UPS with USB or network signalling can shut down the NAS and hosts cleanly during an outage, which is valuable during summer storms, bushfire-related interruptions, or unstable power at a regional property. Check that the UPS can support the NAS, switch, and hypervisor for enough time to complete an orderly shutdown.

Practical setup recommendations

A reliable deployment is usually the result of a few disciplined choices rather than a complicated collection of features. Document IP addresses, IQNs, LUN mappings, credentials, VLANs, and recovery steps before the system becomes business-critical. For general background on storage and web resources, readers may also find NAS reference material useful when comparing related technologies.

Keep the first implementation small. One test datastore and one non-critical VM will expose network, authentication, and performance problems without putting payroll, accounting, or customer data at risk. Once the design behaves consistently, migrate workloads in stages and retain the original recovery path until backups have been verified.

A NAS iSCSI target can be an efficient foundation for virtual machine storage when its limits are understood. Build the storage pool for the workload, keep the network predictable, authenticate access, and test recovery before relying on it for essential services. Begin with a low-risk virtual machine, measure the result, and expand only after the full path has proved dependable.