HP Storage Provisioning Manager (SPM) version 2.1 User Guide

Service Deactivation Policy requirement
The Service Deactivation Policy requirement specifies the actions to be taken on
deactivating the service. The available policies are:
• No Action — On service deactivation, nothing is performed. All SAN zoning, volume data,
and volume presentation are left as it was. Note that the server consuming the storage is still
be able to access it after the service is deleted.
• Quarantine Resources — On service deactivation, the volume within the service is
quarantined from server access, ensuring servers can no longer read or write the data, but
the volume and data are preserved on the array. Volume mapping and masking is removed,
and any SAN zoning is deleted from the SAN. The storage volume is put into a quarantined
state such that it is not provisionable by future requests in SPM. It is the responsibility of the
storage admin to move the data to a suitable archive before returning the volume to an enabled
state or deleting it manually.
• Destroy Data — On service deactivation, the storage volume is deleted, destroying the
data it contains and making the capacity available for future data services to provision. Any
SAN zoning that was performed is also removed. This policy is only to be used in situations
where archiving processes are in place and have saved all necessary data before deleting
the service.
• Recycle — On service deactivation, if the storage volume's presentation was changed, then
the volume is unpresented. If the storage volume was created, then the storage volume is
deleted—destroying the data it contains—and the capacity is returned to its containing pool
for future service provisioning requests. Any SAN zoning that was performed is also removed.
This policy is only to be used in situations where archiving processes are in place and have
saved all necessary data before deleting the service.
NOTE: In a Matrix OE environment, the policy should always be recycle. Other policies
can cause unexpected behavior.
Storage Capability requirement
The Storage Capability requirement specifies the capabilities which a matching service must
be able to perform after it is provisioned (subject to available capacity). If a capability is not
specified as required, then it is optional whether a provisioned service is able to perform the
operation after it is provisioned. For example, a Storage Capability requirement with a value
of “Thin Provisioning” matches only arrays that are capable of creating thinly-provisioned volumes.
Storage Pool Available Capacity requirement
The Storage Pool Available Capacity and Storage Pool Available Capacity
(percentage) requirements specify the amount of free capacity (non-committed available
capacity) which must exist in a pool after the provisioning request is completed. The amount of
free capacity can be expressed as a data size or as a percentage of the pool size.
This requirement enables the storage architect to control the amount of remaining free space that
must exist for provisioning to be performed from a pool.
This requirement is only enforced when a volume is created or grown, and evaluates as a Match
when the remaining free space in a storage template is left after the provisioning is complete. After
provisioning, the requirement always evaluates as a Match (for example, the requirement does
not cause an existing volume service to become nonconformant because the required pool free
space was no longer satisfied).
Requirement types 29