> > In such a scenario, wouldn't the priorizer catch priority changes ? > > No, not necessarily, and certainly not for CLARiiON. None of these > 3 use cases involves changing which path group is the highest priority > path group so each path in the 2 groups continue to have the same > priority as before the externally initiated change of the active path > group. For each use case, only the identity of the active path group > has been changed. > I guess the priorizer *should* catch priority changes ... > > > > ie, paths to owning SP are heavier than paths to not owning SP, so > > changing the owning SP in navisphere would shuffle the path group > > priorites. > > CLARiiON path priority is dependent solely on 2 factors -- (1) the > path must be active (or ghost) and (2) the path must connect to its > logical unit's "default" (not necessarily active) owning service > processor. > > > > > If it is the case I would imagine the failback target to be the > > externally designated one, which seems right. > > No. The CLARiiON's highest priority path group is defined to be > the default owning service processor instead of the active service > processor (they may or may not be the same at any given instant) > in order to maintain the manually established distribution of > logical units across the 2 service processors. > Would it be unreasonable to teach the prioritizer about this case ? Regards, cvaroqui -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
