A virtual machine encounters an abrupt restart while the ESXi hypervisor remains stable. Log analysis indicates the Guest Operating System (OS) initiated a hardware reset request. This behavior is a protective response to underlying physical hardware faults, specifically DIMM failures, or critical resource exhaustion within the virtual graphics driver.
vmware.log contains the following signature: YYYY-MM-DDTHH:MM:SS.Z In(05) vcpu-0 - Chipset: The guest has requested that the virtual machine be hard reset.YYYY-MM-DDTHH:MM:SS.Z In(05) vcpu-1 - Guest: vmwgfx, warning: mob memory overflow.VMware vSphere ESXi 7.x
VMware vSphere ESXi 8.x
If the guest operating system encounters a fatal internal error (eg: Machine Check Exception (MCE) or Kernel Panic) triggered by corrupted data originating from faulty/failing physical memory (DIMM), the guest OS sends a reset signal to the virtual chipset to maintain data integrity thus causing the VM to reboot.
Locate and Verify Logs: Find the datastore path and access the vmware.log for the affected VM by executing the following command on the ESXi host CLI: vim-cmd vmsvc/getallvms
Remediate Physical Hardware: Inspect the physical host hardware IPMI logs. Engage the hardware vendor to replace any faulty DIMM modules reported by ECC or SEL events.
Verify Guest OS Internal State: Examine internal Guest OS logs (e.g., Windows Event Viewer or Linux /var/log/messages) for fatal exceptions matching the timestamp of the reboot. For Linux environments, engage the OS vendor (e.g., Red Hat) to analyze kernel crash dumps (/var/crash/ or kdump) to identify the specific software trigger.
Adjust VM Resources: Increase the Video Memory and Guest RAM in the VM settings to mitigate vmwgfx resource pressure.
Contact Support: If hardware is verified healthy and reboots persist, Contact Broadcom Support.