I've experienced the same exact issue. I opened a case and at the end of the analisys this was the answer of support. I can also say that there are no network issues, or multipath ones and so on.
The bad thing is that SANTricity report this as a "Critical Alert Message" causing worries in the customer!!! It should be better that the level of criticism is lowered.
Here follow answer from support.
===================================================================================
From my analysis, you are not experiencing an anomaly. This behavior is normal operation of the storage array.
From the Santricity Storage Manager Concepts for version 11.10:
https://library.netapp.com/ecm/ecm_download_file/ECMP1394573
“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.
I hope this answers your questions.
