How to Choose a NAS for Virtual Machines

The short answer

Choose a NAS for virtual machines by sizing for random I/O and latency first, then capacity. A suitable system needs:

• Storage designed for sustained random reads and writes
• Enough drive performance for the number of concurrent VMs
• A network link and protocol that can deliver storage without becoming the bottleneck
• RAID or another redundancy layout appropriate for the drives and workload
• Adequate NAS and hypervisor resources
• A separate, tested backup plan

A large NAS with slow hard drives can provide plenty of capacity while still making VMs feel sluggish. Conversely, an all-flash system may deliver low latency but lack the capacity, redundancy, or backup target needed for production use.

Start with the symptom or real use case

The right purchase depends on what “running VMs from a NAS” means in your environment.

VMs are slow to boot or applications feel unresponsive

This usually points to latency, random I/O, contention, or a saturated network—not simply insufficient sequential throughput.

Check:

• Whether several VMs are starting, updating, or backing up at the same time
• Whether the storage pool is nearly full
• Whether the NAS is using hard drives, SATA SSDs, or another drive type
• Whether the hypervisor is accessing storage over SMB, NFS, iSCSI, or a vendor-specific method
• Whether the network link is shared with general file traffic
• Whether snapshots, deduplication, compression, or encryption are adding workload-dependent overhead

A configuration change may solve the problem if the pool is overloaded or the network is misconfigured. If the drives cannot deliver the required random I/O, however, changing a share setting will not turn them into faster storage.

VMs perform well individually but slow down together

This is a contention problem until proven otherwise. A NAS may handle one light VM comfortably but struggle when several guests perform random reads and writes at the same time.

Measure or estimate:

• Number of simultaneously active VMs
• Boot storms and scheduled maintenance
• Database or development workloads
• Peak read and write activity
• Backup windows and snapshot schedules
• Other NAS services, such as Plex libraries, surveillance recording, file sharing, or sync jobs

Separate workloads when practical. A dedicated SSD pool for VMs, a separate hard-drive pool for bulk files, or scheduled backups outside peak hours can be more effective than simply adding capacity.

The NAS has fast drives but the VMs are still slow

Investigate the entire path:

1. VM guest configuration
2. Hypervisor storage settings
3. NAS protocol and datastore configuration
4. Network speed, path, and congestion
5. NAS CPU and memory usage
6. Storage-pool layout and drive health
7. Background services and snapshots

A fast SSD pool cannot overcome a congested network, poor queue handling, a misconfigured datastore, or an overloaded NAS processor.

Define the VM workload before choosing capacity

Start with the VMs, not the number printed on the NAS product page.

Record for each VM:

• Virtual disk capacity currently used
• Expected growth over the replacement period
• Operating system and application requirements
• Memory allocation
• Number of virtual CPUs
• Whether the workload is mostly idle, transactional, development, or database-oriented
• Required recovery point and recovery time
• Whether the VM can be restored from backup instead of remaining online during a hardware failure

Add capacity for the NAS operating system, snapshots, temporary files, updates, and future VMs. Do not plan to fill a storage pool to its nominal usable limit. The amount of free space a pool needs depends on its filesystem, RAID design, snapshots, and workload, so follow the NAS and filesystem vendor’s guidance rather than applying an invented universal percentage.

A simple planning model is:

Required usable capacity = current VM data + projected growth + snapshots + operational headroom + non-VM data

Worked example:

• Current virtual disks: 2 TB
• Expected VM growth: 1 TB
• Snapshot and recovery workspace: 1 TB
• Other NAS data: 4 TB

Minimum planned usable capacity = 2 TB + 1 TB + 1 TB + 4 TB = 8 TB

This is a planning total, not a raw-drive requirement. RAID, filesystem overhead, and vendor-reported capacity differences mean the installed drive capacity must be higher.

Separate compute requirements from storage requirements

There are two different designs:

1. A separate hypervisor runs the VMs and uses the NAS as shared storage.
2. The NAS itself runs the VMs.

Using the NAS as shared VM storage

In this design, the NAS needs storage, networking, memory, and enough processing capacity to serve the requested protocol and other services. The hypervisor provides the VM compute resources.

This is often easier to expand or manage independently, but it makes the network and storage protocol part of every VM read and write.

Running VMs directly on the NAS

Here, the NAS must also provide:

• Sufficient CPU resources
• Enough memory for the NAS operating system, filesystem, services, and guests
• A supported virtualization platform
• Appropriate VM management features
• Storage fast enough for both the guests and NAS services
• A recovery method if the NAS itself is unavailable

Do not assume that a NAS with a virtualization feature is suitable for any operating system or workload. Check the current vendor documentation for supported guest operating systems, memory limits, virtual networking, storage formats, backups, and passthrough features.

Choose storage for latency and random I/O

VM storage is commonly more sensitive to latency and random I/O than to peak sequential transfer speed.

Hard-drive pools

Hard drives can make sense when:

• Capacity is the primary requirement
• The VMs are light or mostly idle
• The NAS will also store large sequential files
• The budget favors capacity over responsiveness
• The workload can tolerate slower boot, update, and application response

Their limitations become more visible with multiple active VMs, databases, software builds, indexing, and concurrent backup jobs.

SSD pools

SSDs are generally the more direct choice for lower-latency VM storage, but the exact result depends on the drive type, pool layout, controller, filesystem, workload, and network.

Evaluate:

• Endurance rating and warranty conditions
• Capacity after redundancy and free-space requirements
• Sustained write behavior
• Power-loss protection where appropriate for the workload
• NAS and drive compatibility
• Replacement availability
• Whether the NAS supports the intended SSD pool configuration

Do not compare SSDs only by advertised sequential speed. VM performance is often determined by small, concurrent reads and writes.

Mixed pools

A practical design may use:

• An SSD pool for active VM datastores
• A hard-drive pool for media, archives, backups, or less demanding files

This is useful only if the NAS supports the intended pools and the workloads can be placed separately. Adding SSDs to a system does not automatically move existing VM data or eliminate contention.

Understand SSD cache limitations

SSD cache is not the same as an SSD storage pool.

A cache may help with frequently accessed data, but its effectiveness depends on the workload and cache implementation. VM workloads can contain substantial writes, data that is accessed unpredictably, or working sets larger than the cache.

Before paying for cache hardware, ask:

• Is the cache read-only, write-through, or write-back?
• What happens during a power failure?
• Are the cache devices redundant?
• Does the NAS require specific SSD types?
• How is cache data rebuilt after a device failure?
• Can the cache absorb the VM workload without becoming a bottleneck?
• Can the same budget provide a dedicated SSD pool instead?

A dedicated SSD pool is usually easier to reason about because the VM data resides directly on the faster media. Cache can still be useful, but it should be selected based on measured workload behavior rather than treated as a universal VM upgrade.

Select the network around the storage workload

The network connects the hypervisor to every VM disk operation when the NAS is used as shared storage.

Theoretical bandwidth can be estimated as:

Bandwidth (Gbps) / 8 = theoretical GB/s

For megabytes per second:

Bandwidth (Gbps) × 1,000 / 8 = theoretical MB/s

These are link-rate calculations, not guaranteed application performance. Protocol overhead, network equipment, NAS processing, storage latency, queueing, and concurrent traffic reduce the result.

For example:

1 Gbps × 1,000 / 8 = 125 MB/s theoretical

That ceiling may be acceptable for light VM use, but it can constrain several active VMs even when the NAS has faster drives. Faster networking can help only when the NAS storage and the rest of the path can use it.

Check:

• NAS network ports
• Hypervisor host ports
• Switch capacity and configuration
• Cabling requirements
• VLAN or network segmentation needs
• Link aggregation support and limitations
• Whether the VM storage network is shared with users, surveillance, media streaming, or backups
• Whether the chosen protocol and hypervisor support multipathing or other redundancy features

Link aggregation does not necessarily make one individual storage session run at the combined speed of multiple links. Its benefits depend on the protocol, traffic distribution, and equipment.

NFS, iSCSI, and SMB

The correct protocol depends on the hypervisor and NAS support.

• NFS can be straightforward for hypervisors that support it and may work well for shared datastores.
• iSCSI presents block storage and may be appropriate where the hypervisor expects or benefits from block devices.
• SMB can be suitable in supported environments, but VM and cluster support must be verified rather than assumed.

Compare the exact features you need:

• Shared datastore access
• Snapshots and cloning
• Multipathing
• Persistent reservations
• Live migration
• Failover behavior
• Permissions and authentication
• Backup integration

Do not choose a protocol solely because it is familiar for ordinary file shares.

Choose RAID and filesystem deliberately

RAID provides availability or redundancy against certain drive failures. It does not replace backups, protect against accidental deletion, prevent ransomware, or guarantee that a corrupted file will be recoverable.

RAID trade-offs for VM storage

• Mirrors can provide strong read performance, simpler rebuild behavior, and good write responsiveness, but usable capacity is lower.
• Parity RAID can provide more usable capacity, but parity calculations and read-modify-write behavior may affect write latency, especially with smaller random writes.
• Dual-parity layouts offer protection against more simultaneous drive failures than single-parity layouts, but write performance, capacity efficiency, and rebuild behavior must be evaluated for the specific implementation.
• Single-drive redundancy may be inadequate for a large or important VM pool if a second drive failure during a rebuild would be unacceptable.

The best layout depends on drive count, drive size, workload, rebuild exposure, and the value of the VMs. Use the NAS vendor’s usable-capacity calculator and documented RAID support; do not infer exact capacity or performance without the actual drive and configuration details.

ZFS and other copy-on-write filesystems

If choosing ZFS or another advanced filesystem, evaluate the whole storage design:

• Pool layout and vdev structure
• Memory requirements
• Snapshot behavior
• Checksumming and integrity features
• Compression
• Deduplication requirements
• Scrubbing and monitoring
• Expansion limitations
• Backup and replication tools

ZFS pool expansion and vdev replacement behavior can differ from traditional RAID systems. Plan the initial layout carefully. Compression may reduce physical writes for compressible data, while deduplication can require substantial resources and should not be enabled without a measured use case and adequate planning.

RAID is not backup

Maintain an independent copy of important VM data. A robust plan may include:

• Hypervisor-aware VM backups
• NAS snapshots for short-term rollback
• Replication to another system
• An offline or otherwise isolated copy
• Off-site or cloud storage where appropriate
• Regular restore tests

A snapshot on the same NAS is useful for some recovery scenarios but is not an independent backup if the NAS, pool, account, or site is compromised.

Check NAS memory and processor requirements

NAS hardware affects VM storage even when the VMs run on a separate host.

More memory may be useful for filesystem caching, metadata, multiple services, and concurrent connections. Processor capacity matters for protocol handling, encryption, compression, checksums, snapshots, indexing, and other services. The required amount depends on the workload and platform, so do not select a precise memory or CPU number without measuring the environment and checking vendor guidance.

If the NAS also handles Plex transcoding, surveillance recording, containers, sync, or intensive file indexing, those services compete with VM storage. Consider disabling unnecessary services, scheduling heavy tasks, or separating workloads across pools or systems.

Account for power, cooling, and expansion

VM storage is usually expected to remain available, so operational details matter.

Consider:

• UPS support and safe shutdown behavior
• Power-loss protection for selected SSDs where appropriate
• Drive temperature and airflow
• Noise and location
• Drive replacement access
• Spare drive strategy
• Network equipment power protection
• Monitoring and alerting
• Firmware and security update procedures

Expansion also needs advance planning. Confirm:

• Whether additional drive bays are available
• Whether the filesystem or RAID design supports the expansion path you want
• Whether expansion requires replacing drives one at a time
• Whether larger drives can be mixed with existing drives
• Whether expansion changes redundancy or performance
• Whether the NAS supports a separate SSD pool later
• Whether network ports can be upgraded or expanded

Do not buy a small chassis expecting every future expansion method to be available. Filesystem and RAID expansion rules can be more restrictive than the number of empty bays suggests.

Distinguish configuration fixes from hardware limits

Before replacing the NAS, test the likely bottleneck.

Configuration problems that may be fixable

• VM datastore is on the wrong pool
• Network link negotiated at a lower speed
• Storage traffic shares a congested network
• Snapshots or backups run during peak activity
• NAS indexing, media processing, or surveillance consumes resources
• The VM has excessive memory pressure or storage queueing
• Incorrect permissions or protocol settings cause retries
• A cache policy is unsuitable for the workload
• The pool is too full
• A drive is reporting errors or reduced performance

Hardware limits that usually require a redesign

• The drives cannot provide the required random I/O
• The NAS lacks sufficient CPU or memory for its services
• The network ports are slower than the workload requires
• The chassis cannot provide the desired redundancy
• The pool cannot be expanded in the required way
• The system lacks support for the required hypervisor protocol or feature
• The NAS has no practical path to a separate SSD pool
• The backup window is longer than the available operating window

Benchmark with a representative, non-destructive test plan. A sequential benchmark alone is not enough. Test latency, random reads and writes, queue depth, concurrent VM behavior, and performance during backups or snapshots.

A practical NAS-for-VM decision checklist

Before buying, answer these questions:

Workload

• How many VMs will run concurrently?
• Which VMs are latency-sensitive?
• Are databases, development tools, or transactional applications involved?
• What are the peak I/O periods?
• Will Plex, surveillance, file sharing, or sync run on the same NAS?

Capacity

• What is the current virtual-disk footprint?
• How fast will it grow?
• How much space is required for snapshots and operational headroom?
• Which data belongs on SSDs and which belongs on high-capacity hard drives?

Redundancy and recovery

• Which RAID or pool layout meets the acceptable failure risk?
• How long could a rebuild take for the selected drives?
• Are VM backups stored separately from the primary pool?
• Has a full VM restore been tested?
• Is there protection from site, account, and ransomware failures?

Networking

• What speed can the NAS, hypervisor, and switch support?
• Is storage traffic isolated or shared?
• Does the chosen protocol support the required clustering, migration, and failover features?
• Are multipathing or redundant links needed?

Drives and filesystem

• Are the drives approved or supported by the NAS vendor?
• Do SSD endurance and power-loss characteristics fit the workload?
• Is the RAID or ZFS layout appropriate for random writes and rebuilds?
• Is SSD cache actually needed, or would a dedicated SSD pool be clearer?

Compute and expansion

• Does the NAS run the VMs, or only serve storage?
• Does it have enough CPU and memory for all enabled services?
• Can the storage pool and network be expanded later?
• Is a UPS and monitoring plan included?

Final buying guidance

For light, non-critical VMs, a redundant hard-drive NAS with a suitable network may be sufficient. For several active VMs or latency-sensitive applications, prioritize a dedicated SSD pool, a network that does not cap the workload, and a redundancy layout designed around write behavior and rebuild risk.

If the NAS itself will run the VMs, treat it as both a virtualization host and a storage server. If a separate hypervisor will use the NAS, focus on datastore protocol support, network reliability, storage latency, and backup integration.

There is no reliable universal specification for “VM-ready” NAS performance. The correct choice depends on the guest workloads, concurrency, drive layout, filesystem, network path, and recovery requirements. Use the vendor’s current compatibility and capacity documentation, then validate the design with representative tests.

When you are ready to compare systems, Browse NAS or narrow the search to NAS and storage servers.