multipath problem: active provider chosen on passive FC path?

[Patrick Proniewski]

On 08 déc. 2014, at 21:03, Tom Samplonius wrote:

>> 
>> I've installed FreeBSD 9.3 on two HP blade servers (G6), into an HP C7000 chassis. This chassis uses two Brocade FC switches (active/passive if I'm not mistaken). The blade servers use 
> 
> 
>> Unfortunately during boot, and during normal operation, the first provider (da2 here) seems faulty:
>> 
>> isp0: Chan 0 Abort Cmd for N-Port 0x0008 @ Port 0x090a00
>> (da2:isp0:0:2:0): Command Aborted
>> (da2:isp0:0:2:0): READ(6). CDB: 08 00 03 28 02 00 
>> (da2:isp0:0:2:0): CAM status: CCB request aborted by the host
>> (da2:isp0:0:2:0): Retrying command
> 
> 
>  FC switches are typically active-active, as the FC switch fabric is "intelligent" and doesn't have looping issues like ethernet.
> 
>  Your issue is probably on the storage array.  Storage arrays typically have an OS profile, and various advanced settings for how a LUN is exported to a client.  Storage arrays typically support SCSI Reservations, where the LUN must be reserved before it can be used.  Also, storage arrays typically have multiple controller cards, and typically an LUN is owned by one of the controllers at a time. The storage array can signal to the client via SCSI that it wants to move the the ownership to another controller.  With proper client support, migrating a LUN to another controller is typically hit-less. 
> 
>  In your case, the storage array is probably configured to use one controller/path at a time.  And it is probably expecting to see specific SCSI messages between itself and the host.  These type of settings are typically set by the OS profile.
> 
>  Generally, storage arrays work best if you only send IO to one controller at a time.  And this involves co-ordination between the array and the client using SCSI control messages.  Though active-active paths can usually be supported as well.


Thank you for your reply. The SAN is an EMC VNX 5300. By default it presents LUNs using ALUA as failover mechanism. I though GEOM could not handle ALUA properly, so I changed the failover setting for this LUN, now the FreeBSD hang during boot. If I boot in single user mode, it boots completely but the result is the same default active path is not functioning correctly.

Tomorrow, I'll try another failover setting (dubbed "legacy"). The SAN also allows me to specify initiator type (default to Clariion), I'll dig into this setting to see if something exists that is more adapted to FreeBSD host.

Any other idea is welcome...

Patrick