This may happen due to the redirect-on-write mechanisms which share unchanged
data between volumes and their snapshots, as well as between snapshots of the
same volume.
The Auto Delete Priority is from the list (1-4), as follows:
v 1 = Is last to be deleted automatically ("1" is the default set by the system)
v ...
v 4 = Is first to be deleted automatically
The snapshot is associated with its master volume and this association cannot be
broken or changed as long as the snapshot exists.
The overwrite option copies the current content of the volume into one of its
existing snapshots (set as an input argument). The overwritten snapshot keeps the
same SCSI serial number and same mapping, so hosts maintain a continuous
mapping to the snapshot, without any need for a rescan or similar operation. The
overwritten snapshot must be an existing snapshot of the given volume. The
overwritten snapshot can't be part of a Snapshot Group.
This command fails when no snapshot space is defined in the Storage Pool the
master volume belongs to.
Mirroring limitations:
v This command fails if the volume is a slave of an asynchronous mirroring
coupling (either synchronous or asynchronous).
v This command fails if the volume is a slave of an inconsistent synchronous
coupling.
Example:
snapshot_create vol=DBVolume name=DBVolume.snapshot1 delete_priority=2
Output:
Command executed successfully.
Access Control:
User Category Permission Condition
Storage administrator Allowed N/A
Storage integration administrator Allowed N/A
Application administrator Conditionally Allowed The volume is mapped to a host
or a cluster associated with the
user. If a snapshot overwrite is
used, the target snapshot must
be one created by a server
administrator.
Security administrator Disallowed N/A
Read-only users Disallowed N/A
Technicians Disallowed N/A
66 IBM XIV Storage System User Manual
To Next Page
Loading...
Need help?
General
