Where Should You Store Homelab VM Disks?

For one external hypervisor host, local NVMe is usually the simplest way to keep active VMs responsive. A NAS can then hold backups, installation images, media, and bulk application data.

Shared NAS storage becomes more useful when multiple hosts need access to the same VM disks or when compute hardware should be replaceable without relocating the datastore. Dedicated or distributed storage is justified when one NAS represents too much downtime risk or the workload needs redundant storage paths and consistently low latency.

NAS vs. SAN for VM Storage: The Short Answer

A NAS usually provides file-level storage through protocols such as NFS and SMB. A storage area network provides block-level storage, commonly through Fibre Channel or iSCSI. UGREEN NAS can provide NFS or SMB file storage and,  SAN Manager can iSCSI block storage to compatible external clients.

Dedicated storage becomes relevant only when the environment requires capabilities that a single NAS cannot provide.

Are the VMs Running on the NAS or Using the NAS as Storage?

UGREEN supports two distinct VM architectures, and the storage options are different for each one.

The VM Runs Directly on the UGREEN NAS

UGREEN’s built-in Virtual Machine Manager is available only on DXP models. Virtual-machine support is unavailable on the DH2300 and DH4300 Plus.

On a supported DXP model, the NAS provides both compute and storage. The VM runs inside UGOS Pro and stores its virtual disks in a local NAS storage space. This arrangement fits light virtualization when the NAS has enough processor and memory resources for the guest and keeping the environment compact matters more than separating compute from storage.

If this is your intended architecture, follow the complete guide to hosting virtual machines on UGREEN NAS.

A Separate Hypervisor Uses the NAS as a Datastore

In this arrangement, Proxmox, ESXi, Hyper-V, or another host supplies the compute resources. The UGREEN NAS supplies storage over the network through NFS, iSCSI, or an appropriate SMB configuration.

This design is useful when:

• The VM host needs more processor power or memory than the NAS provides.
• Compute hardware should be replaceable without rebuilding the storage system.
• Multiple hosts need centralized access to VM disks.
• Storage capacity will grow independently of compute requirements.
• The NAS must continue serving files and backups while the hypervisor restarts.

If you are deciding whether one system should handle both roles, compare the trade-offs in our NAS versus home server guide.

Local NVMe vs. NAS Storage for VMs

Local NVMe minimizes storage latency and removes the network from the active VM I/O path. It is usually the strongest starting point for a single host running databases, development environments, game servers, or several busy operating systems.

NAS storage trades some simplicity and latency for centralized capacity. It can make host replacement easier, allow compatible hosts to access the same datastore, and keep storage growth separate from compute upgrades. In return, every dependent VM now relies on the NAS, network interface, cable, switch path, permissions, and storage protocol.

Choose local NVMe when responsiveness and simplicity matter most. Choose a NAS datastore when shared access, capacity, or operational flexibility provides a clear benefit.

NFS vs. iSCSI vs. SMB for VM Storage

NFS: Straightforward Shared File Storage

NFS provides file-level storage. The NAS exports a shared folder, and the hypervisor stores VM disk-image files inside it.

NFS fits when:

• The hypervisor supports NFS datastores directly.
• More than one compatible host needs access to the same datastore.
• File-level storage fits the hypervisor’s image and snapshot workflow.
• Simple provisioning matters more than presenting block storage.

In UGOS Pro, enable NFS, assign access only to the required host addresses, and keep the export on a trusted storage network. An encrypted UGREEN Btrfs shared folder cannot be used through NFS, so account for that limitation before creating the datastore.

iSCSI: Block Storage for a Supported Host

iSCSI presents a logical unit, or LUN, to a client as block storage. The client or hypervisor then manages that block device according to its storage design.

The UGREEN DXP2800, DXP2800 GT, DXP4800 Plus, DXP4800 Pro, DXP4800GT, DXP6800, DXP6800 Pro, and DXP8800 Plus all support SAN Manager, and can create iSCSI LUNs and targets for compatible external clients.

{{UGPRODUCT}}

iSCSI is not inherently faster than NFS. Both protocols still depend on the drives, RAID layout, NAS resources, network path, queue behavior, and workload.

UGREEN-Hosted VMs and iSCSI Serve Different Architectures

A VM running inside the UGOS Pro Virtual Machine application cannot use a NAS-created iSCSI LUN directly as its virtual disk.

SAN Manager is intended to expose iSCSI storage to compatible external clients. If a VM running directly on the NAS needs access to NAS files, use an appropriate shared-folder protocol inside the guest operating system.

SMB 3: An Option for Qualifying Hyper-V Environments

Hyper-V can use qualifying SMB 3 storage, but the design requires more than enabling a normal file share. The storage server, Hyper-V hosts, authentication method, permissions, and network must meet Microsoft requirements. Managed deployments may also need to grant the Hyper-V host computer accounts access to the share.

Use SMB for active Hyper-V disks only after confirming that the exact deployment supports the required storage, migration, availability, and backup behavior. For a simple Hyper-V homelab, local storage or a carefully configured iSCSI target may be easier to validate.

What Actually Determines VM Storage Performance?

The protocol is only one layer in the complete storage path:

VM > hypervisor > storage protocol > host NIC > switch > NAS NIC > storage pool > drives

The slowest or least stable layer can determine the result.

Benchmark the completed storage path with a workload that resembles the applications inside the VMs. A sequential file-copy result does not predict database, operating-system, or multi-VM performance.

Match the Drives to Random I/O

Active VMs generate frequent small reads and writes from operating-system updates, logs, swap files, databases, temporary files, and metadata. SSD or NVMe storage is the stronger choice for several simultaneous VMs, write-heavy services, databases, and workloads that need consistent latency.

HDD storage remains useful for installation images, backups, archived VM images, infrequently used lab machines, media, and other capacity-oriented data. For a mixed pool strategy, see how to use SSDs and HDDs together in UGREEN NAS.

SMR drives are a poor fit for active VM storage because sustained and random writes can trigger severe slowdowns, especially during heavy workloads and RAID rebuilds. Use suitable CMR NAS or enterprise drives when mechanical storage must carry active VM disks.

Choose RAID for the Workload, Not Just Capacity

RAID 10 can provide more predictable random-write behavior on an HDD array because it uses mirrored pairs instead of distributed parity. Its main compromise is capacity efficiency: approximately half of the raw capacity is available before filesystem and system overhead.

RAID 5 and RAID 6 provide more usable capacity, but small writes require additional parity work. That overhead can matter when several active VMs generate random writes. RAID 6 tolerates two drive failures but performs more parity work than RAID 5.

Base the decision on drive count, write intensity, required capacity, acceptable rebuild risk, and backup availability. The RAID selection guide for NAS explains the broader trade-offs. RAID protects against specified drive failures; it does not replace a VM backup.

Treat SSD Cache as an Optional Layer

SSD cache can help workloads that repeatedly access the same data, but it cannot compensate for an undersized or unsuitable primary storage pool. For active write-heavy VM disks, an SSD storage pool is generally more predictable than relying on cache to absorb the workload.

Use write caching only when the NAS, SSDs, filesystem, and power-protection design can handle power loss safely.

Using UGREEN NAS as an External VM Datastore

UGOS Pro can provide file storage through NFS or SMB and, on supported systems, block storage through SAN Manager. Choose the service that matches the external hypervisor rather than forcing every platform into the same protocol.

Create an NFS Datastore

1. Enable NFS in UGOS Pro.
2. Create or select an unencrypted shared folder.
3. Add NFS permissions for the required hypervisor host or storage network.
4. Record the exported mount path.
5. Add the export through the hypervisor’s supported datastore workflow.
6. Test file creation, VM startup, and reconnection before migrating important workloads.

Keep the export restricted to the systems that require it.

Create an iSCSI Datastore

Where SAN Manager is supported:

1. Install and open SAN Manager.
2. Create a LUN on the intended storage space.
3. Create an iSCSI target and associate it with the LUN.
4. Configure CHAP authentication when appropriate.
5. Limit access to the required initiators.
6. Connect from the external host or hypervisor.
7. Configure the storage through the hypervisor’s supported workflow.
8. Test disconnection and recovery before moving important VMs.

Keep iSCSI on a trusted storage network rather than exposing it directly to the public internet. Use SSD-backed storage when the LUN will contain active, latency-sensitive VM disks.

Configure SMB for Hyper-V

Enable SMB and create a restricted shared folder only after confirming that the Hyper-V environment supports the intended SMB architecture. Verify the SMB version, authentication, host-account permissions, networking, and availability requirements before storing active virtual disks on the share.

What Shared Storage Enables—and What It Still Depends On

Live Migration Still Depends on the Hypervisor

Shared storage can remove the need to copy an entire VM disk during migration because the source and destination hosts can access the same datastore. Successful live migration still requires:

• A compatible hypervisor cluster
• Access to the same VM disk from both hosts
• Compatible processor and VM settings
• Correct migration and storage networking
• Sufficient bandwidth
• Correct storage permissions
• Healthy cluster membership

The NAS supplies the storage layer; the hypervisor controls the migration.

One NAS Remains a Shared Failure Domain

Centralizing VM disks reduces dependence on one compute host but increases dependence on the NAS and network. If the NAS shuts down, loses its storage pool, or becomes unreachable, every VM using that datastore may stop responding.

Before centralizing active disks, define the acceptable downtime, protect the NAS and necessary network equipment with a UPS, identify single network paths, and test how the hosts respond when storage becomes unavailable.

Use Snapshots for Rollback and Backups for Recovery

Snapshots are useful for short-term rollback, but they are not independent backups. Keep these protection layers separate:

• A UGREEN Virtual Machine snapshot records the state of a VM running in Virtual Machine Manager.
• A Btrfs shared-folder snapshot protects supported folder data on that storage space.
• A hypervisor snapshot records VM state according to that platform’s storage capabilities.
• An application-consistent backup coordinates with the guest operating system or application.
• An independent backup keeps recoverable data outside the primary datastore.

A NAS-level snapshot does not automatically create an application-consistent backup of an externally hosted VM. Critical VMs need a backup process supported by the hypervisor or guest operating system, plus a recoverable copy stored outside the primary datastore. Build that protection around an independent NAS backup strategy.

When Dedicated or Distributed Storage Is Justified

Dedicated storage becomes reasonable when the cost of downtime exceeds the cost and complexity of additional infrastructure. Typical triggers include:

• Many hosts depending on the same storage
• Large databases requiring consistently low latency
• VDI or other workloads generating sustained random I/O
• Storage that must remain available during controller or node failure
• Multiple redundant network paths
• Predictable quality-of-service requirements
• Synchronous replication
• Capacity or fault-isolation requirements beyond one NAS

The reason to add dedicated or distributed storage is to obtain specific capabilities that a simpler local or NAS-based design cannot provide—not because the SAN label guarantees speed.

Predeployment Checklist

Before moving active VM disks to a NAS, confirm:

• Whether the VM will run directly on a supported DXP model or on an external hypervisor
• The hypervisor supports the selected storage protocol
• The NAS model and UGOS Pro version provide the required service
• Every required host can reach the datastore through a trusted network
• Shared iSCSI access uses a supported coordinated storage design
• The host, switch, cables, and NAS support the intended link speed
• The storage pool provides enough random-I/O performance and free capacity
• Heavy NAS tasks will not compete with critical VM workloads
• Power protection covers the NAS and required network equipment
• NAS maintenance windows are acceptable for dependent VMs
• Critical VMs have independent backups
• Restore behavior and NAS or network failure have been tested

If an existing deployment performs poorly, use the NAS VM performance troubleshooting guide to isolate the network, storage pool, protocol, host, or guest bottleneck.

Final Takeaway

For one external host, local NVMe with NAS-based backups is usually the cleanest design. For a small multi-host homelab, shared NFS is often the most manageable starting point. iSCSI is valuable when block storage is specifically required and the ownership model is configured correctly. Dedicated or distributed storage belongs in environments that can name the availability or performance capability they need from it.

Frequently Asked Questions

Is NAS storage fast enough for virtual machines?

Yes, when the storage pool, network, and protocol can support the workload. Several light VMs may run well over 2.5GbE, while busy databases or many simultaneous guests may require SSD storage, 10GbE, or a different architecture. Test the complete storage path rather than judging performance from link speed alone.

Should Proxmox use NFS or iSCSI?

NFS is often the simpler starting point for a small Proxmox environment because it provides straightforward shared file storage. iSCSI is appropriate when block storage is specifically required and the Proxmox storage layer is configured for coordinated access. Protocol choice alone does not determine performance.

Can UGREEN NAS provide iSCSI storage for VMs?

Where SAN Manager is available on the UGREEN NAS model and UGOS Pro version, it can create a LUN and target for a compatible external hypervisor. A VM running directly inside UGREEN Virtual Machine Manager cannot use a NAS-created iSCSI LUN as its own virtual disk.

Can multiple hypervisor hosts share the same iSCSI LUN?

Only when the hypervisor and storage configuration explicitly support coordinated shared-block access. Ordinary clients mounting the same writable LUN independently can corrupt the filesystem.

Does NAS storage enable live migration?

Shared NAS storage can satisfy the shared-disk requirement for some migration workflows, but live migration also depends on the hypervisor cluster, host compatibility, permissions, networking, and migration configuration.

Are NAS snapshots enough to back up virtual machines?

No. Snapshots remain on or depend on the primary storage environment and may not be application-consistent. Critical VMs need a supported backup process and a recoverable copy stored outside the primary datastore.