Are these other network interfaces available for failover, or for other networks all together? Is there a way to get the ESX system to log when it chooses to go over another network path?
-Blake
On 3/14/07, Vaughn Stewart mvstew@gmail.com wrote:
For clarification the Filer has three interfaces? one stand alone and the other three trunked (VIF'd) for redundancy/aggregated throughput?
Justin Brodley wrote:
Unfortunately I have to connect to ISCSI on both interfaces, (1 port to 1 network ,3 ports aggregated to the other). The problem only occurs with ESX, because ESX is trying to connect to both networks even though its only physically attached to one.
From: Vaughn Stewart [mailto:mvstew@gmail.com] Sent: Wednesday, March 14, 2007 2:29 PM To: Justin Brodley Cc: toasters@mathworks.com Subject: Re: ISCSI Issue and VMWare ESX 3.0.1
BY default NetApp enables iSCSI on all Ethernet interfaces. You should disable the interfaces which you do not want to connect via iSCSI on.
Vaughn
Justin Brodley wrote:
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