8.1 Hyper-V Failover Clustering & Cluster Shared Volumes (CSV)

Hyper-V Failover Clustering & Cluster Shared Volumes (CSV)

In enterprise private and hybrid cloud architectures, running business-critical virtualized workloads requires zero unplanned downtime, high resilience against host hardware failures, and dynamic workload mobility. Windows Server Failover Clustering (WSFC) integrated with Hyper-V provides the foundational high-availability clustering tier for Windows Server environments. By grouping multiple physical Hyper-V hosts into a unified cluster managed through Failover Cluster Manager or PowerShell, organizations achieve automated virtual machine failover, live workload balancing, and non-disruptive host maintenance.

---

1. Windows Server Failover Clustering (WSFC) Architecture & Prerequisites

A Hyper-V Failover Cluster is a group of independent physical servers (nodes) that work together to increase the availability of virtualized roles and applications. If a physical node experiences hardware failure, power loss, or operating system failure, the virtual machines hosted on that node are automatically restarted on remaining healthy nodes within seconds.

+-----------------------------------------------------------------------------------------+
|                       HYPER-V FAILOVER CLUSTER ARCHITECTURE                             |
|                                                                                         |
|   +------------------------------------+   +------------------------------------+       |
|   | Hyper-V Cluster Node 1 (Active)    |   | Hyper-V Cluster Node 2 (Active)    |       |
|   |  - Role: VM-SQL-01 [Running]       |   |  - Role: VM-APP-01 [Running]       |       |
|   |  - Heartbeat / Cluster Network     |   |  - Heartbeat / Cluster Network     |       |
|   |  - Live Migration Network (RDMA)   |   |  - Live Migration Network (RDMA)   |       |
|   +------------------------------------+   +------------------------------------+       |
|                      \                               /                                  |
|                       \                             /                                   |
|   =====================\===========================/=================================   |
|                          STORAGE FABRIC (iSCSI / FC / SAS / SMB 3.0)                    |
|   ===================================================================================   |
|                                          |                                              |
|                      +-------------------+-------------------+                          |
|                      |  Cluster Shared Volume (CSV LUN)      |                          |
|                      |  Path: C:\ClusterStorage\Volume1       |                          |
|                      |  Holds: VM Configs, VHDX Virtual Disks|                          |
|                      +---------------------------------------+                          |
+-----------------------------------------------------------------------------------------+

Core Prerequisites for Hyper-V Clustering

1. Hardware Homogeneity: While mixed-processor generations can run clustered VMs using Hyper-V Processor Compatibility Mode, identical CPU models (Intel VT-x or AMD-V) and matching BIOS/UEFI settings are strongly recommended for seamless Live Migration.
2. Network Topology: A minimum of two distinct physical network adapters per host is required, though enterprise environments deploy redundant 10GbE/25GbE adapters segregated into distinct subnets or VLANs:
   • Management Network: Host administration, Active Directory domain traffic, and RDP/SSH.
   • Cluster / Heartbeat Network: Inter-node cluster communication, health monitoring, and state replication.
   • Live Migration Network: Dedicated high-speed network for memory state replication during migrations (preferably configured with RDMA / SMB Direct).
   • Storage Network: Dedicated iSCSI or SMB 3.0 traffic if not using Fibre Channel.
   • VM Traffic Network: Hyper-V Virtual Switch carrying tenant guest traffic.
3. Active Directory Domain Services: All cluster nodes must be joined to the same Active Directory Domain Services (AD DS) forest/domain.
4. Shared Storage: Accessible to all cluster nodes simultaneously via Fibre Channel (FC), Fibre Channel over Ethernet (FCoE), iSCSI, Shared Serial Attached SCSI (SAS), or Storage Spaces Direct (S2D).

Cluster Validation Testing (Test-Cluster)

Before forming a cluster, administrators must execute the Cluster Validation Wizard or the Test-Cluster PowerShell cmdlet. Running cluster validation tests hardware, network latency, storage failover reservations (SCSI-3 Persistent Reservations), and Hyper-V virtual switch configurations.

# Execute a full cluster validation across candidate Hyper-V nodes
Test-Cluster -Node "HV-NODE01", "HV-NODE02", "HV-NODE03" `
    -Include "Hyper-V Configuration", "Storage", "Network", "System Configuration", "Inventory" `
    -ReportFilePath "C:\Reports\HyperVClusterValidation.html"

# Create the Failover Cluster after all validation tests pass
New-Cluster -Name "HV-PROD-CLUST" `
    -Node "HV-NODE01", "HV-NODE02", "HV-NODE03" `
    -StaticAddress "10.10.10.50" `
    -NoStorage

[!IMPORTANT] Microsoft Support Policy Requirement: To receive full Microsoft production support for a Failover Cluster, the environment must pass all validation tests in Test-Cluster without blocking errors. A validation report with "Warnings" is acceptable if documented, but "Failures" must be remediated prior to putting the cluster into production.

---

2. Quorum Models & Dynamic Quorum Architecture

Quorum is the consensus mechanism that ensures a cluster maintains integrity and avoids split-brain conditions—a catastrophic scenario where a communication breakdown causes cluster partitions to simultaneously assume volume ownership and write conflicting data to shared disks.

Voting Architecture & Dynamic Quorum

Modern Windows Server Failover Clustering implements Dynamic Quorum. Under Dynamic Quorum, the cluster dynamically recalculates the total votes required for quorum when nodes gracefully shut down or fail sequentially. As long as nodes drop one by one with sufficient time for the cluster to recalculate voting weights, a cluster can survive down to a single remaining node and a witness.

+-----------------------------------------------------------------------------------------+
|                              QUORUM MODELS COMPARISON                                   |
|                                                                                         |
|   QUORUM WITNESS TYPE      BEST USE CASE                    REQUIREMENTS / MECHANISM    |
|   -----------------------+--------------------------------+-----------------------------|
|   Node Majority          | Odd number of nodes (3, 5, 7)  | No witness needed; 50%+1    |
|   (No Witness)           | in a single datacenter         | active nodes maintain quorum|
|   -----------------------+--------------------------------+-----------------------------|
|   Disk Witness           | Multi-site or even-node SAN    | Dedicated shared LUN (512MB)|
|                          | environments                   | with SCSI-3 reservations    |
|   -----------------------+--------------------------------+-----------------------------|
|   File Share Witness     | Multi-site stretched clusters  | SMB file share on a separate|
|   (FSW)                  | or non-SAN environments        | independent server host     |
|   -----------------------+--------------------------------+-----------------------------|
|   Cloud Witness          | All modern 2-node or even-node | Azure Blob Storage account  |
|                          | clusters (Standard Practice)   | Outbound HTTPS port 443     |
+-----------------------------------------------------------------------------------------+

Cloud Witness in Azure Blob Storage

Cloud Witness is the recommended witness type for modern Windows Server clusters. Instead of provisioning an on-premises physical file server or shared SAN LUN, Cloud Witness uses a lightweight Azure Blob Storage account as an arbitration point.

# Configure an Azure Cloud Witness for the Hyper-V Cluster
Set-ClusterQuorum -Cluster "HV-PROD-CLUST" `
    -CloudWitness `
    -AccountName "stghvclusterwitness" `
    -AccessKey "A1b2C3d4E5f6G7h8I9j0K1L2M3N4O5P6Q7R8S9T0U1V2W3X4Y5Z6=="

Why Cloud Witness is Superior:

• Zero Compute Costs: Uses standard Azure Blob Storage; no virtual machine hosting or OS patching required.
• Multi-Site Resiliency: Operates outside local datacenter failure domains, making it ideal as a third-party tiebreaker in stretched multi-datacenter clusters.
• Negligible Storage: Maintains a tiny 0-byte blob file containing only timestamp tokens for arbitration.

---

3. Cluster Shared Volumes (CSV) Architecture & I/O Flow

Prior to Cluster Shared Volumes (CSV), a clustered shared disk (LUN) could only be mounted and accessed by a single node at any given time. If multiple VMs resided on the same LUN, all those VMs had to run on the same cluster host.

Cluster Shared Volumes (CSV) revolutionizes Hyper-V storage by providing an active-active, multi-node shared namespace. Multiple cluster nodes can simultaneously read from and write to the same shared NTFS or ReFS volume. CSV exposes shared volumes as subdirectories under a uniform local namespace on every node: C:\ClusterStorage\VolumeX.

+-----------------------------------------------------------------------------------------+
|                        CLUSTER SHARED VOLUMES (CSV) I/O PATHWAYS                        |
|                                                                                         |
|  [COORDINATOR NODE (Node 1)]                       [NON-COORDINATOR NODE (Node 2)]      |
|  +------------------------+                        +------------------------+           |
|  | VM 1 (Reads/Writes)    |                        | VM 2 (Reads/Writes)    |           |
|  |                        |                        |                        |           |
|  | NTFS / ReFS Metadata   |                        | Direct I/O (Data Reads)|           |
|  | Manager & Coordinator  |                        |                        |           |
|  +-----------+------------+                        +-----------+------------+           |
|              | (Direct SAN)                                    | (Direct SAN)           |
|              |                                                 |                        |
|              v                                                 v                        |
|  +--------------------------------------------------------------------------+           |
|  |                 SHARED STORAGE FABRIC (SAN LUN / CSV VOLUME)              |           |
|  +--------------------------------------------------------------------------+           |
|                                                                                         |
|  === BLOCK REDIRECTED I/O FALLBACK PATH (If Node 2 loses physical storage link) ===     |
|  [Node 2 Guest VM] ---> [Node 2 CSVFS] === SMB 3.0 Cluster Net ===> [Node 1] ---> [SAN] |
+-----------------------------------------------------------------------------------------+

Direct I/O vs Block Redirected I/O

CSV handles storage input/output using two distinct operational modes:

# Convert a standard cluster disk to a Cluster Shared Volume (CSV)
Add-ClusterSharedVolume -Name "Cluster Disk 2" -Cluster "HV-PROD-CLUST"

# Inspect CSV volume state and owner (Coordinator) node
Get-ClusterSharedVolume | Select-Object Name, State, OwnerNode, @{N='Path';E={$_.SharedVolumeInfo.FriendlyVolumeName}}

[!TIP] Exam Trap: ReFS vs NTFS on CSV: Starting with Windows Server 2019 and Windows Server 2022/2025, ReFS (Resilient File System) is fully supported on CSV alongside NTFS. ReFS offers near-instantaneous fixed-size VHDX creation and checkpoint merge operations via Block Cloning (allocate-on-write) technology.

4. Virtual Machine Migration Technologies

Hyper-V provides multiple migration mechanisms to transfer virtual machine compute, memory, and storage states between hosts without service interruption.

+-----------------------------------------------------------------------------------------+
|                      VIRTUAL MACHINE MIGRATION MODES COMPARISON                         |
|                                                                                         |
|   MIGRATION TYPE            DOWNTIME   STORAGE REQUIREMENT    APPLICABILITY             |
|   ------------------------+----------+----------------------+---------------------------|
|   Clustered Live Migration | Zero     | Shared Storage (CSV) | Nodes in same cluster     |
|   Storage Live Migration   | Zero     | Independent Storage  | Any host (moves VHDX files|
|   Shared Nothing Live Mig. | Zero     | Independent Storage  | Non-clustered hosts       |
|   Quick Migration          | Brief    | Shared Storage       | Clustered hosts (pause/res|
+-----------------------------------------------------------------------------------------+

1. Clustered Live Migration (Compute Only)

Clustered Live Migration moves the execution state and RAM of a running virtual machine from one cluster node to another while keeping the underlying virtual disk (VHDX) stationary on shared CSV storage. The process transfers memory pages iteratively, pauses the VM for milliseconds during final CPU register transfer, and announces the VM's MAC address on the new switch port via Gratuitous ARP.

Live Migration Performance & Transport Protocols:

• TCP: Default transport; transfers uncompressed memory pages over standard TCP connections. Higher network utilization.
• Compression: Compresses memory pages using host CPU cycles before transmission across the network. Recommended for 1GbE or saturated 10GbE networks.
• SMB 3.0 / SMB Direct (RDMA): Transfers memory data over SMB 3.0 utilizing RDMA (Remote Direct Memory Access) adapters (iWARP or RoCE). Delivers line-rate throughput (25GbE/100GbE) with near-zero host CPU overhead.

Authentication Protocols:

• Kerberos: Requires configuring Active Directory Constrained Delegation for the cifs and Microsoft Virtual System Migration Service services on the computer accounts of all Hyper-V hosts. Enables initiating Live Migrations remotely via Windows Admin Center, PowerShell remoting, or Hyper-V Manager.
• CredSSP (Credential Security Support Provider): Avoids configuring Kerberos constrained delegation but requires the administrator to log in directly via local interactive desktop session on the source host. Remote PowerShell Live Migration triggers fail under CredSSP due to the "double-hop" authentication barrier.

2. Storage Live Migration

Storage Live Migration relocates a virtual machine's virtual hard disks (.vhdx), checkpoints, and configuration files from one storage location to another without stopping the running VM. While the VM continues executing, Hyper-V performs a baseline file copy, uses a write mirror to log all incoming disk writes to both the source and target locations, synchronizes deltas, and switches file handles upon completion.

# Perform Storage Live Migration of a running VM to a new CSV volume
Move-VMStorage -VMName "VM-APP-01" `
    -DestinationStoragePath "C:\ClusterStorage\Volume2\VM-APP-01"

3. Shared Nothing Live Migration

Shared Nothing Live Migration simultaneously transfers both the memory state and the virtual disk storage of a running VM between two independent, non-clustered Hyper-V hosts connected only by an Ethernet network cable or LAN.

# Migrate a running VM and its storage between non-clustered Hyper-V hosts
Move-VM -Name "VM-DEV-01" `
    -DestinationHost "HV-STANDALONE-02" `
    -IncludeStorage `
    -DestinationStoragePath "D:\Hyper-V\Virtual Hard Disks\VM-DEV-01"

---

5. Host Maintenance: Node Pause and Role Draining

Performing planned host maintenance (e.g., applying Windows cumulative updates or updating physical server firmware) requires evacuating clustered VM workloads without downtime.

# Step 1: Pause the cluster node and drain all hosted VM roles automatically
Suspend-ClusterNode -Name "HV-NODE01" -Drain

# Step 2: Perform host patching, hardware maintenance, or OS reboot
# ... Host reboot occurs here ...

# Step 3: Resume the cluster node and fail back original workloads
Resume-ClusterNode -Name "HV-NODE01" -Failback Immediate

• Suspend-ClusterNode -Drain: Sets the node state to Paused and systematically initiates Live Migrations of all running virtual machines to remaining active nodes, taking node capacity and memory constraints into account.
• Resume-ClusterNode -Failback Immediate: Re-enables the node (Up state) and immediately Live Migrates preferred workloads back to the host if configured in failback policies.