How to configure auto-startup for VM

— ny_wk

VM auto-start tells a VMware ESXi host to power on selected virtual machines automatically whenever the host itself boots, so critical services come back online after a reboot or power outage without anyone logging in manually. This guide shows how to configure VM auto-start the modern way (vSphere Client and ESXi Host Client), the command line (esxcli), and the legacy VMware Infrastructure Client approach, plus the ordering, delays, and pitfalls that trip people up.

The problem: VMs stay powered off after a host reboot

Out of the box, an ESXi host does not automatically power on its virtual machines. If the host reboots after patching, a crash, or a UPS-triggered shutdown, every VM stays off until an administrator opens a client and powers them on by hand. For a domain controller, a database, or a jump host, that delay is exactly when you least want to be manually clicking around.

The fix is the host's Autostart Manager (also called VM Startup/Shutdown). It lets you enable automatic startup per host, choose which VMs start, set the order they start in, and tune the delay between each one so dependencies (for example, a database before the app server that needs it) come up in the right sequence.

One important boundary: autostart is a per-host setting. It controls VMs based on the physical host they are registered on. In a cluster protected by vSphere High Availability (HA), HA handles restarting VMs on surviving hosts after a host failure, and HA can override host autostart behavior. Use autostart for standalone hosts and for the orderly power-on of a single host; use HA for cluster resiliency.

Solution overview: three ways to enable VM auto-start

Pick the method that matches your environment:

• vSphere Client (vCenter Server) — the standard GUI when your hosts are managed by vCenter. Best for production fleets.
• ESXi Host Client — the HTML5 web UI built into every ESXi host (https://<host>/ui). Use it for standalone hosts with no vCenter.
• esxcli / command line — scriptable and ideal for automation, kickstart builds, or fixing things over SSH.

All three configure the same underlying host setting, so you can mix them. The legacy VMware Infrastructure Client (VI Client) from the ESX 3.x / vSphere 4 era did the same job through a panel called Virtual Machine Startup/Shutdown — that workflow is covered at the end for anyone still maintaining old gear.

Step-by-step: configure VM auto-start in the vSphere Client

This is the recommended path on any vCenter-managed host (vSphere 6.7, 7.0, and 8.0 all use the same HTML5 flow).

1. Log in to the vSphere Client at https://<vcenter-fqdn>/ui.
2. In the inventory tree, select the ESXi host (not the VM, not the cluster).
3. Open the Configure tab.
4. Under Virtual Machines, click VM Startup/Shutdown.
5. Click Edit in the top-right of that panel.
6. Check Automatically start and stop the virtual machines with the system. This enables autostart for the whole host.
7. Set the global defaults: Default startup delay (commonly 120 seconds), whether to Continue immediately if VMware Tools starts, the Default shutdown delay, and the Shutdown action (choose Guest Shutdown so guests shut down cleanly rather than being powered off).
8. In the VM list, select the virtual machines you want to manage and use Move Up / Move Down to place them under Automatic Startup in the order you want them powered on.
9. Optionally override per-VM startup order and delay for dependency chains (start the database first, then the app server).
10. Click OK to save.

That is the entire configuration. The host now powers on the listed VMs, in order, the next time it boots.

Step-by-step: VM auto-start on a standalone ESXi host (Host Client)

If the host is not joined to vCenter, use the built-in ESXi Host Client.

1. Browse to https://<esxi-host>/ui and log in as root.
2. In the left navigator, click Host, then Manage.
3. Open the System tab and select Autostart.
4. Click Edit settings, set Enabled to Yes, and adjust Start delay, Stop delay, Stop action, and Wait for heartbeat. Save.
5. Right-click a VM (or use the Autostart menu) and choose Enable, then use Increase priority / Decrease priority to order them.

On the free/standalone hypervisor, this Host Client method is the most reliable way to get VM auto-start working.

Configure VM auto-start from the command line with esxcli

For scripting, kickstart, or SSH repairs, drive autostart entirely from the shell. First enable the host-wide policy, then enable it per VM by VMID.

Turn on the host autostart policy and set sensible global delays:

1. Enable autostart with start/stop delays and a clean guest shutdown:
   esxcli system settings advanced set -o /AutoStart/Enabled -i 1
esxcli system settings advanced set -o /AutoStart/StartDelay -i 120
esxcli system settings advanced set -o /AutoStart/StopDelay -i 120
2. List registered VMs to get each VMID (the first column):
   vim-cmd vmsvc/getallvms
3. Enable autostart for a specific VM and set its order, using its VMID and the host's MoRef. The supported one-line tool is:
   vim-cmd hostsvc/autostartmanager/update_autostartentry <VMID> powerOn 120 1 guestShutdown 60 systemDefault
   The arguments are: VMID, start action, start delay (s), start order, stop action, stop delay (s), wait-for-heartbeat policy.
4. Confirm the configuration:
   vim-cmd hostsvc/autostartmanager/get_autostartseq

Lower start-order numbers boot first. Give dependencies (databases, directory services) the lowest numbers and a delay long enough for them to be ready before dependent VMs power on.

Recommended startup order and delays

The order matters when VMs depend on each other. A typical small-environment sequence looks like this:

If you enable Continue immediately if VMware Tools starts (or Wait for heartbeat: Yes), the host moves to the next VM as soon as VMware Tools reports the guest is up, rather than always waiting the full delay. That makes a long boot sequence much faster while still respecting dependencies.

Common pitfalls when VM auto-start does not work

Auto-start is simple, but a few specifics catch people out repeatedly.

• The host-wide checkbox is off. Per-VM order means nothing until Automatically start and stop the virtual machines with the system (or /AutoStart/Enabled = 1) is enabled for the host. This is the number-one cause of "my VM still won't auto-start."
• vSphere HA disables host autostart. On a cluster with HA turned on, vCenter can grey out or ignore the autostart panel because HA owns VM restart. For ordered power-on in a cluster, plan around HA (or use VM/host restart priorities and dependency settings in HA itself).
• The VM is in the "Manual Startup" group. Selecting a VM is not enough — it must be moved into the Automatic Startup section of the list. VMs left under Manual will not start.
• Delays too short for dependencies. If the app server starts before the database is accepting connections, services fail on boot. Increase the start delay or rely on the VMware Tools heartbeat.
• Stop action set to Power Off. For a graceful host shutdown, set the shutdown action to Guest Shutdown; a hard power-off can corrupt databases and filesystems.
• Forgetting it is per-host. If you vMotion or re-register a VM on a different host, its autostart membership does not follow it — you must configure autostart on the new host.
• VMware Tools not installed. Heartbeat-based "continue when Tools start" only works if VMware Tools is installed and running in the guest; otherwise the host falls back to the fixed delay.

How to verify VM auto-start is configured correctly

Do not wait for the next unplanned outage to discover it does not work. Verify deliberately.

1. Re-open the panel. In the vSphere Client, return to Configure > VM Startup/Shutdown and confirm the checkbox is enabled and your VMs appear under Automatic Startup in the intended order.
2. Check from the CLI. Over SSH run vim-cmd hostsvc/autostartmanager/get_autostartseq and confirm each VM shows powerOn with the order and delays you set, and esxcli system settings advanced list -o /AutoStart/Enabled shows Int Value: 1.
3. Do a controlled reboot. During a maintenance window, place the host in maintenance mode if needed, cleanly shut down or migrate VMs you do not want to test, then reboot the host and watch the VMs power on automatically in sequence.
4. Confirm clean shutdown. When you reboot the host, verify the guests shut down gracefully (Guest Shutdown) rather than being killed, by checking guest event logs for a normal shutdown entry.

Once a controlled reboot brings everything back in the right order, auto-start is proven.

Legacy method: VMware Infrastructure Client (VI Client)

On older ESX/ESXi managed by the thick VMware Infrastructure Client (the ESX 3.x / vSphere 4 era), the workflow is conceptually identical:

1. Launch the VMware Infrastructure Client and connect to vCenter (or the host directly).
2. Select the ESX host in the inventory.
3. Open Configuration, then Virtual Machine Startup/Shutdown.
4. Click Properties, then check Allow virtual machines to start and stop automatically with the system.
5. Highlight each VM and use Move Up to place it under Automatic Startup, then set its delay and order.

Modern note: The VI Client and ESX (with the Service Console) are end-of-life and unsupported. New deployments should run a supported ESXi release managed by the vSphere Client; treat the steps above only as a reference for maintaining legacy hardware that cannot yet be upgraded.

Key Takeaways

• VM auto-start is a per-host setting in the Autostart Manager / VM Startup-Shutdown panel — enable it on the host before any per-VM order takes effect.
• Use the vSphere Client for vCenter-managed hosts, the ESXi Host Client for standalone hosts, and esxcli/vim-cmd for scripting.
• Set startup order and delays so dependencies (DNS, then database, then app) come up in sequence, and use the VMware Tools heartbeat to speed long boots.
• Choose Guest Shutdown as the stop action so VMs shut down cleanly instead of being powered off.
• On a cluster, remember that vSphere HA can override host autostart — and always verify with a controlled reboot.

Frequently Asked Questions

Why won't my VM start automatically after enabling auto-start?

The most common reasons are that the host-wide Automatically start and stop with the system option is still off, the VM is sitting in the Manual Startup group instead of Automatic Startup, or vSphere HA is enabled on the cluster and is overriding host autostart. Re-open the VM Startup/Shutdown panel and confirm the checkbox is set and the VM is in the automatic group.

Does VM auto-start work with vSphere HA in a cluster?

HA and host autostart serve different purposes. Host autostart powers VMs on when that specific host boots; vSphere HA restarts VMs on surviving hosts after a host failure and can disable or override the autostart panel. For cluster resiliency rely on HA and its VM restart priorities; use autostart for standalone hosts or orderly single-host power-on.

How do I set the startup order so a database boots before its app server?

In the VM Startup/Shutdown list, move the database VM above the application VM under Automatic Startup, and give the database a low start order with a delay long enough for it to accept connections before the app server starts. From the CLI, assign the database a lower start-order number with vim-cmd hostsvc/autostartmanager/update_autostartentry.

Can I configure VM auto-start without vCenter?

Yes. On a standalone ESXi host, use the built-in ESXi Host Client at https://<host>/ui under Host > Manage > System > Autostart, or configure it over SSH with esxcli and vim-cmd. vCenter is only required for the centralized vSphere Client workflow.

For more hands-on sysadmin and virtualization walkthroughs, subscribe on YouTube @explorenystream.