HP Storage Provisioning Manager (SPM) version 2.1 User Guide

Creating hosts on a 3PAR Storage System
When SPM attempts to present a volume to an initiator, it first probes the array to detect whether
this initiator is known to the array. If it is not, a new host is created for that initiator. The name
given to that host will generally use the host name given in the requirements. If no host name is
specified, the host name will be “SPM_” followed by the WWN of the initiator. Host names that
begin with "LSM_" are provided to SPM by Matrix OE.
The 3PAR Storage System may have hosts with multiple initiator ports. SPM may create hosts with
multiple initiator ports (e.g. if the requirement specifies this). If an initiator port is already referenced
on the array, then a presentation request might indicate that the initiator port's host grouping should
change. This could happen if a single host contained two initiator ports and the presentation request
referenced one of the ports but not the other (meaning that the initiator port should not be part of
the host anymore). If these presentation requests would affect presentation for another existing
volume, SPM will not change the array's configuration, resulting in a nonconformant service.
For example: Volume1 is presented to Host1 (WWN1) and SPM requests presentation of Volume2
to Host1 (WWN1, WWN2). Adding an initiator endpoint address to the
StorageHardwareIdCollection associated with WWN1 would mean that Volume1 would be
presented to WWN2, which is a side effect. SPM presentation changes will not generate side
effects.
Working with 3PAR Storage System active VLUNs and VLUN templates
On 3PAR Storage Systems, active VLUNs are the paths through which hosts that have logged on
to the fabric can see a given volume. VLUN templates are similar to “declarations” that volumes
are presented to hosts that are currently unknown to the array (for example, offline hosts). SPM
creates VLUN templates, which become active VLUNs when the host is powered on.
For more information, refer to the 3PAR Storage System user guide.
Working with autonomic groups
Autonomic groups are a unique feature of 3PAR Storage Systems that allow storage administrators
to group volumes, hosts, or virtual domains together. Those groups (also known as sets) allow
batch operations on a collection of objects – for instance, presenting a volume to a set of hosts in
one operation – and provide a level of automation by automatically adjusting the way volumes
are exported when objects are added to or removed from sets. For more information, please refer
to the array user guide.
This version of SPM is not fully compatible with autonomic groups and it is recommended to not
use them on arrays managed by SPM. It is however ok to use autonomic groups within the following
guidelines:
• Importing volumes that belong to one or more volume sets is supported. SPM will not reflect
the containment of those volumes in volume sets.
• Presenting volumes to hosts that belong to one or more host sets is supported. SPM will not
reflect the containment of those hosts in host sets.
• Importing volumes that are presented to one or more host sets is NOT supported: SPM will
not be able to reflect that presentation and doing so will lead to errors and inconsistencies
during requirement binding.
• Likewise, using non-SPM tools (e.g. 3PAR GUI or CLI) to present an already-imported volume
to a host set will result in unpredictable behavior during requirement binding.
Volume migration (Tiering)
With 3PAR Storage Systems, it is common for volumes to be migrated from tier to tier. Volume
migration can be performed manually using the 3PAR GUI or CLI, or it can be automated using
licensed software such as Adaptive Optimization and Peer Motion. Either way, SPM must pick up
on those changes and ensure that the catalog is as up to date as possible. To that end, there are
3 ways SPM will update the catalog to take volume migration into account:
72 Working with 3PAR storage systems