HP SAN Virtualization Services Platform - Manual (Page 11)

specific DPM group. If a host is assigned to more than one DPM group, then use the VSM GUI
and not the CLI to make virtual disk presentations.
General comments
Template/root names
Names of created VSM objects (such as, point-in-time (PiT), snapshot, and so on) may be fully
provided by the user explicitly, or may be provided as a template (root) name, to which the VSM
API concatenates a unique suffix to create a complete unique name. This is useful when you want
to run the same script every day to create some new VSM object (for example, a PiT on a virtual
disk). If you provide an absolute PiT name, an error occurs the second time the script runs, since
there is already a PiT by that name. However, if you provide a template/root name for the PiT,
every execution of the script will create a PiT with a different name.
For example, if you create a PiT with the template name pit_on_vol_1, then every time the script
is run, a PiT is created with a name similar to pit_on_vol_1_SA_123456789, where the number
following the _SA_ string is different every time the script is run.
Template/root names are limited to under 16 characters. Template names are also useful for
cleanups. If the above script is run periodically, creating a new object every time, old objects need
to be cleaned up. There is a Purge operation for this purpose. The Purge operation uses the template
name to delete old objects whose names start with the template name (followed by the _SA_ string),
leaving a user-defined number of the most recently created objects.
IMPORTANT: To prevent mistakes or errors, it is essential that you use a unique template name
for every type of created object (PiT, snapshot, and so on) from every source object (for example,
virtual disk, virtual disk group, synchronous/asynchronous mirror group, and so on), so that the
Purge operation deletes only those objects originating from the same source.
Synchronous and asynchronous operations
Many APIs and CLI commands may take some time to complete, so a timeout argument is required.
This argument defines the maximum time that the API or CLI will wait for the completion of the
operation. If the operation completes before the timeout period expires, the API or CLI returns at
that time with a success status. If the command does not complete within the timeout period, the
API or CLI returns after the timeout period expires with a VSM_SYNC_TIMEOUT error.
The successful completion of a command in this context means that:
•
If the API or CLI successfully creates a VSM object (virtual disk, PiT, snapshot, snapclone group,
and so on), this newly created object is ready to be used when the API/CLI returns. For
example, if you create a PiT, you can immediately proceed to create a snapshot on this PiT.
•
If the API or CLI successfully deletes one or more VSM objects, then after the API or CLI returns,
you can create new objects with the same names as those just deleted.
This mode of operation is referred to as a synchronous mode, since the application (or CLI) is
blocked until the operation is completed.
NOTE: The recommended timeout value to use for most operations is 900 (seconds). For some
operations (create a PiT or snapshot, delete PiT, restore snapshot), it is recommended you use even
higher values, since the time they take to complete depends on how much data they need to handle.
There is also an asynchronous mode of operation for APIs and CLI commands that creates VSM
objects like virtual disk, PiT, snapshot, PiT/snapshot on a virtual disk group, and so on. In this
mode of operation, you use the same API or CLI as before, with only one change: The timeout
value is set to zero. Under this condition, the API or CLI starts the operation but does not wait for
it to complete. So if the API or CLI returns without an error, it means that the operation was started
successfully, but has not necessarily been completed yet.
General comments 11