StudentGuideDMX3 - SYMcfg

Copyright © 2007 EMC Corporation. Do not Copy - All Rights Reserved.
Symmetrix Configuration Management
© 2007 EMC Corporation. All rights reserved.
Welcome to Symmetrix Configuration Management.
Symmetrix Configuration Management -1

Revision History
Rev Number Course Date Revisions
1.0 December, 2004 Complete

2.0 March, 2007 Complete
© 2007 EMC Corporation. All rights reserved. Symmetrix Configuration Management - 2
Copyright © 2007 EMC Corporation. All rights reserved.

These materials may not be copied without EMC's written consent.
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.
EMC, is a registered trademark of EMC Corporation.
All other trademarks used herein are the property of their respective owners.

Symmetrix Configuration Management

Upon completion of this course, you will be able to:
y State the fundamental concepts associated with
Symmetrix configuration management
y Perform Symmetrix configuration changes using the
command line interface
ControlCenter GUI
Symmetrix Management Console (SMC)
© 2007 EMC Corporation. All rights reserved. Symmetrix Configuration Management - 3


Module 1: Configuration Management

Fundamentals
Upon completion of this module, you will be able to:
© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 1
Configuration Management Fundamentals -1

Configuration Manager Introduction
Storage requirements are never permanent. Your needs for storage are most likely to grow over time.
Consequently, the ability to utilize free disk space on your Symmetrix unit to create new storage
devices makes the SYMCLI Configuration Manager a practical tool in expanding your storage
capabilities. You can add many different types of devices to your Symmetrix configuration, such as
devices with various mirroring schemes, static RDF devices, dynamic RDF devices, meta devices,
BCVs, and DRVs. You can also reserve physical disks as dynamic spares that can be invoked against a
failed disk. The Configuration Manager also allows you change an existing device to a different type
of device if you decide that a device needs to perform a different role, needs additional mirror
protection, or needs to have RDF attributes added or removed. Being able to reconfigure existing
devices is useful as your storage requirements and device protections continue to evolve. You can
reserve a number of disks as dynamic spares. The dynamic spare disk is held in reserve to support the
devices of a Symmetrix disk that fails. When a disk fails, the dynamic spare disk is invoked against the
failed disk.

Customer Value
In the past, an EMC customer could have waited several days for a bin file change. Using
Configuration Manager, a customer can perform a configuration change within several minutes to
hours.
The time needed to perform a configuration change depends on the type of change and the equipment
being used. By creating new devices, you can also increase storage capabilities. Using the unmapping
and mapping features, disk storage can be moved among hosts. Changing the device configuration of a
BCV to a mirrored device is an example of the new ability to manipulate configurations.

Capabilities
Using SYMCLI and the ControlCenter console, you can perform configuration control operations on
Symmetrix devices, meta devices, BCV devices, standard devices, DRV devices, device groups, and
director ports. For each type of configuration change operation, there are Symmetrix and host system
impacts that you will need to consider. Therefore, using Configuration Manager is not as simple as
learning new commands. To ensure effective configuration changes, you will need to plan for any of
these functions.

Requirements
The minimum requirements for Configuration Manager are Solutions Enabler 4.2 or greater, Symm 4,
4.8, 5, 5.5, DMX or later, Microcode 5x66 or greater, and at least one visible gatekeeper. A license
key is required to use the symcli symconfigure command. The ControlCenter base license enables
configuration changes via the ControlCenter console. The command line license is not required to
make configuration changes via the GUI. It is important to note that the particular version of software,
microcode, and even the Symmetrix model will influence the types of configuration changes available.
When preparing for configuration changes one of the first steps is to ensure the versions of software
and microcode will support they types of changes you plan to implement.

Creating New HVEs
For the configuration change session, you must define a set of changes within a specified command
file. Each type of Symmetrix configuration change is considered a “Class of Change”. Multiple
changes can be made in one session, but all changes must fall into one operation class. Beginning with
Enginuity version 5669, changes for multiple operation classes can be executed within the same
session. Creation of certain device (configuration) types may require more than one class of command
execution. The following is an overview of each class of change. All classes will be discussed in detail
in the next module. The first class of change is “creating new hyper volume extensions” (HVEs)
which creates new Symmetrix devices. There must be available, unconfigured disk space in the
Symmetrix to create new HVEs.

Deleting HVEs
0000
0014
Free Space
0020
00CB
You can delete one or more Symmetrix devices from the specified Symmetrix array. Deleting a device
frees the space that it once occupied for future use.

Mapping and Unmapping Devices
Mapping devices to ports assigns HVEs to Symmetrix front-end ports, making devices addressable to
attached hosts (zoning and device masking must be done separately). A valid host address must be
assigned to each device when mapping. Unmapping removes devices from front-end ports making
devices unavailable to attached hosts.

Manage Meta Devices
Meta device handling allows you to form and dissolve meta devices, add and remove meta members,
convert concatenated meta devices to striped meta devices and vice versa, and modify stripe size of
striped meta devices.

Converting Devices
You can convert a device’s configuration by adding or removing BCV or DRV attributes or convert an
RDF device from static RDF to dynamic RDF.
Configuration Management Fundamentals - 10

Increasing Mirroring
You can increase device protection by adding a mirror.

Decreasing Mirroring
You can decrease device protection by removing a mirror.

Setting Front-End Port Flags
Setting front-end port attributes allows you to set or reset SCSI or fibre port flags such as the fibre FA
loop ID.

Setting Device Emulation
Setting device emulation allows you to change the emulation of a HVE for example, changing a FBA
device to a Celerra_FBA device.

Setting Device Attributes
Setting device attributes allows you to change or set special attributes on existing HVEs. A common
device attribute is the VCMDB attribute that is set on a single device in a Symmetrix utilizing device
masking.

Setting Symmetrix Metrics
Symmetrix metrics are special settings that apply to an entire Symmetrix cabinet. For example, setting
the RAID_S_Support metric will allow you to control whether or not RAID S devices can be created
on that Symmetrix.

Spare Disk Management
Spare disk management allows you to add a new spare disk or remove an existing spare disk. To add a
spare disk requires an available physical disk (with no HVEs configured).

Swapping RDF Personalities within a RA Group
You can modify a RDF configuration by adding or removing RDF attributes and swapping RDF
source/target attributes for an RA group.

Symmetrix Architectural Overview
Channel adapters/directors are the first logical component of the Symmetrix. They are the interface
between the host and the Symmetrix cache.

SAO
FA05 DF01
0
C
1
D D D
0
C
1
C C D
0
C
1
B B D
0
C
1
A A D
0 C
1 D D D
0 C
1
C C D
0 C
1
B B D
0 C
1
A A D
FA12 DF16
Intelligent cache configurations allow the Symmetrix system to transfer data at electronic memory
speeds that are much faster than physical disk speeds. Symmetrix products are based on the principle
that the working set of data at any given time is relatively small when compared to the total subsystem
storage capacity. When this working set of data is in cache, there is a significant improvement in
performance. The performance improvement achieved depends on both of the following principles:
Locality of Reference — If a given piece of information is used, there is a high probability that a
nearby piece of information will be used shortly thereafter.
Data Reuse — If a given piece of information is used, there is a high probability that it will be reused
shortly thereafter.

Logical Front-End
In a Symmetrix array, a front-end director is a Fibre Channel adapter (FA) card that occupies a slot on
the Symmetrix backplane, or the DMX midplane. The FA card in DMX and older Symmetrix models
provides the interface to a host via a fibre network. In older Symmetrix models, the host to Symmetrix
interface connection could also be a SCSI bus that requires a SCSI adapter (SA) type front-end
director.

Front-End Addressing
Pre-DMX SA
0
D
1
0
C DMX FA
1
0
B
1
0
A
1
The Symmetrix DMX provides the widest range of connectivity options in the industry. It supports
Fibre Channel, ESCON, FICON, and Native Gigabit Ethernet. Additional supported connectivity
options are iSCSI and Celerra NAS gateway.
All channel directors contain four high performance microprocessors. The channel directors process
data from the host and manage access to global memory over a direct matrix (DMX) technology. Each
channel director on the Symmetrix DMX system supports eight internal links to global memory. DMX
technology is used across the Symmetrix system, as it is also designed on to each global memory
director. In addition to DMX technology, each director board includes support for a separate message
matrix for the transfer of control information.

Host Adapter Location
Symmetrix channel directors are single cards that occupy one slot on the Symmetrix backplane. All
channel directors, except parallel channel directors, interface to host channels via interface adapter
cards connected to the opposite side of the backplane. Parallel channel directors interface to hosts via
block multiplexer channels through bus and tag connector panels in the bottom of the Symmetrix
cabinet.

Symmetrix DMX Series Director Pairing
D D D D D D D D M M M M M M M M D D D D D D D D
I I I I I I I I 0 1 2 3 4 5 6 7 I I I I I I I I
R R R R R R R R R R R R R R R R
1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1
0 1 2 3 4 5 6
S S S S S S S S
S S S S S S S S l l l l l l l l S S S S S S S S
l l l l l l l l o o o o o o o o l l l l l l l l
o o o o o o o o t t t t t t t t o o o o o o o o
t t t t t t t t t t t t t t t t
0 1 2 3 4 5 6 7 1 1 1 1 1 1 1 1 8 9 A B C D E F
0 1 2 3 4 5 6 7
BE BE BE BE
B B F F or or F F F F or or F F B B
E E E E FE* FE* E E E E FE* FE* E E E E
In the Symmetrix DMX series, Director pairing along with dual ported drives, provides redundancy for
a disk director or drive path failure. Disk director pairing starts from the outside and works toward the
center of the card cage, directors are paired processor-to-processor using the rule of 17. Notice in the
diagram above, directors 1 and 16 are paired and directors 2 and 15 are paired. Front-end director
pairing configuration is recommended, but not required. Specific director slots can be used for a front-
end or back-end director giving the customer flexibility for enhanced back-end performance or
additional connectivity.

Front-End Hardware Pathway
The front end hardware pathway includes the channel adapter number, the processor, and port number.

Rule of 17
The front end rule of 17 is a recommendation for host cabling to eliminate single points of failure.
Odd numbered and even numbered adapters are connected to different internal buses. In this example
the UNIX host is connected to the odd numbered FA 01 and the even numbered FA 16 (1 + 16 = 17).

Symmetrix Cache
y Memory boards are now referred
to as Global Cache Directors and
contain global shared memory
y Boards are comprised of memory
chips and divided into four
addressable regions
y Symmetrix has a minimum of 2
memory boards and a maximum
of 8. Generally installed in pairs
y Individual cache directors are
available in 2 GB, 4 GB, 8 GB,
16 GB 32GB and 64 GB sizes
y Memory boards are Field
Replaceable Units and “hot
swappable”
Cache is the second logical component of a Symmetrix and is crucial because it processes all
read/write operations. Symmetrix cache operations are based on intelligent cache algorithms allowing
for optimal data speed and performance.

Symmetrix Logical Back-End
A fibre-connected disk director (DF) or non-fibre disk director (DA) provide the back-end interface to
disk arrays. The DF or DA is a card that occupies a slot on the Symmetrix backplane, or DMX
midplane. The CPU chip on these director cards run the Symmetrix Enginuity™ operating system,
which manages access to specific disk drives. These back-end directors transfer data from disk to
cache and destage the write-bound data from cache to disk. Another CPU chip on the front-end
director also runs the Symmetrix Enginuity operating system that handles I/O requests from the host. It
maintains data in cache (based on data access patterns) and determines if a data request can be satisfied
from this cached pattern. Front-end directors and disk directors share the cache area. On a write
request, the front-end director writes data to cache. A disk director later destages this data from cache
to the appropriate physical disk.

Logical Back-End
The Symmetrix disk directors manage the interface to the physical disks, and are responsible for data
movement between the disks and cache. The disks are connected to disk directors through industry-
standard SCSI interfaces with two advanced microprocessors per disk director. The Symmetrix
contains four disk directors.

Back-End Addressing
DF02
C
D
D
C
C D
C
B D
C
A D
The back end address includes the Disk Adapter number, the processor, and interface.

DA Location
The disk directors are located in the card cage next to the channel directors and cache cards. Like the
channel directors, the disk directors are easily accessible from the card cage. The functions of a disk
director include retrieving data from disk, writing data to disk, and performing error verification.

Symmetrix Disks
From the perspective of software running on a host system, a Symmetrix array appears to be a number
of physical devices connected to one or more I/O controllers. A host application addresses each of
these devices using a physical device name. Each physical device defined in the configuration database
has specific set of attributes (such as vendor ID, product ID, revision level, and serial ID). A
Symmetrix device can map to a part of a physical disk or to an entire disk. The part of a physical disk
to which a Symmetrix device is mapped is called a hyper-volume or a hyper. A Symmetrix device may
map to multiple hypers (containing identical copies of data) depending on its mirror configuration.

Pre-DMX Architecture
Cache Disks
All host I/O transactions with the array of Symmetrix disk devices are managed by the Enginuity
operating environment, running in the Symmetrix I/O subsystem (channel directors and disk directors).
Because each of the physical disks are indirectly seen as part of the I/O protocol, Symmetrix devices
are presented to the host with the following configuration or emulation attributes:
Each device has N cylinders. The number is configurable (blocks ÷ 960).
Each cylinder has 15 tracks (heads).
Each device track in a fixed block architecture (FBA) has 64 blocks of 512 bytes.

DMX/DMX-2 Architecture
FA05 Cache DF01 Disks
0 C
1 D D D
0 C
C C D
1
0 C
B B D
1 PBC
0 C
A A D
1
FA12 DF16 0 1 2 3 4 5 6 7 8
0 C
1
D D D
0
C
C PBC
1
C D
0 C
1
B B D
0 C
1
A A D
The Symmetrix DMX features a high-performance, Direct Matrix Architecture (DMX) supporting up to 128 point-to-point
serial connections in the DMX2000/3000 (up to 64 in the DMX1000). Symmetrix DMX technology is distributed across all
channel directors, disk directors, and global memory directors in Symmetrix DMX systems. Enhanced global memory
technology supports multiple regions and 16 connections on each global memory director. In the Direct Matrix
Architecture, contention is minimized because control information and commands are transferred across a separate and
dedicated message matrix. The major components of Symmetrix DMX architecture are the front-end channel directors (and
their interface adapters), global memory directors, and back-end disk directors (and their interface adapters). The matrix
midplane provides configuration flexibility through the slot configuration. Each director slot port is hard-wired point-to-
point to one port on each global memory director board.
The Symmetrix DMX global memory director technology is one of the most crucial components of a Symmetrix system.
All read and write operations transfer data to or from global memory. Any transfers between the host processor, channel
directors, and global memory directors are achieved at much greater electronic speeds than transfers involving disks. Each
Symmetrix DMX global memory director accommodates four separately addressable, simultaneously accessible memory
regions, which greatly reduces the probability of contention for global memory access. Each global memory director is
directly connected to each channel director and disk director through the direct matrix. The enhanced global memory
capabilities of the Symmetrix DMX systems, as a part of the Direct Matrix architecture (DMX), allow the addition of more
global memory directors to dramatically impact system bandwidth and performance compared to previous generations of
Symmetrix systems. The DMX architecture ensures highest performance due to the following:
Requests for global memory are expedited to reduce locking.
Requests are intelligently arbitrated to optimize available resource usage.

DMX-3 Architecture
FA05 Cache DF01 Disk Array
0 C
1 D D D
0 C
C C D
1
0 C DAE
1
B B D
Pri LCC Exp
0 C
A A D
1
4 5 ....... E
FA12 DF16 0 1 2 3
0 C
1
D D D
0 C
C C Pri LCC Exp
1 D
0 C
1
B B D
0 C
1
A A D
DMX3 will support configurations of up to 2,400 drives, and 160 Disk Array Enclosures. Each Storage
Bay may contain up to 16 Disk Array Enclosures with up to 15 drives each for a total of 240 drives per
Storage Bay, and 10 storage bays possibility for 2,400 drives in total. This configuration would involve
daisy chaining Disk Array Enclosures.

Hyper Volume Extensions
Hyper volumes are similar to disk drive partitions in that they provide more than 1 logical volume on a
single disk, while making use of the volume's full formatted capacity. A single disk drive can be split
into multiple logical volumes. The Symmetrix enhances disk system functionality by supporting up to
255 hyper volumes on 1 physical drive. A hyper volume may also be called a logical volume. Over
16,000 logical volumes are supported on a Symmetrix. Hyper volumes are the actual volumes with
which a host communicates, and are configured upon initial Symmetrix setup. Additional volumes can
be dynamically added as the customer requires more capacity.

HVE Considerations - Size
Smallest HVE: Largest HVE (depending on microcode):

1 cylinder (approximately .5 MB) Approximately 32 GB
Hyper volumes created can be of various sizes on a single disk drive. A hyper volume can range in
size from 1 cylinder to approximately 32,510 cylinders (approximately 15 GB). Once megabyte is
equal to 2.1333 cylinders.

HVE Considerations – Max Hypers Per Disk
5x67 microcode: 5x68 microcode: 5x70 and later versions:

32 maximum HVEs per disk 128 maximum HVEs per disk 255 maximum HVEs per disk
When a Symmetrix unit is set up initially, the maximum number of hyper volumes per disk is defined
as a Symmetrix-wide parameter. As devices are configured, the Symmetrix configuration server
creates up to the maximum hypers initially defined.

RAID 1 Protection
In the event of a data loss, a reliable backup medium is the best form of protection. Therefore, a
Symmetrix uses enhanced RAID technology to ensure optimal protection of data. RAID 1, or
Mirroring, is used for mission-critical data that requires the highest performance with continuous data
availability. This data protection method stores identical data on another disk. The mirror is
transparent to the host system.
There are three main features of a mirror:
y Mirrored data automatically invoked if either disk fails
y Symmetrix calls home if a disk fails
y Automatic resynchronization after failed disk is replaced
A dynamic spare is a disk drive that is reserved for use in the event that an active disk begins to fail.
To be viable, a dynamic spare must be same size and geometry of the disk being replaced.

RAID S (Parity RAID) Protection
RAID S (referred to as Parity RAID) is a Symmetrix feature that provides parity data protection on the
device level using a physical parity device. RAID S involves groups and ranks. A RAID S group is a
set of disk drives within a Symmetrix configuration that are interrelated for parity protection. Parity
RAID devices must be created in multiples of 3 or 7. For example, a Parity RAID 3+1 protection
group requires three devices for data and one for shared parity. Any requests to create parity devices
outside of the 3 or 7 multiple factor will be denied. The Symmetrix maps each of device’s data mirrors
to the same mirror positions on a separate hyper and creates one parity device to be shared by the data
devices. The number of Parity RAID (3 or 7 members) devices must be defined in the Symmetrix
Attributes.
Parity RAID is no longer supported as of the DMX3.

RAID 5 Protection
Beginning with EMC Solutions Enabler version 5.4, you can create a RAID-5 device. You can do this
the same way you create a mirrored device. For example, a 2-way-mirror device has two hypers. You
create a RAID-5 device with either four or eight hypers. The difference is in how the data is written to
the hypers. Prior to creating a RAID-S or a RAID-5 device, you need to set a Symmetrix parameter for
the type of RAID protection you are configuring. You also need to set a parameter for the number of
members (3 or 7) that you want in a RAID-S protection group, or the number of hypers (4 or 8) that
you want to form a RAID-5 device

Device Configurations
Gatekeepers, Business Continuance Volumes (BCVs), Dynamic Reallocation Volumes (DRVs), and
meta devices each have unique configuration guidelines. Gatekeepers are normally 6 cylinder FBA
volumes. Gatekeepers can be designated by default or active assignment. A BCV device contains a
copy of data from a standard Symmetrix device which is online for regular I/O operation from the host.
Each BCV device has its own address and needs to be configured as a stand-alone Symmetrix device.
A BCV must be the same size as the data volumes that it will copy. For an Optimizer configuration,
you will need to have two DRVs for each size logical volume that is configured on your Symmetrix.

Gatekeepers
SCSI commands executed by SYMAPI are transferred to the Symmetrix array via a Symmetrix device
that is designated as a gatekeeper device. The gatekeeper allows you to retrieve configuration and
status information from the Symmetrix array without interfering with normal device I/O operations. By
default, one of the available Symmetrix devices is designated as a gatekeeper. Alternatively, you can
define specific devices to be used as gatekeepers.

Standards (STD)
A Symmetrix system applies a high degree of virtualization between what the host sees and the actual
disk drives. A Symmetrix device is not a physical disk. A Symmetrix device is a logical volume with a
name that the host can address. From the perspective of the host, these logical volumes in a Symmetrix
unit appear as physical devices connected to one or more I/O controllers. For a host to “see” the
device, you need to define a path by mapping the device to a front-end director, and then you need to
use host-specific utilities or the EMC I/O scan option (available with the symcfg command)2 to have
the host recognize the device. From the perspective of the open systems host, these logical volumes
appear as physical disk devices at addresses specified by a SCSI target ID and Logical Unit Number
(LUN). However, when fibre is the addressing mechanism and peripheral device addressing is being
used, the fibre switch and arbitrated loop generate an equivalent of the target ID, requiring you to
specify only the LUN when mapping a device. Devices used for production data are considered
“standards” (STD).

Business Continuance Volume (BCV)
The Symmetrix TimeFinder™ is a business continuance solution that allows you to use special
Symmetrix devices called Business Continuance Volumes (BCVs). A BCV device contains a copy of
data from a standard Symmetrix device that is online for regular I/O operation from its host(s). Uses
for the BCV copies can include backup, restore, decision support, and applications testing. Each BCV
device has its own host address, and is configured as a stand-alone Symmetrix device. A business
continuance sequence first involves establishing the BCV device as a mirror of a specific standard
Symmetrix device. As a result, the BCV device becomes inaccessible via its original device address
while it is in an established pair. Once the BCV device is synchronized, it may be separated (split) later
from the standard device with which it is paired. Once split, the BCV device with the synchronized
data becomes available for backup or other host processes through its original device address. Once
host processing on the BCV device is complete, the BCV may again be mirrored to a standard
Symmetrix device, which can either be the same device to which it was previously paired, or a
different device.

SRDF R1/R2 Volumes
The Symmetrix Remote Data Facility (SRDF®) is a business continuance solution that maintains a
mirror image of Symmetrix array data at the device level, which may be located in physically separate
sites. SRDF provides a recovery solution for component or site failures using remotely mirrored
devices. SRDF reduces backup and recovery costs and significantly reduces recovery time after a
disaster. In an SRDF configuration, the individual Symmetrix devices are designated as either a source
(R1) or a target (R2) to synchronize and coordinate SRDF activity. If the source (R1) device fails, the
data on its corresponding target (R2) device can be accessed by the local host. Once the source (R1)
device is replaced, it can be resynchronized. SRDF configurations have at least one source (R1) device
mirrored to one target (R2) device. For concurrent RDF systems, there can be two R2 targets. A source
(R1) device can only belong to an RDF1 device group, while a target (R2) device can only belong to
an RDF2 device group.
Since Enginuity 5568, devices can be configured to be Dynamic RDF-capable devices. Dynamic RDF
functionality enables you to create, delete, and swap SRDF pairs while the Symmetrix array is in
operation. Using Dynamic RDF technology, you can establish SRDF device pairs from non-SRDF
devices, then synchronize and manage them in the same way as configured SRDF pairs. The Dynamic
RDF configuration state of the Symmetrix array must be enabled in SymmWin or via the
Configuration Manager and the devices must be designated as dynamic RDF-capable devices.

Dynamic Reallocation Volume (DRV)
Symmetrix Optimizer is a tool that automatically balances hyper-volume loads across physical disks
within a Symmetrix unit by running a process on the Symmetrix service processor that analyzes hyper-
volume activity. You can create a DRV device (Dynamic Reallocation Volume) for use by Symmetrix
Optimizer to temporarily hold user data while Optimizer reorganizes the devices. Optimizer uses
DRVs in device swapping operations in a manner similar to BCV devices in TimeFinder operations.
This reorganization takes place on the back end of the Symmetrix and is transparent to the host and
end-users. The DRV device maintains the protection level for the device whose backend locations are
being optimized.

R1-BCV
A BCV device can be SRDF protected. This is commonly implemented to support SRDF “Multi-Hop”
configurations, using SRDF/AR (Automated Replication).

Meta Devices
• Can consist of 2 – 255 HVEs
• Largest supported meta device is 3.825 TB
• All meta members should be the same size
• All meta members should be the same type/protection
• All meta member candidates must be unmapped
Meta devices allow individual devices to be concatenated to create larger devices. For Enginuity levels
below 5x66, meta devices must be adjacent Symmetrix devices and are formed by grouping physical
devices that followed each other. For Enginuity 5x66 and above, the devices assigned in a meta
sequence do not need to be adjacent. The meta head is the first device in the meta device and is
responsible for receiving incoming commands. When an incoming command for the meta head is
processed, the Enginuity software determines which meta device member should execute the
command. Several operating systems, such as Windows NT and some open systems environments, can
have larger volumes than are provided by standard Symmetrix physical disk devices. A meta device
(volume) is a logical volume set created from individual Symmetrix hypers to define volumes larger
than the current Symmetrix maximum hyper volume size of approximately 16 GB. Meta volumes
(devices) are functionally the same as logical volume sets implemented with the host volume manager
software. Physically, a meta device is two or more Symmetrix hyper volumes presented to a host as a
single addressable device. It consists of a meta head device, some number of member devices
(optional), and a meta tail device.
Meta devices may contain as many as 255 members. The maximum size meta device that has been
tested by EMC is 3.825 terabytes, which is the maximum size supported at this time. In Enginuity 5x66
and above, Meta devices can be composed of non-sequential and non-adjacent volumes.

Forming Meta Devices
Meta devices may contain as many as 255 members. The maximum size meta device that has been
tested by EMC is 3.825 terabytes, which is the maximum size supported at this time. In Enginuity 5x66
and above, Meta devices can be composed of non-sequential and non-adjacent volumes. By allowing
individual physical disk devices to be grouped together into a meta device (volume) and the capability
of meta device addressing, Symmetrix enhances disk system functionality. To increase throughput and
further improve performance, Symmetrix provides multiple I/O drive queues for meta volumes.
Addressing of data contained in a meta device can be organized in two different ways: Concatenated
devices and Striped devices.

Types of Meta Devices - Concatenated
Concatenated devices are volume sets that are organized with the first byte of data at the beginning of
the first device. Addressing continues to the end of the first device before any data on the next device
is referenced. When writing to a concatenated device, the first meta device member receives all the
data until it is full, then data is directed to the next member and so on.
HVEs do not need to be the same size in a concatenated meta device.

Types of Meta Devices - Striped
A striped meta device is one that places data on meta members in user-defined stripes or chunks
instead of filling an entire device first before addressing the next device. The stripe size (or chunk size)
is the amount of data addressed on one device before moving on to the next device in the meta device.
A stripe size of 1920 blocks (which can also be specified in cylinders as 2 cyl) is the recommended
stripe size and the default when no size is specified.
All HVEs must be the same size in a striped meta device.

Virtual Devices
Virtual Device
Production Device Save Device
Snapshot copies use virtual devices to support EMC Snap operations. A virtual device is a host
accessible device containing track-level location information (pointers), which indicates where the
copy session data is located in the physical storage. Virtual devices consume minimal physical disk
storage, as they store only the address pointers to the data stored on the source device or a pool of save
devices.

Save Devices
Virtual Device
Production Device Save Device
Symmetrix save devices are special devices (not mapped to the host) that provide physical storage
space for pre-update images or changed tracks during a virtual snap copy session. Save devices are a
predefined pool of storage devices and must be configured for this purpose. The save device pool acts
as a group for storing data in striped form. Save devices are assigned a Symmetrix device number and
can be unprotected, mirrored, or parity RAID. They cannot be part of a meta volume or grouped.
Note: Configuring save devices as unprotected is not recommended and requires special approval by
EMC.

Tying Together the Four Logical Components
In Symmetrix systems, the channel directors and disk directors share cache memory. Symmetrix
channel directors attach to the CPU channels as well as to cache memory. Symmetrix disk directors
attach to cache as well as the disk drives. The Symmetrix directors perform the following functions:
The channel director handles I/O requests from the host. It accesses the directory in cache to determine
if the request can be satisfied within the cache. The directory contains information on each cache page
and blocks within each page.
The directors manage cache using various methods that generally result in the implementation of a
Least Recently Used (LRU) algorithm. This usage model ensures that only pages of data that have
been recently accessed remain in cache.
Using the Prefetch Algorithm, the disk director dynamically detects sequential data access patterns to
the disk devices. The directors improve the hit ratio of these accesses by promoting blocks from the
disk devices to cache slots before that data has been requested.
The disk director manages access to the disk drives. When a “read miss” occurs, the disk director also
stages tracks into cache. It also performs a background operation that destages written-to blocks to
disk.

Configuration Manager
The symconfigure command allows you to perform powerful control operations that manage various
types of configuration changes on devices in your Symmetrix environment. You can invoke
symconfigure from the local host to make configuration changes to a locally-connected Symmetrix, or
to an RDF-linked Symmetrix array. The SYMCLI Configuration Component extends the basic
SYMCLI command set to include the symconfigure command on the following platforms:
y Sun Solaris
y Hewlett Packard HP-UX
y Windows NT and Windows 2000
y Tru64 UNIX
y IBM AIX
y Linux
y AS/400 (via client/server)
y Linux S/390

Configuration Manager with SRDF
The Symmetrix Remote Data Facility (SRDF) is a business continuance solution that maintains a
mirror image of data at the device level in Symmetrix systems located in physically separate sites.
SRDF Devices SRDF configurations provide for either a uni-directional or a bi-directional data
transfer over SRDF links between sites. Devices are designated as either R1 (source) or a R2 (target)
devices to synchronize and coordinate SRDF transfer activity. A source R1 device is designated an
RDF1 type, while a target R2 device is designated an RDF2 type. An R1 or an R2 device can also have
associated mirror(s) (M1, M2) for increased protection. These are designated RDF1+Mir or RDF2+Mir
as configuration types when using symconfigure.

Configuration Manager and ControlCenter
Today, companies are storing ever-increasing amounts of information. As enterprise storage networks
become more complex, and storage devices grow in number and size, companies are faced with the
challenge of effectively managing their storage. An enterprise storage network is a collection of
storage resources linked together to provide access to information from multiple platforms, operating
systems, and applications across any combination of SCSI, ESCON, or Fibre Channel technologies.
EMC ControlCenter™ is an integrated family of products that enable you to discover, monitor,
automate, provision and report on networks, host resources, and storage resources across your entire
information environment. From a single console, ControlCenter can monitor and manage:
Connectivity components — Fibre Channel switches and hubs.
Host components — Host operating systems, file systems, volume managers, databases, and backup
applications.
Storage arrays — EMC’s Symmetrix®, CLARiiON®, and other vendors’ storage arrays.
ControlCenter shows a consolidated view of the storage environment, allowing you to monitor the
health of, track the status of, report on, and control each object from a console anywhere on the
network.

Symmetrix Command Line Interface
SYMCLI resides on a host system to monitor and to perform control operations on Symmetrix arrays.
SYMCLI commands are invoked from the host operating system command line (shell). The commands
are linked with SYMAPI library functions. The library functions use system calls that generate low-
level I/O SCSI commands to the Symmetrix arrays. To reduce the number of inquiries from the host to
the Symmetrix arrays, configuration and status information is maintained in a Symmetrix host database
file. On a UNIX system, when you run symcfg discover, the Symmetrix host database file,
symapi_db.bin, is created in: /var/symapi/db. On Windows NT, the database file is found in:
C:\Program Files\EMC\Symapi\db. On Open VMS, the database file is found in: SYMAPI$DB

What is SYMCLI?
The Solutions Enabler (known as SYMCLI) is a specialized library or set of UNIX-formatted

commands that can be invoked one at a time. The SYMCLI (Symmetrix® Command Line Interface) is
used in single command line entries and scripts to monitor and perform control operations on devices
and data objects toward the management of your information storage complex. It also monitors the
Symmetrix configuration and the status of devices that make up the information storage environment.
The target storage environments managed by SYMCLI are typically Symmetrix-based but can be
CLARiiON when you have a license and work with the SYMCLI Storage Resource Management
(SRM) component. For base CLI commands to manage CLARiiON storage, see the EMC Solutions
Enabler Open Storage Base Management CLI Product Guide.

syminq
The syminq command can be used to issue SCSI INQUIRY, and optionally SCSI READ CAPACITY,
on one or all devices. By default, the scope of the command is for all disk devices. You can limit the
scope to Symmetrix, CLARiiON, StorageWorks, or HDS devices. In addition, it can be used to list the
fibre and SCSI HBAs in the local host. This scope of this request can be limited to just fibre or just
SCSI by specifying either the -fibre or -scsi options.

syminq Command
EXAMPLES:
To issue just a SCSI INQUIRY to all Symmetrix devices that are visible to this host, enter:
syminq -sym -nocap
To issue a SCSI INQUIRY and READ CAPACITY to a device, enter:
syminq /dev/rdsk/c2t0d2s3
The following example issues a SCSI INQUIRY and READ CAPACITY command to a device and
displays more detailed, verbose information:
syminq -v /dev/rdsk/c2t0d2s3
The following example requests that the SCSI HBAs in the local host be listed:
syminq hba -scsi

Device Serial Number
For 5568 Enginuity microcode, since the support for number of logical devices per Symmetrix
increased to 8000 devices, the output format returned by syminq has changed. The port number in the
device serial number is now modified to handle this. The device serial number format (SSNNNDDP)
remains, however, if the port number shown is greater than or equal to 8, the Symmetrix device’s name
is greater than FFF. To get the correct port number in these cases, subtract 8 from the P field.
Example with 4 character Symmetrix Device Name, (names above FFF):
Device Serial Number: 23035129
Symmetrix ID: 23 Symmetrix Device Name: 1035 Director: 12A Port: 1
Notice how 8 is added to the port to denote the Symmetrix Device Name is over FFF. It can then be
assumed that the Symmetrix Device Name is 1035 not 035.
Example (with 3 character Symmetrix Device Name):
Device Serial Number: 23035121
Symmetrix ID: 23 Symmetrix Device Name: 035 Director: 12A Port: 1

syminq -pdevfile
Use –pdevfile (lists physical device names in a format for use as pdevfile entries) with the syminq
command to view the information embedded in the serial number in an easy to read format. The
display output can be redirected to a pdev file name for reference.

symdev
The symdev command displays information about all or selected Symmetrix devices regardless of
whether they are visible to the local host. You can release a Device External Lock (DEL) on one or
more specified Symmetrix devices.

symdev Command
EXAMPLES
To list all Symmetrix devices that are configured in Symmetrix arrays connected to this host, enter:
symdev list
To show detailed information about Symmetrix device 000C in a Symmetrix array with the specified
unique ID, enter:
symdev -sid 870 show 000C
To list the first 20 BCV devices starting at Symmetrix device 001F, that are configured in each
Symmetrix array, enter:
symdev list -BCV -RANGE 001F: -N 20
To list (verbose) a range of Symmetrix devices (0000 to 000A) that have a device external lock of 9,
enter:
symdev list -sid 870 -lock 9 -RANGE 0000:000A -v
To release all Symmetrix devices in Symmetrix 870 that have a device external lock of 9, enter:
symdev release -sid 870 -lock 9

symdev list
There are many options and arguments that can be used with the symdev command. This list shows a
few that are helpful when preparing for configuration changes.
-noport Lists the Symmetrix devices that are not mapped to any front-end adapter ports.
-multiport Lists the Symmetrix devices that are mapped to multiple front-end adapter ports.
-DA Lists the Symmetrix devices that are mapped to a certain DA director number. The interface, disk,
and hyper IDs can also be used to confine the list further, but defaults to ALL unless specified.
-space Shows the available or unconfigured storage space for the specified listing of disks.

symdev show
Symdev show: Displays detailed information about a Symmetrix device, given the Symmetrix device
name, such as 000C.

sympd
The sympd command performs operations on a device given the device’s physical name, such as
/dev/rdsk/c3t0d3s2, listing devices by Symmetrix ID and showing device-specific information. The
export command stores the current list of physical device names that the host can see, as well as other
information about the physical device, such as the Symmetrix ID, device number, and director/port to a
file. The verify command compares the current list of physical device names to the ones stored in the
file previously for any differences.

sympd Command
EXAMPLES:
To list all Symmetrix devices visible to this host, enter:
sympd list
To show detailed information about a Symmetrix device, enter:
sympd show /dev/rdsk/c2t0d2s3
The following example lists only Symmetrix devices visible to this host that are mapped to all Fibre
Channel directors, port 0:
sympd -sa all -p 0 -fibre list

sympd show
Sympd show: Displays status information about a Symmetrix device that is visible to this host.

symdg
The symdg command performs operations specific to device groups such as, creating new device
groups, importing ASCII group files, exporting groups to files, translating groups to/from Symmetrix
Manager files, deleting groups, renaming groups, and listing and showing information about a device
group.

symdg command
The SolutionsEnabler Base product manages three types of device groups: REGULAR (non-RDF),
RDF1 (RDF source device), and RDF2 (RDF target device). When you create a device group in an
RDF configuration, you must specify the type of the device group (RDF1 or RDF2). Otherwise, the
group type defaults to REGULAR when no type is specified.
EXAMPLES:
To create a Symmetrix device group, mydg_r1, of type RDF R1, enter:
symdg -type RDF1 create mydg_r1
To list all Symmetrix device groups in detailed format, enter:
symdg -v list
To rename Symmetrix device group mydg_r1 to oradg_rdf1, enter:
symdg rename mydg_r1 oradg_rdf1
To show information about device group oradg_rdf1, enter:
symdg show oradg_rdf1
To delete Symmetrix device group oradg_rdf1, regardless of whether the group has members, an
associated gatekeeper, or BCV devices, enter:
symdg -force delete oradg_rdf1

symdg Output
You can group SRDF (Symmetrix Remote Data Facility) standard devices in a device group subject to
the following restrictions:
You cannot mix SRDF and non-SRDF devices in the same device group.
All SRDF devices in a given device group must be either all source (R1) or all target (R2) devices.
All SRDF devices in a given device group must belong to the same Symmetrix RDF group1 or if
concurrent RDF, then two RA groups.
You can associate Business Continuance Volume (BCV) regular devices and RDF1 BCV devices with
a device group. You can do BCV control operations on any BCV pair in the device group. Also, you
can do RDF operations on just the associated RDF1 BCV devices. You can associate virtual devices
(VDEV) paired with standard and BCV devices with any device group. In addition, TimeFinder/Snap
control operations can be performed on any virtual device in a device group. You can associate one or
more gatekeeper devices with a device group. SYMCLI will use the associated gatekeeper to issue
requests to the Symmetrix for control operations on the devices within the specified device group. You
can add a standard device to a device group. However, the gatekeeper cannot be added to the device
group, only associated with a device group.
Note: A BCV device or a RDF2 device cannot be assigned as a gatekeeper, nor can a device that is a
member of a device group be defined as a gatekeeper.
Symdg list: Lists all the device groups that have been created for this host.

symld
The symld command performs operations specific to a device in a device group: adds a device to a
device group, adds all available devices to a device group, lists all devices in a device group,
removes/moves a device or all devices from a device group, renames a device in a device group, and
shows detailed information about a device in a device group. The symld command is also used to write
enable or write disable one or all devices, or front-end directors, in a device group. The symld
command can also be used to break device reservations for one or more devices in a device group.

symld Command
EXAMPLES:
To add a Symmetrix host device to group prod and assign a logical device name temp1, enter:
symld -g prod add pd c2t0d2s2 temp1
To add a Symmetrix device to group ProdDB and assign a logical device name temp2, enter:
symld -g ProdDB add dev 001C temp2
To list all devices in device group ProdDB, enter:
symld -g ProdDB list
To rename device DEV001 to log1 in group ProdDB, enter:
symld -g ProdDB rename DEV001 log1
To remove device log1 from device group ProdDB, enter:
symld -g ProdDB remove log1
To write-disable devices DEV001, DEV005, and DEV016 in group ProdDB, enter:
symld -g ProdDB write_disable DEV001 DEV005 DEV016

symld Output
To write-disable a device prior to unmapping it from a front-end director port, use:
symld –g dgname write_disable DEVxxx –sa xx –p x

or
symdev write_disable xxxx –sa xx –p x
Device groups, as well as the devices in a device group, are assigned names that facilitate reference in
a session. You assign a device group name at the time you create it. The name can have up to 31
characters and must be unique for a given configuration database. When you add a device to a device
group, it is given a logical name. This name allows you to refer to the device independently of its
physical device name or Symmetrix device name. The name can have up to 31 characters and must be
unique within the device group. It is known only within the context of the device group to which the
device belongs. You must use this logical name in any SYMCLI command that has the argument
LdevName or ld.

symcfg
The symcfg command is used to discover a Symmetrix configuration, refresh the Symmetrix
configuration database file, and display configuration information about the Symmetrix arrays attached
to the host and/or any of its directors. The symcfg command can be used to view whether the specified
Symmetrix array(s) have an exclusive Symmetrix lock. You can release the lock if it is hanging. The
symcfg command can be used to set one or all RDF RA or SA directors on a locally-attached
Symmetrix array to either online or offline from the Symmetrix configuration database. The symcfg
command can be used to display the LRU cache management configuration of a Symmetrix array. It
can also be used to list the services entered in the network services file (netcnfg) or list all the UNIX
gatekeeper, database, and lock file semaphores. It can display application and host registration, and
port connection information. In addition, some arrays require authorization information to provide to
access the array. The symcfg authorization command can be used to supply this information for use in
subsequent discovery operations. The symcfg authorization command allows you to list, add, update or
delete this connectivity information. Update allows you to update the password of an existing entry.

symcfg Command
To reduce the number of inquiries from the host to the storage arrays, configuration and status
information is maintained in a Symmetrix host database file (called the Symmetrix configuration
database). On a UNIX system, when you run symcfg discover, a Symmetrix configuration database
file, symapi_db.bin, is created in: /usr/storapi/bin On Windows, the configuration database file is
created in: c:\Program Files\EMC\WideSky\bin

symcfg Output
EXAMPLES
To discover all Symmetrix arrays connected to this host and to build/rebuild the Symmetrix
configuration database file from information gathered, enter:
symcfg discover
To display information about the attached Symmetrix arrays, enter:
symcfg list
To display information about all front-end directors for the specified Symmetrix array, enter:
symcfg list -SA ALL -sid 710
To list all gatekeeper and database semaphores, enter:
symcfg list -semaphores
To verify whether the Symmetrix 0098 configuration and the Symmetrix configuration database are in
sync, enter:
symcfg verify -sid 0098

symcfg list Options
There are many options and arguments that can be used with the symcfg command. This list shows a
few that are helpful when preparing for configuration changes.
-v: Provides a more detailed, verbose listing.
-SA: Confines the action to a front-end (SCSI or Fibre) director number. To select all front-end
director numbers, specify ALL.
-P: Identifies a specific (SCSI or Fibre) port of a front-end director.
-available: Requests the next available Vbus, TID, or LUN address be appended to the output list.
Used with the -address option.
-address: Lists the Vbus, TID, and LUN addresses associated with devices mapped to the front-end
directors.

symcfg –ra all list
The symcfg –ra all list command can be used to display RA group information.

Module 1: Summary
Key Points covered in this module:
y Fundamental concepts associated with Symmetrix
configuration management


Module 2: Configuration Management CLI

y Perform configuration changes using the command line
interface
© 2007 EMC Corporation. All rights reserved. Configuration Management CLI - 1
Configuration Management CLI -1

Command Structure
The symconfigure command allows the advanced user more powerful control to manage various types
of configuration changes affecting Symmetrix devices than otherwise provided by the SYMCLI set.
Most SYMCLI commands, including the symconfigure command can operate on Symmetrix systems
and devices that are either directly attached to the user’s host, or are accessible via an RDF link. This
command allows you to modify Symmetrix devices, ports, RDF characteristics, host assignments, and
create or delete Symmetrix devices. A lock on the Symmetrix configuration is engaged by the
configuration server during the configuration change session. A session is processed in a series of
progressive stages (preview, prepare, commit), which can be monitored using polling options. Not all
stages are always executed. Use discretion when controlling which stages are to be completed to allow
checking and debugging of the command files before the changes are implemented. The stages are:
preview, prepare, and commit.
<Continued>

Command Structure (Continued)
SYNTAX
symconfigure -h
symconfigure list -sid SymmID [-v | -freespace [-units cylinders | MB]]
symconfigure -sid SymmID [-noprompt][-noecho|-v]
[-i Interval][-c Count]
[-f[ile] Cmd_Filename | (redirect stdin)]
preview
prepare
commit
symconfigure verify -sid SymmID
symconfigure query -sid SymmID [-i Interval][-c Count] [-v]
symconfigure abort -sid SymmID
symconfigure -version [-v] [-sid SymmID]

Symmetrix Lock
The Symmetrix configuration server engages a configuration lock (known as lock 15 or lock F) on the
Symmetrix during the change session, blocking others from attempting to change the configuration.
The lock is released at the end of the session or if the session is aborted. The time held by the
configuration lock and the lock itself can be viewed by entering the following command: symcfg list –
lockn 15 Symmetrix device locks are used to prevent other control operations (i.e., SRDF, TimeFinder)
from performing on devices being modified by a configuration change session. Device locks are
engaged by the SYMAPI during the preview stage. Device locks are retained until the configuration
change session has completed and changes have been activated on the Symmetrix. To view a list of the
locked devices on the Symmetrix, use the symdev list -lock command. Device locking is also engaged
by the other Symmetrix control operations for blocking devices during control actions. EMC’s
TimeFinder Snap operations allow for devices to be marked as held, to be available for snap session
copies. Devices are attached and detached as snap target devices using the symsnap attach or detach
command. Held devices are set as Not Ready to the host and are not available for configuration
changes. To view a list of devices currently held, use the symdev list -held command. When swapping
the locations of Symmetrix device hyper volumes to produce optimum Symmetrix performance, the
Symmetrix Optimizer uses the same configuration change mechanism used by symconfigure. Because
only one application can be changing the Symmetrix configuration at a time, one application will fail.
If you think contention may arise between Optimizer swapping and the Configuration Manager, you
can disable the Optimizer during configuration change sessions using the symoptmz -sid SymmID
disable command.

symconfigure -h
Symconfigure –h: Provides brief, online help information including definitions and syntax.

symconfigure -version
Symconfigure –version: Lists the SYMCLI, SYMAPI, and configuration server version information.
Connects to the configuration server managing the Symmetrix configuration for version information.
The –sid option is required if the host is connected to more than one Symmetrix array.

Verifying Communication
Symconfigure verify: Verifies that the configuration currently running in the specified Symmetrix
array complies with the requirements for the host-based configuration changes.

symconfigure Verify
Configuration changes initiated by the symconfigure command should be performed only by advanced
users or system administrators to avoid potential issues. As with any critical operation, planning plays
an important role. Before making configuration changes, you should observe the following
precautionary guidelines:
Understand your current Symmetrix configuration and how the devices are being used by host systems.
Determine your new requirements and thoroughly understand the proposed reconfiguration prior to
making any changes. Document the proposed changes to the configuration.
Ensure that your critical data is safely preserved. Do not store data on any device that is not mirrored.
Verify that a configuration change session can be performed on the Symmetrix unit. This command
makes sure that all the requirements for the host and the Symmetrix are correct. For example:
symconfigure verify –sid 120
If possible, stop I/O activity on all Symmetrix devices to be altered (by making the devices Not Ready
or Write Disabled) before invoking the commit action. Heavy I/O activity on affected devices impacts
the length of time it takes to commit changes.
Determine if your configuration change is in a change class that requires unmapping the devices before
the configuration change session is initiated.

symconfigure query
Monitoring a change session can be useful in checking the status of a change session, especially during
changes to SRDF environments where a change to a Symmetrix unit attached to the local host activates
a change to a remote Symmetrix unit. The system administrator of a host connected to the remote
Symmetrix unit can monitor the progress of the change. A query operation is also helpful at sites where
Symmetrix Optimizer is used to modify the backend volume configuration. To monitor the
configuration change session while the symconfigure commit operation is processing, you can issue
the symconfigure query command or use the UNIX tail command (with the –f option) to interactively
monitor the SYMAPI log file from a second window. The following query checks the status of the
change session on the Symmetrix unit (sid 120) twelve times at 10-second intervals. If you omit the –c
option, the query checks every 10 seconds until the processing completes.
symconfigure –sid 120 query –i 10 –c 12

Aborting a Hung Session
You can attempt to abort a hung configuration change session. The abort action also releases the
configuration session lock. To abort a change session on Symmetrix 000000012345, enter:
symconfigure -sid 45 abort
Since changes made in the RDF operations class will initiate actions on the local Symmetrix and on the
remote Symmetrix, it might become necessary to abort processing on a remote Symmetrix. At some
point during commit processing, a point of no return is reached. Any attempt to abort will be denied
once processing has reached this point.
Configuration Management CLI - 10

symconfigure abort
You can attempt to abort a hung session. The abort action also releases the configuration session lock.
To abort a change session on Symmetrix 000000012345, enter:
symconfigure -sid 45 abort
Since changes made in the RDF operations class will initiate actions on the local Symmetrix and on the
remote Symmetrix, it might become necessary to abort processing on a remote Symmetrix.

symconfigure Arguments - Preview
A session is processed in a series of progressive stages (preview, prepare, commit), which can be
monitored using polling options. Not all stages are always executed. Use discretion when controlling
which stages are to be completed to allow checking and debugging of the command files before the
changes are implemented. The preview argument verifies the syntax and correctness of each individual
change defined and then terminates the session without change execution.

Preview Output
To preview a command file that references Symmetrix 000000012345, enter:

symconfigure -sid 45 –v -f Cmd_Filename preview

symconfigure Arguments - Prepare
The prepare argument will perform the preview checks and also verify the appropriateness of the
resulting configuration definition against the current state of the Symmetrix; then terminates the
session without change execution.

Prepare Output
To prepare a command file that references Symmetrix 000000012345, enter:

symconfigure -sid 45 –v -f Cmd_Filename prepare

symconfigure Arguments - Commit
The commit argument completes all stages and executes the changes in the specified Symmetrix array.

Commit Output
No configuration change is activated in the Symmetrix system until you commit the action. Some
classes of change operations may or may not impact current I/O. When possible, before you commit
any action, stop I/O activity on the Symmetrix devices to be altered during a configuration change
session. Consider the Impact on I/O statement for each class of operation before working on any online
devices. The overall processing time for the changes can vary from 5 minutes to over an hour,
depending on the class of changes. RDF changes will also be applied to the remote Symmetrix array.
Even more time is needed if the devices are to be synchronized. Ensure that all your critical data is
preserved and safe when creating new or changing device configurations. Do not store data on any
device that is not mirrored. All final configurations and device attribute adjustments must meet certain
Open Systems guidelines put forth in the tables of the EMC Symmetrix Support Matrix. You can find
the EMC Symmetrix Support Matrix on the EMC Powerlink™ Web site at: http://powerlink.emc.com
CAUTION: Contact the EMC Customer Support Center for assistance in reverting to your previous
configuration should there be unforeseen problems with the new configuration.

SYMAPI Log
SYMCLI and SYMAPI normally log significant events and actions to a daily log file.
On UNIX, the log file has the following (default) pathname:
/var/symapi/log/symapi-yyyymmdd.log
On Windows NT, the log file has the following (default) pathname:
C:\Program Files\EMC\Symapi\log\symapi-yyyymmdd.log
where: yyyy — year, mm — month, dd — day
The log displays the following items concerning each event:
Time tag of the event occurrence
Process ID (PID)
Source of the event (application name)
Related (internal) API function call
Name of the specific operation or event
Variable event field that describes in detail the event or error
Note: Log files accumulate over time and can consume needed disk space. Periodically, you may need
to purge the log files to conserve space.

Command Files
Command File Guidelines:
• Hatch marks " # " are used for remarks for UNIX and Windows
• White space in the command file is ignored
• Each statement must end with a semicolon " ; "
• Commas " , " are optional
• The command file is case insensitive
• The elements in a statement must be in the appropriate order
• There can be as many statements in one command file as desired
For the configuration change session, you must define a set of changes within a specified command
file. The symconfigure command file format contains various command entries terminated with a
semicolon (;). Multiple changes can be made is one session, but all changes must fall into one
operation class. Command file examples are provided with the actions described later in this module.
Beginning with Enginuity version 5669, changes for multiple operation classes can be executed within
the same session. However, the existing Symmetrix configuration must be valid for each change in the
command file. A given change can not be dependant on a previous change in the same command file.
For example, you can not create a new HVE and map that new HVE to a front-end port in the same
command file.
The command file is formatted uniquely for each type of configuration change. The following are
command file guidelines:
Hatch marks " # " are used for remarks for both UNIX and Windows.
White space in the command file is ignored.
Each statement must end with a semicolon " ; ".
Commas " , " are optional.
The command file is case insensitive.
The elements which make up a statement must be in the appropriate order.
There can be as many statements in one command file as desired.

Command File Argument
Each class of change will have command file arguments that are specific to the type of configuration
changes involved. This list illustrates the variety of command file arguments. Each of these will be
discussed as they pertain to a specific class of change.

Configuration Management Availability
The availability of configuration change operations will vary depending on the version of Symmetrix
Enginuity and the version of Solutions Enabler. When planning configuration changes validate all
potential configuration changes are supported by your current operating environment. The engineering
white paper titled “Using the SYMCLI Configuration Manager” should be used as a reference when
planning configuration changes.

Configuration Management Availability
This table is from the EMC Solutions Enabler Symmetrix Array Controls CLI Version 6.3 Product
Guide. See the product guide for the complete list of supported Symmetrix configuration changes.

Creating HVEs - Considerations
Creating new hyper volume extensions is considered one class of change. Creation of certain device types may require
more than one class of command execution (for example a RDF protected BCV). The Symmetrix must have enough
unconfigured disk space in order to create new devices. There are restrictions on the use of unprotected standard devices
created by symconfigure. Such devices cannot be mapped to hosts for data storage. If an unprotected device is intended for
use as a gatekeeper, it should be created with 20 cylinders or less in order to be mapped to a host. When you make a request
to create a new device, you are creating a Symmetrix device that the Symmetrix system maps to a physical disk on the back
end. In applying a logical volume configuration to physical disks, the Symmetrix system applies the following rules: The
number of hypers on all disks should be roughly the same. All the mirrors or hypers created as a result of the create dev
command file entry must be on different physical disks with different access paths (memory bus, disk directors, disk
interfaces).
Consider the following guidelines when creating new hyper volume extensions:
Creating new HVEs lowers the write pending ceiling per device.
For mirrored HVEs to be created, free space must abide by the rule of 17 (pre DMX).
If a hot spare is invoked or if a device is in a Not Ready state, a commit will not succeed.
You cannot create or convert to SRDF device types: When Domino mode is enabled on any current SRDF pairs; when
there are any invalid tracks on any of the current SRDF devices; or when concurrent RDF is enabled on a device.
When creating devices in an z/OS environment, all new devices must have the same MVS SSID and any remote devices
must also have the same remote MVS SSID within a single session. To create devices with different SSID values, you will
need to run more than one session.
Keep in mind that creating a new device is only one step in the multi-step process required to make the device ready for
use. Some types of new devices require only the step that maps the device to one or more front-end directors. Other types
require additional steps.

Mirror Set Protection Schemes
After deciding on the logical device size, the next configuration consideration is the level of protection
needed for the data. Using Configuration Manager, it is possible to create unprotected storage. Keep
in mind that EMC considers having unprotected storage an unsupported configuration.
Supported configurations with data locally unprotected include:
BCV
DRV
Host Level Mirroring
SRDF (with links up)

This table is from the EMC Solutions Enabler Symmetrix Array Controls CLI Version 6.3 Product
Guide.

Free Space Considerations
The symconfigure list -freespace command displays the Symmetrix unit’s free physical disk space that
you can use to create new devices. The Unformatted column shows free disk space available for any
emulation mode. The Formatted column shows free space on disks that have been partially used for
devices configured with the same emulation mode. The free space on formatted disks can be used only
to create new devices of the same emulation mode. To display free space in megabytes rather than
cylinders (the default), include the –units MB option on the command line.

Symconfigure –freespace Output
The output of the symconfigure –fresspace command enables you to view how much available
“unformatted” disk space is in the Symmetrix.

Device Sizes
If creating BCVs for Timefinder or DRVs for Optimizer, ensure that these devices match the same size
as the STDs that they will be paired with. EMC identifies device size in cylinder counts.

Creating New HVEs Procedure
I/O activity occurring on a Symmetrix device before or during a commit action may cause the commit
action to fail. At the very least, I/O activity on affected devices will impact the length of time that it
takes to complete the configuration changes (for example, when adding a mirror). Some classes of
configuration change operations, such as completely changing how a device will be used in the storage
environment, require stopping I/O operations to that device (for example, before unmapping a device).
If you need to stop I/O activity on any Symmetrix devices that will be altered by the change, shut
down your application, unmount file systems, and suspend I/O before you issue a symconfigure
commit command. In cases where there can be no I/O to a device prior to a change operation, the
command will fail if this condition has not been satisfied.

Creating New HVEs - Verify
Verify that you can open a session on the service processor.

Example: symconfigure -sid 23 verify

Identify Free Space
Identify free space location.

Example: symdev list -da all –space or symdisk list

Create Command File
Create the command file.

Example:
create dev count=2 size=8000 emulation=fba config=2-way-mir;

Command File Syntax
Beginning with Solutions Enabler version 5.3 and Enginuity version 5670, the Configuration Manager
allows you to delete Symmetrix devices. However, a number of restrictions apply. The device to be
deleted must be one of the following emulation types: FBA, CELERRA_FBA, VME_512_FBA,
AS400_590, AS400_590R, AS400_6713_30, AS400_6713_50, AS400_6717_50, AS400_9337_5AA,
AS400_9337_5AC.
The device to be deleted cannot have an attached BCV or DRV and cannot have any snap sessions.
Also the device cannot be:
Mapped to a front end port
Masked by VCM
Held
A virtual device that is in use
A DRV device or BCV device (allowed with Solutions Enabler version 5.4 or higher)
A meta head or a meta member
WORM protected
The VCM database device
An SFS device
Part of an RDF consistency enabled composite group
A SAVE device or a COVD device
Command File Parameters
Emulation
Remote_config
Cylinder
Device_configuration
Ra_group
Count
Size
MVS_ssid
Remote_MVS_ssid
This list represents common command file parameters when creating new hyper volumes.
count = the number of devices to create.
size = the size of the device needed in number of cylinders.
emulation = the device emulation type
config = the device configuration type.
remote_config = the remote SRDF configuration
ra_group = the RA group number in the SRDF environment.
remote_mvs_ssid = When creating an RDF device in a remote Symmetrix array that also contains
CKD devices, a z/OS (MVS) subsystem ID (remote_mvs_ssid) value may be provided.
mvs_ssid = When creating a device in a Symmetrix array that also contains CKD devices, an z/OS
(MVS) subsystem ID (mvs_ssid) value may be provided.
ckd_meta = When creating a device with emulation type of CKD-3380 or CKD-3390, indicates that
the device should be a striped meta device.
savedev = When creating a device, this indicates that the device should be a save device.
disk_group_num = When creating a device, this option allows you to specify a disk group.
remote_disk_group_num = When creating a device, this option allows you to specify a remote disk
group.
Run symconfigure
Run the symconfigure command.

Example: symconfigure –sid 23 –v –f filename commit

Update symapi_db.bin
Update the symapi_db.bin on all attached servers running Solutions Enabler.

Example: symcfg discover

Confirm New Devices
Confirm new devices were created.

Example: symdev list

Mapping and Unmapping - Considerations
To access a new device from a host system, you need to map the device to one or more front-end
director ports and then update the host and the SYMAPI database. Front-end mapping is a Symmetrix
mechanism for exporting the logical view of a device to a host system. After you map a device, the
host is usually unaware of it until you run a host utility that allows the host to address the new device.
To map a device, use the map command file entry to specify the front-end director number and port
number. For FBA devices specify the logical unit number (LUN) for SCSI or fibre, the target ID for
SCSI, the Virtual bus (vbus) address for mapping to a fibre adapter (FA) port if volume set addressing
is being used (for HP-UX) or (if volume set addressing is not being used) only the LUN. For CKD
devices specify the CKD device number (when mapping a CKD device to an OS/390 host). If also
updating a device masking database specify the HBA identifier (WWN, AWWN, or ISCSI name).
After mapping/unmapping devices update the server and then update the symapi_db.bin with the
symcfg discover command. If the VCM_State bit is enabled make sure the mapped device is in the
VCMDB and the VCMDB is refreshed to the channel directors. Alternately, this can be done by
including the WWPN of the HBA as part of the mapping command file. When using a switch, be sure
the mapped port is properly zoned. Remember the target, LUN and virtual bus emulated on the
Symmetrix are always in hexadecimal format while the server is usually in decimal format.

Device Addressing - SCSI
SCSI connections require each hyper volume to emulate a SCSI target ID and LUN when mapped to a
front end port. The selected TIDs and LUNs must be available and supported on the host.

Device Addressing - Peripheral
Peripheral addressing is used for fibre channel hosts (except HP-UX). In this case each HVE mapped
to a FA port must emulate a LUN only. The FA will emulate the target ID.

Device Addressing – Volume Set
HP-UX currently uses only the Volume Set addressing method for accessing Fibre Channel devices.
Volume Set addressing supports up
to 16,384 addresses and up to 512 logical devices (depending on the type of host bus adapter used). In
this case each HVE must emulate a target, LUN, and a virtual bus. The virtual bus number creates
multiple logical controllers for each HBA thereby allowing for maximum possible addresses.

Mapping Procedure
When mapping there is no restriction on I/O if you are adding a second path to a device that is already
mapped. After committing a symconfigure mapping operation, you must update the device mapping
information within the host system environment. Attempting host activity with a device after it has
been removed or altered, but before you have updated the host’s device information, can cause host
errors. To update your hosts, run the utilities specified for your platform. After the host environment is
updated, I/O activity can resume with the Symmetrix device.

Verify Session


Select Devices to Map
Select the device(s) to map.

Example: symdev list or symdev list –noport

Determine Available Host Addresses
Determine available host addresses.

Example: symcfg list –available –addresses –sa 5a –p 0

Create Command File

For peripheral device addressing (FC-SW or FC-AL) and to automatically update/refresh the VCMDB:
Example: map dev 1f2 to dir 5b:0, lun=1f wwn=10000000c9224fa8;
For SCSI:
Example: map dev aa to dir 4a:1, target=a, lun=1d;
For fibre FC-SW or FC-AL with using volume set addressing:
Example: map dev c to dir 12a:1, vbus=1, target=5, lun=12;

Command File Syntax
You can map or unmap devices to front-end directors and their ports. This is the Symmetrix Device
Reallocation (SDR) feature.
To map a Symmetrix device to a director and port, use the following command:
map dev SymDevName to dir DirectorNum:PortNum
[target=ScsiTarget,] lun=ScsiLun
[, vbus=FibreVbus]
[, awwn=awwn|wwn=wwn|iscsi=iscsi];
where:
Starting=the starting address for the range of devices
target = the SCSI target ID (hex value).
lun = the SCSI logical unit number (hex value).
vbus = the virtual bus (vbus) address for mapping to an FA port if using volume set addressing.
emulation=indicates that the device’s emulation type is Celerra_FBA.
awwn = the user given name or alias WWN of a host HBA port, if updating a VCM database.
wwn = the unique 64-bit World Wide Name (WWN) identifier for an HBA port, if updating a VCM
database.
iscsi = the iSCSI name, if updating a VCM database.
Run symconfigure


Update the Server
NOTE:
Zoning and LUN Masking
should be completed before
updating the server.
Update the server:

Solaris: devfsadm
HP: ioscan -FnC disk and insf –e
AIX: cfgmgr
Windows: reboot or rescan



Verify Devices are Mapped
Verify devices are mapped.

Example: symdev list –sa 4a –p 1

Unmapping HVEs Procedure
Consider the following when unmapping devices:

Never unmap a busy device.
Once a device is unmapped on all ports it is automatically RW enabled.
When unmapping a range of devices (if one device is already unmapped) the command will fail.
Never unmap a gatekeeper you’re using unless you already have another gatekeeper available to your
host.

Verify Session


Select Devices to Unmap
Select the device(s) to unmap.

symdev list
If selecting device(s) on a specific port to unmap:
symdev list –sa xx –p x
If you need to see device(s) mapped to multiple ports:
symdev list -multiport
If you need see one device's mapping information:
symdev show xxx
Example:
symdev show 35

Stop I/O on Affected Devices
Stop I/O to devices that will be unmapped.

(unmount, vary off, remove drive letter, etc.)

Write Disable Devices
To write-disable a device prior to unmapping it from a front-end director port, use:
symld –g dgname write_disable DEVxxx –sa xx –p x

or
Place unmapping candidates in a device group if not already in one so they can be write disabled.
To create a regular type of device group:
symdg create unmapdg
Add device(s) to device group:
symld -g unmapdg add dev 55
To add a range of devices:
symld -g unmapr1dg addall dev -range 34:3f
To write-disable a device on all ports:
symld -g unmapdg write_disable
To write disable a device on a select port:
symld -g unmapdg write_disable -sa 5a -p 1
It is also possible to write-disable a device without using device groups by using the following
command:

Create Command File
Create the command file:

To unmap a range of devices:
unmap dev ff:100 from dir 12a:0;
To unmap a device:
unmap dev 101 from dir 4a:0;
To unmap devices from all directors:
unmap dev ccd from dir all:all;

Command File Syntax
You can map or unmap devices to front-end directors and their ports. This is the Symmetrix Device
Reallocation (SDR) feature. To map a Symmetrix device to a director and port, use the following
command:
map dev SymDevName to dir DirectorNum:PortNum
[target=ScsiTarget,] lun=ScsiLun
[, vbus=FibreVbus]
[, device_number=ckd_device_number]
[, awwn=awwn|wwn=wwn|iscsi=iscsi];
where:
device_number = the CKD device number, when mapping a CKD device to an OS/390 host.
database.
Director_num
Fibre_vbus
Port_number
SCSI_LUN
SCSI_target
symdevname
This list represents common command file parameters when mapping or unmapping devices
Director_num = director and port number
Symdevname = device to be mapped
These additional parameters may apply to some configurations.
device_number = the CKD device number, when mapping a CKD device to an OS/390 host.
database.

Run symconfigure


Update the Server
Update the server:

Solaris: devfsadm
HP: ioscan -FnC disk and insf –e
AIX: cfgmgr
Windows: reboot or rescan



Verify Devices are Unmapped
Verify the devices are unmapped.

symdev list
or
symdev list –noport

Meta Device Considerations
• Can consist of 2 – 255 HVEs
• Largest supported meta device is 3.825 TB
• All meta members should be the same size
• All meta members should be the same type/protection
• All meta member candidates must be unmapped
A meta device is two or more Symmetrix hyper volumes presented to a host as a single addressable
device. It consists of a meta head device, some number of member devices (optional), and a meta tail
device. For Enginuity levels below 5x66, meta devices must be adjacent Symmetrix devices (formed
from devices with sequential Symmetrix device numbers). For 5x66 microcode and above, the devices
assigned in a meta sequence do not need to be adjacent.
The meta head is the first device in the meta device and is responsible for receiving incoming
commands. When an incoming command for the meta head is processed, the Symmetrix determines
which meta device member should execute the command.
Several operating systems, such as Windows NT and some open systems environments, can have
larger volumes than are provided by standard Symmetrix devices. A meta device (volume) is a logical
volume set created from individual Symmetrix hyper volumes to define volumes larger than the
current Symmetrix maximum hyper volume size of approximately 15 GB. Meta devices are
functionally the same as logical volume sets implemented with host volume manager software.

Meta Device Types - Concatenated
Concatenated devices are volume sets that are organized with the first byte of data at the beginning of
the first device. Addressing continues to the end of the first device before any data on the next device
is referenced. When writing to a concatenated device, the first meta device member receives all the
data until it is full, then data is directed to the next member and so on.

Meta Device Types - Striped
With random I/O, striping data across multiple disk drives benefits random reads by avoiding the
stacking of multiple reads to a single spindle and disk director. All patterns of I/O access are random
across all members of the striped meta device. With sequential I/O, when there are many sequential
I/Os pending, striping causes data to be uniformly spread out. All the Symmetrix disk spindles
associated with members of the striped meta device are employed to improve I/O throughput. Striping
is unrelated to data protection. Striping is simply a method of placing data on members of the meta
device to enhance performance.

Meta Stripe Size
This chart correlates stripe sizes and stripe capacity. When creating striped meta devices, you can
specify stripe size either in blocks (the default) or in cylinders (you must specify cyl in the command
file).

Meta Device Guidelines
Creating meta devices is a multi-step process. For example, creating a meta RDF device requires three
steps: creating devices, forming a meta device from these devices, and then converting the meta head
device to an RDF device. This table shows the configuration change sessions required to form different
types of meta devices: create, form, and convert.

Data Preservation
When using the symconfigure command to manage meta devices, the data on the devices is not
impacted. However, due to the reconfiguration of the changed meta device, the host may be unable to
access the original data. Therefore, it is the responsibility of the attached host to handle the change to
the physical geometry of the device. In general, it is wise to assume that any meta device configuration
operation will affect the integrity of the data on the devices involved in that operation. When you issue
a command to create a meta device, the meta members lose their independent identities and are no
longer addressable by the host. In particular, you should ensure that critical data that exists on devices
that will be formed into meta devices is preserved before the meta device is created. Take care to
ensure that configuring a meta device does not risk any critical data on the devices that you use to form
the meta device. This table shows how meta device operations impact the preservation of stored data
on the devices that become meta members. The engineering white paper titled “Using the SYMCLI
Configuration Manager” should be used as a reference when planning configuration changes.

Forming Meta Devices
Devices must be unmapped before configuring them as either meta heads or meta members. If not, the
form command for meta devices will be rejected. If you want to form SRDF-meta devices, you will
need to perform several steps. SRDF devices cannot be converted into meta devices in one step. First,
SRDF devices must first be converted to non-RDF devices. Next, the local devices must be converted
into meta devices, separately on both Symmetrix systems in the SRDF configuration. Finally, convert
the meta head on one Symmetrix to an RDF1 device, and specify the meta device on the remote
Symmetrix as the RDF2 pair.

Forming Meta Devices Procedure
When you initially create a meta device, you must form the head and add the members in the same command file. If using
the count option, no members need to be specified. The configuration server will automatically select members from the
pool of unmapped devices that match the meta head in size, emulation and configuration type.
The following are restrictions when configuring meta devices:
When configuring meta devices, the devices must be unmapped.
Meta members cannot be removed from a striped meta device.
To create a striped meta device, all members must be the same size and have the same mirror protection.
To remove a member from a concatenated meta device, the member must be the tail. You cannot remove inner members.
Only the head of a meta may have its type converted.
Only the head of a meta is mapped or assigned to the host.
All metas must contain at least one meta member. When a meta is formed, at least one member must be added.
All meta devices must be composed of devices of the same BCV type (you must convert from RDF devices in order to
change metas).
Meta devices must be composed of devices that are all of the same FBA emulation type.
You must create CKD meta devices using the create dev command, not the form dev command.
VDEV meta devices must be composed of virtual devices that are of the same capacity, stripe size, count, and emulation
type as the standard devices with which they will be used.

Verify Session


Select Devices to Form Meta
Select the devices to form the meta.

symdev list –noport

Split BCV Pairs
Split standards and BCVs if they are used to form a meta.

Example: symmir -g dgname split

Remove From Device Groups
Remove meta member candidates from device groups

Example: symld -g dgname remove DEV001 DEV006

Create Command File
Create command file.

To create a concatenated meta (manually selecting all members):
form meta from dev 0b8 config=concatenated;
add dev 015:016 to meta 0b8;
To create a striped meta (letting the software automatically select the members):
form meta from dev 011
config=striped
stripe_size=1920
count=3;

Command File Syntax
To form a meta device, use the following command:

form meta from dev SymDevName,
config=MetaOption
[, stripe_size=<MetaStripeSize>[cyl]]
[, count=<member_count>];
where:
config = the meta configuration type. Possible values are concatenated or striped.
stripe_size = the size of the striped meta device. This value can be expressed in blocks or cylinders.
Possible sizes in 512 byte blocks are 1920, 3840, 7680, 15360, 30720, and 61440.
cyl = if the stripe_size is expressed in cylinders, include cyl with the MetaStripeSize value. The size of
a cylinder for FBA emulation is 960 512-byte blocks.
count = the total number of devices for the configuration server to add to the new meta device,
including the head. This option may be omitted if you want to specify the members using the add dev
command.
Next, proceed to add the command specifying the new members. Note: Omit this step if the count
option was used previously with the form meta command.
add dev SymDevName[:SymDevName] to meta SymDevName;

BCV_meta_head
Protect_Data
Meta_option
Meta_stripe_size
Symdevname
This list represents common command file parameters when creating meta devices.
BCV_meta_head: When adding new members to an existing, striped meta device, or when re-
configuring a meta device, if the data on the meta device is to be protected, you must specify the name
of a bcv_meta that matches the original meta device in capacity, stripe count, and, stripe size.
Protect_data: When adding members to an existing, striped meta, you must specify whether the data on
the existing meta device needs to be protected. Valid settings are TRUE and FALSE. If this option is
not specified, a setting of TRUE is the default.
Meta_option: The meta type configuration. Possible values are: CONCATENATED or STRIPED
Meta_stripe_size: Size of a striped meta device. Stripe size can be specified in 512 byte blocks, or
cylinders. If specifying cylinders, the keyword cyl must follow the size field. Recommended stripe size
is 1920 (2 cylinders). Note: If no stripe size is specified when creating a striped meta, a default of 2
cylinders will be assigned. Possible sizes in 512 byte blocks are: 1920 (2 cyl), 3840 (4 cyl), 7680 (8
cyl), 15360 (16 cyl), 30720 (32 cyl), 61440 (64 cyl). Note: 1 cylinder = 960 512-byte blocks.
Symdevname: Defines the Symmetrix device name (such as 001C).

Run symconfigure




Display Meta Devices
Display the meta device.

symdev show xxx (where xxx is the meta head)
or
symdev list -meta

Adding to a Concatenated Meta
Once you have successfully formed an initial meta with meta members, you can add additional meta
members as necessary.

Add to Concatenated Meta Procedure
To add additional members to an existing concatenated meta device, use the following form:
add dev SymDevName[:SymDevName] to meta SymDevName;

Verify Session


Split BCV Pairs
Split standards and BCVs before adding to a meta device.


Create Command File

To add to a concatenated meta:
add dev 0b9 to meta 0b8;

Run symconfigure




Display Meta Devices

or
symdev list -meta

Removing From a Concatenated Meta Device
To remove a member from a concatenated meta device, the member must be the tail. You cannot
remove inner members.

Removing From a Concatenated Meta Procedure
To remove a meta member or members from the tail of a concatenated meta device, use the following
form:
remove dev SymDevName[:SymDevName] from meta SymDevName;
Removing concatenated members will lose access to the data on the removed member. Use these
commands with great caution.

Verify Session


Split BCV Pairs
Split meta device from BCV meta before removing member.


Create Command File

To remove from a concatenated meta:
remove dev 0b9 from meta 0b8;

Command File Syntax
To remove a meta member or members from the tail of a concatenated meta device, use the following
form:
remove dev SymDevName[:SymDevName] from meta SymDevName;

Run symconfigure




Display Meta Device

or
symdev list -meta

Adding to a Striped Meta Device
To add additional members to an existing striped meta device, use the following form:
add dev SymDevName[:SymDevName] to meta SymDevName [, protect_data=[TRUE |
FALSE], bcv_meta_head=SymDevName];
where:
protect_data = Possible values are TRUE or FALSE. The protect_data option is only for striped metas.
When set to true, the configuration manager automatically creates a protective copy to the BCV meta
of the original device striping. Because this occurs automatically, there is no need to perform a BCV
establish. When enabling protection via the protect_data option, you must specify a BCV meta
identical to the existing (original) striped meta.
bcv_meta_head = When adding new members to an existing, striped meta device, if the data on the
meta device is to be protected, you must specify the name of a bcv_meta that matches the original
meta device in capacity, stripe count, and stripe size.

Adding to a Striped Meta Device Procedure

Verify Session


Split BCV Pairs
Split standards and BCVs before adding them to a meta device.

symmir -g xxx split
symmir –g dgname split

Create Command File
Create command file.

To add a device to a striped meta:
add dev 444 to meta 443, protect_data=true, bcv_meta_head=333;

Command File Syntax
To add additional members to an existing striped meta device, use the following form:
add dev SymDevName[:SymDevName] to meta SymDevName
[, protect_data=[TRUE | FALSE],
bcv_meta_head=SymDevName];
where:
protect_data = Possible values are TRUE or FALSE. The protect_data option is only for striped metas.
When set to true, the configuration manager automatically creates a protective copy to the BCV meta
of the original device striping. Because this occurs automatically, there is no need to perform a BCV
establish. When enabling protection via the protect_data option, you must specify a BCV meta
identical to the existing (original) striped meta.
bcv_meta_head = When adding new members to an existing, striped meta device, if the data on the
meta device is to be protected, you must specify the name of a bcv_meta that matches the original
meta device in capacity, stripe count, and stripe size.

BCV_meta_head
Protect_Data
Meta_option
Meta_stripe_size
Symdevname
This list represents common command file parameters when working with meta devices.
BCV_meta_head: When adding new members to an existing, striped meta device, or when re-
configuring a meta device, if the data on the meta device is to be protected, you must specify the name
of a bcv_meta that matches the original meta device in capacity, stripe count, and, stripe size.
Protect_data: When adding members to an existing, striped meta, you must specify whether the data on
the existing meta device needs to be protected. Valid settings are TRUE and FALSE. If this option is
not specified, a setting of TRUE is the default.
Meta_option: The meta type configuration. Possible values are: CONCATENATED or STRIPED
Meta_stripe_size: Size of a striped meta device. Stripe size can be specified in 512 byte blocks, or
cylinders. If specifying cylinders, the keyword cyl must follow the size field. Recommended stripe size
is 1920 (2 cylinders). Note: If no stripe size is specified when creating a striped meta, a default of 2
cylinders will be assigned. Possible sizes in 512 byte blocks are: 1920 (2 cyl), 3840 (4 cyl), 7680 (8
cyl), 15360 (16 cyl), 30720 (32 cyl), 61440 (64 cyl). Note: 1 cylinder = 960 512-byte blocks.

Run symconfigure




Display Meta Device

or
symdev list -meta

Dissolving Meta Devices
You can dissolve a specified meta device, which subsequently releases all its members for normal use
as stand alone devices.

Dissolving Meta Devices Procedure
A dissolve action removes the meta head and all its members. Data is not preserved. Dissolving
striped or concatenated devices will lose access to data.

Verify Session


Split BCV Pairs
Split meta device from meta BCV before dissolving.


Create Command File

To dissolve a meta:
dissolve meta dev 0b8;

Command File Syntax
To dissolve a meta device, use the following form:

dissolve meta dev SymDevName;
To dissolve meta device 0010, enter:
dissolve meta dev 0010;
A dissolve action removes the meta head and all its members.

Run symconfigure




Display Devices
Verify that meta device is dissolved.

or
symdev list -meta

Converting Devices
Users can convert an existing hyper volume from one device type to another. This class of change
allows customers to make much better use of the existing capacity in the Symmetrix. The
Configuration Manager allows you to reconfigure an existing device. You can:
Change a device’s configuration type so that the device can perform a different role.
Increase or decrease device protection by adding or removing mirrors (a separate class of change).
Add or remove RDF attributes.
Convert a RAID-S group to a set of unprotected devices (beginning with EMC Solutions Enabler
version 5.4 and Enginuity version 5670)

When converting a device’s type, you retain the same number of mirror positions. This table shows a
listing of device configurations and the number of mirror positions they maintain.

Converting Devices - Considerations
When converting devices that are currently in a device group, some groups will be declared invalid
after particular operations. One example would be if you are performing TimeFinder operations and
have placed in a group, one standard (STD) device and one TimeFinder (BCV) device. You now have
the ability with symconfigure to change the BCV device to a non BCV device. This conversion would
leave the group in an invalid state. There are two ways to handle this situation:
Remove the TimeFinder (BCV) device from the group before you begin the conversion process.
Or, after the device has been converted:
export (symdg export) the device group and remove from the file symdg.txt the invalid device and
import (symdg import) the device group.

Impact on I/O
The following are restrictions/conditions to avoid impact on I/O activity:

When adding/removing DRV attributes—devices must be unmapped.
When adding/removing RDF attributes—no restriction on I/O. The RDF pair must be split or failed
over. If failed over, the R1 device must be unmapped.
When adding/removing BCV attributes—no restriction on I/O. The standard/BCV pair must be split.

SRDF Device Considerations
Reconfiguring devices as RDF devices requires a corresponding configuration change on the remote
Symmetrix unit. The symconfigure command attempts to perform local and remote changes in parallel,
but if another user is executing a configuration change on the remote Symmetrix unit, then your RDF
change will not be applied to either the local or remote Symmetrix unit. You can reconfigure existing
devices to form an SRDF pair in which the R2 device is larger than the R1 device. This configuration
can be useful if you need to migrate data from smaller devices to larger devices. Beginning with
Solutions Enabler version 5.3, you can convert a static RDF device to a dynamic RDF device. You can
also use a convert dev command to remove the RDF attributes from a device. When creating RDF
devices, all conversions within a session must have DeviceConfig settings that reflect the same
destination RDF type (RDF1 or RDF2), the same ra_group number, the same invalidate option, and the
same start_copy option.

Converting Devices Procedure
The convert command can be used for three different classes of device configuration changes, as long
as the class types are performed in separate sessions. Beginning with Enginuity version 5669, changes
for multiple operation classes can be executed within the same session. The three class types that
cannot be used in the same session are:
Add/remove BCV/DRV attributes
Add/remove RDF attributes
Increase/decrease mirroring
Only the head of a meta device can have its type changed. The meta member(s) will automatically
have the changes applied.

Verify Session


Backup Data
Backup data on devices to be converted.

Split BCV Pairs
Split standards and BCVs to be converted. Remove the TimeFinder (BCV) device from the group
before you begin the conversion process. Or, after the device has been converted export (symdg
export) the device group and remove from the file symdg.txt the invalid device and import (symdg
import) the device group.

Create Command File
Create the command file

To convert a single device:
convert dev xxx to 2-way-mir;
To convert a range of devices:
convert dev xxx:xxx to 2-way-mir;
To convert to rdf device(s):
convert dev xxx to xxxxxxxx, ra_group=x, remote_dev=xxx, invalidate=xx, start_copy=xxx;

Command File Syntax
In the command file, you can convert the configuration type of an existing device or devices using the following command:
convert dev SymDevName[:SymDevName] to DeviceConfig
[ ra_group=n, remote_dev=SymDevName,
invalidate=R1|R2|NONE, start_copy=YES|NO ],
[mvs_ssid=nnn] [raidset = TRUE];
where:
SymDevName = the Symmetrix device name of the device targeted for change. To target more than one device, indicate the
first and last devices in a series separated by a colon (:).
DeviceConfig = the desired device configuration type.
ra_group = the RA group number in the SRDF environment.
remote_dev = the remote Symmetrix device name of the particular device targeted for change. If you specify a range of
SymDevNames in the first line of the convert statement, the remote SymDevName value will be increased incrementally to
arrive at the corresponding device number.
invalidate = Specifies which RDF device (R1 source or R2 target) to invalidate. An invalidated copy requires a full refresh
(synchronization of all racks) at some point. If NONE is selected, the RDF device must be specified later using the symrdf
command.
start_copy = Indicates whether an RDF pair should be synchronized after the configuration change is committed.
mvs_ssid = Specifies the z/OS (MVS) subsystem ID that will be assigned to any device created as a result of removing any
mirror(s). If not provided, the original MVS SSID will be assigned when available.
raidset = When requesting to convert a RAID-S group to unprotected devices, set raidset equal to TRUE and list the first
RAID-S member. It is not necessary to list the other members.

Invalidate
Start_copy
Ra_group
Symdevname
This list represents common command file parameters when converting devices.
Invalidate: Specifies which RDF device (R1 source or R2 target) to invalidate. At some point, this
device will need a full refresh (by synchronizing all tracks from the remote mirror).
Start_copy: Indicates whether an RDF pair should be synchronized after the configuration change is
committed.
Device_configuration: Specifies a valid Symmetrix/SYMAPI device and configuration. When this
parameter is being used to apply or remove the BCV, DRV, or RDF attribute, the change will be
denied if the device configuration result would change the device’s mirroring. Also, cannot be used to
convert RDF1 devices to RDF2 devices, which must be done using the swap ra group command.
Ra_group: Integer (non-negative) specifying the SRDF device group.

Run symconfigure




Verify Conversion
Verify the conversion.


Increasing Device Mirroring
The mirroring protection of a device can be increased using a separate session from BCV, DRV, and
RDF change sessions. Device configuration changes to apply or remove the BCV, DRV, or RDF
attribute that results in a change to the device's mirroring, will be denied. For example, converting a 2-
Way-BCV to an unprotected device will be denied. This involves two changes being made to a device,
removing a mirror and removing the BCV attribute. For this type of configuration, you can only
remove a mirror to form a BCV device or remove the BCV attribute to form a 2-Way-MIR device.
The mirroring protection of a device can also be decreased, and this too must be done via a separate
session from the BCV, DRV, and RDF change sessions.
As a result of removing mirrors from a device, a new device is created from the discarded mirrors,
resulting in a new Symmetrix device. If the original or new device is unprotected, it cannot be mapped
to a host. You cannot change a device’s mirroring by converting it to other device types (i.e., from 2-
Way mirror to RDF1).

Mirror Positions
The Symmetrix unit allows you to configure up to four mirrors for each Symmetrix device. The mirror
positions are designated M1, M2, M3, and M4. When a BCV device is established with a standard
device as a mirror, it becomes the next available mirror. Therefore, a single BCV device can be the
second, third, or fourth mirror of the standard device.

This table shows a listing of device configurations and the number of mirror positions they maintain.

Free Space Considerations
Before increasing device mirroring, determine the amount of unconfigured space for the new mirrors.
Use the following command:
symdev list –da all –space
or
symdisk list

symdisk list
This is a sample output of the symdisk list command. Notice the two columns under “Capacity”. Use
this information to determine if there is enough free space to support the configuration change.

Increase Mirror Protection Procedure
Increasing mirroring adds mirror(s) to an existing device.

Example: convert 2-Way-Mir to 3-Way-Mir or convert RDF1 to RDF1+Mir.

Verify Session


Select Devices
Select the device to which you want to add mirroring


Check for Unconfigured Free Space
Check for unconfigured free space.

symdev list –da all –space
or
symdisk list

Create Command File

convert dev 0ba to 2-way-mir;
convert dev 02d:02e to 3-way-mir;

Command File Syntax
In the command file, you can convert the configuration type of an existing device or devices using the
following command:
convert dev SymDevName[:SymDevName] to DeviceConfig
[ ra_group=n, remote_dev=SymDevName,
invalidate=R1|R2|NONE, start_copy=YES|NO ],
[mvs_ssid=nnn] [raidset = TRUE];

Symdevname
This list represents common command file parameters when working with device mirroring.
Device_configuration: Specifies a valid Symmetrix/SYMAPI device and configuration.

Run symconfigure




Verify New Mirror Devices
Verify that new mirror is created.

Example: symdev show xxx

Decreasing Device Mirroring
Decreasing device mirroring could be used to make better use of the space within your Symmetrix. A
good example of this class of change would be to convert some unused mirrored devices into
unprotected devices, and then convert these devices to BCVs for use with Timefinder, or DRVs for use
with Optimizer.

Decreasing Mirroring Procedure
The mirroring protection of a device can also be decreased, and this must be done via a separate
session from device type conversion sessions. As a result of removing mirrors from a device, a new
device is created from the discarded mirrors, resulting in a new Symmetrix device.

Verify Session


Select Devices
Select the device from which you want to remove mirror.


Create Command File
Create the command file

convert dev 0b1 to unprotected;
convert dev 02b:02e to bcv;

Symdevname
This list represents common command file parameters when working with device mirroring.
Device_configuration: Specifies a valid Symmetrix/SYMAPI device and configuration.

Run symconfigure




Verify Mirror is Removed
Verify mirror is removed.


Setting Front-End Port Flags
There are a handful of reasons why you would want to change a front-end port flags:
Changing or updating a host type on a particular port (SUN to HP)
Changing fibre-channel topology (FC-AL to FC-SW)
Implementing certain types of software (for example clustering software)
Incorrectly changing the port flags can render your storage system inaccessible. Be sure of your needs
before resetting these flags.

Guidelines
Follow these guidelines when setting front-end port flags. Backup the symapi_db.bin to another
directory. If the commit fails, it sometimes corrupts the database. Ensure there are at least two
connections from the host to the Symmetrix if you will be changing port flags on the port where you
are running symconfigure commands. If possible, move impacted ports offline

Setting Front-End Port Flags Procedure
When setting port flags, it is recommended that you temporarily suspend I/O activity to the affected
ports. You can display the possible port flags and their current status with the following
command:
symcfg -SA all -p x -v list

Verify Session


Verify Current Flag Settings
Determine current flags set for the impacted port.

Example: symcfg -sa xx -p x -v list

Check Support Matrix
Check flag settings at www.emc.com, search for the support matrix, or access e-Lab Navigator from
Powerlink to fully qualify your environment.

Set Impacted Port Offline
Move the impacted port offline.

Example: symcfg -sid 23 -sa xx -p x offline
To verify if a port is online or offline:
symcfg -sid 23 -sa all –port list
Confirm port(s) are offline.
symcfg list –sa all -port

Create Command File

Example: set port xx:x flag_name=enable|disable
set port 12b:0, common_serial_number=enable;

Command File Syntax
You can set the port characteristics of a specified director using the following command:
set port DirectorNum:PortNum
[FlagName=enable|disable
[,FlagName=enable|disable]]
[fa_loop_id=integer] [hostname=HostName];
where:
FlagName = A SCSI or fibre port flag.
fa_loop_id = the FA director loop ID (arbitrated loop physical address). (0 - 125) (Hard Addressing
must be enabled.)
hostname = 12-character host name.
Incorrectly changing the port flags can render your storage system inaccessible. Be sure of your needs
before resetting these flags.

Director_num
Fa_loop_id
Flag_name
Hostname
Port_number
This list represents common command file parameters when setting port flags.
Director_num: The director identity number, such as 16A.
Fa_loop_id: Specifies the FA director loop ID (arbitrated loop physical address). Possible integer
values are from 0 to 125.
Flag_name: A SCSI or fibre port flag.
Hostname: 12-character host name.
Port_number: Specifies the port number.

Run symconfigure


Verify Flags are Set
Verify flag has been changed on impacted port.

Example: symcfg –sa xx –p x –v list

Set Port Online
Move impacted port back online.

Example: symcfg –sa xx –p x online
Confirm port(s) are online.
Example: symcfg list –sa all –port



You can set the device attributes or emulation of a number of devices in a range using the following
command:
set device SymDevName[:SymDevName] [emulation=EmulationType] [attribute=[NO] device_attr];
where:
emulation = the device emulation type, which can be fixed block architecture selections:
FBA, CELERRA FBA or VME512 FBA.
attribute = A device attribute that restricts how a device can be accessed.
Note: When changing a device’s emulation, changes can only be among FBA emulation types.

When setting device emulations, the devices must be unmapped. There can be no I/O to the devices.

Verify Session


Select Devices
Select devices to set emulation.

symdev list -noport
or
symdev show XXX

Create Command File
Create command file:

To set device emulation to Celerra_FBA:
set device 0b6:0b8, emulation=CELERRA_FBA;

Command File Syntax
command:
set device SymDevName[:SymDevName]
[emulation=EmulationType]
[attribute=[NO] device_attr];
where:
emulation = the device emulation type, which can be fixed block architecture selections: FBA,
CELERRA FBA or VME512 FBA.

Emulation
Symdevname
This list represents common command file parameters when setting device emulation.
Emulation: The device emulation type, which can be fixed block architecture selections: FBA,
CELERRA FBA or VME512 FBA.

Run symconfigure


Verify Emulation is Set
Verify that the emulation for the device has been changed.



Setting Device Attributes
You can set a device attribute and change the device emulation type for a device or range of devices by
using the set device command file entry. The following device attributes restrict how a device can be
accessed: RDB_Cksum, VCMdb (only one device per Symmetrix unit can be established as a VCMdb
device. It should be a mirrored device of at least 16 cylinders), Worm (Write Once Read Many). The
Configuration Manager does not allow you to disable the Worm attribute. This protection is required to
maintain the integrity of a true WORM environment. However, once a device has a track that is
WORM protected, you can contact EMC to disable the Worm attribute if doing so becomes your
requirement.
Beginning with EMC Solutions Enabler version 5.1, you can also set the SCSI3_persist_reserv
attribute (persistent group reservation) if you have a Sun Cluster 3.0 environment where more than two
channels access the device.
Three device attributes apply to non-RDF devices that you want to use as dynamic RDF devices. The
dyn_rdf attribute allows a device to be either an R1 or an R2 device, providing the most flexibility in
performing dynamic RDF operations. Only the dyn_rdf attribute allows you to use these devices to
perform RDF swaps. The other dynamic RDF attributes, dyn_rdf1_only and dyn_rdf2_only, allow a
device to be only an R1 or an R2 device, respectively. Their restriction prevents them from taking part
in RDF swaps.

Setting Device Attributes Procedure
When setting the attribute type to a mapped device, it is recommended that you minimize the I/O
activity to the affected devices.

Verify Session


Select Devices
Select devices to which attributes will be set.

symdev list
or
symdev show xxx

Create Command File

To set the device attribute to vcmdb:
set device 000 attribute=vcmdb

Command File Syntax
command:
set device SymDevName[:SymDevName]
[emulation=EmulationType]
[attribute=[NO] device_attr];
where:
attribute = A device attribute that restricts how a device can be accessed. Possible values include:
RAD
RDB_Cksum
VCMdb (for Device Masking)
Worm (can be enabled only)
SCSI3_persist_reserv (persistent group reservation)
dyn_rdf (This option provides the most flexibility in performing dynamic RDF operations)
dyn_rdf1_only
dyn_rdf2_only

Run symconfigure


Verify Attributes are Set
Verify that the attribute for the device has been changed.



Symmetrix Metrics – Max Hypers per Disk
You can set a limited number of Symmetrix-wide configuration parameters to allow the use of specific
Symmetrix features such as creating dynamic RDF devices or Parity RAID devices.
max_hypers_per_disk — Specifies the maximum number of hyper volumes that can be created on
physical disks in a Symmetrix unit. Possible values are from 1 to 32 or higher, based on the Enginuity
version that you are running on your Symmetrix unit (beginning with Enginuity version 5x70, this
value can be up to 255). You cannot set this parameter to a value that is lower than the number of
hypers currently existing on any device. To determine the current setting for maximum hypers, use the
symconfigure list command with the verbose (–v) option.

Symmetrix Metrics – Dynamic RDF
dynamic_rdf — (beginning with EMC Solutions Enabler version 5.0) Enables the creation of a pool of
devices that are RDF-capable, (can be dynamically assigned as RDF1 or RDF2 devices). The possible
MetricValue is ENABLE or DISABLE.

Symmetrix Metrics – FBA Multi Access Cache
fba_multi_access_cache — Determines whether an FBA read request can share cache slots under some
conditions. It must be enabled to create Celerra FBA devices. You can set its value to ENABLE or
DISABLE.

Symmetrix Metrics – RAID S Support
raid_s_support — (beginning with EMC Solutions Enabler version 5.0) Supports the creation of Parity
RAID-S devices on a Symmetrix unit. You can set its value to ENABLE or DISABLE (the default).

Symmetrix Metrics – RAID 5 Support
RAID_S_members=4 or 8
raid_5_support - (beginning with EMC Solutions Enabler version 5.4) Supports the creation of RAID-
5 devices on a Symmetrix unit. You can set its value to ENABLE or DISABLE (the default).
Raid_s_members (RAID-S requires version 5.1 or higher; RAID-5, version 5.4 or higher) Specifies the
number of members required when you create Parity RAID-S groups or sets, or the number of hypers
(4 or 8) used to form a RAID-5 device. For RAID-S, specify a value of 3 for Parity RAID 3+1
protection, or a value of 7 for Parity RAID 7+1. If you do not set this parameter for RAIDS,
the default is 3. All RAID protection groups (RAID-S or RAID-5) on a Symmetrix unit must have the
same number of members.

Symmetrix Metrics – RAID S Members
RAID_S_members=3 or 7
raid_s_members — RAID-S requires version 5.1 or higher; RAID-5, version 5.4 or higher) Specifies
the number of members required when you create Parity RAID-S groups or sets, or the number of
hypers (4 or 8) used to form a RAID-5 device. For RAID-S, specify a value of 3 for Parity RAID 3+1
protection, or a value of 7 for Parity RAID 7+1. If you do not set this parameter for RAIDS, the default
is 3. All RAID protection groups (RAID-S or RAID-5) on a Symmetrix unit must have the same
number of members.

Symmetrix Metrics – VCMDB Restricted Access
VCMDB_access_restricted — (beginning with EMC Solutions Enabler version 5.1) Enables you to
restrict access to the device masking database to hosts that have a database entry that includes the
VCMDB device. By default, all Host Bus Adapters (HBAs) that log in to the FA port to which the
VCMDB device is mapped can access the database. By setting this parameter value to ENABLE, you
deny database access to all hosts except those whose HBAs have added the VCMDB device through
the symmask add devs command. (You can display the VCMDB device on a Symmetrix unit using the
sympd list –vcm command.) Prior to enabling this parameter, you should ensure that at least one host
HBA has a valid database entry that includes the VCMDB device. (It is recommended that you have
two HBA entries that include this device, in case of an HBA failure.) Without this VCMDB entry, no
hosts can access the database. To gain access to the database again, you would need to reset this
parameter to DISABLE.
NOTE: This feature is no longer available as of the DMX-3.

Setting Symmetrix Metrics Procedure
Setting Symmetrix configuration parameters has no impact on I/O activity.

Verify Session


Display Current Metrics
Determine the current metric values:

Example: symconfigure -sid xx -v list

Available Symmetrix Metrics as of Solutions

Enabler version 6.3
The listed Symmetrix metrics are available as of Solutions Enabler version 6.3

Validate Max Hypers per Disk
If changing max hypers per disk check current highest number of HVEs per disk:
symdev list -da all –space
or
symdisk list

Create Command File

To set the ceiling for the number of HVEs to be formed on any given disk:
set symmetrix max_hypers_per_disk=64;
To set whether read slots can be shared:
set symmetrix fba_multi_access_cache=enable;

Command File Syntax
You can set some attributes to gain access to new Symmetrix features using the following command:
set Symmetrix MetricName=MetricValue
[, MetricName=MetricValue];
where:
MetricName = the Symmetrix metric to be set. Possible name values are:
max_hypers_per_disk — The maximum number of hypers that can be created on a physical disk. The possible MetricValue
is from 1 to 32, or higher, based on the Enginuity version you are running.
dynamic_rdf — Enables the creation of a pool of devices that are RDF-capable, (can be dynamically assigned as RDF1 or
RDF2 devices). The possible MetricValue is ENABLE or DISABLE.
fba_multi_access_cache — Determines whether a read request can share cache slots in some conditions. The possible
MetricValue is ENABLE or DISABLE.
raid_s_support — Allows the creation and use of Parity RAID devices. The possible MetricValue is ENABLE or
DISABLE.
VCMDB_access_restricted — Restricts access to the device masking database (VCMDB) to hosts that have a database
record that includes a VCMDB device. When ENABLED, database access is restricted to all hosts except those in which
the host bus adapters (HBAs) have added a VCMDB device through the symmask add devs command. The possible
MetricValue is ENABLE or DISABLE. For device masking information, see the EMC Solutions Enabler Symmetrix
Device Masking CLI Product Guide.
raid_s_members — Used to set the number of members in a Parity RAID set (RAID-S). The possible MetricValue is 3 or 7,
or else set to SYMAPI_C_NA.
raid_5_support — Enables the ability to create RAID-5 devices in the Symmetrix. The possible MetricValue is ENABLE
or DISABLE.

Run symconfigure


Verify Metrics are Set
Verify that the settings have been changed.

Example: symconfigure –sid xx –v list



Spare Disk Management
Beginning with EMC Solutions Enabler version 5.0, you can reserve a certain number of disks as
dynamic (“hot”) spares. When a physical disk is reserved as a dynamic spare, it cannot be used to hold
any devices. The dynamic spare disk is held in reserve to support the hypers of a Symmetrix disk that
fails. When a disk fails, the dynamic spare disk is invoked against the failed disk. The Symmetrix
system creates a spare disk only from a disk containing no hypers. Values for the recording format to
be used on a spare disk can be either 512 or 520. You should select a format based on the type of disk
that the dynamic spare will replace:
For the Symmetrix 8000-series and all DMX models, use 512 for CKD and FBA type disks, and 520
for AS/400 and Tandem types.
For Symmetrix models 3330/5330, 3700/5700, and 3430/5430 with selective LLF (Low-Level Format)
enabled, use 512 for CKD and FBA, and 520 for AS/400 and Tandem.
For Symmetrix models 3330/5330, 3700/5700, and 3430/5430 with no AS/400 or Tandem devices, use
512 for CKD and FBA type disks.
For Symmetrix models 3330/5330, 3700/5700, and 3430/5430 with AS/400 or Tandem devices, use
512 for CKD, and 520 for FBA, AS/400, and Tandem.

Viewing Existing Spares
To view the set of existing spares, use the following command:

symdisk list –hotspare

Spare Disk Management Procedure
A spare disk can only be created from a new disk containing no hypers. The following are
restrictions/conditions for working with hot spares:
When adding or removing Symmetrix spares—no restriction on I/O.
A spare cannot be removed while in use.

Verify Session


Identify Unconfigured Disks
Identify unconfigured disks within the Symmetrix.

Example: symdisk list

Create Command File

To create a hot spare:
Create spare count=1, Format=512;
To delete a hot spare:
Delete spare disk=[2a,c,1];

Command File Syntax
A spare disk can only be created from a new disk containing no hypers. To reserve a disk as a dynamic
spare, use the following command:
create spare count=n[, format = [512 | 520]];
where:
count = a positive integer the defines the number of disks to be set aside as spares.
format = The recording format to be used on a spare disk. Values are 512 or 520. Select a format based
on the type of disk it should be able to replace.

Count
Format
DirectorNum
Da_interface
Scsi_id
This list represents common command file parameters when working with hot spares.
Count: a positive integer the defines the number of disks to be set aside as spares.
Format: The recording format to be used on a spare disk. Values are 512 or 520. Select a format based
on the type of disk it should be able to replace.
DirectorNum: The director identity number, such as 16A.
Da_interface: The DA SCSI path (c, d, e, or f).
Scsi_id: The SCSI target ID (hex value).

Run symconfigure


Verify Spare Disk Configuration
Verify creation or deletion of spare disk.

Example: symdisk list -hotspare



Swapping RDF Personalities in a RA Group
When you swap the devices in an RA group, you convert the personality of all the SRDF devices in the RA group and swap
the polarity of any ESCON RA directors in the RA group. Source R1 devices become target R2 devices, and vice versa.
The swap ra group command file entry allows you to specify the RA group, which side of RDF devices (R1 source or R2
target) to refresh from any changed data on the other side, and whether the SRDF pairs should be synchronized
immediately after the configuration change is committed. For example, the following command file entry swaps the devices
of RA group 1 and refreshes the R1 devices from the R2 devices (copying data from the R2 devices to the R1 devices). The
start_copy option causes the synchronizing of the SRDF pairs to begin immediately after the configuration change is
committed. swap ra group 1, refresh=r1, start_copy=yes;
The refresh action identifies which devices do not hold a valid copy of the data before the swap operation begins. For
example, after a failover from source to target, the R1 devices will no longer hold a valid copy of the data if processing
continues on the R2 side. Also, after a failover, R2 writes are not propagated back to the R1 devices. If you decide not to
fail back to the original host after a failover
situation is corrected (there may be no reason to shut down the processing of data on the backup target system then to
perform a failback operation), swapping the devices in the RA group is a useful operation. Your original target system
becomes the new source system, and the original source becomes the new target.
The SYMCLI command symrdf swap provides a similar swap capability, but at the device-pair level rather than the RA-
group level11. If you add SRDF devices to a device group, you can use the symrdf swap command to swap the R1/R2
personality of one or more SRDF pairs that you have included in the device group. However, symrdf swap does not swap
the RA director polarity as swap ra group does, and in cases where bi-directional communication is absent, swapping the
director polarity and all SRDF devices in the RA group is required.

Swapping RDF Personalities Procedure
The following are restrictions on swapping RA groups:

All the devices in the RA group must be of the same type (RDF1 or RDF2) if FarPoint™ is enabled.
Only one RA group may be swapped per configuration session.
When swapping source and target attributes—no restriction on I/O to R2, but no I/O allowed to the R1
device.
When swapping the RA group personalities that engage ESCON directors in a FarPoint connection, be
aware that FarPoint buffer settings cannot be adjusted using symconfigure. If your FarPoint buffers are
set to customized parameters other than default values, an EMC representative will need to be called to
adjust the buffer settings after the swap has taken place.
Swapping the devices in an RA group requires a corresponding configuration change on the remote
Symmetrix unit. The symconfigure command attempts to perform local and remote changes in parallel,
but if another user is executing a configuration change on the remote Symmetrix unit, then your RA
group swap will not be applied to either the local or remote Symmetrix unit.

Verify Session


Select RA Group to Swap
Select RA group to swap:

Example: symrdf list

Backup Data on Affected Disks
It is recommended to back up data on all affected devices.

Create Command File

To swap rdf personalities:
swap ra group=1, refresh=r2, start_copy=yes

Command File Syntax
Use the following form to perform an R1/R2 swap:

symrdf -g DgName [-force][-symforce] [-bcv|-all]
[-bypass] [-v|-noecho][-noprompt]
[-i Interval] [-c Count]
swap [-refresh R1|R2]

Refresh
Start_copy
Ra_group
This list represents common command file parameters when swapping RDF personalities.
Refresh: Specifies which RDF device (R1 source or R2 target) to refresh. Possible values are R1 or R2.
Start_copy: indicates whether an RDF pair should be synchronized after the configuration change is
committed.
Ra_group: Specifies an integer (positive) for the RA group.

Run symconfigure




Verify New Configuration
Verify new configuration

symrdf list
or
symdev list

Module 2: Summary
y Performing configuration changes using the command
line interface


Module 3: Configuration Management ECC

y Perform configuration changes using the ControlCenter
GUI
© 2007 EMC Corporation. All rights reserved. Configuration Management ECC - 1
Configuration Management ECC -1

Configuration Manager and ControlCenter
Today, companies are storing ever-increasing amounts of information. As enterprise storage networks
become more complex, and storage devices grow in number and size, companies are faced with the
challenge of effectively managing their storage. An enterprise storage network is a collection of
storage resources linked together to provide access to information from multiple platforms, operating
systems, and applications across any combination of SCSI, ESCON, or Fibre Channel technologies.
EMC ControlCenter™ is an integrated family of products that enable you to discover, monitor,
automate, provision and report on networks, host resources, and storage resources across your entire
information environment. From a single console, ControlCenter can monitor and manage:
Connectivity components — Fibre Channel switches and hubs.
Host components — Host operating systems, file systems, volume managers, databases, and backup
applications.
Storage arrays — EMC’s Symmetrix®, CLARiiON®, and other vendors’ storage arrays.
ControlCenter shows a consolidated view of the storage environment, allowing you to monitor the
health of, track the status of, report on, and control each object from a console anywhere on the
network.

ControlCenter Tiers - Console
The Console is the user interface through which you view and manage the storage environment. It is a
Java-based application that is installed through a browser such as Microsoft Internet Explorer or
Netscape, and launched from a desktop icon or from the command line. ControlCenter applications are
implemented as plug-ins to the Console and use the common collection of services provided by the
ECC Server. For an object to be displayed in the Console, it must have been discovered by an agent.
Once discovered, the object appears in the Console, grouped into its appropriate folder, such as Storage
Systems, Hosts, or Connectivity. Information about the object can be retrieved by the Console from the
Repository or in real-time directly from the agent. It is presented to you through a series of views. Any
command issued for the object is passed from the Console to the ECC Server and forwarded to the
agent to be enacted.

ControlCenter Tiers - Infrastructure
The Infrastructure Tier includes the Repository, ECC Server, and one or more Stores. The infrastructure components can
reside on different Windows 2000 servers as in a distributed infrastructure or can reside on a single server, as is the case of
a single host infrastructure. The size of the environment and performance considerations determines the appropriate
infrastructure configuration. The ECC Server is the primary interface between the Console and the ControlCenter
infrastructure. The ECC Server is a collection of services crafted for use by ControlCenter. It encompasses diverse areas
including:
Web server, which installs and starts the Console
Security and access management, such as licensing, login, authentication, and authorization
Communication with the Console
SNMP collection
Alert and event management
Real-time statistics
Object management to maintain a list of managed objects
Agent management to maintain a list of available agents
The ECC Server retrieves data from the Repository for display by the Console. It can also request real-time data directly
from some agents, but the Console user must initiate the request and the information collected is transient (not stored). The
Repository contains a relational database, based on Oracle 8i.
Installation and maintenance of Oracle are fully embedded into ControlCenter. The Repository holds the current and
historical data of both the storage environment and ControlCenter itself, with the exception of performance data. The ECC
Server processes transactions from the Console for Repository data, such as checking user group permissions. The Store is
a process that populates the Repository with persistent data from the agents. It provides a store and retrieve interface
between the agents and the Repository.

ControlCenter Tiers - Agent
ControlCenter manages every physical and logical element using intelligent agents. The agent collects
data and monitors the health of the element. In addition, it can run user commands for configuring disk
groups, volumes, and file systems, and for real-time explore. There are many types of agents for
managing diverse domains, from storage arrays through to host applications. A different agent
manages each type of object. For example, there is a Storage Agent for Symmetrix, a Host Agent for
Windows, a Database Agent for Oracle, and so on. There can be more than one agent on a host. A
single Master Agent controls all the agents on a host, starts and stops the agents, and facilitates remote
installation and upgrade.

Symmetrix Configuration Overview

y Symmetrix configuration is a component of the ControlCenter Symmetrix Manager
y Enables users to perform a variety of configurations changes to the Symmetrix
– via the ControlCenter Console
– Or via Solutions Enabler CLI
y Prerequisites
– Symmetrix 4.0 and above; SymmWin based Service Processor
– Enginuity level 5x66 and above
– ControlCenter
¾ EMC ControlCenter Master Agent
¾ EMC ControlCenter Symmetrix Agent
¾ Solutions Enabler installed on agent host
¾ Symmetrix Manager License
– CLI
¾ Configuration capability has been available since Solutions Enabler 4.1
¾ Configuration Manager License
Symmetrix configuration changes can be performed either via the ControlCenter Console or by the
Solutions Enabler Command Line Interface (SYMCLI). The configuration capabilities available via
the ControlCenter Console are a subset of the capabilities available via SYMCLI. In this lesson, we
will restrict the discussion to Symmetrix configuration changes via the ControlCenter Console only.
Configuration features depend on the Symmetrix Microcode level and the version of Solutions
Enabler. The most complete set of configuration features are available with the latest Microcode level
and the latest version of Solutions Enabler.
Symmetrix configuration capabilities are enabled in ControlCenter by licensing Symmetrix Manager.
The Symmetrix to be managed should be discovered by a Symmetrix Agent.

Configuration Changes Supported in the Console

y Logical Device Creation and Deletion
y Meta Device Configuration
y Device Mapping (Symmetrix Device Reallocation)
y Device Type Definition
y Device Attribute Definition
y Device Protection Definition
y SRDF Device Definition
y Port Flag Settings
y Symmetrix Attributes
y Save Pool Creation and Population
y SRDF A Attributes
The Configuration changes allowed in the ControlCenter Console are listed above. Each of these configuration changes is
considered a “Change Class”. We will look at each of these change classes in more detail during the course of this lesson.
y Logical Device – Create and Delete Symmetrix Devices
y Meta Device Configuration – Create/Dissolve Symmetrix Meta Volumes
y Device Mapping (SDR or Symmetrix Device Reallocation) – Map Symmetrix Devices to Front End Ports
y Device Type Definition – Convert device types: Standard, Business Continuance Volumes (BCVs), or Dynamic
Reallocation Volumes (DRVs)
y Device Attribute Definition – Give Symmetrix devices the Dynamic RDF or Double Checksum attribute
y Device Protection Definition – Add a mirror to an unprotected device or drop a mirror from a 2-way mirrored device
y SRDF Device Definition – Create static SRDF Device pair definitions from existing Symmetrix devices
y Port Flag Settings - Modify SCSI or Fibre Channel front-end director flags
y Symmetrix Attributes – Change global Symmetrix attributes such as maximum number of hypers per disk, the RAID
type to enable, SRDF settings, and others
y Save Pool – Create and Populate Save Pools
y SRDF A Attributes – Change the SRDF A checkpoint frequency, cache size, and other factors
The Command Line interface also allows the following configuration changes
y Enable/Disable Dynamic RDF - If enabled the Dynamic RDF attribute can be set on non-RDF devices
y Enable/Disable FBA multi access cache - Must be enabled to create Celerra FBA devices
y Restrict access to the VCMDB device - If enabled, you deny database access to all hosts except those whose HBAs
have been masked to the VCMDB device. Device masking could then be performed only by those select hosts
y Change device emulation - Change allowed between FBA emulations types only
y Reserve physical disks as dynamic spares - Disks with no hypers must be available. Dynamic spare is invoked against a
failed disk

Symmetrix Configuration Process

y Configuration change requests are sent from the ControlCenter
Console to the primary Symmetrix Agent
y Symmetrix Agent sends the change requests to the Symmetrix via
SYMAPI (Solutions Enabler) over the SCSI/FC interface
y The steps in a configuration change session are as follows:
– Submit
– Validate
– Prepare
– Commit
– Database Refresh
y Configuration change sessions cannot be aborted via the

ControlCenter Console
Symmetrix configuration changes initiated from the ControlCenter Console are sent to the primary Symmetrix Agent. If a
Symmetrix is managed by more than one Symmetrix Agent, one of the Agents is designated as the primary. The primary
Symmetrix Agent then sends the configuration change request to the Symmetrix by making SYMAPI calls over the
SCSI/FC interface. The sequence of operations after that is similar to that described for the command line method in the
next paragraph.
Symmetrix Configuration changes via Solutions Enabler Command Line Interface (SYMCLI) - symconfigure
y Change information is transferred, to the Symmetrix from the host, via the channel interface (SCSI/FC). The service
processor receives the information through the Ethernet connection and in turn communicates these changes through
sympl (scripts run by the Symmwin program running on the service processor) scripts.
y Changes are done in three stages:
− Preview: Verifies the syntax and correctness of each individual change.
− Prepare: Performs the Preview stage and checks to ensure that the changes can be applied to the Symmetrix in its
current state.
− Commit: Performs the Prepare stage and activates the SymmWin scripts to make the changes.
y Multiple changes can be made in one session, but all changes must belong to the same change (operations) class.
Changes can take a few minutes to hours, depending on the number and type of changes, size of the Symmetrix, and
other factors.
Initiating a Symmetrix Configuration change via ControlCenter is similar to executing a CLI command with the “Commit”
option. From the Console, the user does not have the option of explicitly doing a “Preview” or a “Prepare”. The
Configuration session initiated via the Console will go through a number of steps: 1) Submit – ControlCenter sends the
change request to the Symmetrix Agent; 2) Validate – This is the same as the Preview step of the CLI; 3) Prepare; 4)
Commit; 5) After the Commit is finished, the Configuration Lock on the Symmetrix is released and then ControlCenter
initiates a Database refresh, to update the ControlCenter Repository with the most up to date information about the
Symmetrix.
The CLI has an option to abort a Symmetrix Configuration. The “Abort” command cannot be issued from the
ControlCenter Console.

Accessing Symmetrix Configuration Options

Select Storage Allocation task,
highlight the Symmetrix.
Access either SDR or Meta Device
Configuration via the icons.
SDR Meta Device Configuration
Select Storage Allocation task, highlight the

Symmetrix, access Configure Æ Symmetrix
from the menu bar
Right click on the Symmetrix and access the

Configure menu options.
Symmetrix Configuration is part of the “Storage Allocation” Task set in ControlCenter. Symmetrix
configuration options can be accessed one of three ways.
Select Storage Allocation from the Task Bar Æ Highlight the Symmetrix which you intend to
reconfigure Æ From the menu bar choose Configure Æ Symmetrix
Select Storage Allocation from the Task Bar Æ Highlight the Symmetrix which you intend to
reconfigure Æ Short cut icons are available for SDR and Meta Device Configuration
Right click on the Symmetrix which you intend to reconfigure Æ From the right click menu choose
Configure

Identifying the Primary Symmetrix Agent
If a Symmetrix can be managed by more than one Symmetrix Agent, ControlCenter designates one of
them as the Primary. To identify the Primary Symmetrix Agent use the Agents View in a Tabular
form. The name of the array an agent manages is listed in the “Responsible for Objects” column, and
the “Primary?” column shows if it is currently the primary. There should be only one primary agent of
each type for each array. It is the primary agent that will issue the configuration commands and log
the activity in the SYMAPI log.
Agents View: You can access this by clicking on the Agents Icon in the bottom right hand corner of
the Console. This will populate the view with all the ControlCenter agents currently deployed.
Alternately, you can switch the Target Panel to the Agents view (Pull down under ECC
Administration) and then drag the Symmetrix of interest into the Target Panel.
Configuration Management ECC - 10

Logical Device Configuration

y ControlCenter Console allows the following
– Device emulation – FBA only
– Device configuration (protection) - Unprotected, RAID-1 or RAID-
S/Parity RAID (3 or 7), RAID-5
– SAVE Devices for EMC Snap (DMX Symmetrix only – 5670+)
y Considerations
– Free (unconfigured) space must be available on the Symmetrix
– The number of hypers on the physical disks with free space should
be less than the maximum
– A Valid SSID (sub-system identifier) must be assigned to the new
devices if the Symmetrix serves both open systems and mainframe
– Once a device has been created it can be destroyed via the
ControlCenter Console only for DMX Symmetrix (5670+)
The ControlCenter Console only allows the creation of FBA (open systems) devices with the protection types listed on the
slide. For a DMX Symmertrix (5670+) running EMC Snap, you can designate devices to act as SAVE devices. The
Command Line interface allows the creation of devices with other emulations and protection types. (e.g. Emulation - FBA,
Celerra FBA, VME 512 FBA, CKD, AS/400.) As indicated earlier, the focus of this lesson is on the Symmetrix
Configuration capabilties of ControlCenter and not SYMCLI.
Device Creation considerations:
In order to create new Symmetrix Devices the Symmetrix must have un-configured space available, also the number of
hypers on each of the physical disks should be less than the maximum. The user simply sets up a request for the number of
devices with the desired protection type. The microcode then decides the exact location of the hyper volumes on the
physical disks themselves. The user does not have control over the location of the hyper volumes. The microcode uses the
following algorithm to determine the location of the hypers:
y Sorts by level of configuration complexity (most complex to least) RAID-S/Parity RAID, 4-3-2-way-mirror and
unprotected
y Sorts within each level by size starting from the largest to smallest
y Number of hypers on all disks should be roughly the same
y Starts on disks with the fewest hypers and continues in a round robin fashion
y All mirrors or hypers created must be on different physical disks with different access paths (disk directors/interfaces)
The ControlCenter Console and the Command Line Interface will allow you to delete (destroy) Symmetrix devices only in
DMX Symmetrix (5670+). The CLI can perform this function with Solutions Enabler 5.3.x, the ControlCenter Console
requires a Symmetrix agent on a host running Solutions Enabler 5.4.x or above.

Viewing Unconfigured Space
Select Properties from the Tool bar and then select

Symmetrix and physical disks from the Tree panel.
The Properties view of the Symmetrix displays the total unconfigured capacity available on the
Symmetrix. The total unconfigured capacity on the Symmetrix is the sum of the unconfigured space on
each of the physical disks. The unconfigured space is space on the disk that has not yet been
configured into hyper volumes.
The Properties view of an individual disk shows the Unconfigured space and the number of hypers
currently configured.

Device Configuration
Choose “Logical Device Configuration” by right clicking on the Symmetrix Æ Configure Æ Logical
Device Configuration.
ControlCenter will try to acquire the lock on the Symmetrix. Once the lock is acquired, a warning
message will be displayed. In order to successfully create new devices, all the devices on the
Symmetrix (excluding Virtual Devices) must be in a Ready state. If a device in not in a Ready state,
chances are that there are some problems with the Symmetrix and thus a Configuration Change will
not be allowed. Click OK to continue with the Logical Device Configuration process. The Logical
Device Configuration input screen will be displayed.

Device Configuration Input
• No. Volumes to Create: Number of new devices – user input.

• Emulation: FBA only – cannot be changed.
• Type/Host: Open System only – cannot be changed.
• Size: Number of Cylinders or MB.
• Unit: Cylinders or MB.
• Configuration: Unprotected, Mirrored-2, RAID-5 or Parity RAID
• SAVE device Type: Yes or No
The Logical Device Configuration input window will allow you to build a list of devices that you
would like to configure.
Choose the number of volumes to create (you have to choose multiples of 3 or 7 if you are creating
Parity RAID Devices).
ControlCenter only allows you to create FBA Devices.
You can specify the size in MB or Cylinders. The drop down list will show you the device sizes that
already exist on the Symmetrix. The recommendation is to choose the size from the drop down list, but
you can specify a different size if you want to.
Choose the Configuration (Protection Type) from the drop down list. RAID-5 devices can be
configured as 3+1 or 7+1 depending on what is already configured in the Symmetrix.
If the devices being configured are to be used as SAVE devices for use by TimeFinder SNAP on a
Symmetrix then select ‘Yes’ in the SAVE device Type option. If the Symmetrix model doesn’t
support SAVE devices then the SAVE device Type option will not be shown on the dialog.
Then Click ADD to create an entry in the ‘Requested Configuration” table.
You can create additional requests if you need. Then click on Execute to submit the configuration
change.

Device Configuration - Result
New devices will be in the Unmapped Devices folder
The Configuration session initiated via the Console will go through a number of steps described earlier
in the lesson.
y Submit
y Validate
y Prepare
y Commit
After the Commit is finished, the Configuration Lock on the Symmetrix is released and then
ControlCenter initiates a Database refresh to update the ControlCenter Repository with the most up to
date information about the Symmetrix.
The progress of the configuration change session with the various steps is shown on the Result page.

Meta Device Configuration

y ControlCenter allows the following:
y Concatenated Meta Volumes
– Create or Dissolve
– Add members
– Remove members
¾ Start removal from the tail member
y Striped Meta Volumes

– Create or Dissolve
– Add member
¾ Must have an identical Meta-BCV available on the Symmetrix to successfully add a member
to a striped meta while preserving data
¾ Only supported on certain microcode levels – Consult EMC in advance
¾ EMC Recommends adding all members in the same session rather than adding more
members later
– Remove members
¾ Not allowed
– Stripe width
¾ EMC recommends using a two (2) cylinder (960 KB) stripe width
¾ In a DMX Symmetrix, the stripe width is preset at two (2) cylinder (960 KB)
Meta devices are simply several logical devices that are presented to a host as just one larger device.
Within the Console it appears in most views to be several devices, though the partnered members are
easy to identify. Meta devices can be concatenated (data addressed linearly) or striped (data address
shuffled among the members).
There are restrictions in the manipulation of a striped Meta device. Adding a member to an existing
Striped Meta Volume is generally not recommended. Certain microcode levels will allow you to
preserve the data on the Striped Meta during the expansion process. To preserve the data on the
original meta, an identical BCV Meta should be available. If the microcode supports this feature, the
Symmetrix will make an identical BCV copy of the original meta and then add a device to the old
meta, and then re-stripe the data from the BCV meta to the larger striped meta.
Proceeding with the expansion of the meta without specifying a BCV Meta will result in data loss in
the original meta.

Meta Device Configuration – Considerations

y All member devices must have the same type of
– Protection (Raid S/Parity Raid, RAID-1, RAID-5)
– Emulation (ControlCenter will allow FBA only)
– Attribute (BCV or Standard)
y Devices must be unmapped before they can be formed

as members of a meta
y Changes to the attribute of a meta are done by changing
the attribute of the meta head
y Only the meta head is mapped to a front end port
The ControlCenter Meta Configuration Window will only show you the unmapped Standard and
unmapped BCV devices. In general the ControlCenter Console will prevent you from violating any of
the configuration rules. Standard or BCV Devices which have the Dynamic RDF attribute cannot be
formed into a meta. You must first take away the Dynamic RDF attribute. Create the Meta and then
give the Meta head of the new device the Dynamic RDF attribute.

Meta Device Configuration – Considerations …

y Capacity
– Largest capacity supported without RPQ – 1.1 TB
– Largest capacity possible – 3.825 TB
y Number of Members
– Largest number possible – 255
– Largest number tested by Performance Group – 48
– EMC generally recommends creating smaller meta volumes rather
than very large meta volumes
¾ Meta volumes with four, eight and sixteen members are preferred
y Choice of members
– Spread members evenly across DA ports and processors
– Avoid members on the same physical disk
– RAID-S/Parity RAID – Choose members from different RAID groups
Performance Considerations for Meta Volume

y Queuing enough IO to the meta volume is crucial to extracting optimal performance
y HBA vendors, operating systems and Enginuity all limit the number commands that can be queued
to a LUN
y EMC generally recommends creating smaller meta volumes rather than very large meta volumes
− Meta volumes with four, eight and sixteen members are preferred
y Multipathing software such as PowerPath ensures that the number of commands queued to the
meta volume would be the cumulative total of the commands queued to the meta volume on each
front end port

Display Disk Location of Unmapped Devices
Before creating a Meta device, it is a good idea to look at the back-end locations of the devices that
you intend to use as meta members. Ensure that the devices do not share the same physical disks and
that they are spread as evenly as possible across Disk Directors and ports. It is especially important to
make sure the devices do not share the same disk if you are creating a striped Meta, since you will lose
the effectiveness of striping the data to multiple physical drives.
The Visual storage view (Change the Target Panel to Visual Storage – Storage Allocation pull down)
of the unmapped devices will show you the back-end locations as shown in the slide.
When creating Meta volumes with RAID S or Parity Raid devices make sure they belong to different
RAID Groups. The Properties view in ControlCenter will show the Raid Group Number of the Device.

Creating Meta Volumes
3
2
2. Click Concatenated 3. Click Create Meta

1. Click the device or Striped
2. Or, Click meta head 3. Click Add Members
You might use any of the ways discussed earlier in this course to launch the Meta Device
Configuration dialog. There are three steps in creating a meta:
First, create the meta head. Choose the head device from the panel on the left of the dialog, which
shows all of the eligible devices on the array you selected when you launched the dialog. Then click
one of the meta types Concatenated or Striped in the right panel. Click “Create Meta” to add the
device to the type as a meta head. If this is not a DMX-model Symmetrix, you will be prompted for a
stripe size (DMX-models always use the same 0.94 MB stripe size).
Next, add members to the meta head. Click on the desired members in the left panel and the meta head
you just added in the right panel. Then click “Add Members” to add them as members.
Finally, click “Continue” to review and execute the changes.

Showing the Resulting Meta
You can find your new meta under the Meta Devices category under Unmapped Devices on the array
(the devices had to be unmapped during the meta creation process). Examining the Properties will
show the size of the members, the parameters, stripe size, and related meta members. Looking at the
Relationship view shows how the members are arranged on the back-end disks.

Device Mapping (SDR)

y ControlCenter allows the following
– Mapping and unmapping of open system devices to Fibre Channel (FA) or
SCSI (SA) ports only
– Move/Copy devices between front-end director ports
– Modify/Specify SCSI Target ID/LUN assignments
y Considerations
– Unprotected standard devices cannot be mapped
¾ Unprotected BCVs can be mapped
¾ Unprotected gatekeeper devices (smaller than 20 cylinders) can be mapped
– Determine the front-end director port to which the host is attached
¾ Devices should be mapped to more than one port in multipath and clustered
environments
– Ensure that the selected Target ID and LUN is appropriate for the host
– Reconfigure the host to enable it to recognize the new device
SDR Symmetrix Device Reallocation

Device Mapping via the Command Line interface provides these additional features as well:
y Open Systems or Mainframe (FBA and CKD)
y Specify Virtual bus (vbus) address if volume set addressing is used in HP-UX
y Specify CKD device number - OS/390 host
y Update VCMDB with WWN of HBA to allow access to device being mapped
Device Mapping - Considerations
y Unprotected standard devices cannot be mapped
− Unprotected BCVs can be mapped
− Unprotected gatekeeper devices (smaller than 20 cylinders) can be mapped
y Determine the front-end director port to which the host is attached
− Devices should be mapped to more than one port in multipath and clustered environments
y Ensure that the selected Target ID and LUN is appropriate for the host
− For example, many hosts do not support more than 8 LUNs per target ID
− Do not leave holes in LUN addressing (e.g. 10, 11, 12, 15, 16)
− A good rule of thumb is to maximize the use of target ID’s before using LUNs
y Reconfigure the host to enable it to recognize the new device.
− Reconfiguration may require reboot of the host in some cases
− If the host is attached via a switch, LUN masking has to be performed a well. We will cover LUN Masking later
on in this Module
− The new device might have to be “initialized” for access by the host Logical Volume Manager

Determine Array Port
The Path Details view in ControlCenter shows the array ports a particular device is mapped to. If you
want to make new storage devices available to the host in the same way, you can use this view to find
out how the current storage is accessed.

Map Device
Click the port, then click Move
Click the unmapped device
To map an unmapped device to an array port, bring up the SDR Device Mapping dialog using any of
the methods discussed earlier in the course. Then choose your unmapped device from the panel on the
left, and the port from the panel on the right. Click the Move button to map the device.
If mapping to a Fibre Channel port, the warning popup shown will appear to remind you to add the
device to the VCM database. The host will not have access to the device until it is masked.
To un-map a device that has been mapped, choose the device from the Host Directors part of the tree
on the left. You will find it under whatever director and port it is currently mapped to. Click the
device, and then the Unmap button.

Copy Device to Another Port
Click the already mapped Click the port, then click Copy
device
You will frequently want to map the same device to more than one array port to create redundant
paths. Use the copy feature of the SDR dialog for this purpose. Locate the device under the Host
Directors part of the tree on the left panel—remember, it is already mapped to at least one port. Then
click the additional port you would like to copy the device to in the right panel and hit the Copy
button.
The same device can be copied to any number of ports by repeating this procedure.

Change Device Address
You should always check the device address, or LUN number, before committing your changes. Many
hosts have restrictions regarding these numbers; gaps in the numbering is frequently disallowed. You
can find the automatically assigned address with the device itself in the right panel under the Host
Directors part of the tree. Just click the number to change it.

Execute SDR
Once you have made the changes in the dialog, click Continue to review (above). You can make
several changes to the mapping configuration and then commit them in one event. If everything looks
good, click Execute to begin the configuration change. Most changes do take some time, as the popup
alert shown here suggests. Newer arrays with faster processors naturally take less time to execute
changes. The progress of the change is displayed in the lower part of the window.
Once the change is complete, you can use the Properties view to examine the characteristics of the
device. The detailed view shows all of the ports that the device has been mapped to.

Device Type/Attribute Definition

y Device type definition
– Allows you to convert between Standard, BCV and DRV device
definitions
y Device attribute definition

– Allows you to give device the following attributes
¾ Double Checksum
¾ Dynamic SRDF (R1 or R2 or Both)
y Devices must be unmapped before changing definition

y Devices that cannot participate will be filtered out by the
Console. e.g.
– RAID-S, Parity RAID, RAID-5, SRDF, VDEV, SAV, COVD
– BCV or STD devices in a synchronized state, Meta members
Definitions:
y BCV — Business Continuance Volume: A device that functions as a mirror to a standard device to
create a protected storage environment. The BCV device can also be independently addressed.
y DRV — Dynamic Reallocation Volumes are used by Symmetrix Optimizer to store data
temporarily while moving logical devices from one hyper device to another.
y Double Checksum — Specifies the device to be included in RDB checksum validations. This
allows for an additional level of data integrity testing for Oracle data prior to writing the data.
y Dynamic SRDF R1, R2, and R1/R2 Capable — Historically, source and target SRDF device
pairing has been statically set at configuration time. These attributes allow an unmapped STD
device to be defined as an R1, R2, or both R1 and R2 capable without requiring a configuration
change. You must give the Dynamic SRDF attribute to logical devices on the local and remote
Symmetrix, and then you can dynamically pair them using the SRDF Create Dynamic Pair
command.
The Command Line interface allows the setting of the following additional attributes as well:
y WORM (Write Once Read Many)
y VCMDB
y SCSI3 Persistent Reserve (For SUN Cluster 3.0 environments)

Device Type Definition (BCV/DRV/STD)
To change the device type definition, go to the configuration menu by any of the methods discussed
earlier and choose Device Type Definition. After the configuration lock is acquired, the Device Type
Definition dialog shown above will appear. Just click on the devices you want to change and click the
BCV, DRV, or STD buttons.
Converting a 2-way-mir STD to BCV converts it to a BCV with 2-Way-Mir protection. Thus, changing
the device type definition does not alter the protection of the device.
As usual, clicking the Execute button will start the configuration session.
Note: To convert a device to a DRV it must be configured as Unprotected. A BCV cannot be converted
to a DRV directly, it must be converted to an STD first.

Device Attribute Definition
To change the device attribute definition, use the configuration menu to launch the Device Attribute
Definition dialog shown above. To add or remove an attribute, simply click in the cells under the
attribute column. Light blue colored cells indicate pending changes.
Dynamic R1 and R2 can both be assigned to the same device if desired. If a device is capable of both
Dynamic R1 and R2, it will be able to participate in SRDF Swaps in the future.

Device Protection Definition

– Convert a 2-Way Mirrored device to Unprotected
– Convert an Unprotected device to 2-Way Mirrored
y Considerations
– 2-Way Mirrored Æ Unprotected
¾ Existing device will lose a mirror and a new unprotected device will be
created
¾ End up with two unprotected devices, one with the original Symmetrix
device number and one with a new number
– Unprotected Æ 2-Way Mirrored
¾ Unconfigured space must be available on the Symmetrix
¾ New hyper will be created on a physical disk, this hyper will then
become the second mirror of the original unprotected device
¾ Cannot take two unprotected Symmetrix devices and combine them to
form one 2-Way mirrored device

Device Protection Definition - Add/Remove mirror
before:
after:
Bring up the Device Protection Definition dialog to change the protection of a device. The
ControlCenter Console will only show devices on which the ‘Device Protection” changes can be made.
Hence it will filter out all RAID S/Parity RAID and Mapped 2-Way Mirrored devices.
Click on the Device of interest and then either choose Unprotected or Mirror as appropriate.
The warning message shown above will appear if you are un-protecting a device. Unprotected
Standard devices (larger than 20 cylinders) cannot be Mapped to a front end port unless they are given
the BCV attribute.
The pending changes are show in Blue italics. Click on Execute to commit the configuration change.
The example at the bottom of this illustration shows a BCV that has been unprotected. Each mirror
becomes an independent device, with a new device number being generated for the additional mirror.

SRDF Device Definition

– Configure static SRDF device pairs from existing Symmetrix devices
– Mirrored, RAID 5, or Unprotected devices only
– Devices with dynamic SRDF capability will not be available
¾ Dynamic RDF pairs have to be created/deleted via SRDF/TimeFinder
Manager
y Considerations
– Symmetrix should have been configured for SRDF
– Configuration lock has to be acquired on both Symmetrix
– SRDF RA Groups must exist
¾ ControlCenter cannot create new RA Groups
– Cannot delete or destroy static SRDF device pair relationship via
ContolCenter
– ControlCenter will filter out all Parity RAID and RAID S devices
The SRDF Device Definition configuration adds the R1 attribute to a local device and the R2 option to
a remote device, making them a linked SRDF pair.
This option creates static SRDF Device pairs only. As we have seen, the Dynamic SRDF attribute is
enabled in the Device Attribute Definition dialog, not the SRDF Device Definition dialog.
Parity RAID and RAID S devices can be static SRDF devices. However ControlCenter will NOT
allow the creation of static SRDF device pairs with RAID S or Parity RAID devices. Static SRDF Pairs
with Parity RAID or RAID S devices have to be create via the Command Line Interface.

SRDF Device Definition
1
2
Use any of the methods described previously to launch the SRDF Device Definition dialog. The Select
Symmetrix Screen will pop up first. Choose the Local and Remote Symmetrix from the Drop down
lists. Choose the RA Group Number from the list (cannot create a new RA Group). Choose what SRDF
type(R1 or R2) the local device will be.
The Configuration Lock is acquired and the Warning message shown in Step 2 on the slide will pop
up.
From the “Select Local R1 Device” Column select the device that will become the R1. Before you pick
a device from the Select Local column, the Select Remote R2 Device column will be empty. Once you
select a device from the Select Local column, suitable devices will be displayed on the Select Remote
R2 Device column. Pick a device from the Select Remote R2 Device column and click the Add button
to add this pairing into the Selected RDF pairs table.
When an SRDF Device Pair is created, the previously separate devices will be synchronized with the
same set of data. You have the choice of invalidating or losing the data on either the local or the
remote device. The point to remember is that the device that is being invalidated must be unmapped or
in a Write Disabled or Not Ready state. Click OK to acknowledge the message.

Port Flag Settings

y Change settings of SCSI or Fiber Channel front-end
director ports
y Considerations
– Settings may have to be changed when adding hosts to existing
switched configurations or for preparing an unused port for host
connectivity
– EMC recommends that you temporarily suspend I/O activity to the
affected ports when setting front-end port attributes
– Incorrectly changing the port flags can render your Symmetrix
storage system inaccessible. Be certain of the results of any change
before resetting any of these flags
Considerations:
You should not change the individual flag settings without consulting EMC Customer
Support. Failure to configure these values properly can result in a host no longer being able to
communicate with a Symmetrix array. Changing a flag on one FA port can have an impact on another
port connected to the same processor. For example, a port flag change on FA 14 port 0 impacts FA14
port 1 as well. There is no Undo capacity for this operation, although you can perform an operation in
the same session to revert to a previous state. Verify your actions before proceeding.
The EMC Support Matrix available on EMC PowerLink provides details on the various port flag
settings that are required for various hosts.

Port Flags Settings – Host Policy

y Select the host from Host Policy list
y Select the front-end director port to which the host must be added
y Click on Add to add to the Selected list
y Click Next
When you choose Port Flags Settings from the configuration menu, you will first see a Default Settings
dialog like the one above. You can use it to choose the standard settings for certain operating system
configurations. Just choose the policy and the port and click the Add button. If none of these settings
suits your needs, you can just hit Next without making any changes here.

Port Flags Settings – Review/Manual Edit
The second part of the Port Flags Settings dialog gives you a chance to make detailed edits to the flag
settings. Every flag which is appropriate for the type of port can be edited here by clicking in the box.
A bullet indicates the flag is set; an empty box means it is not set. Settings that can not be edited are in
gray. The two tabs choose the Fibre or SCSI flags for each port.
The Help button will launch a descriptive help text for this dialog, including a description of each port
setting. But again, do not rely only on the Help text when planning port flag changes—consult with
EMC also.

Delete Logical Devices
Use the Delete Logical Device configuration menu to delete one or more devices. This is one of the
few configuration menu dialogs that does not allow you to choose the devices within the dialog. All of
the devices selected on the console when the menu was launched will be deleted! If you right-clicked
on a single device to launch the dialog, only that device will be deleted. If you selected multiple
devices and right-clicked, all of them will be deleted. If you selected a Symmetrix and right-clicked,
all eligible devices on the array will be deleted! Be especially careful with this command.
Devices can only be deleted if they are not:
• Members of a RAID-5 group
• Mapped to a port, or masked to a host
• Attached to a BCV or DRV device
• A VDEV device that is in use
• The source or target of a TimeFinder Clone session
• DRV, BCV, SRDF, Meta head, or Meta member (other configuration commands can remove
these attributes, making the device eligible for deletion)
• WORM protected
• Save device, VCM database device, or SFS device

Set Symmetrix Attributes and SRDF/A Attributes
Right-Click a
Symmetrix to
edit Attributes
Right-Click an RA group to edit SRDF/A Attributes
Launch the Set Symmetrix Attributes dialog from the configuration menu using any of the methods discussed earlier. You
can edit a variety of global Symmetrix settings in this dialog. The settings are:
Max Number of Hypers: Maximum number of hypers per physical disk. Range is 1 to 255.
Enable FBA Multi Access Cache: Determines whether a read request can share cache slots in some conditions.
Allow VCMDB restricted access: Restricts VCMDB host access as indicated by the user.
The RAID options enable Parity and RAID5, and set the Parity level (3+1 or 7+1).
The RDF options enable Dynamic or Concurrent SRDF.
The Max SRDF/A Host Throttle sets the number of seconds that host writes will be throttled before dropping SRDF/A
sessions when the SRDF/A cache buffer is full.
The Max SRDF/A Cache Usage sets how much of available write pending cache (which is typically 80% of all cache) to
allow the SRDF/A buffer to consume.
Naturally, you should consult with EMC before making global changes to your array.
You can configure SRDF/A Attributes for individual RA groups. Right-click on an RA group and choose Set SRDF/A
Attributes from the configure menu to get the dialog shown at the bottom of the illustration. You can set the minimum
cycle time, or the minimum wait time before attempting an RDF/A cycle switch. Values range from 5 to 59 seconds. You
can also set the SRDF/A Group Priority, which controls what SRDF/A sessions to drop when memory gets full. RAs with
higher numbers will be dropped before those with lower numbers.

Save Pools
y Storage devices used to track changes in TimeFinder
SNAP sessions
y Save devices are created in the Logical Device
Configuration dialog; new Save devices appear in the
Default Pool
y New Save Pools are created and
edited in the Save Pool part
of the configuration menu
y Select a pool when starting a
SNAP session
A Save Pool is a collection of devices used to track changes in TimeFinder SNAP sessions. In this sort
of replication, only changed data is stored on the devices in the Save Pool. Changed data is distributed
evenly around the devices—a user only chooses a pool to associate with the SNAP session.
You create Save Devices in the Logical Device Configuration dialog which was discussed previously.
Save Devices can be Mirror or Parity RAID protected. Newly created Save devices end up in the
Default Pool (DEFAULT_POOL) in an Inactive state. Save devices are not found in the Console
outside of one of the pools.
Use the Save Pool part of the configuration menu to create and edit Save Pools themselves.
Active SNAP sessions can cause many writes to the associated Save Pool. You might want to create
separate Save Pools to prioritize the performance characteristics. You might assign many low priority
SNAP sessions to the default pool, but assign only a few high priority sessions to a different pool. The
devices in the high priority pool will have less contention for disk resources because there are fewer
sessions competing for them.
The down side of partitioning the Save devices into different pools is that a single session can not
“borrow” from another pool if the present pool runs out of space. You might end up wasting disk
space if you have more than one Save Pool.

Creating and Editing Save Pools
To create a new Save Pool, launch the New Save Pool dialog from the menu. You can type the name
of the new pool and choose its emulation (FBA or CKD: choose to match the type of devices it will be
associated with) at the top.
At the left are the available Save Devices: devices in the DEFAULT_POOL which are in the Inactive
state. Click on one or more and use the Add button to move it to the Selected Save Devices panel on
the right.
Use the buttons near the bottom to Activate and Deactivate the devices selected for the pool. Active
devices can be used for SNAP sessions. A device must be deactivated before it can be removed from a
pool.
The Edit Save Pool dialog (not shown) is nearly identical to this New Save Pool dialog shown above.
You can not change the name or Emulation of the save pool with the Edit dialog; otherwise, all of the
other controls are present. Use it to add available devices to the pool, remove inactive devices, and
change devices from active to/from inactive. Removing a device from a pool just moves it to the
DEFAULT_POOL leaving it in the Inactive state.

Deleting Save Pools and Devices
Right-click directly on one or more Save devices or an entire Save Pool in the Console and use Delete
Save Devices from the configuration menu to delete the device from the pool. All the devices you
clicked must be in the Inactive state before you can delete it (use Edit Save Pool to make them
Inactive). Deleting a devices has the exact same effect as using the Edit dialog to remove it from the
named pool: the device simply moves to the DEFAULT_POOL in the inactive state. From this state, it
can be re-assigned to another named pool, but it is not actually deleted from the array. You can not
delete a device from the DEFAULT_POOL. No ControlCenter command can completely delete a
Save device.
Right-click directly on a save pool in the Console and use Delete Save Pool from the configuration
menu to delete a save pool . You can not click on the Symmetrix itself to do this. The save pool must
be Disabled before it can be deleted—make it Disabled by first deleting all of the devices from the
pool. The DEFAULT_POOL can not be deleted.

Module 3: Summary
y Performing configuration changes using the
ControlCenter GUI


Module 4: Configuration Management SMC

© 2007 EMC Corporation. All rights reserved. Configuration Management SMC - 1
Configuration Management SMC -1


y Independent, light-weight, web-based
application
– Simple and easy to use browser interface
– Hosted on small Windows/Linux server
– Enables remote access and management
from nearly any client SRM Planning
Storage Management
y Enables access, configuration, and basic and Provisioning
operation of Symmetrix arrays
Services
– Supports all configuration capabilities of
Solutions Enabler/CLI SRM Monitoring
y Supports multiple generations of Symmetrix and Reporting
– Enginuity version 5x68 and newer
y Provides day-one support of new Symmetrix
features when released Device Management
y Adding full-feature ControlCenter does not
require management data to be migrated
EMC completes the device management offering with the addition of Symmetrix Management
Console (SMC for short), enabling you to deploy a light-weight, web-based Graphical User Interface,
or GUI, for performing device management in Symmetrix environments. You can now choose the right
management product or products to meet your specific requirements. Almost anything you can do
using the Solutions Enabler CLI can now be done using the SMC GUI. And, SMC will manage all
Symmetrix systems running Enginuity version 5568 and newer, and will support new hardware and
software features and functionality at the time of product release. Addressing customer demands for
enhanced platform interoperability. SMC is an independent application which runs using its own
lightweight Windows/Linux server. The client runs in a browser window, therefore supporting nearly
any client with remote access to the server. The SMC GUI features closely match Solutions Enabler
CLI features to include all basic monitoring, configuration and control of Symmetrix arrays. SMC has
no Symmetrix-related database other than the Solutions Enabler database, so all data automatically
transfers to the full-feature ControlCenter when discovered by the Symmetrix agent. Due to the
combination of being light-weight yet feature rich, early response to SMC shows it to be a leader in
this type of product

SMC Architecture - Client/Server Infrastructure

y Browser based user access
to SMC server
– Can run SMC from any
client with connectivity to Client SMC Server
Client
host SMC server gatekeepers
– Internet Explorer 6.x or

SMC and Base
Firefox 1.0.5
license keys
– Based on applets
automatically downloaded y SMC Server runs on
to the client Windows 2000 Server or
– 256 MB of memory is the Windows 2003 Server or
stated client requirement Linux (32-bit only)
– tested to use less than 128 – Java based application
MB of memory
¾ Requires 512MB of server
memory
– 128 bit SSL Security available
– Is a SYMAPI application
This image depicts the SMC Client-Server Architecture. Any client which runs a supported Browser
and can network to the SMC server can be used, and does not need to run in the same host as the SMC
Server. The client console is very lightweight and has been tested to use less than 128 megabytes of
memory, however the stated client requirement is 256 megabytes. The client checks for a Java plug-in
at rev 1.5 or above. The SMC Server can run on any of the Windows/Linux platforms listed here. For
Linux the support is restricted to 32-bit operation systems which are running either Redhat AS/ES 4
update 3 or SuSE Linux 9 SP2. On installation, the server memory is checked for a minimum of
512MB, although typical implementations will use less memory. The server is a SYMAPI application
and requires Solutions Enabler version 6.3 or later to be installed. The SMC and Base SYMAPI license
keys are required on the SMC Server Host. The basic configuration shown here contains a single
visible Symmetrix. The SYMAPI database on the SMC server host determines which Symmetrix
arrays are eligible for view in console. SMC permissions determine whether a particular SMC user can
see each Symmetrix in the database. Both local and SRDF single-hop Symmetrix arrays are displayed
in the console. The stated limit for one SMC server is six Symmetrix arrays with an average 4000
volumes each, for a total of 24,000 volumes. A configuration up to this limit will provide reasonable
response time with reasonable resources. The Client console browser can be pointed to a different
SMC Server in order to see different Symmetrix arrays. Secure Communication is available with 128
bit SSL security for the Client-Server connection; however the encryption-decryption process adds a
ten-percent performance penalty. When the host for the SMC Server does not have Symmetrix
gatekeepers, it can remotely access another host with gatekeepers, as displayed in the next slide.

Components of the SMC Interface
Menu
Menu Bar
Bar
View
View Bar
Bar
(Properties)
(Properties) View
View (Details)
(Details)
Navigation Tree
The major components of the SMC Interface are highlighted here. To monitor and control operations,
you can select a single object or a single folder of multiple objects in the Navigation Tree.
The View Bar is used to switch between five different views: Properties, Config Session, Alerts,
Command History and Replication Monitor. The view currently selected displays in the view area. The
View button and corresponding view display are color coded to match. Note the Alert counter in the
top right, which also selects the Alert View. Tree Selection, View selection, and object selection within
the View area determine the current display. The View may be split horizontally into two or three
areas depending on the detail associated with the selection.

Action Menu and Dialog

y Right clicking within the
Navigation tree displays
hierarchical action menus
– Actions that are not available at
that moment are gray
y Selecting an action displays

one or more dialog boxes
This is an example of using the menus and dialog to complete an action. As typical with other
interfaces, you can point the cursor at a menu choice to open a sub-menu. In this example, the
Symmetrix Admin menu opens by right-clicking the selected Symmetrix 000187910035. Choosing
Symmetrix Attributes from the second level menu opens the dialog box. Within the dialog box the
SRDF/A Maximum Cache Usage (Percent) could be changed from the default value of 94 and applied
by clicking Add to Config Session List.
SMC uses dialog boxes for almost all control actions. Dialog boxes provide a means for the user to
specify selections and parameters appropriate to each action. Object specification within dialog tables
are multi-selectable and are filtered based on both the initial selection that invoked the dialog and
using filters within the dialog. Dialog Actions are completed using one or more dialog boxes. For
example, Wizards generally run a series of dialog boxes which must be completed to invoke the action.
Some dialog boxes provide a means for the user to invoke an action, and remain in the dialog for
additional actions with the Apply button.

Config Session View

y Config Session View automatically displayed after a
Configuration Action
The ConfigSession View is similar to the Properties view, using tabs to display different groupings of
Configuration Tasks and allowing space for multiple displays. This lesson introduces the different
SMC Views, while further information about configuration operations will be presented in a later
lesson.

Creating Symmetrix Device

y Device Configuration Æ Create Device
Let us take a look at creating Symmetrix Devices. Right click on a Symmetrix, choose Device
Configuration and then Create Device to launch the dialog window shown.
Enter the number of devices, Configuration (2-way-mir, BCV etc. Select via drop down), Emulation
(FBA, CKD etc. Select from drop down), Device capacity in Cylinders. Additional input may be
required for RDF device configuration.
Click on the Add to Config Session List to add this configuration request to the ConfigSession view.
The ConfigSession view has to be used to send the Commit operation to the Symmetrix Array.
The next three slides discuss the use of the ConfigSession.

Config Session – My Active Tasks
Logged in User ID Config Session Active Task list, possible actions
y Deactivate - move one or more tasks to My Inactive

y Preview All - locks the array and runs a SymmWin preview script for all
user active tasks; lock is released upon completion
y Commit All - locks the array and runs a SymmWin commit script for all
user active task; lock is released upon completion
y Abort All - only available during running Preview or Commit, will abort
SymmWin configuration session if Commit not yet at point of no return;
lock is released upon successful abort
This sequence of managing Config Session Tasks is demonstrated in a series of three slides. This
example shows tasks that are ready to Preview or Commit. You can only manipulate tasks created with
the same user name used to log into SMC. My Active Tasks or My Inactive Tasks only include tasks
created by the same user name. It is important to know that Preview, Commit and Abort apply to all
tasks in the My Active Tasks list. To omit tasks, you can move them to the My Inactive folder, and
then take action on all the remaining Active tasks.
Thus in this example if only the device creation task is to be committed. One would Deactivate the
Symm Attribute task and then click on the Commit All button to start the device creation process.

Config Session – All Active Tasks

y Can View Tasks for All Users
y No actions possible
y Red lock icon (lock 15)
This screen capture is of a different User ID client while the configuration change was in progress.
Notice that all action buttons are gray. The action buttons are not available because this is not the My
Active Tasks list. Lock 15, the Symmetrix Configuration lock displayed with the red lock icon, will
prevent any other configuration changes from executing until it is released. Lock 15 should never be
released without fully understanding that there is a hung configuration change that cannot be cleared in
any other way. The Lock is the way the Symmetrix ensures secure completion of a configuration
change without conflict from any simultaneous configuration change by another application. This
SMC release does a simple release of lock 15, similar to previous versions of SYMCLI.

Config Session – My Inactive Tasks

y Current user Config Session Inactive Task list, possible actions
– Activate, move one or more tasks to My Active Tasks
– Clear, permanently deletes one or more tasks from the Inactive Lists
¾ Completed tasks and Deactivated Tasks remain Inactive until cleared
This screen capture displays the My Inactive Tasks list. Completed tasks and Deactivated tasks are
shown in the Inactive task list. Tasks persist until they are cleared. As in this example, Committed
Tasks are implicitly deactivated, and therefore still listed under the My Inactive Tasks tab. Actually,
the persistence of tasks is in the memory of the SMC Server. If the Server is stopped, all tasks will be
cleared
Configuration Management SMC - 10

Creating an FBA Meta Device

y FBA Meta Device Configuration Æ Form Meta
Filter to see reserved devices
Add devices to form meta
Let us explore the creation of FBA Meta Devices. Right click on a Symmetrix and choose FBA Meta
Device Configuration, then choose Form Meta. In the example shown, the reservation filter is used to
only show those devices reserved by the current SMC user. Four devices are listed in the unmapped
devices list. Add all moves the devcies to the Meta member column. The meta head can then be
specified. As with all confguration tasks click on the Add to Config Session list button. The actual
commit of this action will be done from ConfigSession view.
When creating a meta one can optionally use the “Auto Select” feature. The Auto select feature allows
one to specify the # of metas, # of meta members per meta and the meta heads only. The Symmetrix
microcode will automatically choose the meta members from the available pool of unmapped devices.

Mapping Devices
y Device Masking and Mapping Æ Map Devices
– Launches the Masking Wizard (5 Steps)
Device Mapping is done by right clicking the Symmetrix or Device or Device Folder and choosing
Device Masking and Mapping, then Map Devices. The Mapping dialog has 5 pages. In Page 1 the
devices to be mapped are chosen,
In Page 2 the ports to which the devices are to be mapped are chosen.

Mapping Devices …
3
4
This is a continuation of mapping devices. On Page 3 the LUN Address is specified. The Wizard
automatically picks the next available address. The auto generated LUNs can be edited.
In Page 4 LUN Masking can be optionally done. Note that this wizard only allows the specification of
one initiator per device per port. Use the Masking task if multiple initiators are to be masked to the
same device via the same port.
Page 5 allows the user to review the selections (use the back button or click on the notepad to make
changes). Finally the task can be added to the Config Session list.

Masking Devices
y Device Masking and Mapping Æ Masking
The masking dialog can be initiated by right clicking on a Symmetrix, a Symmetrix port or an HBA
and then choosing Device Masking and Mapping followed by Masking. This launches the masking
dialog box.
Choose a Director port from the drop down list.
Pick an initiator (usually an host HBA) by clicking on Select and choosing one of the initiators that
have already logging into the Symmetrix or type in a world wide name. The initiator could also be
storage port – This would be the case in an Open Replicator/SAN Copy environment.
Use the appropriate filter to display devices in the Available Devices column (unmapped devices could
also be included). The reserved devices filter is also available in this dialog.
Then choose the device to me masked and add it to the Target column.
Apply executes the masking operation and keeps the dialog open for further masking operations. Ok
will execute the masking operation and close the window.
The VCMDB can be refreshed optionally (recommended) when the Apply/OK button is clicked.
Note that masking does not use the Config Session list. Clicking on Apply or Ok commits the masking
operation immediately.

Module 4: Summary
y Performing Symmetrix configuration changes using the

Course Summary
Key Points covered in this course:
command line interface
ControlCenter GUI

Closing Slide

StudentGuideDMX3 - SYMcfg

Uploaded by

Document Information

Original Description:

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

StudentGuideDMX3 - SYMcfg

Uploaded by

Copyright:

Available Formats

Copyright © 2007 EMC Corporation. Do not Copy - All Rights Reserved.

Symmetrix Configuration Management

© 2007 EMC Corporation. All rights reserved.

Welcome to Symmetrix Configuration Management.

Symmetrix Configuration Management -1

1.0 December, 2004 Complete

© 2007 EMC Corporation. All rights reserved. Symmetrix Configuration Management - 2

Copyright © 2007 EMC Corporation. All rights reserved.

EMC, is a registered trademark of EMC Corporation.

Symmetrix Configuration Management -2

Symmetrix Configuration Management

© 2007 EMC Corporation. All rights reserved. Symmetrix Configuration Management - 3

Symmetrix Configuration Management -3

Symmetrix Configuration Management -4

Module 1: Configuration Management

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 1

Configuration Management Fundamentals -1

Configuration Manager Introduction

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 2

Configuration Management Fundamentals -2

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 3

Configuration Management Fundamentals -3

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 4

Configuration Management Fundamentals -4

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 5

Configuration Management Fundamentals -5

Creating New HVEs

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 6

Configuration Management Fundamentals -6

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 7

Configuration Management Fundamentals -7

Mapping and Unmapping Devices

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 8

Configuration Management Fundamentals -8

Manage Meta Devices

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 9

Configuration Management Fundamentals -9

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 10

Configuration Management Fundamentals - 10

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 11

You can increase device protection by adding a mirror.

Configuration Management Fundamentals - 11

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 12

You can decrease device protection by removing a mirror.

Configuration Management Fundamentals - 12

Setting Front-End Port Flags

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 13

Configuration Management Fundamentals - 13

Setting Device Emulation

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 14

Configuration Management Fundamentals - 14

Setting Device Attributes

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 15

Configuration Management Fundamentals - 15

Setting Symmetrix Metrics

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 16

Configuration Management Fundamentals - 16

Spare Disk Management

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 17

Configuration Management Fundamentals - 17

Swapping RDF Personalities within a RA Group

© 2007 EMC Corporation. All rights reserved. Configuration Management Fundamentals - 18