HP Storage Provisioning Manager (SPM) Version 2.0 User Guide

create/destroy zones dynamically depending on the needs of the users and the constraints set in
place by the storage administrator.
NOTE: Manual zoning changes done by a storage admin via BNA's GUI will take priority over
and cancel requests coming in via SPM and will result in SPM request failing.
NOTE: Networks that are manually renamed by a storage admin via BNA's GUI will need to
be removed from SPM and then re-imported and all services that were dependent on said networks
will need to be re-configured and re-activated.
SPM makes certain guarantees of usage of the underlying hardware as follows.
Zoning automation mandates
• SPM requires the storage admin to create the first zone in an Open network to zone the network
before we will create any zones as SPM will never zone an open network.
• SPM will never destroy/modify pre-existing zones as SPM doesn’t know the purpose of these
zones. This means that any zones that are in your network that were not created by SPM will
never be modified in any way by SPM.
• SPM requires there be at least one zone in place before we will zone and since SPM will not
destroy pre-existing zones SPM will never cause the network to go to an Open zoning state.
Zoning policy
SPM 2.0 will default to using the Single Initiator Zoning (SIZ) policy. This means that only candidates
capable of being connected via the SIZ policy or that are already connected will be offered up to
the user during candidate generation time. Using the SIZ policy SPM will create zones on network
capable of zoning automation such that there is a single initiator per zone and only one zone per
initiator. Target endpoints may however be in more than one zone as needed by initiators (for
example we expand the initiator’s zone to include the new targets as required). Targets that need
presented to an initiator are placed by SPM in that initiator’s zone such that the zone may contain
one or more targets and expand or shrink as needed.
NOTE: In a Federated CMS type environment with parallel instances of SPM acting on the same
network, it is required that the initiators being used in the separate SPMs to be distinct thus allowing
the SPMs via the SIZ policy to be acting on distinct zones in the same network.
Zoning naming convention
Zones created by SPM will be named with the following convention; all capitals starting with SPM_
followed by the WWN without colons of the initiator involved in the process (e.g.
SPM_1012EF3400123401). This allows SPM to easily identify which zones it created.
Zone modification
As discussed briefly in the Zoning Policy section pre-existing zones (zones that SPM did not create)
will be used by SPM if they meet the requirements of the desired Connectivity Service as is, but
they will in no way be modified if they don’t meet the desired requirements. Instead a new zone
will be created. Additionally if a pre-existing zone was used as is when the service is
deactivated/removed the pre-existing zone won’t be touched by SPM.
However SPM created zones that have the same initiator as the given requirements but need
modification to include additional targets will be modified as needed. They will also be removed
from the underlying device when SPM no longer needs them; this will occur as soon as all
Connectivity Services that depended on it are deactivated/removed.
Zone destruction
Zones will be destroyed when all Connectivity Services that depended on it are
deactivated/removed. This only applies to SPM created zones. Pre-existing zones will not be
affected. However in either case the zone will be removed from SPM’s storage catalog and thus
not be visible in the GUI anymore.
Connectivity services 59