vCenter serialises operations on a virtual machine. When a task is still running, or the host believes it is, every new power, snapshot or reconfigure action against that VM fails with “Another task is already in progress”. The frustrating version is when the Recent Tasks pane shows nothing running at all, because the task lives on the ESXi host, not in vCenter’s view. The procedure below works on ESXi 7.0, 8.0 U3 and 9.x hosts managed by vCenter 8 or 9.
Table of Contents
Short answer: SSH to the host running the VM, run vim-cmd vmsvc/getallvms to get the VM ID, then vim-cmd vmsvc/get.tasklist <VMID> to list active tasks and vim-cmd vimsvc/task_info <task> to see the real progress. If the task is genuinely progressing (a long snapshot consolidation, for example) let it finish; if it is stuck at the same percentage, cancel it with vim-cmd vimsvc/task_cancel <task>. When the task list is empty but the error persists, restart the management agents with /etc/init.d/hostd restart and /etc/init.d/vpxa restart, which does not affect running VMs.
Why the task is invisible in vCenter
vCenter’s task list reflects what vpxa on the host has reported. If a host rebooted mid-task, vpxa was restarted, or the task was started directly on the host through the Host Client or a backup appliance’s API session, vCenter may have lost track of it while hostd still holds the lock. Typical triggers are long snapshot removals after a backup, a Storage vMotion that stalled, or a host that was rebooted while a task was queued.
Find the VM and its tasks on the host
Enable SSH on the host (Configure » Services » SSH » Start, or through the DCUI) and connect as root:
vim-cmd vmsvc/getallvms | grep -i "vmname"
vim-cmd vmsvc/get.tasklist 42The first command lists every registered VM with its numeric ID; the second shows tasks for VM ID 42 as managed object references such as haTask-42-vim.VirtualMachine.removeAllSnapshots-123456789. Inspect one:
vim-cmd vimsvc/task_info haTask-42-vim.VirtualMachine.removeAllSnapshots-123456789The output includes state (running, queued, success, error), progress as a percentage, startTime, and the operation name. Run it again a minute later. A rising percentage means the task is alive; consolidation of a large delta chain can legitimately take hours, and cancelling it can leave the chain worse than it started.
Cancel a stuck task
If the progress has not changed across several minutes and the operation is safe to cancel (power operations, reconfiguration, a vMotion that never started), cancel it:
vim-cmd vimsvc/task_cancel haTask-42-vim.VirtualMachine.removeAllSnapshots-123456789Not every task is cancellable; the response tells you if the operation refuses. Snapshot consolidation is the notable case that will not cancel cleanly. For a consolidation that appears hung, check the datastore for growing delta files with ls -lh /vmfs/volumes/<datastore>/<vm>/ over a few minutes; if the deltas are still changing, the task is working. If the files are static and the vmware.log shows repeated lock errors, see Consolidate snapshots when ESXi reports “Virtual machine disks consolidation is needed”.
Restart the management agents
When get.tasklist returns nothing but the VM still refuses operations, hostd is holding stale state. Restarting the agents is safe for running workloads: virtual machines keep running, but the host drops out of vCenter for a minute and any in-flight vMotion to or from that host will fail.
/etc/init.d/hostd restart
/etc/init.d/vpxa restartWait for the host to reconnect in vCenter (Hosts and Clusters » host » Connection state), then retry the operation. If hostd itself will not restart, services.sh restart restarts every management service, which takes longer and also restarts SSH; keep a DCUI console session available.
Verify
Retry the original task from vCenter. It should be accepted and appear in Recent Tasks. On the host, vim-cmd vmsvc/get.tasklist <VMID> should show only the new task, and vim-cmd vmsvc/power.getstate <VMID> should return the expected power state. Check /var/log/hostd.log for the task completion line if you want written confirmation.
Common pitfall
Restarting hostd while a snapshot consolidation is actually running is the most damaging move here. The consolidation is performed by the VMX process, so it survives the restart, but the lock state is lost and a second consolidation launched afterwards can fail with “unable to access file since it is locked”. Always read task_info progress twice, a few minutes apart, before deciding a task is stuck.
VCenter another task is already in progress at a glance
Official documentation: Broadcom TechDocs (VMware), Linux man pages.
Related guides: Fix ESXi “Datastore not accessible”: All Paths Down (APD) and Permanent Device Loss (PDL) · Kill an unresponsive VM on ESXi with vim-cmd, esxcli and esxtop · Fix “The redo log of .vmdk is corrupt” on ESXi and Horizon linked clones.
Frequently asked questions
Does this apply to the Host Client on a standalone ESXi host without vCenter?
Yes. The Host Client shows the same error and the vim-cmd commands are identical because the task lock lives in hostd on the host. The only difference is that there is no vpxa to restart.
How long should I wait before cancelling a task that shows no progress?
For power and reconfigure operations, five minutes with no change is enough. For snapshot removal and Storage vMotion, watch the datastore files for at least fifteen minutes; large virtual disks on busy storage can sit at a fixed percentage for long stretches while still working.
Can I undo a task cancellation?
No; a cancelled operation simply stops. Power operations and reconfigurations can be reissued, and a cancelled Storage vMotion leaves the VM on its original datastore. A cancelled snapshot removal leaves the chain intact and can be retried.