Symptoms
You may experience these symptoms:
- A rescan takes longer than with previous versions of ESX.
- When accessing an iSCSI array through Software iSCSI in ESX 3.5, you see the following log spew:
cpu7:1076)iSCSI: bus 0 target 1 trying to establish session 0x352180a0 to portal 0, address <IP Address> port 3260 group 102
cpu1:1072)iSCSI: login phase for session 0x352180a0 (rx 1076, tx 1075) timed out at 5904793, timeout was set for 5904793
cpu7:1076)iSCSI: session 0x352180a0 connect timed out at 5904793
cpu7:1076)<5>iSCSI: session 0x352180a0 iSCSI: session 0x352180a0 retrying all the portals again, since the portal list got exhausted
cpu7:1076)iSCSI: session 0x352180a0 to iqn.1992-08.com.netapp:sn.101186750 waiting 60 seconds before next login attempt
cpu2:1078)iSCSI: bus 0 target 2 trying to establish session 0x3522c1b0 to portal 0, address <IP Address> port 3260 group 1000
cpu2:1078)iSCSI: session 0x3522c1b0 to iqn.1992-08.com.netapp:sn.101186750 failed to connect, rc -113, No route to host
cpu2:1078)iSCSI: session 0x3522c1b0 connect failed at 5907910
cpu2:1078)<5>iSCSI: session 0x3522c1b0 iSCSI: session 0x3522c1b0 retrying all the portals again, since the portal list got exhausted
cpu2:1078)iSCSI: session 0x3522c1b0 to iqn.1992-08.com.netapp:sn.101186750 waiting 60 seconds before next login attempt
cpu7:1076)iSCSI: bus 0 target 1 trying to establish session 0x352180a0 to portal 0, address <IP Address> port 3260 group 102
Purpose
In ESX 3.5, multiple portals are handled differently than in 3.0.x. In pre-ESX 3.5, the iSCSI driver logged into only one portal and only when that fails, would it log into other portals in a round robin fashion.
In ESX 3.5, all portals that are sent in the SendTarget response are logged into. This was done to enable some active/passive arrays that have this portal concept. With active/passive arrays, the ESX storage stack needs to recognize each of the portals as different paths to effectively do multi-path failovers and so the iSCSI driver cannot hide the portals from storage mid-layer.
Specifically with this change, you start to see multiple paths to the targets.
Resolution
Some arrays are designed to provide default access through iSCSI to any hosts configured to access any portal groups.
In ESX 3.5, this log spew is expected as per the following chain of events:
- ESX host's iSCSI initiator logs into the filer's target IP address.
- Using Dynamic discovery, the ESX host issues a SendTargets command to the filer.
- Filer responds with all available target portals which includes any network interface with iSCSI enabled (this is the default behavior).
- ESX host sees this list of portals and attempts to establish connection on each of them.
- ESX host attempts to log into a target portal to which it has no network route. This causes the errors to be generated in the VMkernel logs.
To address this ensure that VMKernel ports are created in order to communicate with all target portals, A VMkernel port will need to be configured on the same IP Range that each of the target port resides for example:
Storage Processor 0 Port 0: 192.168.2.1
Storage Processor 0 Port 1: 192.168.3.1
Storage Processor 1 Port 0: 192.168.2.2
Storage Processor 1 Port 1: 192.168.3.2
VMKernel Port 1: 192.168.2.50
This will allow the VMKernel Port to log into both Storage Processors on Port 0
VMKernel Port 2: 192.168.3.50
This will allow the VMKernel Port to log into both Storage Processors on Port 1
Based on VMware KB 1005321
