How to Set Up a Hyper-V Cluster on Windows Server 2025

How to Set Up a Hyper-V Cluster on Windows Server 2025

A Hyper-V cluster — built on Windows Server Failover Clustering (WSFC) — provides the foundation for high-availability virtualisation. When a host node fails, the virtual machines running on it automatically restart on surviving nodes, often within a minute or two, without any manual intervention. Windows Server 2025 extends this capability with improved resilience for Storage Spaces Direct, faster failover detection, and enhanced cluster-aware updating. This tutorial walks through every step of building a Hyper-V cluster: validating hardware, installing Failover Clustering, running the validation wizard, creating the cluster, configuring quorum, adding shared storage, and deploying the first clustered VM.

Prerequisites

• Two or more Windows Server 2025 servers (Datacenter or Standard edition) at the same patch level
• Identical hardware across all nodes is strongly recommended — same CPU family, same NIC types
• Shared storage accessible by all nodes via iSCSI, Fibre Channel, or SMB 3.0 (Scale-Out File Server); alternatively, Storage Spaces Direct for hyper-converged configurations
• At least two network interfaces per node: one for management/VM traffic, one dedicated for cluster heartbeat
• Static IP addresses assigned to all node NICs that will carry cluster traffic
• Domain membership for all nodes (WSFC requires Active Directory)
• An account with local administrator rights on all nodes

Step 1: Install Failover Clustering and Hyper-V Roles

Both the Failover Clustering feature and the Hyper-V role must be installed on every node that will participate in the cluster. Run the following commands on each server, or use -ComputerName to install remotely from a management station.

# Install Failover Clustering and Hyper-V on the local node
Install-WindowsFeature -Name Failover-Clustering, Hyper-V `
    -IncludeManagementTools `
    -Restart

# Install on remote nodes simultaneously (runs in parallel via jobs)
$nodes = 'HVNODE01', 'HVNODE02', 'HVNODE03'
$nodes | ForEach-Object {
    Invoke-Command -ComputerName $_ -ScriptBlock {
        Install-WindowsFeature -Name Failover-Clustering, Hyper-V `
            -IncludeManagementTools -Restart
    } -AsJob
} | Wait-Job | Receive-Job

# After all nodes have restarted, confirm installation on each
$nodes | ForEach-Object {
    Invoke-Command -ComputerName $_ -ScriptBlock {
        Get-WindowsFeature Failover-Clustering, Hyper-V |
            Select-Object Name, InstallState
    }
}

Step 2: Validate the Cluster with Test-Cluster

The cluster validation wizard — exposed via Test-Cluster — runs a comprehensive series of hardware, network, and storage checks against your proposed nodes. Microsoft only supports clusters that pass validation, so this step is mandatory, not optional. Read the HTML report it generates and resolve all failures before proceeding.

# Run full validation against all proposed cluster nodes
# This will take 10-30 minutes depending on the number of nodes and storage targets
Test-Cluster -Node 'HVNODE01', 'HVNODE02', 'HVNODE03' `
             -ReportName 'C:ClusterValidationHyperVCluster_Validation'

# Run only specific test categories (speeds up testing during troubleshooting)
Test-Cluster -Node 'HVNODE01', 'HVNODE02' `
             -Include 'Storage', 'Network', 'Hyper-V Configuration'

# Open the HTML report automatically
Invoke-Item 'C:ClusterValidationHyperVCluster_Validation.htm'

Review the report carefully. Warnings about network configuration (e.g., no redundant networks) should be addressed before production use. Any failures in the Storage or Network categories must be resolved before creating the cluster.

Step 3: Create the Failover Cluster

Once validation passes cleanly, use New-Cluster to create the cluster object in Active Directory and establish the initial cluster configuration. If you are using SMB 3.0 file share storage instead of block storage, add -NoStorage to prevent the wizard from trying to claim block disks.

# Create a cluster with a static management IP address
New-Cluster -Name 'HVCLUSTER01' `
            -Node 'HVNODE01', 'HVNODE02', 'HVNODE03' `
            -StaticAddress '10.10.1.50'

# For SMB-only (hyper-converged or Scale-Out File Server) deployments, skip storage discovery
New-Cluster -Name 'HVCLUSTER01' `
            -Node 'HVNODE01', 'HVNODE02', 'HVNODE03' `
            -StaticAddress '10.10.1.50' `
            -NoStorage

# Verify the cluster formed successfully
Get-Cluster -Name 'HVCLUSTER01'
Get-ClusterNode -Cluster 'HVCLUSTER01' | Select-Object Name, State, DrainStatus

# Check cluster network configuration
Get-ClusterNetwork | Select-Object Name, Role, State, Address, AddressMask

Step 4: Configure Quorum

Quorum determines how many votes are required for the cluster to remain online and accept client connections. Correct quorum configuration prevents split-brain scenarios where two halves of a cluster both believe they are the authoritative instance. For a two-node cluster, a file share witness or cloud witness is essential. For three or more nodes, the default node majority quorum is usually appropriate.

# View the current quorum configuration
Get-ClusterQuorum

# Set a file share witness (suitable for 2-node clusters or even-node clusters)
# Create the witness share on a server that is NOT a cluster node
Set-ClusterQuorum -Cluster 'HVCLUSTER01' `
                  -FileShareWitness '\DC01HVClusterWitness'

# Use a cloud witness (Azure Blob Storage) — recommended for stretched/geo clusters
Set-ClusterQuorum -Cluster 'HVCLUSTER01' `
                  -CloudWitness `
                  -AccountName 'mystorageaccount' `
                  -AccountKey 'base64encodedkey==' `
                  -Endpoint 'core.windows.net'

# For 3+ node clusters: node majority (no witness required)
Set-ClusterQuorum -Cluster 'HVCLUSTER01' -NodeMajority

# Verify quorum mode and vote assignments
Get-ClusterNode | Select-Object Name, NodeWeight
(Get-Cluster).QuorumType

Step 5: Add Shared Storage

Shared block storage (iSCSI LUNs or Fibre Channel volumes) must be presented to all cluster nodes before being claimed by the cluster. Once claimed, disks can be converted to Cluster Shared Volumes for Hyper-V use.

# Connect iSCSI initiator on each node to the iSCSI target (run on all nodes)
$nodes | ForEach-Object {
    Invoke-Command -ComputerName $_ -ScriptBlock {
        # Start the iSCSI initiator service
        Start-Service MSiSCSI
        Set-Service MSiSCSI -StartupType Automatic

        # Add the iSCSI target portal
        New-IscsiTargetPortal -TargetPortalAddress '10.10.2.100'

        # Connect to all discovered targets
        Get-IscsiTarget | Connect-IscsiTarget -IsPersistent $true
    }
}

# On any cluster node: view disks available to be claimed
Get-ClusterAvailableDisk -Cluster 'HVCLUSTER01'

# Add all available disks to the cluster
Get-ClusterAvailableDisk -Cluster 'HVCLUSTER01' | Add-ClusterDisk

# Convert clustered disks to Cluster Shared Volumes
Get-ClusterResource -Cluster 'HVCLUSTER01' |
    Where-Object { $_.ResourceType -eq 'Physical Disk' } |
    ForEach-Object { Add-ClusterSharedVolume -Name $_.Name }

# Verify CSV status and paths
Get-ClusterSharedVolume -Cluster 'HVCLUSTER01' |
    Select-Object Name, State, @{N='MountPoint'; E={ ($_.SharedVolumeInfo).FriendlyVolumeName }}

Step 6: Add the Hyper-V Role to the Cluster

After shared storage is in place, you can add a Hyper-V virtual machine as a cluster role. New VMs created on a CSV are automatically candidates for high availability.

# Create a new VM on a CSV path (from any node)
New-VM -Name 'ClusteredAppServer01' `
       -ComputerName 'HVNODE01' `
       -MemoryStartupBytes 4GB `
       -NewVHDPath 'C:ClusterStorageVolume1VMsClusteredAppServer01ClusteredAppServer01_OS.vhdx' `
       -NewVHDSizeBytes 127GB `
       -Generation 2 `
       -SwitchName 'External-vSwitch'

# Configure the VM
Set-VMProcessor -VMName 'ClusteredAppServer01' -ComputerName 'HVNODE01' -Count 4
Set-VMMemory -VMName 'ClusteredAppServer01' -ComputerName 'HVNODE01' `
    -DynamicMemoryEnabled $true -StartupBytes 4GB -MinimumBytes 2GB -MaximumBytes 8GB

# Register the VM as a highly available cluster role
Add-ClusterVirtualMachineRole -VMName 'ClusteredAppServer01' -Cluster 'HVCLUSTER01'

# Verify the cluster role
Get-ClusterGroup -Cluster 'HVCLUSTER01' | Where-Object { $_.GroupType -eq 'VirtualMachine' }

Step 7: Test Failover

Before considering your cluster production-ready, test live migration and failover to confirm the cluster behaves as expected under simulated node failure.

# Live migrate a VM from HVNODE01 to HVNODE02 (VM keeps running during migration)
Move-ClusterVirtualMachineRole -Name 'ClusteredAppServer01' `
                               -MigrationType Live `
                               -Node 'HVNODE02'

# Simulate a node failure by stopping the Cluster Service (do NOT do this in production with live VMs)
# This is a test on a lab cluster only
Stop-Service ClusSvc -Force   # Run on HVNODE01 to simulate node leaving the cluster

# From another node, watch VMs fail over
Get-ClusterGroup -Cluster 'HVCLUSTER01' | Select-Object Name, OwnerNode, State

# Check cluster events for failover activity
Get-ClusterLog -Cluster 'HVCLUSTER01' -TimeSpan 30 -UseLocalTime

# Restart the cluster service on the recovered node
Start-Service ClusSvc   # Run on HVNODE01 after "recovery"

Conclusion

Building a Hyper-V cluster on Windows Server 2025 with Windows Server Failover Clustering delivers enterprise-grade high availability for your virtualised workloads. The process — installing the Failover Clustering feature, running Test-Cluster validation, creating the cluster with New-Cluster, setting an appropriate quorum model, adding shared block storage or CSV volumes, and registering VMs as cluster roles — is well-supported by PowerShell at every step. Once the cluster is running, capabilities like live migration, Cluster-Aware Updating, and Storage Spaces Direct can be layered on top to build a fully software-defined, highly available virtualisation platform that scales from a two-node edge deployment to a large data centre fabric.