iSCSI Failover Paths - Not seeing what I expected

[DavidB403]

Setup:

x2 Dell R410 ESXi 4 - x4 GbE Ports - all vSwitches have MTU 9000

x2 Dell PowerConnect 2816 - Jumbo Frames enabled

x1 MD3000i - All iSCSI ports have 9000 MTU - Out-of-band management

From what I have read, I should expect to see four paths for each LUN. Two active, two standby. This is exactly what I see on fecalesx01. But only two paths for each LUN on fecalesx02, one active and one standby. Can anyone tell me what might be our of place? I've scratched my head raw. Please use the screen captures for reference.

Once again: Can anyone tell me why I am not seeing four paths for each LUN on fecalesx02?

Thank you.

[OrionSoG]

It looks like your ESX servers are only seeing one Storage Target, that would explain why you show 1 Target and 2 Paths.

Some suggestions:

1. Be sure to follow the "Port Binding" recommendations in the VMware iSCSI Configuration Guide for vSphere. I see you've decided to create a seperate vSwitch for each iSCSI NIC on your ESX servers. I believe the "port binding" rule still applies in this configuration due to VMKernel communication.

2. To verify, you are using a 16-bit subnet mask for your IP scheme, correct?

3. I've been told by engineering that best practices are to create a physical uplink between the two iSCSI ethernet switches. This allows each Initiator to physically see all host Targets. You can specify the preferred path as one that only traverses one switch, however, you will want a switch-to-switch uplink in order to decrease path failover times. I've seen improvement of up to 30 seconds after creating the physical connection between iSCSI switches.

4. I'm not familiar with your SAN/Storage solution, but you will want to verify path failover settings (round robin, preferred path, etc) and verify the other suggestions I've made before testing.

Good luck and have fun!

Matthew

[athlon_crazy]

I think something to do with your target cant been seen by fecalesx02 :

fecalesx01 able to see 4 target as below :

• vmhba32:C0

• vmhba32:C1

• vmhba32:C2

• vmhba32:C3

Somehow, fecalesx02 only can see this two:

• vmhba32:C0

• vmhba32:C3

On fecalesx02, try disconnect one vmkernel and rescan your iscsi target. See which vmkernel cant connect to iscsi target

vcbMC-1.0.6 Beta

vcbMC-1.0.7 Lite

[Andy_Banta]

David,

Have you done the same NIC setup on each host? Can you provice the output of "esxcli swiscsi nic list --adapter vmhba34" on each of the two systems?

Thanks,

Andy

[DavidB403]

Hi all,

Thank you for the suggestions. I'll be working on this later today and I'll post my findings.

[DavidB403]

3+ Months later.. I thought I'd come back and update you all.

I ended up recreating all vmkernel ports, dedicated iSCSI vSwitches and targets. I honestly have no idea what I may have missed on the first go around, but I'm happy to report I that full multi-pathing on all hosts.

[jammann]

Just for the record, might be helpful to someone. I had a very similar situation: 3 ESXi hosts, 2 switches, 2 MD3000i. 2 of the ESXi hosts were correctly seeing all iSCSI LUNs on 4 different paths. The third one was only seeing 2 paths to each LUNs. Sidenote: This only occurred after upgrading to build 244038, before was on ESXi 4.0.0 19xxxx (don't remembeer exactly) and had 4 paths to each LUN.

Turns out that for some reason one of the iSCSI vmk NIC devices changed its ID from vmk4 to vmk0 (we had some vSwitch reorgs a long time ago, thus vmk0 was unused). For some reason, some parts of the iSCSI infrastructure of ESXi did not catch up with this renumbering.

esxcli swiscsi nic list -d vmhba33

Was still showing the (not anymore existing) vmk4 as a NIC, without a valid configuration.

esxcli swiscsi nic remove --adapter vmhba33 --nic vmk4
esxcli swiscsi nic add --adapter vmhba33 --nic vmk0

followed by a rescan: And poof, there are your paths!

Not that I actually fully understand what I did, but it seems to help