Welcome to part 1 of a 15-part series on building a Two-Node Hyper-V Failover Cluster. This is a planning post — no terminals, no wizards, no screenshots. The architecture goes in your head first, then the next 14 parts make sense as moves on a board you already understand.
What this series builds
By the end of part 15 you’ll have a working Hyper-V failover cluster: two physical (or virtual) hosts running Hyper-V, sharing storage over iSCSI, with the cluster service orchestrating which host runs which VM. When a host dies, the cluster moves the affected VMs to the surviving host with ~30-60 seconds of downtime per VM.
Hyper-V FCs and SQL FCIs are sibling concepts — same Windows Failover Clustering plumbing underneath. The difference: FCI moves a SQL Server instance between nodes; Hyper-V FC moves entire VMs between hosts. Same shared storage requirement, same heartbeat network design, same quorum logic.
Assumptions before starting
This series assumes:
- You have a working Domain Controller already. Workgroup clusters are technically possible but a different (more painful) path; we use AD-joined nodes here.
- You can promote a server to a DC, join machines to a domain, and assign static IPs. These are foundational sysadmin skills the series doesn’t cover.
- You have Hyper-V available on a host beefy enough to run 4 nested VMs (DC + iSCSI + 2 cluster nodes). 16 GB RAM on the lab host is the realistic floor.
The four lab VMs
| VM Name | IP Address | Purpose | FQDN |
|---|---|---|---|
| DC | 10.15.1.100 | Domain Controller | DC.infotechninja.local |
| iSCSI | 10.15.1.106 | Shared Storage (SAN emulator) | iSCSI.infotechninja.local |
| NODE-01 | 10.15.1.101 | Cluster Node 1 (Hyper-V host) | NODE-01.infotechninja.local |
| NODE-02 | 10.15.1.102 | Cluster Node 2 (Hyper-V host) | NODE-02.infotechninja.local |
Domain: infotechninja.local. NODE-01 and NODE-02 in our lab are nested VMs running Hyper-V. In production these would be physical servers with dedicated hardware (or Tier-1 hypervisor hosts).
Networking plan — three vSwitches
Hyper-V FC uses three logical networks. We’ll create three vSwitches at the Hyper-V level on each node:
1. External Switch
Connects all VMs to the main network. Routes externally, has DNS, has gateway. Subnet 10.15.1.0/24.
2. Storage Switch (Internal)
Carries iSCSI traffic between the SAN VM and the cluster nodes. Critical: isolate from regular traffic — iSCSI is bandwidth-heavy and latency-sensitive.
| NIC name | Attached VMs | IP Addresses |
|---|---|---|
| Storage | iSCSI, NODE-01, NODE-02 | 10.10.10.10 (iSCSI) / 10.10.10.11 (NODE-01) / 10.10.10.12 (NODE-02) |
Subnet: 255.255.255.0. No gateway, no DNS. This is a private subnet — nothing routes off-host.
3. Heartbeat Switch (Private)
Cluster heartbeat traffic only — node-to-node. The SAN VM does NOT attach (it doesn’t vote in cluster quorum).
| NIC name | Attached VMs | IP Addresses |
|---|---|---|
| Heartbeat | NODE-01, NODE-02 | 10.10.20.20 (NODE-01) / 10.10.20.21 (NODE-02) |
Subnet: 255.255.255.0. No gateway, no DNS. Truly private.
The cluster IP
Cluster Name Object (CNO) gets its own IP: 10.15.1.107. This IP follows whichever node owns the cluster admin role. Plus, each highly-available VM created later gets its own VIP for client access.
Why three networks (the split-brain story)
Cluster Service uses the heartbeat network to send small “are you alive?” packets between nodes. If the heartbeat is silent for ~5 seconds, the surviving node assumes its partner is dead and starts taking over the dead node’s VMs.
If both nodes can talk to storage but can’t talk to each other (heartbeat NIC dies, storage NIC survives), they BOTH try to start the same VMs from the same storage. That’s split-brain — can corrupt VHDX files within seconds.
Three networks aren’t a luxury — they’re structural defence:
- External heavy load (backups, client traffic) doesn’t starve heartbeat ⇒ no false failover.
- Heartbeat link failure doesn’t kill storage access ⇒ no node-isolation panic.
- Storage saturation doesn’t starve heartbeat ⇒ no flapping.
Combined with a quorum witness disk (covered in Part 11), the cluster has explicit tie-breaker logic for every failure mode.
Hyper-V FC vs SQL FCI — what’s the difference?
Both use Windows Failover Clustering as the underlying mechanism. The role is different:
- Hyper-V FC — cluster runs hypervisor hosts. The clustered “role” is each VM. Failover moves a VM from one host to another. Ideal for: any guest workload that doesn’t have its own HA layer (legacy apps, file servers, AD DCs that need HA at the OS level).
- SQL FCI — cluster runs SQL Server installations. The clustered “role” is the SQL service itself. Failover moves the SQL instance to a different node. Ideal for: SQL Server when you want a single instance with shared storage rather than replicated databases (Always On AG).
Both can coexist on the same Windows Failover Cluster. Both share the same plumbing, networking, and quorum design. If you’ve done one, the other is ~70% the same effort.
What you need before Part 2
- A working DC at
10.15.1.100(or your chosen IP) - Hyper-V running on a host with at least 16 GB RAM available for the four lab VMs
- An ISO of Windows Server 2022 (or 2019) for the cluster nodes and SAN VM
- Time. Setup takes 4-8 hours of focused work for someone new to clustering.
What’s next
Part 2 builds the iSCSI VM — the SAN emulator. Parts 3-6 build the cluster nodes and configure networking. Parts 7-11 build the actual cluster. Parts 12-15 cover advanced topics — CSV, nested virtualisation, highly available VMs, storage expansion. See the full series at Hyper-V Failover Clustering pathway.