Why You Shouldn’t Let Virtual Machines “Sleep” After a Host Reboot?
As a system admin, you’ve likely felt that “gut-wrenching” moment when receiving a notification that a physical server rebooted unexpectedly in the middle of the night. If the host is running 20-30 virtual machines (VMs) and you have to log into each one to manually hit Start, it’s a real nightmare.
The biggest issue isn’t just the fatigue, but the boot order. Imagine a Web Server (position 3) booting up and attempting to connect to the Database (position 1) while the Database services are still loading. The result? Your application immediately throws a blank-screen 500 error.
From my experience running an 8-host cluster in real-world projects, I can confirm that Autostart is a critical feature. It allows us to set priority order and boot delays. The Database comes up first, followed by the Backend API, and finally the Frontend. This is the standard “self-healing” workflow that brings the system back to life without manual intervention.
Enabling Autostart: Don’t Let Your Host Choke
By default, VMware disables this feature to prevent all VMs from starting simultaneously. When that happens, IOPS can spike over 10,000, causing disk congestion and CPU overload right as the host boots.
To get started, follow these steps:
- Access the VMware Host Client via your browser.
- Select Manage from the left menu.
- Go to the System tab and find Autostart.
- Click Edit settings to begin configuration.
In this panel, pay close attention to three key parameters:
- Start delay: I usually set this to 120 seconds. This pause gives the previous VM enough time to load the OS and background services before the next one starts.
- Wait for heartbeat: This is crucial. If set to Yes, ESXi will wait for a signal from the VM’s VMware Tools before triggering the next virtual machine. This is much smarter than just relying on a fixed timer.
- Stop action: Choose Shut down. Don’t use Suspend if you want your data safely written to disk.
Setting Priority: Get the “Brains” Online First
After enabling the global feature, it’s time to assign roles to each VM. Not every VM needs to restart automatically.
Configuration via Web Interface
On the Autostart screen, select a critical VM (like an SQL Server) and click Configure.
- Autostart: Toggle to Enabled.
- Start order: Smaller numbers have higher priority. Golden rule: DB is 1, App is 2, Web/LB is 3.
Pro tip: Only add Production VMs to this list. Keep Dev/Test or backup machines on manual start to save system resources during the recovery phase.
For the Command-Line Enthusiasts (Automation)
If you need to configure an entire fleet of hosts, using SSH is much faster. To view the list and IDs of all VMs, use the command:
vim-cmd vmsvc/getallvmsThen, check the current autostart sequence with:
vim-cmd hostsvc/autostartmanager/get_autostartseqCrucial Lessons for vCenter and HA Clusters
This is a point of confusion for many. If an ESXi host is part of a cluster with vSphere HA (High Availability) enabled, host-level Autostart configurations are ignored.
In this environment, vSphere HA Orchestrator takes control. When a host fails, HA automatically restarts VMs on another host. In this case, you must go to vCenter and look for VM Overrides or VM Startup Priority to set the order, rather than configuring individual ESXi hosts.
Additionally, ensure that 100% of your VMs have VMware Tools installed. Without it, ESXi won’t receive the “heartbeat,” and the entire Autostart process will slow down as it waits for timeouts.
Quick Status Check Script for DevOps
You can use this small Python snippet to check if all VMs are up after a reboot and send a Telegram alert if necessary:
from pyVim.connect import SmartConnect
import ssl
# Skip SSL check for self-signed certs
scontext = ssl._create_unverified_context()
si = SmartConnect(host="192.168.1.100", user="root", pwd="password", sslContext=scontext)
for child in si.RetrieveContent().rootFolder.childEntity:
if hasattr(child, 'vmFolder'):
for vm in child.vmFolder.childEntity:
print(f"VM: {vm.name} -> Status: {vm.runtime.powerState}")I hope these practical insights help your systems run more smoothly and save you from those late-night “emergency watches” whenever a physical server acts up.
