Knowledge Base

The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides
 
Search the VMware Knowledge Base (KB)   View by Article ID
 

vSphere ESX/ESXi 4.x stops during start up at the step: multiextent loaded successfully (2003424)

Symptoms

  • During startup of a vSphere ESX/ESXi 4.x host, the loading screen halts or spends a long time displaying the message:

    multiextent loaded successfully.

Cause

A vSphere ESX/ESXi 4.x host that halts or spends a long time in the multiextent loaded successfully step during start up is experiencing a delay while loading or running storage claim rules. This encompasses storage device discovery and enumeration during start up.

When the storage claim rules complete, the next step of the startup displays the messages loading dvsdev and dvsdev loaded successfully.

Resolution

To identify the cause of the problem with loading or running storage claim rules during startup:

  1. At the physical console or remote KVM, press Alt + F12 on your keyboard. The console switches to displaying the VMkernel logs.

  2. Review the VMkernel logs on the console for any storage-related warnings or errors. During a storage issue, the console logs may scroll quickly with related information. If there are no storage-related warnings or error messages on the console, they may have scrolled off the screen already. Configure Serial Line Logging during startup to capture the logs. For more information, see Enabling serial-line logging for an ESX or ESXi host (1003900).

    Note: If the VMkernel stops logging entirely and becomes unresponsive during the startup process, see Using hardware NMI facilities to troubleshoot unresponsive hosts (1014767).

  3. Compare the VMkernel logs from the console or serial-line logging against a normal startup:

    cpuC:wwww)multiextent loaded successfully.
    sysboot: Starting path Claiming and SCSI Device Discovery
    sysboot: Executing 'esxcli corestorage claimrule load'
    sysboot: Executing 'esxcli corestorage claiming autoclaim --enabled=true'
    sysboot: Executing 'esxcli corestorage claimrule run --wait'

    cpuC:wwww)ScsiPath: nnnn: Plugin 'PluginName' claimed path 'PathName'
    cpuC:wwww)VMWARE SCSI id: Id for PathName 0x01 0x23 0x45 0x67 0x89 0x0a 0xbc 0xde

    cpuC:wwww)ScsiDevice: nnnn: Successfully registered device 'DeviceName' from plugin 'PluginName' of type T

    enumeration of all other storage devices

    sysboot: Path Claiming and SCSI Device Discovery Complete
    sysboot: Executing 'esxcfg-mpath -r'
    sysboot: Loading VMkernel Module 'dvsdev'


  4. Search the knowledge base for the storage-related warnings or error messages obtained via the serial line logging, and proceed with troubleshooting from any matching articles. See also Troubleshooting LUN connectivity issues (1003955).

    Note: If the cause of storage-related warnings or error messages cannot be ascertained during boot, consider disconnecting shared storage devices and booting the host. After a successful boot, attach the shared storage devices and perform a Rescan to discover the storage. Similar difficulty connecting to the storage devices may manifest, and can be investigated with more context.

  5. If no storage-related warnings or error messages are available from the VMkernel on the console or via serial-line logging, contact VMware Support for further assistance. For more information, see Filing a Support Request in My VMware (2006985).

Tags

change-unix-password

See Also

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

  • 13 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.
What can we do to improve this information? (4000 or fewer characters)
  • 13 Ratings
Actions
KB: