How-To
How to Autostart VMware Workstation VMs
In my series of articles on using VMware Workstation on an Intel NUC 13 Pro Desk Edition PC (starting here), I configured a half dozen or so virtual machines (VMs) as thin clients so I could use them for demonstrations and testing.
It worked fine, but recently, Windows 11 (the base OS that I was running Workstation on) rebooted automatically; when it came back up, I had to restart the VMs manually. I knew that with ESXi (VMware's bare-metal hypervisor), you can set VMs to auto restart after a host reboots. After some searching, I found instructions for how to do the same for Workstation Pro 17 in the VMware workstation documentation. It should be noted that VMware Player and earlier versions of Workstation may or may not have this ability, and the information on which edition of Workstation Autostart is available is also a little sketchy.
In this article, I will show you how I enabled Autostart on Workstation Pro 17, hopefully giving this powerful feature more visibility.
Enable the Autostart Service
The Autostart feature is disabled by default. To enable it, enter run in the Search text box.
[Click on image for larger view.]
In the Run text box, enter services.msc.
[Click on image for larger view.]
In the Services screen, right-click VMware Autostart Service, and then click Properties from the drop-down menu.
[Click on image for larger view.]
In the Startup Type drop-down menu, select Automatic or Automatic (Delayed Start). Select Start to start service immediately. Then, click Apply.
[Click on image for larger view.]
Select the Log On tab and enter the user account that you installed Workstation with. Click Apply and then OK.
[Click on image for larger view.]
The Services dialog will now show that the service is running.
[Click on image for larger view.]
Select Which VMs to Autostart
Once the Autostart service has been enabled, you need to specify which VMs to start automatically.
From Workstation, right-click My Computer, and then select Configure Auto Start VMs from the drop-down menu. This must be done from the right navigation pane.
[Click on image for larger view.]
If you get the message "Failed to update AutoStart configuration. Ensure that the vmAutoStart.xml file exists and you have permissions to write this file,," you may have file permission issues.
[Click on image for larger view.]
Verify that the user you configured when setting up the VMwareAutostartService service has write permissions to the %ALLUSERSPROFILE%\VMware\VMware Workstation\vmAutoStart.xml.
[Click on image for larger view.]
Autostart will only work on VMs in the root folder. If you don't see any VMs or a particular VM in the Autostart dialog, ensure it is the root folder. The screenshot below shows that the only VM that can be auto-started is the one in the root folder.
[Click on image for larger view.]
You can specify the order in which the VMs start. For example, you may want a database to start before an application. From the Configure VM Power Actions dialog, you can specify the order.
[Click on image for larger view.]
Once VMs have been added to Autostart, they will start when the host system that Workstation is installed on is powered on, but not when they are initially added to the Autostart dialog.
I wanted to verify that when I rebooted the machine, the VMs would actually start when the host system rebooted and not when Workstation was powered on; using my monitoring tool, I could see that they were.
[Click on image for larger view.]
However, when I tried to interact with the VMs from Workstation, I only had a black screen. The services were running in the background, but I could not interact with them from the GUI; however, I could use RDP or SSH to interact with them.
Using Autostart, I ensured that the VMs I needed for testing were available after the host system rebooted. Autostart does have some quirks, such as only working in VMs in the root folder. It could also be enhanced by specifying a delay in the startup of the VMs that are auto-started. However, it is useful, and I hope VMware will continue to put resources into developing it.
About the Author
Tom Fenton has a wealth of hands-on IT experience gained over the past 30 years in a variety of technologies, with the past 20 years focusing on virtualization and storage. He currently works as a Technical Marketing Manager for ControlUp. He previously worked at VMware in Staff and Senior level positions. He has also worked as a Senior Validation Engineer with The Taneja Group, where he headed the Validation Service Lab and was instrumental in starting up its vSphere Virtual Volumes practice. He's on X @vDoppler.