In 2019, a new VM advanced setting called vmx.reboot.PowerCycle was introduced and greatly simplified the remediation of CPU vulnerabilities for our customers. The operational challenge that came with applying CPU microcode updates was that all running VMs on an ESXi host would need to go through a complete power cycle (power off and power back on) before the guest operating system(s) would be fully protected.
The new VM setting would notify ESXi to convert a guest operating system reboot into a VM power cycle operation, which aligns nicely when an organization applies a guest OS update or patch and the guest OS is then rebooted afterwards. The benefit to our customers is that the remediation of CPU vulnerabilities can co-exists with an organizations existing maintenance window and the OS is remediated through a regular guest OS reboot. From the guest OS point of view, nothing has changed, it still sees a reboot but from the VM virtual hardware point of view, a complete power cycle has occurred. A very cool and innovative solution if you ask me!?
The reason for this background, there is another use case that has also been operationally challenging which is upgrading the VM Compatibility, also known as VM Virtual Hardware. A VM must be powered off before you can change the VM Compatibility and a simliar challenge arises with coordinating the downtime of a VM with application owners/teams. What if we had a simliar capability like the guest OS reboot triggering a power cycle, but instead of power cycling the VM, it would simply power it off?
