Windows Server 2025 and Hyper-V Cluster Setup: End to End

# Run on each node, or use Invoke-Command to target all nodes at once
$nodes = "HV-Node1", "HV-Node2", "HV-Node3", "HV-Node4"

Invoke-Command -ComputerName $nodes -ScriptBlock {
    Install-WindowsFeature `
        -Name Hyper-V, Failover-Clustering, Data-Center-Bridging, `
               RSAT-Clustering-PowerShell, Hyper-V-PowerShell, `
               FS-FileServer `
        -IncludeManagementTools `
        -Restart
}

# After nodes restart, join all to the domain if not already done
# Then verify features installed correctly
Invoke-Command -ComputerName $nodes -ScriptBlock {
    Get-WindowsFeature Hyper-V, Failover-Clustering | Select-Object Name, InstallState
}

# Run on each node
# NET01 and NET02 are your RDMA-capable physical NIC names - adjust to match your hardware

# Step 1: Create the SET-based Hyper-V virtual switch
New-VMSwitch -Name "ConvergedSwitch" `
             -NetAdapterName "NET01","NET02" `
             -EnableEmbeddedTeaming $true `
             -AllowManagementOS $false  # We'll add an explicit management vNIC

# Step 2: Add management OS vNICs per traffic type
Add-VMNetworkAdapter -ManagementOS -Name "Management"    -SwitchName "ConvergedSwitch"
Add-VMNetworkAdapter -ManagementOS -Name "Cluster"       -SwitchName "ConvergedSwitch"
Add-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -SwitchName "ConvergedSwitch"
Add-VMNetworkAdapter -ManagementOS -Name "SMB-1"         -SwitchName "ConvergedSwitch"
Add-VMNetworkAdapter -ManagementOS -Name "SMB-2"         -SwitchName "ConvergedSwitch"

# Step 3: Assign VLANs to each vNIC
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Management"    -Access -VlanId 100
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Cluster"       -Access -VlanId 200
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "LiveMigration" -Access -VlanId 300
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "SMB-1"         -Access -VlanId 500
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "SMB-2"         -Access -VlanId 501

# Step 4: Assign QoS minimum bandwidth weights (must add to 100 across all vNICs)
Set-VMNetworkAdapter -ManagementOS -Name "Management"    -MinimumBandwidthWeight 10
Set-VMNetworkAdapter -ManagementOS -Name "Cluster"       -MinimumBandwidthWeight 5
Set-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -MinimumBandwidthWeight 20
Set-VMNetworkAdapter -ManagementOS -Name "SMB-1"         -MinimumBandwidthWeight 15
Set-VMNetworkAdapter -ManagementOS -Name "SMB-2"         -MinimumBandwidthWeight 15

# Step 5: Enable RDMA on the SMB vNICs (requires RDMA capable physical NICs)
Enable-NetAdapterRdma -Name "vEthernet (SMB-1)"
Enable-NetAdapterRdma -Name "vEthernet (SMB-2)"

# Step 6: Map each SMB vNIC to a specific physical NIC for RSS affinity
Set-VMNetworkAdapterTeamMapping -ManagementOS -VMNetworkAdapterName "SMB-1" -PhysicalNetAdapterName "NET01"
Set-VMNetworkAdapterTeamMapping -ManagementOS -VMNetworkAdapterName "SMB-2" -PhysicalNetAdapterName "NET02"

# Step 7: Set static IPs on each vNIC (adjust subnets to match your environment)
New-NetIPAddress -InterfaceAlias "vEthernet (Management)"    -IPAddress 10.0.100.11 -PrefixLength 24
New-NetIPAddress -InterfaceAlias "vEthernet (Cluster)"       -IPAddress 10.0.200.11 -PrefixLength 24
New-NetIPAddress -InterfaceAlias "vEthernet (LiveMigration)" -IPAddress 10.0.300.11 -PrefixLength 24
New-NetIPAddress -InterfaceAlias "vEthernet (SMB-1)"         -IPAddress 10.0.500.11 -PrefixLength 24
New-NetIPAddress -InterfaceAlias "vEthernet (SMB-2)"         -IPAddress 10.0.501.11 -PrefixLength 24

Write-Host "Network configuration complete on $(hostname). Repeat on each node with appropriate IP addresses."

# Run from a management station with RSAT or from one of the nodes

# Validation - fix failures before proceeding
Test-Cluster -Node "HV-Node1","HV-Node2","HV-Node3","HV-Node4" `
             -Include "Hyper-V Configuration","Inventory","Network","Storage","System Configuration"

# Create the cluster - use -NoStorage for S2D deployments
# For SAN-based deployments, omit -NoStorage to let clustering claim shared disks
New-Cluster -Name "HV-Cluster01" `
            -Node "HV-Node1","HV-Node2","HV-Node3","HV-Node4" `
            -StaticAddress 10.0.100.20 `
            -NoStorage  # Required for S2D; omit for SAN-based deployments

# Verify cluster formed correctly
Get-ClusterNode
Get-ClusterNetwork | Select-Object Name, Role, State, IPv4Addresses

# Restrict which networks carry which cluster traffic
# Cluster heartbeat should only use the dedicated Cluster network
Get-ClusterNetwork | ForEach-Object {
    switch ($_.Name) {
        "Cluster Network 1" { $_.Role = [Microsoft.FailoverClusters.PowerShell.ClusterNetworkRole]::Cluster }   # heartbeat only
        "Cluster Network 2" { $_.Role = [Microsoft.FailoverClusters.PowerShell.ClusterNetworkRole]::ClusterAndClient } # management
        "Cluster Network 3" { $_.Role = [Microsoft.FailoverClusters.PowerShell.ClusterNetworkRole]::None }      # live migration - set via Hyper-V
        "Cluster Network 4" { $_.Role = [Microsoft.FailoverClusters.PowerShell.ClusterNetworkRole]::None }      # storage - no cluster traffic
        "Cluster Network 5" { $_.Role = [Microsoft.FailoverClusters.PowerShell.ClusterNetworkRole]::None }      # storage - no cluster traffic
    }
}

# Set live migration to use the dedicated LM network
# Windows Server 2025 has improved network selection logic - it now automatically
# prefers the correct network for source/destination pairs in both switched and switchless topologies
Get-ClusterResourceType -Name "Virtual Machine" | `
    Set-ClusterParameter -Name MigrationExcludeNetworks -Value (
        (Get-ClusterNetwork | Where-Object { $_.Name -notmatch "LiveMig" }).Id -join ";"
    )

# Cloud Witness uses Azure Blob Storage - requires an Azure Storage account
# One blob per cluster; same storage account can serve multiple clusters
# Uses SAS tokens internally - access key is used to generate the token, not stored directly

Set-ClusterQuorum -CloudWitness `
                  -AccountName "yourstorageaccountname" `
                  -AccessKey   "your-storage-account-access-key"

# Verify quorum configuration
Get-ClusterQuorum

# Check dynamic quorum and dynamic witness status
(Get-Cluster).DynamicQuorum   # Should be 1 (enabled)
(Get-Cluster).DynamicWitness  # Should be 1 (enabled)

# Verify each node's vote weight
Get-ClusterNode | Select-Object Name, State, NodeWeight, DynamicWeight

# Enable Storage Spaces Direct
# Confirm prompt - this is irreversible; drives are consumed by the S2D pool
Enable-ClusterS2D -Confirm:$false

# Verify pool created and drives claimed
Get-StoragePool | Where-Object IsPrimordial -eq $false
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, OperationalStatus, Usage

# Create a three-way mirror volume (requires 3+ nodes, tolerates 2 failures)
# Use thin provisioning (new in Windows Server 2025) to overcommit the pool
New-Volume -FriendlyName "VMs-Production" `
           -StoragePoolFriendlyName "S2D on HV-Cluster01" `
           -FileSystem CSVFS_ReFS `
           -Size 10TB `
           -ResiliencySettingName Mirror `
           -PhysicalDiskRedundancy 2 `
           -ProvisioningType Thin

# Create a two-way mirror volume (2 nodes, tolerates 1 failure)
New-Volume -FriendlyName "VMs-Dev" `
           -StoragePoolFriendlyName "S2D on HV-Cluster01" `
           -FileSystem CSVFS_ReFS `
           -Size 2TB `
           -ResiliencySettingName Mirror `
           -PhysicalDiskRedundancy 1 `
           -ProvisioningType Thin

# Verify volumes are CSVs and mounted on all nodes
Get-ClusterSharedVolume | Select-Object Name, State, SharedVolumeInfo

# For iSCSI: Connect initiators on each node first
# Ensure the iSCSI initiator is running and connected to the target on all nodes
Start-Service msiscsi
Set-Service msiscsi -StartupType Automatic

# Connect to iSCSI target (run on each node)
New-IscsiTargetPortal -TargetPortalAddress "192.168.100.10"
Connect-IscsiTarget -NodeAddress "iqn.2025-01.com.example:storage01" -IsPersistent $true

# Initialize and prepare disks - run once from one node after all nodes are connected
# Disks should appear as Available Storage in Failover Cluster Manager
Get-ClusterAvailableDisk | Add-ClusterDisk

# Convert clustered disks to CSVs
# Format as NTFS first (SAN volumes), then add to CSV
Get-ClusterDisk | Where-Object {
    $_.State -eq "Online" -and $_.IsClustered -eq $true
} | Add-ClusterSharedVolume

# Verify CSVs accessible on all nodes at C:\ClusterStorage\
Get-ClusterSharedVolume | Select-Object Name, State, SharedVolumeInfo

# Run on each node (or via Invoke-Command)
# Point default VM and VHD paths to your CSV volume
Set-VMHost -VirtualMachinePath "C:\ClusterStorage\VMs-Production"
Set-VMHost -VirtualHardDiskPath "C:\ClusterStorage\VMs-Production"

# Set live migration authentication to Kerberos
# Required on Windows Server 2025 - CredSSP is broken by Credential Guard
Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos

# Set live migration performance option
# Compression: default, good balance for 10 GbE without RDMA
# SMB: use when RDMA is available on the live migration network (highest throughput)
Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

# Set maximum simultaneous live migrations
# Default is 2. Increase for large environments with fast LM networks.
# Don't exceed the number of physical NICs in the live migration path
Set-VMHost -MaximumVirtualMachineMigrations 4
Set-VMHost -MaximumStorageMigrations 2

# Run from a machine with Active Directory module and Domain Admin rights
# Repeat for each pair of nodes: each node must delegate to every other node

$nodes = "HV-Node1", "HV-Node2", "HV-Node3", "HV-Node4"

foreach ($sourceNode in $nodes) {
    $sourceAccount = Get-ADComputer -Identity $sourceNode
    $delegationTargets = @()

    foreach ($destNode in $nodes) {
        if ($destNode -ne $sourceNode) {
            # Allow source to delegate Microsoft Virtual System Migration Service to dest
            $delegationTargets += "Microsoft Virtual System Migration Service/$destNode"
            $delegationTargets += "Microsoft Virtual System Migration Service/$destNode.domain.local"
            # Also allow CIFS delegation if you need storage live migration
            $delegationTargets += "cifs/$destNode"
            $delegationTargets += "cifs/$destNode.domain.local"
        }
    }

    Set-ADComputer -Identity $sourceAccount `
                   -Add @{ "msDS-AllowedToDelegateTo" = $delegationTargets }

    Write-Host "Delegation configured for $sourceNode -> $($nodes -ne $sourceNode -join ', ')"
}

# Force AD replication and verify
Sync-ADObject -Object (Get-ADComputer "HV-Node1").DistinguishedName -Destination (Get-ADDomainController)
(Get-ADComputer "HV-Node1" -Properties "msDS-AllowedToDelegateTo")."msDS-AllowedToDelegateTo"

# Run from any cluster node or a management station with RSAT-Clustering-PowerShell installed

# Preferred owner: which node the VM prefers to run on after cluster restart
# The VM will still fail over to other nodes if the preferred node is unavailable
Set-ClusterOwnerNode -Group "VM: SQL-Primary" -Owners "HV-Node1","HV-Node2"

# Possible owners: which nodes are allowed to run this VM at all
# Use this to prevent a VM from failing over to nodes that lack a required license
# or resource (e.g. GPU, specific storage path)
Set-ClusterOwnerNode -Resource "VM: SQL-Primary" -Owners "HV-Node1","HV-Node2","HV-Node3"

# Anti-affinity: prevent VMs from running on the same node simultaneously
# Windows Server 2025 uses AntiAffinityClassNames for this
# VMs with the same anti-affinity class name won't run on the same node after failover
(Get-ClusterGroup "VM: SQL-Primary").AntiAffinityClassNames   = "SQL-HA-Pair"
(Get-ClusterGroup "VM: SQL-Secondary").AntiAffinityClassNames = "SQL-HA-Pair"

# Verify placement
Get-ClusterGroup | Where-Object { $_.GroupType -eq "VirtualMachine" } |
    Select-Object Name, OwnerNode, State | Sort-Object OwnerNode

# After creating the cluster with -NoStorage and before enabling S2D,
# configure the site and rack topology so S2D knows how to distribute copies

# Define sites
New-ClusterFaultDomain -Name "Site-Primary"   -Type Site -Description "Primary datacenter"
New-ClusterFaultDomain -Name "Site-Secondary" -Type Site -Description "Secondary building"

# Define racks within each site
New-ClusterFaultDomain -Name "Rack-1" -Type Rack -Parent "Site-Primary"
New-ClusterFaultDomain -Name "Rack-2" -Type Rack -Parent "Site-Secondary"

# Assign nodes to racks
Set-ClusterFaultDomain -Name "HV-Node1" -Parent "Rack-1"
Set-ClusterFaultDomain -Name "HV-Node2" -Parent "Rack-1"
Set-ClusterFaultDomain -Name "HV-Node3" -Parent "Rack-2"
Set-ClusterFaultDomain -Name "HV-Node4" -Parent "Rack-2"

# Verify topology
Get-ClusterFaultDomain | Select-Object Name, Type, Parent

# Now enable S2D - it will detect the multi-rack topology and
# prompt to set rack fault tolerance on the storage pool
# Answer Y to enable four way mirror resiliency across racks
Enable-ClusterS2D -Confirm:$false

# Update the storage pool to latest version after S2D is enabled
Get-StoragePool S2D* | Update-StoragePool

# Create a volume using nested mirror for campus cluster resilience
# NestedMirror provides two-way mirror within each site, plus mirroring between sites
New-Volume -FriendlyName "VMs-CampusHA" `
           -StoragePoolFriendlyName "S2D on HV-Cluster01" `
           -FileSystem CSVFS_ReFS `
           -Size 5TB `
           -ResiliencySettingName Mirror `
           -PhysicalDiskRedundancy 3 `
           -ProvisioningType Thin

# After all nodes are upgraded to Windows Server 2025:

# Verify all nodes are running 2025 before upgrading functional level
Get-ClusterNode | ForEach-Object {
    $os = Invoke-Command -ComputerName $_.Name -ScriptBlock {
        (Get-CimInstance Win32_OperatingSystem).Caption
    }
    [PSCustomObject]@{ Node = $_.Name; OS = $os }
}

# Check current cluster functional level
Get-Cluster | Select-Object Name, ClusterFunctionalLevel

# Upgrade to Windows Server 2025 functional level
# This is irreversible - ensure all nodes are on 2025 before running
Update-ClusterFunctionalLevel -Confirm:$false

# Verify upgrade
Get-Cluster | Select-Object Name, ClusterFunctionalLevel