If you’re running an ESXi server for managing your home lab environment – or even for other niche use cases out in the field – the use of a startup and shutdown order can assist with lab maintenance. In my case, a new circuit panel was being installed in my home for non-lab related reasons (it was an old piece of crap and my kitchen needed an additional circuit). This requires going without power for a brief period of time. Thus, I leveraged my startup order to ensure that all of my critical management virtual machines were powered off, and later powered on, in the correct order.
One major caveat to this? It doesn’t work if the VMs are moving around from host to host. The startup order only affects VMs on a specific host. It’s no big deal for my environment because my management server is a standalone ESXi node. You can get around this limitation by using PowerCLI scripts, but I wanted something that was dead simple to use and had zero dependencies on me being at home.
Startup Order Planning
If you plan to use this feature, make sure to adhere to the following:
- Make sure the VMs called out in your startup order do not migrate around to another host. Otherwise, the order becomes irrelevant.
- Don’t manually power off the VMs. Just issue a Shutdown command to the host running the VMs. The host will gracefully power off the VMs based on the reverse of your startup order configuration. Once the host comes back online, it will run the startup order to power on the VMs.
I also noticed that my Domain Controller takes a few minutes to properly initialize and begin handling domain services. Unfortunately, VMware Tools starts up early in the process. To work around this issue, I disabled the “Continue immediately if the VMware Tools start” feature. Instead, the host will wait 5 minutes (300 seconds) before powering on each VM on the list.
After power was restored to the house, my management server clicked back on and a few minutes later I could see that the critical VMs were powered on and ready to service requests. I wish this sort of functionality was baked into vSphere in such a way that it could cross multiple host nodes without relying on vCenter. Sort of like High Availability (HA).