Configuring an ESX host to capture a Service Console coredump (1032962)
This article provides steps for configuring an ESX host to capture a Service Console kernel coredump during a purple diagnostic screen error. The default configuration of ESX captures a Service Console kernel coredump when needed, though it may be necessary to change the default configuration.
To configure an ESX host to capture VMkernel coredumps, see Configuring an ESX/ESXi host to capture a VMkernel coredump from a purple diagnostic screen (1000328).
During several specific types of critical purple diagnostic screen errors, a coredump from the Service Console kernel is captured in addition to the VMkernel coredump. For specific information on these errors, see:
- Understanding a "Lost Heartbeat" purple diagnostic screen (1009525)
- Understanding an "Oops" purple diagnostic screen (1006802)
This article is not applicable to ESXi, as there is no service console. For more information, see VMware ESX and ESXi 4.0 Comparison (1015000).
Two advanced configuration parameters,
Misc.CosCoreFile, control the behavior of ESX during a purple diagnostic screen error involving the service console.
These configuration options can be changed using the vSphere Client, PowerCLI, vCLI, or the local console. For more information on changing configuration options on the ESX host, see Configuring advanced options for ESX/ESXi (1038578).
- Default: 1
- Possible values: 0 or 1
The advanced configuration option Misc.PsodOnCosPanic controls if an ESX host stops with a purple diagnostic screen when the Service Console kernel encounters an Oops, Panic, or other critical unhandled kernel exception. This option should always be set to 1, otherwise information regarding the Service Console kernel error is not be captured.
- Possible values: string, absolute path on a VMFS datastore
The advanced configuration option Misc.CosCoreFile controls where the ESX host attempts to write a Service Console kernel coredump. This configuration option is set during installation of ESX, and contains an absolute path to a file on a Datastore. The long identifier is a VMFS-3 Datastore UUID, and by default points to the first local VMFS Datastore created during installation of ESX. If the default Datastore no longer exists, the option should be updated to reflect a location that can be written to.
This file does not exist by default. It is created (or overwritten, if it already exists) during a purple diagnostic screen error.
The space required for writing a coredump on this datastore is equal to the amount of memory configured for the service console, plus the size of the swap space configured for the service console. To determine the amount of memory allocated to the service console, see Increasing the amount of RAM assigned to the ESX Server service console (1003501). To determine the size of the swap space configured for the service console, review
- Configuring an ESX/ESXi host to capture a VMkernel coredump from a purple diagnostic screen
- Increasing the amount of RAM assigned to the ESX Server service console
- Interpreting an ESX host purple diagnostic screen
- Understanding an "Oops" purple diagnostic screen
- Understanding a "Lost Heartbeat" purple diagnostic screen
- VMware ESX and ESXi 4.1 Comparison