Build a two-node Hyper-V cluster without a SAN using Storage Spaces Direct

Small businesses and remote offices often assume that a highly available Hyper-V cluster needs three separate investments: two virtualisation hosts, a SAN or other shared-storage appliance, and the network fabric connecting them. That traditional design still has valid uses, but it is not the only way to build a Windows Server cluster.

Storage Spaces Direct, usually shortened to S2D, combines the internal drives in two or more Windows servers into shared cluster storage. In a two-node hyperconverged design, the same two servers provide compute, storage and failover. Virtual machines run on Cluster Shared Volumes and can move between the nodes without a separate SAN.

This makes S2D particularly relevant to organisations that need local resilience but cannot justify a dedicated storage array: branch offices, factories, clinics, schools, retail sites and small server rooms. Many Windows administrators know Hyper-V and Failover Clustering but are not aware that Windows Server can also provide the resilient storage layer.

The important wording is without a separate shared-storage appliance, not without storage. Each server still needs multiple suitable local drives, fast links to its partner, a quorum witness, tested backups and enough spare capacity to survive maintenance and failure.

A two-node S2D cluster can therefore be a sensible way to run a small highly available Hyper-V platform without buying a SAN. It can also become an expensive experiment if the design starts with two cheap servers and treats network adapters, drive endurance, quorum and recovery capacity as details to solve later.

The most economical design I would build today is two identical all-flash servers, four enterprise SSDs per node, two direct 10 or 25 GbE links between the nodes, separate management connectivity and a witness outside the cluster. That removes the storage switch from the first version and avoids spending two additional drive bays per node on cache devices.

There are two different meanings of cheap, and they should not be mixed:

• A learning cluster can use second-hand enterprise equipment and accepts that the hardware combination is not supported for production.
• A small production cluster can reduce cost through two nodes and switchless networking, but its complete server, HBA, NIC, drive and firmware combination still needs vendor support.

This article covers Windows Server Storage Spaces Direct. It is not an Azure Local deployment guide, and it does not suggest that a collection of compatible-looking components is a validated production solution.

What the small organisation gains

The design removes the separate storage array and its associated controllers, licences and storage-network dependencies. It also gives the organisation a practical maintenance model: move or drain virtual machines from one node, patch or repair that server, return it to service, wait for storage to resynchronise, and then maintain the second node.

If one server fails, the surviving node continues serving the mirrored storage and can run the critical virtual machines, provided it was sized with enough CPU and memory. When the failed node returns, S2D resynchronises its data automatically. This is high availability within the site; it does not protect against fire, theft, ransomware, accidental deletion or loss of the whole location.

For an IT team already administering Windows Server, Hyper-V and PowerShell, this can reduce the number of technologies that must be learned and supported. The trade-off is that storage health, network health and Hyper-V capacity now share the same two physical servers, so monitoring and operational discipline matter.

Where a two-node cluster fits

Good use cases include:

• A branch or remote office that needs a small number of locally available virtual machines and must keep operating through one server failure.
• A small organisation consolidating Active Directory, file, management and line-of-business workloads onto two Hyper-V hosts.
• A site replacing one large standalone Hyper-V server with a platform that can be maintained without shutting down every workload.
• Edge workloads where local operation must continue through a single server outage.
• A small Scale-Out File Server for continuously available SMB storage.
• A training platform for Failover Clustering, Hyper-V, S2D, quorum, Cluster-Aware Updating and failure testing.
• A secondary site where workloads are also protected by an independent backup and replication design.

It is a poor fit when:

• The only requirement is inexpensive bulk or backup storage. A two-node mirrored flash cluster is usually the wrong cost model for archive capacity.
• The business expects the cluster itself to provide site disaster recovery. Both nodes in one room remain one site failure domain.
• The workload needs more capacity or write performance than two servers can provide.
• There is no third location or service for a quorum witness.
• Nobody will monitor physical disks, storage jobs, firmware, network health and free pool capacity.
• The plan depends on consumer SSDs, USB storage, shared RAID LUNs or one storage network path.

S2D in one minute

Traditional failover clusters expect both servers to see the same storage. That storage commonly comes from a SAN. Storage Spaces Direct changes the model: every drive is directly attached to one server, and Windows combines those drives into a cluster-wide software-defined pool.

S2D keeps copies of data across the nodes. Hyper-V stores its virtual disks and configuration on Cluster Shared Volumes created from that pool. SMB3 carries storage traffic and resynchronisation between the servers. Failover Clustering decides where virtual machines run, while a witness helps the two-node cluster maintain quorum when one node is unavailable.

There is no shared RAID shelf and neither server directly mounts the other server’s disks. The shared-storage behaviour is created by Windows across fast Ethernet links.

The architecture

Each node contributes its own direct-attached drives to one S2D storage pool. Cluster Shared Volumes are created from that pool and hold Hyper-V virtual machines or Scale-Out File Server data. SMB Multichannel carries storage traffic between the nodes.

For two nodes, place the witness outside both servers. A Cloud Witness uses a small Azure Storage blob, while a File Share Witness uses a dedicated SMB share. A disk witness is not supported with Storage Spaces Direct. The witness stores cluster voting information; it is not a third copy of your data.

                 Cloud Witness or File Share Witness
                              |
                    Management network
                     /                 \
              +-------------+     +-------------+
              |   S2DNODE01 |     |   S2DNODE02 |
              | Hyper-V/S2D |     | Hyper-V/S2D |
              +-------------+     +-------------+
                 ||       ||  direct 10/25 GbE storage links
                 ||=======||  Link A and Link B
                 ||       ||
              4 x enterprise     4 x enterprise
              SSD capacity       SSD capacity

Two direct links remove the need for a storage switch at this scale. They do not remove the need for separate management access, redundant network adapters or careful IP and cluster-network configuration.

Hardware bill of materials

The learning build

Use this to learn, demonstrate and test. Do not present it as a supported production design.

Item	Recommendation per node	Why
Chassis	Two identical second-hand enterprise servers with at least six usable drive bays	Four capacity drives plus resilient boot, with matched firmware and layout
CPU	One modern server CPU with at least 8 physical cores	Enough for the host, storage processing and several small lab VMs
Memory	64 GB ECC minimum; 128 GB preferred	Fixed host overhead plus useful capacity for clustered VMs
Boot	Two 240 GB or larger enterprise boot devices in RAID 1, or the vendor’s mirrored boot module	Separates the operating system from the S2D pool
Capacity	Four identical 960 GB or 1.92 TB enterprise SAS/SATA SSDs with power-loss protection	Meets the Windows Server all-flash physical minimum and keeps the layout symmetric
Storage controller	A true SAS HBA or a controller mode that directly passes through each supported SAS drive	S2D must see the physical drives; do not create one-drive RAID 0 virtual disks
Storage network	Two identical dual-port 10 GbE SFP+ adapters, using one direct link per port pair	Cheap used 10 GbE equipment is sufficient for learning SMB Multichannel
Management	One or two 1 GbE ports	Keeps management reachable while storage links are isolated
Cabling	Four supported SFP+/DAC cables in total for two direct networks	No storage switch is required for two nodes
Power	Dual power supplies per server, ideally on independent protected feeds	Removes an avoidable single-device failure
Witness	Small Cloud Witness or a File Share Witness outside both nodes	Maintains cluster quorum when one node is unavailable

Used adapter families such as Intel X520/X710 and NVIDIA/Mellanox ConnectX can be economical, but the family name alone proves nothing. Confirm the exact part number, transceiver or DAC, driver, firmware and Windows Server release. Avoid online listings that omit the manufacturer part number or photograph a different adapter revision.

The small production build

Item	Practical starting point	Production requirement
Servers	Two identical current or vendor-supported systems	Exact configured solution supported for S2D by the server vendor
CPU	12–24 physical cores per node	Size from measured VM CPU demand and leave failover headroom
Memory	128 GB minimum; 256 GB is a more useful starting point	One node must carry the critical workload during maintenance or failure
Boot	Vendor-supported mirrored boot devices, 200 GB or larger	Monitor boot-device health independently of S2D
Capacity	Four or more identical enterprise SSDs per node	Power-loss protection, endurance and firmware supported by the vendor
Network	Two 10 or 25 GbE storage paths per node	Identical adapters, drivers and firmware; RDMA when the validated design supports it
Management	Redundant management ports or a supported converged design	Preserve administrative access during one path failure
Power	Redundant PSUs and independent power paths	Test the intended power-failure boundary
Witness	Cloud or File Share Witness in an independent failure domain	Monitor witness reachability and document recovery behavior
Support	Server, drive and NIC support with replacement access	A cluster is only recoverable as quickly as failed parts can be replaced

For production, start with the vendor’s supported configuration rather than choosing a chassis and attempting to make every installed component fit afterward. Run the full cluster validation suite and keep its report as build evidence.

Drive selection: where low-cost builds usually fail

Windows Server physical deployments require at least four all-NVMe, all-SSD or all-persistent- memory capacity drives per server. If a cache tier is used, each server needs at least two additional cache devices. Drives must be symmetric across nodes, and SSDs must provide power-loss protection.

That makes four enterprise SSD capacity drives with no dedicated cache the simplest small all-flash design. Microsoft notes that pool caching has limited benefit for small all-flash deployments, while omitting cache increases usable capacity and reduces the number of drives to buy.

Use the same:

• Drive count on each node.
• Media type and interface.
• Capacity and endurance class.
• Model and firmware wherever possible.
• Controller/HBA path and enclosure layout.

Do not use:

• Consumer SSDs without documented power-loss protection.
• USB drives.
• RAID virtual disks in place of physical-drive pass-through.
• SAN, Fibre Channel, iSCSI or FCoE LUNs as S2D capacity.
• Shared SAS storage or disks visible through multiple paths.
• A mixture of whatever drives were available cheaply.

Drive endurance matters because write amplification, repair and rebalance activity are part of normal operation. If dedicated cache is used, Microsoft recommends high-endurance cache devices of at least 3 drive writes per day or 4 TB written per day.

Capacity: raw terabytes are not usable terabytes

Assume each node has four 1.92 TB SSDs:

Raw capacity = 2 nodes × 4 drives × 1.92 TB = 15.36 TB

The approximate capacity before filesystem and reserve considerations is:

Resiliency	Approximate efficiency	Approximate usable from 15.36 TB	Failure model
Two-way mirror	50%	7.68 TB	One server or one drive failure at a time
Nested two-way mirror	25%	3.84 TB	A server plus a drive in the surviving server, or two drive failures
Nested mirror-accelerated parity	About 35–40%	About 5.38–6.14 TB	Improved two-node fault tolerance with a capacity/performance trade-off

Do not allocate all calculated usable capacity. Repairs and rebalancing need free pool capacity, and CSVs need operating headroom. I would plan workload capacity from the usable figure after resiliency, then reserve at least one capacity drive’s worth per node as a starting operational allowance and refine it from the vendor design and failure model.

Microsoft recommends nested resiliency for production two-server clusters because ordinary two-way mirror protects against only one hardware failure at a time. Nested two-way mirror is simple and fast but expensive in capacity. Nested mirror-accelerated parity improves efficiency but is more complex and should be validated against the actual workload.

Memory and CPU sizing

The cluster does not make compute capacity free. During a node outage, the remaining server must run the critical VMs and the storage stack while repair or resynchronisation may also be active.

A practical calculation is:

Memory per node = host reserve + S2D metadata + all critical VM memory + growth headroom

Microsoft requires memory for Windows Server and workloads plus 4 GB per TB of cache capacity on each server for S2D metadata. That cache-capacity rule is not a complete host sizing formula.

For a small production cluster, design normal utilisation so either node can absorb the critical VMs. If both nodes normally run at 80% memory, failover is a promise the hardware cannot keep. Treat 128 GB per node as an entry point, not a universal recommendation; 256 GB often gives a more workable balance for several infrastructure and application VMs.

Network design

Storage Spaces Direct uses SMB3, SMB Multichannel and, when configured, SMB Direct. Microsoft requires at least 10 GbE for a small two- or three-node cluster and recommends two or more connections per node for redundancy and performance.

For a low-cost two-node cluster:

1. Use two identical 10 or 25 GbE ports per node for storage traffic.
2. Connect port A directly to port A on the other node and repeat for port B.
3. Put the two links on separate IP subnets.
4. Retain separate management connectivity.
5. Confirm SMB Multichannel uses both intended paths.
6. Use RDMA only when the adapters, drivers, firmware and configuration form a supported design.

Useful read-only checks include:

Get-NetAdapter | Sort-Object Name |
    Select-Object Name, InterfaceDescription, Status, LinkSpeed, DriverVersion

Get-SmbClientNetworkInterface
Get-SmbServerNetworkInterface
Get-SmbMultichannelConnection
Get-ClusterNetwork | Select-Object Name, Address, Role, State

Do not copy a Data Center Bridging or RDMA configuration from another adapter family. Incorrect RoCE priority flow control and switch configuration can create a cluster that is fast in a demo and unstable under congestion. iWARP avoids the lossless-Ethernet configuration requirement, but it still needs supported hardware, firmware and drivers.

Software and licensing

For Windows Server S2D, use matching, fully patched Windows Server Datacenter installations on both nodes. Storage Spaces Direct is a Datacenter feature. Licence every physical core according to the applicable Windows Server terms and separately account for guest operating-system rights, management products and application licences. Evaluation media is suitable for a time-limited lab, not production.

Both nodes should use the same:

• Windows Server release, edition and patch level.
• Server model and BIOS configuration.
• HBA and NIC model, driver and firmware.
• Drive layout, media type, model and firmware.

Install Hyper-V when the cluster is hyperconverged, Failover Clustering for the cluster, and the File Server role for the storage components:

Install-WindowsFeature Hyper-V, Failover-Clustering, FS-FileServer `
    -IncludeManagementTools

Build sequence

The commands below show the order, not a paste-and-run deployment. Replace names and addresses through an approved build document, and stop on unexplained validation warnings.

1. Establish the hardware baseline

On both nodes, capture inventory before pooling any drive:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, DriverVersion
Get-PhysicalDisk | Select-Object FriendlyName, SerialNumber, MediaType, Size,
    CanPool, HealthStatus, OperationalStatus
Get-Disk | Select-Object Number, FriendlyName, SerialNumber, PartitionStyle,
    IsBoot, IsSystem, Size

Every intended S2D capacity drive must be empty, directly attached to one node and shown as poolable. Never use a broad disk-cleaning loop to make a failed prerequisite disappear.

2. Validate the nodes

$nodes = 'S2DNODE01', 'S2DNODE02'

Test-Cluster -Node $nodes `
    -Include 'Storage Spaces Direct', Inventory, Network, 'System Configuration'

Open the generated validation report. Correct failures involving drivers, firmware, networking, symmetry or storage. Record the reason for any accepted warning.

3. Create the cluster without traditional shared storage

New-Cluster -Name 'S2DCLUSTER' -Node $nodes -NoStorage
Get-ClusterNode -Cluster 'S2DCLUSTER'

Use an approved static cluster address when DHCP is not available. Confirm DNS registration and cluster-name permissions rather than improvising an address.

4. Configure quorum

For a Cloud Witness:

Set-ClusterQuorum -Cluster 'S2DCLUSTER' `
    -CloudWitness `
    -AccountName '<storage-account-name>' `
    -AccessKey '<retrieve-securely-at-runtime>'

Get-ClusterQuorum -Cluster 'S2DCLUSTER'

Do not place the key in a script, repository or command transcript. A File Share Witness is a good alternative when its SMB host is independent from both cluster nodes and the cluster data.

5. Enable S2D

Enable-ClusterStorageSpacesDirect -CimSession 'S2DCLUSTER'

Get-StoragePool -CimSession 'S2DCLUSTER' -IsPrimordial $false
Get-PhysicalDisk -CimSession 'S2DCLUSTER' |
    Sort-Object FriendlyName |
    Select-Object FriendlyName, SerialNumber, MediaType, Size,
        HealthStatus, OperationalStatus, Usage

Confirm the expected disk count, media type and health before creating a volume.

6. Inspect the available resiliency tiers

Get-StorageTier -CimSession 'S2DCLUSTER' |
    Select-Object FriendlyName, MediaType, ResiliencySettingName,
        PhysicalDiskRedundancy, Size

For a production two-node cluster, choose nested resiliency from the tier names actually returned by your cluster. Microsoft documents tier names such as NestedMirrorOnSSD and NestedParityOnSSD; do not assume a name without checking the deployed system.

An example nested mirror volume, after confirming the tier and capacity, is:

New-Volume -CimSession 'S2DCLUSTER' `
    -StoragePoolFriendlyName 'S2D*' `
    -FriendlyName 'VMs01' `
    -StorageTierFriendlyNames 'NestedMirrorOnSSD' `
    -StorageTierSizes 1TB

Start with a deliberately small volume, verify its resiliency and health, then expand according to the tested capacity plan.

7. Validate before placing workloads

Get-ClusterSharedVolume -Cluster 'S2DCLUSTER'
Get-VirtualDisk -CimSession 'S2DCLUSTER' |
    Select-Object FriendlyName, ResiliencySettingName, Size,
        FootprintOnPool, HealthStatus, OperationalStatus
Get-StorageJob -CimSession 'S2DCLUSTER'
Get-StorageSubSystem -CimSession 'S2DCLUSTER' `
    -FriendlyName 'Clustered Windows Storage*' |
    Get-StorageHealthReport

Then test one controlled node drain:

Suspend-ClusterNode -Cluster 'S2DCLUSTER' -Name 'S2DNODE02' -Drain
Get-ClusterGroup -Cluster 'S2DCLUSTER'
Get-StorageJob -CimSession 'S2DCLUSTER'
Resume-ClusterNode -Cluster 'S2DCLUSTER' -Name 'S2DNODE02' -Failback Immediate

Do this before production data is present. Confirm the remaining node has sufficient compute, memory and network capacity, then allow storage to return fully healthy before any second maintenance action.

What to monitor from day one

At minimum, alert on:

• Any physical disk leaving Healthy/OK.
• Any virtual disk or pool leaving Healthy/OK.
• Storage jobs that do not progress within the expected maintenance window.
• Pool free capacity falling below the documented repair reserve.
• Loss of one SMB storage path or unexpected reduction in link speed.
• Cluster node, CSV or witness state changes.
• Firmware, driver or Windows update drift between nodes.
• Backup failure and restore-test age.

Patch and restart one node at a time. After each node returns, wait for storage jobs to finish and health to return before touching the second node.

The final recommendation

For a home lab, buy two identical used enterprise servers only after confirming their HBAs can present disks directly, their NICs have current Windows Server drivers and they provide enough matched drive bays. Use four enterprise SSDs per node and two direct 10 GbE links. Keep the lab isolated and accept that it does not become supported merely because Test-Cluster passes.

For a small production deployment, spend money on the parts that define recoverability: the validated hardware combination, enterprise drives with power-loss protection, redundant storage paths, adequate memory for single-node operation, an independent witness, replacement support and tested backups. Save money by using a two-node switchless topology, not by removing the failure protections that make the cluster worthwhile.

Verification and limits

The minimum node, network, memory, boot, drive, direct-attachment, power-loss-protection and symmetry requirements were checked against Microsoft documentation on 24 September 2026. The two-node capacity and failure comparisons were checked against Microsoft’s volume-planning and nested-resiliency documentation. The component examples and practical memory starting points are design recommendations, not Microsoft minimums or vendor validation.

This article was documentation-reviewed but the complete physical design was not assembled and benchmarked for publication. Hardware availability, firmware support, licensing and vendor support change. Confirm them before purchase. A successful build does not replace backups, off-site recovery or a tested restore process.

References

• Storage Spaces Direct hardware requirements
• Storage Spaces Direct overview
• Deploy Storage Spaces Direct
• Plan volumes on Windows Server clusters
• Nested resiliency for a two-server cluster
• Storage pool cache
• Cluster and pool quorum
• Deploy a quorum witness
• Failover clustering hardware requirements