Accepted Solutions
If you duplicate the /Library/vCenter/Virtual Machine management/Power Management/Reboot guest OS workflow and modify it, you can fix this behavior. In the duplicated workflow, change the script content to the following (assuming you want to start the VM if it's off; if not - remove the "vm.powerOnVM_Task()" call from the else block):
if(vm.runtime.powerState.value == "poweredOn") {
vm.rebootGuest();
}
else {
vm.powerOnVM_Task();
}
If you're using that workflow, it calls the Initiate Guest OS Reboot (i.e. graceful shutdown) from vCenter:
vCenter is the one kicking the error back to vRO because it can't reboot a guest that isn't running.
Note that my script change does not account for the correct action for all possible power states, it just checks to see if the VM was already on before calling rebootGuest, otherwise, it calls powerOnVM_Task(); This is probably safe for most cases.
If you couple this with a wait workflow that reboots, sleeps for a minute or so , and then waits for VMware tools to report good to go, then you know the reboot operation finished. The reason for sleeping is to give the vCenter time to realize VM Tools isn't running and update that status. You may need to make it longer in case you think a shutdown on the VM takes a while as is the case for some complex applications to receive kill signals and shutdown gracefully.
The schema for the Reboot Guest OS and Wait workflow looks like this (I previously made this one for other projects; I can share if you like, but it's pretty simple and you can build it yourself in a couple of minutes):
If you duplicate the /Library/vCenter/Virtual Machine management/Power Management/Reboot guest OS workflow and modify it, you can fix this behavior. In the duplicated workflow, change the script content to the following (assuming you want to start the VM if it's off; if not - remove the "vm.powerOnVM_Task()" call from the else block):
if(vm.runtime.powerState.value == "poweredOn") {
vm.rebootGuest();
}
else {
vm.powerOnVM_Task();
}
If you're using that workflow, it calls the Initiate Guest OS Reboot (i.e. graceful shutdown) from vCenter:
vCenter is the one kicking the error back to vRO because it can't reboot a guest that isn't running.
Note that my script change does not account for the correct action for all possible power states, it just checks to see if the VM was already on before calling rebootGuest, otherwise, it calls powerOnVM_Task(); This is probably safe for most cases.
If you couple this with a wait workflow that reboots, sleeps for a minute or so , and then waits for VMware tools to report good to go, then you know the reboot operation finished. The reason for sleeping is to give the vCenter time to realize VM Tools isn't running and update that status. You may need to make it longer in case you think a shutdown on the VM takes a while as is the case for some complex applications to receive kill signals and shutdown gracefully.
The schema for the Reboot Guest OS and Wait workflow looks like this (I previously made this one for other projects; I can share if you like, but it's pretty simple and you can build it yourself in a couple of minutes):