How to Check Why a VMware VM Was Powered Off or Rebooted

When a virtual machine is found powered off or rebooted, the first question is usually simple: did someone shut it down, did the guest OS crash, or did ESXi/vCenter do something to it?

I usually do not start by blaming HA or storage. Start with the timeline. Once the time window is clear, the rest of the investigation becomes much easier.

1. Check vCenter tasks and events first

Open the VM in vCenter and check Tasks and Events. Look around the time when the VM went down. You are looking for entries such as:

  • Power Off virtual machine
  • Reset virtual machine
  • Restart Guest OS
  • Shutdown Guest OS
  • vSphere HA restarted virtual machine
  • VMware Tools initiated guest shutdown

If there is a user name attached to the task, you already have a strong lead. If there is no clear user task, continue with host and guest logs.

2. Check the VM folder and vmware.log

The VM’s vmware.log is often the most useful file. Find the datastore path of the VM and check the newest log files.

grep -i "power" vmware.log
grep -i "reset" vmware.log
grep -i "shutdown" vmware.log
grep -i "tools" vmware.log

Useful patterns include whether the power operation came from vpxa, hostd, VMware Tools, or a manual action.

3. Check ESXi host logs

On the ESXi host where the VM was running:

grep -i "VM_NAME" /var/log/hostd.log
grep -i "VM_NAME" /var/log/vpxa.log
grep -i "VM_NAME" /var/log/vmkernel.log

hostd.log and vpxa.log are useful for management actions. vmkernel.log is more useful if you suspect host, storage, or device-level problems.

4. Check inside the guest OS

Do not skip the guest. A clean Windows shutdown usually leaves events in the System log. A Linux guest may have entries in journalctl or system logs.

For Windows, check:

  • Event ID 1074: planned shutdown or restart
  • Event ID 6005/6006: event log service start/stop
  • Event ID 6008: previous shutdown was unexpected
  • BugCheck events if there was a blue screen

For Linux:

journalctl --list-boots
journalctl -b -1
last -x | head

5. Check HA and host events

If the VM restarted on another host, check cluster HA events. HA restart is usually visible in vCenter events. If the VM did not restart, check whether HA admission control, datastore heartbeat, or isolation response was involved.

6. Common causes

  • A user powered off or reset the VM in vCenter.
  • Guest OS patching triggered a reboot.
  • VMware Tools initiated a guest shutdown.
  • vSphere HA restarted the VM after host failure.
  • The guest OS crashed.
  • Storage or host issues caused a VM stun or crash.

Final note

The most reliable answer usually comes from matching three places: vCenter events, vmware.log, and guest OS logs. One source alone can be misleading.

有VM问题需要协助?

免费试用VMware技术助理(已接Deepseek)!即时解答VM难题

→ 🤖VM技术助理

解析和诊断各类vCenter错误,ESXi日志,虚拟机vmware.log

→ 📕VMware日志分析器

图书推介 - 京东自营

24小时热门

还有更多VMware问题?

免费试下我们的VMware技术助理(已接Deepseek)!即时解答VM难题 → 🤖VM技术助理

试试 📕VMware日志分析器 免费诊断各类vCenter错误,ESXi日志,虚拟机vmware.log等等

########

扫码加入VM资源共享交流微信群(请备注加群

需要协助?或者只是想技术交流一下,直接联系我们!

推荐更多

//omg10.com/4/9119499