I have created a work-around and will share here, because this is an important (essential) capability to have.
Background
Question: How do I set up VMWare Workstation 12.5 (running on a Windows host) to automatically suspend all guest VM's when the host OS shuts down or restarts?
I have read several posts on this over the years: I know they exist, but none are helpful.
Fact: Windows 10 will automatically apply updates and restart the machine whenever it feels like it, with little ability for the user to control or disable this behavior.
I am a developer and business user, and use VMWare Workstation (NOT Server) so that I can have multiple VM's open for various interactive purposes: different development environments, different applications, etc.
If Windows 10 chooses to apply an update in my absence (which it regularly does, without my ability to prevent this from happening), this essentially halts all the running VM's, causing loss of work and potential data corruption. This is entirely unacceptable.
To be clear, this is not a matter of convenience (i.e. that I am lazy and don't want to suspend the gust VM's before I explicitly shutdown), but is rather that the host OS may spontaneously shutdown or restart without my control. Thus random loss of work and data is an inherent and regularly-encountered aspect of running VMWare Workstation 12.5 on a Windows 10 host. There must be a way to correct this problem.
Should be Automatic
According to: VMware Workstation 12 Pro Release Notes a new feature of VMWare Workstation Pro 12 was: "Automatically suspend virtual machines upon host shutdown". But this does not seem to actually work / to be present, and I can find no menu options or documentation pertaining to this feature.
PItfalls
A Windows "shutdown" script won't always work for Windows 10 because of the way fastboot works and because of other changes to the shutdown sequence in Windows 10 (not well-understood). This means that old answers that say "Create a shutdown script...configure in GPO", etc. are not satisfactory.
Even disabling fastboot does not allow shutdown scripts to run reliably. There are a number of potential factors, including whether or not you are booting the host from a VHD or from a physical disk, edition of Windows, etc.
Furthermore, even if you could get the shutdown script to run reliably, it may run too late in the shutdown sequence--after the applications, including VMWare Workstation have been terminated...which means that the Windows shutdown script approach is not a useful option.
Solution: Create a Scheduled Task in Windows Task Scheduler
The heart of this work-around is to create a scheduled task using the Windows Task Scheduler. The scheduled task should be triggered by certain system events (not by a specific time-of-day schedule).
There are several different events that must trigger this task, as some events apply to only certain shutdown sequences (i.e. command line-initiated, Windows UI initiated, power button, system updates, etc.)
The actual script to execute is below.
The scheduled task should have the following:
Launch "Task Scheduler"
Click on "Task Scheduler Library" treeview (left side of screen)
Click on "Create Task" in the Actions window (right side of screen)
Under "General" tab, provide an appropriate name
Under "General" tab, check: "Run only when the user is logged on"
Under "General" tab, check: "Run with highest privileges"
Under "Triggers", you will click "New" to add a new trigger, and will repeat this and the following settings 6 times (6 individual triggering events should be set). For each:
"Begin the task:" should be set to "On an event"
Select the Log, and the Source, and type in the Event ID for each of the 6 events. The rest of the settings on the screen can be left at their defaults.
Log:System
Source:User32
Event ID:1074
Log: Microsoft-Windows-Winlogon/Operational
Source:Winlogon
Event ID:7002
Log: Microsoft-Windows-Eventlog-ForwardingPlugin/Operational
Source:Eventlog-ForwardingPlugin
Event ID:6005
Log: Microsoft-Windows-Eventlog-ForwardingPlugin/Operational
Source:Eventlog-ForwardingPlugin
Event ID:6006
Log:Security
Source:Microsoft Windows security auditing.
Event ID:4634
Log:Security
Source:Microsoft Windows security auditing.
Event ID:4647
Under "Actions" tab click "New", the default Action of "Start a program", and click Browse or type in the path to the batch file (see below for the batch file itself).
By using a scheduled task that is triggered by these events, it seems like Windows 10 does reliably launch the batch file at shutdown (or more technically correct, at user logoff).
Batch File
Create a batch file and save it somewhere on you local hard drive. You can use Notepad to do this. Name it something that ends in .bat (not .txt)...so when in Notepad you click Save, make sure "Save as file type" is set to "All Files (*.*)" so that Notepad does not append a .txt to the filename.
The contents of the file should be something like this:
@echo off
echo SuspendRunningVMs Command (x64)...
SETLOCAL
REM Specify where vmrun.exe can be located
SET WSPath="C:\Program Files (x86)\VMware\VMware Workstation"
REM Get the list of currently running VMs
%WSPath%\vmrun.exe list | FIND /V "Total running VMs:" > %temp%\vmlist.txt
REM Suspend all running VMs
FOR /F "delims=*" %%v IN (%temp%\vmlist.txt) DO CALL :SuspendVM "%%v"
:WaitLoop
echo Waiting for the VMs to suspend...
REM Pause until no more VMs are running
%WSPath%\vmrun.exe list | FIND "Total running VMs: 0"
IF NOT ERRORLEVEL 1 GOTO End
timeout /t 10 /nobreak
GOTO WaitLoop
:End
echo End of script; all VMs suspended.
ENDLOCAL
GOTO :EOF
REM Suspend a VM
:SuspendVM
REM Suspend any running VM. Workaround a "vmrun list" quirk that outputs
REM a blank line, by not trying to suspend a blank VM
IF %1x==x GOTO :EOF
echo Suspending VM %1
%WSPath%\vmrun.exe suspend %1
REM Allow some time after suspend call (allow disk to write vmem).
echo Wait a little bit for the VM to commit...
timeout /t 15 /nobreak
GOTO :EOF
REM Resume a VM (not used now, but may have use in future)
:ResumeVM
REM Resume any suspended VM. Workaround a "vmrun list" quirk that outputs
REM a blank line, by not trying to start a blank VM
IF %1x==x GOTO :EOF
echo Starting VM %1
%WSPath%\vmrun.exe start %1
GOTO :EOF
:EOF
Summary
I cannot understand how auto-suspend of all VM's upon shutdown of the Windows host has not been and is still not a built-in feature of VMWare Workstation running on Windows. This seems to be critical to anyone who does not want to loose work and risk corrupting data in their VM's. This need has intensified with Windows 10 as the host, because Windows will spontaneously reboot the computer when it applies updates, and Microsoft does not provide a way to prevent this spontaneous reboot from occurring.
Please, VMWare, make this capability a feature of future VMWare Workstation releases. This is not a "server-only" feature: even interactive users of VM's don't want to loose unsaved data and state of their virtual machines.
References
I did a lot of research on this, and was aided by a number of different posts from different people. I will provide the URL's here:
Question about Task Scheduler during logoff event
https://social.technet.microsoft.com/Forums/en-US/a9eaa5ac-b772-4647-a0b1-72257cdc091a/windows-10-sh...Windows CMD Script to Aid Backups (esp. post #3)
Windows 10 Shutdown Scripts not always running
https://www.reddit.com/r/Windows10/comments/3yk73v/shutdown_script_called_via_local_machine_group
VMware Workstation 12 Pro Release Notes (see "Automatically suspend virtual machines upon host shutdown")
Improvement Suggestion: Suspend VMs Automatically On Host Log-off/Shut-down
drueter
That's some good research and nice work, Thanks!
About the call for feature, VMware Development team has been looking to incorporate this feature for sometime and we have as new Tech Preview running right now which incorportates this feature along with other features you might find interesting.
"Automatically Suspend Shared VM Upon Host Shutdown - All your running shared virtual machines will be automatically suspended when your host operating system is about to shutdown."
You can try our Tech Preview 2017 for WS to find out more.
I have been able make may AutoStart Shared VMs suspend when my Win10 Host shuts down, reboots, or hibernates on my VMWare Pro 12 system (now 12.5.7) for quite some time. I honestly don't know why VWMare doesn't document this or provide this capability in the UI, but it's easy:
Edit C:\ProgramData\VMWare\hostd\vmAutoStart.vmAutoStart.xml and change the xml tags named <stopAction> from "GuestShutdown" to "Suspend". Problem solved.
I don't think this affects regular Guests that are not Shared VMs, but it works perfectly for Shared VMs configured for Autostart. You will have to configure the Shared VMs for AutoStart in the UI (Shared VMs / Manage AutoStart VMs) before you edit this file, and if you add or change any Autostart VMs you will have to edit the file again. But it does work.
Create a script to run during system shutdown - SuspendVMs.bat
this suspends all VM images not just shared ones
-------------------------------------
cd C:\Program Files (x86)\VMware\VMware Workstation
for /f %%G in ('vmrun list') DO vmrun suspend %%G"
exit
-------------------------------------
Please the file in C:\Windows\System32\GroupPolicy\Machine\Scripts\Shutdown
then Edit Group policies to run it - reference
https://lifehacker.com/use-group-policy-editor-to-run-scripts-when-shutting-do-980849001
https://lifehacker.com/use-group-policy-editor-to-run-scripts-when-shutting-do-980849001
basically run gpedit.msc
then
Computer configuration
Windows Settings
Scripts(Startup/Shutdown)
on right side double click shutdown
the ADD the script to the list
As the original poster said, using a simple shutdown script (via GPO) is unreliable. In my case, it worked on one machine, but on another the script would run after the VMW process had already been shutdown, so it was too late to suspend the running vm's.
It is bizarre that this hasn't been exposed as a basic feature in all these years. If it's any incentive: Hyper-V suspends running vm's by default whenever the host is shutdown/restarted.
Hi omf,
This was implemented in Workstation 14. I agree with you however that that was royally late.
--
Wil
Hey Wil.
Is there a setting to enable the Auto Shutdown?
I have Workstation 14.1 on Win 10 and I came in this morning to a rebooted PC (!%^$*)#%&$()&$@#(^%)#!@@)
None of my VMs got suspended 😞
Nice work! Thank you for sharing your workaround!
Hello Thomas,
Does this help?
Manage Virtual Machine Power Actions on Shared and Remote Hosts
--
Wil
Ah. Yes, that is good. Thank You !
But you have to convert the VM to be Shared.
Are there drawbacks to this? for instance, can I still move the VMs to another machine at-will ?
Thomas,
It doesn't lock the VM to your machine, but it has some limitations:
Quote from http://kb.vmware.com/kb/2005585
When you share a virtual machine, you lose these features:
Unity
Shared Folders
AutoProtect
drag and drop
copy and paste
Thin Print
Ability to connect/redirect USB devices from the host to the virtual machine not available with Workstation 8.x
3D Acceleration
More about the process is written here:
Creating and Managing Shared Virtual Machines
--
Wil
Thank you for that. This is still relevant for v15.0.2
It works well, however when I launch a guest in VMware Workstation on host startup, a few minutes later while I"m using hosts, this scheduler triggers and shuts down the guest.
In fact, on host startup I see that batch file execution and task scheduler log shows that it triggers twice at the same time
Any ideas why?
Yes, I had the same problem with VMware 15 on Windows 10. This worked:
Edit the file "%PROGRAMDATA%\VMware\VMware Workstation\config.ini" as Administrator and add a new Line with:
vmx.headless.suspendOnHostShutdow = "TRUE"
Now it works without making the VM shared.
I found it quite hard to find this solution originally so I copied it and put it up on GitHub for easier retrieval and to make it smoother to improve as a group effort (when/if bugs are encountered). You can find it here. I attributed drueter, of course, but I couldn't find a real name for the account. I have also updated a corresponding SuperUser questions to guide more people in this direction.
The GitHub repo that contains this solution now contains an semi-automated installation (download two files and run a command). Seems to work well, but feel free to file bugs to the issue tracker . Thanks David!