The answer is in how you have your HBA's zoned, and the behavior you reported actually validates it was properly architected per best practice.  With the setting now reverted back to the preferred setting (which is also the default), the 4x "Active (I/O)" paths are the optimized paths which correspond to those that are direct paths (via the switch of course) to the current SP owner of the LUN. The other 4x Active (but without I/O) paths are the non-optimized paths or rather those that have a path to the current SP owner but via its peer SP and redirected as necessary through the CMI channel.  Since each HBA have paths to both SPA and SPB per best practice (again the reported behavior validates this), with Round-Robin configured and alternating I/O (1000 by default but never at the same time) down each optimized path, that is why you are seeing activity on each HBA.  If you were to then disable all paths to the current LUN owner, with ALUA configured, you should experience the following:  1) The current Active (I/O) paths should update with status "Disabled" or "Dead" depending on how you are testing or simulating path failures  2) The I/O should transfer to the other 4 Active paths  3) The LUN should not trespass which suggests that the I/O is being redirected by the upper-director via the CMI interface  4) After 128,000 I/O via the non-optimized paths, the system will make the decision to trespass the LUN (implicit trespass) instead of maintaining the non-optimal paths of an extra hop.
what would be the effect on the esx host and vms when tresspassing a lun on a cx4 when the multipath policy is set to round robin?  how would it differ from if the policy was set at mru or fixed?  thanks
lun tresspass and round robin