Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having an issue with a client of ours.

We've set up Round-robin multipathing to their san from their ESX cluster, we have it configured so that two NICs on each host are added to a port group, one NIC is connected to one switch, then the other to another switch. Each switch is then patched to one of the two Gigabit interfaces on the Equallogic. I've then configured dynamic discovery properly and enabled round-robin on each datastore for each host.

Our client has a stand-alone esxi server as part of their environment and, with this configuration, it works fine. It's only the cluster that now seems to be having an issue. When we originally reconfigured it to work earlier in the day I tested it by pulling a switch and it worked for the cluster + the standalone esxi host. I then went on to put a basic configuration on the switches; 1 port untagged on vlan 1 for management and the rest untagged on vlan 500 for data. I then put the first reconfigured switch in, then after a short while pulled the second switch, saw it fail over and then did the same. After reconfiguring it I put the second switch back in to the environment and it was working fine.

I then realised I'd run the power to the switches through the side of the cabinet and had to reroute them, so pulled the power on switch 2, ok, plugged it back in, ok, pulled the power on switch one, ok, plugged it back in... then all access to the datastores was lost. I had a look in at the datastores in vsphere and noticed all LUNs were disconnected, even after a refresh nothing would come up. So I pulled the power on switch one and access was restored.

The weird thing is this behaviour is only observed on the ESX cluster, the ESXi standalone host works fine and has, as far as I can tell, an identical configuration.

I'll admit I'm no storage genius, would anybody care to shed some light on where I'm going wrong?

share|improve this question
The switch type, firmware rev and interconnectivity (stacked or not) between the switches (if any) are important additional bits of info. I've seen very similar behaviour with Dell PC6224's running old firmware for example. Your description of how you;ve configured the iSCSI ports on ESX isn't completely clear. The recommended pattern is to have two vmKernel ports, each with one (and only one) physical nic bound to it and then you have to bind these to the iSCSI stack, have you set it up that way? – Helvick Oct 5 '11 at 10:06
Thanks for that, that's definitely got us pointed in the right direction. I've configured as per your suggestions, following… and now I have multiple paths showing up under the "Manage Paths" button, however on all old datastores both paths are the same IP, on all subsequent datastores we create the IPs are different. Do you have any idea why? P.S. post as an answer and I'll award you the answer points. – Alex Berry Oct 12 '11 at 14:19
Also, when viewing the individual LUNS on the SAN, it shows connections from both interfaces, however the older LUNS are connected to both interfaces but to the same SAN IP. We were a bit stuck earlier and the only difference we could see between our layout and Dell's reference layout was a link between our iscsi switches, which we implemented and and which finally got multipathing working, however it seems that bit connections are going out of the secondary switch on older LUNS because of it. – Alex Berry Oct 12 '11 at 14:23
Use the Equallogic MEM plug-in and it's accompanying scripts to build the vswitch and port groups for iSCSI. – SpacemanSpiff Oct 13 '11 at 14:43
Unfortunately our client doesn't meet the licensing requirements for the MEM plug-in. – Alex Berry Oct 14 '11 at 12:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.