Determining Why a Virtual Machine was Unexpectedly Powered Off, Restarted, or Rebooted

Products

VMware vCenter Server VMware vSphere ESXi VMware Cloud Foundation VMware Telco Cloud Platform

Issue/Introduction

Clients connected to a virtual machine (VM) lose access, and dependent applications or services report connectivity errors.

The virtual machine no longer responds to network requests or user interaction via the console client, indicating it has been turned off, rebooted, or hard reset unexpectedly.

Reviewing the environment logs reveals key signature symptoms:

The vmware.log for the guest VM records: PIIX4: PM Soft Off. Good-bye
The Windows Event Viewer for a Windows guest OS records a user-sent shutdown state.
The ESXi host management agent log (hostd.log) logs a state transition: Info hostd : State Transition (VM_STATE_ON -> VM_STATE_SHUTTING_DOWN)

Environment

vCenter Server: 7.x, 8.x
VMware ESXi: 7.x, 8.x
VMware Cloud Foundation (VCF): 5.x
Telco Cloud Platform (TCP): 5.x

Cause

A virtual machine state change (power off, restart, or soft shutdown) can be triggered by guest operating system halts, administrative actions executed via user accounts or API calls, automated High Availability (HA) cluster monitoring tasks, or underlying system faults such as a kernel panic or Blue Screen of Death (BSOD).

Resolution

1. Locate the Virtual Machine Log Directory

Log in to the vSphere Client with administrative credentials.
Select the affected virtual machine in the inventory hierarchy.
Click the Summary tab, then select Edit Settings.
Navigate to the VM Options tab and expand General.
Identify and record the directory path listed under Virtual Machine Working Location.

2. Retrieve and Open the Relevant Log File

Open a web browser and navigate to https://<vCenter_FQDN_or_IP>.
Click Browse datastores in the vSphere inventory and locate the datastore and folder noted in the working location step.
Open the target vmware.log file using a text editor.

Note: A new vmware-#.log file is automatically rolled and created during a hard reset, initial power-on sequence, or a vMotion migration. Match the timestamp under the "Last Modified" column to the approximate time of the outage.

Locate the second line of the vmware.log file to identify the precise ESXi host name that was running the workload when the outage occurred:

[YYYY-MM-DDTHH:MM:SS] vmx| Hostname=esx02.example.com

3. Analyze State Change Signatures in vmware.log

Scenario A: Guest OS-Initiated Soft Shutdown or Reset

If the guest operating system explicitly initiated a shutdown sequence or soft reset, look for the following entries:

Next Step: Contact the guest operating system vendor to isolate why the OS kernel triggered a halt. For Windows environments, review the in-guest System Event Logs specifically for Event IDs 41, 1074, or 1076 to capture the recorded reason string.

Scenario B: User or vSphere API-Initiated Operations

If an administrator or an automation script executed an API directive against the virtual machine object, one of the following exact signatures will populate:

Hard Reset: [YYYY-MM-DDTHH:MM:SS] vcpu-0| CPU reset: hard
Power Off:[YYYY-MM-DDTHH:MM:SS] vmx| MKS local poweroff
Guest Shutdown Command: ```text [YYYY-MM-DDTHH:MM:SS] vmx| I120: Tools: sending 'OS_Halt' (state = 1) state change request [YYYY-MM-DDTHH:MM:SS] vcpu-0| I120: PIIX4: PM Soft Off. Good-bye.

* **Guest Reboot Command:**
```text
[YYYY-MM-DDTHH:MM:SS] vmx| I120: Tools: sending 'OS_Reboot' (state = 2) state change request
[YYYY-MM-DDTHH:MM:SS] vcpu-0| I120: CPU reset: soft (mode 1)

Scenario C: Virtual Machine Executable Backtrace Crash

If the virtual machine process (vmx) encountered a severe failure and crashed, it will capture an unexpected signal and throw a stack dump:

[YYYY-MM-DDTHH:MM:SS]: vmx| Caught signal 6 -- tid 101087
[YYYY-MM-DDTHH:MM:SS]: vmx| SIGNAL: eip 0x1019e731 esp 0xbf5ffa9c ebp 0xbf5ffac8
[YYYY-MM-DDTHH:MM:SS]: vmx| Backtrace:
[YYYY-MM-DDTHH:MM:SS]: vmx| Backtrace[0] 0xbf5ff858 eip 0x805ae40
[YYYY-MM-DDTHH:MM:SS]: vmx| Unexpected signal: 6.

Scenario D: Guest OS Blue Screen (BSOD) or Critical Bugcheck

If the operating system inside the VM encountered a critical system fault, the frame buffer manager captures the crash dump text directly into the log:

svga| I120: WinBSOD: ( 1) `A problem has been detected and Windows has been shut down to prevent damage '
svga| I120: WinBSOD: (15) `*** STOP: 0x00000024 (0x00000000001904FB,0xFFFFF880069B2CE8,0xFFFFF880069B2540,0'

Next Step: Collect the crash artifacts or utilize the vmss2core tool to convert a suspended state file into a core memory dump for operating system vendor analysis.

Scenario E: vSphere HA Cluster VM Component Monitoring Reset

If the vSphere High Availability (HA) VM Monitoring agent loses heartbeats or disk I/O feedback from VMware Tools, it resets the unstable instance:

vmx| Vix: [104333 vmxCommands.c:457]: VMAutomation_Reset. Trying hard reset