VNX Snapshots

White Paper

VNX Snapshots

Abstract
This white paper describes EMC VNX Snapshots.
The paper reviews and explains operations and
best practices for the feature, as well as limits and
functions.

July 2012

VNX Snapshots White Paper 1

Copyright © 2012 EMC Corporation. All Rights
Reserved.

EMC believes the information in this publication is
accurate as of its publication date. The information
is subject to change without notice.

The information in this publication is provided “as
is.” EMC Corporation makes no representations or
warranties of any kind with respect to the
information in this publication, and specifically
disclaims implied warranties of merchantability or
fitness for a particular purpose.

Use, copying, and distribution of any EMC software
described in this publication requires an
applicable software license.

For the most up-to-date listing of EMC product
names, see EMC Corporation Trademarks on
EMC.com.

Part Number H10858


Table of Contents
Executive summary ........................................................................................... 5
Audience ......................................................................................................... 5
VNX Snapshots Technical Overview ..................................................................... 6
What is new? .................................................................................................................... 6
How do Snapshots work? ................................................................................................ 6
Snapshot granularity ................................................................................................... 8
Snapshot Mount Point..................................................................................................... 9
VNX operations............................................................................................... 11
Create a Snap .................................................................................................................11
Create a Snapshot Mount Point....................................................................................13
Attach a Snap .................................................................................................................14
Branching (snap of a snap) ...........................................................................................15
Copy a Snapshot........................................................................................................15
Snap of a Snapshot Mount Point .............................................................................17
Detach a Snapshot Mount Point...............................................................................19
Detach a Snapshot Mount Point with Snapshots ...................................................20
Destroy a Snapshot .......................................................................................................22
Consistency Groups.......................................................................................................23
Attach a Consistent Snapshot ..................................................................................24
Branch a Consistent Snapshot .................................................................................27
Rules for Consistency Groups ...................................................................................28
Restore............................................................................................................................28
Restore with SnapView Snapshots and VNX Snapshots ........................................29
Restore a LUN.............................................................................................................29
Restore CGs ................................................................................................................31
Repurpose Snapshots ...................................................................................................31
Migrations ......................................................................................................................32
Migration considerations ..........................................................................................35
Limits ..............................................................................................................................35
VNX Snapshot Auto-Delete ............................................................................... 36
Auto-Delete Thresholds .................................................................................................37
Pool Space Used Threshold ..........................................................................................37
Snapshot Space Used Threshold .............................................................................38
Delete Eligibility .............................................................................................................39
Auto-Delete paused .......................................................................................................39


Snapshot Expiration ......................................................................................................40
CLI ................................................................................................................ 41
Create a Snapshot .........................................................................................................41
Copy a Snapshot ............................................................................................................42
Create a Snapshot Mount Point....................................................................................42
Attach a Snapshot .........................................................................................................43
Create a Cascading Snapshot .......................................................................................43
Detach a Snapshot ........................................................................................................44
Destroy a Snapshot .......................................................................................................44
List all VNX Snapshots for a LUN ..................................................................................44
Create a Consistency Group ..........................................................................................45
List Consistency Groups ................................................................................................45
Create a Consistent Snapshot ......................................................................................46
Attach a Consistent Snapshot ......................................................................................46
SnapCLI ......................................................................................................... 47
Flush buffers ..................................................................................................................47
Create a Snapshot .........................................................................................................47
Attach a Snapshot .........................................................................................................47
Copy a Snap ...................................................................................................................47
Consistency Groups.......................................................................................................48
Sample SnapCLI batch script ........................................................................................48
VNX Snapshots vs. SnapView terms .................................................................. 49
Terminology ................................................................................................... 50
Properties Detailed ......................................................................................... 51
Snapshot properties ......................................................................................................51
Snapshot Mount Point properties ................................................................................52
Additional pool properties ............................................................................................53


Executive summary
VNX™ Snapshots is a new VNX software feature that creates point-in-
time data copies. VNX Snapshots is used for data backups, software
development and testing, repurposing, data validation, and local rapid
restores. Unlike SnapView™ snapshots and clones, VNX snapshots do
not consume large amounts of pool capacity. As a result, this feature is
preferred for modern data management.
This white paper describes all VNX Snapshots operations in detail.
Wherever possible, all aspects of the feature sets are presented visually.
The paper provides straightforward instructions for common functional
tasks. Most tasks are shown from the point of view of Unisphere™
(graphical user interface) and naviseccli (command line interface).
VNX Snapshots and SnapView will coexist on the same LUN.
Furthermore, SnapView clones, which use a different technology from
SnapView snapshots, will work with VNX Snapshots.

Audience
This paper is intended for EMC customers and EMC field personnel who
are familiar with VNX technology. The paper is intended to be used as a
main reference for VNX Snapshot technology.


VNX Snapshots Technical Overview
What is new?
VNX Snapshots is a new feature introduced in VNX for Block OE Release
32. It was created to improve on the existing SnapView Snapshot
functionality by better integrating with pools. In fact, VNX Snapshots can
only be used with pool LUNs.
LUNs that are created on physical RAID groups, also called RAID LUNs,
support only SnapView Snapshots. This limitation exists because VNX
Snapshots require pool space as part of the technology.
Note: SnapView Snapshots are compatible with pool LUNs. VNX
Snapshots and SnapView Snapshots can coexist on the same pool LUN.
VNX Snapshots support 256 writeable snaps per pool LUN. It supports
Branching, also called Snap of a Snap. There are no restrictions to the
number of branches, as long as the total number of snapshots for a
given primary LUN is within 256, which is the hard limit.
Consistency Groups are also introduced in this release. Several pool
LUNs can be combined into a Consistency Group and snapped
concurrently.

How do Snapshots work?
VNX Snapshots use redirect on write (ROW) technology. ROW redirects
new writes destined for the primary LUN to a new location in the storage
pool. Such an implementation is different from copy on first write
(COFW) used in SnapView, where the writes to the primary LUN are held
until the original data is copied to the reserved LUN pool to preserve a
snapshot.
Figure 1 compares the two technologies.


Figure 1: SnapView write vs. VNX Snapshot write

In Figure 1, the main difference between SnapView Snapshot and VNX
Snapshot is evident. VNX Snapshot technology writes the new data to a
new area within a pool, without the need to read/write to the old data
block. This improves the overall performance compared to SnapView.
Similarly, during a read from a snapshot, the snapshot's data does not
need to be constructed from two different places as shown in Figure 4

Figure 2: SnapView read vs. VNX Snapshot read


Snapshot granularity
Every VNX Snapshot has 8 KiB block granularity. This means that every
write occupies at least 8 KiB on the pool. The distribution of the 8 KiB
blocks within a 1 GiB slice is congruent with the normal thin write
algorithm.
Consider the following example. A LUN is snapped with a few blocks of
data. The new snapshot points at those blocks, just like the primary
LUN.

Figure 3: VNX Snapshot pointing at the same blocks with the LUN at creation time

After a few moments, the primary LUN may receive an I/O that overwrites
block A. The first snapshot continues pointing to the original set of
blocks A, B, C, and D. After Snap2 is taken, it points to A`, B, C and D.
The next primary LUN I/O overwrites block D, and it now points to A`, B,
C, and D`.

Figure 4: VNX Snapshots point at unchanged blocks, Primary LUN is using new blocks


Thick LUN consideration
When a VNX Snapshot is created on a Thick LUN, portions of its address
space are changed to indirect mode. In other words, when writes come
in to the Snapped Thick LUN, the LUN starts converting address mapping
from direct to 8KiB blocks for each portion of the Thick LUN being
written.
Note: Thick LUN remains to be classified as Thick in the CLI and GUI.
The Thick LUN remains in an indirect mode while it has VNX Snapshots.
When the last snapshot of the Thick LUN is removed, the mode
automatically converts to direct . The conversion to direct mode is not
instantaneous, and is performed in the background. The conversion can
be aborted by creating a new VNX Snapshot on the LUN.
VNX Snapshots are a part of the storage pool. A snapshot does not
consume space from the pool, until the new data is written to the
primary LUN or to the snapshot itself.

Snapshot Mount Point
Snapshot Mount Point (SMP) is a virtual LUN-like container. It is used to
emulate a typical LUN, but provides the ability for the host to write to
snapshots and to change snapshots without the need to rescan the SCSI
bus on the client.

Figure 5: What is a Snapshot Mount Point?


An SMP is created for snapshots of a specific LUN. This means that each
SMP can be used only for snapshots of a single primary LUN.
To enable access to hosts, SMPs must be provisioned to storage groups
just like any typical LUN.


VNX operations
VNX Snapshots support the following operations.

Create a Snap
Creating a snapshot does not consume any pool space. The space starts
being used when new writes to the primary LUN or the snapshot itseld
arrive. Snapshots have a granularity of 8 KiB, and thier blocks are
tracked just like the blocks in thin LUNs.

Figure 6: A pair of VNX Snapshots

Every snapshot must have a primary LUN, and that property never
changes. A primary LUN cannot be deleted while it has snapshots. In
Unisphere, you can delete a LUN that has snapshots by selecting an
optional setting that deletes the snapshots first.
To create a snapshot:
1. In Unisphere, select Storage > LUNs.

Figure 7: Create VNX Snapshots in Unisphere


2. Click Create Snapshot or right-click the primary LUN.

# To create snapshot in the CLI

naviseccli snap -create -res 1 -name "cli_snap" -descr "snap created via CLI"
# ^^^
# LUN ID

When a snapshot is first created, it is write-protected:

Figure 8: Unisphere view of the VNX Snapshot write protection

When you try to attach a snapshot that has the Allow Read/Write option
disabled, Unisphere automatically enables it and displays a warning.

Figure 9: Unisphere VNX Snapshot Attach warning

If a Snapshot is attached from the CLI, then the -allowReadWrite property
must be set to Yes. Therefore, you must manually modify it prior to an
attach command.


Before creating a snapshot, use the SnapCLI utility to flush the host
buffers.
:: Windows
SnapCLI flush -o G:

# To modify a snap in the CLI

naviseccli snap -modify -id "cli_snap" -allowReadWrite yes

Create a Snapshot Mount Point
To create an SMP in Unisphere, use the Configure Snapshot Mount Point
wizard located in Data Protection > Common Data Protection Tasks. The
wizard is also available in the Wizards area on the right pane.

Figure 10: Unisphere Snapshot Mount Point creation wizard location

Alternatively, you can also create an SMP by right clicking on a LUN
listed in the LUN tab under Storage > LUNs.

Figure 11: Unisphere right mouse click Snapshot Mount Point creation

Creating an SMP does not require any space from the pool.


Note: Each SMP is dedicated to a specific primary LUN. It is not possible
to attach snapshots from two different primary LUNs to a single SMP.
Therefore, a backup server that is backing up four different LUNs must
have four different SMPs provisioned to back up the snapshots of those
LUNs.
In Unisphere, you can provision the SMP to a host through either the
wizard or the SMP create screen.
In the CLI, you can provision the SMP to a host by using the Storage
Group command:
# To create a Snapshot Mount Point in CLI

naviseccli lun -create -type Snap -primaryLunName PrimaryLUN -sp B -l 60
-name SMP_name -allowInbandSnapAttach yes # ^^ SMP LUN ID!!!

# When LUN ID is not provided at creation, VNX assigns one automatically.
# in that case, it needs to be looked up in order
# to provision the SMP to a storage group

# To provision the SMP to a Storage Group

naviseccli storagegroup -addhlu -gname "Storage Group 1" -hlu 60 -alu 60

CLI guidelines
• Create the SMP on the same Storage Processor as the primary
LUN
• Set the -allowInbandSnapAttach parameter to "yes" to allow
SnapCLI host binary to attach the Snapshots (It is a security
feature. The Troubleshooting section provides more details.)
o This parameter can easily be modified at a later time.
• An SMP is added to a storage group just like a usual LUN.

Attach a Snap
Attaching is an asynchronous operation during which the SMP remains
available, but the I/O is queued. This means that that the host does not
have to rescan the SCSI bus to view the snapshot. The rescan is required
only to discover the SMP when it is first presented to the host.


Figure 12: Attaching a Snapshot to a Snapshot Mount Point

Note: A SCSI rescan is not required for switching attached snapshots,
that is, detaching one snapshot and attaching another to the same SMP.
However, you must stop all I/O to the SMP and most importantly, flush
the host buffers (using the SnapCLI utility).

Branching (snap of a snap)
There are two main ways to create a Snap of a Snap. One way is to
create a simple copy of a Snapshot and another is to take a Snapshot of
the attached Mount Point, for example, Cascading Snapshots.

Copy a Snapshot
A VNX Snapshot can be copied to another snapshot. The resulting
snapshot is a copy of the source except for the name. The -
allowReadWrite1 property is set to No on the copy.
The snapshot copy retains the source LUN properties and resides within
the same pool as the original snapshot. So, copying a snapshot
increases snapshot count by one.

1
This property is a security feature, preventing unauthorized mounting a snapshot for read/write operations.


Figure 13: VNX Snapshot copy

Note: Only unattached snapshots can be copied. Attached snapshots
are branched by snapping SMP, a process that is also called Cascading
Snapshots.


Snap of a Snapshot Mount Point
A snapshot of an SMP still has the same Primary LUN property as the
Mount Point (and as the attached snapshot. The primary LUN properties
of snapshots and the mount points that they are attached to will never
be different)
It is technically possible to attach a snapshot to an SMP that is not a
part of a storage group. Therefore, it is possible to create a snapshot of
such an SMP. The resulting snapshot will be slightly different from a
regular snapshot copy. The source of this snapshot and the creation
times will not be the same as the snapshot attached to the SMP.

Figure 14: VNX Snap of a Snap, aka Cascading Snapshots


The Source LUN property of the Cascading Snapshot has the name of the
SMP. It is possible to create multiple snapshots at this level, and
individually mount them.

Figure 15: VNX Snapshots, multiple levels

Note: In Figure 14 and Figure 15, both SMPs may only be used for
Primary LUN1 Snaps. No other snapshots may be attached to them.
However, either SMP could be provisioned to any host..


Detach a Snapshot Mount Point
Detaching a snapshot from an SMP modifies these properties: Last
Modified Date and Last Modified By. Detaching a snapshot from an SMP
does not destroy the SMP by default, and the SMP stays provisioned to
the host. Detaching is an asynchronous operation during which the SMP
remains available, but the host I/O is queued at the array. After the
detach operation completes, all queued I/O requests return a fail status
to the host.

Figure 16: Detaching a VNX Snapshot


Detach a Snapshot Mount Point with Snapshots
Detaching a snapshot from an SMP is more complex when the SMP has
a few of its own snapshots.

Figure 17: Detaching SMP with its own Snapshots

Figure 17 shows that as a result of Snap2 detaching from SMP1, the
second level snapshots (Snap2.1 and Snap2.2) need to change:
• The Source LUN property to match a higher-level object, which
is Primary LUN1.
• The Creation time to match Snap2 (original Snap attached to
SMP1)
• The Last modify time to match the old Last modified time or
Creation time (if Last modified was empty) or remains the same,
if the snapshot had not been modified (as Snap2.2 has in Figure
17).


Similarly, a multilevel structure will change as shown in Figure 18.

Figure 18: Multi-level detaching SMP with its own Snapshots

Note: A detached SMP persists by default and is kept provisioned to the
host. There is no degradation in the array performance during the
detaching operation.
When users are about to detach an SMP, Unisphere displays a message
asking users to stop I/O and flush the host buffers.

Figure 19: Unisphere Snapshot detach confirmation

EMC recommends flushing the buffers by using the SnapCLI utility on
the host. For example:
:: Windows. flush the buffers for drive G:
SnapCLI.exe flush -o G:


Destroy a Snapshot
Destroying (deleting) a snapshot reclaims space for reuse in the storage
pool. Reclaim is not instant, and is done by an internal process. This
internal process is throttled for better performance of the array and is
not sequential, that means, more than one snapshot can be destroyed
at one time. Multiple snapshot destructions start on the first-come-first-
served basis. VNX is tuned to destroy up to 16 snapshots
simultaneously on each Storage Processor (SP). Additional destruction
requests are queued until a destruction thread becomes available.
When a snapshot is in the "Destroying" state, it is still counted towards
the maximum number of snapshots. The snapshot name is changed to
Destroying_<timestamp> before it is destroyed. This way, a user can re-
create a snapshot called "Monday_Backup_Snapshot" immediately
after executing a command to destroy the old snapshot . This is
especially useful for SnapCLI-based scripts.
After the destruction command is accepted by the array, actual
destruction may take different amounts of time to complete. The time
difference is dependent on several factors such as the amount of data
within a Snap, the SP CPU load, and the speed of the underlying disks
within a pool.


Consistency Groups
A Consistency Group (CG) is an object that contains a list of primary
LUNs or SMPs (but not both) that are treated as a single entity for taking
snapshots.
A Consistent Snapshot is one snapshot of a collection of LUNs. When a
snapshot of a CG is initiated, all writes to member LUNs are held until
their snapshots have been created. Typically, CGs are used for LUNs that
belong to the same application.
Note: Application-side consistency is achieved with AppSync product
that integrates with VNX Snapshots and VNX Snapshot CGs.
CGs are intended to take write-order–consistent snapshots of a group of
LUNs or SMPs. CGs have a name and description. CGs can contain any
non-private pool-based LUNs, or SMPs.

Figure 20: VNX Snapshot Consistency Group

Figure 21: Unisphere view of a Consistency Group


Attach a Consistent Snapshot
Mounting an entire Consistent Snapshot requires the same number of
SMPs as there are members in the CG.

Figure 22: Attaching a Consistent Snapshot

Note: A Consistent Snapshot may have different number of snapshots
than a CG, if the CG’s members were modified after the snapshot was
taken.
It is technically possible to attach a single snapshot from the Consistent
Snapshot. The system checks the SMP's primary LUN to know which
portion of the Consistent Snapshot to attach.


Figure 23: Attaching individual SMPs to a Consistent Snapshot

However, when SMPs are also members of a CG, they can be attached to
only one consistent snapshot. Figure 24 displays a bad example that
does not work.
The main difference between Figure 24 and Figure 23 is that SMPs in
Figure 23 are not in a CG, and SMPs in Figure 24 are.


Figure 24: SMPs that are members in a CG cannot be attached to different Consistent Snapshots


Branch a Consistent Snapshot
Consistent Snapshots can be branched just like regular snapshots.

Figure 25: Attaching a Copy of a Consistent Snapshot


Cascading Consistent Snapshots
To create a cascading Consistent Snapshot, a new CG must be created
out of SMPs attached to a snapshot.

Figure 26: Attaching a Cascading Consistent Snapshot

Rules for Consistency Groups
The rules for CGs are:
• CGs must not contain a combination of primary LUNs and SMPs
• CGs must not contain multiple SMPs from the same primary LUN
• Any LUN/SMP can belong to only one CG
• SMPs that are members in a CG cannot be attached to different
Consistent Snapshots
• Consistent Snapshots for RAID LUNs or a mix of RAID LUNs and
Thick/Thin LUNs are only possible with SnapView snapshots
(sessions)

Restore
Snapshots can be used to restore a primary LUN or an SMP. In other
words, the data in the LUN will be changed to match the data in the
snapshot. The classic use case for this operation is when recovering
from data corruption.


Restoring automatically creates a 'Restore point snapshot' to recover
from unintentional data corruption. Although restoring is not instant, it
is an online operation. While the LUN is being restored, its state shows
as 'Initializing,' and is changed back to 'Ready' after the restore is
complete.
Note: Restoring is also referred to as Protected Restore, because
restoring does not change the snapshot. All its data is protected.
When restoring an SMP, the data from the source snapshot (the one
being restored) is placed onto the snapshot attached to a Mount Point.
Note: Restoring can change the LUN size if the source snapshot was
taken before the primary LUN expansion or shrinking.

Restore with SnapView Snapshots and VNX Snapshots
Since pool LUNs can have a combination of SnapView snapshots and
VNX Snapshots, it is possible to restore from either a SnapView
snapshot or a VNX Snapshot. Restore is supported for both cases.
• To restore a primary LUN from a VNX Snapshot, all SnapView
snapshots (sessions) must be manually deleted (stopped).
• If the primary LUN is restored from a SnapView snapshot
(session), VNX Snapshots are unaffected.

Figure 27: Unisphere error on Snapshot restore due to the presence of a SnapView session

Restore a LUN
Certain prerequisite steps must be performed from the host operating
system for a successful LUN restoration. Operating Systems often have
cached metadata pertaining to the LUN's file system. Restore operations
tend to confuse memory maps unless the cache is cleared.
This affects most operating systems. The following is a sample
procedure to restore a LUN from a VNX Snapshot. Microsoft Windows
operating system is used as an example.
Step 1
Stop application access to the LUN. Optionally, you may need to flush
application buffers.


Step 2
Flush the buffers for the drive by using SnapCLI .
Note: EMC recommends using SnapCLI for all other operating systems (if
an appropriate binary exists). Use native operating system methods
when SnapCLI binary is not available.
:: Windows
SnapCLI flush -o G:

:: Optionally, one could flush a physical drive, when it is not a "drive letter"
:: Note, this command makes sense only when the drive is mounted,
:: e.g. has a drive letter assigned
SnapCLI flush -o .PhysicalDrive1

Step 3
Unmount the drive. For some versions of Windows, unmounting refers to
removing the drive letter. Windows 2008 has an option to turn the drive
offline. This can be done either from Disk Management or from the CLI
(diskpart).
Note: Unmounting the drive guarantees that the host stops all I/O to the
LUN.

Figure 28: Windows 2008 Disk Manager -- switching a disk to offline mode

C:>diskpart

Microsoft DiskPart version 6.1.7601
Copyright (C) 1999-2008 Microsoft Corporation.
On computer: WIN2K8

DISKPART> list disk


Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 465 GB 38 MB
Disk 1 Online 10 GB 1024 KB

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> offline disk

DiskPart successfully offlined the selected disk.

DISKPART>

Step 4
Restore the LUN from Unisphere or by using naviseccli.
Note: SnapCLI does not allow restores for security reasons.
Step 5
Mount the drive (On Windows 7, assign a letter)

Restore CGs
When restoring a Consistent Snapshot to a CG, it is possible that the
member list of the current CG may be out of sync with the list of LUNs in
a Consistent Snapshot. This happens when a CG is extended with
additional members.
In this case, the array does not let users restore CG from a snapshot with
different CG members than the current member list. The CG must be
modified to match the member list of the snapshot, followed by another
restore attempt.

Repurpose Snapshots
Some snapshots may need to be repurposed for other use. For example,
when a primary LUN must be deleted, but one of its VNX Snapshots
need to be retained.
There are two ways to do that:
• Migrate the SMP to another LUN before deleting the primary LUN
• Detach a snapshot and then restore the primary LUN (from that
snapshot)
o The primary LUN may have a different HLU than SMP, or
may even be presented to another host. Make sure to
check where the data is provisioned.
o In addition, the primary LUN has a different WWN from the
SMP. So, if any of your tools or scripts are using the WWN
of the SMP/primary LUN, they must be updated.


Migrations
One of the VNX Snapshot use cases is to promote a snapshot to be a
typical LUN. To do that, the snapshot must be attached, and then the
SMP can be migrated to another LUN.
If a migrating SMP has any snapshots associated with it (for example
Cascading Snapshots), all of them will be destroyed.

Figure 29: Attached Snapshot before migration

Consider the example in Figure 29:
• 'Host 1' is a production server running an application with
'PrimaryLUN1' provisioned.
• 'Host 2' is a development server. This server must try a new
version of the application on a copy of the production data.
• The Administrator performs the following actions:
o Takes a snapshot 'Snap2' from the production
'PrimaryLUN1'
o Creates an SMP 'SMP Name' for snapshot from
'PrimaryLUN1'


o Provisions 'SMP Name' to 'Host 2' (for example adds 'SMP
Name' to the storage group for 'Host 2')
o Attaches 'Snap2' snapshot to 'SMP Name'
o Runs SCSI rescan on 'Host 2'
o Creates a local drive on 'Host 2'
• At some point, 'SMP Name' is snapped, and a 'Snap2.1' is
created.
After some time of running development code on 'SMP Name', it is decided
to promote it to an independent LUN
The Administrator performs the following actions:
• Creates a new LUN, 'LUN Temp' that is the same size as
'PrimaryLUN1'. The new LUN does not have to be a pool LUN, or
be in the same pool. It can be any LUN that is supported by the
VNX array.
• Starts a LUN migration session from 'SMP Name' to 'LUN Temp'
o Unisphere displays a warning message that the existing
'SMP Name' snapshots will be destroyed.

Figure 30: Unisphere LUN migration warning

o Administrator acknowledges the warning.


• The LUN migration runs for some time. The speed of migration
depends on several factors such as the LUN priority, size of
'PrimaryLUN1', and array load.
• Migration completes and
o 'SMP Name' Snapshot Mount Point is deleted
o 'LUN Temp' is renamed to 'SMP Name' and retains all the
SCSI attributes of the Mount Point, including WWN and even
HLU ID within the storage group.
o 'Snap2.1' is destroyed
 An internal process examines the blocks used for
'Snap2.1' and returns them to the pool

Figure 31: Migrating an attached Snapshot Mount Point to a new LUN

Note: If any of the 'SMP Name' snapshots were attached, the LUN
migration would not have started. If 'SMP Name' had many unattached
snapshots, they would be deleted as a result of LUN migration.


Migration considerations
• When a primary LUN with SnapView snapshots is migrated to a
RAID or pool LUN, all SnapView snapshots migrate to the
destination LUN
• When a primary LUN or attached SMP with VNX Snapshots is
migrated to a RAID or pool LUN, all VNX Snapshots are deleted
(migration does not start if one of several of the underlying VNX
Snapshots are attached or in use)

Limits
• The maximum number of snapshots per primary LUN is 256. The
system displays an error if a user tries to create more snapshots.
The same error is displayed in the CLI.
• When a pool LUN has a VNX Snapshot and a SnapView Snapshot at
the same time, SnapView COFW takes priority over ROW. That
means that the "old" data is copied to the Reserve LUN Pool (RLP)
first, before the "changed" data is written. The data written is still
placed in the proper pool space, not within the pool LUN (as it
would have been if the LUN had not been a RAID group LUN.)
• A snapshot taken before primary LUN (thin LUN only) expansion
does not reflect the new size. Therefore, a restore from that
snapshot will restore primary LUN back into the old size.
• An Attached SMP can be expanded, but only if it is attached to a
snapshot and is associated with a Thin primary LUN. SMPs
associated with Thick LUNs cannot be expanded.


VNX Snapshot Auto-Delete
As stated earlier, VNX Snapshots use pool space and decrease the
amount of user usable space in the pool. The mechanism to control
unlimited snapshot growth was created, and dubbed 'Auto-Delete
Management.'
The main goal of VNX Snapshot Auto-Management is not to let the
snapshots take usable space away from pool LUNs. Auto-Delete is
controlled by the Auto-Delete policy that can be set on each pool, pool
LUN, CG, and VNX Snapshot. Every Auto-Delete policy has two sets of
thresholds:
a. Pool Space Thresholds (low and high)
b. Snapshot Space Thresholds (low and high)
The Auto-Delete Pool policy is enabled by default. However, in can be
easily disabled.
Note: Only Storage Pool Auto-Delete policy is enabled by default. The
policy for Pool LUNs, Consistency Groups, and VNX Snapshots are
disabled by default.

Figure 32: Unisphere Pool properties, showing Auto-Delete policy

The Auto-Delete policy can be enabled or disabled for the following
objects:
• Pool
• LUN


• Snapshot (Regular or Consistent Snapshot)
• Consistency Group
• SMP
Whenever a high threshold is crossed, the VNX array starts an Auto-
Delete process that scans the affected pools for Snapshots that are
eligible for destruction based on the Auto-Delete policy of the pools,
primary LUNs, SMPs, CGs, and snapshots.
Note: Attached snapshots are excluded from Auto-Delete regardless of
other settings.
Disabling Auto-Delete at the pool level disables all Auto-Delete
operations within the pool, regardless of the individual
LUN/CG/snapshot settings (except for scanning for expired LUNs).
Disabling Auto-Delete on a LUN, SMP, or CG, disables Auto-Delete on all
snapshots created from it regardless of the individual snapshot
settings.
Snapshots are Auto-Deleted one at a time, because the system does not
have an ability to predict how many snapshots need to be deleted to
reach the low threshold.

Auto-Delete Thresholds
Figure 33 shows Auto-Delete thresholds.

Figure 33: Storage Pool Auto-Delete Thresholds

Pool Space Used Threshold
Pool Space Used Threshold is a user configurable parameter that
determines whether the system should monitor the space used in the


Pool and Auto-Delete snapshots if required. When enabled, the
following thresholds are used for space monitoring. When disabled, the
threshold values are retained by the system but the pool space used is
not actively monitored.
Pool Space Used Threshold is enabled by default at the time of Pool
creation.
There are two Pool Space Used Thresholds:
• Pool Space Used High Threshold: By default, it is set to 95% of the
pool capacity. When the pool crosses the threshold, the Auto-Delete
process is triggered. This process examines pool snapshots for
destruction eligibility in order of age, oldest first. When eligible
snapshots are found, the process starts deleting them one at a
time.
• Pool Space Used Low Threshold: By default, it is set to 85% of the
pool capacity. This threshold must be smaller than Pool Space Used
High Threshold. When this threshold is crossed, it is an indication
for the Auto-Delete process to stop looking for new snapshots
eligible for deletion.
Snapshot Space Used Threshold
Snapshot Space Used Threshold is a user configurable parameter that
determines whether the system should monitor the Snapshot space
used in the pool and Auto-Delete Snapshots if required. When enabled,
the following thresholds are used for space monitoring. When disabled,
the threshold values are retained by the system but the snapshot space
used is not actively monitored.
Snapshot Space Used Threshold is disabled by default at the time of
pool creation.
There are two Snapshot Space Used Thresholds:
• Snapshot Space Used High Threshold: By default, it is set to 25% of
the pool capacity. When the pool crosses the threshold, the Auto-
Delete process is triggered. This process examines the pool
snapshots for destruction eligibility in order of age, oldest first, and
starts deleting them one at a time.
• Snapshot Space Used Low Threshold: By default, it is set to 20% of
the pool capacity. This threshold must be smaller than Snapshot
Space Used High Threshold. When this threshold is crossed, it is an
indication for the Auto-Delete process to stop looking for new
snapshots eligible for deletion.


Delete Eligibility
A busy snapshot is excluded from Auto-Delete or expiration destruction.
A snapshot is busy when:
• It is attached to a SMP
• It is involved in a restore
The Auto-Delete settings can be set in multiple places. Use the following
table for system rules.

Pool LUN VNX Auto-Delete behavior
Snapshot
On On On Snapshots are subject to destruction
On On Off This snapshot is exempt from
destruction
On Off On or Off Snapshots are exempt from
destruction
Off On or Off On or Off All pool Snapshots are exempt from
destruction
Similar rules apply to Consistent Snapshots.
Note: If a Consistent Snapshot has member LUNs in multiple pools,
Auto-Delete in any of those pools can delete that snapshot unless the
snapshot or its Source CG are exempt.

Auto-Delete paused
When Auto-Delete is unable to find enough eligible snapshots to delete
to be able to reach the Low Threshold, a warning is posted.
To resolve the warning, perform one or several of the following actions:
• Increase pool's capacity by adding more disks to it
• Manually delete snapshots
• Change configuration to allow more snapshots to be
automatically deleted
• Change thresholds
In some extreme cases, when deleting snapshots or failing to find
eligible Snaps to be deleted, the Auto-Delete process does not get
below the High Threshold. In that case, the Auto-Delete process stops
and posts an "Automatic Snapshot deletion paused" array error.


Figure 34: Unisphere Auto-Delete error

To correct the error, perform one or several of the same actions as with a
warning and make sure to manually restart the automatic deletion
feature in the Pool Properties dialog box. Optionally, an error condition
is lifted when Auto-Delete is completely disabled on a pool.

Snapshot Expiration
Every VNX Snapshot may have an optional expiration date. Expired
snapshots are destroyed at regular intervals. The VNX array scans for
expired snapshots once an hour (The Auto-Delete process does not
process destruction of expired snapshots. The destruction is handled by
another software layer.) When the expiration time is reached, the
snapshot may not be destroyed immediately. It is deleted by the
process started at the next running interval.
Setting an expiration date on a snapshot automatically disables Auto-
Delete. In CLI, the user must acknowledge a warning or overwrite it with -
o flag. In Unisphere, the user can set an expiration date only after Auto-
Delete is disabled (unchecked).
Similarly, enabling Auto-Delete for a snapshot automatically clears the
expiration timestamp for that snapshot and Unisphere displays a
warning.


CLI
Navisphere Secure Command Line Utility, naviseccli, is updated to
include a new command 'snap' and extend existing 'lun' command for
VNX Snapshots.
[nasadmin@~]$ naviseccli -h SPA snap

Usage:
snap -create -res resource [-resType type][-name snapName][-descr description]
[{-keepFor keepFor|-allowAutoDelete {yes|no}}][-allowReadWrite {yes|no}][-o]
snap -destroy -id snapName [-o]
snap -list [{-id snapName|[-resType type][-res resource]}][{-brief|-detail}]
snap -modify -id snapName [-name newName][-descr description]
[{-keepFor keepFor|-allowAutoDelete {yes|no}}][-allowReadWrite {yes|no}]
snap -copy -id snapName [-name newName][-o]
snap -restore -id snapName [-bakName bakName][-res lunNumber][-o]
snap -attach -id snapName -res lunNumber
snap -detach -id snapName [-res lunNumber][-o]
snap -group -create -name cgName [-res lunNumber(s)][-descr description]
[-allowSnapAutoDelete {yes|no}]
snap -group -destroy -id cgName [-destroySnapshots]
snap -group -list [-id cgName][{-brief|-detail}]
snap -group -modify -id cgName [-name newName][-descr description]
[-allowSnapAutoDelete {yes|no}]
snap -group -addmember -id cgName -res lunNumber(s)
snap -group -rmmember -id cgName -res lunNumber(s)
snap -group -replmember -id cgName -res lunNumber(s)
snap -feature -info

A quick list of array maximums and total VNX Snapshot numbers is
displayed with this command:
[nasadmin@~]$ naviseccli -h SPA snap -feature -info

Is VNX Snapshots Supported: True
Max. Snapshots: 8192
Max. Snapshots Per Primary LU: 256
Max. CGs: 128
Max. Members Per CG: 64
Max. Snapshot Mount Points: 1024
Total Number of Snapshots: 42
Total Number of CGs: 3
Total Number of Snapshot Mount Points: 16

Instead of listing CLI commands, view the collection of commands that
are helpful for everyday CLI use.

Create a Snapshot
To create a snapshot, naviseccli requires the LUN ID, and not the LUN
name. Be sure to flush host buffers before creating a snapshot. See 7.1
Flush buffers for an example.
# Look up the LUN ID, if needed.
[nasadmin@~]$ naviseccli -h SPA lun -list -name Primary_LUN1 -default

LOGICAL UNIT NUMBER 10 <== LOOK HERE
Name: Primary_LUN1
Default Owner: SP B

# Create a Snapshot, and allow it to be mounted read/write (default is no)
[nasadmin@~]$ naviseccli -h SPA snap -create -res 10 -resType LUN -name
Primary_LUN1_Snapshot -descr "The CLI made snapshot" -allowReadWrite yes

# list a Snapshot
[nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot


Name: Primary_LUN1_Snapshot
Description: The CLI made snapshot
Creation time: 03/27/12 10:54:54
Source LUN(s): 10
Source CG: N/A
State: Ready
Allow Read/Write: Yes
Modified: No
Allow auto delete: Yes
Expiration date: Never

Copy a Snapshot
As explained earlier, a copy of a snapshot does not inherit two
properties:
• Name
• Allow Read/Write flag, which is set to 'No' by default
Creation time is inherited from the original snapshot.
[nasadmin@~]$ naviseccli -h SPA snap -copy -id Primary_LUN1_Snapshot
-name Primary_LUN1_Snapshot_COPY

[nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot_COPY

Name: Primary_LUN1_Snapshot_COPY
Creation time: 03/27/12 10:54:54
Source LUN(s): 0
Source CG: N/A
State: Ready
Allow Read/Write: No <===== LOOK HERE. Allow Read/Write property is not copied!
Modified: No

Create a Snapshot Mount Point
An SMP is a 'LUN-like' object, and is created similar to a simple pool
LUN.
The -allowInbandSnapAttach property is a security feature, that lets
SnapCLI from the host to attach/detach snapshots to this mount point.
[nasadmin@~]$ naviseccli -h SPA lun -create -type Snap -primaryLunName Primary_LUN1
-name PrimaryLUN1_SMP1 -allowInbandSnapAttach yes -sp B

# list the SMP
[nasadmin@~]$ naviseccli -h SPA lun -list -name PrimaryLUN1_SMP1

LOGICAL UNIT NUMBER 8155 <=== Note the LUN number
Name: PrimaryLUN1_SMP1
UID: 60:06:01:60:13:40:2A:00:70:5C:2C:51:1E:78:E1:11
Current Owner: SP B
Default Owner: SP B
Allocation Owner: SP B
User Capacity (Blocks): 20971520
User Capacity (GBs): 10.000
Consumed Capacity (Blocks): 8404992
Consumed Capacity (GBs): 4.008
Pool Name: Pool 0
Raid Type: r_5
Offset: 0
Auto-Assign Enabled: DISABLED


Auto-Trespass Enabled: DISABLED
Current State: Ready
Status: OK(0x0)
Is Faulted: false
Is Transitioning: false
Current Operation: None
Current Operation State: N/A
Current Operation Status: N/A
Current Operation Percent Completed: 0
Is Pool LUN: Yes
Is Thin LUN: Yes
Is Private: No
Is Compressed: No
Tiering Policy: Auto Tier
Initial Tier: Highest Available
Tier Distribution:
Performance: 100.00%

After the SMP is created, it could be added to a Storage Group, similar to
a typical LUN:
[nasadmin@~]$ naviseccli -h SPA storagegroup -addhlu -gname "Storage Group 1"
-hlu 50 -alu 8155

Attach a Snapshot
There are two ways to attach a snapshot:
1. Attach a snapshot to an SMP by sending a command to the SMP
2. Attach a snapshot to an SMP by sending the command to the
snapshot
# attach via the lun command
[nasadmin@~]$ naviseccli -h SPA lun -attach -l 8155 -snapName Primary_LUN1_Snapshot

# attach via the snap command
[nasadmin@~]$ naviseccli -h SPA snap -attach -id Primary_LUN1_Snapshot -res 8155

# Note: in both cases 8155 is the LUN ID of the Snapshot Mount Point

If a snapshot does not allow read/write access, you will receive the
following error:
The properties of this snapshot do not allow it to be attached. Modify the snapshot
properties to allow it to be attached and retry the attach operation. (0x716d802e)

# To modify the Read/Write flag use this command:
[nasadmin@~]$ naviseccli -h SPA snap -modify -id Primary_LUN1_Snapshot
-allowReadWrite yes

# And repeat attach

Create a Cascading Snapshot
Cascading snapshot is a snapshot of an attached SMP.
[nasadmin@~]$ naviseccli -h SPA snap -create -res 8155
-name PrimaryLUN1_Cascading_Snapshot1

# list the result
[nasadmin@~]$ naviseccli -h SPA snap -list -id PrimaryLUN1_Cascading_Snapshot1 -detail

Name: PrimaryLUN1_Cascading_Snapshot1
Description:
Creation time: 03/27/12 12:54:21


Last modify time: Never
Last modified by: N/A
Source LUN(s): 8155 <===== LUN ID of the SMP (aka PrimaryLUN1_SMP1)
Source CG: N/A
Primary LUN(s): 10 <===== LUN ID of the Primary LUN (aka Primary_LUN1)
State: Ready
Status: OK(0x0)
Allow Read/Write: No <===== We didn't specify -allowReadWrite flag at creation
Modified: No
Attached LUN(s):

Detach a Snapshot
There are two ways to detach a snapshot:
1. Detach a snapshot by sending a command to the snapshot
2. Detach a snapshot by sending the command to the SMP
To detach using a lun command, use the name of the SMP. There are no
warnings.
[nasadmin@~]$ naviseccli -h SPA navi lun -detach -name PrimaryLUN1_SMP1

However, when sending the detach command to a snapshot itself, there
are warnings:
[nasadmin@~]$ naviseccli -h SPA snap -detach -id Primary_LUN1_Snapshot
WARNING : Attempting to detach a snapshot mount point that has snapshots. The snapshots
of the mount point will be inherited by the source of the snapshot being detached.
Snapshot mount point: 8154
Are you sure you want to perform this operation?(y/n): yes

[nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot -detail

Name: Primary_LUN1_Snapshot
Creation time: 03/27/12 10:54:54
Last modify time: 03/27/12 13:01:09 <===== Time when detached
Last modified by: PrimaryLUN1_SMP1_COPY
Source LUN(s): 0
Source CG: N/A
Primary LUN(s): 0
State: Ready
Status: OK(0x0)
Modified: Yes <===== Shows as modified, since it used to be attached
Attached LUN(s): <===== Nothing listed

Destroy a Snapshot
[nasadmin@~]$ naviseccli -h SPA snap -destroy -id Primary_LUN1_Snapshot
Are you sure you want to perform this operation?(y/n): yes

List all VNX Snapshots for a LUN
Check whether the LUN belongs to a CG.
[~]$ naviseccli -h SPA lun -list -l 4 -belongsToCG
LOGICAL UNIT NUMBER 4
Name: LB_LUN
Consistency Group: USG-CG

[~]$ naviseccli -h SPA lun -list -l 12 -belongsToCG


Name: LB_LUN
Consistency Group: N/A

Note: The 'getlun' command does not show the VNX Snapshot
information.

[~]$ naviseccli -h SPA getlun 4 | egrep -i "group|snap"
RAIDGroup ID: N/A

If the LUN is a part of a CG, use that CG name to find the list of all LUNs:
[~]$ naviseccli -h SPA snap -list -res CG_name
Name: 2012-02-10 14:45:18
Description:
Creation time: 02/10/12 14:45:24
Source LUN(s): 4,5
Source CG: CG_name
State: Ready
Modified: No

Name: Backup Snapshot:2012-02-14 04:28:21
Description:
Creation time: 02/14/12 16:28:23
Source LUN(s): 4,5
Source CG: CG_name
State: Ready
Allow Read/Write: No
Modified: No

To list snapshots for a single LUN (that is not a member of a CG) specify
the LUN ID or name with -res option.

Create a Consistency Group
To create a CG with two member LUNs, use this command:
[~]$ naviseccli -h SPA snap -group -create -name "CG_name" -res 4,5 -descr "CG group1"

List Consistency Groups
To list all CGs on the array, use this command:
[~]$ naviseccli -h SPA snap -group -list
Name: CG_name
Description:
Member LUN ID(s): 4, 5
State: Ready

Name: USG-CG_mountpoints
Description:
Member LUN ID(s): 8081,8080
State: Ready


Create a Consistent Snapshot
To snap a Consistent Snapshot, use the command:
[~]$ naviseccli -h SPA snap -create -res CG_Name -name Consistent_Snap

Note: When creating a Consistent Snapshot on a CG that has only SMP
members, all the SMPs must be attached.
Otherwise, the following error is displayed:
[~]$ naviseccli -h SPA snap -create -res CG_Name -name Consistent_Snap
The snapshot of the consistency group cannot be created because some members of the
group are unattached snapshot mount points. Attach all members of the consistency group
and retry the operation. (0x716d8063)

Attach a Consistent Snapshot
CLI does not allow attaching a Consistent Snapshot to multiple SMPs in
one command. It is only possible to attach a Consistent Snapshot to
every SMP one by one.
[~]$ naviseccli -h SPA lun -attach -name SMP1 -snapName Consistent_Snap

[~]$ naviseccli -h SPA lun -attach -name SMP2 -snapName Consistent_Snap

[~]$ naviseccli -h SPA lun -list -showOnly Snap -attachedSnapshot
Name: SMP1
Attached Snapshot: Consistent_Snap

Name: SMP2
Attached Snapshot: Consistent_Snap


SnapCLI
SnapCLI is the utility used on the host to manage snapshots and their
attachments to the SMPs. It does in-band (FC or iSCSI) communication
with the array and thus does not require an IP connection to the Storage
Processor (SP).
SnapCLI is similar to the ADMSNAP utility in SnapView. Both provide the
same level of security in that they can only manage snapshots of LUNs
that they have access to, based on the primary LUNs or existing SMPs
exposed to the host. In other words, the array administrator sets up the
primary LUNs and/or SMPs and puts them in the host storage group and
then the host administrator may use SnapCLI to manage snapshot
creation, destruction, attach and detach for those LUNs only.
Note: To run SnapCLI, run the SnapCLI command from its installation
folder, or modify the PATH to include the SnapCLI path. The default path
in Windows is C:Program FilesEMCUnisphere
SnapCLI

Flush buffers
Like ADMSNAP, SnapCLI must be used to flush disk buffers before
creating or detaching a VNX Snapshot. This is especially important in
Windows environments.
:: Windows
SnapCLI flush -o G:

Create a Snapshot
:: Windows
SnapCLI create -s SnapCLI_snap1 -o .PhysicalDrive1

:: Or address by the drive letter
SnapCLI create -s SnapCLI_snap2 -o G:

Attach a Snapshot
The following command attaches a snapshot to the first SMP available.
When there are many SMPs (that belong to the primary LUN), the first
available SMP is used (usually the one identified as the lower drive, e.g.
.PhysicalDriveX).
:: Windows
SnapCLI attach -s SnapCLI_snap1 -f

Note: When the -f option is supplied, VNX changes the -
allowReadWrite property to "Yes" while the snapshot stays attached.

Copy a Snap
An attached snapshot cannot be copied. Therefore, the request to copy
an attached snapshot will fail.


When a snapshot is not attached, it can be copied. You must specify
both the name of the Snap to be created and the name of the Snap to be
snapped.
:: Windows
SnapCLI copy -s SnapCLI_snap1_copy -b SnapCLI_snap1 -o G:

Consistency Groups
One main difference between SnapCLI and ADMSNAP is the introduction
of Consistency Groups support. When creating VNX Snapshots, you can
specify the name of Consistency Group (CG) along with a list of LUNs. If
the specified CG does not already exist, it is created containing the LUNs
specified as members.
Note: If the specified Consistency Group already exists, the existing
members of the CG are replaced with the LUNs specified as members.
The storage system maintains the CG and member LUNs persistently.
:: Windows

:: Create a Consistent Snapshot, and a Consistency group (if it doesn't exist)
SnapCLI create -s Consistent_Snap -o T:,R: -c CG_name

Sample SnapCLI batch script
Note: SnapCLI does not support storagegroup commands. Therefore, all
necessary SMPs must be provisioned to the hosts before SnapCLI can
mount any snapshots. SMPs are not required for snapshot creation.
:: Windows
@echo off

:: Create one snap
echo "Creating a snapshot for drive M:"
SnapCLI create -s SnapCLI_snap_m -o M:

:: Create a Consistent Snap
:: and a Consistency group (if it doesn't exist)
SnapCLI create -s Consistent_Snap -o T:,R: -c CG_name

:: Attach a single snap
:: (requires 1 mount point already provisioned to the host)
SnapCLI attach -s SnapCLI_snap_m -f

:: Attach a Consistent Snapshot
:: (requires as many mount points as number of LUNs in the CG)
SnapCLI attach -s Consistent_Snap -f


VNX Snapshots vs. SnapView terms
The following table shows the consolidated difference between VNX
Snapshots and SnapView terminology.

VNX Snapshot Definition SnapView
Snapshot Point-in-time copy of a LUN2 Session
Create Take a point-in-time copy of a LUN3 Start
Attach Connect a snapshot to Snapshot Mount Activate
Point
Detach Disconnect from a Snapshot Mount Point Deactivate
Primary LUN LUN4 from which the snapshot is taken Source LUN
Snapshot An object that is exposed to the host Snapshot
Mount Point through a storage group
Restore Change a LUN data to a specific point-in- Rollback
time copy
Delete Delete a snapshot Stop
Copy Create an identical copy of a Snapshot -- N/A --
Consistency Persistent grouping of primary LUNs or -- N/A --
Group Mount Points

2
In here, besides LUNs, VNX Snapshots can be taken on a Consistency Group, or Attached Mount Point
3
Same as above
4
Same as above


Terminology
• Consistency Group—an object that contains a list of primary
LUNs or Snapshot Mount Points (but not both) that are treated as
a single entity for taking snapshots.
• Consistent Snapshot—a point-in-time copy of a Consistency
Group.
• Copy on First Write (COFW)—the technology behind SnapView
Snapshots. After a snapshot is taken, new writes to the primary
LUNs are delayed to enable copying old blocks to the special
reserve LUN within the Reserve LUN Pool.
• Logical Unit Number (LUN)—is the identifying number of a SCSI or
an iSCSI object that processes SCSI commands. The LUN is the
last part of the SCSI address for a SCSI object. The LUN is an ID
for the logical unit, but the term is often used to refer to the
logical unit itself.
• Mount Point, Snapshot Mount Point (SMP)—a virtual LUN-like
container. It is used to "emulate" a typical LUN, but provide the
ability for hosts to write to snapshots and to change snapshots
without changing LUN properties such as WWN, and often
without the need to rescan SCSI bus on the client.
• Redirect on Write (ROW)—the technology behind VNX Snapshots.
After a snapshot is taken, new writes to the primary LUN are
redirected (written) to a new location within a storage pool.
• Storage processor (SP)—a hardware component that provides the
processing resources to perform storage operations such as
creating, managing, and monitoring storage resources.
• Unisphere—a web-based management environment to create
storage resources, configure and schedule protection for stored
data, and manage and monitor other storage operations on VNX
and VNXe systems.


Properties Detailed
Snapshot properties
Every snapshot has the following properties:

Snapshot Description User Value range
property editable?
Name Unique user friendly name. Yes ASCII, all printable
This name can be used to characters (0x20
identify the snapshot in to 0x7E) with no
management commands. The leading or trailing
array will generate a unique spaces.
name if it is not supplied Maximum length:
during the time of snapshot 255
creation.
Description User-created description. Yes ASCII, all printable
characters (0x20
to 0x7E) with no
leading or trailing
spaces.
Maximum length:
255
Creation Time The time when the snapshot Timestamp
was created
Last Modify The time when the snapshot Timestamp or the
Time was last detached from an word "Never"
SMP
Last Modified The field is blank until the ASCII, all printable
By first snapshot is detached. characters (0x20
After it is detached, the field to 0x7E) with no
is updated with the name of leading or trailing
the SMP that the snapshot spaces.
was attached to. Maximum length:
64
Primary LUN Name of the source that is ASCII, all printable
used to create the Snapshot. characters (0x20
to 0x7E) with no
leading or trailing
spaces.
Maximum length:
64
State Object state from the array's • Initializing
point of view. • Ready
• Faulted


Snapshot Description User Value range
property editable?
• Offline
• Destroying
Allow An indicator whether the Yes Yes/No
Read/Write Snapshot may be attached to
an SMP or not. The default
setting is “No”.
Modified An indicator that the Yes/No
snapshot is or had previously
been attached to an SMP.
Source LUNs The SMP that the Snapshot is List
currently attached to.
Allow auto An indicator whether or not Yes Yes/No
delete this Snapshot participates in
auto-delete.
Expiration The date/time that the Yes Timestamp
Date snapshot will get
automatically deleted (Time
of day of destruction may be
approximate). The default is
“Never” expiring.

Snapshot Mount Point properties
Every SMP has the following properties:

SMP property Description User Value range
editable?
Name Unique user friendly name Yes ASCII, all printable
characters (0x20
to 0x7E) with no
leading or trailing
spaces.
Maximum length:
64
LOGICAL UNIT ID of the SMP. The array Yes Shared with all
NUMBER assigns a unique LUN ID to LUN types (starts
the SMP. This can be set in high similar to
the GUI or CLI only at the time SnapView
of creation. Snapshot LUNs)
User Capacity Size of the attached
snapshot. One of:
• Primary LUN size if never
attached


SMP property Description User Value range
editable?
• Current attached
snapshot size
• Last attached size if
unattached.
LUN Type Field indicating that the LUN Snapshot Attach
is VNX SMP LUN
State Details Details about the current ASCII
state, if any
WWN World Wide Name
Current SP that currently owns the SPA, SPB.
Owner LUN
Default SP that owns the LUN by Yes SPA, SPB
Owner default

Auto Assign An indicator if the LUN SPA, SPB
Enabled should participate in auto
assignment
Allocation SP Set by the array (derived from SPA, SPB
the primary LUN)
Auto Delete Indicator whether or not Yes Yes/No
snapshots of this SMP
participate in auto-delete.
The default setting is “Yes”.
Active Set by the array • Expanding
Operation • Shrinking
• Attaching
• Detaching
Attached User-friendly name of the Maximum length:
Snapshot snapshot attached to the 255
SMP.
Statistics Same as traditional LUNs,
DLUs and TLUs
Allow Inband Setting to enable or disable Yes • Enabled
Snap Attach attach from host-based • Disabled
SnapCLI.

Additional pool properties
VNX Snapshots adds the following pool properties:

Pool Description User Value range
property editable?


property editable?
Primary The total amount of storage Total primary
Capacity that is consumed from this capacity
Used pool for data written to all the
primary LUNs in the pool
Snapshot The total amount of storage Total snapshot
Capacity that is consumed from this capacity
Used pool for data written to all the
snapshots in the pool

Metadata The total amount of storage Total overhead
Capacity that is allocated from this capacity
pool to store metadata for
the LUNs and Snapshots in
the pool
Primary The total amount of user data Total primary
Subscribed that can be written to all of subscription
Capacity the LUNs in the pool
Snapshot The total amount of space Total snapshot
Subscribed that all snapshots currently subscription
Capacity consume and what they
would consume if all the
primary LUNs’ data was
overwritten
Metadata The total amount of metadata Total overhead
Subscribed storage that is required to subscription
Capacity support writing to the entire
contents of all the LUNs in
the pool
Auto-Delete Indicator that the system Yes On/Off
Pool Full should check the pool full
Threshold high water mark for auto-
Enabled delete. (Default: TRUE)
Auto-Delete Pool percentage full that will Yes 0.01 - 99% 5
Pool Full High trigger snapshot auto-
Water Mark deletion in the pool. Shown
as a pool percentage full and
also a size for convenience.
(Default: 95%)
Auto-Delete Pool percentage full at which Yes 0 - 98.00% 6

5
GUI only allows whole numbers. CLI will accept decimal places.
6


property editable?
Pool Full Low auto-delete will stop
Water Mark snapshot auto-deletion in the
pool. This value must be less
than the high water mark.
(Default: 85%)
Auto-Delete The state of the pool full • Idle
Pool Full auto-delete process for this • Running
State pool • Could not
Reach LWM
The “Auto-delete Pool Full • System Paused
State” and “Auto-Delete • Failed
Snap Used State” states will
be aggregated into a single
state for reporting using the
GUI. Separate states for each
will be reported via the CLI.
Auto-Delete Indicator that the system Yes On/Off
Snapshot should check the snapshot
Space Used space used high water mark
Threshold for auto-delete. (Default:
Enabled FALSE)
Auto-Delete Total percentage snapshot Yes 0.01 - 99.00% 7
Snapshot space used in the pool that
Space Used will trigger snapshot auto-
High Water deletion in the pool. Shown
Mark as a pool percentage full and
also a size for convenience.
(Default: 25%)
Auto-Delete Total percentage snapshot Yes 0 - 98.00% 8
Snapshot space used in the pool that
Space Used will stop snapshot auto-
Low Water deletion in the pool. This
Mark value must be less than the
high water mark. Shown as a
pool percentage full and also
a size for convenience.
(Default: 20%)
Auto-Delete The state of the Snapshot • Idle
Snap Used Space Used auto-delete • Running
State process for this pool • Could not

7
8


property editable?
Reach LWM
The “Auto-delete Pool Full • System Paused
State” and “Auto-Delete • Failed
Snap Used State” states will
be aggregated into a single
state for reporting using the
GUI. Separate states for each
will be reported using the CLI.


VNX Snapshots

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a VNX Snapshots

Similar a VNX Snapshots (20)

Más de EMC

Más de EMC (20)

Último

Último (20)

VNX Snapshots