SYMMETRIX VMAX

OPERATIONS
 VMAX Operations
This module will cover:
• Overview of Enginuity
• Overview of SYMCLI
• Allocation and of VMAX devices to hosts
using symcli.
• De allocation of VMAX Devices from
hosts using symcli.
 VMAX Operations
Enginuity
• The Symmetrix architecture is built on the sophisticated
Enginuity Operating environment.
• Enginuity is the software component which enables
consistency across generations of hardware, leverages
new technologies, and provides performance and data
integrity.
• An operating environment tied to a time-proven
architecture is an operating environment that has
captured, retained, and built on an existing and proven
code base. In such an operating environment,functions
within the storage system do not have to be redesigned,
unless doing so would benefit users.
 VMAX Operations
Enginuity

• The Enginuity operating environment delivers the

following benefits:
• Continuous availability
• Data integrity
• Built-in security features
• Performance optimization
• Advanced management
• A foundation for powerful functionality
VMAX Operations
Enginuity Layers
 VMAX Operations
At the top of the layers is the host
communication point to the
Symmetrix,
At the bottom are the actual
Symmetrix hardware components,
such as memory and directors.
VMAX Operations
 SYMCLI
What is SYMCLI?
• The EMC® Solutions Enabler SYMCLI is a
specialized library consisting of commands
that can be invoked on the command line, or
within scripts. These commands can be used
to monitor device configuration and status,
and perform control operations on devices
and data objects within your managed
storage complex.
SYMCLI
 VMAX Operations
SYMCLI
• SYMCLI resides on a host system to monitor and perform
control operations on Symmetrix arrays. SYMCLI
commands are invoked from the host operating system
command line (shell). The SYMCLI commands are built on
top of SYMAPI library functions, which use system calls
that generate low-level I/O SCSI commands to the
storage arrays.
• To reduce the number of inquiries from the host to the
storage arrays, configuration and status information is
maintained in a Symmetrix host database file (called the
Symmetrix configuration database; symapi_db.bin by
default).
 SYMCLI
• symcli =Provides the version number of the
installed Symmetrix command line interface.
• symcli –h =Describes how to use the SYMCLI
command.
• symcli -v =Displays the SYMCLI commands and a
brief description of each command.
• symcli -env =Displays a list of the environment
variables that can be set for a SYMCLI session.
• symcli -def =Displays a list of the environment
variables that are set for the current SYMCLI session.
 SYMCLI
• There are a number of different terms to identify and
specify a Symmetrix device using the SYMCLI
commands:
• PdevName or pd — Indicates a physical (host) device
name (e.g. sympd list)
• SymDevName or dev — Indicates a Symmetrix device
name (e.g symdev list)
• LdevName or ld — Indicates a logical device name
(e.g. symld list)
 SYMCLI
• During the very first command line session for a
newly set up Symmerix, or if a configuration change
has occurred, the configuration database must be
built, or rebuilt, with the most complete and current
information for all physical devices connected to your
host. The command for that is:
symcfg discover
 SYMCLI
C:\symcli>
symcfg discover

This operation may take up to a few

minutes. Please be patient...

C:\symcli>
 SYMCLI
• This command scans all SCSI buses, collects
information about all the arrays and devices found,
and rebuilds the database with the collected device
information and parameters from all local and
remotely attached devices. You can limit the
discovery to just Symmetrix arrays by specifying the
-symmetrix option, locally attached CLARiiON
arrays by specifying the -clariion option, only
physical device information by specifying the -pdev
option, or combine some of these commands.
 SYMCLI
• VCMDB: (Volume Control Manager Data Base)
VCMDB Device is the one that holds the information about
the masking entries in the Symmetrix. The VCMDB on
each Symmetrix array holds information about the
devices that a particular host can access through a
specific director. Each director can control access to as
many as 256 unique WWNs or 512 iSCSIs (beginning with
Enginuity version 5771). As many as 128 fiber director
ports, and 64 multi-protocol (iSCSI) ports (depending on
the Symmetrix model) can be configured within the
device masking VCMDB.
 SYMCLI
• Since the release of Enginuity 5771 and DMX-3, the
physical VCM gatekeeper volume no longer contains
the actual device masking database. This information
is stored on the internal Symmetrix File System (SFS)
volumes and the content is only accessible via
syscalls (using any available gatekeeper device).
 SYMCLI
• Use the symcfg verify command to determine if
the host configuration database file is synchronized
with the current configuration of a specific
Symmetrix array.

• To view all the Symmetrix arrays that can be

managed using the management host, run the
following command:
• symcfg list
 SYMCLI
C:\symcli>symcfg -sid 3949 verify

The Symmetrix configuration and the

database file are in sync.
 SYMCLI
C:\symcli>symcfg list

S Y M M E T R I X

Mcode Cache Num Phys Num Symm

SymmID Attachment Model Version Size (MB) Devices Devices

000187430968 Local 1000S-M2 5671 32768 16 1050

000187461439 Local 1000S-M2 5671 32768 16 997
000187700102 Local DMX2000S 5671 36864 12 3984
000187720594 Local DMX2000S 5671 36864 14 3986
000187751432 Local 2000S-M2 5671 65536 14 4146
000190100749 Local DMX3-24 5773 180224 12 13455
000190105011 Local DMX4-24 5773 196608 8 13431
000190105263 Local DMX4-24 5773 196608 14 13669
000192602038 Local VMAX-1 5874 360960 11 15273
000192603917 Local VMAX-1 5875 120320 12 4047
000192603949 Local VMAX-1 5875 120320 10 3763
 SYMCLI
• The symcfg list -status command provides a
list of all arrays connected to your host, whether the
configuration has changed, and if the array was
discovered during the last discovery operation.
 SYMCLI
C:\symcli>symcfg list -status

S Y M M E T R I X

Mcode
SymmID Attachment Model Version Config Changed Discovered

000187430968 Local 1000S-M2 5671 No Yes

000187461439 Local 1000S-M2 5671 No Yes
000187700102 Local DMX2000S 5671 No Yes
000187720594 Local DMX2000S 5671 No Yes
000187751432 Local 2000S-M2 5671 No Yes
000190100749 Local DMX3-24 5773 No Yes
000190105011 Local DMX4-24 5773 No Yes
000190105263 Local DMX4-24 5773 No Yes
000192602038 Local VMAX-1 5874 No Yes
000192603917 Local VMAX-1 5875 No Yes
000192603949 Local VMAX-1 5875 No Yes
 SYMCLI
• The SYMCLI configuration change command,
symconfigure, is used to perform control
operations on Symmetrix arrays and the array
devices and ports. Some of the Symmetrix array
controls include setting array-wide metrics, and
determining what type of devices the array will
support, such as RAID 6 devices. Device controls
include creating devices, mapping devices, and
configuring device pools. The symconfigure
command is also used for reserving devices and
releasing device reservations.
 SYMCLI
• Solutions Enabler 7.0 and later, running on the
Symmetrix V-Max™ Series with Enginuity™ handles
configuration changes differently from previous
versions of Solutions Enabler. It allows Concurrent
Provisioning, or running more than one set of
symconfigure commands as long as certain
conditions are fulfilled.
 SYMCLI
• Up to four concurrent configuration change sessions
are allowed to run at the same time (VMAX ONLY),
when they are non-conflicting. This means that
multiple parallel configuration change sessions can
run at the same time as long as the changes do not
include any conflicts on the following:
• Device back-end port
• Device front-end port
• Device
 SYMCLI
• Devices and meta devices can be created and
mapped in one command. This eliminates the need
to perform multiple configuration changes when
provisioning new storage.
• The Symmetrix array manages its own less restrictive
device locking.
• A session ID identifies each running session on the
array.
 SYMCLI
• A session acting on a specified symconfigure
command file can be verified and checked using the
preview and prepare arguments. The commit
argument performs these same checks, but then
attempts to execute the specified action. Next we
will see a brief overview of what these arguments
constitute.
 SYMCLI
• Preview
• The preview argument verifies the syntax and
correctness of each individual change defined, their
correctness as a set, and then terminates the session
without change execution (correct within the realm
of the host and valid as a possible Symmetrix
configuration).
 SYMCLI
• Prepare: The prepare argument performs the
preview checks, validates the change operation
(devices are in correct state, etc.), and also verifies
the appropriateness of the resulting configuration
definition against the current state of the Symmetrix
arrays; the argument then terminates the session
without attempting to make the configuration
change. For Symmetrix V-Max arrays running
Enginuity 5874, the prepare argument performs the
same actions as the preview argument.
 VMAX Operations
SYMCLI
• Commit: The commit argument completes all checks
and verifications, and then attempts to make the
requested configuration changes in the specified
Symmetrix array. The attached file shows an example
of creating RAID 1 Devices.
 SYMCLI
We will first take a quick look at the way allocations are
done in DMX and then look at VMAX equivalent of
the same.
The following steps are included in DMX Allocation.
• Identify next available channel address for each
front-end port.
• Map devices to each front-end port.
• For each initiator to front-end port connection,
create a masking entry.
•
 SYMCLI
With the Symmetrix DMX, devices first map to front-
end director ports, and then multiple masking
entries are created defining each port-initiator-
device(s) relationship.
These one-to-one relationships allow fine granularity of
control by defining specific connections between
HBA and director ports, but can be cumbersome as
the number of HBAs and servers increase.
 SYMCLI
• Mapping and Masking:
• Mapping connects the devices with the specified
Front End Directors.

• Masking enables the mapped devices to be visible to

the host.
• Masking without mapping or Mapping devices
without masking will create issues as devices will not
be visible correctly to the hosts.
 SYMCLI
• Verify physical and logical connectivity and zoning by
querying the login table to determine if all HBAs on
all servers have performed port logins (PLOGI) to the
appropriate front-end ports. The following is an
example of a command that would verify if port
logins have occurred, indicating correct zoning and
connectivity.
symmask -sid 056 list logins –wwn <HBA_WWN>
 SYMCLI
• Once the logins are confirmed, rename the entries as
shown below:
• symmask -sid 056 -wwn 10000000c9752325
rename server1
• symmask -sid 056 -wwn 10000000c9752326
–rename server1
 SYMCLI

• If the devices are not currently mapped, they must

be mapped using an available channel address. The
following is an example of the commands that would
identify available channel addresses.
symcfg -sid 56 -dir 7B -p 1 list -address –
available
symcfg -sid 56 -dir 10B -p 1 list -address –
available
 SYMCLI
• Map the devices to the front-end director ports. The
following is an example of the commands that would
map the devices to the front-end ports using the
next available channel address identified in the
previous step. Create a file called map.txt and enter
the following lines into it:

map dev 30 to dir 7B:0 LUN=20;

map dev 30 to dir 7B:0 LUN=20;
 SYMCLI
Run the following commands:
symconfigure –sid 56 –f map.txt –v
preview
symconfigure –sid 56 –f map.txt –v
prepare

symconfigure –sid 56 –f map.txt –v commit

 SYMCLI
Run the following commands to complete the masking.

• symmask -sid 056 add dev 30:39 -wwn

10000000c9752325 -dir 7B -p 1
• symmask -sid 056 add dev 30:39 -wwn
10000000c9752326 -dir 10B -p 1
• Symmask –sid 056 refresh
 SYMCLI
Check the mapping/masking by running the following
commands:

• symmaskdb –sid 056 list capacity –host

server1
• symmaskdb –sid 056 list assign –devs
030
Symmetrix VMAX approach to storage
provisioning
On the Symmetrix VMAX with Enginuity 5874, Auto
provisioning Groups are now the exclusive
mechanism for storage provisioning.

Auto-provisioning is implemented using the

symaccess CLI command with Solutions Enabler 7.0
(and later versions) or using Symmetrix Management
Console.
Symmetrix VMAX approach to storage
provisioning
With Auto-provisioning Groups, related initiators
(HBAs) are grouped into an initiator group, related
front-end ports are grouped into a port group, and
related devices are grouped into a storage group.
A masking view associates the groups together. At
the time the masking view is created, all the
required mapping and masking are performed
automatically in a single operation. This approach
dramatically reduces complexity and simplifies
storage allocation.
 Auto-provisioning Groups concepts
The fundamental concept of Auto-provisioning Groups is
the logical grouping of related objects and the creation of
a view that associates the related groups together. The
following are definitions for these objects.
An initiator group is a logical grouping of up to 32 Fibre
Channel initiators or eight iSCSI names or a combination
of both. An initiator group may also contain the name of
another initiator group to allow the groups to be
cascaded to a depth of one (Cascaded Initiator Group)
A port group is a logical grouping of Fibre Channel and/or
iSCSI front-end director ports. The only limit on the
number of ports in a port group is the number of ports in
the Symmetrix VMAX
 Auto-provisioning Groups concepts

• A storage group is a logical grouping of up to 4,096

Symmetrix devices. LUN addresses are assigned to the
devices in the storage group when the masking view is
created using the dynamic LUN addressing feature.

• A masking view defines an association between one

initiator group, one port group, and one storage groups.
When a masking view is created, the devices in the
storage group are mapped to the ports in the port group
and masked to the initiators in the initiator group.
VMAX Operations
SYMCLI
 VMAX Operations
SYMCLI

We will now look at how Storage

Allocation is done in VMAX
 VMAX Operations
Storage allocation
• Creating storage groups
• You can create a storage group using a range of devices, a
list of devices, a device group, or a device file. The
symaccess syntax for creating a storage group is:
• symaccess -sid SymmID create -name
GroupName -type storage [devs
SymDevStart:SymDevEnd
|SymDevName[,SymDevName[,SymDevName...]]
|<-g DgName [-std] [-bcv] [-vdev] [-tgt]>
| <-file DeviceFileName [src] [tgt]> [-
reserve_id ResvID[,ResvID[,ResvID...]]]]
 VMAX Operations
Storage allocation
• In the following example, a range of devices
containing storage are put into a newly created
storage group named SG_1:
• symaccess create -sid 458 -name SG_1 -
type storage devs 050:055
 VMAX Operations
Storage allocation
• Storage/Port/Initiator group names can be up to 64
characters, and are not case sensitive. Group names
must be unique per group type, but different group
types can share the same name. For example, a
storage group, a port group, and an initiator group
can all have the name Financial_DB. However, two
storage groups cannot be named Financial_DB.
 VMAX Operations
Storage allocation
• Creating port groups
• Port groups may contain any number of valid front-
end ports. A port can belong to more than one port
group.
• Only Fibre and Gig-E ports on front-end directors will
be allowed to be added to a port group. Port groups
can have mixed port types. Ports must have the ACLX
flag enabled to be added to a port group.
 VMAX Operations
Storage allocation
• Syntax for creating a port group is:
• symaccess -sid SymmID create -name GroupName
-type port [-dirport Dir:Port[,Dir:Port...]]

• In the following example, a new port group, PG_1 is created

containing three front-end ports:
• symaccess create -sid 458 -name PG_1 -type
port -dirport 7E:0,7G:1,8F:0
 VMAX Operations
Storage allocation
• Creating initiator groups
• An initiator group is a container of one or more host
initiators (Fibre or iSCSI). Each initiator group can
contain up to 32 entries. An initiator group may also
include the name of another initiator group to allow
the groups to be cascaded to a depth of one. An HBA
may only belong to one group, but may have
masking views for both an upper and lower group if
cascaded.
 VMAX Operations
Storage allocation
• You can create an initiator group using the HBA’s
WWN, iSCSI, a file containing WWNs or iSCSI names,
or another initiator group name. The symaccess
syntax for creating an initiator group is:
• symaccess -sid SymmID create -name GroupName
-type initiator [ -wwn wwn | -iscsi iscsi | -
file InitiatorFilename | -ig
InitiatorGroupName ] [-consistent_lun]
 VMAX Operations
Storage allocation
• Use the -consistent_lun option if the devices of a
storage group (in a view) need to be seen on the
same LUN ID on all ports of the port group. If the -
consistent_lun option is set on the initiator group,
Solutions Enabler will make sure that the LUN
number assigned to devices is the same for the
ports.
• If this is not set, then the first available LUN on each
individual port will be chosen.
 VMAX Operations
Storage allocation
• In the following example, an initiator group, IG_1 is
created containing one WWN:
• symaccess create -sid 458 -name IG_1 -
type initiator -file IG_1
• Where the file IG_1 contains:
wwn:210000e08b04daac
 VMAX Operations
Storage allocation
Another way to create Initiator Group is:
symaccess -sid 458 create -name IG_1 -
type initiator –consistent_lun

symaccess -sid 458 -name IG_1 -type

initiator add –wwn 10000000c9abcded
symaccess -sid 458 -name IG_1 -type
initiator add –wwn 10000000c9abcdef
 VMAX Operations
Storage allocation
• Cascaded initiator groups
• An initiator group (Child) can be added to another
initiator group (Parent), only if the Child Group does not
contain any initiator groups.
• The following scenario describes cascaded initiator
groups:
HOST1 contains WWN1 & WWN2, which are added to IG_1.
HOST2 contains WWN3 & WWN4, which are added to IG_2.
IG_3 is created and contains IG_1 & IG_2.
 VMAX Operations
Storage allocation
Commands to create the cascaded Initiator Group:
symaccess -sid 458 create -name IG_3 -
type initiator -file IG_1

symaccess -sid 458 add -name IG_3 -type

initiator -file IG_2
 VMAX Operations
Storage allocation
Command to check the groups to ensure correct
devices/ports/initiators are added.
symaccess -sid 458 –type storage show
SG_1

symaccess -sid 458 –type port show PG_1

symaccess -sid 458 –type initiator show

IG_1
 VMAX Operations
Storage allocation
• Creating a masking view
• A masking view is a container of a storage group, a
port group, and an initiator group. When you create
a masking view, the devices in the storage group
become visible to the host. The devices are masked
and mapped automatically.
 VMAX Operations
Storage allocation
Syntax for creating a masking view is:
create view -sid SymmID -name ViewName -sg
StorageGroupName -pg PortGroupName -ig
InitiatorGroupName [ < [-reserve_id
ResvID[,ResvID[,ResvID...]]] [-lun Addr]
[-emulation <ckd | celerra>
• In the following example, a masking view, MV_1, is
created containing the previously-created storage group,
port group, and initiator group:
symaccess -sid 458 create view -name MV_1 -
sg SG_1 -pg PG_1 -ig IG_1
 VMAX Operations
Storage allocation
• Ease of managing the groups:
• Biggest advantage of this method is the way the
devices/ports/initiators can be added. For
example,to add devices 089, 090, and 091 to storage
group SG_Prod on Symmetrix array 458, issuing the
following command is sufficient.
symaccess -sid 458 -name SG_Prod -type storage
add devs 089,090,091
In DMX, the devices would be added only after mapping and
masking.
 VMAX Operations
Storage allocation
Similarly, to add ports to a port group becomes much
easier.
• To add port 1 of Fibre director 16D to the existing
port group PG_1 on Symmetrix 245,
symaccess -sid 245 -name PG_1 -type port add -
dirport 16D:1
In a DMX, first we would need to ensure that the LUN IDs being
used by the devices to which this director will be masked and
mapped with are available.
 VMAX Operations
Storage allocation
Same goes for Initiator Groups. To add initiator -wwn
10000000c94ef69c to the initiator group IG_1 on
Symmetrix 245, enter:
symaccess -sid 245 -name IG_1 add -type
initiator -wwn 10000000c94ef69c
 VMAX Operations
Storage allocation
• When using an input file, each initiator must be placed on a
new line and start with either WWN: or iSCSI: or 'IG:,
depending on the type of the initiator or initiator group
name. The following is an example of the format for an
initiator file:
• WWN:10000000c94ef69c
• iSCSI:iscsiname
• IG:IgName
• #WWN:10000000c94ef69d
 VMAX Operations
Renaming
• Renaming:
• Use the rename -new_name command to rename a storage
group, port group, or an initiator group, using the following
form:
symaccess -sid SymmID rename -name GroupName -
type <storage | port | initiator> -new_name
NewGroupName
• Use the rename view -new_name command to rename a
masking view, using the following form:
• symaccess -sid SymmID rename view -name
ViewName -new_name NewViewName
 VMAX Operations
SYMCLI
This completes the Storage
Allocation steps.
We will now look at how
Storage De allocation
is done in VMAX.
 VMAX Operations
Storage Deallocation
Storage de allocation is done in a reverse way of allocation if it’s a full
decommission. If only some devices are to be removed, then that
will be covered in Device Removal in the coming slides.

• Deleting masking views

• When a masking view is deleted, all the groups contained in the
masking view will remain intact. Any device reservations will
continue to be enforced when a masking view is deleted.
• To delete a masking view, use the following form:
symaccess -sid SymmID delete view -name ViewName
• For example, to delete masking view MV_1, on Symmetrix 458,
enter:
symaccess -sid 458 delete view -name mv_1
 VMAX Operations
Storage Deallocation
• Removing devices
• A storage group should not be deleted until all the devices
have been removed. It’s best to use the unmap option during
removing the device(s) from the storage group as that will
unmap devices in the background. No need for creating
unmapping script as required in DMX.
• Note: A storage group cannot be completely emptied if it is
associated with a masking view.
Example:
• symaccess -sid 458 -name SG_1 -type storage
remove devs 050,52,54 -unmap
 VMAX Operations
Storage Deallocation
• Deleting storage groups
• A storage group should be empty before being deleted, unless
using the –force option.
• Note: A storage group cannot be deleted if it is associated
with a masking view.
• delete <view -name ViewName [-unmap] > |< -
name GroupName –type <storage | port |
initiator> [-force] > [-noprompt]
• For example, to delete storage group SG_1 on Symmetrix 458.
• symaccess -sid 458 -name sg_1 -type storage
delete
 VMAX Operations
Storage Deallocation
• Removing ports:
• Note: A port group cannot be completely emptied if it is
associated with a masking view.
• Syntax for removing ports:
• symaccess -sid SymmID -name GroupName -type port
-dirport Dir:Port[,Dir:Port[,Dir:Port...]][-
emulation ckd][-unmap] remove [-unmap [-emulation
celerra]]
• To remove port 1 of Fibre director 16D from the existing port group
PG_1 on Symmetrix 245, enter:
• symaccess -sid 245 -name PG_1 -type port remove -
dirport 16D:1
 VMAX Operations
Storage Deallocation
• Deleting port groups:
• To delete a port group, use the following syntax:
delete <view -name ViewName> [-force] |-name
GroupName -type <storage | port | initiator >
[-noprompt]
• Note: A port group cannot be deleted if it is associated with a
masking view.
• To delete port group PG_1 on Symmetrix 245, enter:
symaccess -sid -name PG_1 -type port delete
 VMAX Operations
Storage Deallocation
• Removing initiators:
The symaccess remove command removes specified initiators from an
initiator group. An initiator group that is currently associated with a
masking view will be allowed to be emptied and the view will remain
along with the other two groups.
The following is the syntax for removing an initiator from an initiator group:
• symaccess -sid SymmID -name GroupName -type initiator -
wwn wwn | -iscsi iscsi | -ig InitiatorGroupName| -f
InitiatorFilename [-login] remove
• For example, to remove initiator -wwn 10000000c94ef69c from the
initiator group IG_1 on Symmetrix 245, enter:
• symaccess -sid 245 -name IG_1 remove -type initiator –
wwn 10000000c94ef69c -login
• Add the -login option to the command to remove the initiator from the
Symmetrix
• array’s login history table.
 VMAX Operations
Storage Deallocation
• Deleting initiator groups
To delete an initiator group, use the following syntax:
delete <view -name ViewName> [-force] |-name
GroupName -type <storage | port | initiator >
[-noprompt]

To delete initiator group IG_1 on Symmetrix 245, enter:

• symaccess -sid -name IG_1 -type initiator
delete
• Note: An initiator group cannot be deleted if it is associated
with a masking view.
 VMAX Operations
SYMCLI
This completes the
Storage De Allocation steps in
VMAX.
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations
Viewing information
 VMAX Operations

This completes the VMAX Operations Training.