CLI Guide

Arguments
Required arguments
[-d|--storage-
volumes]
path,path...
* List of one or more storage volumes to claim.
Optional arguments
[--appc]
Make the specified storage volumes application consistent. Prevents data already on the specified
storage volumes from being deleted or overwritten during the process of constructing a virtual volume.
After a virtual volume is constructed using this storage volume, there is no restriction on the access to
the data, i.e. the data can be overwritten by host I/O.
CAUTION: The application consistent attribute may be modified using the set command
but only when the storage volume is in the claimed state. The application consistent
attribute may not be altered for storage volumes that are unclaimed or in use.
[-n|--name]
name
The new name of the storage volume after it is claimed.
--thin-rebuild
Claims the specified storage volumes as “thin”. Thin storage allocates blocks of data on demand versus
allocating all the blocks up front.
If a storage volume has already been claimed, it can be designated as thin using the set command.
--batch-size
integer
When using wildcards to claim multiple volumes with one command, the maximum number of storage
volumes to claim at once.
[-f|--force]
Force the storage volume to be claimed. For use with non-interactive scripts.
* - argument is positional.
Description
A storage volume is a device or LUN that is visible to metro node. The capacity of storage volumes is used to create extents,
devices and virtual volumes.
Storage volumes must be claimed, and optionally named before they can be used in a metro node cluster. Once claimed, the
storage volume can be used as a single extent occupying the volume’s entire capacity, or divided into multiple extents (up to
128).
This command can fail if there is not a sufficient number of meta volume slots. See the troubleshooting section of the metro
node procedures in the SolVe Desktop for a resolution to this problem.
Thin provisioning
Thin provisioning allows storage to migrate onto a thinly provisioned storage volumes while allocating the minimal amount of thin
storage container capacity.
Thinly provisioned storage volumes can be incorporated into RAID 1 mirrors with similar consumption of thin storage container
capacity.
Metro node preserves the unallocated thin pool space of the target storage volume by detecting zeroed data content before
writing, and suppressing the write for cases where it would cause an unnecessary allocation. metro node requires you to specify
thin provisioning for each back-end storage volume. If a storage volume is thinly provisioned, the thin-rebuild attribute must be
true either during or after claiming.
CAUTION:
If a thinly provisioned storage volume contains non-zero data before being connected to metro node,
the performance of the migration or initial RAID 1 rebuild is adversely affected.
System volumes are supported on thinly provisioned LUNs, but these volumes must have their full capacity of
thin storage container resources set aside and not be in competition for this space with any user-data volumes
on the same pool.
Commands 301