Understanding the message: The CPU has been disabled by the guest operating system (2000542)
A VMware virtual machine stops running, reporting that the CPU has been disabled by the guest operating system.
- The user interface reports a message similar to:
- The CPU has been disabled by the guest operating system. Power off or reset the virtual machine.
- The CPU has been disabled by the guest operating system. You will need to power off or reset the virtual machine at this point.
- The virtual machine's log file reports a message similar to:
Vix: [nnnnnnn vmxCommands.c:nnnn]: VMAutomation_HandleCLIHLTEvent. Do nothing.
This message is seen when a guest operating system running in a VMware virtual machine intentionally halts the virtual CPU by executing the instructions CLI and HLT in succession. This can occur during a critical error or fault within the Guest OS.
The CLI (Clear Interrupts) instruction clears the interrupt flag, preventing further interrupts from being serviced until they are re-enabled. The HLT (Halt) instruction halts the CPU until the next interrupt is fired. This combination will prevent any future interrupts from being serviced, intentionally hanging the CPU. When executed on a VMware virtual machine's vCPU, this combination results in the vCPU stopping and a message reported in the logs and user interface.
Issuing the HLT instruction requires ring 0 access, and can only be run by privileged system software such as the Guest OS kernel. Issuing the CLI instruction requires ring 0,1,2 access, and is often restricted to only ring 0 during Guest OS kernel startup. This message usually indicates a critical fault within the Guest OS kernel, though more detailed analysis is required to determine the root cause.
Collect information from the current outage:
- Identify the virtual machine and time of the outage.
- Take a screenshot of the virtual machine's console, making note of any error messages.
- Suspend the virtual machine and copy the checkpoint suspend (
.vmss) and memory image (
.vmem) (if present) from the virtual machine directory. Set the files aside.
- Resume the virtual machine to the suspended state, then reset the virtual machine to start the GuestOS.
- Collect logs from the GuestOS kernel leading up to the outage. For more information, engage the guest operating system vendor.
- Collect logs from the host leading up to the outage. For more information, see Collecting diagnostic information for VMware products (1008524).
Analysis of information:
- Review any error messages or warnings emitted by the guest operating system's kernel leading up to the outage, either on the console or in its log files. For more information, contact the guest operating system vendor.
- Convert the checkpoint suspend files (
.vmem) from the virtual machine into a core dump file using the
vmss2coreutility. For more information, see the Debugging Virtual Machines with the Checkpoint to Core Tool technical note.
- Review the core dump file using an appropriate debugger to determine the cause of the fault. For more information, engage the guest operating system vendor.
- Review any error messages or warnings emitted by the VMware host or virtualization product leading up to the outage. To determine whether these contributed to the outage, search the knowledge base or open a support request.