Automatically shutting down Hyper-V VMs during a power outage

The automatic stop action: save, shut down or turn off

Every Hyper-V VM has an automatic stop action (AutomaticStopAction). It defines what happens to the VM when the host server shuts down. There are three options, and the default is Save:

PowerShell on the host shows and changes the setting for your VMs:

Get-VM | Select-Object Name, State, AutomaticStopAction
Set-VM -Name "SQL01" -AutomaticStopAction ShutDown

Important: the stop action only applies when the host is shut down. It is a useful fallback, but no protection against a power outage. Without a trigger, the host keeps running until the UPS battery is empty, and then host and VMs go down hard at the same time.

Why the stop action alone is not enough

1. There is no trigger
   The host knows nothing about the UPS. Something has to detect battery operation, evaluate the remaining runtime and start the shutdown, via USB cable on a single server or over the network via SNMP or NUT.
2. Time is limited
   During shutdown, Windows waits for the stop actions of all VMs. How long that takes depends on their number, memory and disk speed. Trigger too late and the battery runs out before every VM is saved or shut down.
3. No order
   The stop action runs for all VMs of a host at roughly the same time. Dependencies such as "application servers before the database, domain controllers last" cannot be expressed, let alone across several hosts.
4. Several hosts, one UPS
   If several Hyper-V hosts share one UPS, each needs a trigger. Software installed per host works independently: every host decides on its own, nobody coordinates.
5. Power comes back
   Short outages are more common than long ones. Shutting everything down at the first battery signal takes the environment down even for a twenty-second dip. Thresholds, several confirmations and an abort window make sense.

In which order VMs should be shut down

The basic rule: first the VMs nothing else depends on, last the ones others need. A proven order for typical Windows environments:

1. Terminal and application servers — Remote Desktop, ERP, web servers. They write to databases and file shares and should close their connections cleanly while the other side is still running.
2. Database and mail servers — SQL Server, Exchange. Both are crash-safe but come back faster after a clean stop. Details in the guide SQL Server & Exchange on Hyper-V.
3. File and print servers
4. Domain controllers last — so that authentication and DNS keep working for the remaining VMs until the end. Why a hard power-off of a DC is usually no disaster anyway is covered in Active Directory & power outages.
5. Finally the host itself — only once every VM is off or saved.

On restart the order is reversed. Hyper-V provides the automatic start action with a delay in seconds for this: the domain controller starts immediately, all other VMs a few minutes later.

The value that matters is Start. The default StartIfRunning (“Automatically start if it was running when the service stopped”) only starts VMs that were still running when the host shut down. If a tool shuts the VMs down individually beforehand, they stay off afterwards.

Set-VM -Name "DC01"  -AutomaticStartAction Start -AutomaticStartDelay 0
Set-VM -Name "SQL01" -AutomaticStartAction Start -AutomaticStartDelay 120
Set-VM -Name "APP01" -AutomaticStartAction Start -AutomaticStartDelay 240

Failover clusters add quorum and Cluster Shared Volumes to the picture, see Hyper-V failover cluster power outage.

Calculating the right moment

The trigger threshold has to cover the complete shutdown plus a reserve. Work backwards, using measured rather than estimated times:

The reserve is not a luxury: the runtime a UPS reports is an estimate by its firmware and becomes increasingly optimistic as the battery ages. It therefore pays to add a minimum battery charge as well, with both values active: whichever is crossed first triggers the shutdown. Why datasheets and displays are often off is explained in Calculating UPS runtime.

Automatic, ordered, no agents on the hosts

The UPS Hyper-V Shutdown Monitor runs as a Windows Service on one machine in the network, polls the UPS via SNMP or NUT and controls the Hyper-V hosts via WinRM, without extra software on the hosts:

1. Trigger with thresholds — battery charge and remaining runtime, default 20 % and 300 seconds, freely adjustable. It only triggers after three consecutive confirmations (adjustable), so a short dip does not shut anything down.
2. Order across hosts and VMs — hosts and VMs get an order. VMs at the same level shut down in parallel; the next level only starts when the previous one has finished.
3. Shut down or save per VM — choose per VM: clean shutdown (Stop-VM) or save state (Save-VM). If a VM does not respond within the time limit (default 120 seconds per host), it is turned off so the host can shut down safely.
4. One machine coordinates every host — including physical servers without Hyper-V and, if desired, the local machine at the very end.
5. Abort window — if power returns shortly after the trigger, the shutdown is cancelled (default 15 seconds).
6. Test first — readiness check, dry run with estimated total duration and a test mode that logs the whole sequence without shutting anything down.

Everything above is included in every edition. Multiple UPS units with host assignment and live migration to a host that still has power come with the Pro edition. More in the feature list and the setup guide.

Check before the next power outage

1. "Shutdown" integration service enabled — Get-VMIntegrationService -VMName <name> lists it per VM. Linux guests need the Hyper-V integration (hv_utils), which current distributions include.
2. Set the automatic stop action deliberately — as a fallback in case the host is ever shut down without stopping the VMs first. With "Save", plan enough free disk space.
3. Document the order — which VM depends on which, and which domain controller shuts down last and starts first?
4. Measure times instead of guessing — shut every VM down once during a maintenance window and note the duration. That gives you the threshold (section 04).
5. Set start delays — domain controllers without delay, dependent VMs with delay.
6. Protect the monitoring itself — the machine that watches the UPS and shuts everything down must keep running until the end: not as a VM on one of the hosts it shuts down, or at least in the very last stage.
7. Test once — in test mode or during a maintenance window. The first real power outage should not be the first test.

Frequently asked questions