ESXi 5.0 Build 504890 iSCSI VMKernel ports not working after reboot

[RichardStafford]

Hi Guys

I have just patched my ESXI 5.0 server to 504890 as I was experiencing the iSCSI software initiator boot lag. I have four iSCSI interfaces connected on seperate VLANs. Now that I have patched the server, none of my vmk interfaces used for iSCSI are working. I can't ping the iSCSI target at all from the console.

If I remove the VMKernel interface and then recreate it exactly as was then everything works again: I can ping my target and connect to the LUN. If I reboot the server then I get the same thing - I have to remove and recreate my iSCSI interfaces for things to start working again.

Is anyone else experiencing this? I think I may have to roll back to 4.1

[allupinyourdc]

We ran into the exact same problem with a customer of mine.  We spent quite a bit of time troubleshooting it as it was a new install rather than an upgrade.  ESXi 5.0 Build 509890 is the same version they are on.

They had 2 initiators on 2 seperate subnets with 2 distinct paths to their SAN.  After a reboot we lost connection to the iSCSI san completely, the vmkernel ports wouldn't even ping.  Wierd thing is when we re-created even one of the two initiators, then both would start working...  Strange.

We also tested removing one of the initiators and only having a single initiator and it would work fine and sustain through a reboot, so it seems to have to do with the dual vmkernels in a multipath setup. 

It does not seem to affect 469512 version, as I tested it in my lab and it seems to work fine.

[Obel1sk]

I am having this problem with 504890 as well

[BriFar]

Hi,

I do not know if you managed to solve this or not.

I am writing just in case you didn't or for others that have the same issue in the future.

We have solved the issue by re-creating the iSCSI network on each host by creating a separate vswitch for each vmkernel port as show in this post

http://communities.vmware.com/message/1842596#1842596

Our setup is 2xDELL Poweredge R710 and an MD3200i with 2xMD1220 shelves.

Make sure you patch the ESX hosts to avoid the long delay on startup.

[Obel1sk]

Yes, this solution worked in one of our environments as well.  Most configurations I have used included multipath storage in the same vswitch for fabric failover, this makes it not possible for me now I would hope that this configuration would be supported soon.  (maybe it doesn't matter, on cisco ucs now and fabric failover is achieved outside of the host)

shawn