Hi Justin Do you have a network connection for the ESX service console on the back end network (where you want the traffic to go)?
Although it's not supposed to work at all if the service console doesn't have access to the back end network, I've seen it sorta work with weirdness similar to what you're seeing.
Second, and probably more useful, newer versions of ONTAP introduce the concept of portsets. Not sure exactly where this came in, but it's not in 7.0.5 and it is in 7.1.1 . You create a portset, then in the igroup settings, you can assign a portset, and that igroup will only see LUNs through the designated ports of the portset. You can bind to a portset when you create the igroup, or you can bind to it later with the "igroup bind" command. Portsets are created and managed with the "portset" command.
bandit> igroup bind usage: igroup bind <initiator_group> <portset> - binds the igroup to the portset
The initiator group must not be currently bound to any portset If the initiator group is bound, use the 'igroup unbind' command to first unbind the initiator group before attempting to bind to another portset.
For more information, try 'man na_igroup'
bandit> portset The following commands are available; for more information type "portset help <command>" add destroy remove show create help
bandit> portset create portset create: -f or -i must be specified usage: portset create { -f | -i } <portset> [ <filer:port1 filer:port2 ...> ] portset create { -f | -i } <portset> [ <port1 port2 ...> ] - creates a new portset
A portset is a collection of ports. The type is specified with the -f (FCP) or the -i (iSCSI) options (Note only FCP is currently supported). Ports can optionally be supplied, and will be added to the group.
FCP ports are specified by the name of the filer and the port slot letter name separated by a ':' (example filer:4a).
This command also allows the ports to simply be specified by the port slot letter name. Ports specified in this style will add that port from both the local and partner filers at the same time.
A non-empty portset will not be created in a cluster setup if the interconnect between the two filers is down
For more information, try 'man na_portset'
Definitely check out the docs and try it with some non production servers before trying it live!
Let us know how it goes!
Peter
________________________________
From: Justin Brodley [mailto:jbrodley@sumtotalsystems.com] Sent: Wednesday, March 14, 2007 2:03 PM To: toasters@mathworks.com Subject: ISCSI Issue and VMWare ESX 3.0.1
I'm currently dealing with a problem on several of our ESX IBM LS21 Blades when trying to attach to ISCSI Luns on the Netapp FAS 3020's. Our Netapp currently connects to two separate physical networks to deliver ISCSI connectivity. The ESX support folks are telling us that the netapp presents both ISCSI interfaces to the server. Initially the ESX box connects on the correct interface, but then after a few hours it attempts to try the other IP address and fails and disconnects the entire VM Host from the Netapp, despite the fact that the network never went down. We have several Windows 2003 servers with ISCSI initiator that don't have this problem on identical hardware and chassis.
I assume that either ESX's iscsi initiator is badly designed, or MS has broken some industry standard spec. To rearchitect our storage network will take significant investment on our part, and we'd rather come up with a way to fix this either by pushing on ESX to fix the initiator or finding a way to have the Netapp only send one IP address back to the initiator. Is there any way to resolve this from the Netapp perspective?
Thanks in advance.
-Justin