Wednesday, January 26, 2011

VMware ESXi 4.0 Update 2 slow boot up seemingly stuck at: vmw_psp_mru, multiextent, dvfilter, vmfs3, nfsclient modules / processes

For those who have come across my previous post yesterday:

VMware ESXi 4.1 slow boot up seemingly stuck at: vmw_vaaip_netapp, vmkibft, vmfs3 modules / processes

http://terenceluk.blogspot.com/2011/01/vmware-esxi-41-slow-boot-up-seemingly.html

… because the host I ran into the problem as mentioned in the post above didn’t have any VMs on it yet, I thought it would be a great opportunity to see if there was a difference between installing 4.1 and 4.0 Update 2 on it.  The reason I suspected it may be a bit different was because this slow boot up process appears to affect different hardware differently.  Case in point, the following hardware and ESXi version can have the slow boot time corrected with the KB: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016106 modifying the Scsi.CRTimeoutDuringBoot parameter:

Combination #1

NetApp Model: FAS2020

Data ONTAP: Release 7.2.6.1

Server: HP ProLiant DL360 G6 w/Brocade-425/825 FC HBA

ESXi 4.1 Version: Build 4.1.0, 260247

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

However, if we had the following combination on the hardware and ESXi version, the KB doesn’t help:

Combination #2

NetApp Model: FAS2020

Data ONTAP: Release 7.2.6.1

Server: HP ProLiant DL380 G5 w/LPe11000 FC HBA

ESXi 4.1 Version: Build 4.1.0, 260247

image

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

What’s interesting is that I took Combination #2 today, installed ESXi 4.0 Update 2 and then found that the KB mentioned above improved the boot up process (down to 4 to 5 minutes) when I modified the ESXi 4.0 specific Scsi.UWConflictRetries value from the default 1000 to 80.  For documentation purposes, I’m going to include the screenshots of the processes where the boot up would seemingly get stuck on prior to modifying the parameter:

multiextent

image

dvfilter

image

vmfs3

image

nfsclient

image

Definitely a bit different than the screens shown when ESXi 4.1 was installed.  So note that if you experience similar symptoms, try modifying the Scsi.UWConflictRetries value from the default 1000 to 80 as it helped the boot up process significantly.

1 comment:

Danny Aston said...

Hi,

I had the same issue - I thought the machine was hanging to re-installed twice before just leaving it!

Thanks,
Danny