Hyper-V Failover Cluster Power Outage

A cluster doesn't fail as a whole — it fails in pieces

For a single Hyper-V host it's simple: power goes out, the UPS reports critical, VMs shut down gracefully, host powers off. A Windows Failover Cluster with multiple Hyper-V nodes is more complicated, because the cluster itself is a distributed system that needs a quorum majority of healthy nodes to stay operational at all.

If only part of the nodes lose connectivity or power in an uncoordinated way while others keep running, the cluster service can interpret that as a network partition — with all the risk that carries for Cluster Shared Volumes (CSV) and running VMs: stuck handles, delayed failovers, and in the worst case a quorum loss that takes down the entire cluster even though enough nodes were technically still up.

That's why clusters follow a rule that doesn't matter for a single host: a cluster shut down completely and in sync is safer than one shut down halfway. Shutting down hosts individually and uncoordinated, whichever one happens to hit its threshold first, risks exactly the scenario UPS monitoring is meant to prevent.

One UPS for the whole cluster — or a separate UPS per host?

Before thinking about software, it's worth looking at your own power setup. In practice there are two fundamentally different starting points:

Migrate where possible — shut down in sync when not

For scenario B (separate UPS per host), a simple "UPS critical → shut down this host" script isn't enough, because it has no idea whether the rest of the cluster is still healthy. The UPS Hyper-V Shutdown Monitor handles this with two mechanisms that work together, configurable per host:

1. Live migration to the healthy partner host
   If a host loses its power supply completely, the software first checks whether a configured partner host — on a different UPS — is still healthy and has enough runtime left. If so, its running VMs are moved there via Move-VM before the emptied host shuts itself down. This requires either a real failover cluster with shared storage or a correctly configured shared-nothing migration.
2. Synchronous full shutdown when migration isn't possible
   If the partner host is affected too — say the outage is bigger than expected — the software deliberately does not migrate partially, but gracefully shuts down the entire configured environment once the thresholds are reached. That's exactly what avoids the half-shut-down state described in section 01.
3. UPS redundancy with a minimum-runtime threshold
   If a single host has two independent power feeds (two power supplies, two UPS units), its shutdown is deferred rather than triggered as long as the second UPS is still healthy and, optionally, reports a configured minimum remaining runtime — the host is still running on the intact feed after all.

Live migration and the minimum-runtime threshold for the migration target are Professional features. See the full feature list or the edition comparison for details.

Check before the next power outage

1. Document your power topology — which node is on which UPS, which circuit, which part of the building? Without this you can't tell scenario A from scenario B.
2. Place the quorum witness independently — a file-share witness on its own, unrelated power circuit, or a cloud witness (which is outside your own data center by design), prevents the same outage from taking down both the cluster nodes and the witness, leaving quorum unreachable.
3. Define a shutdown order — gracefully shut down or migrate VMs first, then the cluster service, then the host itself. Never hard-power-off a host while the cluster service is still active.
4. Set realistic per-host thresholds — a shutdown triggered too late leaves no time for an orderly migration; the runtime reserve needs to account for how long migration itself takes.
5. Use test mode before the real thing — run through the shutdown sequence and live migration once in test mode (logged, not executed) before the first real power outage becomes the first test.
6. Place UpsMonitor itself independently — if the management VM running UpsMonitor lives on one of the monitored hosts or shares its UPS, it can go down along with a real outage before it finishes orchestrating the shutdown of the other hosts. A plain live migration of that VM is not a concern (the running process just keeps executing through the migration) — what matters is where it stands during a real outage, not whether it was migrated in between.