Storage Provisioning With EMC Symmetrix Autoprovisioning Groups

Storage Provisioning
with EMC® Symmetrix®

Autoprovisioning Groups
Technical Notes
P/N 300-009-148
REV A02
May 25, 2010
These technical notes contain information on the following topics:
Executive summary ............................................................................................................................3

Introduction .........................................................................................................................................3
Audience ......................................................................................................................................................... 3
Conventions used in this document ........................................................................................................... 4
Provisioning storage using Solution Enabler ...............................................................................4
Presenting storage to a SYMAPI control host............................................................................................ 4
Steps for provisioning storage ................................................................................................................ 5
Example of provisioning storage ............................................................................................................ 5
Presenting storage to a production and a backup host ............................................................................ 8
Steps for provisioning storage ................................................................................................................ 8
Example of provisioning storage ............................................................................................................ 9
Adding existing storage, ports, or initiators to an existing view ..................................................... 16
Example of adding storage to an existing storage group .................................................................. 16
Presenting storage to a cluster ................................................................................................................... 20
Steps for provisioning storage by using a cascaded initiator group ............................................... 21
Example of using a cascaded initiator group...................................................................................... 22
Removing a masking view and its associated groups ............................................................................ 30
Example of deleting a masking view and associated groups ........................................................... 31
Specifying LUN addresses ......................................................................................................................... 33
Specifying HBA flags .................................................................................................................................. 41
Overriding port flags .................................................................................................................................. 45
Insuring consistent LUNs across initiators .............................................................................................. 50
Provisioning storage using SMC ...................................................................................................52
Presenting storage to a SYMAPI control host.......................................................................................... 52
1
Storage Provisioning With EMC Symmetrix Autoprovisioning Groups
Steps for provisioning storage ............................................................................................................... 52

Example of provisioning storage .......................................................................................................... 53
Presenting storage to a production and a backup host ........................................................................... 61
Steps for provisioning storage ............................................................................................................... 61
Example of provisioning storage .......................................................................................................... 62
Adding existing storage, ports, or initiators to an existing view ...................................................... 76
Example of adding storage to an existing storage group .................................................................. 76
Presenting storage to a cluster.................................................................................................................... 80
Steps for provisioning storage using a cascaded initiator group ..................................................... 81
Example of using a cascaded initiator group ...................................................................................... 82
Removing a masking view and its associated groups ............................................................................ 92
Example of deleting a masking view and associated groups............................................................ 93
Specifying LUN addresses .......................................................................................................................... 97
Specifying HBA flags................................................................................................................................. 100
Overriding port flags ................................................................................................................................. 107
Insuring consistent LUNs across initiators ............................................................................................. 112
Conclusion ....................................................................................................................................... 113
2 Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes

Executive summary
Introduced in EMC® Solutions Enabler and EMC Symmetrix®
Management Console (SMC) version 7.0, the Autoprovisioning Groups
feature provides an easier, faster way to provision storage in EMC
Symmetrix VMAX™ arrays running EMC Enginuity™ 5874. Most of the
applications running on Symmetrix arrays require a fault-tolerant
environment with clustered hosts as well as multiple paths to devices.
Autoprovisioning Groups was developed to make storage allocation
easier and faster, especially with these types of configurations.
Mapping and masking devices in previous versions of Solutions Enabler
required a separate command for each initiator/port combination
through which devices would be accessed. Both the symaccess
command in Solutions Enabler and SMC allow the user to create a group
of devices (storage group), a group of director ports (port group), and a
group of host initiators (initiator group), and associate them in a
masking view. When the masking view is created, the devices are
automatically mapped and masked.
After the masking view is created, any objects (devices, ports, or
initiators) added to an existing group automatically become part of the
associated masking view. This means that no additional steps are
necessary to add additional devices, ports, or initiators to an existing
configuration. All necessary operations to make them part of the
configuration are handled automatically by Symmetrix Enginuity once
the objects are added to the applicable group. This reduces the number
of commands needed for mapping and masking devices and allows for
easier storage allocation and de-allocation.
Introduction
These technical notes describe how to provision storage by using the
Symmetrix Autoprovisioning Groups feature. The goals of this paper
are:
To summarize the functionality of the feature
To provide examples showing how to use Autoprovisioning Groups
to provision storage
Audience
This document is intended for use by the technology professional who
works in an environment with Symmetrix VMAX disk arrays. It is
Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes 3

specifically targeted at EMC field technical staff and EMC customers

who need to understand how to provision storage to hosts attached to a
VMAX disk array.
Conventions used in this document

An ellipsis (...) appearing on a line by itself indicates that unnecessary
command output has been removed.
Command syntax, output, and examples appear in the
Courier New font.
An asterisk (*) appearing in command output indicates that unnecessary
command output has been removed from within a line.
Provisioning storage using Solution Enabler

Several use cases will be presented that illustrate various ways that
Autoprovisioning Groups can be used to provide access to Symmetrix
volumes using Solutions Enabler.
Note: The use case examples were developed by using the same hosts,
therefore the initiator WWNs are the same in all of the use cases. A WWN can
only belong to a single initiator group; however, initiator groups can be
cascaded by placing them in other initiator groups.
Presenting storage to a SYMAPI control host

In the first example, gatekeepers need to be provisioned to a
management host that will be monitoring and managing the Symmetrix
using Solutions Enabler. Best practice for assigning gatekeepers to hosts
specifies that gatekeeper device be assigned on only a single front-end
path.

Figure 1 Creating individual paths to gatekeepers
Steps for provisioning storage

In a simple configuration it is possible to create a masking view for a
single initiator on a single port with any number of devices using just
one symaccess command.
The following are the general steps that can be followed to accomplish
this goal:
1. Create a view and specify a view name, HBA WWN, front-end port,
and Symmetrix volumes for the first path.
2. Create a view and specify a view name, HBA WWN, front-end port,
and Symmetrix volumes for the second path.
Once the masking view has been created, the devices are available to the
initiators on the storage ports. Host-specific commands can then be run
to configure the devices to the operating system.
Example of provisioning storage

Step 1 - Create a view and specify a view name, HBA WWN, front-end
port, and Symmetrix volumes for the first path. When using this method,
the view is given a name by the user and that name is used for the
initiator, port, and storage groups.
The symaccess list hba command can be used to print the HBA
WWNs and the ports that they are zoned to:
# symaccess list hba

Identifier Physical Device Path Symmetrix ID Dir:P

---------------- -------------------------------- ------------ -----
10000000c9767816 c3t5000097208139918d0s2 000192601254 07E:0
10000000c9767817 c4t5000097208139959d0s2 000192601254 07F:1
Gatekeepers 08F – 092 will be made available on the first path:
# symaccess create view -name mgmtGKpath0 -wwn 10000000c9767816 -dirport 7E:0

devs 08F:092 -sid 54
Step 2 - Create a view and specify a view name, HBA WWN, front-end
port, and Symmetrix volumes for the second path.
Gatekeepers 093 – 096 will be made available on the second path:
# symaccess create view -name mgmtGKpath1 -wwn 10000000c9767817 -dirport 7F:1

devs 093:096 -sid 54
The devices are now available to the initiators on the storage ports. After
the host configures the devices, they are available to the operating
system on both paths:
# symaccess list view -sid 54
Symmetrix ID : 000192601254
Masking View Name Initiator Group Port Group Storage Group

------------------- ------------------- ------------------- -----------------
mgmtGKpath0 mgmtGKpath0 mgmtGKpath0 mgmtGKpath0
mgmtGKpath1 mgmtGKpath1 mgmtGKpath1 mgmtGKpath1
# syminq
Device Product Device

---------------------------- -------------------------- ---------------------
Name Type Vendor ID Rev Ser Num Cap (KB)
---------------------------- -------------------------- ---------------------
/dev/rdsk/c3t50*8d0s2 GK EMC SYMMETRIX 5874 5400054000 5760
/dev/rdsk/c3t50*8d1s2 GK EMC SYMMETRIX 5874 540008F000 5760
# symcfg discover
This operation may take up to a few minutes. Please be patient...

# symaccess show view mgmtGKpath0 -sid 54
Masking View Name : mgmtGKpath0

Initiator Group Name : mgmtGKpath0
Host Initiators
{
WWN : 10000000c9767816
}
Port Group Name : mgmtGKpath0
Director Identification
{
FA-7E:0
}
Storage Group Name : mgmtGKpath0
Sym Dev Host

Name Dir:P Physical Device Name Lun Attr Cap(MB)
------ ----- ----------------------- ---- ---- -------
008F 07E:0 c3t5000097208139918d1s* 1 5
0090 07E:0 c3t5000097208139918d2s* 2 5
0091 07E:0 c3t5000097208139918d3s* 3 5
0092 07E:0 c3t5000097208139918d4s* 4 5
# symaccess show view mgmtGKpath1 -sid 54
Masking View Name : mgmtGKpath1

Initiator Group Name : mgmtGKpath1
Host Initiators
{
WWN : 10000000c9767817
}
Port Group Name : mgmtGKpath1
{
FA-7F:1
}
Storage Group Name : mgmtGKpath1
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
0093 07F:1 c4t5000097208139959d1s* 1 5
0094 07F:1 c4t5000097208139959d2s* 2 5
0095 07F:1 c4t5000097208139959d3s* 3 5
0096 07F:1 c4t5000097208139959d4s* 4 5

Additional elements such as initiators, ports, or volumes can be added,

as needed, to the groups that are created by the command.
Note: Running symcfg discover is not required; however, the Physical

Device Name field in symaccess show view will display the devices as
“Not Visible” until they are configured by the host and symcfg discover
is run.
Presenting storage to a production and a backup host

This use case shows a simplified configuration in which the storage
administrator needs to provision storage to two newly attached hosts. In
this example, one of the machines is a production database server and
the other is a database backup server that will access clones of the
production volumes. Each host will access its own set of devices through
two HBAs zoned to the VMAX array on the same FA ports.
Figure 2 Storage presented to a production and a backup host

To make the storage available to the appropriate host, the storage
groups, port group, and initiator groups must be created. The applicable
groups must then be combined into a masking view for each host, which
will do the mapping and masking so that the storage is accessible.
In this example a Symmetrix device group will be created and will be
used to provide the device lists for the storage groups.

this goal:
1. Create a Symmetrix device group that contains the production
volumes and the clone target volumes.
2. Create the production storage group that contains the production
volumes.
3. Create the backup storage group that contains the clone target
volumes.
4. Create the port group.
5. Create the production server initiator group.
6. Create the backup server initiator group.
7. Create the production server masking view containing the
production storage group, port group, and production initiator
group.
8. Create the backup server masking view containing the backup
storage group, port group, and backup initiator group.

Step 1 - Create a Symmetrix device group, add the production volumes,
and add the clone target volumes:
# symdg create proddb_dg

# symld -g proddb_dg addall dev -range 798:79B -sid 54
# symld -g proddb_dg addall dev -range 912:915 –tgt
The device group now contains the standard volumes (STD) for the
production host and the target volumes (TGT) for the backup host:
# symdg show proddb_dg
Group Name: proddb_dg
Group Type : REGULAR

Device Group in GNS : No
Valid : Yes
Group Creation Time : Fri Jan 30 16:06:03 2009
Vendor ID : EMC Corp
Application ID : SYMCLI

Number of STD Devices in Group : 4

Number of Associated GK's : 0
Number of Locally-associated BCV's : 0
Number of Locally-associated VDEV's : 0
Number of Locally-associated TGT's : 4
Number of Remotely-associated VDEV's(STD RDF): 0
Number of Remotely-associated BCV's (STD RDF): 0
Number of Remotely-associated TGT's(TGT RDF) : 0
Number of Remotely-associated BCV's (BCV RDF): 0
Number of Remotely-assoc'd RBCV's (RBCV RDF) : 0
Number of Remotely-assoc'd BCV's (Hop-2 BCV) : 0
Number of Remotely-assoc'd VDEV's(Hop-2 VDEV): 0
Number of Remotely-assoc'd TGT's (Hop-2 TGT) : 0
Standard (STD) Devices (4):

{
--------------------------------------------------------------------
Sym Cap
LdevName PdevName Dev Att. Sts (MB)
--------------------------------------------------------------------
DEV001 N/A 0798 RW 4314
DEV002 N/A 0799 RW 4314
DEV003 N/A 079A RW 4314
DEV004 N/A 079B RW 4314
}
TGT Devices Locally-associated (4):

{
--------------------------------------------------------------------
Sym Cap
--------------------------------------------------------------------
TGT001 N/A 0912 RW 4314
TGT002 N/A 0913 RW 4314
TGT003 N/A 0914 RW 4314
TGT004 N/A 0915 RW 4314
}
Step 2 - Create the production storage group that contains the

production volumes. For this step, the device group will be used to
provide the device list for the symaccess command. The standard
devices will be added to the group by default:
# symaccess create -name dbprod_stor -type storage -g proddb_dg -sid 54
Groups that have been created can be viewed using symaccess list
and symaccess show commands:
# symaccess list -type storage -name dbprod_stor -sid 54 -v
Storage Group Name : dbprod_stor

Device Count : 4
Masking View Count : 0
Last updated at : 09:47:30 PM on Fri Jan 30,2009
# symaccess show dbprod_stor -type storage -sid 54
Devices : 0798:079B
Masking View Names

{
None
}
Step 3 - Create the backup storage group that contains the clone target
volumes. For this step, the device group will be used with the –tgt flag
to add the target devices:
# symaccess create -name dbbackup_stor -type storage -g proddb_dg -tgt -sid 54
# symaccess show dbbackup_stor -type storage -sid 54
Storage Group Name : dbbackup_stor
Devices : 0912:0915
Masking View Names

{
None
}
Step 4 – Create the port group containing the two Symmetrix ports to
which the HBAs are zoned:
# symaccess create -name dbsrv_port -type port -dirport 7E:0,7F:1 -sid 54
# symaccess show dbsrv_port -type port -sid 54
Last updated at : 04:09:19 PM on Mon Feb 02,2009
Port Group Name : dbsrv_port
{

FA-7E:0
FA-7F:1
}
Masking View Names

{
None
}
The –detail option can also be used with symaccess list to generate
output with the port and view counts in columns:
# symaccess list -type port -name dbsrv_port -sid 54 -detail
Port View
Port Group Name Count Count
-------------------------------- ----- -----
dbsrv_port 2 0
Step 5 – Create the production server initiator group. In this example,

the HBA WWNs are entered by using a file. They can also be entered
manually on the command line.
Each WWN in the file must contain the string “WWN:” followed by the
16-digit WWN. It cannot contain blank spaces or empty lines:
# cat /prod_WWN_file
WWN:10000000c9767816
WWN:10000000c9767817
# symaccess create -name dbprodsrv_init -type initiator -file /prod_WWN_file

-sid 54
# symaccess show dbprodsrv_init -type initiator -sid 54
Initiator Group Name : dbprodsrv_init
Host Initiators
{
WWN :10000000c9767816
WWN :10000000c9767817
}
Masking View Names

{
None
}

Parent Initiator Groups

{
None
}
Step 6 – Create the backup server initiator group:
# symaccess create -name dbbackupsrv_init -type initiator -file

/backup_WWN_file -sid 54
# symaccess show dbbackupsrv_init -type initiator -sid 54
Initiator Group Name : dbbackupsrv_init
Host Initiators
{
WWN :10000000c97683e0
WWN :10000000c97683e1
}
Masking View Names

{
None
}

{
None
}
Step 7 – Create the production server masking view containing the

production storage group, port group, and production initiator group.
Once the masking view command completes and the prompt returns, the
devices will be mapped and masked and available to the production
host:
# symaccess create view -name dbprodsrv_view -storgrp dbprod_stor -portgrp

dbsrv_port –initgrp dbprodsrv_init –sid 54
The production masking view has now been created. Both symaccess
list and symaccess show display the view along with its associated
initiator group, port group, and storage group:
# symaccess list view -name dbprodsrv_view -sid 54

------------------- ------------------- ------------------- ------------------

dbprodsrv_view dbprodsrv_init dbsrv_port dbprod_stor
# symaccess show view dbprodsrv_view -sid 54
Masking View Name : dbprodsrv_view

Host Initiators
{
WWN : 10000000c9767816
WWN : 10000000c9767817
}
{
FA-7E:0
FA-7F:1
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
0798 07E:0 Not Visible 1 4314
07F:1 Not Visible 1 4314
0799 07E:0 Not Visible 2 4314
079A 07E:0 Not Visible 3 4314
079B 07E:0 Not Visible 4 4314
After running the host-specific commands to configure new devices, the

Symmetrix volumes in the storage group are available to the host:
# syminq

---------------------------- -------------------------- ---------------------
---------------------------- -------------------------- ---------------------
/dev/rdsk/c3t50*8d1s2 EMC SYMMETRIX 5874 5400798000 4417920
/dev/rdsk/c3t50*8d3s2 EMC SYMMETRIX 5874 540079A000 4417920
/dev/rdsk/c3t50*8d4s2 EMC SYMMETRIX 5874 540079B000 4417920


Step 8 – Create the backup server masking view that contains the backup
storage group, port group, and backup initiator group:
# symaccess create view -name dbbackupsrv_view -storgrp dbbackup_stor -portgrp

dbsrv_port –initgrp dbbackupsrv_init –sid 54
The backup masking view has now been created. Both symaccess list
and symaccess show display the view along with its associated initiator
group, port group, and storage group:
# symaccess list view -name dbbackupsrv_view -sid 54

------------------- ------------------- ------------------- ------------------
dbbackupsrv_view dbbackupsrv_init dbsrv_port dbbackup_stor
# symaccess show view dbbackupsrv_view -sid 54
Masking View Name : dbbackupsrv_view

Host Initiators
{
WWN : 10000000c97683e0
WWN : 10000000c97683e1
}
{
FA-7E:0
FA-7F:1
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
0912 07E:0 Not Visible 1 4314
0913 07E:0 Not Visible 2 4314
0914 07E:0 Not Visible 3 4314
0915 07E:0 Not Visible 4 4314


Symmetrix volumes in the storage group are available to the host:
# syminq

---------------------------- -------------------------- ---------------------
---------------------------- -------------------------- ---------------------
Adding existing storage, ports, or initiators to an existing view

Adding additional Symmetrix volumes, array ports, or host initiators to
the existing masking view is as simple as adding the desired element to
an existing storage, port, or initiator group.
If the production environment in the previous example is running out of
space and needs more storage, the following steps can be followed to
make additional Symmetrix volumes available to the production host
with corresponding target devices available to the backup host. As in the
original example, the Symmetrix device group is used to provide the
device lists for the symaccess commands:
1. Add the standard devices to the device group.
2. Add the target devices to the device group
3. Run the symaccess add command to add the standard devices that
were placed in the device group into the production storage group.
4. Run the symaccess add command to add the target devices that
were placed in the device group into the backup storage group.
Example of adding storage to an existing storage group

Step 1 - Add standard devices 7C3 and 7C4 to the device group.
# symld -g proddb_dg addall dev -range 7C3:7C4

Step 2 - Add target devices 916 and 917 to the device group.
# symld -g proddb_dg addall dev -range 916:917 -tgt
# symdg show proddb_dg
Group Name: proddb_dg
Group Type : REGULAR

Device Group in GNS : No
Valid : Yes
Group Creation Time : Fri Jan 30 16:06:03 2009
Vendor ID : EMC Corp
Application ID : SYMCLI
Number of STD Devices in Group : 6

Number of Associated GK's : 0
Number of Locally-associated BCV's : 0
Number of Locally-associated VDEV's : 0
Number of Locally-associated TGT's : 6
Number of Remotely-associated VDEV's(STD RDF): 0
Number of Remotely-associated BCV's (STD RDF): 0
Number of Remotely-associated TGT's(TGT RDF) : 0
Number of Remotely-associated BCV's (BCV RDF): 0
Number of Remotely-assoc'd RBCV's (RBCV RDF) : 0
Number of Remotely-assoc'd BCV's (Hop-2 BCV) : 0
Number of Remotely-assoc'd VDEV's(Hop-2 VDEV): 0
Number of Remotely-assoc'd TGT's (Hop-2 TGT) : 0
Standard (STD) Devices (6):

{
--------------------------------------------------------------------
Sym Cap
--------------------------------------------------------------------
DEV001 c3t5000097208139918d1s* 0798 RW 4314
DEV002 c3t5000097208139918d2s* 0799 RW 4314
DEV003 c3t5000097208139918d3s* 079A RW 4314
DEV004 c3t5000097208139918d4s* 079B RW 4314
DEV005 N/A 07C3 RW 4314
DEV006 N/A 07C4 RW 4314
}
TGT Devices Locally-associated (6):

{
--------------------------------------------------------------------
Sym Cap
--------------------------------------------------------------------
TGT001 N/A 0912 RW 4314
TGT002 N/A 0913 RW 4314
TGT003 N/A 0914 RW 4314
TGT004 N/A 0915 RW 4314
TGT005 N/A 0916 RW 4314
TGT006 N/A 0917 RW 4314

Step 3 – Run the symaccess add command to add the standard

devices that were placed in the device group into the production
storage group:
# symaccess add -name dbprod_stor -type storage -std -g proddb_dg -sid 54
# symaccess show view dbprodsrv_view -sid 54
Masking View Name : dbprodsrv_view

Host Initiators
{
WWN : 10000000c9767816
WWN : 10000000c9767817
}
{
FA-7E:0
FA-7F:1
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
0798 07E:0 c3t5000097208139918d1s* 1 4314
07F:1 c4t5000097208139959d1s* 1 4314
0799 07E:0 c3t5000097208139918d2s* 2 4314
07F:1 c4t5000097208139959d2s* 2 4314
079A 07E:0 c3t5000097208139918d3s* 3 4314
07F:1 c4t5000097208139959d3s* 3 4314
079B 07E:0 c3t5000097208139918d4s* 4 4314
07F:1 c4t5000097208139959d4s* 4 4314
07C3 07E:0 Not Visible 5 4314
07C4 07E:0 Not Visible 6 4314
Note: The new devices will be listed as “N/A” in the PdevName field in
symdg show output and “Not Visible” in the symaccess show view
output until they are configured by the host and symcfg discover is run.
Step 4 – Run the symaccess add command to add the target devices
that were placed in the device group into the backup storage group:

# symaccess add -name dbbackup_stor -type storage -tgt -g proddb_dg -sid 54
# symaccess show view dbbackupsrv_view -sid 54
Masking View Name : dbbackupsrv_view

Host Initiators
{
WWN : 10000000c97683e0
WWN : 10000000c97683e1
}
{
FA-7E:0
FA-7F:1
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
0912 07E:0 Not Visible 1 4314
0913 07E:0 Not Visible 2 4314
0914 07E:0 Not Visible 3 4314
0915 07E:0 Not Visible 4 4314
0916 07E:0 Not Visible 5 4314
0917 07E:0 Not Visible 6 4314
After running the applicable host commands, standard devices 7C3 and
7C4 are available to the production host and target devices 916 and 917
are available to the backup host:
# syminq

---------------------------- -------------------------- ---------------------
---------------------------- -------------------------- ---------------------

/dev/rdsk/c3t50*8d5s2 EMC SYMMETRIX 5874 54007C3000 4417920

# syminq

---------------------------- -------------------------- ---------------------
---------------------------- -------------------------- ---------------------
Presenting storage to a cluster

Cascaded initiator groups can be used to assign shared volumes to
cluster nodes while still assigning groups of devices that are not shared
among the hosts.
administrator needs to provision storage two newly attached cluster
nodes. In this example, both nodes of the cluster will share four EMC
Virtual ProvisioningTM thin devices (92A – 92D). Each node will also
have access to two RAID 6 devices (7DB – 7DC for node A and 7DD –
7DE for node B) that will not be available to the other host.

Figure 3 Storage presented in a clustered environment
Steps for provisioning storage using a cascaded initiator group

In this example, no Symmetrix device groups will be created. Both a
device file and command line ranges will be used for the device lists.
1. Create a storage group containing the volumes that will be presented
to Node A only.
2. Create a storage group containing the volumes that will be presented
to Node B only.
4. Create the initiator group for Node A.
5. Create the initiator group for Node B.
6. Create the cascaded initiator group and add the initiator group for
Node A to the cascaded initiator group.
7. Add the initiator group for Node B to the cascaded initiator group.
8. Create the clustered device masking view containing the shared
storage group, the port group, and the cascaded initiator group.
9. Create the Node A masking view containing the Node A storage

group, port group, and Node A initiator group.

10. Create the Node B masking view containing the Node B storage
group, port group, and Node B initiator group.
After running the host commands to configure the new devices, they are
available to the operating system.
Example of using a cascaded initiator group

Step 1 — Create a storage group that contains the volumes (92A – 92D)
that will be shared among both nodes of the cluster. In this example, the
device list is provided in a device file:
# cat devs
92A
92B
92C
92D
# symaccess create -name clustnodeAB_stor -type storage -file devs -sid 54
# symaccess show clustnodeAB_stor -type storage -sid 54
Last updated at : 02:17:57 PM on Wed Apr 08,2009
Storage Group Name : clustnodeAB_stor
Devices : 092A:092D
Masking View Names

{
None
}
Step 2 — Create a storage group that contains the volumes that will be
presented to Node A only (7DB:7DC). The devices to be added will be
specified in the CLI command:
# symaccess create -name clustnodeA_stor -type storage devs 7DB:7DC -sid 54
# symaccess show clustnodeA_stor -type storage -sid 54
Storage Group Name : clustnodeA_stor
Devices : 07DB:07DC
Masking View Names

{
None
}
Step 3 — Create a storage group that contains the volumes that will be
presented to Node B only (7DD:7DE). The devices to be added will be
specified in the CLI command:
# symaccess create -name clustnodeB_stor -type storage devs 7DD:7DE -sid 54
# symaccess show clustnodeB_stor -type storage -sid 54
Storage Group Name : clustnodeB_stor
Devices : 07DD:07DE
Masking View Names

{
None
}
Step 4 — Create the port group:
# symaccess create -name clust_port -type port -dirport 07E:0,07F:1 -sid 54
# symaccess show clust_port -type port -sid 54
Port Group Name : clust_port
{
FA-7E:0
FA-7F:1
}
Masking View Names

{
None
}
Step 5 — Create the initiator group for Node A:
# cat clustnodeA_WWN_file
WWN:10000000c9767816
WWN:10000000c9767817

# symaccess create -name clustnodeA_init -type initiator -file

clustnodeA_WWN_file -sid 54
# symaccess show clustnodeA_init -type initiator -sid 54
Initiator Group Name : clustnodeA_init
Host Initiators
{
WWN :10000000c9767816
WWN :10000000c9767817
}
Masking View Names

{
None
}

{
None
}
Create a storage group that contains the volumes that — Create the
initiator group for Node B:
# cat clustnodeB_WWN_file
WWN:10000000c97683e0
WWN:10000000c97683e1
# symaccess create -name clustnodeB_init -type initiator -file

clustnodeB_WWN_file -sid 54
# symaccess show clustnodeB_init -type initiator -sid 54
Initiator Group Name : clustnodeB_init
Host Initiators
{
WWN :10000000c97683e0
WWN :10000000c97683e1
}
Masking View Names

{
None
}


{
None
}
Step 7 — Create the cascaded initiator group:

One of the existing initiator groups, in this case, clustnodeA,_init is
added when the cascaded IG is created:
# symaccess create -name clustnodeAB_init -type initiator -ig clustnodeA_init

-sid 54
Step 8 — Add the initiator group for Node B to the cascaded initiator
group:
# symaccess add -name clustnodeAB_init -type initiator -ig clustnodeB_init

-sid 54
# symaccess show clustnodeAB_init -type initiator -sid 54
Initiator Group Name : clustnodeAB_init
Host Initiators
{
IG :clustnodeA_init
IG :clustnodeB_init
}
Masking View Names

{
None
}

{
None
}
Step 9 — Create the clustered device masking view containing the
shared storage group, the port group, and the cascaded initiator group:
# symaccess create view -name clustnodeAB_view -storgrp clustnodeAB_stor

-portgrp clust_port -initgrp clustnodeAB_init -sid 54
Running symaccess show view on the cascaded initiator group will

display the child initiator groups in the Host Initiators field:
# symaccess show view clustnodeAB_view -sid 54

Masking View Name : clustnodeAB_view
Initiator Group Name : clustnodeAB_init
Host Initiators
{
IG : clustnodeA_init
IG : clustnodeB_init
}
{
FA-7E:0
FA-7F:1
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
092C 07E:0 Not Visible 3 4314
092D 07E:0 Not Visible 4 4314
The -ig <child_ig> option can be chosen to see the cascaded group
from the child group’s perspective:
# symaccess show view clustnodeAB_view -ig clustnodeA_init -sid 54
Initiator Group Name : clustnodeA_init *
Host Initiators
{
WWN : 10000000c9767816
WWN : 10000000c9767817
}

{
FA-7E:0
FA-7F:1
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
* Denotes a cascaded Initiator Group within the specified Masking View
# symaccess show view clustnodeAB_view -ig clustnodeB_init -sid 54
Initiator Group Name : clustnodeB_init *
Host Initiators
{
WWN : 10000000c97683e0
WWN : 10000000c97683e1
}
{
FA-7E:0
FA-7F:1
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------


* Denotes a cascaded Initiator Group within the specified Masking View
Step 10 — Create the Node A masking view containing the Node A

storage group, the port group, and the Node A initiator group:
# symaccess create view -name clustnodeA_view -storgrp clustnodeA_stor

-portgrp clust_port -initgrp clustnodeA_init -sid 54
# symaccess show view clustnodeA_view -sid 54
Masking View Name : clustnodeA_view
Initiator Group Name : clustnodeA_init
Host Initiators
{
WWN : 10000000c9767816
WWN : 10000000c9767817
}
{
FA-7E:0
FA-7F:1
}
Storage Group Name : clustnodeA_stor
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
07DB 07E:0 Not Visible 5 4314
07DC 07E:0 Not Visible 6 4314
Step 11 — Create the Node B masking view containing the Node B

storage group, the port group, and the Node B initiator group:
# symaccess create view -name clustnodeB_view -storgrp clustnodeB_stor

-portgrp clust_port -initgrp clustnodeB_init -sid 54

# symaccess show view clustnodeB_view -sid 54
Masking View Name : clustnodeB_view
Initiator Group Name : clustnodeB_init
Host Initiators
{
WWN : 10000000c97683e0
WWN : 10000000c97683e1
}
{
FA-7E:0
FA-7F:1
}
Storage Group Name : clustnodeB_stor
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
07DD 07E:0 Not Visible 5 4314
07DE 07E:0 Not Visible 6 4314
After configuring the devices from the operating systems, the correct
devices are available to each cluster node:
Cluster Node A sees thin devices 92A – 92D as well as RAID-6 devices
7DB – 7DC:
# syminq -sym

---------------------------------- --------------------- ---------------------
Name Type ID Rev Ser Num Cap (KB)
---------------------------------- --------------------- ---------------------
/dev/rdsk/c3t5000097*18d0s2 GK SYMMETRIX 5874 5400054000 5760
/dev/rdsk/c3t5000097*18d1s2 SYMMETRIX 5874 540092A000 4417920
/dev/rdsk/c3t5000097*18d2s2 SYMMETRIX 5874 540092B000 4417920
/dev/rdsk/c3t5000097*18d3s2 SYMMETRIX 5874 540092C000 4417920
/dev/rdsk/c3t5000097*18d4s2 SYMMETRIX 5874 540092D000 4417920
/dev/rdsk/c3t5000097*18d5s2 SYMMETRIX 5874 54007DB000 4417920
/dev/rdsk/c3t5000097*18d6s2 SYMMETRIX 5874 54007DC000 4417920


Cluster Node B also sees thin devices 92A – 92D, but it sees RAID-6
devices 7DD – 7DE:
# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
/dev/rdsk/c3t5000097*18d5s2 SYMMETRIX 5874 54007DD000 4417920
/dev/rdsk/c3t5000097*18d6s2 SYMMETRIX 5874 54007DE000 4417920
Note: The order in which the parent and child initiator groups are created
will have an effect on what LUNs are assigned to the devices in the groups. If
the order used in this example was reversed, meaning that the views for the
child groups were created before the view for the parent group, the LUNs of
the devices would be different.
For example, if clustnodeA_view and clustnodeB_view were created before

clustnodeAB_view, devices 7DB-7DC would have LUNs 001-002, devices
7DD-7DE would also have LUNs 001-002, and devices 92A-92D in the parent
initiator group would have LUNs 003-006.
Removing a masking view and its associated groups

Prior to removing storage, initiator, or port groups, any masking view to
which the group is associated must first be removed. This will unmask
the devices. The user also has the option to unmap the devices while
removing the masking view.
The following steps can be performed to remove the masking view as
well as the associated storage, initiator, and port groups:

1. Delete the masking view and, optionally, unmap the devices in the
associated storage group.
2. Delete the initiator group.
3. Delete the port group.
4. Delete the storage group.
Example of deleting a masking view and associated groups

In the following example, the proddb_view masking view will be
deleted and the devices in the associated storage group will be
unmapped. Following that, the initiator group, port group, and storage
group will also be removed:
# symaccess show view proddb_view -sid 54
Masking View Name : proddb_view

Initiator Group Name : proddb_init
Host Initiators
{
WWN : 10000000c97683e0
WWN : 10000000c97683e1
}
Port Group Name : proddb_port
{
FA-7E:0
FA-7F:1
}
Storage Group Name : proddb_stor
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
07B0 07E:0 Not Visible 0 4314
00A8 07E:0 Not Visible 4 5
00A9 07E:0 Not Visible 5 5
00AA 07E:0 Not Visible 6 5


00AB 07E:0 Not Visible 7 5
Step 1 – Delete the masking view and, optionally, unmap the devices in
the associated storage group by using the –unmap option:
# symaccess delete view -name proddb_view -sid 54 -unmap –nop
When the prompt returns, the view has been deleted and the devices in
the storage group have been ummapped from the FA ports:
No Masking Views could be found for the specified input parameters
# symdev list -sid 54 -noport
Symmetrix ID: 000192601254
Device Name Directors Device

-------------------------- ------------- -------------------------------------
Cap
Sym Physical SA :P DA :IT Config Attribute Sts (MB)
-------------------------- ------------- -------------------------------------
...
00A8 Not Visible ???:? 09A:D3 2-Way Mir N/Grp'd RW 6
00A9 Not Visible ???:? 09C:C2 2-Way Mir N/Grp'd RW 6
00AA Not Visible ???:? 09B:D4 2-Way Mir N/Grp'd RW 6
00AB Not Visible ???:? 10D:C0 2-Way Mir N/Grp'd RW 6
...
07B0 Not Visible ???:? 10A:DA RAID-5 N/Grp'd RW 4314
07B1 Not Visible ???:? 10D:D9 RAID-5 N/Grp'd RW 4314
07B2 Not Visible ???:? 10C:DA RAID-5 N/Grp'd RW 4314
07B3 Not Visible ???:? 09A:D5 RAID-5 N/Grp'd RW 4314
...
Step 2 – Delete the initiator group. If the initiator group is not empty, the
initiators must be removed from the group prior to the delete or the –
force flag must be used:
# symaccess delete -name proddb_init -type initiator -sid 54 -force –nop
Step 3 – Delete the port group. If the port group is not empty, the ports
must be removed from the group prior to the delete or the –force flag
must be used:
# symaccess delete -name proddb_port -type port -sid 54 -force –nop

Step 4 – Delete the storage group. If the storage group is not empty, the
volumes must be removed from the group prior to deleting the group or
the –force flag must be used:
# symaccess delete -name proddb_stor -type storage -sid 54 -force –nop
The view and groups have now been removed:
# symaccess list view -sid 54

------------------ ------------------- ------------------- -------------------
view_LICOA067 init_LICOA067 port_LICOA067 stor_LICOA067
ctrlsrv_licoa068 ctrlsrv_licoa068 ctrlsrv_licoa068 ctrlsrv_licoa068
licoa057_1_view licoa057_1_hbas licoa057_1_ports licoa057_1_stor
# symaccess list -sid 54 -detail
View
Group Name Count Count Type
-------------------------------- ----- ----- ---------
init_LICOA067 2 3 Initiator
licoa057_1_hbas 2 1 Initiator
ctrlsrv_licoa068 2 1 Initiator
port_LICOA067 2 3 Port
licoa057_1_ports 2 1 Port
ctrlsrv_licoa068 2 1 Port
stor_LICOA067 8 1 Storage
licoa057_1_stor 24 1 Storage
ctrlsrv_licoa068 12 1 Storage
Specifying LUN addresses

The symaccess command assigns dynamic LUNs when device masking
is performed. When the devices are mapped to the FA as part of the
masking view creation, Symmetrix Enginuity assigns the next available
LUNs to the devices in the storage group. If the –lun option is used
when the masking view is created, the devices will be given a dynamic
LUN range that starts at the specified value.
The following example shows a masking view being created for an
existing initiator group, storage group, and port group.
The host initially sees only the ACLX database device:
# syminq -sym


---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
An initiator group, storage group, and port group have already been
created for the host:
# symaccess list -sid 54 -detail
View
Group Name Count Count Type
-------------------------------- ----- ----- ---------
proddb_init 2 0 Initiator
proddb_port 2 0 Port
proddb_stor 4 0 Storage
# symaccess show proddb_init -type initiator -sid 54
Last updated at : 08:35:04 PM on Thu Feb 12,2009
Host Initiators
{
WWN :10000000c97683e0
WWN :10000000c97683e1
}
Masking View Names

{
None
}
# symaccess show proddb_stor -type storage -sid 54
Devices : 07B0:07B3
Masking View Names

{
None
}
# symaccess show proddb_port -type port -sid 54

{
FA-7E:0
FA-7F:1
}
Masking View Names

{
None
}
A masking view can now be created that will mask and map the four
devices in the storage group (7B0 - 7B3) on the ports in the port group to
the WWNs in the initiator group. When the mapping is done, the devices
in the storage group will get the next four LUNs available on the FA
port. By specifying a starting LUN value, in this case LUN 1, the LUN
values will be assigned dynamically:
# symaccess create view -name proddb_view -storgrp proddb_stor -portgrp

proddb_port –initgrp proddb_init -lun 1 -sid 54
Because mapping is also being done, the prompt will take a few
moments to return. After the command completes, the devices are
mapped and masked and available to be configured by the host
operating system. The devices have been dynamically assigned LUNs
001 – 004, which are displayed in the Host LUN column of the storage
group:
Masking View Name : proddb_view

Host Initiators
{
WWN : 10000000c97683e0
WWN : 10000000c97683e1
}
{

FA-7E:0
FA-7F:1
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
These LUN values differ from the LUNs actually assigned on the FA
(0B1-0B4):
# symcfg list -address -FA 07E -P 0 -sid 54
Director Device Name Attr Address

---------------------- ----------------------------- ---- --------------
Ident Symbolic Port Sym Physical VBUS TID LUN
------ -------- ---- ---- ----------------------- ---- --- ---
FA-7E 07E 00054 c3t500009720139918d0s* ACLX 0 00 000

0055 Not Visible 0 00 001
...
0091 Not Visible 0 00 0AF
0092 Not Visible 0 00 0B0
07B0 Not Visible 0 00 0B1
00B0 Not Visible 0 00 0C0
...
00A5 Not Visible 0 00 0F5
Total ----
Mapped Devices: 205
Including Metamembers: 205
Available Addresses: 3884 (s)
After running the host commands to configure the devices, they are now
available to the operating system on two paths with LUNs 001 - 004:
# syminq -sym


--------------------------------- --------------------- ---------------------
--------------------------------- --------------------- ---------------------
When adding devices to an existing storage group using a list of devices

in the command line, both a starting LUN and specific LUNs for the
devices in the list may be specified.
In the following example, an existing host has a group of devices
assigned but only sees the ACLX device. If gatekeepers are assigned, it
might be desirable to give them high LUN numbers so that they appear
at the end of the device list while also adding new devices that use the
next LUNs available to the initiator. Devices 907 and 908 and
gatekeepers 0AC and 0AD will be added to the storage group. The first
two devices will be given LUNs 015 and 016 (21 and 22 in decimal); the
second two devices will be given LUNs 0F0 and 0F1 (240 and 241):
# symaccess show view licoa057_1_view -sid 54
Masking View Name : licoa057_1_view

Initiator Group Name : licoa057_1_hba
Host Initiators
{
WWN : 10000000c9767816
}
Port Group Name : licoa057_1_port
{
FA-7E:0
}
Storage Group Name : licoa057_1_stor
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
07DB 07E:0 c3t5000097208139918d1s* 1 4314
07DC 07E:0 c3t5000097208139918d2s* 2 4314

07DD 07E:0 c3t5000097208139918d3s* 3 4314

07DE 07E:0 c3t5000097208139918d4s* 4 4314
0833 07E:0 c3t5000097208139918d5s* 5 4314
0834 07E:0 c3t5000097208139918d6s* 6 4314
0835 07E:0 c3t5000097208139918d7s* 7 4314
0836 07E:0 c3t5000097208139918d8s* 8 4314
0837 07E:0 c3t5000097208139918d9s* 9 4314
0838 07E:0 c3t5000097208139918d10* a 4314
0839 07E:0 c3t5000097208139918d11* b 4314
083A 07E:0 c3t5000097208139918d12* c 4314
083B 07E:0 c3t5000097208139918d13* d 4314
083C 07E:0 c3t5000097208139918d14* e 4314
083D 07E:0 c3t5000097208139918d15* f 4314
083E 07E:0 c3t5000097208139918d16* 10 4314
092A 07E:0 c3t5000097208139918d17* 11 4314
092B 07E:0 c3t5000097208139918d18* 12 4314
092C 07E:0 c3t5000097208139918d19* 13 4314
092D 07E:0 c3t5000097208139918d20* 14 4314
# symaccess -sid 54 -name licoa057_1_stor -type storage add devs

907,908,0AC,0AD -lun 015,016,0F0,0F1
The devices have been added to the storage group and are mapped and
masked with the specified dynamic LUN addresses:

Host Initiators
{
WWN : 10000000c9767816
}
{
FA-7E:0
}
Sym Dev Host

------ ----- ----------------------- ---- ---- -------
07DB 07E:0 c3t5000097208139918d1s* 1 4314
07DC 07E:0 c3t5000097208139918d2s* 2 4314
07DD 07E:0 c3t5000097208139918d3s* 3 4314
07DE 07E:0 c3t5000097208139918d4s* 4 4314
0833 07E:0 c3t5000097208139918d5s* 5 4314
0834 07E:0 c3t5000097208139918d6s* 6 4314
0835 07E:0 c3t5000097208139918d7s* 7 4314

0836 07E:0 c3t5000097208139918d8s* 8 4314

0837 07E:0 c3t5000097208139918d9s* 9 4314
0838 07E:0 c3t5000097208139918d10* a 4314
0839 07E:0 c3t5000097208139918d11* b 4314
083A 07E:0 c3t5000097208139918d12* c 4314
083B 07E:0 c3t5000097208139918d13* d 4314
083C 07E:0 c3t5000097208139918d14* e 4314
083D 07E:0 c3t5000097208139918d15* f 4314
083E 07E:0 c3t5000097208139918d16* 10 4314
092A 07E:0 c3t5000097208139918d17* 11 4314
092B 07E:0 c3t5000097208139918d18* 12 4314
092C 07E:0 c3t5000097208139918d19* 13 4314
092D 07E:0 c3t5000097208139918d20* 14 4314
0907 07E:0 Not Visible 15 4314
0908 07E:0 Not Visible 16 4314
00AC 07E:0 Not Visible f0 5
00AD 07E:0 Not Visible f1 5
The LUNs that are actually assigned on the FA are different from the
dynamically assigned LUNs:
# symcfg list -address -FA 07E -P 0 -sid 54
Director Device Name Attr Address

---------------------- ----------------------------- ---- --------------
Ident Symbolic Port Sym Physical VBUS TID LUN
------ -------- ---- ---- ----------------------- ---- --- ---
FA-7E 07E 0
0054 c3t5000097208139918d0s* ACLX 0 00 000
...
00AA Not Visible 0 00 0B7
00AB Not Visible 0 00 0B8
00AC c3t5000097208139918d24* 0 00 0B9
00AD c3t5000097208139918d24* 0 00 0BA
00AE Not Visible 0 00 0BB
00AF Not Visible 0 00 0BC
0907 c3t5000097208139918d21* 0 00 0BD
0908 c3t5000097208139918d22* 0 00 0BE
...
Total ----
Mapped Devices: 215
Including Metamembers: 215
Available Addresses: 3874 (s)
After configuring the devices to the host, the host special device files

have been created using the dynamic LUN addresses:
# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
/dev/rdsk/c3t500009*8d3s2 BCV SYMMETRIX 5874 54007DD000 4417920
/dev/rdsk/c3t500009*8d5s2 R1 SYMMETRIX 5874 5400833000 4417920
/dev/rdsk/c3t500009*8d9s2 SYMMETRIX 5874 5400837000 4417920
/dev/rdsk/c3t500009*8d16s2 SYMMETRIX 5874 540083E000 4417920
/dev/rdsk/c3t500009*8d240s2 GK SYMMETRIX 5874 54000AC000 5760
/dev/rdsk/c3t500009*8d241s2 GK SYMMETRIX 5874 54000AD000 5760
After running symcfg discover, the special device files appear in the
symaccess show view output:

Host Initiators
{
WWN : 10000000c9767816
}
{
FA-7E:0
}

Sym Dev Host

------ ----- ----------------------- ---- ---- -------
07DB 07E:0 c3t5000097208139918d1s* 1 4314
07DC 07E:0 c3t5000097208139918d2s* 2 4314
07DD 07E:0 c3t5000097208139918d3s* 3 4314
07DE 07E:0 c3t5000097208139918d4s* 4 4314
0833 07E:0 c3t5000097208139918d5s* 5 4314
0834 07E:0 c3t5000097208139918d6s* 6 4314
0835 07E:0 c3t5000097208139918d7s* 7 4314
0836 07E:0 c3t5000097208139918d8s* 8 4314
0837 07E:0 c3t5000097208139918d9s* 9 4314
0838 07E:0 c3t5000097208139918d10* a 4314
0839 07E:0 c3t5000097208139918d11* b 4314
083A 07E:0 c3t5000097208139918d12* c 4314
083B 07E:0 c3t5000097208139918d13* d 4314
083C 07E:0 c3t5000097208139918d14* e 4314
083D 07E:0 c3t5000097208139918d15* f 4314
083E 07E:0 c3t5000097208139918d16* 10 4314
092A 07E:0 c3t5000097208139918d17* 11 4314
092B 07E:0 c3t5000097208139918d18* 12 4314
092C 07E:0 c3t5000097208139918d19* 13 4314
092D 07E:0 c3t5000097208139918d20* 14 4314
0907 07E:0 c3t5000097208139918d21* 15 4314
0908 07E:0 c3t5000097208139918d22* 16 4314
00AC 07E:0 c3t5000097208139918d24* f0 5
00AD 07E:0 c3t5000097208139918d24* f1 5
More information about using dynamic LUN addressing can be found in

the Symmetrix Dynamic LUN Addressing Technical Note, which is available
on the EMC Powerlink® website.
Specifying HBA flags

The symaccess command can be used to set port flags on both initiator
groups and also on individual host bus adapters within an initiator
group. This functionality allows multiple operating systems to easily
share FA ports by moving the place where the flags are set from the FA
port to the HBA or initiator group.
The following flags can be set on the initiator group:
Volume_Set_Addressing [V]
Common_Serial_Number [C]
Disable_Q_Reset_on_UA [D]
Environ_Set [E]
Avoid_Reset_Broadcast [ARB]
AS400 [AS4]

OpenVMS [OVMS]
SCSI_3 [SC3]
SPC2_Protocol_Version [SPC2]
SCSI_Support1 [OS2007]
All of the HBA flags can be set on an individual HBA or an entire
initiator group with the exception of the Volume Set Addressing flag.
As the Volume Set Addressing flag affects the LUN addressing scheme
in support of HP-UX environments, it can only be set at the initiator
group level. The V flag prevents LUNs 8 – F from being assigned to a
volume. It is not applicable for any other host environment and must be
set on the port or on the initiator group. The V flag can apply to both
child and parent initiator groups, but must be consistent across them. If
an attempt is made to add an initiator group to another IG to form a
cascaded IG and a child group has the V flag set but the parent does not,
the command will fail:
Note: In many cases, setting a flag at the group level is preferable to setting it
at the initiator level. Setting the flag on the IG propagates the setting to all
initiators in the group and guarantees that any initiators added to the group
at a later time will inherit the same settings.
To view the current flags set on an initiator group:
# symaccess -sid 54 -type init show licoa057_init -detail
Initiator Group Name : licoa057_init

Last updated at : 10:06:11 AM on Mon Dec 21,2009
Port Flag Overrides : No

Consistent Lun : No
Originator Port wwn : 10000000c9767817

User-generated Name : 10000000c9767817/10000000c9767817
FCID Lockdown : No
Heterogeneous Host : No
CHAP Enabled : N/A
Type : Fibre

FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre

To set the Disable_Q_Reset_on_UA or D flag on an initiator group:
# symaccess -sid 54 -type init -name licoa057_init set ig_flags on D –enable
The Disable_Q_Reset_on_UA is now set on the initiator group and all

initiators belonging to it. The Port Flag Overrides field indicates that a
port flag has been set on the IG, and also for each HBA:

Last updated at : 12:07:00 PM on Mon Mar 15,2010
Port Flag Overrides : Yes

Enabled : Disable_Q_Reset_on_UA(D)
Disabled : N/A
Consistent Lun : No

FCID Lockdown : No
Disabled : N/A
CHAP Enabled : N/A
Type : Fibre

FCID Lockdown : No
Disabled : N/A
CHAP Enabled : N/A
Type : Fibre
To remove the IG flag that was just set:
# symaccess -sid 54 -name licoa057_init -type initiator set ig_flags off D

Last updated at : 09:40:11 AM on Tue Mar 16,2010

Consistent Lun : No

FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre

FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre
To set a flag by using the HBA WWN, the following can be run, which in
this case sets the D flag on only one of the initiators in the IG and not the
entire group:
# symaccess -sid 54 -wwn 10000000c9767817 set hba_flags on D –enable
The Port Flag Overrides field indicates that the override applies only to
one of the HBAs in the IG:


Consistent Lun : No

FCID Lockdown : No
Disabled : N/A
CHAP Enabled : N/A
Type : Fibre

FCID Lockdown : No


CHAP Enabled : N/A
Type : Fibre
To unset the flag on the WWN:
# symaccess -sid 54 -wwn 10000000c9767817 set hba_flag off D


Consistent Lun : No

FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre

FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre
Note: There is some dependency between the OS2007 and SPC2 flags. The
OS2007 flag can only be set or enabled on the initiator or group when the
SPC2 flag is set or enabled on the same initiator or group. The reverse is also
true; the SPC2 flag can not be set, disabled, or turned off while the OS2007
flag is set or enabled.
Overriding port flags

Flags that are set on the FA port can be also be overridden. In this case,
the ports that this host is using to access the Symmetrix has the common
serial number (C) flag set:
# symaccess -sid 54 show licoa057_port -type port
Port Group Name : licoa057_port

Last updated at : 10:06:11 AM on Mon Dec 21,2009
{
FA-7E:0
FA-10E:1
}
Masking View Names

{
licoa057_view
}
# symcfg -sid 54 list -FA 7E -p 0 -v

...
SCSI Flags
{
Negotiate_Reset(N) : Disabled
Soft_Reset(S) : Disabled
Environ_Set(E) : Disabled
HP3000_Mode(B) : Disabled
Common_Serial_Number(C) : Enabled
Disable_Q_Reset_on_UA(D) : Disabled
Sunapee(SCL) : Disabled
Siemens(S) : Disabled
Sequent(SEQ) : Disabled
Avoid_Reset_Broadcast(ARB) : Disabled
Server_On_AS400(A4S) : Disabled
SCSI_3(SC3) : Enabled
SPC2_Protocol_Version(SPC2) : Enabled
SCSI_Support1(OS2007) : Disabled
}
Fibre Specific Flags

{
Volume_Set_Addressing(V) : Disabled
Non_Participating(NP) : Disabled
Init_Point_to_Point(PP) : Enabled
Unique_WWN(UWN) : Enabled
Access_Logix(ACLX) : Enabled
OpenVMS(OVMS) : Disabled
AS400(AS4) : Disabled
Auto_Negotiate(EAN) : Enabled
}
# symcfg -sid 54 list -FA 10E -p 1 -v

...
SCSI Flags
{
Negotiate_Reset(N) : Disabled
Soft_Reset(S) : Disabled

Environ_Set(E) : Disabled
HP3000_Mode(B) : Disabled
Common_Serial_Number(C) : Enabled
Disable_Q_Reset_on_UA(D) : Disabled
Sunapee(SCL) : Disabled
Siemens(S) : Disabled
Sequent(SEQ) : Disabled
Avoid_Reset_Broadcast(ARB) : Disabled
Server_On_AS400(A4S) : Disabled
SCSI_3(SC3) : Enabled
SPC2_Protocol_Version(SPC2) : Enabled
SCSI_Support1(OS2007) : Disabled
}
Fibre Specific Flags

{
Volume_Set_Addressing(V) : Disabled
Non_Participating(NP) : Disabled
Init_Point_to_Point(PP) : Enabled
Unique_WWN(UWN) : Enabled
Access_Logix(ACLX) : Enabled
OpenVMS(OVMS) : Disabled
AS400(AS4) : Disabled
Auto_Negotiate(EAN) : Enabled
}
The common serial number flag causes the serial number returned in
response to a SCSI inquiry to end in all zeros:
# syminq

---------------------------- --------------------------- ---------------------
---------------------------- --------------------------- ---------------------
/dev/rdsk/c3t5*d0s2 EMC SYMMETRIX 5874 54003A9000 4417920
/dev/rdsk/c3t5*d1s2 EMC SYMMETRIX 5874 54003AA000 4417920
/dev/rdsk/c3t5*d2s2 EMC SYMMETRIX 5874 54003AB000 4417920
/dev/rdsk/c3t5*d3s2 EMC SYMMETRIX 5874 54003AC000 4417920
/dev/rdsk/c3t5*d4s2 EMC SYMMETRIX 5874 54003AD000 4417920
/dev/rdsk/c3t5*d5s2 EMC SYMMETRIX 5874 54003AE000 4417920
/dev/rdsk/c3t5*d6s2 EMC SYMMETRIX 5874 54003AF000 4417920
/dev/rdsk/c3t5*d7s2 EMC SYMMETRIX 5874 54003B0000 4417920
...
The IG currently has no port flags set and no port flags overridden:


Consistent Lun : No


FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre

FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre
To unset the flag for just the initiators in an IG while leaving it set on the
port, the –disable option is used along with the “on” option. The flag
cannot simply be turned off at the IG level because the IG is not
overriding the flag. It must be turned 'on' at the initiator group to turn on
the override of the flag. It can then be disabled so that the override action
is to unset the flag:
# symaccess -sid 54 -name licoa057_init -type initiator set ig_flags on C

–disable

Last updated at : 07:33:24 AM on Wed Mar 17,2010

Enabled : N/A
Disabled : Common_Serial_Number(C)
Consistent Lun : No

FCID Lockdown : No
Enabled : N/A
CHAP Enabled : N/A
Type : Fibre

FCID Lockdown : No

Enabled : N/A
CHAP Enabled : N/A
Type : Fibre
The full serial number, which now includes FA and port numbers, is
now being displayed in syminq output:
# syminq

---------------------------- --------------------------- ---------------------
---------------------------- --------------------------- ---------------------
/dev/rdsk/c3t57208* EMC SYMMETRIX 5874 54003A9470 4417920
/dev/rdsk/c3t57208* EMC SYMMETRIX 5874 54003AA470 4417920
/dev/rdsk/c3t57208* EMC SYMMETRIX 5874 54003AB470 4417920
/dev/rdsk/c3t57208* EMC SYMMETRIX 5874 54003AC470 4417920
/dev/rdsk/c3t57208* EMC SYMMETRIX 5874 54003AD470 4417920
/dev/rdsk/c3t57208* EMC SYMMETRIX 5874 54003AE470 4417920
/dev/rdsk/c3t57208* EMC SYMMETRIX 5874 54003AF470 4417920
/dev/rdsk/c3t50208* EMC SYMMETRIX 5874 54003B0470 4417920
...
Now that the flag is set on the IG, it can be turned off on the IG by using
the “off” option:
# symaccess -sid 54 -name licoa057_init -type initiator set ig_flags off C

Last updated at : 07:53:07 AM on Wed Mar 17,2010

Consistent Lun : No

FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre

FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre

# syminq

---------------------------- --------------------------- ---------------------
---------------------------- --------------------------- ---------------------
/dev/rdsk/c3t5*d1s2 EMC SYMMETRIX 5874 54003AA000 4417920
/dev/rdsk/c3t5*d2s2 EMC SYMMETRIX 5874 54003AB000 4417920
/dev/rdsk/c3t5*d3s2 EMC SYMMETRIX 5874 54003AC000 4417920
/dev/rdsk/c3t5*d4s2 EMC SYMMETRIX 5874 54003AD000 4417920
/dev/rdsk/c3t5*d5s2 EMC SYMMETRIX 5874 54003AE000 4417920
/dev/rdsk/c3t5*d6s2 EMC SYMMETRIX 5874 54003AF000 4417920
...
Insuring consistent LUNs across initiators

In some host environments, it is a requirement that volumes be assigned
to the same LUN value on all channels. To facilitate this, the
–consistent_lun option can be used when creating initiator groups.
For example:
# symaccess -sid 51 create -name licoa058_init -type initiator -file
clustnodeA_WWN_file –consistent_lun
# symaccess -sid 51 show licoa098_init -type initiator -detail


Consistent Lun : Yes
Originator Port wwn : 10000000c97a7659

User-generated Name : 10000000c97a7659/10000000c97a7659
FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre
Originator Port wwn : 10000000c97a765a

User-generated Name : 10000000c97a765a/10000000c97a765a
FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre
When the consistent_lun flag is set on an IG and when it is added to a

masking view, all volumes in associated storage groups will be assigned

identical LUNs on all channels as mapping and masking are performed

by the Symmetrix.
The -consistent_lun option can apply to both child and parent
initiator groups but must be consistent across them. If an attempt is
made to add an initiator group to another IG to form a cascaded IG and a
child group has the consistent_lun flag set but the parent does not, the
command will fail:
# symaccess -sid 51 create -name licoa099_init -type initiator -f

clustnodeB_WWN_file
# symaccess -sid 51 show licoa099_init -type initiator -detail


Consistent Lun : No
Originator Port wwn : 10000000c976c3e5

User-generated Name : 10000000c976c3e5/10000000c976c3e5
FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre
Originator Port wwn : 10000000c976c3e6

User-generated Name : 10000000c976c3e6/10000000c976c3e6
FCID Lockdown : No
CHAP Enabled : N/A
Type : Fibre
# symaccess -sid 51 show licoaCLUST_init -type initiator -detail
Initiator Group Name : licoaCLUST_init


Consistent Lun : Yes
Group Name : licoa098_init

User-generated Name : N/A
FCID Lockdown : N/A
Heterogeneous Host : N/A
Port Flag Overrides : N/A
CHAP Enabled : N/A
Type : Initiator Group

# symaccess -sid 51 add -name licoaCLUST_init -type initiator -ig

licoa099_init
The operation will result in consistent lun violation
In this situation, the set command would allow the user to set this flag
on the child after it has been created. This would allow the child initiator
group to be added to the parent IG:
# symaccess -sid 51 set -name licoa099_init set consistent_lun on
Provisioning storage by using SMC

The following use cases illustrate various ways that initiator groups can
be used to provide access to Symmetrix volumes using SMC.
Presenting storage to a SYMAPI control host

In the first example, gatekeepers need to be provisioned to a
management host that will be the SMC server. Best practice for assigning
gatekeepers to hosts specifies that gatekeeper device be assigned on only
a single front-end path.
Figure 3 Creating individual paths to gatekeepers

this goal:

1. Create a storage group containing the gatekeepers that will be

accessed on path 0.
2. Create a storage group containing the gatekeepers that will be
accessed on path 1.
3. Create a port group containing the port for path 0.
4. Create a port group containing the port for path 1.
5. Create an initiator group containing the HBA for path 0.
6. Create an initiator group for the initiator for path 1.
7. Create a masking view for path 0.
8. Create a masking view for path 1.

The folders containing all of the initiator groups entities can be found in
the Masking Views folder in the tree view pane under the Symmetrix
serial number:
Figure 4 Masking Views folder

Step 1 - Create a storage group containing the gatekeepers that will be
accessed on path 0.
The dialog box used to create storage groups can be accessed by right-
clicking on either the Symmetrix serial number, the Symmetrix Masking
Views folder, or the Storage Groups folder, then by selecting Device

Masking and Mapping > Storage Groups Maintenance > Create Storage
Group ...
Figure 5 Creating storage groups

In the Create dialog box, the group name can be entered. The user can
also choose the Devices Source Type from a pull-down menu. This
allows the user to choose devices manually from a list of available
Symmetrix devices or from a device group, composite group, or storage
template.
In this example, three gatekeepers (05A, 05B, and 05C) are chosen from a
list of available Symmetrix devices. After selecting them and clicking
Add they are put into the Group Members field. After clicking OK, the
storage group is created.
Figure 6 Viewing a storage group

Step 2 – Follow the same steps and create a storage group containing the
gatekeepers that will be accessed on path 1.
Step 3 – Create a port group containing the port for path 0.
The dialog box used to create port groups can be accessed by right-
folder, or the Port Groups folder, then by selecting Device Masking and
Mapping > Port Groups Maintenance > Create Port Group ...

Figure 7 Creating port groups

After naming the port group, selecting the desired port (7E:0), clicking
Add, and clicking OK, the port group will be created:
Figure 8 Viewing a port group

Step 4 – Follow the same steps and create a port group containing the
port that will be used on path 1.
Step 5 – Create an initiator group containing the HBA for path 0.
The dialog box used to create initiator groups can be accessed by right-
folder, or the Initiator Groups folder, then by selecting Device Masking
and Mapping > Initiator Groups Maintenance > Create Initiator Group ...

Figure 9Creating initiator groups

With initiator groups, the WWN of the HBA can be chosen from a list of
available initiators or a new initiator that has not been discovered yet can
be entered manually.
After naming the initiator group, selecting the initiator, clicking Add,
and clicking OK, the initiator group will be created:
Figure 10 Viewing an initiator group

Step 6 – Follow the same steps and create an initiator group containing
the HBA for path 0.
Step 7 – Create a masking view for path 0.
The dialog box used to create a masking view can be accessed by right-
folder, or the Masking Views folder, then by selecting Device Masking
and Mapping > Masking Views Maintenance > Create Masking View ...
After entering in the masking view name, the storage group can be
selected from a list by clicking the Select button to bring up the Select a
Storage Group dialog box.
Figure 11 Selecting a storage group

After the storage group is selected, the port and initiator groups can be
selected in the same manner.

Figure 12 Selecting a port and initiator group

After they have been chosen, clicking OK will cause SMC to perform the
mapping and masking. When the operation is complete, the masking
view is created and the gatekeepers are available to the host:
Figure 13 Viewing a masking view

# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
/dev/rdsk/c3t500009*918d1s2 GK SYMMETRIX 5874 540005A000 5760
/dev/rdsk/c3t500009*918d2s2 GK SYMMETRIX 5874 540005B000 5760
/dev/rdsk/c3t500009*918d3s2 GK SYMMETRIX 5874 540005C000 5760

Step 8 – Follow the same steps and create a masking view for Path 1.
Presenting storage to a production and a backup host

administrator needs to provision storage to two newly attached hosts. In
this example, one of the machines is a production database server and
the other is a database backup server that will access clones of the
production volumes. Each host will access its own set of devices through
two HBAs zoned to the VMAX array on the same FA ports.
Figure 14 Storage presented to a production and a backup host

To make the storage available to the appropriate host, the storage
groups, port group, and initiator groups must be created. The applicable
groups must then be combined into a masking view for each host, which
will do the mapping and masking so that the storage is accessible.
In this example a Symmetrix device group will be created and will be
used to provide the device lists for the storage groups.
this goal:
1. Create a Symmetrix device group that contains the production
volumes and the clone target volumes.
2. Create the production storage group that contains the production

volumes.
3. Create the backup storage group that contains the clone target
volumes.
5. Create the production server initiator group.
6. Create the backup server initiator group.
7. Create the production server masking view containing the
production storage group, port group, and production initiator
group.
8. Create the backup server masking view containing the backup

Step 1 - Create a Symmetrix device group, add the production volumes,
and add the clone target volumes. The dialog box used to create device
groups can be accessed by right-clicking on the Device Groups folder
then by selecting DG/CG Management > Create Group ...

Figure 15 Creating device groups

The standard volumes (STD) for the production host and the target
volumes (TGT) for the backup host can now be selected. Selecting the
STD device type brings up a list of available Standards. The following
figure shows four devices (7DB – 7DE) are chosen:

Figure 16 Selecting volumes

Selecting the TGT device type brings up a list of devices that are
available to be used as clone targets. The four clone targets (7DF – 7E2)
can be selected and added to the device group:

Figure 17 Adding clone targets to the device group

After clicking OK, the device group is created.
Figure 18 Viewing a device group

Step 2 - Create the production storage group that contains the
production volumes. For this step, the device group will be used to
provide the device list.
The dialog box used to create storage groups can be accessed by right-

folder, or the Storage Groups folder, then selecting Device Masking and
Mapping > Storage Groups Maintenance > Create Storage Group ...
Figure 19 Creating storage groups

After naming the storage group, Device Group can be selected from the
pull-down menu for Devices Source Type. The correct device group can
then be chosen by clicking Select... next to the Device Source Name field.
When the dialog box opens, all of the devices in the device group will
populate the Group Members list. In this example, only the STD devices
will be part of this storage group, so the TGT devices must be removed
before the storage group is created.

Figure 20 Selecting source storage group members

Step 3 – The storage group for the backup server can be created in the
same way except the STD devices will be removed before clicking OK:

Figure 21 Selecting target storage group members

Both storage groups are now available:

Step 4 – Create the port group containing the two Symmetrix ports to
which the HBAs are zoned.
The dialog box used to create port groups can be accessed by right-

Figure 23 Creating port groups

In the Create dialog box, the Port Group Name can be entered and the
ports chosen. In this example, both the Standard and Target devices will
be available on ports 07E:0 and 07F:1:

Figure 24 Creaing a port group

After clicking OK, the port group is created:
Figure 25 Viewing a port group

Step 5 – Create the production server initiator group. The dialog box
used to create initiator groups can be accessed by right-clicking on either
the Symmetrix serial number, the Symmetrix Masking folder, or the

Initiator Groups folder, then by selecting Device Masking and Mapping

> Initiator Groups Maintenance > Create Initiator Group ...
Figure 26 Creating the production server initiator group

With initiator groups, the WWN of the HBA can be chosen from a list of
available initiators or a new initiator that has not been discovered yet can
be entered manually.
After naming the initiator group, selecting the initiator, clicking Add,
and then OK, the initiator group will be created:

Figure 27 Initiator group is created

Step 6 – Create the backup server initiator group in the same manner.
Step 7 – Create the production server masking view containing the
production storage group, port group, and production initiator group.
The dialog box used to create a masking view can be accessed by right-


Figure 28 Creating a masking view

After entering in the masking view name, the storage group can be
selected from a list by clicking Select ... to bring up the Select a Storage
Group dialog box.

Figure 29 Select a Storage Group dialog box

After the storage group is selected, the port and initiator groups can be
selected in the same manner:
Figure 30 Selecting port and initiator groups

After they have been chosen, clicking OK will cause SMC to perform the
mapping and masking. When the operation is complete, the masking
view is created and the devices are available:


Symmetrix volumes in the storage group (7DB-7DE) are available to the
host:
# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
Step 8 – Create the backup server masking view containing the backup

Symmetrix volumes in the storage group (7DF-7E2) are available to the

host:
# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
/dev/rdsk/c3t5000097*18d1s2 SYMMETRIX 5874 54007DF000 4417920
Adding existing storage, ports, or initiators to an existing view

Adding additional Symmetrix volumes, array ports, or host initiators to
the existing masking view is as simple as adding the desired element to
an existing storage, port, or initiator group.
If the production environment in the previous example is running out of
space and needs more storage, the following steps can be followed to
make additional Symmetrix volumes available to the production host
with corresponding target devices available to the backup host.
1. Add the standard devices that were placed in the device group into
the production storage group.
2. Add the target devices that were placed in the device group into the
backup storage group.
Example of adding storage to an existing storage group

Step 1 – Add standard devices 7E8 and 7E9 into the production storage
group.
The dialog box used to modify storage groups can be accessed by right-
clicking on the storage group to be modified under the Storage Groups
folder, then by selecting Device Masking and Mapping > Storage Groups
Maintenance > Modify Storage Group ...

Figure 33 Modifying storage groups

Choose the devices from the list of available devices, click Add to add
them to the list for group members, and click OK.

Figure 34 Adding additional devices to a storage group

After clicking OK, the devices are part of the storage group. The
mapping and masking is done automatically.

Step 2 – Add target devices 7EA and 7EB into the backup storage group
in the same way.

Figure 36 Add target devices into the backup storage group

After running the applicable host commands, standard devices 7E8 and
7E9 are available to the production host:
# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------


Target devices 7EA and 7EB are available to the backup host:
# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
/dev/rdsk/c3t5000097*18d5s2 SYMMETRIX 5874 54007EA000 4417920
/dev/rdsk/c3t5000097*18d6s2 SYMMETRIX 5874 54007EB000 4417920
/dev/rdsk/c4t5000097*59d5s2 SYMMETRIX 5874 54007EA000 4417920
/dev/rdsk/c4t5000097*59d6s2 SYMMETRIX 5874 54007EB000 4417920
Note: It is also possible to use the Expand Storage wizard to add devices to a
storage group.
The wizard can be accessed by right-clicking on the storage group to be

modified under the Storage Groups folder, then clicking Device Masking and
Mapping > Storage Groups Maintenance > Expand Storage Group ...
Presenting storage to a cluster

Cascaded initiator groups can be used to assign shared volumes to
cluster nodes while still assigning groups of devices that are not shared
among the hosts.
administrator needs to provision storage to two newly attached cluster
nodes. In this example, both nodes of the cluster will share four Virtual
Provisioning thin devices (92A – 92D). Each node will also have access to
two RAID 6 devices (7DB – 7DC for node A and 7DD – 7DE for node B)
that will not be available to the other host.

Figure 37 Storage presented in a clustered environment
Steps for provisioning storage using a cascaded initiator group

In this example, no Symmetrix device groups will be created. Both a
device file and command line ranges will be used for the device lists.
this goal:
1. Create a storage group that contains the volumes that will be shared
among both nodes of the cluster.
2. Create a storage group that contains the volumes that will be
presented to Node A only.
3. Create a storage group that contains the volumes that will be
presented to Node B only.
5. Create the initiator group for Node A.
6. Create the initiator group for Node B.
7. Create the cascaded initiator group.
8. Create the clustered device masking view containing the shared
storage group, port group, and cascaded initiator group.

9. Create the Node A masking view containing the Node A storage

group, port group, and Node A initiator group.
10. Create the Node B masking view containing the Node B storage
group, port group, and Node B initiator group.
After running the host commands to configure the new devices, they are
available to the operating system.
Example of using a cascaded initiator group

Step 1 - Create a storage group that contains the volumes (92A – 92D)
that will be shared among both nodes of the cluster. In this example the
device list is provided in a device file.
The dialog box used to create storage groups can be accessed by right
folder, or the Storage Groups folder, then by selecting Device Masking
and Mapping > Storage Groups Maintenance > Create Storage Group ...
After naming the storage group, Symmetrix can be selected from the
pull-down menu for Devices Source Type. The Available Devices list can
be filtered or can contain all available Symmetrix devices.

Devices 92A to 92D are chosen and added to the Group Members list by
selecting them and then by clicking Add. The storage group is then
created by clicking OK:
Step 2 - Create a storage group that contains the volumes that will be
presented to Node A only (7DB:7DC).

Step 3 - Create a storage group that contains the volumes that will be
presented to Node B only (7DD:7DE).
Step 4 – Create the port group.

The dialog box used to create port groups can be accessed by right
After naming the port group, select the desired ports (7E:0 and 7F:1),
click Add and OK. The port group will be created:

Step 5 - Create the initiator group for Node A.

The dialog box used to create initiator groups can be accessed by right
folder, or the Initiator Groups folder, then by selecting Device Masking
and Mapping > Initiator Groups Maintenance > Create Initiator Group ...

Both HBA WWNs can be selected from the Available Initiators list. They
can then be put in the Selected Initiators list by clicking Click OK to
create the port group.

Step 6 - Create the initiator group for Node B.

Use the same steps to create the initiator group for Node B.
Step 7 - Create the cascaded initiator group that contains the node A and
Node B initiator groups.
Cascaded initiator groups are created in the same way that regular
initiator groups are created except other initiator groups are added to the
cascaded group instead of individual initiators. Existing initiator groups
will appear at the end of the list of available initiators. They can be
selected and added to the cascaded initiator group just as regular
initiators are added.

The Cascaded or parent initiator group now contains the two child
initiator groups:
Step 8 - Create the clustered device masking view containing the shared
storage group, port group, and cascaded initiator group.
The dialog box used to create a masking view can be accessed by right

Provide a name to the view and then click the Select... next to each
group and choose the correct storage, port, and initiator groups. Then
click OK to create the view.
Step 9 - Create the Node A masking view containing the Node A storage
group, the port group, and the Node A initiator group.

Use the same steps to create the masking view for the devices that will be
seen only by Node A.
Step 10 - Create the Node B masking view containing the Node B storage
group, the port group, and the Node B initiator group.
Use the same steps to create the masking view for the devices that will be
seen only by Node B.
After configuring the devices from the operating systems, the correct
devices are available to each cluster node:
Cluster Node A sees thin devices 92A – 92Das well as RAID-6 devices
7DB – 7DC:
# syminq -sym

---------------------------------- --------------------- ---------------------

---------------------------------- --------------------- ---------------------

Cluster Node B also sees thin devices 92A – 92D, but it sees RAID-6
devices 7DD – 7DE:
# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
Removing a masking view and its associated groups

Prior to removing storage, initiator, or port groups, any masking view to
which the group is associated must first be removed. This will unmask
the devices. The user also has the option to unmap the devices while
removing the masking view.
The following steps can be performed to remove the masking view as
well as the associated storage, initiator, and port groups:
1. Delete the masking view and, optionally, unmap the devices in
the associated storage group.
2. Delete the initiator group.

3. Delete the port group.

4. Delete the storage group.
Example of deleting a masking view and associated groups

In the following example, the “dbprodsrv_view” masking view will be
deleted and the devices in the associated storage group will be
unmapped. Following that, the initiator group, port group, and storage
group will also be removed:
Step 1 – Delete the masking view and, optionally, unmap the devices in
the associated storage group.
The dialog box used to delete views can be accessed by right-clicking on
the “dbprodsrv_view” view in the Properties pane, then clicking Device
Masking and Mapping > Masking Views Maintenance > Delete Masking
View ...
Figure 38 Deleting the masking view

Select the Unmap removed devices checkbox, click OK, and confirm the
operation to remove the view.

Figure 39 Unmapping devices

Step 2 – Delete the initiator group.
The dialog box used to delete an initiator group can be accessed by right-
clicking on the “dbprodsrv_init” group in the Properties pane, then
clicking Device Masking and Mapping > Initiator Groups Maintenance >
Delete Initiator Group ...

Figure 40 Deleting an initiator group

Confirm the operation to delete the initiator group:
Figure 41 Confirm the operation

Step 3 – Delete the port group.
The dialog box used to delete a port group can be accessed by right-
clicking on the “dbsrv_port” group in the Properties pane, then clicking
Device Masking and Mapping > Port Groups Maintenance > Delete Port
Group ...
Figure 42 Deleting a port group

Confirm the operation to delete the port group:

Step 4 – Delete the storage group.

The dialog box used to delete a storage group can be accessed by right-
clicking on the “dbprod_stor” group in the Properties pane, then clicking
Device Masking and Mapping > Storage Groups Maintenance > Delete
Storage Group ...
Figure 43 Deleting a storage group

Confirm the operation to delete the storage group:

Figure 44 Confirm the operation

The view and groups have now been removed:
Figure 45 View and groups are removed
Specifying LUN addresses

SMC assigns dynamic LUNs when device masking is performed. When
the devices are mapped to the FA as part of the masking view creation,
Symmetrix Enginuity assigns the next available LUNs to the devices in
the storage group.
If Set Dynamic LUN Addresses... is clicked when the masking view is
created, the devices can be given a range that starts at the specified
value. Individual device LUNs can also be modified.
This host currently has only the ACLX device available to it:

# syminq -sym

---------------------------------- --------------------- ---------------------
---------------------------------- --------------------- ---------------------
An initiator group, storage group, and port group have already been
created for the host.
A masking view can now be created that will mask and map the devices:
Clicking Set Dynamic LUN Addresses... brings up the Set LUN

Addresses dialog box and allows the user to choose a range and also to
manually change individual LUN values.
The first two devices in the device list are gatekeepers. It is common to
assign gatekeepers high LUN values so that they appear at the end of
host or syminq output. In this example, the LUN addresses for the two
gatekeepers (0AC and 0AD) have been changed to 0F0 (240) and 0F1
(241):

After creating the masking view, the devices are available with the
specified dynamic LUN addresses:
# syminq -sym

------------------------------------ --------------------- ---------------------
------------------------------------ --------------------- ---------------------
/dev/rdsk/c3t5000097*18d2s2 M(2) SYMMETRIX 5874 54007B0000 8835840


/dev/rdsk/c3t5000097*18d25s2 M(2) SYMMETRIX 5874 5400ACC000 17675520
/dev/rdsk/c3t5000097*18d240s2 GK SYMMETRIX 5874 54000AC000 5760
/dev/rdsk/c3t5000097*18d241s2 GK SYMMETRIX 5874 54000AD000 5760
Specifying HBA flags

SMC can be used to set port flags on both initiator groups and also on
individual host bus adapters within an initiator group. This functionality
allows multiple operating systems to share FA ports by moving the flags
from the FA port to the HBA or initiator group.
The following flags can be set on the initiator group:
Volume_Set_Addressing [V]
Common_Serial_Number [C]
Disable_Q_Reset_on_UA [D]
Environ_Set [E]
Avoid_Reset_Broadcast [ARB]
AS400 [AS4]
OpenVMS [OVMS]
SCSI_3 [SC3]
SPC2_Protocol_Version [SPC2]
SCSI_Support1 [OS2007]
As the Volume Set Addressing flag affects the LUN addressing scheme
in support of HP-UX environments, it can only be set at the initiator
group level. The V flag prevents LUNs 8 – F from being assigned to a
volume. It is not applicable for any other host environment and must be
set on the port or on the initiator group. The V flag can apply to both
child and parent initiator groups, but must be consistent across them. If
an attempt is made to add an initiator group to another IG to form a
cascaded IG and a child group has the V flag set but the parent does not,
the command will fail:
Note: In many cases, setting a flag at the group level is preferable to setting it
at the initiator level. Setting the flag on the IG propagates the setting to all
initiators in the group and guarantees that any initiators added to the group
at a later time will inherit the same settings.
To view the current flags set on an initiator group:

To set the Disable_Q_Reset_on_UA or D flag on an initiator group, right-

click the masking view and select Device Mapping and Masking >
Initiator Groups Maintenance > Modify Initiator Group….:

Click Set HBA Flags:
Select the flag to set, and check Override and Enable and then click OK
on both dialog boxes:

The Disable_Q_Reset_on_UA is now set on the initiator group and all

initiators belonging to it:

To remove the IG flag that was just set, uncheck both boxes in the Set
HBA Flags dialog box and click OK on both dialog boxes.
To set a flag by using the HBA WWN, expand the list of fibre host bus
adapters, right-click the chosen WWN, and select Device Masking and
Mapping > Set Initiator Attributes:

In the Set Initiator Attributes dialog box, click Set HBA Flags:
Check both the Override and Enable boxes to enable the D bit:

Click OK on both dialog boxes. The flag is now set on the HBA:

To unset the flag on the WWN, uncheck both boxes in the Set HBA Flags
dialog box and click OK on both dialog boxes.
Note: There is some dependency between the OS2007 and SPC2 flags. The
OS2007 flag can only be set or enabled on the initiator or group when the
SPC2 flag is set or enabled on the same initiator or group. The reverse is also
true; the SPC2 flag can not be set, disabled, or turned off while the OS2007
flag is set or enabled.
Overriding port flags

Flags that are set on a port can be overridden. In this case, the ports that
this host are accessing the Symmetrix has the Common Serial Number
(C) flag set. One of the two ports is 7E:0:
# symaccess list hba
Identifier Physical Device Path Symmetrix ID Dir:P

---------------- -------------------------------- ------------ -----
10000000c97683e0 c3t5000097208183D18d160s2 000192601551 07E:0
10000000c97683e1 c4t5000097208183D25d160s2 000192601551 10E:1

The common serial number flag causes the serial number returned in
response to a SCSI inquiry to end in all zeros:
# syminq

---------------------------- --------------------------- ---------------------
---------------------------- --------------------------- ---------------------
/dev/rdsk/c3t5*d0s2 EMC SYMMETRIX 5874 5100278000 4417920
/dev/rdsk/c3t5*d4s2 EMC SYMMETRIX 5874 510027C000 4417920
The IG currently has no port flags set and no port flags overridden:

The flag cannot simply be turned off at the IG level because the IG is not
overriding the flag. It must be turned 'on' at the initiator group to turn on
the override of the flag. It can then be disabled so the override action is
to unset the flag:
Right-click the initiator group, select Device Mapping and Masking >
Initiator Groups Maintenance > Modify Initiator Group. In the Initiator
Group Management – Modify dialog box, click Set HBA Flags:

In the Set HBA Flags dialog box, check Override for the Common Serial
Number flag followed by OK at both dialog boxes:

The C flag is now overridden for the initiators in this IG:
The full serial number, which now includes FA and Port numbers, is

now being displayed in syminq output:

# syminq

---------------------------- --------------------------- ---------------------
---------------------------- --------------------------- ---------------------
/dev/rdsk/c3t5*d4s2 EMC SYMMETRIX 5874 510027C470 4417920
Insuring consistent LUNs across initiators

In some environments, it is a requirement that volumes be given the
same LUN value on all channels. To facilitate this, the -consistent
LUN option can be used when creating initiator groups:
When the Consistent LUN flag is set on an IG and it is added to a

masking view, all volumes in associated storage groups will be assigned

identical LUNs on all channels as mapping and masking are performed

by the Symmetrix.
The Consistent LUN option can apply to both child and parent initiator
groups but must be consistent across them. If an attempt is made to add
an initiator group to another IG to form a cascaded IG and a child group
has the Consistent LUN flag set but the parent does not, the command
will fail:
If this occurs, the flag can be set on the child group, which can then be
added to the parent IG.
More information about using dynamic LUN addressing can be found in
the Symmetrix Dynamic LUN Addressing Technical Note, which is available
on Powerlink:
Conclusion
Mapping and masking devices in previous versions of Solutions Enabler
required a separate operation for each initiator/port combination
through which devices would be accessed. In Solutions Enabler and
SMC 7.0 the Autoprovisioning Groups feature allows the user to create a
group of devices (storage group), a group of director ports (port group),
and a group of host initiators (initiator group), and associate them in a
masking view. When the masking view is created, the devices are
automatically mapped and masked.
After the masking view is created, any objects (devices, ports, or
initiators) added to an existing group automatically become part of the
associated masking view. This means that no additional steps are
necessary to add additional devices, ports, or initiators to an existing
configuration. All necessary operations to make them part of the
configuration are handled automatically by Symmetrix Enginuity once
the objects are added to the applicable group. This reduces the number
of commands needed for mapping and masking devices and allows for
easier storage allocation and de-allocation.
Autoprovisioning Groups makes storage allocation easier and faster,
especially in modern storage environments where fault-tolerant

configurations with clustered hosts as well as multiple paths to devices

are normally required.
Copyright © 2010 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.

All other trademarks used herein are the property of their respective owners.

Storage Provisioning With EMC Symmetrix Autoprovisioning Groups

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Storage Provisioning With EMC Symmetrix Autoprovisioning Groups

Uploaded by

Copyright:

Available Formats

Storage Provisioning

with EMC® Symmetrix®

These technical notes contain information on the following topics:

Executive summary ............................................................................................................................3

Steps for provisioning storage ............................................................................................................... 52

2 Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes

Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes 3

specifically targeted at EMC field technical staff and EMC customers

Conventions used in this document

Provisioning storage using Solution Enabler

Presenting storage to a SYMAPI control host

4 Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes

Figure 1 Creating individual paths to gatekeepers

Steps for provisioning storage

Example of provisioning storage

# symaccess list hba

Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes 5

Identifier Physical Device Path Symmetrix ID Dir:P

Gatekeepers 08F – 092 will be made available on the first path:

# symaccess create view -name mgmtGKpath0 -wwn 10000000c9767816 -dirport 7E:0

# symaccess create view -name mgmtGKpath1 -wwn 10000000c9767817 -dirport 7F:1

# symaccess list view -sid 54

Masking View Name Initiator Group Port Group Storage Group

Device Product Device

This operation may take up to a few minutes. Please be patient...

6 Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes

# symaccess show view mgmtGKpath0 -sid 54

Masking View Name : mgmtGKpath0

Port Group Name : mgmtGKpath0

Storage Group Name : mgmtGKpath0

Sym Dev Host

# symaccess show view mgmtGKpath1 -sid 54

Masking View Name : mgmtGKpath1

Port Group Name : mgmtGKpath1

Storage Group Name : mgmtGKpath1

Sym Dev Host

Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes 7

Additional elements such as initiators, ports, or volumes can be added,

Note: Running symcfg discover is not required; however, the Physical

Presenting storage to a production and a backup host

Figure 2 Storage presented to a production and a backup host

Steps for provisioning storage

8 Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes

Example of provisioning storage

# symdg create proddb_dg

# symdg show proddb_dg

Group Name: proddb_dg

Group Type : REGULAR

Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes 9

Number of STD Devices in Group : 4

Standard (STD) Devices (4):

TGT Devices Locally-associated (4):

Step 2 - Create the production storage group that contains the

# symaccess create -name dbprod_stor -type storage -g proddb_dg -sid 54

# symaccess list -type storage -name dbprod_stor -sid 54 -v

Storage Group Name : dbprod_stor

10 Storage Provisioning With Symmetrix Autoprovisioning Groups Technical Notes

# symaccess show dbprod_stor -type storage -sid 54

Last updated at : 09:47:30 PM on Fri Jan 30,2009

Storage Group Name : dbprod_stor

Masking View Names

# symaccess create -name dbbackup_stor -type storage -g proddb_dg -tgt -sid 54

# symaccess show dbbackup_stor -type storage -sid 54