Quick answer: Shut down the guest before forcing power off
This is an ESXi-host CLI reference, originally written for a vSphere 6.7-era incident. These actions can interrupt service. Identify the correct VM first, then choose either shutdown or reboot; a hard power-off is a last resort.
Jump to identify the VM, check power state, shutdown and last-resort power-off, or guest reboot.
Recently, I got to see something I haven’t had to experience in a while. I had a VM that wouldn’t power down in the GUI even after I vMotion it to another host. I had to go back into my old school archive for the procedure of bringing down a VM via CLI from the ESXi host it lives on.
Step 1 — Confirm the host and the maintenance decision.
Use an approved ESXi Shell or SSH session on the host currently running the affected VM, with the administrative permissions required by your operating procedure. Confirm the application owner, outage window, and recovery plan before issuing a power-changing command.
Step 2 — Identify the VM.vim-cmd vmsvc/getallvms
Match the VM name and configuration-file path. Use its numeric VMID from the first column. In the examples below, replace VMID with that number; do not type a shell-prompt #.
Step 3 — Read the current state.vim-cmd vmsvc/power.getstate VMID
The command includes a dot between power and getstate. Reconfirm the host and VMID if the VM has moved.
Step 4 — Choose shutdown, not an automatic force-off.
For a guest shutdown, request:vim-cmd vmsvc/power.shutdown VMID
Allow time for the guest to stop, then check power.getstate again. Guest shutdown requires running VMware Tools and a responsive guest.
Last resort only: if graceful shutdown has failed and the application owner has accepted the risk, vim-cmd vmsvc/power.off VMID powers off the VM without an orderly guest shutdown. Unsaved data can be lost and recovery may be required. Do not run both commands as an unattended sequence.
Step 5 — Power on only when intended.
After confirming that the VM is powered off and the recovery or maintenance plan calls for startup, use:vim-cmd vmsvc/power.on VMID
Check the console, guest readiness, and application health after startup.
Alternative — Reboot a running guest.
If your intent is a guest reboot rather than a shutdown, use:vim-cmd vmsvc/power.reboot VMID
This requests a guest-OS reboot through VMware Tools. It is not the same as a hard reset. Do not power the VM off first and then treat this as the next step. Confirm guest and application health afterward.
Summary. This article began as a vSphere 6.7-era troubleshooting note. The command names above were checked against Broadcom’s command reference. For an unresponsive VM, use the current vendor troubleshooting procedure appropriate to your ESXi release; guest-operation requirements are documented in the vSphere API reference. If commands fail or a task remains stuck, stop and investigate rather than escalating automatically to process kills or a host restart.