HP Storage Provisioning Manager (SPM) Version 2.0 User Guide

F Working with unmanaged networks
Overview
This section specifies the format of the XML files used to describe the characteristics of unmanaged
storage area networks (SANs) to SPM 2.0. Unmanaged SANs are SANs with which SPM cannot
communicate. In order for a user of SPM to track connectivity within such SANs using SPM, the
characteristics of the SANs are described in XML files which SPM will read.
SPM 2.0 allows users to manage connectivity in a number of SANs. However, some users may
need to manage types of SAN with which SPM cannot communicate directly. Users can track the
connectivity in such unmanaged SANs within SPM by creating XML files describing the SANs and
placing those files in a directory which SPM examines. SPM reads any files found in the directory
and incorporates the information within them into its model of connectivity. Since SPM cannot
communicate with unmanaged SANs, users must ensure consistency of the state of the SANS and
the data about them within SPM.
Unmanaged SANs
SPM 2.0 can communicate with a number of SANs as provided by Hewlett Packard. End users
can write adapters to allow SPM to communicate with other SANs. If an SPM user must configure
connectivity within a SAN for which Hewlett Packard has not provided an interface and for which
no adapter is available, these SANs can be treated as unmanaged SANs within SPM.
Unmanaged networks are networks that SPM is unable to communicate directly with and thus SPM
will only communicate with unmanaged network via the storage admin. This consists of an xml
resource file that the storage admin would enter data describing his network(s). SPM then reads
in this data and is able to generate candidates and make requests to the storage admin based on
this xml resource file.
Unmanaged networks are read only, meaning that SPM will not write changes directly to the xml
resource file. Any changes would need to be done by the storage admin one the underlying network
device manager then the xml resource file would need to be updated to reflect the changes.
Allow External Processing
Normally unmanaged networks will only generate service candidates for resources as described
in the xml resource file. However unmanaged networks contain property called Allow External
Processing that when checked will allow the unmanaged network to generate service candidates
for initiators that don’t exist in the xml resource file, but all other requirements are met and there
is a valid FCProxyWWN given to describe where the Initiator endpoint will exist on the network.
This is the same Proxy Use Case as described in Managed networks, however adapted to fit the
unmanaged networks.
If a service is created based on this unmanaged proxy case using the Allow External Processing
property the service is immediately marked as nonconformant as the initiator endpoint does not in
fact exist. The storage admin needs to recognize this as a notification to make the necessary
changes on the underlying network device manager and then reflect those changes in the xml
resource file.
Storage admin changes requested by SPM
To determine what changes should be made the storage admin will need to view the service’s
outputs. Listed will be the zone required by name and the endpoints to include in the zone. The
zone name must be used/created exactly as shown in the service outputs for the system to behave
correctly, this include case and symbols.
Zone removal
Zones can be safely removed via the underlying network device manager and removed from the
xml resource file if they are not listed in the unmanaged network’s zones tab. Only zones that are
currently depended upon by services will show up there.
72 Working with unmanaged networks