Skip to content
Calcrivo

Host Failure Impact Calculator

Quantify a host failure: VMs affected, capacity lost, post-failure utilisation, restart window and the availability cost.

Inputs

hosts
VMs
hosts
%
seconds

Guest boot plus application start, not just the power-on operation.

VMs

vSphere HA restarts in batches rather than all at once.

seconds
USD

Editable placeholder — use your own service's measured cost of downtime.

VMs Requiring Restart

28VMs

Cluster Capacity Lost

12.5%

Utilisation After the Failure

74.3%

Restart Window

1m

Cost of the Outage

$10.61

Survivability Verdict

Survivors absorb the load comfortably

Step by step

  1. Values used

    Hosts in cluster = 8 hosts; VMs in cluster = 220 VMs; Hosts lost = 1 hosts; Cluster utilisation before the failure = 65 %; Restart time per VM = 45 seconds; VMs restarted concurrently = 32 VMs; Failure detection and election time = 30 seconds; Cost of downtime per hour = 4,000 USD

  2. Host Failure Impact

    VMs affected = ceil(VMs ÷ hosts) × hosts lost; post-failure utilisation = current utilisation × hosts ÷ surviving hosts; restart window = detection time + ceil(VMs affected ÷ concurrent restarts) × restart time.

  3. VMs Requiring Restart

    = 28 VMs

  4. Cluster Capacity Lost

    = 12.5

  5. Utilisation After the Failure

    = 74.3

  6. Restart Window

    = 1.25

  7. Cost of the Outage

    = 10.61

  8. Survivability Verdict

    = Survivors absorb the load comfortably

How it works

Two independent things happen when a host dies. Capacity redistributes onto the survivors, and because the denominator shrinks the utilisation rise is non-linear — losing one host of eight at 65% pushes survivors to 74%, but losing two pushes them to 87%. Separately, HA has to detect the failure, elect a master and restart the VMs in batches, which is what the users actually experience as downtime. HA guarantees a restart, not a fast one: a hundred VMs restarting 32 at a time with a 45-second application start is over two and a half minutes of outage before detection is even counted. Substitute your own cost-of-downtime figure; the default is a placeholder.

Formula

Host Failure Impact

VMs affected = ceil(VMs ÷ hosts) × hosts lost; post-failure utilisation = current utilisation × hosts ÷ surviving hosts; restart window = detection time + ceil(VMs affected ÷ concurrent restarts) × restart time.

post-failure utilisation
Load redistributed across the survivors, which rises non-linearly
concurrent restarts
HA restart batch size, not the total VM count
detection time
Heartbeat timeout plus master election before restarts begin

Frequently Asked Questions

How is Host Failure Impact calculated?

VMs affected = ceil(VMs ÷ hosts) × hosts lost; post-failure utilisation = current utilisation × hosts ÷ surviving hosts; restart window = detection time + ceil(VMs affected ÷ concurrent restarts) × restart time. Two independent things happen when a host dies. Capacity redistributes onto the survivors, and because the denominator shrinks the utilisation rise is non-linear — losing one host of eight at 65% pushes survivors to 74%, but losing two pushes them to 87%. Separately, HA has to detect the failure, elect a master and restart the VMs in batches, which is what the users actually experience as downtime.

Why does Host Failure Impact matter?

HA guarantees a restart, not a fast one: a hundred VMs restarting 32 at a time with a 45-second application start is over two and a half minutes of outage before detection is even counted. Substitute your own cost-of-downtime figure; the default is a placeholder.

What values do I need to enter?

This calculator takes 8 inputs: Hosts in cluster, VMs in cluster, Hosts lost, Cluster utilisation before the failure, Restart time per VM, VMs restarted concurrently, Failure detection and election time, Cost of downtime per hour. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why does utilisation rise faster than the capacity lost?

Losing one host of eight removes 12.5% of capacity, but the same workload now divides across seven hosts instead of eight — a 14.3% increase in per-host load. The effect compounds with each additional host lost, which is why small clusters need proportionally more headroom.

You might also need