Operating Environment Software Owner manual

Network names
There is one restriction on the editing that may be performed on an unmanaged network XML file.
The user may not simultaneously edit the names of more than one network in an unmanaged
network XML file (more than one network may exist in a file constructed using the file format for
SPM 2.0). If SPM detects that more than one network in an XML file has been renamed, it will mark
those networks offline.
Endpoints and zones
The XML files described in this document specify the endpoints and zones within one or more
unmanaged SANs. SPM does not allow two networks to contain the same endpoint. If a conflict
between two networks is detected, SPM does not allow the endpoint to be used in provisioning a
service. Thus, unmanaged SAN users should ensure that an XML file does not contain network
endpoints that are also present in another network, whether the other network is managed or
unmanaged.
Proxy WWNs
If a user wants to use proxy WWNs with a simple unmanaged network one can either add a
pattern to the unmanaged network that the proxy WWNs will match, or one can make a proxy
WWN that matches a pattern already in the unmanaged network. If a pattern is added to an
unmanaged network to match proxy WWNs, it may or may not include a wild card. For more
information, see “Fibre Channel Initiator Endpoint requirement” (page 26) or “Fibre Channel Target
Endpoint requirement” (page 26).
If an unmanaged network is in use that has been created by the SPM upgrade process (stored in
the file UpgradeUnmanagedNetworks.xml) or with a complex network (for example, in the
Matrix environment), then any required proxy WWNs must be manually added to the unmanaged
XML network. These may be added either as AddressPattern elements or as Endpoint elements.
For more information, see “Example unmanaged SAN XML files” (page 97).
Proxy WWNs must be added explicitly to an unmanaged network XML file if the proxy WWNs
do not match an existing pattern in the unmanaged network.
Allow external processing
Normally SPM will only generate service candidates for zoned unmanaged networks using zones
and initiators described in the XML file defining the network. However unmanaged networks have
a user-editable property called AllowExternalProcessing that, when checked, will allow SPM to
generate service candidates for an unmanaged network using zones and initiators that are not in
the XML file, if all other requirements are met and if the initiator has a valid FCProxyWWN that is
part of the unmanaged network or if the initiator's WWN matches a pattern contained in the
unmanaged network. This is similar to the Proxy Use Case described in Managed networks.
If a service is created using the Allow External Processing property, SPM immediately marks the
service as nonconformant when the service is activated since the required zone does not exist. To
allow the service to become conformant, the user must make the necessary changes in the actual
network and must add corresponding information to the XML file describing the unmanaged
network. These changes should be based on the service's outputs. To make the service conformant,
the network must include a zone containing all the endpoints listed in the service's outputs.
NOTE: In a Matrix Infrastructure Orchestration environment the provisioning will pause and an
email is sent indicating the need for manual zoning and the workflow can be continued once
zoning is performed and the XML file updated.
Network types
SPM supports only unmanaged Fibre Channel SANs. While the format of the XML file allows for
the possibility of other SAN networks types, SPM currently does not support them.
Overview 93