A virtual machine that ignores a guest shutdown, greys out in vCenter, or sits at “Powering off” for twenty minutes needs to be stopped from the host. ESXi offers three progressively blunter tools: vim-cmd, which asks hostd to perform a power operation; esxcli, which signals the VMX process directly; and esxtop, which kills the VMX world at the kernel level. Use them in that order. The commands apply to ESXi 7.0, 8.0 U3 and 9.x, standalone or managed by vCenter.
Table of Contents
Short answer: SSH to the host, find the VM with vim-cmd vmsvc/getallvms, confirm its state with vim-cmd vmsvc/power.getstate <VMID>, and try vim-cmd vmsvc/power.shutdown <VMID> then vim-cmd vmsvc/power.off <VMID>. If those fail with “The operation is not allowed in the current state” or “Another task is already in progress”, get the World ID with esxcli vm process list and run esxcli vm process kill -t soft -w <WorldID>, escalating to -t hard and finally -t force. As a last resort, kill the world from esxtop with the k key.
Step one: vim-cmd
Start with hostd, which understands the VM and its tasks:
vim-cmd vmsvc/getallvms
vim-cmd vmsvc/power.getstate 17
vim-cmd vmsvc/get.tasklist 17If get.tasklist shows a running task, inspect it with vim-cmd vimsvc/task_info <task> and cancel it with vim-cmd vimsvc/task_cancel <task> before going further; the full procedure is in Fix “Another task is already in progress” in vCenter. Then request a clean shutdown, and if the guest does not respond within a couple of minutes, a hard power off:
vim-cmd vmsvc/power.shutdown 17
vim-cmd vmsvc/power.off 17power.shutdown requires VMware Tools; power.off does not. The error “The operation is not allowed in the current state” usually means hostd believes the VM is already off or mid-transition; move to esxcli.
Step two: esxcli vm process kill
esxcli talks to the VMX process by World ID rather than through hostd’s object model:
esxcli vm process listEach entry shows the display name, World ID, Process ID, VMX cartel ID and the path to the .vmx file. Kill in escalating severity:
esxcli vm process kill --type=soft --world-id=2101234
esxcli vm process kill --type=hard --world-id=2101234
esxcli vm process kill --type=force --world-id=2101234Soft asks the VMX to shut down gracefully (similar to a power off but through the process); hard terminates it immediately; force kills it at the kernel level and is the one to use when the process itself is wedged. Wait about thirty seconds between attempts and re-run the list to see whether the world has gone. If hostd is unresponsive and esxcli hangs, localcli accepts the same syntax without going through hostd:
localcli vm process list
localcli vm process kill --type=force --world-id=2101234Errors such as “Syscall kill returned error (-1)” or “No such process” mean the world is already gone or is in an uninterruptible kernel state, typically waiting on storage.
Step three: esxtop
Run esxtop, press c for the CPU view, then f to change fields and enable the LWID (leader world ID) column with c. Locate the VM by name, press k, type its LWID, and confirm. This is the same as esxcli vm process kill -t force but bypasses even the esxcli front end. Killing the wrong world can crash the host, so double check the name before pressing Enter.
When nothing works
A VMX process stuck in an uninterruptible wait is almost always blocked on I/O to a datastore that has gone into APD or PDL. Check esxcli storage core device list and /var/log/vmkernel.log for the device; the VM cannot be killed until the storage either returns or is declared PDL. See Fix ESXi “Datastore not accessible”: APD and PDL. If the storage is gone for good, the host reboot is the final option, and the VM’s .vmx.lck file may need removing afterwards before it will power on elsewhere.
Verify
Confirm the VM is off from both perspectives:
vim-cmd vmsvc/power.getstate 17
esxcli vm process list | grep -A4 "VMNAME"power.getstate should return “Powered off” and the process list should no longer include the VM. In vCenter, if the VM shows as “Unknown” or “Invalid”, remove it from inventory and re-register from the datastore browser. Check the guest’s file systems after the next boot; a forced kill is equivalent to pulling the power cable.
Common pitfall
Killing the world without checking for a running snapshot consolidation or a backup proxy holding the disks open is the usual way to create a locked-file problem afterwards. Look at vim-cmd vmsvc/snapshot.get <VMID> and at whether a backup job is active before using force, and always try soft first.
Kill unresponsive VM ESXi at a glance
Official documentation: Broadcom TechDocs (VMware), Linux man pages.
Related guides: Fix “The redo log of .vmdk is corrupt” on ESXi and Horizon linked clones · Proxmox VE 9 vs ESXi 9 for hosting providers: licensing, storage, backup and migration realities · Fix Horizon “Agent Unreachable” and desktops stuck in Pending state.
Frequently asked questions
Does esxcli vm process kill work on a VM protected by vSphere HA?
Yes, but HA may treat the killed VM as a failure and restart it on another host within a minute or two, depending on the VM monitoring settings. Disable HA restart for that VM, or be prepared for it to reappear.
How long should I wait between the soft, hard and force kill types?
Around thirty seconds for soft to allow the VMX to flush, then proceed directly to hard and force if the process remains in the list. There is no benefit in waiting longer once the guest is unresponsive.
Can I undo a forced power off?
No. The VM stops as if power was removed. Power it back on normally; the guest file system will replay its journal, and applications with their own recovery (databases, mail stores) should be checked for consistency.