E-Series reports LUNs on a not preferred controller

this happens on different controllers installed in different sites on different models too (E-5500 with SAS and SATA hdd and on EF-550)

Sometime the "Need attention" warn appears on SANTricity Storage Manager and the warining is due to the fact that some LUN are declared served by the "B" controller that is not the default one.

The involved LUNs belong to the same disk pool but not all the LUNs of this disk pool are "trespassed".

Using the automatic configuration to put all the LUNs to the default "A" controller it works with no issues but after some time (hours and/or days) the array report that the same LUNs have been passed to the "B".

From the host point of view nothing changes, the mpio information still continue to report that the LUN is on the default optimized path.

“Most host multi-path drivers will attempt to access each volume on a path to its preferred controller. However, if this preferred path becomes

unavailable, the multi-path driver on the host will failover to an alternate path. This failover might cause the volume

ownership to change to the alternate controller.”

In the event viewer, I see Volume not on preferred path due to AVT/RDAC failoverI also see: IO shipping implicit volume transfer

These confirm my suspicion that I/O shipping is causing the condition.

According to my interpretation of the data, the above described behavior is what you are seeing. This leaves us wondering why the hosts are choosing to use the alternate path. Is there a networking issue? A Host issue? I can’t be certain based on the provided data. Certainly your MPIO is configured and working, but there are underlying problems somewhere causing this behavior.

Other entries in the event viewer give us a clue that there are likely underlying network issues:

Session terminated unexpectedly

Connection terminated unexpectedly

These are both iSCSI issues. Please check into the possibility of network issues.

Re: E-Series reports LUNs on a not preferred controller

No. No further answers.Read back here an old answer I've reported grin support. This seems by design.But, I repeat it, this should be fixed avoiding autosupport warnings that report it as a critical issue worrying customers!