Hi,
I have started at a site where all of the controller ports are on the same subnet. Controller 1 has xxx.xxx.xxx.101 and 102 and controller 2 has xxx.xxx.xxx.103 and 104
In ESX one vSwitch has been configured with all of the targets (101 to 104) dynamically discovered in the ISCSI initiator.
Is it worth setting up another vSwitch configured with all of the targets for redundancy ? (the physical setup is as above with links from each controller to the two switches)

thanks,

John

Hi John,

Another vSwitch can provide you more redundancy & isolation for security and performance. Just take care as you integrate since you have an existing infrastructure. You may need to fine tune your implementation to meet your end goals.

There is a pretty good response from TexiWill at VMTN- http://communities.vmware.com/message/916558#916558.

Hi,
I have created a second vSwitch with the label ISCSI2, I have give this an IP addess of xxx.xxx.xxx.20. The other vSwitch as an address of xxx.xxx.xxx.10
On the MD3000i under "View/End ISCSI Sessions" I can only see sessions with the initiator address of xxx.xxx.xxx.10 - should I be able to see initiator addresses with xxx.xxx.xxx.20 as well ?

in the VI Client under storage adapters for each LUN I see two paths, one active and one standby ... is this correct, should I be seeing more paths ? as in the example above it has 4 paths per LUN.

It also shows 2 dead links to LUN 31 ?

thanks,

John

Hi,
I have resolved the paths issue, I hadn't attached the already existing VMK1 to the vmkernal ISCSI initiator.

I still have the issue where I only see sessions on the MD3000i with the initiator address of xxx.xxx.xxx.10 which is assigned to VMK1 (vSwitch1) on the VMware host.
I don't see any sessions for xxx.xxx.xxx.20 which is VMK2 (vSwitch2)

I also still have the issue with dead links to LUN 31 any idea how I can remove these ?

Can anyone asist with this ?

thanks,

John

John,

You did not mention which version of ESX you are using, however if it is ESX 3.5 then yes that is correct, ESX 3.5 supports fail over only and you would see an active path and a standby path, the failover policy should be most recently used (MRU)

If you are using ESX 4.0 then you can configure the paths to use Round Robin as the failover policy.

(Oh wait maybe you did, I just saw the keyword of ESX 4.0) So yes, go to Manage Paths and change each and every path to Round Robin.
Hope this helps.

Hi Aaron,
I'm still confused ... should or should I not see sessions on the MD3000i (using the MDSM) with the initiator address of xxx.xxx.xxx.20 (from vSwitch2 on the ESXi 4 host) ?

Or do they just show up when Round Robin is implemented ? I currently have an Active (I/O), Active, and two Standby paths for each of the two LUN's

Thanks,

John

John,

Well yes you should see the log in from the .20 NIC. Make sure you bound that NIC to the iSCSi initiator per the config document.

Hi Aaron,
Both NIC's are bound to the iSCSI initiator as there are 4 paths per LUN that show up in VMware, and the "esxcli swiscsi nic list -d vmhbaxx" shows both VMK1 and VMK2 which are both of the NIC's.

Thanks,

John

Did you do a rescan of the iSCSI initiator? (VMHBA32 or above)
Check to see how the switches are configured, you may not have a path from .20 to the array set up correctly.

Also, you have to change the failover policy to Round Robin or you will only get the Active (I/O), Active, Standby. With Round Robin you will have two Active (I/O) paths.