ESXCLI: Power Off a VM Stuck in an Unknown State (ESXi 7 & 8)

By /

Updated for 2026: originally tested on ESXi 5.5. The commands below are unchanged in ESXi 7 and 8 — esxcli vm process is still the tool of last resort when a VM won’t respond to the vSphere Client. Use it when a VM is stuck in an unknown state, ignoring normal power-off requests.

1. Open a console on the host

Enable SSH on the ESXi host (Host → Actions → Services → Enable Secure Shell) and connect, or use the DCUI/ESXi Shell directly. You need to be on the host the VM is running on — if the VM is registered elsewhere, you’re on the wrong box.

2. Find the VM’s World ID

[root@esxi1:~] esxcli vm process list
web01
   World ID: 358921
   Process ID: 0
   VMX Cartel ID: 358918
   UUID: 42 3f ...
   Display Name: web01
   Config File: /vmfs/volumes/datastore1/web01/web01.vmx

Note the World ID of the stuck VM. Confirm the display name matches — killing the wrong world is not recoverable.

3. Kill it — in escalating order

[root@esxi1:~] esxcli vm process kill --type=soft  --world-id=358921

The three types, weakest first. Always start with soft and give it a minute before escalating:

  • soft — a clean power-off, like pressing the power button politely through VMware Tools. Try this first.
  • hard — an immediate power cut, like yanking the plug. The VM stops now; the guest OS gets no say.
  • force — kills the VM’s world outright, equivalent to kill -9 on the VMX process. Last resort, when hard doesn’t take.
[root@esxi1:~] esxcli vm process kill --type=hard  --world-id=358921
[root@esxi1:~] esxcli vm process kill --type=force --world-id=358921

4. Verify

[root@esxi1:~] esxcli vm process list

The VM should no longer appear. If it still does after force, the VMX process itself is wedged — find it with ps | grep -i <vm-name> and kill that PID, or place the host in maintenance mode and reboot the host as the final answer.

Before you reach for this

  • Try the graceful paths first: power off from the vSphere Client, and vim-cmd vmsvc/power.getstate <vmid> / vim-cmd vmsvc/power.off <vmid> for a second opinion on the VM’s state.
  • A VM that repeatedly lands in an unknown state has a cause — hostd issues, a locked VMDK, storage latency. Check /var/log/hostd.log and vmkernel.log on the host before it happens twice.

Running your own server? These guides assume you have a Linux box somewhere — see our guide to choosing a VPS in 2026 for the 7 specs that actually matter before you spin one up.

Scroll to Top