h5765 Data Migration Open Replicator Symm Ppme Techbook

Data Migration:
EMC Open Replicator for Symmetrix

and PowerPath Migration Enabler
Version 1.2
EMC Open Replicator for Symmetrix Features

Open Replicator Setup and Verification
Open Replicator and PPME Migration Examples
Donald Fried-Tanzer
SOLUTIONS GUIDE
Copyright 2008, 2010 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is
subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES
NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION
IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable
software license.
For the most up-to-date regulatory document for your product line, go to the Technical Documentation and
Advisories section on EMC Powerlink.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.
Data Migration: EMC Open Replicator for Symmetrix and PowerPath Migration Enabler
Version 1.2
P/N H5765.2
Data Migration: EMC Open Replicator and PowerPath Migration Enabler Version 1.2
Contents
Preface
Chapter 1
Introduction
1.1 Introduction ...........................................................................
1.2 Data Migration definition ....................................................
1.3 EMC Open Replicator for Symmetrix................................
1.3.1 Terminology: control and remote.............................
1.3.2 Control FA "host" setup requirements ....................
1.3.3 Terminology: push and pull, cold and hot .............
1.3.4 Multipathing with hot setup requirements ............
1.4 EMC PowerPath Migration Enabler (PPME)....................
1.5 Migration project steps.........................................................
1.6 When to use Open Replicator with PPME ........................
1.7 Operational interfaces ..........................................................
Chapter 2
22
22
22
22
23
23
23
24
24
25
27
Brief EMC Foundation and Migration Product

Descriptions
2.1 Introduction ........................................................................... 30
2.2 EMC Symmetrix storage arrays and associated software 32
2.2.1 Basic architecture ........................................................ 32
2.2.2 EMC Enginuity Operating Environment ................ 32
2.2.3 Symmetrix Logical Volumes (SLVs) ........................ 33
2.2.4 Symmetrix V-Max and Symmetrix DMX arrays
and Open Replicator ........................................................... 33
2.2.5 Pre-DMX Symmetrix arrays and Open Replicator 33
2.2.6 Other Symmetrix software ........................................ 34
2.3 EMC CLARiiON and associated software ........................ 35
2.3.1 EMC MirrorView ........................................................ 35
Data Migration: Open Replicator and PowerPath Migration Enabler Version 1.2
2.3.2 SnapView .....................................................................

2.3.3 SAN Copy ....................................................................
2.3.4 Navisphere Management Suite ................................
2.4 EMC SAN products ..............................................................
2.4.1 Connectrix....................................................................
2.4.2 Connectrix Manager ...................................................
2.4.3 SAN Manager ..............................................................
2.4.4 Invista ...........................................................................
2.5 EMC Host products ..............................................................
2.5.1 PowerPath Family.......................................................
2.5.2 Replication Manager ..................................................
2.5.3 EMC Solutions Enabler ..............................................
2.5.4 Symmetrix Management Console (SMC)................
2.5.5 EMC Ionix ControlCenter..........................................
2.6 Consulting and IT Services..................................................
2.6.1 Infrastructure Consulting ..........................................
2.6.2 Implementation...........................................................
Chapter 3

3.1 Introduction ...........................................................................
3.2 Definitions..............................................................................
3.2.1 Hot push.......................................................................
3.2.2 Cold push.....................................................................
3.2.3 Hot pull ........................................................................
3.2.4 Cold pull.......................................................................
3.2.5 Open Replicator interaction rules with SRDF ........
3.3 Basic Open Replicator migration operation flow .............
3.3.1 Setup steps ...................................................................
3.3.2 Migration steps............................................................
3.3.3 Cleanup steps ..............................................................
3.4 Monitoring, troubleshooting and recovery.......................
3.5 Control interface alternatives ..............................................
3.5.1 Solutions Enabler CLI ................................................
3.5.2 Symmetrix Management Console GUI....................
3.5.3 PowerPath Migration Enabler (PPME) CLI ............
3.6 Reference information ..........................................................
Chapter 4
36
36
36
37
37
37
37
37
39
39
39
40
40
41
41
42
43
46
46
46
47
49
50
51
52
52
56
61
62
63
63
63
64
64
Cold Push to CLARiiON Setup Example

4.1 Introduction ........................................................................... 66
4.2 Setup step 1, identify target devices................................... 66
4.3 Setup step 2, configure migration SAN zones .................. 68
4.3.1 Determining Control Director WWN ......................

4.3.2 Determining Remote Storage Array WWN(s) ........
4.3.3 Selective or all Symmetrix FA Zoning .....................
4.3.4 Example configuration of migration SAN zones ...
4.4 Setup step 3, configure migration LUN masking.............
4.4.1 Create CLARiiON storage group .............................
4.4.2 Register host and add devices to CLARiiON
storage group........................................................................
4.5 Setup step 5, prepare Open Replicator session pairs .......
4.6 Setup step 6, verify completion of setup steps..................
4.6.1 Create action is a thorough verification step ..........
4.6.2 Verify zoning with symsan -sanports ..................
4.6.3 Verify LUN masking with symsan -sanluns ........
4.6.4 Verify zoning with symmask list logins ............
4.6.5 Verify all with symrcopy create.............................
4.6.6 SMC Remote Report ...................................................
Chapter 5
68
69
72
72
73
73
73
74
75
75
75
77
78
79
80
Cold Push to CLARiiON Migration Example

5.1 Introduction ........................................................................... 84
5.2 Migration step 7, BCV split.................................................. 87
5.2.1 Device Group creation ............................................... 87
5.2.2 Initial TimeFinder/Mirror establish......................... 89
5.2.3 TimeFinder/Mirror split............................................ 90
5.3 Migration step 8, symrcopy create...................................... 92
5.3.1 Cold control devices must be Not Ready ................ 92
5.3.2 Create action options .................................................. 93
5.3.3 Open Replication query display ............................... 94
5.3.4 Query -detail option ................................................... 95
5.4 Migration step 10, symrcopy activate ................................ 96
5.5 Migration step 12, symrcopy set ceiling ............................ 97
5.6 Migration step 13, symrcopy query and verify ................ 99
5.7 Migration step 14, iterative symrcopy recreate .............. 100
5.7.1 Incrementally update control devices from
production devices............................................................. 100
5.7.2 Incrementally update remote devices from
control devices.................................................................... 101
5.7.3 Stop applications and final incremental update... 102
5.8 Migration step 15, verify migration and symrcopy
terminate..................................................................................... 104
5.8.1 Hot push differences from cold push .................... 104
5.9 Cleanup step 16, make source devices host inaccessible 106
5.10 Cleanup step 17, make target devices ready to host .... 107
5.11 Cleanup step 18, restart applications using targets ..... 108
5.12 Cleanup step 19, redeploy the source devices storage 110
Chapter 6
Hot Pull from CLARiiON Migration Example

6.1 Introduction ......................................................................... 112
6.1.1 Hot pull setup steps.................................................. 112
6.1.2 Hot pull migration steps.......................................... 112
6.1.3 Hot pull cleanup step ............................................... 113
6.2 Setup step 1, identify target devices................................. 115
6.3 Setup step 2, configure migration SAN zone.................. 116
6.3.1 Determining control director WWNs .................... 116
6.3.2 Determining remote storage array WWNs ........... 117
6.3.3 Reuse existing migration SAN zones..................... 117
6.4 Setup step 3, configure migration LUN masking........... 118
6.4.1 Create CLARiiON Storage Group .......................... 118
6.5 Setup step 4, configure target zoning and LUN
masking ...................................................................................... 119
6.6 Setup step 5, Prepare Open Replicator session pairs file 121
6.7 Setup step 6, verify completion of setup steps ............... 124
6.7.1 Discover missing zoning with symrcopy create .. 124
6.7.2 Example configuration of additional migration
SAN zone ............................................................................ 126
6.7.3 Discover missing LUN masking with symrcopy
create.................................................................................... 126
6.7.4 Example LUN masking for all Symmetrix V-Max
(or Symmetrix DMX) FA control directors .................... 128
6.7.5 Successful create verifies hot pull setup................ 128
6.8 Migration step 9, Stop the applications ........................... 129
6.9 Migration step 10, symrcopy activate .............................. 131
6.10 Migration step 11, Restart applications using targets.. 132
6.11 Migration step 13, symrcopy query and verify ............ 137
6.12 Migration step 15, verify migration and terminate...... 138
6.13 Cleanup step 19, redeploy the source devices .............. 138
Chapter 7
Hot Pull from Symmetrix Migration Example

7.1 Introduction .........................................................................
7.1.1 Hot pull setup steps..................................................
7.1.2 Hot pull migration steps..........................................
7.1.3 Hot pull cleanup step ...............................................
7.2 Setup step 1, identify target devices.................................
7.3 Setup step 2, configure migration SAN zone..................
140
140
141
141
143
144
7.3.1 Determining control director World Wide Port

Names (WWPNs) ............................................................... 144
7.3.2 Determining Remote Storage Array WWPN(s).... 146
7.3.3 Configuration of migration SAN zones................. 148
7.4 Setup step 3, configure migration device masking ........ 149
7.4.1 Application source device references..................... 149
7.4.2 Add Symmetrix device masking ............................ 150
7.4.3 Symmetrix V-Max device masking using
Auto-provisioning Groups ............................................... 152
7.5 Setup step 4, configure target zoning and LUN
masking....................................................................................... 165
7.6 Setup step 5, prepare Open Replicator session pairs file 166
7.7 Setup step 6, verify completion of setup steps................ 170
7.7.1 Confirm hot pull setup with successful create ..... 170
7.7.2 SMC Remote Report ................................................. 172
7.8 Migration step 9, stop the applications ............................ 174
7.9 Migration step 10, Open Replicator activate ................... 177
7.10 Migration step 11, restart applications using targets... 179
7.11 Migration step 12, tune migration ................................. 181
7.12 Migration step 13, check status, wait until copied ....... 183
7.13 Migration step 15, verify migration and terminate...... 184
7.14 Cleanup step 19, redeploy the source devices .............. 186
Chapter 8
PowerPath Migration Enabler (PPME) Overview

8.1 Introduction .........................................................................
8.2 Benefits of using PPME ......................................................
8.3 Nondisruptive migration overview .................................
8.4 Definitions ............................................................................
8.4.1 Pseudo or Native device name migrations ...........
8.4.2 Source and target ......................................................
8.4.3 PPME Migration States ............................................
8.4.4 PPME Abort, Cleanup, and Recover ......................
8.5 PPME considerations and restrictions .............................
8.6 PPME with Open Replicator migration operation flow
8.6.1 Setup steps .................................................................
8.6.2 Migration steps..........................................................
8.6.3 Cleanup steps ............................................................
8.7 Reference information ........................................................
Chapter 9
188
188
189
191
191
191
191
194
195
196
196
197
199
202
PPME with Open Replicator Migration Example

9.1 Introduction ......................................................................... 204
9.2 PPME Setup steps 1-4 ......................................................... 205

9.3 PPME Setup steps 5-6, powermig setup ......................... 205
9.3.1 Identify source and target pseudo device names. 206
9.3.2 PPME license required ............................................. 207
9.3.3 PPME powermig setup ............................................ 208
9.4 Migration step 10, powermig sync .................................. 210
9.5 Migration step 12, tune migration ................................... 211
9.6 Migration step 13, query status, until SourceSelected 212
9.7 Migration step 18a, powermig selectTarget ............... 214
9.8 Migration step 18b, powermig commit ............................ 215
9.9 Migration step 16, powermig cleanup ............................. 217
9.10 Migration step 19, redeploy source devices storage .... 217
Appendix A
Open Replicator Performance Tuning

A.1 Two goals of Open Replicator tuning .............................
A.2 Resource conflicts...............................................................
A.2.1 I/O resource paths ..................................................
A.2.2 Array I/O conflicts ..................................................
A.3 Limiting Open Replicator resource usage......................
A.3.1 Using a separate management host ......................
A.3.2 Limiting Symmetrix FA director competition .....
A.4 Migration options can impose performance delays .....
A.5 Tuning Open Replicator....................................................
A.5.1 Static configuration limits on Open Replicator
resource use ........................................................................
A.5.2 Dynamic limits on Open Replicator resource
use ........................................................................................
A.6 Monitoring Open Replicator performance.....................
A.6.1 symrcopy query .......................................................
A.6.2 symrcopy list ceiling................................................
A.6.3 symstat with -RepType rcopy................................
A.7 Tuning for applications sensitive to response time ......
Appendix B
223
223
225
225
226
227
230
Troubleshooting
B.1 Solutions Enabler logs........................................................
B.1.1 Cold push example log entries ...............................
B.1.2 Hot pull example log entries ..................................
B.2 Audit Log.............................................................................
B.3 PowerPath Migration Enabler (PPME) logs ...................
B.4 Reactivate Failed Session...................................................
220
220
220
220
221
221
221
222
223
232
232
237
239
241
244
Glossary
Index
10
Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Migration project steps ............................................................................. 25

Open Replicator hot (or live) push ......................................................... 47
Open Replicator cold (or BCV) push...................................................... 49
Open Replicator hot (or live) pull ........................................................... 50
Open Replicator cold (or point-in-time) pull ........................................ 51
Setup steps flowchart................................................................................ 53
Migration steps flowchart ........................................................................ 57
Cleanup steps flowchart........................................................................... 61
Invoking Connectivity Status for Host in a Storage Group ................ 70
Host connectivity status for a CLARiiON storage group. .................. 71
CLARiiON CX3-40f Storage Processor World Wide Port Names...... 71
Connectrix Manager activate zone verification screen ........................ 72
SMC Remote Report menu selection...................................................... 80
SMC Remote Report Remote Ports......................................................... 81
SMC Remote Report Remote LUNs display ......................................... 81
Create Page 3 showing CLARiiON Available Remote Devices ......... 82
Cold push migration and cleanup flowchart ........................................ 86
Host connectivity status for licod194 in Storage Group D194.......... 117
Windows drive L contents .................................................................... 121
Windows Disk Management display of drives L, M, N and O ........ 122
Activate additional zones verification screen excerpt ....................... 126
Disk Management display of target devices additional space ......... 133
Disk Management updated display showing 4 GB partitions ......... 136
Symmetrix hot pull setup, migration, and cleanup flowchart ......... 142
SMC properties for Symmetrix 000190300359 devices 95-98 ............ 143
SMC Front End Paths detail for control target device 95 .................. 144
SMC director 2C port 0 properties showing the port WWN ............ 145
SMC director 15C port 0 properties showing the port WWN .......... 145
SMC Front End Paths detail for remote source device 141 ................ 146
Connectrix Manager activate Symmetrix hot pull zones .................. 148
11
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
12
Disk Management display of remote source drives P, Q, R, and S..

SMC Device Masking menu ..................................................................
SMC add device masking for remote devices 141-144 on FA-8C:0..
SMC device masking success confirmation dialog.............................
SMC add device masking for remote devices 141-144 on FA-9C:0..
SMC Tasks Masking Wizard selection .................................................
Masking Wizard step 1 welcome screen ..............................................
Masking Wizard step 2 create masking view......................................
Masking Wizard step 3 click to create Initiator Group......................
Masking Wizard step 3 Initiator Group creation................................
Masking Wizard step 4 select an existing Port Group.......................
Masking Wizard step 5 click to create a Storage Group ....................
Storage Group creation dialog...............................................................
Masking Wizard step 7 summary .........................................................
Masking Wizard success dialog ............................................................
SMC properties device detail for control target device 95. ...............
SMC Open Replicator Create Copy Session menu.............................
SMC Create Copy Session page 1: Set session parameters ...............
SMC Create Copy Session page 2: select control devices..................
SMC Open Replicator page 3: Select remote devices.........................
SMC Create Copy Session page 4: Select device pairs.......................
SMC Create Copy Session page 5: Set session options and execute
SMC Confirm Open Replicator create execution................................
SMC Create Copy Session success dialog box ....................................
SMC Remote Report menu selection ....................................................
SMC Remote Report Remote Ports tab ................................................
SMC Remote Report Remote Luns display .........................................
SMC Removing device masking for devices 141-144 for FA-8C:0 ...
SMC Removing device masking for devices 141-144 for FA-9C:0 ...
SMC Open Replicator session properties and control menu ............
SMC Open Replicator Activate .............................................................
Open Replicator session properties after activate ..............................
Disk Management display of drives P-S on the target devices ........
SMC Select Open Replicator Set Ceiling Menu ..................................
SMC Open Replicator Set Ceiling .........................................................
SMC Open Replicator session properties Refresh View update ......
SMC Open Replicator session properties showing Copied state .....
Donor Update Off SMC Session Control dialog box..........................
Terminate SMC Session Control dialog box........................................
PPME Operation with pseudo-named devices and Open
Replicator..................................................................................................
PPME Migration states and commands ...............................................
PPME with Open Replicator setup steps flowchart ...........................
149
150
151
151
152
154
155
156
157
159
160
161
162
163
164
165
166
167
167
168
169
170
171
171
172
173
173
175
176
177
178
178
180
181
182
183
184
185
186
190
192
197
76
77
78
79
80
81
82
PPME migration steps flowchart..........................................................

PPME cleanup steps flowchart .............................................................
PPME with Open Replicator setup, migration, and cleanup steps .
Windows Event Viewer with PPME error message selected...........
Event Properties detail for missing PPME license.............................
Windows Event Viewer with PPME error message selected...........
Event Properties detail for missing PPME license.............................
198
202
204
241
242
243
243
13
14
Preface
As part of an effort to improve and enhance the performance and capabilities

of its product line, EMC routinely releases revisions to its hardware and
software. Therefore, some functions described in this guide may not be
supported by all versions of the software or hardware currently in use. For the
most up-to-date information on product features, refer to the product release
notes.
Audience
This TechBook describes best practices for using EMC Open Replicator
for Symmetrix for data migration. Advantages and proper use of EMC
PowerPath Migration Enabler (PPME) together with Open Replicator
are also explained. Open Replicator features used for data mobility
and remote vaulting, but not for data migration, are not covered in this
guide.
The intended audience for this TechBook is storage administrators,
system administrators, and anyone interested in migrating
applications.
Readers of this TechBook are expected to be familiar with:
EMC Symmetrix Logical Volumes (SLVs) including masking
CLARiiON or third-party array LUNs and masking for

heterogeneous migration
SAN zoning
EMC Solutions Enabler SYMCLI and Symmetrix Management

Console (SMC)
This TechBook is divided into nine chapters and two appendices:
15
Preface
16
Chapter 1, Introduction, provides an introduction to the

interfaces and potential deployment of EMC Open Replicator for
Symmetrix together with PowerPath Migration Enabler or alone.
Background information including Open Replicator terminology
and required setup operations are introduced.
Chapter 2, Brief EMC Foundation and Migration Product

Descriptions, provides an introduction to EMC Symmetrix
hardware and software technologies that are used to implement
migration solutions.
Chapter 3, EMC Open Replicator for Symmetrix,defines all Open

Replicator terminology, interfaces and operations. All of the steps
for initiating and conducting Open Replicator operations are
described.
Chapter 4, Cold Push to CLARiiON Setup Example, provides an

example of the steps needed to set up a cold push migration. This
chapter also describes additional setup requirements for hot
operations and multiple methods for verifying that Open
Replicator setup is complete. The examples shown in this chapter
use a Solaris host and SYMCLI.
Chapter 5, Cold Push to CLARiiON Migration Example, provides

an example of the steps needed to initiate, monitor and conclude a
cold push migration. The examples shown in this chapter use a
Solaris host and SYMCLI.
Chapter 6, Hot Pull from CLARiiON Migration Example,

provides an example of the steps needed to initiate, monitor and
conclude a hot pull migration. This chapter also provides an
example of incomplete zoning and masking, revealing some of the
errors that may be encountered while preparing for a hot pull
migration and presents information on how to resolve those errors.
The examples shown in this chapter use a Windows host and
SYMCLI.
Chapter 7, Hot Pull from Symmetrix Migration Example,

conclude a hot pull migration. The examples shown in this chapter
use a Windows host and the Symmetrix Management Console
(SMC).
Chapter 8, PowerPath Migration Enabler (PPME) Overview,

defines all PPME terminology, interfaces and operations. All of the
steps for installing, initiating and conducting PPME Open
Replicator operations are described.
Preface
Chapter 9, PPME with Open Replicator Migration Example,

conclude a PPME with Open Replicator migration session. The
examples shown in this chapter use a Windows host and the
powermig command.
Appendix A, Open Replicator Performance Tuning, consolidates,

expands and elaborates on the performance tuning information
included within the chapters of this TechBook.
Appendix B, Troubleshooting, provides log examples that

correlate with the examples in chapters 4-9, and provides
troubleshooting not covered in the chapter examples.
This TechBook is the second in a series of Data Migration TechBooks.

Readers should reference the first volume, Choosing a Data Migration
Solution for EMC Symmetrix Arrays, that explores the complexity of data
migration and how to select a data migration solution for Symmetrix in
an open systems environment.
For readers who have access to EMC Powerlink, check EMC
Powerlink for new TechBooks in this Data Migration series or visit the
Vervante On Demand Publishing website:
http://Powerlink.EMC.com
and then Home > Support > Technical Documentation and Advisories
> TechBooks
http://www.vervante.com/
17
Preface
Where to get help

Product
information
EMC support, product, and licensing information can be obtained as

follows:
For documentation, release notes, software updates, or for information
about EMC products, licensing, and service, go to the EMC Powerlink
website (registration required) at:
http://Powerlink.EMC.com
Technical support
Related
documentation
For technical support, go to EMC Customer Service on Powerlink. To

open a service request through Powerlink, you must have a valid
support agreement. Please contact your EMC sales representative for
details about obtaining a valid support agreement or to answer any
questions about your account.
Related documents, available on EMC Powerlink, include:
EMC Solutions Enabler Symmetrix Open Replicator CLI Product
Guide
EMC Solutions Enabler Installation Guide
EMC Solutions Enabler Symmetrix Array Management CLI Product
Guide
EMC Solutions Enabler Symmetrix Array Controls CLI Product
Guide
EMC Solutions Enabler Symmetrix SRM CLI Product Guide
EMC Solutions Enabler Symmetrix TimeFinder Family CLI Product
Guide
EMC Solutions Enabler Symmetrix SRDF Family CLI Product Guide
EMC PowerPath Migration Enabler User Guide
Implementing PowerPath Migration Enabler in Open Replicator and
Invista Environments
Migrating Microsoft Cluster Server using EMC Open Replicator for
Symmetrix Technical Note
EMC Symmetrix LUN Expansion and UNIX Logical Volume
Managers Technical Note
EMC Enginuity 5773 Flexible Device Geometry in a Sun Solaris
Environment Technical Note
Choosing a Data Migration Solution for EMC Symmetrix Arrays
TechBook
18
Preface
White paper: New Features in EMC Enginuity 5874 for Symmetrix

Open Systems Environments
EMC Symmetrix Enginuity Release Notes (multiple release levels
available)
EMC Solutions Enabler Version 7.0 Release Notes
EMC Symmetrix Management Console Version 7.0 Release Notes
Storage Provisioning With EMC Symmetrix Auto-provisioning
Groups Technical Note
Typographical
conventions
EMC uses the following type style conventions in this document:

Bold
User actions (what the user, clicks, presses, or selects

Interface elements (button names, dialog box names
Names of keys, commands, programs, scripts, applications, system calls,
processes, utilities, notifications, services, applications, and utilities in text
Italic
Book titles
New terms in text
Emphasis in text
Courier
Courier
bold
User entry
Options in command-line syntax
Courier
italic
Arguments in examples of command-line syntax

Variables in examples of screen or file output
Variables in pathnames
<>
Angle brackets enclose parameter or variable values supplied by the user
[]
Square brackets enclose optional values
Vertical bar indicates alternate selections - the bar means or
{}
Braces indicate content that you must specify (that is, x or y or z)
...
Ellipses indicate nonessential information omitted from the example
Prompts
System output
Filenames
URLs
Syntax when shown in command line or other examples
19
Preface
The author of this TechBook
This TechBook was written by Donald Fried-Tanzer, an employee of

EMC based at headquarters in Hopkinton, Massachusetts. Donald has
over 25 years of experience in client-server applications, fault-tolerant
servers, and storage management software including: provisioning,
remote replication, local replication, migration, configuration and
monitoring.
We'd like to hear from you!
Your feedback on our TechBooks is important to us! We want our books

to be as helpful and relevant as possible, so please feel free to send us
your comments, opinions and thoughts on this or any other TechBook:
TechBooks@emc.com
20
1
Introduction
This chapter provides a brief executive summary of the two migration

products covered in this guide: EMC Open Replicator for Symmetrix
and EMC PowerPath Migration Enabler (PPME). Key terminology
and setup requirements for Open Replicator are introduced. The full set
of migration project steps is depicted identifying the project steps
covered in this book and where to find more information on other
project steps. An abbreviated approach to choosing whether to use
Open Replicator with PPME concludes the chapter. The topics covered
include:
1.1 Introduction ..................................................................................

1.2 Data Migration definition ...........................................................
1.3 EMC Open Replicator for Symmetrix .......................................
1.4 EMC PowerPath Migration Enabler (PPME)...........................
1.5 Migration project steps................................................................
1.6 When to use Open Replicator with PPME ...............................
1.7 Operational interfaces .................................................................
Introduction
22
22
22
24
24
25
27
21
Introduction
1.1 Introduction
EMC Open Replicator for Symmetrix enables the creation of remote
point-in-time copies that can be used for data mobility, remote vaulting,
and migration between EMC Symmetrix V-Max (or
Symmetrix DMX) and qualified storage arrays with full, incremental,
offline (cold), and online (hot) copy capabilities. This TechBook will
focus on the use of Open Replicator for data migration only.
1.2 Data Migration definition

Data Migration can be defined as the one-time movement of data from
a source to a target, where the data will subsequently only be accessed
at the target. The key to this definition is that for any particular piece of
data, this is a one-time movement. This one-time movement
differentiates Data Migration from Replication where applications
continue to access the source data after the target copy is created. Also,
the one-time movement differentiates Data Migration from Data
Mobility where incremental updates to the data would continue to be
applied.
By definition data migration refers to the relocation of data. After a
migration operation, applications that access the data must reference
the data in its new location. Therefore, part of the migration solution is
the methodology used to point applications to the new data location
(also known as application cutover). Few if any applications have been
designed with the ability to continue processing during the application
cutover process. Therefore either an application outage will be
required, or the migration must be transparent to the application.
1.3 EMC Open Replicator for Symmetrix

1.3.1 Terminology: control and remote
Open Replicator can transfer data between Symmetrix arrays
(homogeneous,) or between a Symmetrix V-Max (or Symmetrix DMX)
and another qualified Fibre Channel array (heterogeneous). The
Symmetrix V-Max (or Symmetrix DMX) where Open Replicator runs,
and its devices, are always referred to as the control side of the copy
operation. Other Symmetrix arrays, CLARiiON arrays, or third-party
arrays on the SAN are referred to as the remote array/devices.
22
Introduction
1.3.2 Control FA "host" setup requirements

Open Replicator runs as an application in the Fibre Director (FA) of the
Symmetrix V-Max (or Symmetrix DMX). The Open Replicator software
causes the FA to appear as an open systems host to the remote storage
array. Therefore, no special software is needed in the remote storage
array. However, zoning and LUN masking is needed to access the
remote devices and must be defined (as is the case anytime a host needs
to access devices on a remote storage array). Configuring the required
zoning and LUN masking is the most common area where problems
occur when setting up Open Replicator and will be covered thoroughly
in multiple examples. Additionally, multiple methods for verifying that
the setup is correct will be covered in the examples.
1.3.3 Terminology: push and pull, cold and hot

Open Replicator supports two types of copy operations: push and pull.
A push operation copies data from the control device to the remote
device. A pull operation copies data to the control device from the
remote device. Open Replicator has two modes of operation: cold
(offline) and hot (online). These two modes refer to the state of the
Symmetrix V-Max (or Symmetrix DMX) resident devices (control
devices). The terms online or offline are used to indicate the potential
state of a host application that uses these devices. Only with a hot
operation can an application using Symmetrix V-Max (or Symmetrix
DMX) based storage remain online. For data consistency reasons, the
remote devices must never be written to by any host connected to the
remote array. In cases where the remote device is the source of the Open
Replicator copy operation (a pull operation), it may be permissible for a
remote host to have read-only access to the remote device.
1.3.4 Multipathing with hot setup requirements

Typically a Symmetrix device is visible to a host on more than one I/O
path. This is done to improve both fault tolerance (failover) and
performance (load balancing). Multipathing is accomplished by
configuring the Symmetrix to present Symmetrix Logical Volumes
(SLVs) as being visible to the application host on more than one FA port.
The application host must use some type of multipathed I/O solution
in order to correctly handle the same device being presented on more
than one I/O path. A common multipathing host solution is EMC
PowerPath. The combination of multipathed control devices and hot
Introduction
23
Introduction
Open Replicator operations result in the greater requirement that all FA

directors that present the control devices, must be zoned and LUN
masked as hosts able to access the remote array devices.
1.4 EMC PowerPath Migration Enabler (PPME)

PowerPath Migration Enabler (PPME) is a hybrid migration solution
that provides the ability to perform nondisruptive migrations or
encapsulations while leveraging another underlying technology, such
as Open Replicator, TimeFinder/Clone, Invista or Host Copy. PPME
provides a solution with virtually no impact to host resources by
utilizing array-based or SAN-based replication (except for Host Copy).
PPME benefits data migrations by greatly reducing or eliminating
application disruption caused by the migration, reducing migration
risk, and simplifying migration operations. PowerPath Migration
Enabler can be installed without PowerPath multipathing technology,
but PowerPath multipathing is required for completely nondisruptive
migrations. This TechBook only covers PPME operation with Open
Replicator.
1.5 Migration project steps

Figure 1 summarizes the basic migration flow.
24
Introduction
Business Impact
Analysis
Source Configuration
Discovery
Migration Strategy
and Tool Selection
Detailed Mapping
and Design
Provisioning
Skill Refreshing
Migration Pilot
Migration and
Cutover
Sign-off
ICO-IMG-000440
Figure 1
Migration project steps
This TechBook is focused on operational migration examples, similar to

a Migration Pilot. There is also some inclusion of the Migration and
Cutover step particularly in describing how PowerPath Migration
Enabler (PPME) simplifies this step. The Migration Strategy and Tool
Selection step is where the decision would be made whether to use
Open Replicator alone or together with PPME. The Selection step
requires both the Business Impact Analysis and Source Configuration
Discovery steps to provide necessary input. These first three steps are
covered in the first volume in the Data Migration series of TechBooks,
Choosing a Data Migration Solution for EMC Symmetrix Arrays. The
selection model defined for migration tool selection is conducted here
in an abbreviated manner.
1.6 When to use Open Replicator with PPME

In this case, the starting assumption is that EMC Open Replicator for
Symmetrix has been selected as the main migration tool and the
decision is whether to use it alone or in conjunction with PPME. To
Introduction
25
Introduction
make this determination, follow the iterative six step model shown
below, and provide answers to the highlighted applicable key questions.
How these questions are answered will determine whether Open
Replicator should be used alone, or in conjunction with PPME.
1. Define the reasons for the data migration, clearly noting mandatory
and optional objectives.
Applicable key question: Is this a transformational migration in the
sense of including the permanent addition of migration enablers for
future migrations?
2. Inventory the existing environment and identify storage elements
that must participate with the chosen data migration solution, along
with resources that are available to support the migration itself.
3. Inventory the target environment identifying storage elements that
must participate with the chosen data migration solution, and
resources available to support the migration itself.
4. Identify potential data migration solutions that can successfully
move the data from the existing environment to the target
environment.
Applicable key question: Is PPME and transparent migration
supported in the existing and target environments?
26
Introduction
5. Identify business factors that limit potential data migration

solutions such as budget, human resources, and application outage
and verification requirements.
Applicable key question: How important is avoiding application
interruptions now or in the future, reducing migration risk, and
simplifying migration operations?
6. Compare and evaluate the potential data migration solutions
including the criteria identified in steps 1-5.
The answers provided to the applicable key questions defined in steps 1, 4
and 5 can identify opportunities to realize the advantages of using
PPME together with Open Replicator. PPME can greatly reduce or
eliminate application disruption due to the migration. If this is a key
factor for the current or future migrations, then it is likely that the use of
PPME will be beneficial. However, the ability of PPME to completely
eliminate any migration related interruptions is limited by the presence
of PowerPath 5.x on the migration host, the type of host, and the host's
support for PPME and PowerPath pseudo devices. Lastly, in step 6, the
relative importance of the answer to the applicable key question in step 5
must be evaluated against any offsetting factors such as cost or other
restrictions.
1.7 Operational interfaces

There are three different interfaces available to control EMC Open
Replicator for Symmetrix: the Solutions Enabler Command Line
Interface (CLI), the Symmetrix Management Console (SMC) Graphical
User Interface (GUI), and the PowerPath Migration Enabler (PPME)
CLI. Examples of using all three interfaces are included in this
TechBook. Note that the PPME CLI interface has fewer operational
steps and provides a greater breadth with the inclusion of migration
cutover operations than is available with the Solutions Enabler CLI or
SMC alone.
Introduction
27
Introduction
28
2
Brief EMC Foundation
and Migration Product
Descriptions
This chapter provides brief descriptions of EMC Symmetrix hardware

and software technologies that may play a role in a data migration
using Open Replicator and PPME. The topics covered include:
2.1 Introduction .....................................................................................

2.2 EMC Symmetrix storage arrays and associated software.........
2.3 EMC CLARiiON and associated software ..................................
2.4 EMC SAN products ........................................................................
2.5 EMC Host products ........................................................................
2.6 Consulting and IT Services............................................................
Brief EMC Foundation and Migration Product Descriptions
29
30
32
35
37
39
41
2.1 Introduction
This chapter contributes to the selection model introduced in Chapter 1,
by providing brief introductions of EMC products that will be used
primarily in selection model steps 2-4. Chapter 2 of the Choosing a Data
Migration Solution for EMC Symmetrix Arrays TechBook has a more
complete listing of EMC migration-related products. The subset of
products included in this chapter were chosen because they can be
operationally relevant to using Open Replicator and PPME.
Products are presented in the following groupings: Symmetrix,
CLARiiON, SAN, Host and Services:
30
Symmetrix storage arrays are present in all Open Replicator

migration configurations, because at least one Symmetrix V-Max (or
Symmetrix DMX) storage array must be present as the control array.
Other Symmetrix storage arrays may act as the remote array in Open
Replicator operations. The TimeFinder family of local replication
products may be used to create point-in-time copies for cold
operations. The SRDF family of remote replication products may
provide information about remote Symmetrix arrays and can be
used to perform remote operations. Solutions Enabler, the
Symmetrix Management Console (SMC) and EMC Ionix
ControlCenter Symmetrix Manager are associated management
software for managing the Symmetrix.
CLARiiON storage arrays may act as the remote array in Open

Replicator operations. The SAN Copy product is a CLARiiON
based product with functionality similar to Open Replicator. It is
included with a short discussion of a use case where SAN Copy
might be used instead of Open Replicator. Navisphere
Management Suite is associated management software that can be
used to set-up the CLARiiON to work as a remote array in Open
Replicator operations.
EMC Connectrix products are SAN switches and directors which,

as part of the SAN, contain the zoning that must be properly
defined in order for Open Replicator to work. EMC Connectrix
Manager and EMC Ionix ControlCenter SAN Manager are
associated management software capable of managing and
monitoring zoning. Invista Storage Virtualization runs in the SAN
and is mentioned briefly because PPME can work with Invista as
the underlying replication technology.
The host grouping includes migration-related products that execute

solely on a customer host system, as well as products that provide a
host-executable control interface for array or SAN-based migration
software. PowerPath multipathing can effect the setup
requirements for Open Replicator. PowerPath Migration Enabler
(PPME) also executes on the host. Control interfaces include
Solutions Enabler, Symmetrix Management Console (SMC) and
EMC Ionix ControlCenter.
Services are very often a key component of actual data migrations.

In many cases, a majority of the migration costs are in discovery,
documentation, mapping and design, provisioning, piloting and
qualification. EMC Services are a key method to reduce risk and
ensure the success of data migrations.
31
2.2 EMC Symmetrix storage arrays and associated software

The following sections describe the Symmetrix array: basic architecture,
operating environment, logical volumes, array types used with Open
Replicator, replication and management software.
2.2.1 Basic architecture

Symmetrix is a high-end enterprise storage system with maximum
capacity and the highest performance, consolidating massive amounts
of data and host applications and storage tiers on reliable, cost-effective
networked storage. Symmetrix provides broad connectivity with 4
Gb/s performance, advanced security, high availability, and energy
efficiency in an easy-to-operate storage system.
Symmetrix is an Integrated Cached Disk Array (ICDA). All I/Os are
cached. There are three functional areas:
Shared Global Memory provides cache memory
Front-end directors connect to hosts and service all host I/O

requests to/from cache
Back-end directors stage and destage data between cache and

physical disk drives
The Symmetrix architecture can be compared to a MPP (Massively

Parallel Processing) server with directors working simultaneously
performing all the tasks of the array.
2.2.2 EMC Enginuity Operating Environment

Symmetrix storage arrays run EMC Enginuity, the most mature,
comprehensive, stable, highly available and proven storage operating
environment in the industry. Enginuity is the emulation code, service
processor code and other software used by a Symmetrix to implement
core functionality. Each processor in every director is loaded with
specific emulation code. Enginuity coordinates the independent
director processors to act as one Integrated Cached Disk Array.
Enginuity provides base system functionality and advanced features
like local (TimeFinder) and remote (SRDF) replication, Open Replicator
and other optional software products.
32
2.2.3 Symmetrix Logical Volumes (SLVs)

Symmetrix Logical Volumes (SLVs) are logical abstractions of physical
disk drives that are presented to open system hosts as FBA (Fixed Block
Architecture) devices. EMC and customers configure these devices
using Symmetrix management software. More information about this
software is available in Section 2.2.6.3, Symmetrix management
software, on page 35. Enginuity also provides the capability to map
SLV visibility on specific FA adapters and to limit visibility to specific
Host Bus Adapters (HBAs) on a switched Fibre Channel connection
using device masking (LUN masking). Symmetrix Access Controls can
be used as a further security feature to specifically limit the types of
actions possible on devices from specific hosts.
2.2.4 Symmetrix V-Max and Symmetrix DMX arrays and Open Replicator
The current Symmetrix models are the Symmetrix V-Max SE and
Symmetrix V-Max Series that run Enginuity level 5874. The previous
Symmetrix model family DMX-4 950/1500-4500 can run Enginuity
levels 5772 or 5773. The preceding set of Symmetrix DMX models were
the DMX-3 950/1500-4500 that can run Enginuity levels 5771, 5772 or
5773. The first DMX models were the DMX-1/DMX-2
800/1000/2000/3000 that can run Enginuity levels 5670 or 5671.
Enginuity levels 5671 and 5771 were the first levels to include the EMC
Open Replicator for Symmetrix software. Open Replicator runs as an
application in the Fibre Director (FA) of the Symmetrix V-Max or
Symmetrix DMX. The Open Replicator software causes the FA to
appear as an open systems host to the remote storage array, while it
continues to simultaneously function as the host front-end to the
Symmetrix.
2.2.5 Pre-DMX Symmetrix arrays and Open Replicator

Earlier Symmetrix arrays cannot run Enginuity 5x71 code and therefore
cannot act as the control array for Open Replicator. However, since
previous arrays have front-end Fibre Channel support, they can act as
the remote array for Open Replicator.
33
2.2.6 Other Symmetrix software

2.2.6.1 Symmetrix
Remote Data
Facility (SRDF)
Family
The EMC Symmetrix Remote Data Facility (SRDF) family of replication

software offers various levels of Symmetrix based business
continuance, disaster recovery and data mobility solutions. SRDF
products offer the capability to maintain multiple, host-independent,
mirrored copies of data. The Symmetrix systems can be in the same
room, in different buildings within the same campus, or hundreds to
thousands of kilometers apart. By maintaining copies of data in
different physical locations, SRDF is an effective mechanism for data
center migration. SRDF is designed for Symmetrix to Symmetrix
connections through Fibre Channel, Gigabit Ethernet (GigE), and
ESCON. SRDF has been a part of Enginuity since 1994.
2.2.6.2 TimeFinder
Family
The EMC TimeFinder family of software is the most powerful suite of

local storage replication solutions available. Fully leveraging the
industry-leading high-end Symmetrix hardware architecture, it offers
unmatched deployment flexibility and massive scalability to deliver a
wide range of in-the-system data copying capabilities to meet mixed
service level requirements without operational impact. The
field-proven TimeFinder family is the most widely deployed set of
high-end replication solutions in the industry, with tens of thousands of
installations in the most demanding environments. And, only the
TimeFinder family can provide cross-volume and cross-storage system
consistency, tight integration with industry leading applications, and
simplified usage through automated management. The EMC
TimeFinder family of local replication allows users to nondisruptively
create and manage point-in-time copies of data to allow operational
processes, such as backup, reporting, and application testing to be
performed independent of the source application to maximize service
levels without impacting performance or availability.
TimeFinder/Clone, TimeFinder/Mirror or TimeFinder/Snap can play a
role in Open Replicator data migration in two ways. First, TimeFinder
can be used to create a local point-in-time copy for an Open Replicator
cold push migration to a remote array. Both TimeFinder and Open
Replicator include incremental support, so this point-in-time copy can
be incrementally updated, followed by an incremental Open Replicator
update to quickly reach the new point-in-time. At the end of the
migration, the final TimeFinder and Open Replicator incremental
updates would be conducted after production I/O was stopped to the
production device. Second, if the remote array is a Symmetrix,
TimeFinder can be used to ensure a backup copy of the production data
is available at the remote location in case there is a disruption during an
34
Open Replicator incremental push. This is necessary, because when

Open Replicator performs an incremental update from the production
volumes, the data on the remote devices is not in a consistent state until
the update completes.
Note: Enginuity 5874 no longer supports native TimeFinder/Mirror operations.
However, TimeFinder/Mirror commands are still supported using the
TimeFinder/Clone emulation feature. Therefore, usually there are no changes
in the operational details provided for integrating TimeFinder/Mirror with
Open Replicator. The emulation feature is not supported for virtually
provisioned (thin) devices; in this case new scripts using native
TimeFinderClone commands (symclone) must be used in place of emulated
TimeFinder/Mirror commands (symmir).
2.2.6.3 Symmetrix
management
software
Enginuity and array-based applications like SRDF and TimeFinder

reside in the Symmetrix array and can be managed by host
applications. EMC Solutions Enabler includes a CLI interface for Open
Replicator, SRDF, TimeFinder, device configuration, device mapping,
and device masking. Symmetrix Management Console (SMC) provides
a browser-based GUI interface on top of Solutions Enabler. EMC Ionix
ControlCenter Symmetrix Manager is a central feature of the EMC Ionix
ControlCenter family of products, which provides a unified view for
multiple arrays via a single-pane-of-glass interface. Symmetrix
Manager is used to discover, monitor, and configure Symmetrix storage
from a single console including the ability to automate key system
management, and replication tasks.
2.3 EMC CLARiiON and associated software

CLARiiON arrays combine advanced, easy-to-use midrange networked
storage with robust software capabilities. CLARiiON also provides the
high availability and scalability needed to manage and consolidate
more data. CLARiiON arrays have front-end Fibre Channel support
and can act as the remote array for Open Replicator.
2.3.1 EMC MirrorView

EMC MirrorView provides synchronous and asynchronous remote
replication options across IP and Fibre Channel networks. MirrorView
is used for remote replication between CLARiiON arrays across IP and
Fibre Channel networks and can also be used for data migration.
35
2.3.2 SnapView
SnapView is used to create and manage local point-in-time snapshots
and complete data clones for testing, backup, recovery and migration
operations. When the Open Replicator remote array is a CLARiiON,
SnapView can be used to ensure a backup copy of the production data
is available at the remote location in case there is a disruption during an
Open Replicator incremental push. This is necessary, because when
Open Replicator performs an incremental update from the production
volumes, the data on the remote devices is not in a consistent state until
the update completes.
2.3.3 SAN Copy

SAN Copy copies data between multi-vendor storage systems over the
high-speed SAN infrastructure or WAN in a manner very similar to
EMC Open Replicator for Symmetrix. When using SAN Copy, the
CLARiiON Storage Processor acts as a host to the remote storage array.
Again, no special software is needed in the remote array. Like Open
Replicator, SAN Copy supports incremental copy capabilities for local
array-based sources. SAN Copy would likely be used instead of Open
Replicator when there is a need for incremental support while copying
data from a CLARiiON source to a Symmetrix target.
2.3.4 Navisphere Management Suite

Navisphere provides browser-based discovery, monitoring,
configuration, and reporting on multiple EMC CLARiiON storage
arrays. Navisphere provides management for CLARiiON's advanced
software functionality including: EMC Navisphere Quality of Service
Manager, Navisphere Analyzer, SnapView, SAN Copy, and MirrorView.
Navisphere also provides the mechanism to set the LUN masking
required to make CLARiiON LUNs accessible to the Symmetrix V-Max
(or Symmetrix DMX) FA Open Replicator "host."
36
2.4 EMC SAN products

2.4.1 Connectrix
EMC Connectrix products are advanced directors and switches for
creating an efficient, scalable, high-availability SAN infrastructure.
EMC offers a comprehensive line of Connectrix switches that scale from
8 to 70 ports. Some models provide support for SAN Extension, SAN
Routing, and network-hosted applications such as EMC RecoverPoint
and EMC Invista.
2.4.2 Connectrix Manager

EMC Connectrix Manager provides an interface to the Connectrix
server, centralized management of multiple enterprise directors and
switches, and a high-level view of the enterprise storage network
within the local data centers or at geographically dispersed locations.
Connectrix Manager can be used to configure the required zoning for
the Symmetrix V-Max (or Symmetrix DMX) FA Open Replicator "host"
and the remote storage array.
2.4.3 SAN Manager

EMC Ionix ControlCenter SAN Manager streamlines and centralizes
management of multivendor SANs from one easy-to-use interface. SAN
Manager can be used to configure the required zoning for the
Symmetrix V-Max (or Symmetrix DMX) FA Open Replicator "host" and
the remote storage array.
2.4.4 Invista
Invista Storage Virtualization introduces a hardware abstraction layer
to storage infrastructure, decoupling storage from operating systems.
The storage device that is visible to a host is no longer array specific,
but is a virtual entity that allows the arrays providing the capacity to be
interchanged as business needs dictate, resulting in the ability to move,
expand, or change the storage infrastructure while the application
remains online. Applications can be migrated between storage tiers or
onto refreshed storage systems while reducing or eliminating planned
downtime. Storage Virtualization is a technology enabler for
Information Lifecycle Management (ILM). Storage Virtualization also
provides a common means for storage management across
heterogeneous storage platforms, which simplifies management and
37
reduces operating cost for ongoing data migration needs. PowerPath

Migration Enabler can use Invista as the underlying SAN-based data
migration technology.
38
2.5 EMC Host products

2.5.1 PowerPath Family
The PowerPath family enables EMC host-based solutions including
multipathing, data migration, and host-based encryption.
PowerPath Multipathing automatically tunes the storage area

network (SAN) and selects alternate paths for data if necessary.
Residing on the server, PowerPath Multipathing enhances SAN
performance and application availability. It also integrates multiple
path I/O capabilities, automatic load balancing, and path failover
functions for complete path management.
PowerPath Migration Enabler (PPME) enables other technologies,

like array-based replication, virtualization and Host Copy, to
eliminate application downtime during data migrations or
virtualization implementations. PPME keeps arrays in sync during
Open Replicator data migrations (with minimal impact to host
resources). PPME also provides ease of use for data migrations that
reduce risk and lower costs. In addition, PPME enables seamless
deployment of Invista virtualized environments by encapsulating
(or bringing under the control of) the volumes that will be
virtualized.
2.5.2 Replication Manager

Replication Manager is used to administer multiple EMC replication
technologies and coordinate the entire replication process -- from
discovery and configuration to the operation of multiple disk-based
replicas. Replication Manager can be used to automate the discovery of
storage arrays, applications, replication technologies, and hosts. With
Replication Manager, all information and activities for replicas can be
recorded and catalogued. Replication Manager provides a
wizard-driven interface to create copies of information and includes
support for TimeFinder alone or integrated with SRDF, SnapView alone
or integrated with MirrorView, SAN Copy, RecoverPoint, Celerra
SnapSure, Celerra Replicator, and Invista Clones.
39
2.5.3 EMC Solutions Enabler

An EMC Solutions Enabler installation provides the host with SYMAPI,
CLARAPI, and STORAPI shared libraries for use by Solutions Enabler
applications, and the Symmetrix Command Line Interface (SYMCLI)
for use by Storage Administrators and Systems Engineers. SYMCLI is a
specialized library of UNIX-formatted commands that can be invoked
one at a time. It supports single command line entries and scripts to
map and perform control operations on devices and data objects. It also
can be used to monitor device configuration and status of devices that
make up the storage environment. The target storage environments are
typically Symmetrix, but can be CLARiiON when you have a license
and work with the mapping SRM component.
2.5.4 Symmetrix Management Console (SMC)

As a small and easy-to-implement, browser-based graphical interface,
SMC can be hosted on a small Windows, Linux or Solaris server and is
accessible via a client web browser from nearly anywhere in the world.
Because of this minimal infrastructure, SMC is an ideal graphical
complement to SYMCLI and even to full EMC Ionix ControlCenter for
performing basic device management of a Symmetrix system. SMC is
also an exceptional product for those comfortable with SYMCLI, but
who might be looking for an easy, graphical interface for controlling
their Symmetrix arrays. Like Solutions Enabler, the SMC Server can be
run from any host which has at least one Symmetrix device visible to it.
The SMC Server can also be configured to remotely connect to another
Solutions Enabler host which has at least one Symmetrix device visible
to it. With SMC, users can manage operations from device creation to
virtual provisioning to replication configuration and monitoring. And
as needs change and grow, higher-level, storage resource management
capabilities can easily be added via the EMC Ionix ControlCenter
family. SMC provides a wizard based interface for setting up Open
Replicator migrations including selection of control and remote devices
through available devices windows.
40
2.5.5 EMC Ionix ControlCenter

EMC Ionix ControlCenter simplifies and automates key tasks, such as
discovery, monitoring, reporting, planning, and provisioning for even
the largest, most complex storage environments. EMC Ionix
ControlCenter can manage storage, fabric, and hosts, providing a
unified, single-pane-of-glass view for multiple arrays, switches and
hosts. When performing migrations, its GUI interface is an ideal way to
both provision the target environment and to reconfigure the SAN.
EMC Ionix ControlCenter is a family of products with additionally
licensed features including SAN Manager. Base Ionix ControlCenter
packaging includes both Solutions Enabler and Symmetrix
Management Console. The key Symmetrix Management piece is the
EMC Ionix ControlCenter Symmetrix Manager. CLARiiON, Celerra,
and EMC Centera management tools can be launched from within the
Ionix ControlCenter framework. The EMC Ionix ControlCenter
infrastructure includes one or more dedicated server hosts and agents
that reside on managed hosts. With this infrastructure, Ionix
ControlCenter is able to scale to support very large enterprises.
2.6 Consulting and IT Services

The overall data migration flow diagram introduced in Figure 1 on
page 25, included the following project steps needed to complete a data
migration:
Business Impact Analysis

Source Configuration Discovery
Migration Strategy and Tool Selection
Detailed Mapping and Design
Provisioning
Skill Refreshing
Migration Pilot
Migration and Cutover
From this list of eight steps where only one is directly related to moving
data, it would be correct to conclude that the challenge of a data
migration is not just moving the data. EMC has a plethora of products
available to address just about every type of migration scenario you can
imagine. Choosing a Data Migration Solution for EMC Symmetrix Arrays
contains greater detail. In reviewing actual migrations, it becomes
evident that most migration costs are associated with discovery,
documentation, mapping and design, provisioning, piloting and
41
qualification. Therefore, when planning a migration, it is worth

considering contracting EMC Services for assistance in many of these
areas.
2.6.1 Infrastructure Consulting

2.6.1.1 Backup, recovery, and archive
Address the critical storage challenge of backup and archiving by
analyzing architectural alternatives and devising strategies based on
cost/benefit, capabilities, and design requirements
2.6.1.2 Business continuity
Develop a high availability and disaster recovery strategy to protect
critical business functions through an end-to-end approach, addressing
people, process, and technology.
2.6.1.3 Cloud computing strategy service
Develop the business case, design the optimum architecture, and create
a plan for transforming the IT organization.
2.6.1.4 Compliance
Improve alignment with business policies and industry regulations
while reducing information management costs by providing
sustainable, standardized practices.
2.6.1.5 Data center networking
Increase the operational agility of networked infrastructure.
Customized engagements to help mitigate risk, improve service levels,
and realize cost advantage by mapping technology needs to business
objectives.
2.6.1.6 Green IT
Align infrastructure strategy with business, sustainability, and
technology goals. Reduce an enterprises carbon footprint while
increasing data center efficiency and enhancing overall productivity.
2.6.1.7 Information security
Map business and regulatory requirements to policies, programs, and
strategies. Reduce risk and the cost and complexity of regulatory
compliance.
42
2.6.1.8 Infrastructure consolidation consulting

Streamline data centers to realize cost, energy, and service delivery
benefits.
2.6.1.9 IT service management
Improve the efficiency and effectiveness of IT operations to handle
todays rapidly growing enterprise information. Define service
catalogs, rationalize and refine processes, and redesign IT
organizations.
2.6.1.10 Managed availability services
Provide multi-year business continuity program support to drive
continuing improvements in service levels. EMC consultants
recommend, implement, and manage an ongoing business continuity
program addressing an organizations specific requirements.
2.6.1.11 Private cloud architecture impact advisory service
EMC, Cisco, and VMware provide an organization and its stakeholders
an approach to modeling private cloud to the organizations specific
data center environment.
2.6.1.12 Strategy for remote office infrastructure
Manage risk, cost, and performance across a distributed enterprise.
EMC consultants provide a strategy that encompasses people, process,
and technology. Optimize remote infrastructure to meet demanding
service-level requirements.
2.6.1.13 Virtualization services
Develop a holistic virtualization strategy to increase asset utilization,
improve operational efficiency, raise service quality, speed ROI, and
reduce overall costs.
2.6.2 Implementation
2.6.2.1 Assessment services
Identify possible strategies for your information infrastructure-to meet
your business and technical goals and plans.
2.6.2.2 Business continuity implementation services
Get a complete suite of services for business continuity needs.
43
2.6.2.3 Design and implementation services

Get best practices recommendations and proven methodologies for
hardware and software design and implementation.
2.6.2.4 Disk security services
Secure information and support compliance initiatives.
2.6.2.5 Enterprise content management implementation services
Combine enterprise content management with storage, virtualization,
archiving, and backup and recovery.
2.6.2.6 Migration services
Ensure safe migration of data among EMC storage systems or between
heterogeneous systems.
2.6.2.7 Performance assessments/health check services
Maintain high service levels by identifying factors that affect
storage-platform performance.
44
3
EMC Open Replicator for
Symmetrix
This chapter provides definitions and descriptions of Open Replicator

capabilities. The full set of operational steps available to control any
migration using Open Replicator is described. Specific migration
scenarios using alternate control interfaces show examples of these
steps in subsequent chapters. The topics covered include:
3.1 Introduction ...................................................................................... 46

3.2 Definitions......................................................................................... 46
3.3 Basic Open Replicator migration operation flow........................ 52
3.4 Monitoring, troubleshooting and recovery.................................. 62
3.5 Control interface alternatives ......................................................... 63
3.6 Reference information ..................................................................... 64
45
3.1 Introduction
EMC Open Replicator for Symmetrix enables remote point-in-time
copies to be used for data mobility, remote vaulting, and migration
between EMC Symmetrix V-Max (or Symmetrix DMX) and qualified
storage arrays with full or incremental copy capabilities. Open
Replicator can:
Pull from source volumes on qualified remote arrays to a

Symmetrix V-Max (or Symmetrix DMX) volume
Push any live source Symmetrix V-Max (or Symmetrix DMX)

volume to a target volume on a qualified array with incremental
updates
Perform online data migrations from qualified storage to

Symmetrix V-Max (or Symmetrix DMX) with minimal disruption to
host applications
3.2 Definitions
The Symmetrix V-Max (or Symmetrix DMX), where Open Replicator
runs, and its devices are always referred to as the control side of the
copy operation. Other Symmetrix arrays, CLARiiON arrays, or
third-party arrays on the SAN are always referred to as the remote
array/devices. Open Replicator supports two types of copy operations:
push and pull. A push operation copies data from the control device to
the remote device. A pull operation copies data to the control device from
the remote device. Open Replicator has two modes of operation: cold
(offline) and hot (online). Online and offline refer to the state of the
Symmetrix V-Max (or Symmetrix DMX) resident devices (control
devices). For data consistency reasons, the remote devices must never be
written to by any host connected to the remote array. In cases where the
remote device is the source of the Open Replicator copy operation (a pull
operation), it may be permissible for a remote host to have read-only
access to the remote device.
3.2.1 Hot push

Open Replicator can push data volumes out from a Symmetrix-either in
a live mode (hot) or from a static copy or source volume (cold). For a
live push, no local point-in-time copies of the volumes are required. The
Symmetrix creates logical point-in-time copies without having to
allocate additional disk space, and I/O is permitted against the source
volume during the transfer. If the application attempts a write to a
46
location whose original point-in-time data has not yet been copied to
the remote device, then Copy on First Write (COFW) applies, delaying
the host I/O until the data is safely on the remote. All FA ports for the
control devices must be configured (zoned and LUN masked) to see the
remote devices, so that the FA which encounters the not-yet-copied data
can perform the COFW itself. The initial hot push must be a full copy,
and often includes the option to save differential information. The
saved differential information is used when the hot push is recreated
and activated, pushing only incremental changes since the previous
activate. For data migration, this type of full hot push followed by
repeated incremental pushes would be customary, with the final
incremental push occurring while the application is shut down,
allowing the remote copy to be fully up-to-date. Figure 2 illustrates an
Open Replicator hot (or live) push.
Start: 6:00 a.m.

STD
Target
End: 6:15 a.m.
Image: 6:00 a.m.

ICO-IMG-000434
Figure 2
Open Replicator hot (or live) push
To minimize the performance impact of COFW on production

applications, Open Replicator provides a precopy option. When the
precopy option is used, copying begins immediately at create or
recreate time and runs in the background without taking a point in time
image of the device. COFW is not invoked until the Open Replicator
session is activated, marking the point-in-time that must be preserved.
By copying most of the data before activation, COFW will occur less
frequently because in most cases the data will have been copied to the
remote before the first write.
3.2.2 Cold push

For cold push, the control devices must be presented as "not ready" to
the host. This ensures that there will be no need for the Symmetrix to
preserve the point-in-time or handle COFW. Rather than shutting
47
applications down to obtain a static point-in-time, it is customary to use

TimeFinder/Clone, TimeFinder/Mirror or TimeFinder/Snap to make
an incrementally updateable point-in-time copy of the production data.
Note: Starting with Enginuity 5874, Solutions Enabler 7.0, and SMC 7.0, a
TimeFinder/Snap virtual device (VDEV) can be used as the incrementally
updatable TimeFinder/Snap point-in-time copy of the production volume and
the source of an Open Replicator cold push. Unlike the target devices used to
hold a TimeFinder/Clone or TimeFinder/Mirror copy, which must be equal (or
greater) in size than the corresponding production data devices, VDEVs can be
significantly smaller. (Best practice is for VDEVs to consume less than 30
percent of the amount of space needed to store a full copy of the production
volumes.) The ability to only partially allocate space for the copy of the
production devices is another condition for when cold push might be used in
place of hot push for data migration.
The TimeFinder copy then serves as the control devices for the cold
push. After the Open Replicator cold push completes, the TimeFinder
copy is incrementally updated from the production copy, and the Open
Replicator session is recreated and activated pushing an incremental
update to the remote devices. For data migration, the application would
be shut down before the final TimeFinder incremental establish
(recreate and activate for TimeFinder/Snap), followed by the final
Open Replicator recreate and incremental update to achieve a fully
up-to-date remote copy.
Because there is no need for COFW and no concern for delaying
application writes, multiple remote device copies can be made from a
single control device, and not all FA ports for the control devices must be
configured (zoned and LUN masked) to see the remote devices. For data
mobility purposes, up to 16 remote copies of the local volume can be
made, and those remote copies can all be incrementally updated.
Figure 3 shows an Open Replicator cold (or BCV) push with multiple
targets.
48
SB15
SB13
SB9
SB8
SB11
SB10
SB12
SB14
SB7
SB5
SB3
SB1
SB0
SB2
SB4
SB6
Target
PS0
PS1
PS2
PS3
PS4
SMB0 SMB1
STD
Target
BCV
Target
ICO-IMG-000435
Open Replicator cold (or BCV) push
Figure 3
Cold push would be used in place of hot push for data migration for the
following conditions:
Distance to the remote storage array is greater than 200 km or the

COFW performance penalty is unacceptable to the production
application.
Open Replicator shared use of the bandwidth for all front-end FA

ports which the control devices are mapped to is unacceptable for
performance reasons.
There is sufficient storage available to create a BCV, Clone or VDEV

copy of the production devices.
3.2.3 Hot pull

In pull operations, the Symmetrix volume can be in a live state during
the copy process, which makes either restoring remotely vaulted
volumes or migrating from other storage platforms very fast and
efficient. Remember that for data consistency reasons, remote devices
must always be presented as write disabled to any host connected to
the remote array. Therefore production applications cannot run on the
remote array during the Open Replicator copy. However, with hot pull,
hosts and applications can begin to access the data on the control array
as soon as the session is activated, even before the data copy process
has completed. A process referred to as Copy on First Access (COFA) is
used to ensure the appropriate data is available to a host operation
when it is needed. All FA ports for the control devices must be
49
SB15
SB13
SB11
SB10
SB12
SB14
configured (zoned and LUN masked) to see the remote devices in order
to immediately perform the COFA. Figure 4 illustrates an Open
Replicator hot (or live) pull.
SB9
SB7
SB5
SB3
SB1
SB0
SB2
SB4
SB6
SB8
PiT
Copy
PS0
PS1
PS2
PS3
PS4
SMB0 SMB1
STD
STD
PiT
Copy
ICO-IMG-000436
Figure 4
3.2.3.1 Donor
update
Open Replicator hot (or live) pull
Since production applications are writing to the local (control) copy,

there exists the potential for data loss due to a SAN failure or other
connectivity issue during a hot pull operation. Until the Open
Replicator copy is complete, some of the not yet copied data is only on
the remote while some of the newly written data is only available locally
on the control. The donor update option can be used to protect against
this potential for data loss. When enabled, the donor update feature
enables arrays to propagate (update) writes to the control device back to
the remote device (donor) as data is being pulled from the remote device.
When used, donor update ensures that the data on the local (control)
and remote devices are consistent. As a result, new data written to the
local (control) device will not be lost if an Open Replicator session has to
be restarted before completing. With donor update enabled, data is first
written to the target device, and then propagated to the remote source
device; the host I/O write completes only if both writes are successful.
3.2.4 Cold pull

Of course, a pull can also be performed in cold mode to a static
Symmetrix V-Max (or Symmetrix DMX) volume. Because there is no
special software running on the remote array, there is no mechanism to
implement an incremental pull. Therefore, it is unlikely that cold pull
would be used for a data migration unless it is acceptable to have the
50
SB15
SB13
SB9
SB8
SB11
SB10
SB12
SB14
production applications shut down for the entire time it takes the
migration to complete. Figure 5 illustrates an Open Replicator cold (or
point-in-time) pull.
SB7
SB5
SB3
SB1
SB0
SB2
SB4
SB6
STD
PS0
PS1
PS2
PS3
PS4
SMB0 SMB1
Target
STD
Target
Target
STD
ICO-IMG-000437
Open Replicator cold (or point-in-time) pull
Figure 5
Note: In the unlikely event that a cold pull is chosen to facilitate a given
migration activity, if infrastructure permits, consider running those sessions as
hot pulls to enable more choices to handle any issues that may arise without
compromising downtime objectives.
3.2.5 Open Replicator interaction rules with SRDF

Prior to Enginuity 5874 and Solutions Enabler 7.0, certain interactions
between Open Replicator and SRDF operations were blocked.
The following SRDF operations are no longer blocked when an Open
Replicator control device is in the Created or Recreated state:
SRDF establish or resume when the R2 is an Open Replicator

control device
SRDF restore when the R1 is an Open Replicator control device
The following Open Replicator operation is no longer blocked when the

SRDF link is in the RW (Read Write or Ready) state:
Open Replicator pull operation
51
3.3 Basic Open Replicator migration operation flow

The basic operational flow for a migration using Open Replicator can be
divided into three main phases: setup, migration and cleanup. This
section will define 19 steps across all three phases. The migration and
cleanup phase steps will continue numbering from the phase that
precedes it, so that step numbers will be unique across the complete
operational flow, not just within a phase. Not every step is necessary for
any given migration. Steps are optional based on the particular type of
migration (e.g., cold push vs. hot push, or hot pull). The decision point
for optional steps is indicated by a parenthetical phrase in the
numbered step listing, or a decision diamond in the flowchart
representation. In chapters, 4-9, which detail specific migration
examples, optional steps that do not apply are omitted, leaving gaps in
the numbered step listings and grayed graphics in the flowchart
representations.
3.3.1 Setup steps

There are up to six setup steps. They are:
1. Configure (provision) or identify the target devices.
2. Configure/connect migration SAN zones between remote ports
and Symmetrix V-Max (or Symmetrix DMX) control FA "host"
ports.
3. Configure LUN masking for remote devices to allow access from
Symmetrix V-Max (or Symmetrix DMX) control FA "host" ports.
4. Configure host zoning and device (LUN) masking for target
devices (only for hot pull migrations).
5. Prepare Open Replicator session pairs file (or define pairing in
SMC GUI).
6. Verify completion of setup steps up to creating the Open
Replicator session.
52
Figure 6 illustrates the setup steps as a flowchart.

1. Provision / identify
target devices
2. Zone DMX FA control
to remote array
3. LUN mask remote
devices to DMX FA
Figure 6
3.3.1.1 Step 1 detail
Hot pull?
N
4. Zone and device mask

target devices to host
5. Define OR session
pairs (file)
6. Verify setup
configuration, create
ICO-IMG-000529
Setup steps flowchart
In a migration, the source devices must already exist, but that is not the
case for target devices. Therefore, the target devices of the migration
must be configured (provisioned) if they do not already exist. For Open
Replicator the target devices must be of the same or greater size than
the source devices. (Open Replicator actually will migrate data from a
larger source to a smaller target when the -force_copy option is
specified; this option is unlikely to be used for a straight migration, but
is particularly useful for restoring back to an original smaller source
from a larger target.)
Note: When the Open Replicator source device is a VDEV, the relationship with
the production device does not exist until the symsnap create command is
executed. Exactly when the symsnap create operation is performed can vary,
but it must occur before setup step 6, which includes the symrcopy create
command. A VDEV control device can participate in only one Open Replicator
session. Multi-virtual snap VDEVs are not supported as Open Replicator source
devices.
Because the Symmetrix V-Max (or Symmetrix DMX) FA port will act as
an open systems host to the remote storage array, it is necessary to set up
one or more migration SAN zones for access to the remote ports. This
set-up includes identifying the Symmetrix V-Max (or Symmetrix DMX)
control FA ports World Wide Names (WWNs). For hot operations these
WWNs must all be included in migration zone sets, for cold operations
the WWNs can be selectively included in migration zone sets. It is also
necessary to identify the remote storage array WWN for access to the
remote devices. The actual zone definition operation can be completed
with Connectrix Manager, EMC Ionix ControlCenter SAN Manager, or
native switch zoning tools.
53
Because the Symmetrix V-Max (or Symmetrix DMX) FA "host" is

connected to the remote storage array on a switched fibre port, it is
necessary to perform LUN masking so that the Symmetrix V-Max (or
Symmetrix DMX) FA initiator is defined as having access to the remote
devices. This LUN masking is performed with tools specific to the
remote storage array. Commands for performing this operation for a
remote CLARiiON array are introduced in the next chapter, and device
(LUN) masking for a remote Symmetrix will be shown in subsequent
examples.
For Symmetrix, device masking is the term used for LUN masking (for
Symmetrix V-Max with Enginuity 5874, the Auto-provisioning Groups
feature provides an easier, faster way to provision storage replacing the
old way of configuring device masking). Before a migration is complete
it is always necessary to ensure that the appropriate host applications
are able to access the target devices in place of the original source
devices. For hot pull migrations, this step is performed prior to
initiating the movement of data from the source (remote) to the target
(control).
Open Replicator requires the definition of control-remote pairs; multiple

pairs are grouped into a single file in order to be managed together.
There are three formats for specifying devices in this file: device WWN,
Symmetrix device name or CLARiiON device ID. Device WWN can
always be used for any device. The Symmetrix device name format can
always be used for the control device and in some cases for the remote
device. If the Solutions Enabler database has discovered the remote
Symmetrix or CLARiiON array, then the Symmetrix or CLARiiON
device format can be used for the remote device. When using the SMC
GUI, the process of selecting control and remote devices is made easier
with the ability to selectively filter a list of available devices. The WWN
format can easily be selected with a click, avoiding the need to correctly
enter the lengthy WWN strings.
The final setup step is to use the defined control-remote pair file (or GUI
selection) to create the Open Replicator session. The create operation
validates all necessary control FA access to remote devices and will fail if
the pair definition, zoning or LUN masking is not defined correctly. The
create action can be considered part of the setup phase because it
does not begin migration data movement in most cases (hot push
operations that specify the -precopy option do initiate migration data
movement).
54
Note: In some cases, SCSI reservations for devices under cluster control or the
AIX operating system will prevent the create operation from being successful.
In this case alternate verification options can be used; more information about
these options is available in Section 4.6, Setup step 6, verify completion of
setup steps, on page 75.
Note: The symrcopy create command is described to be the most thorough
test for verifying the completion of the Open Replicator setup phase. The
alternative methods of verifying the completion of the setup phase (without
running the symrcopy create action) are not sufficient when using a VDEV
control device. The specific order of operations requires that the symrcopy
create command is executed before the symsnap activate command in
migration step 7.
55
3.3.2 Migration steps

A single migration will use four to seven of the eight potential
migration steps. Note that step numbering continues at seven to follow
the last setup step. The migrations steps are:
7. Split the BCV or activate the clone or VDEV
(optional for cold push migrations from a BCV, clone or VDEV).
8. Move all resources to a single cluster node, and create the
Open Replicator session
(only needed if the session was not created during setup and not
terminated as part of step 7).
9. Stop the application (only for pull migrations).
10. Activate the Open Replicator session.
11. Restart the application pointing to the target (control) devices,
(only for hot pull migrations).
12. Tune migration to an acceptable level of impact on production
application (optional).
13. Verify Open Replicator copy session is finished.
14. Iteratively apply incremental updates
(customary for push migrations).
a. Use TimeFinder to incrementally update the control devices
(only for cold push).
b. Recreate and activate the Open Replicator session to
incrementally update the remote.
c. Repeat steps 14a-14b until all updates have been processed,
shut down the application before the last update in step 14a,
so there will be no changes generated during the final
incremental push.
15. Verify migration is complete and terminate Open Replicator
session.
Figure 7 on page 57 illustrates the migration steps as a flowchart.
56
Cold push
from BCV, clone
or VDEV?
7. Split the BCV

or activate the clone or VDEV
8. Move resources to single

cluster, create
N
Create not run?
N
Pull?
N
9. Stop the application
10. OR activate
Hot pull?
N
Need tuning?
11. Restart application using

target devices
12. Tune OR to acceptable

impact level
N
13. Verify OR copy
done
Push?
N
Last update?
Y
14c. Stop the application
N
Cold push?
14a. TimeFinder
incremental update
N
15. Verify migration
terminate OR
14b. OR recreate and

activate
Application
still running?
N
Figure 7
ICO-IMG-000530a
Migration steps flowchart
57
3.3.2.1 Steps 7
through 15 detail
Steps 7 through 15 consist of the following:
Step 7, initialize the BCV, clone or VDEV control device with a

point-in-time copy of the production device, is necessary when the
control device is a BCV, clone, or VDEV device. Step 7 must precede
step 8 when the control device is a TimeFinder/Mirror BCV, because
the split operation makes the BCV an independent device.
Note: The symsnap and symrcopy commands needed to support cold push
from a VDEV device must be performed in a specific order. The general rule is
that the parallel symsnap action (create, activate, or recreate) must
precede the same symrcopy operation. The symsnap activate
-not_ready command sets the TimeFinder/Snap point-in-time and must
precede migration step 10. The -not_ready option is used to keep the VDEV
in the Not Ready state, which is required while the Open Replicator session is
present.
Step 8, create the Open Replicator session, is needed if the

create is postponed from the setup phase or if TimeFinder
operations in step 7 require that the Open Replicator session is not
in the created state.
Step 9, stop the applications, is necessary for pull operations

because the remote source data must not be changed once the pull
migration session is activated.
Step 10, activate the Open Replicator session, is the key migration
phase step, setting the point-in-time for the migration copy.
Step 11, restart the application pointing to the target devices is part
of the migration phase only for hot pull migrations; for all other
migrations the restart is completed as part of the cleanup phase.
Step 12, tune the migration, is optional; it is available to adjust the

migration impact on production applications as needed.
Step 13, wait and monitor for completion of the migration copy, is
most likely the step that will take the longest time.
Step 14, iteratively applying incremental updates, is necessary for

push migrations to propagate production application changes to the
target (remote) until production application changes cease when the
applications are stopped.
When using a VDEV control device, step 14a, the TimeFinder
incremental update, cannot activate the recreated TimeFinder/Snap
session before the Open Replicator session is first recreated.
Similarly, the symrcopy activate in step 14b cannot precede the
58
symsnap activate (which again includes the -not_ready

option to keep the VDEV in the Not Ready state). Therefore when
using TimeFinder/Snap the order of operations for steps 14a-14b
must be:
1. symsnap recreate
2. symrcopy recreate
3. symsnap activate -not_ready
4. symrcopy activate
Step 15, terminate the Open Replicator session, is completed once
the migration is verified because data migration is the one-time
movement of data from source to target so the session is no longer
needed. The symrcopy terminate command must precede any
symsnap terminate commands.
59
Tuning Open Replicator Typically there are two conflicting

performance goals for a data migration. First, it is necessary for the
migration to complete within the planned for migration window.
Second, the data migration should not cause unacceptable levels of
performance degradation for production applications. Open Replicator
shares the processing power of the front-end fibre (FA) director and the
bandwidth of the fibre path with the production applications. Open
Replicator provides three alternatives for tuning Open Replicator
performance: the ceiling parameter which limits fibre bandwidth that
can be used by Open Replicator, the pace parameter which defines
delays added between Open Replicator operations, and the nocopy
mode which suspends Open Replicator copy activity.
The primary tuning mechanism is the Open Replicator ceiling
parameter. Ceiling is set to the maximum percentage of the fibre
bandwidth that can be used by Open Replicator. By default this value is
not set, theoretically allowing Open Replicator to use up to 100 percent
of the bandwidth. The secondary tuning mechanism is the pace
parameter. Pace is a value set between 0 and 10 (default 5), which
translates to a position in a table that adds a delay between Open
Replicator I/O transfers. The larger the pace value, the longer the delay.
Another method of tuning is setting the mode to nocopy, which will
effectively stop all Open Replicator I/O except for copy operations
required when in hot mode to preserve the point-in-time (copy on first
write for hot push, and copy on first access for hot pull). This method is
most likely used in special circumstances when it is necessary to limit
nonproduction I/Os as much as possible. It will be necessary to set the
mode back to copy for the copy session to complete the migration.
Ceiling is considered the best tuning mechanism because it delivers
fixed, accurate, repeatable results that can be based on observed and
calculated values. Pace values greater than zero will always add Open
Replicator processing delays, even when Open Replicator I/Os would
not get in the way of production applications. The PPME throttle
mechanism is an alternate interface to the Open Replicator pace
parameter. The pace value is ignored for all participating director/port
combinations where the ceiling value is not NONE, including PPME
Open Replicator sessions.
60
3.3.3 Cleanup steps

Figure 8 illustrates the following cleanup steps in a flowchart:
16. Make the source devices inaccessible to the host
(needed for all but hot pull operations).
17. Make the target devices ready to the host
(needed for all but hot pull operations).
18. Restart applications pointing to the target devices in place of the
original source devices (needed for all but hot pull operations).
19. Redeploy the source devices storage now that the migration is
complete.
Y
Hot pull?
N
16. Make source devices
inaccessible to host
17. Make target devices ready

to host
18. Restart applications using
target devices
19. Redeploy source devices
storage
ICO-IMG-000531
Figure 8
Cleanup steps flowchart
Step 18, restart production applications to reference the target devices,

is the main task in the cleanup phase.
Steps 16 and 17 prepare for this step by removing the source devices in
step 16 and adding the target devices as host visible devices in step 17.
In the case of hot pull steps 16-18 are skipped because the production
applications were restarted using the target devices in the migration
phase.
Note the use of the term target devices which would usually mean the
remote devices in the case of a hot or cold push, or in the unusual case of
using cold pull for a data migration it would mean the control devices.
Step 19, redeploys the source devices storage, which is now free for
new uses.
61
These steps are identified as being in the cleanup phase because Open
Replicator actions ended with the termination of the session in the
migration phase. PowerPath Migration Enabler (PPME) includes
alternate commands to achieve the outcomes of step 11 and steps 15-18
for hot pull operations under PPME control. These alternate commands
provide the PPME advantages of greatly reducing or eliminating
application disruptions due to these steps, reducing migration risk, and
simplifying migration operations.
Note: Chapter 8, PowerPath Migration Enabler (PPME) Overview, introduces
a more comprehensive and reordered description of these alternate cleanup
steps.
3.4 Monitoring, troubleshooting and recovery

Best practices for monitoring, troubleshooting and recovery will be
shown in the examples detailed in the following chapters. The range of
tools available will first be introduced here. When using Open
Replicator the vast majority of problems encountered result from errors
in setting up the initial zoning and LUN masking. This chapter
introduced the Open Replicator create action as an effective tool to
verify complete setup.
Chapter 4, Cold Push to CLARiiON Setup Example, will go into
additional detail for interpreting setup errors reported by create and
alternatives to create for verifying correct setup. Once a migration is
started, there are basic tools for monitoring the copy session progress.
The query action will list the status of the control and remote pairs and
the progress of the copy sessions. The verify action can be used to
determine if an expected status exists, and the interval and count
options can be set up to loop until the desired state is achieved. The
return code from verify operations can be used effectively within a
script to branch based on the status of the copy sessions. Besides 100
percent completion of a copy operation, the other important status to
deal with is a failed copy operation. Recovery from a failed operation is
generally dealt with by simply restarting the copy operation and taking
a new point-in-time. In the case of hot pull, a new point-in-time would
only be valid on the remote, provided the -donor_update option was
used.
Appendix B, Troubleshooting, provides log information that
correlates with the examples presented in Chapters 4 through 9, and an
example of reactivating a failed differential push session.
62
3.5 Control interface alternatives

There are three different interfaces available to control EMC Open
Replicator for Symmetrix: the Solutions Enabler Command Line
Interface (SYMCLI), the Symmetrix Management Console (SMC)
Graphical User Interface (GUI), and the PowerPath Migration Enabler
(PPME) CLI.
3.5.1 Solutions Enabler CLI

The Solutions Enabler Command Line Interface (SYMCLI) supports
EMC Open Replicator for Symmetrix operations with the symrcopy
command. The symsan command, which lists ports visible from a
given director port and LUNs visible behind a given remote port, is
particularly helpful for verifying that zoning and LUN masking has
been correctly configured for Open Replicator operations.
Configuration of devices, mapping, and masking is also supported by
the symconfigure, symmask and symmaskdb commands. Output
available from symdev, sympd, and symcfg commands may also be
helpful in manually verifying key Open Replicator related information.
3.5.2 Symmetrix Management Console GUI

The Symmetrix Management Console (SMC) Graphical User Interface
(GUI) supports EMC Open Replicator for Symmetrix operations with
the Open Replicator create and session control wizards. The create
wizard gets invoked from the control menu for the local Symmetrix
array. This five-page wizard progressively moves the user through the
process of specifying all of the information needed to create an Open
Replicator session:
1. Set session parameters
2. Select control devices
3. Select remote devices
4. Select device pairs
5. Set create options, and execute
If device pairs definitions are available from a previously saved file, the
wizard jumps from page 1 to page 5. Once created, Open Replicator
session control is available from the Control, Replication menu. SMC
also supports Remote Report, which like symsan lists ports visible
from a given director and LUNs visible behind a given remote port.
63
3.5.3 PowerPath Migration Enabler (PPME) CLI

The PowerPath Migration Enabler (PPME) CLI supports EMC Open
Replicator for Symmetrix operations with the powermig command.
Since Open Replicator will be used as the underlying technology for the
migration, setup steps 1-4 are conducted in the same way as listed in
Section 3.3.1, Setup steps, on page 52. The powermig command has
its own setup action to configure the source and target pair devices.
The Open Replicator hot pull operation is then initiated by the
powermig sync command. The rest of the powermig actions are used
to monitor progress until completion of the synchronization, and then
to conduct application cutover to the target devices. These cutover steps
go beyond the scope of the migration data movement steps available in
Solutions Enabler and SMC. Without PPME, cutover steps need to be
conducted in host and application specific ways.
3.6 Reference information

Specific details of the Solutions Enabler Open Replicator commands can
be found in the Solutions Enabler Symmetrix Open Replicator CLI Product
Guide. This TechBook includes all migration-related features available
in Open Replicator at the time of publication; not all of these actions or
options are available in earlier code releases. The EMC Solutions Enabler
Symmetrix Open Replicator CLI Product Guide and the EMC Solutions
Enabler Release Notes provide details about feature availability.
Specific details of the Symmetrix Management Console Open
Replicator screens can be found in the online help within the product.
An example of special considerations for necessary steps dealing with
clustered hosts can be found in the Migrating Microsoft Cluster Server
using EMC Open Replicator for Symmetrix Technical Note.
64
4
Cold Push to CLARiiON
Setup Example
This chapter provides an operational example of the setup phase.

Together with Chapter 5, Cold Push to CLARiiON Migration
Example, a complete example of all the steps needed to execute a cold
push using SYMCLI on a Solaris host is provided. Alternate examples
for verifying successful completion of the setup step is presented. The
topics covered include:
4.1 Introduction ...................................................................................... 66

4.2 Setup step 1, identify target devices.............................................. 66
4.3 Setup step 2, configure migration SAN zones ............................. 68
4.4 Setup step 3, configure migration LUN masking........................ 73
4.5 Setup step 5, prepare Open Replicator session pairs.................. 74
4.6 Setup step 6, verify completion of setup steps ............................ 75
65
4.1 Introduction
This chapter details the setup steps for a cold push to a CLARiiON
using Solutions Enabler SYMCLI on a Solaris host. Because step 4 of the
setup steps introduced in chapter 3 is only completed for hot pull
migrations, it is omitted from the listing of numbered steps below:
1. Configure (provision) or identify the target devices
2. Configure/connect migration SAN zone between remote
devices and Symmetrix V-Max (or Symmetrix DMX) control FA
"host" ports.
Symmetrix V-Max (or Symmetrix DMX) control FA "host" ports.
SMC GUI).
Replicator session.
4.2 Setup step 1, identify target devices

As mentioned in Section 3.3.1.1, Step 1 detail, on page 53, the target
devices of the migration must be configured (provisioned) if they do
not already exist. For Symmetrix arrays, the Solutions Enabler
symconfigure command, SMC's Device Configuration screens or
EMC Ionix ControlCenter Symmetrix Manager can be used to configure
target devices of an equal or greater size than the source devices. For all
remote devices it is necessary to know the device world wide name
(WWN). However, if the remote Symmetrix or CLARiiON device has
been discovered and is in the Solutions Enabler database file, then the
Symmetrix or CLARiiON array ID and device number ("name") can be
used in place of the WWN. Open Replicator will use the array specific
identification to obtain the WWN from the database file. This is
generally easier to use than dealing with lengthy WWN strings.
In order to discover a CLARiiON, the symcfg authorization
command must first be used to associate a CLARiiON storage
processor IP address with a username and password. The discover
operation requires either the -clariion option to discover only
CLARiiON arrays, or the -all option to discover both Symmetrix and
CLARiiON arrays. Once discovered, information about the CLARiiON
devices can be displayed using the -clariion option. For example on
page 67:
66
# symcfg authorization add -hostname nnn.nnn.nnn.nnn -username name -password password

# symcfg discover -all
This operation may take up to a few minutes. Please be patient...
# symcfg list -clariion
C L A R I I O N
Firmware
Version
Num
Disks
ClarID
Model
HK190807410004
CX3_40_F 3.24.40.5.014
15
Num Phys
Devices
4
Num Clar
Devices
10
# symdev list -clariion

Clariion ID: HK190807410004
Device
Device
---- ----------------------------------- ---------------------------------------------Num
Physical Name
Config Cap(MB) WWN
--------------------------------------------------------------------------------------00000
00001
00002
00003
00004
00005
00006
00007
00008
00009
Not Visible
Not Visible
Not Visible
Not Visible
Not Visible
Not Visible
Not Visible
Not Visible
Not Visible
/dev/rdsk/emcpower3c
Raid-5
Raid-5
Raid-5
Raid-5
Raid-5
Raid-5
Raid-5
Raid-5
Raid-5
Raid-5
4096
4096
4096
4096
4096
4096
4096
4096
4096
4096
600601602b401e00148f6936d93bdd11
600601602b401e00158f6936d93bdd11
600601602b401e00168f6936d93bdd11
600601602b401e00178f6936d93bdd11
600601602b401e00188f6936d93bdd11
600601602b401e00198f6936d93bdd11
600601602b401e001a8f6936d93bdd11
600601602b401e001b8f6936d93bdd11
600601602b401e00bae08e938a47dd11
600601602b401e001078c2a48a47dd11
If the remote array is not a CLARiiON or a Symmetrix, or not in the

database, then it is necessary to use the WWN. The Solutions Enabler
syminq command and the similar inq command can be used to
display WWN information for Symmetrix, CLARiiON and third-party
arrays. For example:
# syminq -clariion -cids -wwn
Device
--------------------------------Name
--------------------------------/dev/rdsk/c2t5006016A41E087E6d0s2
/dev/rdsk/c2t5006016241E087E6d0s2
/dev/rdsk/c4t5006016041E087E6d0s2
/dev/rdsk/c4t5006016841E087E6d0s2
/dev/vx/rdmp/emcpower3s2
Device
------------------- --------------------------------Num
Array ID
WWN
------------------- --------------------------------0009 HK190807410004 600601602B401E001078C2A48A47DD11
0009 HK190807410004 600601602B401E001078C2A48A47DD11
0009 HK190807410004 600601602B401E001078C2A48A47DD11
0009 HK190807410004 600601602B401E001078C2A48A47DD11
0009 HK190807410004 600601602B401E001078C2A48A47DD11
0009 HK190807410004 600601602B401E001078C2A48A47DD11
67
4.3 Setup step 2, configure migration SAN zones

As the Symmetrix V-Max (or Symmetrix DMX) FA port will act as an
open systems host to the remote storage array, it is necessary to set up
one or more migration SAN zones for access to the remote devices.
Therefore, both the local (control) director WWN(s) and the remote
front-end WWN(s) must be determined.
4.3.1 Determining Control Director WWN

The control is always a Symmetrix device, so Solutions Enabler, SMC or
EMC Ionix ControlCenter can be used. First it must be determined on
which directors the control devices are visible. The Solutions Enabler
symdev list -multiport command is one of the easiest ways to
obtain this information. In the following example, the four control
devices: 80, 81, 82 and 83, are all mapped to both director 2C port 0 and
director 15C port 0.
# symdev -sid 359 list -range 80:83 -multiport
Symmetrix ID: 000190300359
M U L T I - P O R T
D E V I C E S
Device Name
Directors
Device
-------------------------------- ------------- --------------------------------------Cap
Physical
Sym SA :P DA :IT Config
Attribute
Sts
(MB)
-------------------------------- ------------- ---------------------------------------
Not Visible
Not Visible
0080
01A:C6
- 02C:0
- 15C:0
-
2-Way BCV Mir

-
N/Asst'd
-
RW
-
4096
-
Not Visible
Not Visible
0081
16B:C6
- 02C:0
- 15C:0
-
2-Way BCV Mir

-
N/Asst'd
-
RW
-
4096
-
Not Visible
Not Visible
0082
16A:DC
- 02C:0
- 15C:0
-
2-Way BCV Mir

-
N/Asst'd
-
RW
-
4096
-
Not Visible
Not Visible
0083
15B:C7
- 02C:0
- 15C:0
-
2-Way BCV Mir

-
N/Asst'd
-
RW
-
4096
-
Note that the -multiport option will only list devices with more than
one path. If there is only a single path, then symdev list should be
used without the -multiport option.
68
The FA director port world wide port name (WWPN or WWN) can be
displayed using the symcfg list command. For example:
# symcfg -sid 359 list -fa 2c -p 0
S Y M M E T R I X
Dir
FA-2C
Port
0
F I B R E
D I R E C T O R S
WWN
VCM
Enabled
Volume Set
Addressing
Pnt to Pnt
5006048AD5F031C1
Yes
No
Yes
# symcfg -sid 359 list -fa 15c -p 0

S Y M M E T R I X
Dir
FA-15C
Port
0
F I B R E
D I R E C T O R S
WWN
VCM
Enabled
Volume Set
Addressing
Pnt to Pnt
5006048AD5F031CE
Yes
No
Yes
4.3.2 Determining Remote Storage Array WWN(s)

The remote storage array can be a Symmetrix, a CLARiiON or a
third-party array. For a remote Symmetrix array the procedure for
determining the WWPN for the remote FA director is the same as the
one used to obtain the WWPN for the local director on a Symmetrix.
For a remote CLARiiON array, the Navisphere GUI can be used to
determine the Storage Processor(SP) WWPNs. CLARiiON LUN
masking is accomplished using storage groups, where all devices in the
same Storage Group are defined to be accessible to all hosts in the
69
Storage Group. Figure 9 illustrates right-clicking on the host in the

Storage Group containing the remote devices (LUNs) in order to select
the Connectivity Status for that host.
ICO-IMG-000532
Figure 9
Invoking Connectivity Status for Host in a Storage Group
Figure 10 on page 71 shows that four paths between the CLARiiON and
host LICOD229 can be used to access LUNs 4, 5, 6 and 7. However, the
CLARiiON LUNs are owned by only one SP at one time. For fault
tolerance, a LUN can trespass over to the other SP; therefore it is
necessary to define paths for the currently passive SP as well.
70
ICO-IMG-000533
Figure 10
Host connectivity status for a CLARiiON storage group.
Figure 11 shows all of the Front End Port WWPNs, with ports 0 and 2
highlighted for both SPA and SPB.
ICO-IMG-000534
Figure 11
CLARiiON CX3-40f Storage Processor World Wide Port Names
For a remote third-party array, it is necessary to use tools specific to the

array to determine the WWPNs to use in the zoning.
71
4.3.3 Selective or all Symmetrix FA Zoning

For cold operations it is not necessary to zone all possible paths. This
allows the user to limit migration movement to selective paths. For hot
operations it is required that all Symmetrix FA ports that are mapped
by the control devices be zoned and LUN masked to "see" the remote
devices.
4.3.4 Example configuration of migration SAN zones

In this example, only a single active path and the minimum zoning
necessary for a cold operation is illustrated. Two paths must be
configured for this case, since the remote is a CLARiiON storage array;
the second path is needed to handle the condition of the remote LUN
trespassing from one SP to the other SP. Figure 12 shows an excerpt of
the Connectrix Manager Zoning verification screen with the single path
and standby path zones defined.
ICO-IMG-000535
Figure 12
72
Connectrix Manager activate zone verification screen
4.4 Setup step 3, configure migration LUN masking

4.4.1 Create CLARiiON storage group
Because the Symmetrix V-Max (or Symmetrix DMX) FA "host" is
connected to the remote storage array on a switched fibre port, it is
necessary to perform LUN masking to grant the Symmetrix V-Max (or
Symmetrix DMX) FA initiator access to the remote devices. This LUN
masking is performed with tools specific to the remote storage array.
Here, an example of Storage Group based LUN masking for the
CLARiiON using navicli is presented.
The default location of Navisphere executables on UNIX operating
systems is /opt/Navisphere/bin. The network hostname for the
CLARiiON SPA IP address is Clar0031_SPA. First, the Storage
Group OR_Symm359 is created by executing a command that looks
something like this:
# cd /opt/Navisphere/bin
# ./navicli -h Clar0031_SPA storagegroup -create -gname OR_Symm359
4.4.2 Register host and add devices to CLARiiON storage group

Next, the Symmetrix FA "host" is manually registered for both the SPB
port 0 and SPA port 0 in the storage group. Then the four remote devices
are added to the storage group. For each CLARiiON LUN device
number (-alu), the LUN number presented to the host (-hlu) is
defined.
# ./navicli -h Clar0031_SPA storagegroup -setpath -gname
5:F0:31:C1:50:06:04:8A:D5:F0:31:C1 -sp b -spport 0 -host
serialnumber array
# ./navicli -h Clar0031_SPA storagegroup -setpath -gname
5:F0:31:C1:50:06:04:8A:D5:F0:31:C1 -sp a -spport 0 -host
serialnumber array
# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname
OR_Symm359 -hbauid 50:06:04:8A:D

Sym0359 -failovermode 1 -o -unit
OR_Symm359 -hbauid 50:06:04:8A:D
Sym0359 -failovermode 1 -o -unit
OR_Symm359
OR_Symm359
OR_Symm359
OR_Symm359
-alu
-alu
-alu
-alu
04
05
06
07
-hlu
-hlu
-hlu
-hlu
00
01
02
03
73
4.5 Setup step 5, prepare Open Replicator session pairs

Open Replicator requires the definition of control-remote pairs. Multiple
pairs grouped into a single file can be managed together by Open
Replicator. The control device is identified in the first (leftmost) column
and the remote device is identified in the second (rightmost) column.
The array ID must be fully specified and is separated from the
device/LUN name (number) by a colon. Since the CLARiiON was
discovered into the SYMAPI database file (Section 4.2, Setup step 1,
identify target devices, on page 66), the clardev= format can be used
for the remote devices in the file:
# cat cold_orpairs
symdev=000190300359:0080
symdev=000190300359:0081
symdev=000190300359:0082
symdev=000190300359:0083
#
74
clardev=HK190807410004:00004
clardev=HK190807410004:00005
clardev=HK190807410004:00006
clardev=HK190807410004:00007
4.6 Setup step 6, verify completion of setup steps

4.6.1 Create action is a thorough verification step
The most thorough test for verifying the completion of the setup steps
is to create the Open Replicator session. The create operation
verifies all necessary control FA access to the remote devices and will
fail if the pair definition, zoning or LUN masking is not correctly
defined. Create does not begin the migration itself, except in the case
when the -precopy option is specified for hot push operations. In
some cases, SCSI reservations for devices under cluster control will
prevent the create operation from being successful. In these cases
alternate verification options, presented next, can be used in place of
the create.
Note: When the Open Replicator source device is a VDEV, the relationship with
the production device does not exist until the symsnap create command is
executed. Exactly when the symsnap create operation is performed can vary,
but it must occur before setup step 6, which includes the symrcopy create
command.
4.6.2 Verify zoning with symsan -sanports

Solutions Enabler 6.4 with Enginuity 5772 introduced the symsan
command, which was designed explicitly for verifying the correct Open
Replicator zoning and masking. The zone
OR_Symm0359_2C0_Clar0031_SPB_0 created in the Section 4.3.4,
Example configuration of migration SAN zones, on page 72 included
the WWN for Symmetrix FA director 2C port 0, and the WWN for
CLARiiON SP B port 0. The zone
OR_Symm0359_2C0_Clar0031_SPA_0 included the same Symmetrix
FA WWN with the CLARiiON SP A port 0, in case of LUN trespass
from SP B to SP A. The symsan -sanports command lists the WWNs
that are zoned together with the specified Open Replicator FA port. The
Remote Port WWN 5006016841E087E6 is the SP B port 0 WWN. The
Remote Port WWN 5006016041E087E6 is the SP A port 0 WWN. The
symsan output also identifies the array as a CLARiiON, including the
array ID and also the number of LUNs visible behind each WWN. A
greater than zero Num LUNs value indicates the number of LUNs that
are successfully LUN masked. Since four LUNs were expected this
could be interpreted as successful remote LUN masking. For example:
# symsan -sid 359 list -sanports -dir 2c -p 0
75
Flags
DIR:P
I
Vendor
----- ----- ------------02C:0
.
EMC CLARiiON
02C:0
.
EMC CLARiiON
Num
Array
LUNs Remote Port WWN
---------------- ---- ------------------------------HK190807410004
4 5006016841E087E6
HK190807410004
4 5006016041E087E6
Legend:
Flags: (I)ncomplete : X = record is incomplete, . = record is complete.
76
4.6.3 Verify LUN masking with symsan -sanluns

In order to be certain that the correct LUNs are masked, the
symsan -sanluns command can be used to list the LUN WWNs
behind the Remote Port WWN. In the output produced by this
command, the Dev Num (Device Number) column indicates the
CLARiiON device number. Additionally each record can be checked for
the correct device Capacity.
# symsan -sid 359 list -sanluns -wwn 5006016841E087E6 -dir 2c -p 0
Symmetrix ID:
Remote Port WWN:
DIR:P
----02C:0
02C:0
02C:0
02C:0
ST
A
T
E
-RW
RW
RW
RW
000190300359
5006016841E087E6
Flags
Block Capacity
LUN
ICRTHS Size
(MB)
Num
------- ----- ----------- ----......
512
4096
0
......
512
4096
1
......
512
4096
2
......
512
4096
3
Legend:
Flags: (I)ncomplete
(C)ontroller
(R)eserved
(T)ype
t(H)in
(S)ymmetrix
:
:
:
:
:
:
X
X
X
A
X
X
=
=
=
=
=
=
Dev
Num
----0004
0005
0006
0007
LUN
WWN
-------------------------------600601602B401E00188F6936D93BDD11
600601602B401E00198F6936D93BDD11
600601602B401E001A8F6936D93BDD11
600601602B401E001B8F6936D93BDD11
record is incomplete, . = record is complete.

record is controller, . = record is not controller.
record is reserved, . = record is not reserved.
AS400, F = FBA, C = CKD, . = Unknown
record is a thin dev, . = record is not a thin dev.
Symmetrix device, . = not Symmetrix device
Note: Beginning with Solutions Enabler 7.0, the symsan command added two
flags to indicate thin device and Symmetrix device. A thin device is not eligible
to be a source device for Open Replicator. Open Replicator pull support for
iSeries requires the remote device to be on a Symmetrix array.
77
4.6.4 Verify zoning with symmask list logins

If the Solutions Enabler version is less than 6.4.2 or the Symmetrix
Enginuity level is less than 5772.83, the symsan command is not
available. In this case, the symmask list logins command can be
used to determine if the zoning was successful. At the time of activating
the zone including the OR FA port "host," all participants in the zone
should log on to the SAN fabric. The display below shows WWN
Identifiers On Fabric, but not Logged In with the standard
CLARiiON prefix 500601 (Logged In will change to Yes after an Open
Replicator activate action). The full WWN match the WWN for SPA
port 0 and SP B port 0. For example:
# symmask -sid 359 list logins -dir 2c -p 0
Symmetrix ID
: 000190300359
Director Identification : FA-2C

Director Port
: 0
Identifier
---------------10000000c97111fc
5006016041e087e6
5006016841e087e6
210000e08b927df4
Type
----Fibre
Fibre
Fibre
Fibre
User-generated
Node Name
Port Name
--------------------------------10000000c97111fc 10000000c97111fc
NULL
NULL
NULL
NULL
210000e08b927df4 210000e08b927df4
FCID
-----6b0900
6167ef
6177ef
610613
Logged
In
-----Yes
No
No
Yes
On
Fabric
-----Yes
Yes
Yes
Yes
One important caveat about using the list logins command is that
the reported state is not necessarily current. The key is the first
appearance of the WWN. However once on fabric, the information
remains on the list logins output regardless of whether the WWN is
currently On Fabric. For Symmetrix V-Max, symaccess list
logins wouldbe used in place of symmask.
78
4.6.5 Verify all with symrcopy create

Unless working in a special case dealing with device reservations (e.g.,
windows clustering) or not wanting to begin a hot push which includes
the -precopy option, it is wise to fully test the setup by creating the
Open Replicator session.
Note: When the Open Replicator source device is a VDEV, the specific order of
operations requires that the symrcopy create command is executed before
the symsnap activate command in migration step 7. The symsnap
create operation creates the relationship with the production device and
must be executed before the symrcopy create command.
Using the cold_orpairs file from Section 4.5, Setup step 5, prepare
Open Replicator session pairs, on page 74 the cold push is created as
follows:
# symrcopy -file cold_orpairs -push -cold create
'Create' operation execution is in progress for the device list
in device file 'cold_orpairs'. Please wait...
The device is not in a valid Ready status. Operation cannot proceed
As mentioned when first defining Section 3.2.2, Cold push, on page

47, cold operations require the control devices to be in the Not Ready
state. This can be verified as follows:
# cat cold_controldevs
80
81
82
83
# symdev -sid 359 -file cold_controldevs not_ready
Execute a 'Not Ready' operation for devices in file 'cold_controldevs' (y/[n]) ? y
'Not Ready' operation succeeded for devices in file 'cold_controldevs'.
# symrcopy -file cold_orpairs -push -cold create
Execute 'Create' operation for the 4 specified devices
in device file 'cold_orpairs' (y/[n]) ? y
'Create' operation successfully executed for the device list
in device file 'cold_orpairs'.
#
The successful execution of the create operation confirms that all

necessary zoning and LUN masking is correctly in place.
79
4.6.6 SMC Remote Report

The Symmetrix Management Console provides a GUI equivalent to
symsan. Figure 13 illustrates invoking the Remote Report menu from
an initial right click of the control Symmetrix array, and choosing
ReplicationOpen ReplicatorRemote Report.
ICO-IMG-000536
Figure 13
80
SMC Remote Report menu selection
Remote Report has two tabs. Figure 14 illustrates the Remote Ports tab
showing information similar to the symsan -sanports display for
director 2C port 0.
ICO-IMG-000537
Figure 14
SMC Remote Report Remote Ports
Clicking on the Remote Luns tab and selecting director 2C

automatically selects the first WWN displayed in the Remote Ports
display. Figure 15 illustrates the Remote Luns tab display:
ICO-IMG-000538
Figure 15
SMC Remote Report Remote LUNs display
81
Additionally, the GUI selection of remote devices populates the

available list with the successfully mapped remote devices. Figure 16
illustrates page 3 of the Create Copy Session wizard where the available
remote devices are populated from the Remote Report information.
ICO-IMG-000539
Figure 16
82
Create Page 3 showing CLARiiON Available Remote Devices
5
Cold Push to CLARiiON
Migration Example
This chapter details the migration and cleanup phases for a cold push
migration example using Solutions Enabler SYMCLI on a Solaris host.
The setup phase steps were already covered in Chapter 4, Cold Push
to CLARiiON Setup Example. The topics covered include:
5.1 Introduction ...................................................................................... 84

5.2 Migration step 7, BCV split............................................................. 87
5.3 Migration step 8, symrcopy create ................................................ 92
5.4 Migration step 10, symrcopy activate ........................................... 96
5.5 Migration step 12, symrcopy set ceiling ....................................... 97
5.6 Migration step 13, symrcopy query and verify ........................... 99
5.7 Migration step 14, iterative symrcopy recreate ......................... 100
5.8 Migration step 15, verify migration and symrcopy terminate 104
5.9 Cleanup step 16, make source devices host inaccessible ......... 106
5.10 Cleanup step 17, make target devices ready to host............... 107
5.11 Cleanup step 18, restart applications using targets ................ 108
5.12 Cleanup step 19, redeploy the source devices storage .......... 110
83
5.1 Introduction
This chapter details the migration and cleanup phases for a cold push
migration example using Solutions Enabler SYMCLI on a Solaris host.
The five setup steps required for the cold push were covered in
Chapter 4, Cold Push to CLARiiON Setup Example. This chapter
contains detailed examples of the seven migration steps introduced in
Section 3.3.2, Migration steps, on page 56 that are applicable for a
cold push (steps 9 and 11 only completed for pull migrations are
omitted):
7. Split the BCV or activate the clone or VDEV.
8. Open Replicator session create.
12. Tune migration to acceptable level of impact on production
application.
14. Iteratively apply incremental updates.
a. Use TimeFinder to incrementally update the control devices
(only for cold push).
b. Recreate and activate the Open Replicator session to
incrementally update the remote.
c. Repeat steps 14a-14b until all updates have been processed,
shut down the application before the last update in step 14a
to eliminate changes during the final incremental push.
15. Terminate Open Replicator session.
Also briefly covered will be the four applicable cleanup steps:
16. Make the source devices inaccessible to the host.
17. Make the target devices ready to the host.
18. Restart the application pointing to the target devices in place of
the original source devices.
complete.
84
Figure 17 on page 86 illustrates the cold push migration and cleanup

steps in a flowchart. The paths from decision diamonds which is not
taken and omitted steps are grayed to show they are not conducted for
this cold push example. The step 14 detail, which includes three
substeps (a-c) and related decision diamonds, shows all paths and steps
without graying, because each path and step is performed at least once.
85
Cold push
from BCV, clone
or VDEV?
7. Split the BCV


cluster, create
N
Create not run?
N
Pull?
N
10. OR activate
Hot pull?
N
Need tuning?

target devices

impact level
N
13. Verify OR copy
done
Push?
N
Last update?
Y
14c. Stop the application
N
Cold push?
14a. TimeFinder
incremental update
N
terminate OR
Hot pull?
14b. OR recreate and

activate
Y
N
16. Make source devices
inaccessible
Application
still running?
17. Make target devices ready

to host
target devices
storage
Figure 17
86
Cold push migration and cleanup flowchart
ICO-IMG-000540a
5.2 Migration step 7, BCV split

5.2.1 Device Group creation
For a cold push, it is common to use a TimeFinder/Mirror BCV,
TimeFinder/Clone BCV or target device, or TimeFinder/Snap VDEV as
the control device; this example will use a TimeFinder/Mirror BCV
device. For this example the application uses the file system at mount
point /cphome, a VxVM logical volume made up of 4 Symmetrix
devices: A0 - A3.
# mount
. . .
/cphome on /dev/vx/dsk/cpvg/cplv read/write/setuid/devices/delaylog/largefiles/i
oerror=mwdisable/dev=48c80e8 on Mon Jun 30 17:39:47 2008
. . .
The mount command showed /cphome as a VxVM logical volume

cplv, which is part of the volume group cpvg.
# vxprint -g cpvg -ht
DG NAME
NCONFIG
ST NAME
STATE
DM NAME
DEVICE
RV NAME
RLINK_CNT
RL NAME
RVG
CO NAME
CACHEVOL
VT NAME
NVOLUME
V NAME
RVG/VSET/CO
PL NAME
VOLUME
SD NAME
PLEX
SV NAME
PLEX
SC NAME
PLEX
DC NAME
PARENTVOL
SP NAME
SNAPVOL
NLOG
DM_CNT
TYPE
KSTATE
KSTATE
KSTATE
KSTATE
KSTATE
KSTATE
DISK
VOLNAME
CACHE
LOGVOL
DCO
MINORS
GROUP-ID
SPARE_CNT
PRIVLEN PUBLEN
STATE
PRIMARY
STATE
REM_HOST
STATE
STATE
STATE
LENGTH
STATE
LENGTH
DISKOFFS LENGTH
NVOLLAYR LENGTH
DISKOFFS LENGTH
dg cpvg
default
default
33000
1214852481.33.licod229
dm
dm
dm
dm
cpvgd0
cpvgd1
cpvgd2
cpvgd3
emcpower380s2
emcpower381s2
emcpower382s2
emcpower383s2
2048
2048
2048
2048
8382336
8382336
8382336
8382336
v
pl
sd
sd
sd
sd
cplv
cplv-01
cpvgd0-01
cpvgd1-01
cpvgd2-01
cpvgd3-01
cplv
cplv-01
cplv-01
cplv-01
cplv-01
ACTIVE
ACTIVE
0
0
0
0
33529344
33529344
8382336
8382336
8382336
8382336
SELECT
CONCAT
0
8382336
16764672
25147008
auto
auto
auto
auto
ENABLED
ENABLED
cpvgd0
cpvgd1
cpvgd2
cpvgd3
APPVOL_CNT
STATE
DATAVOLS SRL
REM_DG
REM_RLNK
READPOL
LAYOUT
[COL/]OFF
[COL/]OFF
[COL/]OFF
PREFPLEX
NCOL/WID
DEVICE
AM/NM
DEVICE
UTYPE
MODE
MODE
MODE
MODE
fsgen
RW
emcpower380 ENA
emcpower381 ENA
emcpower382 ENA
emcpower383 ENA
The vxprint command for cpvg showed that the four devices that
make up the volume group cpvg use pseudo device names
emcpower380s2 - emcpower383s2.
87
# sympd list -sid 359 -powerpath

P O W E R P A T H
D E V I C E S
Device Name
Directors
Device
------------------------------------- ------------------------------------------------Cap
Physical
Attribute
Sts
(MB)
------------------------------------- ------------ -----------------------------------. . .
00A0
02A:C9 2-Way Mir
Grp'd
RW
4096
- 15C:0
- /dev/rdsk/c4t5006048AD5F031C1d144s2 - 02C:0
- /dev/rdsk/c2t5006048AD5F031CEd144s2 - 15C:0
- /dev/vx/rdmp/emcpower381s2
00A1
15B:DA 2-Way Mir
- 15C:0
- -
Grp'd
-
RW
-
4096
-
00A2
15A:C4 2-Way Mir
- 15C:0
- -
Grp'd
-
RW
-
4096
-
00A3
02B:DD 2-Way Mir
- 15C:0
- . . .
#
Grp'd
-
RW
-
4096
-
The sympd list command output shows that Symmetrix logical

volumes A0 - A3 correspond to pseudo device names emcpower380s2
- emcpower383s2. The example below: creates the device group
cpgroup and populates it with the STD application devices A0 - A3.
Since, TimeFinder/Mirror BCVs will be used as the source devices for
Open Replicator, BCV devices 80 - 83 are associated with the device
group.
# symdg create cpgroup
# symld -g cpgroup addall -sid 359 -range a0:a3
# symbcv -g cpgroup associateall -range 80:83
If TimeFinder/Clone was being used, a BCV could be used in the same

way or target devices (TGT) could be added to the group with the
following command:
symld -g cpgroup add dev NN -tgt
If TimeFinder/Snap was being used, a VDEV would be added to the
group with the following command:
symld -g cpgroup add dev NN -vdev
88
5.2.2 Initial TimeFinder/Mirror establish

Migration step 7 is to split the BCV. Since the initial state of the BCV is
Never Established, it is necessary to first synchronize the BCV with
the STD. Before the BCV can be used in a full establish operation, the
Open Replicator session created earlier as part of verifying completion
of the setup phase must be terminated. Depending on the Open
Replicator state, Solutions Enabler will block TimeFinder/Mirror
operations on Open Replicator control devices to ensure that the
contents are not changed in the middle of Open Replicator operations.
Here is an example of Solutions Enabler blocking the
TimeFinder/Mirror operation:
# symmir -g cpgroup establish -full -opt
Execute 'Full Establish' operation for device group
'cpgroup' (y/[n]) ? y
'Full Establish' operation execution is in progress for
device group 'cpgroup'. Please wait...
A specified device is involved in a Remote Copy session and cannot be modified
#
The simplest rule is that the Open Replicator state must be Copied (in
nondata migration situations, the Restored state without donor
update enabled is also valid). Terminating the session will also avoid
any operational conflicts, and is appropriate in this case because the
BCV control device needs to have the correct data before the first Open
Replicator copy session. Here is an example of first terminating the
Open Replicator session, and then seeing the TimeFinder/Mirror
operation work without being blocked:
# symrcopy -file cold_orpairs terminate
Execute 'Terminate' operation for the 4 specified devices
'Terminate' operation execution is in progress for the device list
'Terminate' operation successfully executed for the device list
# symmir -g cpgroup establish -full -opt
Execute 'Full Establish' operation for device group
'Full Establish' operation execution is in progress for
'Full Establish' operation successfully initiated for device group 'cpgroup'.
#
89
5.2.3 TimeFinder/Mirror split

Before the BCV devices can be split, the synchronization must be
complete, and the verify action using the interval option(-i) is an
easy way to wait for synchronization to complete. From the
synchronized state the split action is permitted. The split action
has multiple options for specifying a consistent split. In this case the
vxfs mountpoint specified will be frozen just before the instant split is
performed and thawed as soon as the foreground split completes. The
-vxfs option can only be used when running on the production host;
when using a control host the -consistent option can be used
instead. For this example and with other cold pushes using a BCV or
clone, consistency is obtained using TimeFinder rather than using
similar consistency options with the symrcopy activate action. For
example:
# symmir -g cpgroup verify -synched -i 30
Not All devices in the group 'cpgroup' are in 'Synchronized' state.
Not All devices in the group 'cpgroup' are in 'Synchronized' state.
All devices in the group 'cpgroup' are in 'Synchronized' state.
# symmir -g cpgroup split -instant -vxfs /cphome
Execute 'Split' operation for device group
'Split' operation execution is in progress for
Freezing 1 filesystem(s)......................................Done.
Thawing 1 filesystem(s).......................................Done.
'Split' operation successfully executed for device group
'cpgroup'.
#
Note: It would actually be better to use the -not_ready option on the split
action to put the Open Replicator source device in the Not Ready state as
required for a cold push. This option was left out in this example to show how
to correctly overcome its omission in Cold control devices must be Not
Ready, on page 92.
90
If TimeFinder/Clone was being used, the activate can be issued

immediately after the create without waiting, however for performance
reasons, it is better to verify that the precopy cycle is completed:
symclone -g cpgroup verify -precopy -cycled
symclone -g cpgroup activate -vxfs /cphome -not_ready
If TimeFinder/Snap was being used, the activate can be issued
immediately after the create without waiting. When using a VDEV, use
of the -not_ready option for this command is required, as the VDEV
must remain in the Not Ready state while the Open Replicator session
is present:
symsnap -g cpgroup activate -vxfs /cphome -not_ready
91
5.3 Migration step 8, symrcopy create

5.3.1 Cold control devices must be Not Ready
The first attempt at executing the create action will fail, because the
TimeFinder/Mirror split operation leaves the BCV devices in the
Ready state, and Open Replicator control devices in a cold session must
be in the Not Ready state. For example, here is a create attempt and
the corresponding error message:
# symrcopy -file cold_orpairs create -push -cold -differential -name cold_push -copy
The device is not in a valid Ready status. Operation cannot proceed
#
An alternate way to control this group of devices, besides the list within
a file used in Section 4.6.5, Verify all with symrcopy create, on page
79, is to use the device group created for the TimeFinder operations.
The -bcv option will cause the not_ready action to only be applied to
the BCV devices associated with the device group (the production
devices A0-A3 will not be affected). For example:
# symld -g cpgroup -bcv not_ready
Execute a 'Not Ready' Device operation for all devices
in device group 'cpgroup' (y/[n]) ? y
'Not Ready' Device operation successfully completed for the device group.
#
92
5.3.2 Create action options

Now that the devices are Not Ready, the repeated create action will
succeed. Here is an example of a successful create:
# symrcopy -file cold_orpairs create -push -cold -differential -name cold_push -copy
The create action used in this example has a number of important

options set:
The -file cold_orpairs option defines the control and remote

device pairs.
The -push and -cold options make this copy session a cold push.
The -differential option directs Open Replicator to keep track

of changes to the control devices, providing the ability to push
incremental updates to the remote.
The -name cold_push option defines a session name for all the
pairs defined in the cold_orpairs file, providing an alternate
method of specifying which pairs are addressed by the symrcopy
command.
The -copy option indicates that upon activate, a background

sequential copy from the control to the remote will begin.
93
5.3.3 Open Replication query display

The query (or verify) actions can be used to show the copy session in
the Created state. Note the use of the named session cold_push to
refer to the control/remote pairs of interest. The CD value for the RI
flags indicate the display of the remote device using the CLARiiON ID
and device name rather than the LUN WWN. Additionally the CDSHU
flag settings indicate the use of -copy, -differential, -push, and
-cold options for this copy session.
# symrcopy -session cold_push query
Session Name
: cold_push
Control Device
---------------------------Protected
SID:symdev
Tracks
------------------ --------000190300359:0083
65535
000190300359:0082
65535
000190300359:0081
65535
000190300359:0080
65535
Total
Track(s)
MB(s)
Remote Device
Flags
Status
Done
----------------------- ----- -------------- ---Identification
-------------------HK190807410004:0007
HK190807410004:0006
HK190807410004:0005
HK190807410004:0004
RI
-CD
CD
CD
CD
CDSHU
----XXX..
XXX..
XXX..
XXX..
CTL <=> REM

(%)
-------------- ---Created
N/A
Created
N/A
Created
N/A
Created
N/A
--------262140
16383.8
Legend:
R: (Remote Device Vendor Identification)
S = Symmetrix, C = Clariion, . = Unknown.
I:
(Remote Device Specification Identifier)

D = Device Name, W = LUN WWN, World Wide Name.
Flags:
(C): X =
. =
(D): X =
. =
(S): X =
. =
(H): X =
. =
(U): X =
. =
(*): The
The background copy setting is active for this pair.

The background copy setting is not active for this pair.
The session is a differential copy session.
The session is not a differential copy session.
The session is pushing data to the remote device(s).
The session is pulling data from the remote device(s).
The session is a hot copy session.
The session is a cold copy session.
The session has donor update enabled.
The session does not have donor update enabled.
failed session can be reactivated.
94
5.3.4 Query -detail option

Specifying the -detail option with the query action reveals the
default setting of five (5) for the pace parameter. It will also display the
Modified Tracks, for incremental updates, but this value is only
calculated if the Solutions Enabler options file parameter
SYMAPI_RCOPY_GET_MODIFIED_TRACKS is set to TRUE. The default
setting is FALSE in order to optimize performance. The session name is
also listed in this display:
# symrcopy -session cold_push query -detail
Session Name
: cold_push
Control Device
-----------------------------------Protected Modified
SID:symdev
Tracks
Tracks
----------------- --------- -------000190300359:0083
65535
0
000190300359:0082
65535
0
000190300359:0081
65535
0
000190300359:0080
65535
0
. . .
Remote Device
Flags Status
Done Pace
Name
----------------------- ----- -------- ---- ---- --------Identification
-------------------HK190807410004:0007
HK190807410004:0006
HK190807410004:0005
HK190807410004:0004
RI
-CD
CD
CD
CD
CDSHU
----XXX..
XXX..
XXX..
XXX..
CTL<=>REM (%)
-------- ---- ---- --------Created
N/A
5 cold_push
Created
N/A
5 cold_push
Created
N/A
5 cold_push
Created
N/A
5 cold_push
95
5.4 Migration step 10, symrcopy activate

Activate sets the point-in-time for the push of data from the control
to the remote. In this case of cold push, there is no need for consistency
options, as these were already used as part of the TimeFinder/Mirror
split operation. Notice that after the activate, the Status has
changed to CopyinProg(ress) and the number of Protected
Tracks for each device is reduced from the starting value of 65535 as
tracks are copied to the remote.
# symrcopy -session_name cold_push activate
Execute 'Activate' operation for the 4 specified devices
with session name 'cold_push' (y/[n]) ? y
'Activate' operation execution is in progress for the device list
with session name 'cold_push'. Please wait...
'Activate' operation successfully executed for the device list
with session name 'cold_push'.
Session Name
: cold_push
Control Device
---------------------------Protected
SID:symdev
Tracks
------------------ --------000190300359:0083
65365
000190300359:0082
65366
000190300359:0081
65368
000190300359:0080
65370
Total
Track(s)
MB(s)
. . .
96
Remote Device
Flags
Status
Done
----------------------- ----- -------------- ---Identification
-------------------HK190807410004:0007
HK190807410004:0006
HK190807410004:0005
HK190807410004:0004
RI
-CD
CD
CD
CD
CDSHU
----XXX..
XXX..
XXX..
XXX..
CTL <=> REM

(%)
-------------- ---CopyInProg
0
CopyInProg
0
CopyInProg
0
CopyInProg
0
--------261469
16341.8
5.5 Migration step 12, symrcopy set ceiling

As shown earlier with the query -detail, by default the pace
parameter is set to five, which significantly slows copy operations by
inserting delays.
As a best practice, the ceiling value should be used which more
effectively limits the Open Replicator use of resources shared with the
production applications. In this case, the ceiling value is set to 30%
reserving 70% of the FA bandwidth for production applications. The
pace value is ignored for all participating director/port combinations
where the ceiling value is not NONE.
Unlike the pace parameter which is session based, the ceiling value is
director/port based and affects all sessions that use those ports. Since
both ports 2C:0 and 15C:0 are used by the production devices and could
be used by Open Replicator, the ceiling is set on both ports by executing
the following commands:
# symrcopy set ceiling 30 -sid 359 -dir 2c -port 0
Execute 'Set Ceiling' operation (y/[n]) ? y
'Set Ceiling' operation execution is in progress
'Set Ceiling' operation successfully executed
# symrcopy set ceiling 30 -sid 359 -dir 15c -port 0
Execute 'Set Ceiling' operation (y/[n]) ? y
'Set Ceiling' operation execution is in progress
'Set Ceiling' operation successfully executed
#
97
In actual practice, it would be better to set the ceiling prior to any Open
Replicator I/O taking place (i.e., before the activate). The setting of
performance parameters is shown at this point in the operational
sequence because it is possible that active tuning might be altered at
various points of the migration versus setting a single value that is
always in place.
Just as the detailed query can be used to show the pace setting, there is
a list ceiling operation that can be used to display the ceiling
values, and that also shows the current Open Replicator use of
bandwidth. In the following example, only director port 2C:0 shows
bandwidth use, because director port 15C:0 was not zoned and LUN
masked for this cold push.
# symrcopy -sid 359 list ceiling
Symmetrix Remote Copy Bandwidth Ceiling
Dir:P
----01C:0
01C:1
02C:0
02C:1
15C:0
15C:1
16C:0
16C:1
Max
(MB)
---150
150
150
150
150
150
150
150
Set
(%)
---NONE
NONE
30
NONE
30
NONE
NONE
NONE
Actual
(MB)
-----0
0
14
0
0
0
0
0
98
5.6 Migration step 13, symrcopy query and verify

This step consists mostly of waiting until the Open Replicator copy
completes for the point-in-time of the activate. The query action
will report the Status, the decreasing number of Protected
Tracks, and the increasing Done percent. The normal status sequence
goes from CopyInProg to Copied. Using the verify action allows
scripts to wait for a particular status. The use of the count (-c) option
limits how long to wait and the program can check for unsuccessful
return status indicating an exit from the loop due to the count being
reached rather than reaching the waited for status.
In the following example, the interval (-i) of 300 seconds (5 minutes)
with a count of 36 means waiting for three hours (180 minutes). In the
example, the Copied state was reached within the three-hour time limit
for checking. It is important to specify a realistic time limit based on the
amount of data to be copied and the bandwidth or other tuning
limitations that will affect how long the copy could take to complete.
Session Name
: cold_push
Control Device
---------------------------Protected
SID:symdev
Tracks
------------------ --------000190300359:0083
60460
000190300359:0082
60466
000190300359:0081
60480
000190300359:0080
60483
Remote Device
Flags
Status
Done
----------------------- ----- -------------- ---Identification
-------------------HK190807410004:0007
HK190807410004:0006
HK190807410004:0005
HK190807410004:0004
RI
-CD
CD
CD
CD
CDSHU
----XXX..
XXX..
XXX..
XXX..
CTL <=> REM

(%)
-------------- ---CopyInProg
7
CopyInProg
7
CopyInProg
7
CopyInProg
7
# symrcopy -session cold_push verify -copyinprog

All session(s) with name 'cold_push' are in 'CopyInProg' state.
# symrcopy -session cold_push verify -copied -i 300 -c 36
None of the session(s) with name 'cold_push' are in 'Copied' state.
None of the session(s) with name 'cold_push' are in 'Copied' state.

. . .
All session(s) with name 'cold_push' are in 'Copied' state.

#
99
5.7 Migration step 14, iterative symrcopy recreate

5.7.1 Incrementally update control devices from production devices
Because a cold push from a BCV is based on a point-in-time that does
not include all of the application writes to the production device, it
must be incrementally updated with the writes since the activation of
the last cold push. This is done using a combination of
TimeFinder/Mirror commands to incrementally update the BCV and
Open Replicator commands to incrementally update the remote devices.
To avoid Solutions Enabler blocks on TimeFinder interactions with
Open Replicator, the simple rule to follow is that the Open Replicator
session should be in the Copied state when attempting TimeFinder
operations. In Migration step 13, symrcopy query and verify, the last
status verified was the Copied state. In the following example,
TimeFinder/Mirror is used to incrementally establish (update) the
BCV, verify the BCVs are synchronized with the production devices,
and then consistently split the BCVs. Also included here is the
-not_ready option to keep the BCVs in the Not Ready state as
required for Open Replicator cold operations.
# symmir -g cpgroup establish
Execute 'Incremental Establish' operation for device group
'Incremental Establish' operation execution is in progress for
'Incremental Establish' operation successfully initiated for device group
'cpgroup'.
# symmir -g cpgroup verify -synched -i 30
# symmir -g cpgroup split -instant -vxfs /cphome -not_ready
Execute 'Split' operation for device group
Freezing 1 filesystem(s)......................................Done.
Thawing 1 filesystem(s).......................................Done.
'Split' operation successfully executed for device group 'cpgroup'.
#
100
If TimeFinder/Clone had been used in place of TimeFinder/Mirror, the

sequence would have been to consistently establish the TGT
(combine incremental recreate and activate) with an updated
point-in-time of the production devices using the -not_ready option.
It is not required to wait until the TGTs have finished copying the
point-in-time and reached the Copied state with the verify action.
If TimeFinder/Snap had been used in place of TimeFinder/Mirror, the
TimeFinder incremental update, cannot activate the recreated
TimeFinder/Snap session before the Open Replicator session is first
recreated. Similarly, the symrcopy activate cannot precede the
symsnap activate (which again includes the -not_ready option to
keep the VDEV in the Not Ready state). Therefore when using
TimeFinder/Snap the order of operations for iterative update must be:
1.
2.
3.
4.
symsnap recreate
symrcopy recreate
symsnap activate -not_ready
symrcopy activate
5.7.2 Incrementally update remote devices from control devices

First, use Open Replicator recreate to set up an incremental update
using the Symmetrix Differential Data Facility (SDDF) information
maintained as a result of the -differential option on the original
create. Second, use activate to set a new point-in-time and start the
movement of data. Third, wait for completion of the incremental data
movement. The Copied state indicates finishing the incremental
update and is required for using TimeFinder in the next iteration of
incremental updates.
# symrcopy -session cold_push recreate
Execute 'Recreate' operation for the 4 specified devices
'Recreate' operation execution is in progress for the device list
'Recreate' operation successfully executed for the device list
# symrcopy -session cold_push activate
101

#
5.7.3 Stop applications and final incremental update

In order to end the iterative loop of incremental updates, it is necessary
to stop production applications from writing to the production devices.
The file system is displayed here as a simplistic method for comparing
with the migrated copy in Section 5.8, Migration step 15, verify
migration and symrcopy terminate, on page 104. In this example, the
change directory (cd) away from the mounted filesystem emulates
stopping the application, and is required before the filesystem can be
unmounted. Once the filesystem is unmounted, the volume group can
be deported from VxVM, and the disks can be removed from VxVM.
# cd /cphome
# ls -l
total 8
-rw-r--r-1 root
root
-rw-r--r-1 root
root
-rw-r--r-1 root
root
-rw-r--r-1 root
root
drwxr-xr-x
2 root
root
-rw------1 root
root
# cd /
# umount /cphome
# vxdg deport cpvg
# vxdisk rm emcpower380s2
#
102
12
216
12
216
96
0
Jun
Jun
Jun
Jun
Jun
Jun
30
30
30
30
30
30
17:43
17:43
17:43
17:43
17:14
17:40
cold_controldevs
cold_orpairs
controldevs
hot_orpairs
lost+found
sh2256.1
The last incremental synchronization is repeated almost identically as

in Section 5.7.1, Incrementally update control devices from production
devices, on page 100 and Section 5.7.2, Incrementally update remote
devices from control devices, on page 101. The count value on the
verify checks is lower since there is less data to update. The
TimeFinder/Mirror split operation cannot freeze the file system since
it is now unknown (and effectively frozen) due to the umount and
deport operations performed earlier.
In the following example, the -noprompt option is used to skip the
control action verification queries. Since there are no new writes, after
completion of this last incremental update the Open Replicator remote
devices are fully synchronized with the production devices.
# symmir -g cpgroup establish -noprompt
'Incremental Establish' operation execution is in progress for
'Incremental Establish' operation successfully initiated for device group
'cpgroup'.
# symmir -g cpgroup verify -synched -i 30 -c 6
# symmir -g cpgroup split -not_ready -noprompt
'Split' operation successfully executed for device group 'cpgroup'.
# symrcopy -session cold_push recreate -noprompt
'Recreate' operation execution is in progress for the device list
'Recreate' operation successfully executed for the device list
# symrcopy -session cold_push activate -noprompt
#
103
5.8 Migration step 15, verify migration and symrcopy terminate

Before terminating the Open Replication copy sessions (and losing all
differential information), it is best to conduct some type of application
specific verification that the remote devices are a complete and valid
replacement for the original production devices. This will be shown as a
comparison with the list directory of the production devices later in
Section 5.11, Cleanup step 18, restart applications using targets, on
page 108. In a true production data migration, best practice would
include bringing the application up in a test mode using the migrated
data to verify that the application will work without fail. The depth and
breadth of this type of verification will vary depending on the business
requirements for each data migration. Once verified, the Open
Replicator sessions are no longer needed and can be terminated as
follows:
# symrcopy -session cold_push terminate
No sessions were found with name: cold_push
#
Note: When using TimeFinder/Snap, the symrcopy terminate command
must precede any symsnap terminate commands.
5.8.1 Hot push differences from cold push

This TechBook does not include an entire example of hot push, because
the operations are very similar to those just shown for cold push. There
is a difference in the required setup, because hot operations require all
capable ports to be zoned and LUN masked. This difference will be
covered in detail in Chapter 6, Hot Pull from CLARiiON Migration
Example. A partial hot push example is included in Section B.4,
Reactivate Failed Session, on page 244.
104
There are two key operational differences between a hot and cold push.
First, with a hot push there is no need for BCV or Clone devices; the
activate takes a point-in-time on the actual production devices,
using Copy on First Write (COFW) to handle production write I/Os to
data not yet copied to the remote devices. Second the control devices can
be in the Ready state since COFW is in effect.
Operationally, this means there is no need for the TimeFinder
operations or the not_ready device control operations. The Open
Replicator activate action will likely use the -consistent option to
ensure a consistent point-in-time, since this is no longer done separately
using TimeFinder/Mirror or TimeFinder/Clone. Additionally, the
create and recreate actions will often use the -precopy option to
minimize the COFW performance penalty on the production devices. In
order to get the most benefit from precopy, best practice would include
a time delay between the create/recreate and activate actions.
The command symrcopy verify -precopy -cycled can be used
to wait for the completion of one sequential pass through all blocks of
the production devices before activating the session.
105
5.9 Cleanup step 16, make source devices host inaccessible

By definition, these cleanup steps occur after all Open Replicator steps
are complete. These host and application specific examples are included
briefly here in order to contrast these manual steps with more
functional actions that are included as part of PowerPath Migration
Enabler (PPME) (which is discussed in Chapter 9, PPME with Open
Replicator Migration Example).
Although the original source devices were made unavailable to the host
in Section 5.7.3, Stop applications and final incremental update, on
page 102, this change was not permanent and it is possible that upon a
reboot these devices may be accessed again. If the source device mount
definitions are not removed from /etc/vfstab, upon reboot the
source devices would automatically be remounted. If an unplanned
disk rescan or reboot takes place without making these devices
inaccessible, then it is possible that the host may mistakenly use these
devices again in place of the migrated target devices upon recognizing
the private region information on the disks. Best practice would avoid
this problem and also preserve the production volumes unchanged
until it was certain that there was no need to revert to the data stored on
the original source devices. The following steps can be used to unmask
the source devices from the host to ensure that the host will not
inadvertently use these devices.
# symmaskdb -sid 359 list assignment -dev a0:a3
Symmetrix ID : 000190300359
Device
-----00A0
00A1
00A2
00A3
Identifier
---------------210000e08b927df4
210000e08b925cf5
210000e08b927df4
210000e08b925cf5
210000e08b927df4
210000e08b925cf5
210000e08b927df4
210000e08b925cf5
Type
----FIBRE
FIBRE
FIBRE
FIBRE
FIBRE
FIBRE
FIBRE
FIBRE
Dir:P
---------------FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
# symmask -sid 359 -wwn 210000e08b927df4 remove -g cpgroup -std -dir 2c -p 0

# symmask -sid 359 -wwn 210000e08b925cf5 remove -g cpgroup -std -dir 15c -p 0
# symmask -sid 359 refresh -noprompt
Symmetrix FA directors updated with contents of SymMask Database 000190300359
#
# symmaskdb -sid 359 list assignment -dev a0:a3
No device masking database records could be found for the specified input para
meters
#
106
5.10 Cleanup step 17, make target devices ready to host

The target devices are presented to the host in this case, simply by
removing the remote CLARiiON devices from the OR_Symm359 storage
group and adding the devices to the existing D229 storage group for the
local Solaris host. In other cases it might be necessary to add new
zoning or create a new storage group or use other array specific LUN
masking techniques. For example:
#
#
#
#
#
#
#
#
./navicli
./navicli
./navicli
./navicli
./navicli
./navicli
./navicli
./navicli
-h Clar0031_SPA storagegroup -removehlu -gname OR_Symm359 -hlu 00 -o

-h Clar0031_SPA storagegroup -addhlu -gname D229 -alu 04 -hlu 01
The SYMAPI database is updated by rediscovering the CLARiiON and

the list of CLARiiON devices now shows host pathnames for devices
4-7.
# symcfg discover -clariion
# symdev list -clariion
Device
----- ----------------------Num
Physical Name
----- -----------------------
Device
---------------------------------------------Config Cap(MB) WWN
----------------------------------------------
00000
00001
00002
00003
00004
00005
00006
00007
00008
00009
RAID-5
RAID-5
RAID-5
RAID-5
RAID-5
RAID-5
RAID-5
RAID-5
RAID-5
RAID-5
Not Visible
Not Visible
Not Visible
Not Visible
Not Visible
4096
4096
4096
4096
4096
4096
4096
4096
4096
4096
600601602B401E00148F6936D93BDD11
600601602B401E00158F6936D93BDD11
600601602B401E00168F6936D93BDD11
600601602B401E00178F6936D93BDD11
600601602B401E00188F6936D93BDD11
600601602B401E00198F6936D93BDD11
600601602B401E001A8F6936D93BDD11
600601602B401E001B8F6936D93BDD11
600601602B401E00BAE08E938A47DD11
600601602B401E001078C2A48A47DD11
107
5.11 Cleanup step 18, restart applications using targets

The migrated information on the target devices includes the VxVM
private region with the disk group information which can be imported.
# vxdctl enable
# vxdisk list
DEVICE
TYPE
DISK
GROUP
c0t0d0s2
auto:none
c0t1d0s2
auto:none
emcpower0s2 auto:cdsdisk
. . .
# vxdg import cpvg
# vxvol -g cpvg start cplv
# mount -F vxfs /dev/vx/dsk/cpvg/cplv /cphome
#
STATUS
online invalid
online invalid
online
online
online
online
online
Although the remote devices on the CLARiiON and the control devices
on the Symmetrix V-Max (or Symmetrix DMX) were both configured as
4 GB devices, the actual size of the devices differs slightly with the
CLARiiON devices being slightly larger. To get the host operating
system to recognize and use the additional space, it is necessary to
execute operating system and application specific steps.
On Solaris hosts, a logical units disk label contains information about
the vendor, product, geometry, and slices. PowerPath Migration
Enabler (PPME) includes a utility called powerformat that can be
used independent of PPME to safely update disk-label information,
preserve partition definitions and data, and make newly available disk
capacity available for use.
108
For this example, vxdisk resize is used as the first step to get the OS
and LVM to recognize the new space on the LUNs. The before and after
output from vxprint shows the change in PUBLEN from 8382336 to
8385792 blocks for an increase of 3456 blocks for each disk media (DM)
record:
# df -k
Filesystem
kbytes
used
. . .
/dev/vx/dsk/cpvg/cplv
16764672
21198
# vxprint -g cpvg -ht
DG NAME
NCONFIG
NLOG
ST NAME
STATE
DM_CNT
DM NAME
DEVICE
TYPE
RV NAME
RLINK_CNT
KSTATE
RL NAME
RVG
KSTATE
CO NAME
CACHEVOL
KSTATE
VT NAME
NVOLUME
KSTATE
V NAME
RVG/VSET/CO KSTATE
PL NAME
VOLUME
KSTATE
SD NAME
PLEX
DISK
SV NAME
PLEX
VOLNAME
SC NAME
PLEX
CACHE
DC NAME
PARENTVOL
LOGVOL
SP NAME
SNAPVOL
DCO
dg cpvg
default
default
avail capacity
15697013
1%
MINORS
GROUP-ID
SPARE_CNT
PRIVLEN PUBLEN
STATE
PRIMARY
STATE
REM_HOST
STATE
STATE
STATE
LENGTH
STATE
LENGTH
DISKOFFS LENGTH
NVOLLAYR LENGTH
DISKOFFS LENGTH
33000
Mounted on
/cphome
APPVOL_CNT
STATE
DATAVOLS SRL
REM_DG
REM_RLNK
READPOL
LAYOUT
[COL/]OFF
[COL/]OFF
[COL/]OFF
PREFPLEX
NCOL/WID
DEVICE
AM/NM
DEVICE
1214852481.33.licod229
dm cpvgd0
emcpower2s2 auto
2048
dm cpvgd1
emcpower1s2 auto
2048
dm cpvgd2
emcpower0s2 auto
2048
dm cpvgd3
emcpower4s2 auto
2048
v cplv
ENABLED ACTIVE
pl cplv-01
cplv
ENABLED ACTIVE
sd cpvgd0-01
cplv-01
cpvgd0
0
sd cpvgd1-01
cplv-01
cpvgd1
0
sd cpvgd2-01
cplv-01
cpvgd2
0
sd cpvgd3-01
cplv-01
cpvgd3
0
# vxdisk -g cpvg resize emcpower2s2
# vxprint -htq
Disk group: cpvg
8382336
8382336
8382336
8382336
33529344
33529344
8382336
8382336
8382336
8382336
dg cpvg
default
default
33000
1214852481.33.licod229
dm
dm
dm
dm
emcpower2s2
emcpower1s2
emcpower0s2
emcpower4s2
auto
auto
auto
auto
2048
2048
2048
2048
8385792
8385792
8385792
8385792
cplv
cplv-01
ENABLED ACTIVE
ENABLED ACTIVE
cpvgd0
0
cpvgd0
cpvgd1
cpvgd2
cpvgd3
v cplv
pl cplv-01
sd cpvgd0-01
. . .
UTYPE
MODE
MODE
MODE
MODE
SELECT
CONCAT
0
8382336
16764672
25147008
fsgen
RW
emcpower2 ENA
emcpower1 ENA
emcpower0 ENA
emcpower4 ENA
33529344 SELECT
33529344 CONCAT
8382336 0
fsgen
RW
emcpower2 ENA
109
Next the vxresize command is used to expand the volume and file
system. The expansion size specified is +13824 (4 x 3456) blocks. The
vxprint output shows the cplv logical volume length increasing by
13824 blocks from 33529344 to 33543168. Similarly, the filesystem
capacity in kbytes changed from 16764672 to 16771584, an increase of
6912 kbytes which matches the expected change in blocks (13824 blocks
2 blocks/kbyte = 6912 kbytes). For more information on handling
LUN expansion for UNIX systems, reference the EMC Symmetrix LUN
Expansion and UNIX Logical Volume Managers Technical Note available on
Powerlink.
# df -k
Filesystem
kbytes
used
avail capacity Mounted on
. . .
16764672
21198 15697013
1%
/cphome
# /etc/vx/bin/vxresize -g cpvg -F vxfs cplv +13824
# vxprint -g cpvg -htq
dg cpvg
default
default 33000
1214852481.33.licod229
dm cpvgd0
emcpower2s2 auto
. . .
v cplv
ENABLED
pl cplv-01
cplv
ENABLED
sd cpvgd0-01
cplv-01
cpvgd0
sd cpvgd1-01
cplv-01
cpvgd1
sd cpvgd2-01
cplv-01
cpvgd2
sd cpvgd3-01
cplv-01
cpvgd3
sd cpvgd2-02
cplv-01
cpvgd2
sd cpvgd1-02
cplv-01
cpvgd1
sd cpvgd0-02
cplv-01
cpvgd0
# df -k
Filesystem
kbytes
used
. . .
16771584
21198
#
2048
8385792
ACTIVE
ACTIVE
0
0
0
0
8382336
8382336
8382336
33543168
33543168
8382336
8382336
8382336
8385792
3456
3456
3456
SELECT
CONCAT
0
8382336
16764672
25147008
33532800
33536256
33539712
avail capacity
15703493
1%
fsgen
RW
emcpower2 ENA
emcpower1 ENA
emcpower0 ENA
emcpower4 ENA
emcpower0 ENA
emcpower1 ENA
emcpower2 ENA
Mounted on
/cphome
5.12 Cleanup step 19, redeploy the source devices storage

Exactly how the storage that was used for the original source devices is
redeployed is unique to each situation, so it would not be meaningful to
try to depict a best practice here. In some cases of data migration, the
old storage is literally removed from the site and is not made available
for any actual redeployment. In the example used in this chapter, it is
likely that the devices would either be reused as already configured for
different data, or be deleted and reconfigured for different data.
110
6
Hot Pull from CLARiiON
Migration Example
This chapter details a hot pull Open Replicator example that differs
from the previous cold push example in the set of steps needed to
complete the migration. This chapter also highlights a troubleshooting
example that demonstrates an initial failure to successfully complete
setup step 6. The topics covered include:
6.1 Introduction ...................................................................................

6.2 Setup step 1, identify target devices...........................................
6.3 Setup step 2, configure migration SAN zone............................
6.4 Setup step 3, configure migration LUN masking.....................
6.5 Setup step 4, configure target zoning and LUN masking.......
6.6 Setup step 5, Prepare Open Replicator session pairs file ........
6.7 Setup step 6, verify completion of setup steps .........................
6.8 Migration step 9, Stop the applications .....................................
6.9 Migration step 10, symrcopy activate ........................................
6.10 Migration step 11, Restart applications using targets............
6.11 Migration step 13, symrcopy query and verify ......................
6.12 Migration step 15, verify migration and terminate................
6.13 Cleanup step 19, redeploy the source devices ........................
112
115
116
118
119
121
124
129
131
132
137
138
138
111
6.1 Introduction
This chapter details a hot pull migration example using Solutions
Enabler SYMCLI on a Windows host. The full range of migration steps
will be reviewed and steps that are different than those detailed in
Chapter 4, Cold Push to CLARiiON Setup Example and Chapter 5,
Cold Push to CLARiiON Migration Example will be highlighted.
6.1.1 Hot pull setup steps

Since this is a hot operation, the zoning and LUN masking
requirements are stricter than for cold operations, requiring all
Symmetrix FA ports that are mapped by the control devices to be zoned
and LUN masked to "see" the remote devices. In order to demonstrate
troubleshooting in an example, the setup steps 2 and 3 will deliberately
miss meeting this requirement. Additionally, because this is a hot pull
migration some of the actions completed in the previous example as
cleanup phase steps, instead are completed here during the setup phase
in step 4. The six hot pull setup steps are:
2. Configure/connect migration SAN zone between remote devices
and Symmetrix V-Max (or Symmetrix DMX) control FA host
ports.
Symmetrix V-Max (or Symmetrix DMX) control FA host ports.
devices.
5. Prepare Open Replicator session pairs file.
Replicator session.
6.1.2 Hot pull migration steps

This chapter will provide details of an example of the six migration
steps applicable for a hot pull. In this example, step 8 which invokes a
create in the migration phase is not necessary. The create is
executed at the end of the setup phase, and this time there is no
TimeFinder operation which in Section 5.2.2, Initial
TimeFinder/Mirror establish, on page 89 required exiting the
Created state through a terminate action. Step 9 needed for all pull
migrations is now included, and step 11 for hot pull migrations is
included as well. Tuning is applicable for all migrations including hot
112
pull, and already completed earlier in Section 5.5, Migration step 12,
symrcopy set ceiling, on page 97. It is not necessary to repeat this
action in this example, because the ceiling setting applies to all sessions
which use the same FA director ports. Step 14 is omitted because
iteratively applying incremental updates is not applicable for pull
operations. The hot pull migration steps are:
9. Stop the production application.
11. Restart the application pointing to the target (control) devices.
6.1.3 Hot pull cleanup step

In the case of hot pull, applications are redirected to access the data
from the target devices before the data movement is complete.
Therefore, the first three cleanup steps are actually completed in the
setup phase. That leaves only a single step in the cleanup phase, step 19:
to redeploy the source devices storage once the migration is complete.
Figure 18 on page 114 illustrates the hot pull setup, migration, and
cleanup steps in a flowchart. The nonapplicable step 14, iterative
incremental update for push sessions, and the three nonapplicable
cleanup steps (steps 16-18) are omitted from the flowchart entirely to
avoid unnecessary complexity.
113
target devices
2. Zone DMX FA
control to remote array
3. LUN mask remote
devices to DMX FA
Hot pull?
N

7. Split the BCV


cluster, create
pairs (file)
6. Verify setup
Cold push
from BCV, clone
or VDEV?
N
Create not run?
N
Pull?
N
10. OR activate
Hot pull?
N
Need tuning?

target devices

impact level
N
13. Verify OR copy
done
Push?
N

terminate OR
Hot pull?
N

storage
ICO-IMG-000541a
Figure 18
114
Hot pull setup, migration, and cleanup flowchart

For this pull example, the target devices are the control
devices on the Symmetrix DMX 000190300359 array. The
remote source devices are 2 GB in size and the target devices
are 4 GB in size. The symdev command with the -range
option can be used to display the control devices 91:94
also revealing the Physical Device Names:
c:\>symdev -sid 359 list -range 91:94
Device Name
Directors
Device
--------------------------- ------------ -----------------------------------Cap
Sym Physical
SA :P DA :IT Config
Attribute
Sts
(MB)
--------------------------- ------------ -----------------------------------0091
0092
0093
0094
\\.\PHYSICALDRIVE6
\\.\PHYSICALDRIVE7
\\.\PHYSICALDRIVE8
\\.\PHYSICALDRIVE9
15C:0
15C:0
02C:0
02C:0
15B:D6
01A:CC
02B:D7
01A:DD
2-Way
2-Way
2-Way
2-Way
Mir
Mir
Mir
Mir
N/Grp'd
N/Grp'd
N/Grp'd
N/Grp'd
RW
RW
RW
RW
4096
4096
4096
4096
c:\>
115
6.3 Setup step 2, configure migration SAN zone

This example will use the same Symmetrix and CLARiiON arrays as
used in Chapter 4, Cold Push to CLARiiON Setup Example.
Therefore the zone for the DMX FA port that acts as an open systems
host to the remote storage array is already set up. A quick check will be
made to confirm that the correct zoning and LUN masking has been set
up for the devices to be used in this example.
6.3.1 Determining control director WWNs

The Solutions Enabler symdev list -multiport command is used to
determine on which directors the control devices are visible. For this
example, all four control devices, 91-94, are mapped to both director 2C
port 0 and director 15C port 0. These are the same FA director ports that
were eligible to be configured in the Open Replicator SAN zones in
Section 4.3.1, Determining Control Director WWN, on page 68.
c:\>symdev -sid 359 list -range 91:94 -multiport
M U L T I - P O R T
D E V I C E S
Device Name
Directors
Device
--------------------------- ------------- ----------------------------------Cap
Physical
Attribute
Sts
(MB)
--------------------------- ------------- ----------------------------------
\\.\PHYSICALDRIVE6
Not Visible
0091
15B:D6 2-Way Mir
- 15C:0
- - 02C:0
- -
N/Grp'd
-
RW
-
4096
-
\\.\PHYSICALDRIVE7
Not Visible
0092
01A:CC 2-Way Mir
- 15C:0
- - 02C:0
- -
N/Grp'd
-
RW
-
4096
-
\\.\PHYSICALDRIVE8
Not Visible
0093
02B:D7 2-Way Mir
- 02C:0
- - 15C:0
- -
N/Grp'd
-
RW
-
4096
-
\\.\PHYSICALDRIVE9
Not Visible
0094
01A:DD 2-Way Mir
- 02C:0
- - 15C:0
- -
N/Grp'd
-
RW
-
4096
-
c:\>
116
6.3.2 Determining remote storage array WWNs

The remote storage array is again CLARiiON HK190807410004.
Figure 19 illustrates checking the connectivity status for Storage Group
D194 and reveals the same A-0, A2, B-0, B-2 Storage Processor
connections as those seen in Section 4.3.2, Determining Remote
Storage Array WWN(s), on page 69
ICO-IMG-000542
Figure 19
Host connectivity status for licod194 in Storage Group D194
6.3.3 Reuse existing migration SAN zones

Since the same Symmetrix DMX FA and CLARiiON SPA ports are
relevant to this example and were put in place for the example in
chapters 4-5, it appears that the zones already defined can be used
without change. However, the example in this chapter is for a hot
operation which requires all paths to be configured so each director can
handle protected track copy needs for itself. For hot pull operations,
protected tracks that have not already been copied by the background
copy are copied immediately as part of Copy on First Access (COFA).
For hot push operations the protected track copy is Copy on First Write
(COFW). The single active path zoning already defined for director 2C
port 0 alone is insufficient because director 15C port 0 is not included in
any migration zone. For purposes of displaying typical error messages
when required zoning is missing, this example will proceed without
adding the missing zones at this time.
117
6.4 Setup step 3, configure migration LUN masking

6.4.1 Create CLARiiON Storage Group
Because the same DMX FA hosts are connected to the same remote
CLARiiON storage array, storage group OR_Symm359 defined in
Section 4.4.1, Create CLARiiON storage group, on page 73 can be
reused. However, like the zoning above, for a hot operation, all paths
must be LUN masked and the single FA DMX port host in the storage
group (corresponding to DMX FA 2C port 0, but not 15C port 0) will
prove to be insufficient. For purposes of displaying typical error
messages when necessary LUN masking is missing, this example will
proceed without completing all LUN masking requirements at this
time. The four remote source devices for this pull example are added to
the storage group in the example below:
c:\>navicli -h Clar0031_SPA storagegroup -addhlu -gname OR_Symm359 -alu 0 -hlu 0
c:\>
118
6.5 Setup step 4, configure target zoning and LUN masking

Unlike the example for setting up a cold push in Chapter 4, Cold Push
to CLARiiON Setup Example, the current example is a hot pull which
moves up the step of zoning and masking the target devices from
occurring in the cleanup phase to the setup phase, since the application
will be accessing the target devices from the start.
Target devices 91-94 are already correctly mapped and device masked
as shown below by the presence of a physical path displayed when the
sympd list command is executed:
c:\>sympd -sid 359 list
Device Name
Directors
Device
------------------------ ------------- -------------------------------Cap
Physical
Attribute
Sts (MB)
------------------------ ------------- -------------------------------. . .
\\.\PHYSICALDRIVE6 0091 02C:0 15B:D6 2-Way Mir
N/Grp'd
RW
4096
\\.\PHYSICALDRIVE7 0092 15C:0 01A:CC 2-Way Mir
N/Grp'd
RW
4096
\\.\PHYSICALDRIVE8 0093 02C:0 02B:D7 2-Way Mir
N/Grp'd
RW
4096
\\.\PHYSICALDRIVE9 0094 02C:0 01A:DD 2-Way Mir
N/Grp'd
RW
4096
. . .
c:\>
119
For example, a command file named map.txt that could be used for
the mapping operation would look something like this:
map dev 91:94 to dir 2C:0 starting lun=81;
map dev 91:94 to dir 15C:0 starting lun=81;
And invoking the mapping operation and specifying the device

masking commands could be done by executing a command sequence
like this:
c:\>symconfigure -sid 359 -f map.txt commit
Execute a symconfigure operation for symmetrix '000190300359' (y/[n]) ? y
A Configuration Change operation is in progress. Please wait...
Establishing a configuration change session............Established.
Processing symmetrix 000190300359
Performing Access checks...............................Allowed.
Checking Device Reservations...........................Allowed.
Submitting configuration changes.......................Submitted
Locking devices........................................Locked.
Validating configuration changes.......................Validated.
Initiating PREPARE of configuration changes............Prepared.
Initiating COMMIT of configuration changes.............Queued.
COMMIT requesting required resources...................Obtained.
Step 012 of 012 steps..................................Executing.
Local: COMMIT.........................................Done.
Terminating the configuration change session...........Done.
The configuration change session has successfully completed.
c:\>symmask list hba
Identifier
---------------10000000c97111fc
10000000c971196e
Type
----Fibre
Fibre
Adapter
---------------10000000c97111fc
10000000c971196e
Physical Device Path

--------------------\\.\PHYSICALDRIVE33
\\.\PHYSICALDRIVE5
Dir:P
----02C:0
15C:0
c:\>symmask -sid 359 -wwn 10000000c97111fc -dir 2c -p 0 add devs 91:94 -dynamic_lun
c:\>symmask -sid 359 -wwn 10000000c971196e -dir 15c -p 0 add devs 91:94 -dynamic_lun
The following devices are already assigned in at least one entry:
0091 0092 0093 0094
Would you like to continue (y/[n])?y
c:\>symmask -sid 359 refresh -noprompt
Symmetrix FA directors updated with contents of SymMask Database 000190
300359
c:\>
120
6.6 Setup step 5, Prepare Open Replicator session pairs file

The application for this example uses Windows drive letters L, M, N
and O which reside on the initial CLARiiON source devices. Figure 20
illustrates the contents of drive L as seen with the Windows Explorer.
ICO-IMG-000543
Figure 20
Windows drive L contents
121
Using Disk Management, it can be seen in Figure 21 that drives L, M, N

and O correspond to disks 1-4. Note that the size of each drive is 2 GB.
ICO-IMG-000544
Figure 21
122
Windows Disk Management display of drives L, M, N and O
Because the CLARiiON has been discovered in the SYMAPI database

file, the CLARiiON device numbers (0-3) related to physical drives 1-4
can be determined using the symdev list command with the
-clariion option. For example:
c:\>symdev list -clariion
Device
---- --------------------Num
Physical Name
---- ---------------------
Device
------------------------------------------------Config Cap(MB) WWN
-------------------------------------------------
00000
\\.\PHYSICALDRIVE1
RAID-5
2048
600601602B401E000CDB4E44EA4DDD11
00001
\\.\PHYSICALDRIVE2
RAID-5
2048
600601602B401E000DDB4E44EA4DDD11
00002
\\.\PHYSICALDRIVE3
RAID-5
2048
600601602B401E000EDB4E44EA4DDD11
00003
. . .
c:\>
\\.\PHYSICALDRIVE4
RAID-5
2048
600601602B401E000FDB4E44EA4DDD11
Therefore, for this example hot pull session, the Open Replicator pair
file defining the control-remote pairs could be:
c:\>type hot_pull_orpairs.txt
symdev=000190300359:0091 clardev=HK190807410004:0
c:\>
123

6.7.1 Discover missing zoning with symrcopy create
Using the hot_pull_orpairs file, an attempt to create the hot pull
Open Replicator session will reveal any problems with the required
setup:
c:\>symrcopy -file hot_pull_orpairs.txt -pull -hot create
in device file 'hot_pull_orpairs.txt' (y/[n]) ? y
in device file 'hot_pull_orpairs.txt'. Please wait...
The ORS create operation failed, see the SYMAPI log file for more information
c:\>
124
Detailed error messages can be displayed by re-executing the create

action with the verbose option -v specified, providing similar
information as can be obtained by examining the contents of the
SYMAPI log file. In the example shown below, the first reported status
SANCOPY_DEV_SUCCESS indicates that for control device 91, director
2C could see the remote device. However, the second reported status
SANCOPY_DEV_NO_REMOTE_TARGETS indicates that for the same
control device 91, director 15C could not see any remote devices. This
indicates that a zoning error exists.
c:\>symrcopy -file hot_pull_orpairs.txt -pull -hot create -v
STARTING a REMOTE Copy CREATE (PULL) (HOT)
SELECTING Control device - Remote devices:
(Ctl)Sym: 000190300359
DD11 - [SELECTED]
(Ctl)Sym: 000190300359
DD11 - [SELECTED]
(Ctl)Sym: 000190300359
DD11 - [SELECTED]
(Ctl)Sym: 000190300359
DD11 - [SELECTED]
Device: 00091 -
LUN WWN: 600601602B401E000CDB4E44EA4D
Device: 00092 -
LUN WWN: 600601602B401E000DDB4E44EA4D
Device: 00093 -
LUN WWN: 600601602B401E000EDB4E44EA4D
Device: 00094 -
LUN WWN: 600601602B401E000FDB4E44EA4D
STARTING a RCOPY 'CREATE' operation.

(Ctl)Sym: 000190300359 Device: 00091 LUN WWN: 600601602B401E000CDB4E44EA4D
DD11 - [loc_dir:02C, rem_num:0, rem_sts:0x1SANCOPY_DEV_SUCCESS ]
DD11 - [loc_dir:15C, rem_num:0, rem_sts:0xaSANCOPY_DEV_NO_REMOTE_TARGETS ]
DD11 - [SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR]
The Rcopy 'CREATE' operation FAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)
c:\>
The symsan list -sanports command confirms the missing

zoning definition:
c:\>symsan list -sanports -sid 359 -dir 15c -port 0

No results found.
c:\>
125
6.7.2 Example configuration of additional migration SAN zone

For the hot pull, it is necessary to define a zone for all directors mapped
to the control device. However, only a path for FA 2C port 0 was zoned
in Section 4.3.4, Example configuration of migration SAN zones, on
page 72. Now, a second active path is defined for FA 15C port 0
including the standby path to accommodate trespassing in the
CLARiiON. The original zone defined a path from Symmetrix 2C0 to
CLARiiON SPB0 (and standby path to SPA0). The new zone defines a
path from Symmetrix 15C0 to CLARiiON SPB2 (and standby path to
SPA2). The definition of two independent active zones instead of one
zone with all paths results in better performance due to the way Open
Replicator manages alternate paths. Figure 22 shows an excerpt of the
Connectrix Manager Zoning verification screen with the additional
path and standby path zoning defined.
ICO-IMG-000545
Figure 22
Activate additional zones verification screen excerpt
6.7.3 Discover missing LUN masking with symrcopy create

In the example below, a repeat of the attempt to create the hot pull
Open Replicator session will produce a different error since zoning is in
place but LUN masking is still missing. The second status reported for
control device 91, the entry for director 15C now reports
SANCOPY_DEV_WWID_NOT_FOUND indicating that the remote device
WWN could not be found. Since the WWN came from the SYMAPI
database, the cause is not a WWN entry error, but that the correct WWN
cannot be seen. This is most likely the result of missing LUN masking.
c:\>symrcopy -file hot_pull_orpairs.txt -pull -hot create -v
126

STARTING a REMOTE Copy CREATE (PULL) (HOT)
SELECTING Control device - Remote devices:
(Ctl)Sym: 000190300359 Device: 00091 DD11 - [SELECTED]
. . .
STARTING a RCOPY 'CREATE' operation.
LUN WWN: 600601602B401E000CDB4E44EA4D

DD11 - [loc_dir:02C, rem_num:0, rem_sts:0x1SANCOPY_DEV_SUCCESS ]
DD11 - [loc_dir:15C, rem_num:0, rem_sts:0x6SANCOPY_DEV_WWID_NOT_FOUND ]
DD11 - [SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR]
c:\>
The symsan list -sanports command confirms that zoning is in

place, but when the -sanluns option is used with the symsan list
command, there are no complete LUN records. For example:
c:\>symsan list -sanports -sid 359 -dir 15c -port 0

Flags
Num
DIR:P
I
Vendor
Array
LUNs Remote Port WWN
----- ----- ------------- ---------------- ---- -------------------------------15C:0
EMC CLARiiON
HK190807410004
1 5006016A41E087E6
15C:0
EMC CLARiiON
HK190807410004
1 5006016241E087E6
Legend:
Flags: (I)ncomplete : X = record is incomplete, . = record is complete.
c:\>symsan list -sanluns -wwn 5006016241E087E6 -sid 359 -dir 15c -port 0
Symmetrix ID:
000190300359
Remote Port WWN:
5006016241E087E6
ST
A
T Flags Block
Capacity
LUN
Dev LUN
DIR:P E ICRT Size
(MB)
Num
Num WWN
----- -- ----- ----- ----------- ----- ----- -------------------------------15C:0 NR X...
N/A
1
0
N/A 50060160C1E087E650060160C1E087E6
Legend:
Flags: (I)ncomplete
(C)ontroller
(R)eserved
(T)ype
:
:
:
:
X
X
X
A
=
=
=
=
record
record
record
AS400,
is incomplete, . = record is complete.

is controller, . = record is not controller.
is reserved, . = record is not reserved.
F = FBA, C = CKD, . = Unknown
c:\>
127
6.7.4 Example LUN masking for all Symmetrix V-Max (or Symmetrix DMX) FA
control directors
Defining zoning is not the only thing required to provide access. In this
example, FA 15C port 0 also needs to be properly LUN masked before
the remote devices can be seen. For the remote CLARiiON array in this
example, this can be accomplished by adding the FA 15C port 0 host to
the OR_symm359 storage group. Symmetrix FA host 15C is manually
registered for both the SPB port 2 and SPA port 2 in the storage group:
c:\>navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D
5:F0:31:CE:50:06:04:8A:D5:F0:31:CE -sp b -spport 2 -host Sym0359 -failovermode 1 -o -unit
serialnumber array
c:\>navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D
5:F0:31:CE:50:06:04:8A:D5:F0:31:CE -sp a -spport 2 -host Sym0359 -failovermode 1 -o -unit
serialnumber array
c:\>
6.7.5 Successful create verifies hot pull setup

Now that the correct zoning and LUN masking is in place, the Open
Replicator create succeeds without error in the following example.
Although the Open Replicator sessions are now setup, data movement
has not yet begun. The best practice for hot pull migrations is to always
include the -donor_update option if production applications will be
writing to the target devices. This is necessary to protect against
potential data loss due to a SAN failure or other connectivity issues
during a hot pull operation:
c:\>symrcopy -file hot_pull_orpairs.txt create -pull -hot -donor_update -name
hot_pull -copy
in device file 'hot_pull_orpairs.txt'.
c:\>
128
6.8 Migration step 9, Stop the applications

Since this example is a pull migration, it is necessary to stop any
production applications that are using the remote source devices (drives
L-O), in order to fix a point-in-time for the remote array devices. This is
done at an appropriate time when a short interruption in running the
production applications can be tolerated.
The Symmetrix Integration Utilities (SIU, available with Solutions
Enabler) integrates and extends the Windows 2003 and Windows 2008
disk management functionality to better operate with EMC Symmetrix
business continuance storage devices. Data migration using Open
Replicator can also take advantage of this functionality with support
specifically for Windows servers by extending their ability to:
Mount and unmount hard disks and their associated file systems
Flush file system cache buffers to disk
Manipulate disk signatures
Scan the drive connections and discover any new disks available
to the system
The SIU includes the symntctl command to execute the needed
functionality. Once the production applications are stopped, the remote
source volumes will no longer be used and are unmounted. The
symntctl umount command:
Obtains an exclusive lock on that volume from the operating
system, which will fail if another application is still using the
drive
Performs a file system flush as part of the dismount process
Flags the drive as permanently dismounted (offline) until a
subsequent mount operation. This ensures that no other
applications can access the volume while it is being unmounted,
thus ensuring data integrity during migration operations.
129
For example, the following symntctl commands can be used to

unmount drives L through 0:
c:\>symntctl umount -drive L:
Successfully unmounted the volume.
c:\>symntctl umount -drive M:
c:\>symntctl umount -drive N:
c:\>symntctl umount -drive O:
c:\>
Additionally, to ensure that the original source volumes will not

become visible on a subsequent rescan or reboot, the LUN masking for
each volume needs to be removed. This is done by issuing a set of
commands that look like this:
c:\>navicli -h Clar0031_SPA storagegroup -removehlu -gname D194 -hlu 00 -o
c:\>
130
6.9 Migration step 10, symrcopy activate

The activate action sets the point-in-time for the pull of data from the
remote to the control. In this hot pull example, there is no need for
consistency options, as the applications were stopped and the disk
cache was flushed thereby ensuring consistency. Notice that after the
activate, the Status changes to CopyinProg(ress) and the
Protected Tracks counts decrease as tracks are copied to the control.
c:\>symrcopy -session_name hot_pull activate
with session name 'hot_pull' (y/[n]) ? y
with session name 'hot_pull'. Please wait...
with session name 'hot_pull'.
c:\>symrcopy -session_name hot_pull query
Session Name
: hot_pull
Control Device
---------------------------Protected
SID:symdev
Tracks
------------------ --------000190300359:0094
32757
000190300359:0093
32760
000190300359:0092
32760
000190300359:0091
32755
Total
Track(s)
MB(s)
Remote Device
Flags
Status
Done
------------------------- ----- -------------- ---Identification
---------------------HK190807410004:00003
HK190807410004:00002
HK190807410004:00001
HK190807410004:00000
RI
-CD
CD
CD
CD
CDSHU
----X..XX
X..XX
X..XX
X..XX
CTL <=> REM

(%)
-------------- ---CopyInProg
0
CopyInProg
0
CopyInProg
0
CopyInProg
0
--------131032
8189.5
Legend:
I:

Flags:
(C): X =
. =
(D): X =
. =
(S): X =
. =
(H): X =
. =
(U): X =
. =
(*): The

c:\>
131
6.10 Migration step 11, Restart applications using targets

Now that the data copying has begun, production applications can be
restarted immediately without waiting for the copy to complete. If an
attempt is made to access data not yet copied, then it will be copied
(COFA) immediately. Copying all of the data from the source devices to
the targets includes copying information about the 2 GB original size of
the source devices. The symntctl update command can be used to
update the partition information to include the additional space that
actually exists on the target devices:
c:\>symntctl rescan
Device rescan in progress...
Device rescan completed successfully.
c:\>symntctl update -pd \\.\PHYSICALDRIVE6
Successfully updated device partitions.
c:\>
132
Figure 23 illustrates the updated partition information presented in

Disk Management that shows the 2.01 GB of additional unallocated
space for each disk. Since the disks have not yet been mounted, all of
the allocated partition information is shown as being Free Space.
ICO-IMG-000546
Figure 23
Disk Management display of target devices additional space
133
The symntctl mount command is used now to mount the target

devices using the same drive letters as the source devices had used, so
production applications that use the filesystems will now access the
data on the target devices.
c:\>symcfg discover -all
c:\>symntctl mount -drive L: -sid 359 -symdev 91
Successfully mounted the volume.
c:\>symntctl mount -drive M: -sid 359 -symdev 92
c:\>symntctl mount -drive N: -sid 359 -symdev 93
c:\>symntctl mount -drive N: -sid 359 -symdev 94
c:\>
134
The DiskPart utility is used to extend the allocated disk partition to use
the unallocated space, so that all 4 GB of space can be used by
applications. For example:
c:\>diskpart
Microsoft DiskPart version 5.2.3790.3959
Copyright (C) 1999-2001 Microsoft Corporation.
On computer: LICOD194
DISKPART> select disk 6
Disk 7 is now the selected disk.
DISKPART> list partition
Partition ### Type
Size
Offset
------------- ---------------- ------- ------Partition 1
Primary
2039 MB
32 KB
DISKPART> select partition 1
Partition 1 is now the selected partition.
DISKPART> extend
DiskPart successfully extended the volume.
DISKPART> extend
DISKPART> extend
135
DISKPART> extend
DISKPART> exit
Leaving DiskPart...
c:\>
Figure 24 illustrates the updated display from Disk Management

showing the extended 4 GB partitions (no longer the original 2 GB).
ICO-IMG-000547
Figure 24
136
Disk Management updated display showing 4 GB partitions
6.11 Migration step 13, symrcopy query and verify

completes copying all of the tracks from the remote devices to the control
devices. Once this is done, the original source devices are no longer
needed. The query action will report the Status and the decreasing
number of Protected Tracks, and the increasing Done percent.
Using the verify action allows scripts to wait for a particular status:
c:\>symrcopy -session hot_pull query
Session Name
: hot_pull
Control Device
---------------------------Protected
SID:symdev
Tracks
------------------ --------000190300359:0094
32416
000190300359:0093
32403
000190300359:0092
32427
000190300359:0091
32413
Total
Track(s)
MB(s)
Remote Device
Flags
Status
Done
----------------------- ----- -------------- ---Identification
-------------------HK190807410004:00003
HK190807410004:00002
HK190807410004:00001
HK190807410004:00000
RI
-CD
CD
CD
CD
CDSHU
----X..XX
X..XX
X..XX
X..XX
CTL <=> REM

(%)
-------------- ---CopyInProg
1
CopyInProg
1
CopyInProg
1
CopyInProg
1
--------129659
8103.7
Legend:
I:

Flags:
(C): X =
. =
(D): X =
. =
(S): X =
. =
(H): X =
. =
(U): X =
. =
(*): The

c:\>symrcopy -session hot_pull verify -copied -i 300 -c 36

None of the session(s) with name 'hot_pull' are in 'Copied' state.
None of the session(s) with name 'hot_pull' are in 'Copied' state.
. . .
All session(s) with name 'hot_pull' are in 'Copied' state.
c:\>
137
6.12 Migration step 15, verify migration and terminate

Because this is a hot pull, production applications are already using the
target devices, in effect verifying the validity of the copied data.
However, if any application specific verification of the migration is
desired, it must be completed before terminating the Open Replication
copy sessions along with the donor update feature that keeps the
original source updated with all changes since the production
applications began using the targets. Once the validation is complete,
the Open Replicator sessions are no longer needed and can be
terminated by executing a set of commands that look something like the
following:
c:\>symrcopy -session hot_pull terminate
The specified action is not allowed without the force flag because the control device has
a session with donor update enabled
c:\>symrcopy -session hot_pull set donor_update off -consistent
Execute 'Set Donor Update Off' operation for the 4 specified devices
'Set Donor Update Off' operation execution is in progress for the device list with session
name 'hot_pull'. Please wait...
'Set Donor Update Off' operation successfully executed for the device list with session
name 'hot_pull'.
c:\>symrcopy -session hot_pull terminate
with session name 'hot_pull'.
c:\>
6.13 Cleanup step 19, redeploy the source devices

Because this example is a hot pull, the key cleanup steps of redirecting
production applications to access the target devices in place of the
source devices were completed in Section 6.10, Migration step 11,
Restart applications using targets, on page 132. Step 19, redeploy the
source devices storage, is the only step remaining in the cleanup phase.
138
7
Hot Pull from Symmetrix
Migration Example
This chapter details using Symmetrix Management Console (SMC) as

the management tool to manage an Open Replicator hot pull. As
another hot pull example, the required steps match the example in
Chapter 6, Hot Pull from CLARiiON Migration Example, with the
small difference being that the remote storage array is a Symmetrix.
The topics covered include:
7.1 Introduction .................................................................................... 140

7.2 Setup step 1, identify target devices............................................ 143
7.3 Setup step 2, configure migration SAN zone............................. 144
7.4 Setup step 3, configure migration device masking ................... 149
7.5 Setup step 4, configure target zoning and LUN masking........ 165
7.6 Setup step 5, prepare Open Replicator session pairs file ......... 166
7.7 Setup step 6, verify completion of setup steps .......................... 170
7.8 Migration step 9, stop the applications....................................... 174
7.9 Migration step 10, Open Replicator activate.............................. 177
7.10 Migration step 11, restart applications using targets.............. 179
7.11 Migration step 12, tune migration ............................................ 181
7.12 Migration step 13, check status, wait until copied .................. 183
7.13 Migration step 15, verify migration and terminate................. 184
7.14 Cleanup step 19, redeploy the source devices ......................... 186
139
7.1 Introduction
This chapter details a hot pull migration example using Symmetrix
Management Console (SMC) on a Windows host. This example is very
similar to the hot pull example in Chapter 6, Hot Pull from CLARiiON
Migration Example, requiring the same steps to be completed. This
example will highlight the use of SMC for the completion of the steps;
the remote storage array is a Symmetrix, so all the required device
(LUN) masking can also be completed from within SMC.
7.1.1 Hot pull setup steps

Since this is a hot operation, all Symmetrix FA ports that are mapped by
the control devices must be zoned and LUN masked to "see" the remote
devices. In this example all zoning and masking requirements will be
met in the setup steps, including using SMC Remote Report to verify
completion. The definition of Open Replicator session pairs can be
completed in an SMC wizard dialog and the actual creation of a file is
optional. The six hot pull setup steps are:
2. Configure/connect migration SAN zone between remote devices
ports.
devices.
5.
6.
140
Prepare Open Replicator session pairs file step can be

completed by a selection process in SMC with or without the
creation of an actual file.
Verify completion of setup steps up to creating the Open
Replicator session.
7.1.2 Hot pull migration steps

This chapter will detail an example of six migration steps applicable for
a hot pull. The step 12 optional tuning action, that is applicable for all
migrations types, will be detailed again in order to illustrate the SMC
interface for tuning Open Replicator. The six hot pull migration steps
detailed are:
9. Stop the production application.
11. Restart the application pointing to the target (control) devices.
12. (optional) Tune migration to acceptable level of impact on
production applications.
7.1.3 Hot pull cleanup step

In the case of hot pull, applications are altered to access data from the
target devices before data movement is complete. Therefore, the first
three cleanup steps are completed in the setup phase. That leaves only a
single step in the cleanup phase, step 19: to redeploy the source devices
storage once the migration is complete.
Figure 25 on page 142 illustrates the hot pull setup, migration, and
cleanup steps in a flowchart. The nonapplicable step 14, iterative
incremental update for push sessions, and the three nonapplicable
cleanup steps (steps 16-18) are omitted from the flowchart entirely to
avoid unnecessary complexity.
141
target devices
2. Zone DMX FA
control to remote array
3. LUN mask remote
devices to DMX FA
Hot pull?
N

7. Split the BCV


cluster, create
pairs (file)
6. Verify setup
Cold push
from BCV, clone
or VDEV?
N
Create not run?
N
Pull?
N
10. OR activate
Hot pull?
N
Need tuning?

target devices

impact level
N
13. Verify OR copy
done
Push?
N

terminate OR
Hot pull?
N

storage
ICO-IMG-000548a
Figure 25
142
Symmetrix hot pull setup, migration, and cleanup flowchart

For this pull example, the target (control) devices are devices 95-98 on
the Symmetrix DMX 000190300359 array. Figure 26 illustrates the use
of the Device Properties display for these devices.
ICO-IMG-000549
Figure 26
SMC properties for Symmetrix 000190300359 devices 95-98
143
7.3 Setup step 2, configure migration SAN zone

This example uses a different remote array than in previous examples so
new migration zones need to be set up. The zones will include the
control Symmetrix V-Max (or Symmetrix DMX) FA ports, that act as
open systems host initiators and the remote Symmetrix storage array FA
ports where the remote devices are mapped.
7.3.1 Determining control director World Wide Port Names (WWPNs)

Figure 27 illustrates a display of device properties that can be used to
determine the control device FA directors. The # Paths column indicates
that each of the control devices is mapped to two paths. Selecting
device 95, displays the properties detail. Selecting the FBA Front End
Paths tab reveals that directors FA-2C port 0 and FA-15C port 0 are the
FA control ports.
ICO-IMG-000550
Figure 27
SMC Front End Paths detail for control target device 95
Navigating to the first FA director 2C port 0 provides the display of the

WWN for the port. Figure 28 on page 145 illustrates the properties for
director 2C port 0 including the WWN.
144
ICO-IMG-000551
Figure 28
SMC director 2C port 0 properties showing the port WWN
Figure 29 illustrates the properties for the control devices other mapped
director 15C port 0.
ICO-IMG-000552
Figure 29

145
7.3.2 Determining Remote Storage Array WWPN(s)

The remote storage array for this example is Symmetrix
000187720450. Figure 30 illustrates a display of the directors that
remote source device 141 is mapped to in the device detail FBA Front
End Paths tab.
ICO-IMG-000553
Figure 30
SMC Front End Paths detail for remote source device 141
Navigating to the first FA director 8C port 0 provides the display of the

WWPN. Figure 31 on page 147 illustrates the properties for director 8C
port 0 including the WWN.
146
ICO-IMG-000554
Figure 31
Figure 32 on page 147 illustrates the properties for the remote devices
other mapped director 9C port 0.
ICO-IMG-000555
Figure 32

147
7.3.3 Configuration of migration SAN zones

For the hot pull, it is necessary to zone all directors mapped to the
control device due to each director handling Copy on First Access
(COFA). In this example, two independent zones are defined for best
performance: one zone between control 2C:0 and remote 8C:0, and a
second zone between control 15C:0 and remote 9C:0.
Figure 33 is an excerpt from the Connectrix Manager verification screen
that illustrates the activation of two migration zones that have been
added to the active zoneset for the hot pull between the two Symmetrix
arrays.
ICO-IMG-000556
Figure 33
148
Connectrix Manager activate Symmetrix hot pull zones
7.4 Setup step 3, configure migration device masking

7.4.1 Application source device references
The application for this example uses Windows drive letters P, Q, R,
and S that reside on the remote Symmetrix source devices. Using
Windows Disk Management, it can be seen in Figure 34 that drives P, Q,
R, and S correspond to disks 29-32.
ICO-IMG-000557
Figure 34
Disk Management display of remote source drives P, Q, R, and S
149
7.4.2 Add Symmetrix device masking

Because the Symmetrix V-Max (or Symmetrix DMX) FA hosts are
connected to the remote storage array on switched fibre ports, it is
necessary to perform LUN masking to grant the Symmetrix V-Max (or
Symmetrix DMX) FA initiator access to the remote devices. This LUN
masking is performed with tools specific to the remote storage array,
that in this case is a Symmetrix and is called device masking. Since the
remote Symmetrix is only remote in terms of Open Replicator but is local
in the sense of presenting host visible devices, SMC can be used to
complete the device masking. Figure 35 illustrates invoking the Device
Masking Menu after right clicking the remote Symmetrix array (Device
Masking and MappingMasking).
ICO-IMG-000558
Figure 35
SMC Device Masking menu
Figure 36 on page 151 illustrates the SMC device masking dialog. The
dialog begins with the selection of the remote Director Port FA-8C:0 and
the control Director Port that is acting as the initiator WWN
5006048AD5F031C1 (FA-2C0). The list of Available Devices was filtered
by Dev Config = 2-Way Mir and Cap(acity) = 4096 MB. The four remote
devices 141-144 were moved to the masking Target list by clicking the
Add button. Notice the checkbox for refreshing the VCMDB after the
Apply/OK is checked. When checked, the refresh will occur
automatically.
150
ICO-IMG-000559
Figure 36
SMC add device masking for remote devices 141-144 on FA-8C:0
SMC presents a confirmation dialog that is used to report on the success

of invoking control actions. Figure 37 illustrates the Success
confirmation for the device masking operation.
ICO-IMG-000560
Figure 37
SMC device masking success confirmation dialog
151
Because this is a hot pull, masking must be defined on all paths.

Figure 38 illustrates the SMC device masking dialog adding access for
WWN 5006048AD5F031CE (control FA-15C:0) to remote devices 141-144
on remote director port FA-9C:0.
ICO-IMG-000561
Figure 38
SMC add device masking for remote devices 141-144 on FA-9C:0
7.4.3 Symmetrix V-Max device masking using Auto-provisioning Groups

Conceptually, adding Symmetrix V-Max device masking is the same as
shown for Symmetrix DMX in Add Symmetrix device masking, on
page 150. A parallel example using the SMC 7.1 Task Masking Wizard
will be shown in this section.
152
7.4.3.1 Auto-provisioning Groups

The Auto-provisioning Groups feature was introduced in Solutions
Enabler 7.0 and Symmetrix Management Console (SMC) 7.0. It provides
an easier, faster way to provision storage in Symmetrix V-Max arrays
running Enginuity 5874. Most of the applications running on
Symmetrix arrays require a fault-tolerant environment with clustered
hosts as well as multiple paths to devices. Auto-provisioning Groups
was developed to make storage allocation easier and faster, especially
with these types of configurations.
Mapping and masking devices in previous versions of Solutions
Enabler required a separate command for each initiator/port
combination through which devices would be accessed. Both
symaccess commands in Solutions Enabler and SMC allow the user to
create a group of devices (storage group), a group of director ports (port
group), and a group of host initiators (initiator group), and associate
them in a masking view. When the masking view is created, the devices
are automatically mapped and masked.
After the masking view is created, any objects (devices, ports, or
initiators) added to an existing group automatically become part of any
associated masking view(s). This means that no additional steps are
necessary to add additional devices, ports, or initiators to an existing
configuration. All necessary operations to make them part of the
configuration are handled automatically by Symmetrix Enginuity once
the objects are added to the applicable group. This reduces the number
of commands needed for mapping and masking devices and allows for
easier storage allocation and de-allocation.
The examples presented in this TechBook using symmask, symmaskdb
and SMC Device Masking are not applicable for Symmetrix V-Max
systems running Enginuity 5874. Solutions Enabler 7.0 introduces the
symaccess command to manage Auto-provisioning Groups and
includes parallel commands to symmask for actions like list logins
and list hba. SMC 7.0 introduces new menu items and dialogs for
managing Auto-provisioning Groups, including Storage Groups
Maintenance, Port Groups Maintenance, Initiator Groups Maintenance,
and Masking Views Maintenance.
For more information and examples see the Storage Provisioning With
EMC Symmetrix Auto-provisioning Groups Technical Note.
153
7.4.3.2 SMC Task Masking Wizard

Auto-provisioning can be invoked using multiple SMC menus to create
an Initiator Group, a Port Group, a Storage Group and a Masking View
to associate the three together. SMC also now supplies task interfaces to
more easily sequence these multiple steps without having to know each
menu to invoke and in what order. Figure 39 illustrates selecting the
Masking Wizard from the Tasks view.
ICO-IMG-000764
Figure 39
154
SMC Tasks Masking Wizard selection
Figure 40 illustrates the Masking Wizard step 1 welcome screen that

lists the sequence of steps that the wizard will lead you through and the
information that you will need to provide.
ICO-IMG-000765
Figure 40
Masking Wizard step 1 welcome screen
155
Figure 41 illustrates the Masking Wizard step 2 that is used to create a

masking view for the selected Symmetrix.
ICO-IMG-000766
Figure 41
156
Masking Wizard step 2 create masking view
Figure 42 illustrates part of Masking Wizard step 3 where the Create

button is clicked to create a new Initiator Group.
ICO-IMG-000767a
Figure 42
Masking Wizard step 3 click to create Initiator Group
Figure 43 on page 159 illustrates the create Initiator Group dialog. The
group is given the name OR1724_10E0_10F0 reflecting Open
Replicator, the last four digits of the Symmetrix ID and the two FA
directors that will be acting as host HBAs to the local Symmetrix 1715.
The values displayed as Available Initiators are present only after an
attempt to create the Open Replicator session is invoked. The attempt
causes the FAs to log in on the fabric even though the Open Replicator
create fails due to the missing LUN masking that is still being set up.
157
The FA WWN display on the control Symmetrix shows the WWNs for
10E0 and 10F0 that will be selected:
symcfg -fa all list
Symmetrix ID: 000192601724 (Local)
S Y M M E T R I X
Dir
FA-7E
FA-7E
FA-10E
FA-10E
FA-7F
FA-7F
FA-10F
FA-10F
158
Port
0
1
0
1
0
1
0
1
F I B R E
D I R E C T O R S
WWN
ACLX
Enabled
Volume Set
Addressing
Pnt to
50000972081AF118
50000972081AF119
50000972081AF124
50000972081AF125
50000972081AF158
50000972081AF159
50000972081AF164
50000972081AF165
Yes
Yes
Yes
No
Yes
No
Yes
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
ICO-IMG-000767b
Figure 43
Masking Wizard step 3 Initiator Group creation
After the Add button is clicked, the two selected initiators move from
the Available to the Selected display. Clicking the OK ends this dialog
returning to Masking Wizard step 3 where clicking the Next button
moves to step 4.
Figure 44 on page 160 illustrates Masking Wizard step 4 selecting the
ports. In this example, the Select button was clicked to bring up the a
display of existing Port Groups. The Port Group 7e0_10e0_p already
exists for the two ports that the Open Replicator remote devices are
mapped to and is highlighted when clicked on. Expanding the group
displays the two FA ports 7E0 and 10E0. where the Create button is
clicked to create a new Initiator Group. Clicking the OK button ends the
select dialog returning to Masking Wizard step 4.
159
Note: Unlike the previous example for Symmetrix DMX device masking, using
Auto-provisioning groups, it is not necessary to repeat the dialog for a second
(or third, or fourth, etc.) port. Simply adding multiple ports to the Port Group
completes masking for all of the ports.
ICO-IMG-000768
Figure 44
Masking Wizard step 4 select an existing Port Group
Clicking the Next button moves on to the next step in the wizard.
160
Figure 45 illustrates part of Masking Wizard step 5. Click the Create

button to open a dialog to create a new Storage Group made up of the
Open Replicator remote devices.
ICO-IMG-000769a
Figure 45
Masking Wizard step 5 click to create a Storage Group
161
Figure 46 illustrates the Storage Group create dialog. The Storage

Group name ORremoteTO1724 is defined. After selecting the Device
Source Type as Symmetrix, the hundreds of available devices were
filtered by clicking the filter button and selecting the specific size of
4097 MB devices. The Add All button is clicked to move the the devices
from the Available Devices display to the Group Members display.
ICO-IMG-000769b
Figure 46
Storage Group creation dialog
Clicking OK will return to Masking Wizard step 5, where clicking the

Next button will move to step 6.
Note: The value of the Auto-provisioning masking methodology can be
stressed by pointing out that to add additional devices to the Masking View
that is being defined, the only step required will be to modify the storage group
by adding the additional devices. Once that is done the devices will be visible
on all defined ports to all of the defined initiators.
162
Figure 47 illustrates Masking Wizard step 7 that displays a summary of

all previous steps to define the Masking View. Clicking the Finish
button ends the wizard and creates the Masking View completing the
masking definition..
ICO-IMG-000770
Figure 47
Masking Wizard step 7 summary
163
Figure 48 illustrates the Masking Wizard success dialog that displays

after the progres bar confirming successful creating of the new Masking
View.
Note: The progress dialog for the Masking View creation can take longer than
Symmetrix DMX users may be accustomed to. This is due to the fact that with
Enginuity 5874, masking creation will automatically map devices to the ports
that are being masked if they are not already mapped..
ICO-IMG-000771
Figure 48
164
Masking Wizard success dialog
7.5 Setup step 4, configure target zoning and LUN masking

The current example is a hot pull that moves the step of zoning and
masking the target devices from occurring in the cleanup phase to the
setup phase, since the application will be accessing the target devices
from the start.
Target devices 95-98 are already correctly mapped and device masked
host visible devices as shown by the Physical Device Name displayed
in the properties device detail in SMC. Figure 49 illustrates the
properties detail for control target device 95 showing host Physical
Device Name .\PHYSICALDRIVE15.
ICO-IMG-000562
Figure 49
SMC properties device detail for control target device 95.
Similarly, the displays for target devices 96-98 show Physical Device
Names .\PHYSICALDRIVE16-18.
165
7.6 Setup step 5, prepare Open Replicator session pairs file

The SMC Open Replicator Create Copy Session wizard consists of five
pages that include the definition of the session control-remote pairs.
Figure 50 illustrates invoking the Create Copy Session menu by
right-clicking the control Symmetrix in the navigation tree
(ReplicationOpen ReplicatorCreate Copy Session).
ICO-IMG-000563
Figure 50
SMC Open Replicator Create Copy Session menu
The first page of the wizard provides for the setting of session
parameters. In this example, the parameters are defined as a hot pull
session. The Device Selection default Customize radio button option
will use an additional three wizard pages to select the control and remote
device pairs. If previously saved to a file, it is possible to read in a pairs
file as well as to manually edit the pair definitions and skip to page five
of the wizard. Figure 51 on page 167 illustrates the setting of a session
as a hot pull session using the Customize method to specify the pair
definitions.
166
ICO-IMG-000564
Figure 51
SMC Create Copy Session page 1: Set session parameters
The second page provides for selecting the control devices. Figure 52
illustrates the selection of devices 95-98 and filtering the Available
Devices to see only devices that have been mapped to director FA-2C
port 0 and have a capacity of 4096 MB.
ICO-IMG-000565
Figure 52
SMC Create Copy Session page 2: select control devices

167
The third page provides for selecting the remote devices. Figure 53
illustrates the selection of devices 141-144 and filtering the Available
Devices to see only devices that have been zoned and masked on
Symmetrix 000187720450 director FA-8C port 0. This page of the wizard
only presents devices that are correctly zoned and LUN masked
offering a verification of correct setup even before invoking the Open
Replicator create action. The WWN radio button on this page can be
selected to manually add WWN formatted remote devices that may not
yet be correctly zoned and LUN masked.
ICO-IMG-000566
Figure 53
168
SMC Open Replicator page 3: Select remote devices
The fourth page provides for pairing the control and remote devices.
Figure 54 illustrates adding the pairing of control device 98 with remote
device 144.
ICO-IMG-000567
Figure 54
SMC Create Copy Session page 4: Select device pairs
169

7.7.1 Confirm hot pull setup with successful create
The fifth page of the Open Replicator wizard provides for setting
additional create options including enabling background Copy and
Donor Update. Before clicking the Finish button to invoke the create
operation, the Save button can be clicked to save the pair definitions in
a file that can be read and edited on page one of the wizard as an
alternate to defining pairing on pages two through four. Figure 55
illustrates setting Copy and Donor Update, and then initiating the
create operation.
ICO-IMG-000568
Figure 55
170
SMC Create Copy Session page 5: Set session options and execute
Similar to the prompt confirmation encountered when using the

Solutions Enabler symrcopy command, there is a confirmation screen
in SMC that gets displayed before any control action is invoked.
Figure 56 illustrates how to confirm the execution of the Open
Replicator Create action.
ICO-IMG-000569
Figure 56
SMC Confirm Open Replicator create execution
Figure 57 illustrates the Create Copy Session success dialog box. For the
rest of the control actions in this chapter, the dialogs for control action
confirmation and success will not be shown.
ICO-IMG-000570
Figure 57
SMC Create Copy Session success dialog box
171
7.7.2 SMC Remote Report

With SMC, the equivalent of symsan is checked as part of selecting
remote devices in the wizard. The SMC Remote Report provides an
explicit way of looking at this information from within SMC without
having to invoke the Create Copy Session wizard. Figure 58 illustrates
invoking the Remote Report menu with an initial right click of the
control Symmetrix V-Max (or Symmetrix DMX) array, and selecting
ReplicationOpen ReplicatorRemote Report.
ICO-IMG-000571
Figure 58
172
SMC Remote Report menu selection
Remote Report has two tabs. Figure 59 illustrates the Remote Ports tab,
that shows information similar to the symsan -sanports display for
director FA-2C port 0.
ICO-IMG-000572
Figure 59
SMC Remote Report Remote Ports tab
Clicking on the Remote Luns tab then selecting control director FA-2C
Port 0, and then selecting the Port WWN 5006048ACC18C087 for remote
Symmetrix 000187720450 FA-8C:0 confirms remote devices 141-144 are
accessible. Figure 60 illustrates the Remote Luns tab display:
ICO-IMG-000573
Figure 60
SMC Remote Report Remote Luns display
173
7.8 Migration step 9, stop the applications

Since this example is a pull migration, it is necessary to stop production
applications that are using the remote source devices (drives P-S), in
order to fix a point-in-time for the remote array devices. This is done at
the appropriate time when a short interruption in running the
production applications can be tolerated.
As in Section 6.8, Migration step 9, Stop the applications, on page 129
the Symmetrix Integration Utilities (SIU) symntctl command is used
to unmount the source drives.
c:\>symntctl umount -drive P:
c:\>symntctl umount -drive Q:
c:\>symntctl umount -drive R:
c:\>symntctl umount -drive S:
c:\>
174
Additionally, to ensure that the original source volumes will not

become visible on a subsequent rescan or reboot, the device masking for
the volumes needs to be removed.
Figure 61 shows removing the device masking for remote source devices
141-144 for Windows host HBA WWN 10000000c97111fc from director
FA-8C:0.
ICO-IMG-000574
Figure 61
SMC Removing device masking for devices 141-144 for FA-8C:0
175
After clicking Apply to make the masking change, and clicking OK in

the success dialog, the same change is made to the second path for the
source devices.
Figure 62 shows removing the device masking for remote source devices
141-144 for WWN 10000000c971196e from director FA-9C:0.
ICO-IMG-000575
Figure 62
176
SMC Removing device masking for devices 141-144 for FA-9C:0
7.9 Migration step 10, Open Replicator activate

Once the Open Replicator session is created, it can be selected in the
SMC navigation tree by expanding Replication Views and then
expanding Open Replicator Sessions. The Properties view displays
status equivalent to the symrcopy query command. In this case
control devices 95-98 are paired with remote devices 141-144 and the
state is Created. Right clicking on the session name in the navigation
tree can be used to bring up the Open Replicator Session Control menu.
Figure 63 illustrates the Open Replicator session navigation tree
selection, properties view and Session Control menu selection
(ReplicationOpen ReplicatorSession Control).
ICO-IMG-000576
Figure 63
SMC Open Replicator session properties and control menu
The SMC Session Control dialog, provides for selection of the desired
action. At this point, the Activate action is selected to set the
point-in-time for the pull of data from the remote to the control. In this
example of a hot pull, there is no need to click the Consistent checkbox
option, as the applications were stopped and the disk cache was flushed
ensuring consistency. Since SMC uses the same dialog to invoke an
operation on single or multiple devices, it is necessary to select the
device pairs that should be affected by the chosen action.
177
Figure 64 illustrates the selection of the Activate action for Open

Replicator session symm_hot_pull affecting all four device
control-remote device pairs.
ICO-IMG-000577
Figure 64
SMC Open Replicator Activate
Notice that after the activate, the State has changed to CopyinProg(ress)
and the Prot(ected) Tr(ac)ks have started to be decremented as tracks
have copied over to the control.
Figure 65 illustrates the change in status after an activate operation is
performed.
ICO-IMG-000578
Figure 65
178
Open Replicator session properties after activate
7.10 Migration step 11, restart applications using targets

Now that the data copying has begun, production applications can be
restarted immediately without waiting for the copy to complete. If an
attempt is made to access data that has not yet been copied, then that
data will be copied immediately (COFA). In this example the remote and
control devices are the same capacity, but have a different disk geometry
because the remote Symmetrix array is a DMX-2 and the control
Symmetrix array is a DMX-3. The Windows host operating system has
no problem with this change. However, Solaris requires some extra
steps to handle this difference that can be found on Powerlink in the
EMC Enginuity 5773 Flexible Device Geometry in a Sun Solaris Environment
Technical Note.
As previously explained, the symntctl command is used to rescan for
devices and update the control target device partitions:
c:\>symntctl rescan
Device rescan in progress...
Device rescan completed successfully.
c:\>
The symntctl mount command is used to mount the target devices

using the same drive letters that the source devices used, so production
applications that use the filesystems will now access the data on the
target devices.
c:\>symntctl mount -drive P: -sid 359 -symdev 95
c:\>symntctl mount -drive Q: -sid 359 -symdev 96
179

c:\>symntctl mount -drive R: -sid 359 -symdev 97
c:\>symntctl mount -drive S: -sid 359 -symdev 98
c:\>
Figure 66 illustrates the updated display from Disk Management

showing the volumes P-S now based on the target devices.
ICO-IMG-000579
Figure 66
180
Disk Management display of drives P-S on the target devices
7.11 Migration step 12, tune migration

The ability to set and change the pace and ceiling options is equivalent in
SMC as when using the symrcopy command. Figure 67 illustrates
invoking the Set Ceiling menu by first right clicking the control
Symmetrix array (the ceiling option affects all Open Replicator
sessions), and then ReplicationOpen ReplicatorSet Ceiling.
ICO-IMG-000580
Figure 67
SMC Select Open Replicator Set Ceiling Menu
181
The Set Ceiling dialog provides for selecting the Director and Port
individually, or selecting the ALL option for either or both (to select
multiple ports). Figure 68 illustrates setting the Ceiling percentage to 30
for Director FA-2C Port 0.
ICO-IMG-000581
Figure 68
182
SMC Open Replicator Set Ceiling
7.12 Migration step 13, check status, wait until copied

completes copying all of the tracks from the remote devices to the control
devices. Once this is done, the original source devices will no longer be
needed. The SMC Refresh View button can be clicked to update the
properties display for the Open Replicator session. This is one way to
see the decreasing number of Protected Tracks, and the increasing
% Complete.
Figure 69 illustrates clicking the Refresh View button and the Open
Replicator session properties with the default column positioning
reordered to display the columns of most interest without horizontal
scrolling.
ICO-IMG-000582
Figure 69
SMC Open Replicator session properties Refresh View update
183
7.13 Migration step 15, verify migration and terminate

Once the replication is complete, the State will change to Copied.
Figure 70 illustrates all pairs in the session in the Copied state.
ICO-IMG-000583
Figure 70
184
SMC Open Replicator session properties showing Copied state
Because SMC is a GUI and is not used in scripting, there is no direct

equivalent of the symrcopy verify command. However, as an
intelligent GUI, the available (nongrayed) drop-down menu Action
options displayed in the Open Replicator Session Control dialog reflects
which actions are valid for the current session state.
Because this is a hot pull, the production applications are already using
the target devices, in effect verifying the validity of the copied data.
However, if any application specific verification of the migration is
desired, it must be completed before terminating the Open Replication
copy sessions along with the donor update feature that keeps the
original source updated with all changes since the production
applications began using the targets. Once the validation is complete,
the Open Replicator sessions are no longer needed and can be
terminated.
Figure 71 illustrates turning off the donor update feature (notice that
the flags in the final U position of the CDSHU flags shows an X for
enabled donor update).
ICO-IMG-000584
Figure 71
Donor Update Off SMC Session Control dialog box

185
Figure 72 illustrates invoking the Terminate action from the SMC

Session Control dialog. Notice that the flags in final U position of the
CDSHU flags now shows an . for disabled donor update.
ICO-IMG-000585
Figure 72
Terminate SMC Session Control dialog box
Following the Terminate action confirmation and the Terminate success

dialog, the navigation tree symm_hot_pull session disappears from the
Open Replicator Replication Views.
7.14 Cleanup step 19, redeploy the source devices

Because this example is a hot pull, the key cleanup steps of redirecting
production applications to access the target devices in place of the
source devices was completed in Section 7.10, Migration step 11,
restart applications using targets, on page 179. Step 19, redeploy the
source devices storage, is the only step remaining in the cleanup phase.
186
8
PowerPath Migration
Enabler (PPME) Overview
This chapter defines PowerPath Migration Enabler (PPME) benefits,

terminology and operations. The setup, migration and cleanup phases
are described using the set of steps first defined in Section 3.3, Basic
Open Replicator migration operation flow, on page 52. Because the
PPME interface and capabilities offer significant simplification and
enhancements, some steps are reordered, skipped, merged together, or
split apart; yet the basic flow is still fundamentally the same. The topics
covered include:
8.1 Introduction ...................................................................................

8.2 Benefits of using PPME ................................................................
8.3 Nondisruptive migration overview ...........................................
8.4 Definitions......................................................................................
8.5 PPME considerations and restrictions .......................................
8.6 PPME with Open Replicator migration operation flow..........
8.7 Reference information ..................................................................
188
188
189
191
195
196
202
187
8.1 Introduction
PowerPath Migration Enabler (PPME) is a hybrid migration solution
that provides the ability to perform nondisruptive migrations and
application cutovers while leveraging Open Replicator to actually
migrate the data. PPME benefits data migrations by greatly reducing or
eliminating application disruption due to the migration, reducing
migration risk, and simplifying migration operations.
When migrating data with PPME, the data continues to be accessible to
host applications while the migration takes place. Therefore,
application disruption is minimal or nonexistent. The level of
disruption depends on whether data is being migrated from a pseudo- or
a native-named device, and whether PowerPath is installed on the host.
If PowerPath has not been installed, then a disruption may be required
to install PowerPath.
8.2 Benefits of using PPME

Even if PPME cannot entirely eliminate application outages, it greatly
minimizes them and reduces data migration risk. Complex migrations
almost always will require certain setup activities for the migration that
may involve a host reboot. For example, a migration requirement to
update HBA drivers that requires a host reboot would be executed in a
scheduled maintenance window. The application interruption
necessary for installing PowerPath 5.x (a PPME prerequisite) can also
be scheduled to take place during normal maintenance windows prior
to the actual migration process. There is a great difference between
performing this type of activity as part of a maintenance window and
the more risky procedures that have to be conducted when PPME is not
used. One example of a risky procedure not needed when PPME is used
is the potentially catastrophic cutover outage where a machine is shut
down, a few configuration changes are made, and the machine does not
come back up without issue (note that the risk of this type of outage can
also be minimized with careful planning and by using best practices).
With PPME the cutover task is fully verified before being performed
and can sometimes be conducted fully online. I/O redirection allows
administrators to preview deployment without committing to it. And
with PPME, in all cases, the data remains accessible to host applications
during the migration process.
Eliminating or even just reducing application downtime during a
migration greatly simplifies the planning for large-scale migrations.
Migration window flexibility is important to administrators because it
188
simplifies the migration planning process. Administrators do not have

to rely on others to follow their directions, nor do they need to work off
their shift, which is when migration data movement operations are
frequently scheduled. With PPME, the pressure to correctly complete
critical and complex migration tasks during outages or off hours is
reduced or eliminated.
PPME also greatly simplifies migration operations, hiding the
complexities of underlying migration products and integrating with the
host. This simplification is even more important in providing a
common interface across heterogeneous hosts, eliminating the host
specific knowledge required to perform key migration tasks. The
simplicity that PPME brings to migration operations may even allow
less skilled and less expensive staff to execute the work.
8.3 Nondisruptive migration overview

The PPME powermig command is used to interface with Open
Replicator. Open Replicator hot pull does the bulk data copying
between the arrays through the SAN. PPME keeps source and target
devices synchronized by cloning writes on the host. Mirroring the two
devices allows testing of the migration and returning to the initial state
with no downtime.
Figure 73 on page 190 illustrates an example of PPME Operation with
pseudo-named (location independent) devices and Open Replicator
where PPME swaps the pseudo-named devices in the middle so that
emcpower25c points to the target device instead of the source device
without any change required in the application.
189
Application
Application
Application
PowerPath Filter Driver

emcpower25c
emcpower25c
emcpower25c
emcpower37c
Complete
migration
and remove
old storage
Configure
target
pseudo
devices
OR Copy
SAN
Data
RAID 1
Data
RAID 1
Data
RAID 5
Data
RAID 5
ICO-IMG-000452
Figure 73
190
PPME Operation with pseudo-named devices and Open Replicator
8.4 Definitions
8.4.1 Pseudo or Native device name migrations
The operating system creates native devices to represent and provide
access to logical devices. A native device is path specific (as opposed to
path independent) and represents a single path to a logical device. The
device is native in that it is provided by the operating system for use
with applications. After migrating data from a native device name,
production applications must be reconfigured to use the new
target-device name, which is a minimally disruptive process.
Pseudo device names are location-independent names that represent a
single logical device and the path set leading to it. A
location-independent device name allows the migration of data without
requiring the reconfiguration of applications in order to use a new
logical unit. When data is migrated from one pseudo-named device to
another pseudo-named device, the migration can be nondisruptive. The
example in Chapter 9, PPME with Open Replicator Migration
Example, illustrates a migration from one pseudo device to another.
8.4.2 Source and target

PPME uses the terms source and target to refer to the two endpoints of a
data migration. When Open Replicator hot pull is used for migrations,
the source LUNs are Open Replicator remote devices and the target
LUNs are control devices.
8.4.3 PPME Migration States

A migration session transitions through a number of states as
powermig commands are executed. Figure 74 on page 192 shows the
overall migration workflow, including the sequence of powermig
commands and the corresponding migration states. Numbers one
through eight in the graphic shown in Figure 74 depict the commands
involved in a normal migration workflow. The graphic also shows the
migration states from which you can enter the powermig abort and
powermig cleanup commands.
191
powermig
cleanup
powermig setup
Setup
2
powermig sync
Synching
powermig
abort
Source & target

synchronized
SourceSelected
5
powermig
selectSource
4
powermig
selectTarget
TargetSelected
powermig commit
Source is Pseudo
6
Committed
powermig
cleanup
powermig commit
Source is Native
CommittedAndRedirected
7
powermig undoRedirect
ICO-IMG-000586
Figure 74
PPME Migration states and commands
Table 1 on page 193 describes the PPME Migration states when Open
Replicator is used as the underlying technology, along with the relevant
Open Replicator states.
192
Table 1
PPME Migration states
State
Description
Setup
A migration is in the Setup state after a powermig setup

command completes successfully. Before a migration can enter
this state, synchronization prerequisites must be met. When
Open Replicator is the underlying technology, all requirements
for the create action have been met and the Open Replicator
state is Created.
Syncing
A migration enters the Syncing state when the powermig

sync command initiates a synchronization of the source and
target logical units. When Open Replicator is the underlying
technology, the bulk copy of data from the source to the target
is done in the SAN by Open Replicator in the CopyInProg
state. Application reads are from the source, writes are
mirrored to both source and target by PPME.
SourceSelected
The migration enters the SourceSelected state once the

Open Replicator session has reached the Copied state (or after
powermig selectSource completes). Application reads are
still from the source, while writes continue to be mirrored to
both source and target by PPME.
TargetSelected
The migration transitions to the TargetSelected state after

the powermig selectTarget command completes.
Application reads are now from the target, writes are still
mirrored to both source and target by PPME, making it
possible to return to the SourceSelected state.
CommittedAndRedi The migration enters the CommittedAndRedirected state

rected
after the powermig commit command completes for a
native-named source device. Application reads continue from
the target via redirection, writes are no longer mirrored so it is
not possible to abort the migration. This is intended to be a
short lived temporary state, where production applications
must be stopped. Then the powermig undoRedirect
command is invoked to disable the redirection. Once
applications have been reconfigured to use the target device
paths, they can be restarted.
Committed
The migration enters the Committed state after the powermig

commit command completes for a pseudo-named source
device or after the powermig undoRedirect command for a
native-named source device. Application reads continue from
the target, writes are not mirrored so it is not possible to abort
the migration.
193
8.4.4 PPME Abort, Cleanup, and Recover

A migration can be aborted with the powermig abort command
anytime after entering powermig sync and before entering the
powermig commit command. In other words, a migration can be
aborted while in the Syncing, SourceSelected, or
TargetSelected state. An aborted migration session returns to the
Setup state; from this state the migration can either be restarted
(powermig sync) or it can be cleaned up (powermig cleanup).
The purpose of cleanup is to ensure that production applications
and/or the operating system are not confused by identical data residing
on both the source and target LUNs. The powermig cleanup
command can be run while in the Committed or the Setup state.
When run while in the Committed state, selected data on the source
LUN is removed. When run while in the Setup state (typically after an
abort) selected data on the target LUN is removed. After running this
command the source or target LUN from which selected data has been
removed will not mistakenly be read by the host operating system.
The powermig recover command can be used to recover a migration
after an interruption occurs. Interruptions can result from a migration
error, a process crash, or a device fault. This command should be run
whenever the migration is in the NeedsRecovery state. In the case of a
migration error, the recovery may fail until the cause of the error is
identified and resolved. When the powermig recover command
completes successfully, the migration state changes to the state to which
the session was transitioning when the interruption occurred.
194
8.5 PPME considerations and restrictions

The following restrictions apply to all host platforms when using
PPME:
PowerPath Migration Enabler does not support:

Migrating paging or swapping devices.
Migrating boot devices.
Uninstalling or upgrading PowerPath while a migration is in
progress.
The target LUN:

Must be the same size as or larger than the source logical unit for
Open Replicator migrations.
Cannot be under the control of a volume manager.
Cannot have I/O directed to it.
If the Migration Enabler host uses different HBAs to access the

source and target logical devices, the HBAs must be comparable in
every way (even different revisions of the same HBA are not
permitted).
LUNs involved in a migration should not be used as Symmetrix

gatekeeper devices because I/O redirection will cause gatekeeper
errors. Use of the Solutions Enabler gkavoid or gkselect files can
ensure that migration LUNs are not used as gatekeepers. The EMC
Solutions Enabler Symmetrix Array Management CLI Product Guide
contains more information about gatekeeper devices.
When migrating data to a target LUN that is larger than the source
LUN, the migration must be committed before gaining access to
space on the target that does not exist on the source. Attempting to
access that space when the migration is in the TargetSelected
state will result in I/O errors.
For Solaris hosts the powerformat utility can be used to
increase the size of a LUN by updating the ASCII and disk label
information. More information about powerformat can be
found in the EMC PowerPath Migration Enabler User Guide.
Requires the host be running PowerPath version 5.0 or higher.
195
8.6 PPME with Open Replicator migration operation flow

The eight steps in the normal PPME workflow introduced in Figure 74
on page 192 will be listed and flowcharted using the 19 migration steps
introduced in Section 3.3, Basic Open Replicator migration operation
flow, on page 52 even though steps that apply to cold or push Open
Replicator operations are not applicable. Correctly setting up the
underlying technology is crucial to the successful use of PPME.
For this example using Open Replicator as the underlying technology,
the setup phase steps will directly parallel the previous hot pull
examples. The migration phase steps using Open Replicator are fewer
and simpler because PPME provides for skipping some steps entirely
and delays other steps to the cleanup phase. The cleanup phase steps
will be significantly redefined in order to incorporate the change in
order and greater functionally of PPME in this phase.
8.6.1 Setup steps

The first four setup steps are required in order to set up Open
Replicator for hot pull operations and therefore fully apply when using
PPME with Open Replicator. For some operating systems, it may be
necessary to run explicit powermt commands to update the PowerPath
configuration after making the target devices visible to the host. An
additional sub-step is added to the fourth step, making the first four
setup steps now:
2. Configure/connect migration SAN zone between remote ports
ports.
4a. Configure host zoning and device (LUN) masking for target
devices.
4b. Update and save the PowerPath configuration.
The powermig setup command effectively combines the fifth and
sixth setup steps, though there is no creation of an actual pairs file nor a
user made call to symrcopy create.
SMC GUI).
196

Replicator session.
Figure 75 illustrates the setup steps as a flowchart.
target devices
to remote array
Hot pull?
N
4a. Zone and device mask

4b. Update and save
PowerPath configuration
3. LUN mask remote

devices to DMX FA
5-6. powermig setup

[define source / target
pair, create OR session]
Figure 75
ICO-IMG-000587
PPME with Open Replicator setup steps flowchart
8.6.2 Migration steps

A PPME managed migration has fewer operational steps than a hot pull
migration solely under Open Replicator control. The ability of
PowerPath to redirect I/O allows for less impact on the production
applications and provides more flexibility as to when the migration
change is committed. For example, migration steps 9 and 11 that briefly
stop and restart applications with them pointing to the target devices
are no longer needed prior to the migration, because during the
migration copy, PPME directs all application reads from the source
device, and can transparently manage the redirection of the application
to the target devices after the data movement completes. And because
PPME provides a broader set of cleanup operations, step 15 that
consists of the verification of the migration and termination of the Open
Replicator session is postponed to that phase. With PPME, the
migration steps look like this:
10. powermig sync (activate the Open Replicator session)
12. Tune migration to acceptable level of impact on production
application(optional)
13. powermig query (verify Open Replicator copy session is
finished)
Figure 76 on page 198 illustrates the migration steps as a flowchart.
197
10. powermig sync

[OR activate]
N
Need tuning?

impact level
N
13. powermig query
[Verify OR copy done]
ICO-IMG-000588
Figure 76
PPME migration steps flowchart

Activating each Open Replicator session is accomplished by the
powermig sync command that initiates the copying from source to
target. Although this operation is performed as an Open Replicator hot
pull, with PPME the production applications are still reading from the
source devices rather than the targets. Additionally, the session is not
created with the donor update option enabled because PPME mirrors
all application writes to both source and target devices.
As mentioned in Tuning Open Replicator, on page 60 the PPME
throttle mechanism is an alternate interface to the Open Replicator pace
parameter. However, the pace parameter is the secondary tuning
mechanism for Open Replicator. In order to use the primary tuning
mechanism, the ceiling value can be set using symrcopy set
ceiling or SMC Set Ceiling. The pace value is ignored for all
participating director/port combinations where the ceiling value is not
NONE (including PPME Open Replicator sessions).
The powermig query command is used to report back on the progress
of the background copying. Since the query action must specify a
single PPME handle, it only reports on a single source/target pair. The
powermig info -all -query command, on the other hand can be
used to report on all source/target pairs under PPME control.
198
8.6.3 Cleanup steps

The cleanup steps when using PPME are simple, yet provide extensive
functionality and flexibility that reduce migration risk. The cleanup
step descriptions and ordering are different when PPME uses Open
Replicator, than when Open Replicator is used alone. The final step of
the migration phase and the four cleanup steps introduced in Section
3.3, Basic Open Replicator migration operation flow, on page 52 are:
15. Verify migration is complete and terminate Open Replicator
session.
16. Make the source devices inaccessible to the host
(optional, needed for all but hot pull operations).
17. Make the target devices ready to the host
18. Restart applications pointing to the target devices in place of the
original source devices
complete.
Even though PPME uses Open Replicator hot pull operations to do the
bulk data migration copying, the desired outcomes of steps 16 and 18
are part of the cleanup phase. That is because the switch to having the
production applications read from the target devices is delayed until
this phase.
The PPME commands that fulfill the purpose of steps 15, 16 and 18,
achieves the desired outcomes in different ways that are described in
the next five sections. Step 17 is skipped when using PPME because it
was already completed as step 4 in the setup phase (the same as when
Open Replicator hot pull is used without PPME). Step 19 is very similar
for all of the migration examples presented, though the source devices
can remain configured as visible to the host, since PPME includes
commands that avoid application or operating system confusion that
can be caused by seeing identical data residing on both the source and
target LUNs.
199
8.6.3.1 PPME switch application reading from source or target devices

PPME explicitly includes cleanup operations as part of its command
set. Unlike when using Open Replicator hot pull directly, when used
with PPME, production applications continue to read from the source
device during the migration movement of data. Once the bulk copy is
complete, mirroring to both source and target devices makes it possible
to switch back and forth between reading from source and reading from
target until all validation checks for the migration are complete.
The SourceSelected state defines the condition when source and
target are synchronized and all application reads come from the source.
The PPME command powermig selectTarget can be used to
switch to the TargetSelected state. The TargetSelected state
defines the condition when source and target are synchronized and all
application reads come from the target. The best practice is to conduct
application specific migration verification while in this state (the first
half of step 15). The PPME command powermig selectSource can
be used to switch back to the SourceSelected state. The ability to
switch back and forth between the source and target devices is
performed transparently to the production applications.
8.6.3.2 PPME transparently committing to the target devices
When using pseudo-named source devices and while in the
TargetSelected state, the PPME command powermig commit can
be used to switch to the Committed state. When this operation is
performed, production applications transparently continue to operate
using the target devices, that now use the pseudo-names previously
used for the source devices. Unlike the selectTarget or
SelectSource actions, the commit action is permanent because write
mirroring is stopped, making the source devices no longer valid for
production application use. This move of application processing to the
target devices effectively completes step 18 without any application
restart.
8.6.3.3 PPME cleanup of the source devices
While in the Committed state, the PPME command powermig
cleanup can be used to remove selected data from the source LUN.
This removal ensures that production applications or the operating
system are not confused by identical data residing on both the source
and target LUNs. Avoiding this potential confusion meets the purpose
of step 16 and can make step 19, redeploying the source devices easier
200
because they are still configured to be visible to the host. The cleanup
operation also terminates the Open Replicator session, thereby
completing the second half of step 15.
8.6.3.4 PPME commit for native-named source devices
When using native-named source devices, it is not possible to
transparently direct all production application I/O to the target devices
on a permanent basis. The native-names specifically reference the
physical path to the source devices and therefore cannot be used to
permanently reference different paths to the target devices.
When using native-named source devices and while in the
TargetSelected state, the PPME command powermig commit can
be used to switch to the CommittedAndRedirected state. With this
operation, the production applications transparently continue to
operate using the target devices, via temporary I/O redirection. The
commit action is permanent because write mirroring is stopped,
making the source devices no longer valid to use for production
applications. Applications can continue to run referencing the target
devices in this manner until it is convenient to briefly stop them. The
powermig undoRedirect command is then used to disable the I/O
redirection. Then, production applications must be reconfigured to use
the target device paths, and then be restarted. Cleanup of the source
devices should then be completed as described in Section 8.6.3.3,
PPME cleanup of the source devices , on page 200. This move of
application processing to the target devices effectively completes step
18.
8.6.3.5 PPME abort and cleanup of the target devices
At any time during the migration data movement or migration
validation testing, the powermig abort command can be executed
provided the commit operation has not been executed. The abort
operation leaves the migration in the Setup state, and from there the
migration can either be restarted or cleaned up. From the Setup state,
the PPME command powermig cleanup command can be used to
remove selected data from the target LUN. This removal ensures that
production applications and/or the operating system are not confused
by identical data residing on both the source and target LUNs.
201
Figure 77 illustrates the PPME cleanup steps as a flowchart. The

multiple parts of step 18 and notes referring to step 15 and 16 appear
out of numeric order due to representing the PPME operational flow
using the step definitions for migration steps conducted without PPME
from Section 3.3, Basic Open Replicator migration operation flow, on
page 52.
18a. powermig selectTarget
migration check validation
(step 15, first half)
Abort?
Abort processing
detail not
included in this
flowchart
18b. powermig commit
Native-named
source devices?
18c. Stop applications
N
16. powermig cleanup
avoid source device conflicts
OR terminate (step 15,
second half)
18d. powermig undoRedirect

storage
Figure 77
ICO-IMG-000589
PPME cleanup steps flowchart
8.7 Reference information

Additional details for PPME can be found in the EMC PowerPath
Migration Enabler User Guide. Users should upgrade to the latest version
in order to get the latest features and performance improvements.
Details of PPME support for pseudo and native devices can be found in
the E-Lab Interoperability Navigator available on the Powerlink
website (http://Powerlink.EMC.com).
202
9
PPME with Open Replicator
Migration Example
This chapter details a PPME with Open Replicator migration example

that uses the same arrays, hosts and devices as those used in Chapter 7,
Hot Pull from Symmetrix Migration Example. The setup, migration,
and cleanup steps defined for PPME in Chapter 8, PowerPath
Migration Enabler (PPME) Overview,will be clarified by a migration
example. The topics covered include:
9.1 Introduction .................................................................................... 204

9.2 PPME Setup steps 1-4 .................................................................... 205
9.3 PPME Setup steps 5-6, powermig setup..................................... 205
9.4 Migration step 10, powermig sync .............................................. 210
9.5 Migration step 12, tune migration .............................................. 211
9.6 Migration step 13, query status, until SourceSelected.............. 212
9.7 Migration step 18a, powermig selectTarget............................... 214
9.8 Migration step 18b, powermig commit ...................................... 215
9.9 Migration step 16, powermig cleanup ........................................ 217
9.10 Migration step 19, redeploy source devices storage ............... 217
203
9.1 Introduction
This chapter details a PPME with Open Replicator migration example
that uses the same Windows host, source devices (141-144) and target
devices (95-98) as those used in Chapter 7. The applicable migration
steps defined for PPME in Chapter 8 apply for this example, so the list
of steps required to perform the migration is not repeated here.
However, the migration steps flowchart for all three phases is shown in
Figure 78 on page 204.
target devices
to remote array
3. LUN mask remote
devices to DMX FA
Hot pull?
N
5-6. powermig setup

[define source / target
pair, create OR session]
4a. Zone and device mask

4b. Update and save
PowerPath configuration
10. powermig sync

[OR activate]
N
Need tuning?

impact level
N
13. powermig query
[Verify OR copy done]
18a. powermig selectTarget
migration check validation
(step 15, first half)
Abort?
Abort processing
detail not
included in this
flowchart
18b. powermig commit
Native-named
source devices?
18c. Stop applications
N
16. powermig cleanup
avoid source device conflicts
OR terminate (step 15,
second half)
18d. powermig undoRedirect

storage
Figure 78
204
ICO-IMG-000594
PPME with Open Replicator setup, migration, and cleanup steps
9.2 PPME Setup steps 1-4

Since PPME will also use an Open Replicator hot pull for the bulk data
copy, the setup steps 1-4 are identical to the way they were performed
in Chapter 7, Hot Pull from Symmetrix Migration Example, therefore
these operations will not be repeated in this example. The PPME with
Open Replicator operational flowchart adds a step 4b, to update and
save the PowerPath configuration. This step was not necessary in the
example presented here. An example of completing this step on a
Solaris host is:
# powermt config
# powermt save
#
9.3 PPME Setup steps 5-6, powermig setup

The session concept available with symrcopy and the SMC interface
for Open Replicator provides a convenient user interface to work with
multiple pairs of devices as a single unit. In the Symmetrix array, each
control/remote pair in the same session is actually independent of each
other. The PPME interface does not provide for a way to group multiple
pairs of devices as a single unit. Each source/target pair is controlled
individually with a separate handle assigned to each pair. Therefore
there is no need to create a pairs file; instead each source and target
device pair is defined on the command line of the setup action. For
this example, each device must be identified using a PowerPath pseudo
device name because the Windows operating system only supports
pseudo device names. In other environments, native device names can
be used as well.
205
9.3.1 Identify source and target pseudo device names

The physical names for the source devices used can be displayed using
the following Solutions Enabler command:
c:\>symdev list -sid 450 -range 141:144
Device Name
Directors
Device
------------------------- ------------- ------------------------------Cap
Sym Physical
SA :P DA :IT Config
Attribute Sts (MB)
------------------------- ------------- ------------------------------0141
0142
0143
0144
\\.\PHYSICALDRIVE29
\\.\PHYSICALDRIVE30
\\.\PHYSICALDRIVE31
\\.\PHYSICALDRIVE32
09C:0
09C:0
09C:0
08C:0
02C:C3
01C:C4
02B:C4
15C:C4
2-Way
2-Way
2-Way
2-Way
Mir
Mir
Mir
Mir
N/Grp'd
N/Grp'd
N/Grp'd
N/Grp'd
RW
RW
RW
RW
4096
4096
4096
4096
c:\>
However, the PowerPath pseudo device names for Windows uses the
format harddiskXX, that can be seen when displaying the PowerPath
devices:
c:\>powermt display dev=all
. . .
Pseudo name=harddisk29
Symmetrix ID=000187720450
Logical device ID=0141
state=alive; policy=SymmOpt; priority=0; queued-IOs=0
=======================================================================
--------------- Host ----------- - Stor - I/O Path - -- Stats --### HW Path
I/O Paths Interf.
Mode
State Q-IOs Errors
=======================================================================
2 port2\path0\tgt1\lun16 c2t1d16 FA 9cA active dead
0
1
2 port2\path0\tgt3\lun16 c2t3d16 FA 9cA active alive
0
0
4 port4\path0\tgt1\lun16 c4t1d16 FA 8cA active dead
0
1
4 port4\path0\tgt3\lun16 c4t3d16 FA 8cA active alive
0
0
. . .
. . .
. . .
206
Similarly, the target physical device names can be displayed:

c:\>symdev list -sid 359 -range 95:98
Device Name
Directors
Device
------------------------- ------------- ------------------------------Cap
Sym Physical
SA :P DA :IT Config
Attribute Sts (MB)
------------------------- ------------- ------------------------------0095 \\.\PHYSICALDRIVE15 15C:0 01B:C5 2-Way Mir N/Grp'd
RW
4096
0096 \\.\PHYSICALDRIVE16 15C:0 16A:D8 2-Way Mir N/Grp'd
RW
4096
0097 \\.\PHYSICALDRIVE17 15C:0 16B:CC 2-Way Mir N/Grp'd
RW
4096
0098 \\.\PHYSICALDRIVE18 15C:0 16A:CD 2-Way Mir N/Grp'd
RW
4096
c:\>
Since the format of the pseudo device names is known, it is not

necessary to use the powermt display command to see the
hardiskXX format. For example, target device 95 has a physical device
name ending in 15, therefore specifying the pseudo device name
harddisk15 explicitly can yield a check that it does indeed point to
Symmetrix device 95:
c:\>powermt display dev=harddisk15
. . .
9.3.2 PPME license required

In addition to the Solutions Enabler Open Replicator/LM license,
PowerPath Migration Enabler requires a specific license for data
migrations using Open Replicator. Issuing a valid PPME command
without the required license will result in an
error. The required license can be added using the PowerPath license
registration command emcpreg:
c:\>powermig setup -techType OR -src harddisk24 -tgt harddisk15 -noprompt
PPME error(15): Required license is missing or expired
c:\>emcpreg -add NN#N-NNN#-NNNN-NN#N-NNNN-NNNN

Success: License added
c:\>
207
9.3.3 PPME powermig setup

The setup action requires the underlying technology to be specified;
OR is used to signify Open Replicator. Many of the powermig
command arguments have two and three character abbreviations: src
for source, tgt for target, and no for noprompt. The source and
target pseudo device names are specified to define the pair and a
numeric handle is returned to use for subsequent powermig
commands:
Migration Handle = 1
c:\>powermig setup -techType OR -src harddisk25 -tgt harddisk16 -no

c:\>powermig setup -techType OR -src harddisk26 -tgt harddisk17 -no


c:\>
The powermig info -all command can be used to report on all

source/target pairs under PPME control. Notice that the four
source/target pairs used in this example are in the setup state.
c:\>powermig info -all
========================================
Hnd Source
Target
Tech State
=== ========== ========== ==== =====
1 harddisk24 harddisk15
OR setup
OR setup
OR setup
OR setup
c:\>
208
The setup action issues the Open Replicator create command, so the
successful setup state confirms that the create was successful,
verifying that all of the required Open Replicator setup steps have been
completed. Even though the powermig command is used to control
this migration, it is still possible to view Open Replicator status directly
using symrcopy or SMC. In the following example, notice the
following flag values: C(opy) is set, (pu)S(h) is reset indicating a pull,
H(ot) is set, and (donor)U(pdate) is reset:
c:\>symrcopy -sid 359 list
Control Device
--------------Protected
Sym
Tracks
----- --------0095
65535
0096
65535
0097
65535
0098
65535
Remote Device
Flags
Status
Done
----------------------------- ----- -------------- ---Identification
-------------------------000187720450:0141
000187720450:0142
000187720450:0143
000187720450:0144
RI
-SD
SD
SD
SD
CDSHU
----X..X.
X..X.
X..X.
X..X.
CTL <=> REM

(%)
-------------- ---Created
N/A
Created
N/A
Created
N/A
Created
N/A
Total --------Tracks 262140

MB(s) 16383.8
Legend:
I:

Flags:
(C): X =
. =
(D): X =
. =
(S): X =
. =
(H): X =
. =
(U): X =
. =
(*): The

c:\>
209
9.4 Migration step 10, powermig sync

Activating Open Replicator sessions is accomplished by executing the
powermig sync command, that initiates the copying from source to
target.
c:\>powermig sync -handle 1 -noprompt
c:\>
210
9.5 Migration step 12, tune migration

The PPME throttle mechanism is an alternate interface to the Open
Replicator pace parameter. The following example of powermig help
shows how to get the syntax detail for the throttle action:
c:\>powermig help throttle
throttle - used for altering the speed of a migration
Usage:
powermig throttle -handle <handle> -throttleValue <value> -suspendTime <valu
e>
c:\>
The -suspendTime option is not applicable when using Open

Replicator as the underlying technology. In this example, the ceiling
values set for the Symmetrix control FA ports in earlier are still in effect.
The throttle value is ignored for all participating director/port
combinations where the ceiling value is not NONE. The following
command can be used to display the current ceiling settings:
c:\>symrcopy -sid 359 list ceiling
Dir:P
----01C:0
01C:1
02C:0
02C:1
15C:0
15C:1
16C:0
16C:1
Max
(MB)
---150
150
150
150
150
150
150
150
Set
(%)
---NONE
NONE
30
NONE
30
NONE
NONE
NONE
Actual
(MB)
-----0
0
0
0
0
0
0
0
c:\>
211
9.6 Migration step 13, query status, until SourceSelected

This step consists mostly of waiting until the underlying technology,
Open Replicator copy, completes copying all of the tracks from the
source devices to the target devices.
The powermig query command is used to report back on the progress
of the background copying. The query action must specify a single
PPME handle, and thus can only report on a single source/target pair.
In the following example, notice the PPME Migration state is now
syncing and the Percent InSync is up to 1 percent.
c:\>powermig query -handle 1
Handle: 1
Source: harddisk24
Target: harddisk15
Technology: OR
Migration state: syncing
Percent InSync: 1%
Throttle Value: 5
c:\>
The powermig info command has an -all option, that can be used
to list the status for all PPME source/target pairs in a single command.
Additionally, the -query option can be specified to include the
percent InSync values:

==========================================
Hnd Source
Target
Tech State
=== ========== ========== ==== =======
OR syncing
OR syncing
OR syncing
OR syncing
c:\>powermig info -all -query

==============================================
Hnd Source
Target
Tech State
=== ========== ========== ==== ===========
OR syncing(1%)
OR syncing(1%)
OR syncing(1%)
OR syncing(1%)
c:\>
212
After waiting long enough, the bulk Open Replicator copy will
complete and the sessions will be in the Open Replicator Copied state.
As shown in this example, the Open Replicator Copied state is
reflected in the PPME sourceSelected state:
c:\>powermig info -all -query
=================================================
Hnd Source
Target
Tech State
=== ========== ========== ==== ==============
OR sourceSelected
OR sourceSelected
OR sourceSelected
OR sourceSelected
c:\>
When using PPME, the sourceSelected state is an indicator that the

data transfer is complete. The next set of operations are part of the
robust cleanup steps introduced in Section 8.6.3, Cleanup steps, on
page 199. These steps are presented in a typical PPME sequence, but
the titles are not numerically in order, since the step numbers are based
on the Open Replicator examples presented previously.
213
9.7 Migration step 18a, powermig selectTarget

The PPME command powermig selectTarget is used to switch to
the targetSelected state. The targetSelected state defines the
condition when source and target are synchronized and all application
reads come from the target. The following commands are used to enter
the targetSelected state and display that status:
c:\> powermig selectTarget -handle 1 -noprompt

=================================================
Hnd Source
Target
Tech State
=== ========== ========== ==== ==============
OR targetSelected
OR targetSelected
OR targetSelected
OR targetSelected
c:\>
A best practice is to conduct application specific migration verification

while in this state (the first half of step 15). As part of the verification
process it is possible to switch back and forth between the
sourceSelected and targetSelected states; such switching is
transparent to the production applications. If the migration does not
meet the migration verification criteria, it can be aborted, then restarted
or completely cleaned up. If the migration verification criteria are met,
then it is time to commit the migration to using the target devices.
214
9.8 Migration step 18b, powermig commit

For this example on a Windows host, pseudo-named source devices are
in use, providing for a transparent, single step commit. If native devices
were in use, two powermig command actions would be necessary,
along with stopping applications in between and reconfiguring them to
reference the target devices in place of the source devices as described
in Section 8.6.3.4, PPME commit for native-named source devices, on
page 201.
The PPME command powermig commit can be used to switch to the
Committed state:
c:\>powermig commit -handle 1 -noprompt

============================================
Hnd Source
Target
Tech State
=== ========== ========== ==== =========
OR committed
OR committed
OR committed
OR committed
c:\>
215
The production applications can now transparently continue to operate

using the target devices on a permanent basis, because PPME has
swapped the pseudo-names used for source and target devices. This
change in pseudo-names can be seen by comparing the powermt
display output from before the commit (Section 9.3.1, Identify
source and target pseudo device names, on page 206) with the output
after the commit shown below. Previously, source devices 141-144 used
pseudo-names were hardisk29 to hardisk32. Now, the target
devices 95-98 use pseudo-names hardisk29 to hardisk32.
c:\>powermt display dev=all
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
216
9.9 Migration step 16, powermig cleanup

While in the Committed state, the PPME command powermig
cleanup should be used to remove selected data from each source
LUN, ensuring that production applications and/or the operating
system are not confused by identical data residing on both the source
and target LUNs. The help for the cleanup action shows that the
-format option could be used in this example to perform a full disk
format on the source LUN.
c:\>powermig help cleanup
cleanup - Cleanup after a migration.
Usage:
powermig cleanup -handle <handle> [-format] [-force]
c:\>powermig cleanup -handle 1 -noprompt
c:\>
The cleanup action deletes the PPME migration information and

terminates the Open Replicator session, as shown by the following
command actions:
No migrations found.
c:\>symrcopy -sid 359 list
No Devices with RCopy sessions were found.
c:\>
9.10 Migration step 19, redeploy source devices storage

Step 19 is very similar for all of the presented migration examples.
However in this example, because of the cleanup action, the source
devices can remain configured as being visible to the host.
217
218
A
Open Replicator
Performance Tuning
The purpose of this appendix is to consolidate, expand and elaborate

on the performance tuning information included in the earlier chapters
of this TechBook. The topics covered include:
A.1 Two goals of Open Replicator tuning ....................................

A.2 Resource conflicts .....................................................................
A.3 Limiting Open Replicator resource usage.............................
A.4 Migration options can impose performance delays ............
A.5 Tuning Open Replicator...........................................................
A.6 Monitoring Open Replicator performance............................
A.7 Tuning for applications sensitive to response time .............
220
220
221
222
223
225
230
219
A.1 Two goals of Open Replicator tuning

Open Replicator tuning is a matter of balancing two possibly conflicting
goals. Usually, the most important goal of Open Replicator tuning is to
ensure that the data migration does not unacceptably impact the
simultaneously running production applications. The secondary goal is
to ensure that the data migration completes within the planned
window for the migration. These goals will conflict when the number of
resources needed to meet the migration window goal results in
undesired impact to production applications.
A.2 Resource conflicts

Open Replicator impact on production application performance is
mainly a result of I/O resource conflict. There might also be some CPU
impact when Open Replicator management is executed on the
application host.
A.2.1 I/O resource paths

The production application I/O path goes from the:
Production Host I/O Queue HBA SAN Source Array
except in the case of a hot pull, when the production I/O is redirected to
the Target Array.
The Open Replicator migration I/O path goes from the:
Source ArraySANTarget Array
A.2.2 Array I/O conflicts

In the case of a push migration, both the production and migration
applications utilize resources in the source storage array (the control
Symmetrix V-Max or Symmetrix DMX array). In the case of hot pull
migration, both the production and migration applications utilize
resources in the target storage array (the control Symmetrix V-Max or
Symmetrix DMX array). The key contended resource in the storage
array I/O path is the control Symmetrix V-Max (or Symmetrix DMX)
front-end fibre director (FA) that connects the array to the host through
the SAN. When the FA is used for both production and migration
resources, there is conflict when there is not enough excess capacity to
meet both demands fully. And even if there is enough capacity to meet
the dual demands, there is still queuing conflicts when competing
requests arrive simultaneously. One request will be serviced first, while
220
the other must wait resulting in an extended service time. Within the
Symmetrix V-Max (or Symmetrix DMX) there also will be competition
for cache memory and back-end disk I/O, however this competition
has less impact due to the asynchronous nature of performance impact
in an integrated cached disk array (ICDA). Performance tuning
approaches for Open Replicator cache memory and back-end disk I/O
are not any different than tuning for these resources with other
applications.
A.3 Limiting Open Replicator resource usage

A.3.1 Using a separate management host
As a SAN-based migration product, Open Replicator avoids I/O
conflicts at the production host. The command management I/O for
Open Replicator uses a very small amount of production host I/O
resources if executed on the production host. For this reason (and to
avoid similarly low impact CPU utilization) sometimes Open
Replicator migration is directed from a separate management host. The
Open Replicator management CPU and I/O resource usage is probably
too small to have a significant impact, so the use of a separate
management host is typically a result of conforming to site defined
practices. Note that certain cleanup migration phase steps can only be
executed on the production host. Correspondingly, PowerPath
Migration Enabler (PPME) needs to be executed on the production host.
A.3.2 Limiting Symmetrix FA director competition

Given that both production and migration applications are contending
for FA resources, tuning FA performance is a matter of limiting one
application's I/O requests to the benefit of the other. Most migrations
will actually employ multiple strategies to achieve this.
One principle strategy involves scheduling. Often, the migration
window is during a lower production application resource usage
period. Scheduling the migration at this time has the double benefit of
more resources being available for the migration while the impact on
the production application is less critical. Depending on the length of
the migration window, and the consequence of production application
slowdowns during this period, it may be possible to tune the migration
to use even more resources in order to complete the migration within
the migration window timeframe.
221
A second strategy involves using independent FA resources to permit

both production and migration applications to avoid resource
contention with each other, though each still may not find its
independent resources sufficient to avoid performance issues. Only
Open Replicator cold migrations can fully utilize this strategy. Open
Replicator hot migrations require all FA directors that are mapped to
the control devices to be configured to support Copy on First
Access/Write (COFx) operations. The ceiling setting can be used to
limit Open Replicator hot migration I/Os to only COFx I/Os.
A third strategy involves limiting one application's FA I/O requests to
the benefit of the other. Whether this can be done by production
applications is beyond the scope of this TechBook. As introduced in
Tuning Open Replicator, on page 60 the Open Replicator I/O
requests can be limited through setting the ceiling value, setting the pace
value and temporarily disabling background copying.
A.4 Migration options can impose performance delays

Certain Open Replicator migration configurations result in systemic
performance delays in return for a desired feature. For example, hot
migration COFx activity means that the production I/O is delayed until
the migration copy operation preserving the activate point-in-time
completes first. This delay can be avoided by using a cold migration
configuration. This delay can be minimized in the case of hot push, by
using the -precopy option to reduce the number of tracks not yet
copied to the remote requiring COFW I/Os (Note: precopy requires
Enginuity 5772 or higher). Hot pull migrations that utilize the
-donor_update option also have a systemic performance delay of
copying the write I/Os to the remote before allowing the production
write to the control to complete.
222
A.5 Tuning Open Replicator

Open Replicator performance can be tuned by static configuration
choices or using dynamic commands both before and during a
migration to set ceiling, pace or nocopy mode.
A.5.1 Static configuration limits on Open Replicator resource use

The goal of static configuration for performance is to separate the FA
director resources used by Open Replicator migrations from production
applications. If the Symmetrix V-Max (or Symmetrix DMX) has enough
FA director ports, then Open Replicator cold migrations can be
configured to use independent FA director ports. This can be achieved
by mapping the control devices to one or more FA director ports not
used by production applications. Then, these migration control FA
director ports would be zoned and LUN masked to see the remote array
directors and devices. If there are no free FA director ports, then cold
migrations can be configured to use a subset of the FA director ports
used by production applications, thus limiting the FA director ports
where there is competition for resources.
For hot migration configurations, it is still possible to partially achieve
the use of independent FA director ports. The static configuration part
is the same as for cold migrations - mapping the control devices to one
or more FA director ports not used by production applications.
However, hot migration configurations require all control FA director
ports to be zoned and LUN masked for COFx access, thus all of the
production application FA director ports must be configured for Open
Replicator use. Fortunately, the ceiling setting can be used to severely
limit the use of the shared FA director ports. Setting the ceiling value to
zero percent means that a FA director port will not be used for any
background copy migration operations; it will only be used for COFx
activity as needed.
A.5.2 Dynamic limits on Open Replicator resource use

Open Replicator provides three alternatives for limiting Open
Replicator use of shared FA director ports that can be changed before
and during a migration: the ceiling parameter which limits fibre
bandwidth that can be used by Open Replicator, the pace parameter
which defines delays added between Open Replicator operations, and
the nocopy mode which suspends Open Replicator background copy
activity.
223
A.5.2.1 Ceiling
The ceiling parameter is the primary and most predictable tuning

mechanism because it directly sets a maximum FA director port
bandwidth that can be used by Open Replicator. The default ceiling
value is NONE, theoretically allowing Open Replicator to use up to 100
percent of the FA port bandwidth. Setting the ceiling value to any value
less than 100 percent limits the potential Open Replicator use of the FA
port, and overrides any setting of the pace value. This value can be set
prior to the migration or changed at any time during the migration. A
command can be used to set the same ceiling value for all FA ports, or
the ceiling value for each FA port can be set independently. If the
production applications have time of day or week variations that might
tolerate or suffer more from a higher contention for resources at certain
times, then the ceiling value can be dynamically adjusted. Note that the
command that lists ceiling values, also displays the current Open
Replicator use of bandwidth, effectively reporting whether all the
capacity up to the current ceiling value is actually being used.
A.5.2.2 Pace
The pace parameter limits the use of all FA ports used for a particular
Open Replicator session by inserting delays between Open Replicator
I/O requests. Although this effectively limits use of the FA port, it also
guarantees that the migration will take longer, even if there is spare
capacity in the FA port. The range of valid values is from 0 to 10, with a
default value of 5. A pace setting of zero does not insert any delay. A
value of 10 inserts the maximum delay. The parameter value can be
displayed using the -detail option with the query or list actions.
The PPME throttle setting is an alternate interface to the Open
Replicator pace setting. The pace value is ignored for all participating
director/port combinations where the ceiling value is not NONE.
A.5.2.3 Nocopy
mode
The ability to dynamically switch an Open Replicator session into

nocopy mode provides a simple way to temporarily suspend all but
COFx migration I/O requests. The most common use of nocopy mode is
to initially set a hot pull session in nocopy mode so that initial high
COFA I/O is not joined by any background copy I/O. This setting has
to be temporary because it is necessary to set the mode back to
background copy in order for the migration to complete with all tracks
copied to the target. The current mode setting can be determined by
interpreting the C flag setting displayed in the output of the query or
list actions.
224
A.6 Monitoring Open Replicator performance

For this monitoring session, a hot push session using the same devices
as in Section 7.6, Setup step 5, prepare Open Replicator session pairs
file, on page 166 was created with ceiling set to 10 percent.
A.6.1 symrcopy query

Open Replicator performance can be monitored using the symrcopy
query command or SMC equivalent as shown in previous chapters.
The change from one query output to the next can be used as a
performance measure combined with elapsed time. The decrease in the
number of Protected Tracks, or the increase in Done % are the
changing values. For example, soon after activating the session, the
query output could look something like this:
c:\>symrcopy -session hot_push query
Session Name
: hot_push
Control Device
--------------------------Protected
SID:symdev
Tracks
----------------- --------000190300359:0098
65072
000190300359:0097
64862
000190300359:0096
64752
000190300359:0095
64862
Total
Track(s)
. . .
Remote Device
Flags
Status
Done
--------------------- ----- ---------- ---Identification
-----------------000187720450:0144
000187720450:0143
000187720450:0142
000187720450:0141
RI
-SD
SD
SD
SD
CDSHU
----XXXX.
XXXX.
XXXX.
XXXX.
CTL<=>REM (%)
---------- ---CopyInProg
0
CopyInProg
1
CopyInProg
1
CopyInProg
1
--------259548
225
A.6.2 symrcopy list ceiling

The output of symrcopy list ceiling can be used to show the
actual MB/sec used by Open Replicator for each director. In the
example below, the ceiling setting for directors 2C:0 and 15C:0 is 10
percent. The maximum MB/sec for each FA director port is 150
MB/sec. The actual MB/sec displayed in the example is 15 and 14
MB/sec, equivalent within rounding error to 10 percent of 150 MB/sec
or 15 MB/sec. Therefore in this case the ceiling setting is limiting the
Open Replicator throughput.
c:\>symrcopy -sid 359 list ceiling
Dir:P
----01C:0
01C:1
02C:0
02C:1
15C:0
15C:1
16C:0
16C:1
Max
(MB)
---150
150
150
150
150
150
150
150
Set
(%)
---NONE
NONE
10
NONE
10
NONE
NONE
NONE
Actual
(MB)
-----0
0
15
0
14
0
0
0
c:\>
226
A.6.3 symstat with -RepType rcopy

The symstat command has three status actions that use the Open
Replicator specific -RepType rcopy option. The first example uses
the -type REQUESTS option. The short interval of 10 seconds (-i 10)
and count of 3 (-c 3) quickly generate two sets of calculated delta
output. Best practice would use a much longer interval to both provide
more meaningful data and to avoid more frequent polling for
performance data than really necessary. Notice the values for PUSH
KB/sec for each of the four control devices.
c:\>symstat -type REQUESTS -sid 359 -reptype rcopy -i 10 -c 3
RCopy
-------------KB/sec
PULL
PUSH
Device
14:19:11
14:19:21
0095
0096
0097
0098
(DRIVE15)
(DRIVE16)
(DRIVE17)
(DRIVE18)
0
0
0
0
8908
9414
5804
6457
14:19:31
0095
0096
0097
0098
(DRIVE15)
(DRIVE16)
(DRIVE17)
(DRIVE18)
0
0
0
0
9664
8857
5798
5817
c:\>
The second symstat example uses the -dir ALL option, which could
also have specified an individual director. Notice the Open Replicator
cache usage for directors 2C and 15C.
c:\>symstat -dir all -sid 359 -reptype rcopy -i 10 -c 3
RCopy
14:19:38
Cache Requests/sec
Director
MB/sec
%RW
READ
WRITE
RW
Hits
14:19:49
FA-1C
FA-2C
FA-15C
FA-16C
0
14
14
0
-----28
0
0
0
283
0
283
280
0
280
0
0
0
------ ------ -----563
0
563
N/A
71
69
N/A
--139
14:19:59
FA-1C
FA-2C
FA-15C
FA-16C
0
15
14
0
-----29
0
0
0
275
0
275
276
0
276
0
0
0
------ ------ -----551
0
551
N/A
45
43
N/A
--87
c:\>
227
The third symstat example uses the -type PATH option, which has
two sorting options; -by_session is used here. Notice the total and
remaining tracks to be copied per device.
c:\>symstat -type path -sid 359 -reptype rcopy -i 10 -c 2 -by_session
Time
Stamp
Session
Name
Control
Device
Target
Destination
14:20:49
hot_pu*
0095
hot_pu*
0096
hot_pu*
0097
hot_pu*
0098
000187720450:0141
N/A
000187720450:0142
N/A
000187720450:0143
N/A
000187720450:0144
N/A
Time
Stamp
Session
Name
Control
Device
Target
Destination
14:20:59
hot_pu*
0095
hot_pu*
0096
hot_pu*
0097
hot_pu*
0098
000187720450:0141
N/A
000187720450:0142
N/A
000187720450:0143
N/A
000187720450:0144
N/A
Tracks
Director RCopy
Total Remaining
Port Ceiling
65535
65535
65535
65535
65535
65535
65535
65535
51048
51048
50995
50995
54568
54568
54708
54708
FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
Tracks
Director RCopy
Total Remaining
Port Ceiling
65535
65535
65535
65535
65535
65535
65535
65535
49689
49689
49696
49696
53567
53567
53556
53556
FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
FA-2C:0
FA-15C:0
c:\>
228
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
The fourth symstat example again uses the -type PATH option, this
time using the -by_port sorting option. In addition to the total and
remaining tracks to be copied per device, the MB/sec transfer rate is
listed for each director port.
c:\>symstat -type path -sid 359 -reptype rcopy -i 10 -c 2 -by_port
Time
Stamp
Director
Port
14:21:04
FA-2C:0
FA-15C:0
RCopy
Ceiling
Port
MB/sec
RCopy
MB/sec
10
10
Port
MB/sec
RCopy
MB/sec
Time
Stamp
Director
Port
RCopy
Ceiling
14:21:14
FA-2C:0
10
11
15
FA-15C:0
10
12
14
Control
Tracks
Device Total Remaining
0095
0096
0097
0098
0095
0096
0097
0098
49153
49054
53014
53000
49153
49054
53014
53000
hot_pu*
hot_pu*
hot_pu*
hot_pu*
hot_pu*
hot_pu*
hot_pu*
hot_pu*
Control
Tracks
Device Total Remaining
Session
Name
0095
0096
0097
0098
0095
0096
0097
0098
65535
65535
65535
65535
65535
65535
65535
65535
Session
Name
65535
65535
65535
65535
65535
65535
65535
65535
47598
47818
52000
51978
47598
47818
52000
51978
hot_pu*
hot_pu*
hot_pu*
hot_pu*
hot_pu*
hot_pu*
hot_pu*
hot_pu*
c:\>
229
A.7 Tuning for applications sensitive to response time

In order to maintain the activate point-in-time, Open Replicator hot
migration COFx I/Os will occur even if background copy migration
activity is already using the allowed ceiling percentage of FA port
bandwidth. An example of a production application that is sensitive to
response time is MicroSoft Cluster Server (MSCS). MSCS performs
frequent SCSI reservation queries on its LUNs, to ensure that the active
nodes still have SCSI reservations on the LUNs in order to prevent a
split brain cluster. If a particular active MSCS node sees that it has lost
its SCSI reservation, or does not receive an acknowledgement that it
still has a reservation quickly enough, it will take its resources offline to
prevent data corruption due to a split brain. Excessive COFx activity on
FA ports that do not have enough bandwidth can slow down these SCSI
reservation responses to a point that MSCS will go offline.
The Open Replicator migration use of bandwidth can be mitigated with
a number of tuning strategies. For hot push, precopy should be utilized
reducing COFW I/Os at activate time. Sessions should initially be in
nocopy mode, and only switched to background copy mode, once COFx
activity starts to slow down. Start with a relatively low ceiling (15-20%),
and then gradually increase the ceiling, keeping a close watch on host
I/Os per second (IOPS) and response time avoiding allowing Open
Replicator to affect the production applications' response times too
much.
230
B
Troubleshooting
This appendix provides log information that correlates with the

examples presented in chapters 4-9. Log examples are shown for
commands resulting in both success and failure. Also included is an
example of an Enginuity 5773 enhancement of Open Replicator that
enables reactivating a failed differential push session. The topics
covered include:
B.1 Solutions Enabler logs...............................................................

B.2 Audit Log....................................................................................
B.3 PowerPath Migration Enabler (PPME) logs ..........................
B.4 Reactivate Failed Session..........................................................
Troubleshooting
232
239
241
244
231
Troubleshooting
B.1 Solutions Enabler logs

The Solutions Enabler log directory is a subdirectory of the working
solutions enabler directory. If the default directories were used for
Solutions Enabler installation, the logs can be found in:
UNIX:
/var/symapi/log
Windows
C:\Program Files\EMC\SYMAPI\log
Inside the log directory, there are two log file types related to this
TechBook: symapi-YYYYMMDD.log and symntctl-YYYYMMDD.log.
B.1.1 Cold push example log entries

For example, the log entries related to operations in Chapter 4, Cold
Push to CLARiiON Setup Example, and Chapter 5, Cold Push to
CLARiiON Migration Example, are displayed in the next eight
subsections.
232
Troubleshooting
B.1.1.1 Open Replicator create and not_ready control devices

The following excerpt from the symapi-20080618.log and
symapi-20080619.log corresponds to the example shown in Section
4.6.5, Verify all with symrcopy create, on page 79:
06/18/2008 16:17:03.854
1896
1 EMC:SYMRCOPY
SymRemoteCopyControl STARTING a REMOTE Copy CREATE
(PUSH) (COLD)
06/18/2008 16:17:03.854
1896
1 EMC:SYMRCOPY
validateCreate
Cannot CREATE (COLD) session on
dev:00A0, sid:000190300359, it is not NR
06/18/2008 16:17:03.854
1896
1 EMC:SYMRCOPY
SymRemoteCopyControl The Rcopy 'CREATE' operation
FAILED. (SYMAPI_C_INV_DEVICE_RDY_STATUS)
06/18/2008 16:20:08.434
1907
STARTING a 'NOT_READY' control operation.
06/18/2008 16:20:08.435
1907
1 EMC:SYMCLI
SymDevListControl() symdev list: symid: 000190300359
director: N/A, port: N/A ()
06/18/2008 16:20:08.488 1907
1 EMC:SYMCLI
test_dev_state()
TestState: DEV_STATE_NOT_READY_DEVICE,
SymID: 000190300359 Dev: (00A3) Remote: 0, Src: 0, BCV: 0, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW,
Consistency: DIS, Susp Pend: 0, BCV: 0, BCV Paired: 0 BCV State: NeverEstab, InvR1: 0, InvR2: 0, R2WPonR1: 0 Mode: SYN,
Dom: ENB, ACp: OFF, API sts: SYMAPI_C_INV_DEVICE_RDY_STATUS
06/18/2008 16:20:08.508
1907
Set device(s) Not Ready at local Symmetrix.................Done.
06/18/2008 16:20:08.527
1907
The 'NOT_READY' control operation SUCCEEDED.
06/18/2008 16:21:43.511
1915
STARTING a 'READY' control operation.
06/18/2008 16:21:43.511
1915
1 EMC:SYMCLI
06/18/2008 16:21:43.559
1915
1 EMC:SYMCLI
test_dev_state()
TestState: DEV_STATE_READY_DEVICE,
SymID: 000190300359 Dev: (00A3) Remote: 0, Src: 0, BCV: 0, cfg: Inv Dev sts: NR, SA: RW, RA: RW, DA: RW, Link: RW,
06/18/2008 16:21:43.579
1915
Set device(s) Ready at local Symmetrix....................Done.
06/18/2008 16:21:43.598
1915
The 'READY' control operation SUCCEEDED.
06/18/2008 16:22:00.565
1920
06/18/2008 16:22:00.569
1920
1 EMC:SYMCLI
06/18/2008 16:22:00.612 1920
1 EMC:SYMCLI
test_dev_state()
SymID: 000190300359 Dev: (00A3) Remote: 0, Src: 0, BCV: 0, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW,
06/18/2008 16:22:00.630
1920
06/18/2008 16:22:00.649
1920
. . .
06/19/2008 16:59:45.664
2545
1 EMC:SYMRCOPY
(PUSH) (COLD)
06/19/2008 16:59:45.665
2545 STARTING a RCOPY 'CREATE' operation.
06/19/2008 16:59:53.138
2545
1 EMC:SYMRCOPY
doPaceOnDev
Setting throttle to 0xff, dev:0xa0
06/19/2008 16:59:53.143
2545
1 EMC:SYMRCOPY
doPaceOnDev
06/19/2008 16:59:53.147
2545
1 EMC:SYMRCOPY
doPaceOnDev
06/19/2008 16:59:53.151
2545
1 EMC:SYMRCOPY
doPaceOnDev
06/19/2008 16:59:53.172 2545
1 EMC:SYMRCOPY
SymRemoteCopyControl The Rcopy 'CREATE' operation SUCCEEDED.
Troubleshooting
233
Troubleshooting
B.1.1.2 TimeFinder/Mirror establish and Open Replicator terminate

The following excerpt from the symapi-20080624.log corresponds
to the example shown in Section 5.2.2, Initial TimeFinder/Mirror
establish, on page 89:
06/24/2008 18:21:30.926
4327
1 EMC:SYMMIR
evaluate_dev
is an RCOPY push source in created/recreated state
06/24/2008 18:21:30.927
4327
1 EMC:SYMMIR
evaluate_dev
06/24/2008 18:21:30.927
4327
1 EMC:SYMMIR
evaluate_dev
06/24/2008 18:21:30.927
4327
1 EMC:SYMMIR
evaluate_dev
is an RCOPY push source in created/recreated state 06/24/2008 18:22:20.621
SymRemoteCopyControl STARTING a REMOTE Copy TERMINATE
06/24/2008 18:22:20.621
4332 STARTING a RCOPY 'TERMINATE' operation.
4332
BCV
Device: 0080 (000190300359)
BCV
Device: 0081 (000190300359)
BCV
Device: 0082 (000190300359)
BCV
Device: 0083 (000190300359)

1 EMC:SYMRCOPY
06/24/2008 18:22:21.219
4332
1 EMC:SYMRCOPY
SymRemoteCopyControl The Rcopy 'TERMINATE' operation
SUCCEEDED.
06/24/2008 18:22:33.929
4335
1 EMC:SYMMIR
SymDgBcvControl()
dg: cpgroup, ldev: , SymID:
000190300359, symdev: , bcvdev: , flags: (exact)
06/24/2008 18:22:33.933
4335 STARTING a BCV 'ESTABLISH' operation for 4 [SRC-TGT] Pairs:
06/24/2008 18:22:33.977
4335 Symm 000190300359 Number of Pairs: 4 Operation Flags: MultiEstablish
06/24/2008 18:22:33.986
4335
Source-Target Devices: [ 00A0-0080 00A1-0081 00A2-0082 00A3-0083 ]
06/24/2008 18:22:34.409
4335 The BCV 'ESTABLISH' operation SUCCEEDED.
B.1.1.3 TimeFinder/Mirror split

to the example shown in Section 5.2.3, TimeFinder/Mirror split, on
page 90:
06/24/2008 18:46:36.231
4347
1 EMC:SYMMIR
SymDgBcvControl()
000190300359, symdev: , bcvdev: , flags:
06/24/2008 18:46:36.231
4347 STARTING a BCV 'SPLIT' operation for 4 [SRC-TGT] Pairs:
06/24/2008 18:46:36.266
4347 Symm 000190300359 Number of Pairs: 4 Operation Flags: MultiNone
06/24/2008 18:46:36.284
4347
06/24/2008 18:46:42.755
4347 The BCV 'SPLIT' operation SUCCEEDED.
B.1.1.4 Open Replicator create and not_ready control devices reprise

to the examples shown in Section 5.3.1, Cold control devices must be
Not Ready, on page 92 and Section 5.3.2, Create action options, on
page 93:
06/24/2008 18:46:56.404
4350
1 EMC:SYMRCOPY
(PUSH) (COLD) (DIFFERENTIAL)
06/24/2008 18:46:56.405
4350
1 EMC:SYMRCOPY
validateCreate
Cannot CREATE (COLD) session on
dev:0080, sid:000190300359, it is not NR
06/24/2008 18:46:56.405
4350
1 EMC:SYMRCOPY
SymRemoteCopyControl The Rcopy 'CREATE' operation
FAILED. (SYMAPI_C_INV_DEVICE_RDY_STATUS)
06/24/2008 18:47:55.248
4354
06/24/2008 18:47:55.249
4354
1 EMC:SYMCLI
SymDgControl()
grp: cpgroup symid: 000190300359
ldev: director: N/A, port: N/A ()
06/24/2008 18:47:55.292 4354
1 EMC:SYMCLI
test_dev_state()
SymID: 000190300359 Dev: (0080) Remote: 0, Src: 0, BCV: 1, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW,
Consistency: DIS, Susp Pend: 0, BCV: 1024, BCV Paired: 1 BCV State: NeverEstab, InvR1: 0, InvR2: 0, R2WPonR1: 0 Mode:
SYN, Dom: ENB, ACp: OFF, API sts: SYMAPI_C_INV_DEVICE_RDY_STATUS
06/24/2008 18:47:55.312
4354
06/24/2008 18:47:55.336
4354
06/24/2008 18:48:20.104
4357
1 EMC:SYMRCOPY
(PUSH) (COLD) (DIFFERENTIAL)
06/24/2008 18:48:20.104
06/24/2008 18:48:27.841
234
4357
1 EMC:SYMRCOPY
SymRemoteCopyControl The Rcopy 'CREATE' operation SUCCEEDED.
Troubleshooting
B.1.1.5 Open Replicator activate and set ceiling

to the examples shown in Section 5.4, Migration step 10, symrcopy
activate, on page 96 and Section 5.5, Migration step 12, symrcopy set
ceiling, on page 97:
06/24/2008 21:45:44.987
06/24/2008 21:45:44.987
1646
1 EMC:SYMRCOPY
SymRemoteCopyControl STARTING a REMOTE Copy ACTIVATE
1646 STARTING a RCOPY 'ACTIVATE' operation.
06/24/2008 21:45:45.033
1646
1 EMC:SYMRCOPY
SymRemoteCopyControl The Rcopy 'ACTIVATE' operation
SUCCEEDED.
06/24/2008 21:47:09.376
1662
1 EMC:SYMRCOPY
SymDirectorQosSet
STARTING a QOS 'SymDirectorQosSet'
operation - symid: 000190300359, start dev: 0x0000, num devs: 0. LRU set: F , Pace: BCV(F), RDF(F), BCS(F), MIR(F),
SNAP(F)
06/24/2008 21:47:09.385
1662
1 EMC:SYMRCOPY
SymDirectorQosSet
QOS 'SymDirectorQosSet' operation
SUCCEEDED.
06/24/2008 21:47:26.422
1665
1 EMC:SYMRCOPY
SymDirectorQosSet
STARTING a QOS 'SymDirectorQosSet'
operation - symid: 000190300359, start dev: 0x0000, num devs: 0. LRU set: F , Pace: BCV(F), RDF(F), BCS(F), MIR(F),
SNAP(F)
06/24/2008 21:47:26.442
1665
1 EMC:SYMRCOPY
SymDirectorQosSet
QOS 'SymDirectorQosSet' operation
SUCCEEDED.
B.1.1.6 TimeFinder/Mirror incremental update of control devices

to the example shown in Section 5.7.1, Incrementally update control
devices from production devices, on page 100:
06/25/2008 10:45:14.430
1991
1 EMC:SYMMIR
SymDgBcvControl()
06/25/2008 10:45:14.430
1991 STARTING a BCV 'INCREMENTAL_ESTABLISH' operation for 4 [SRC-TGT] Pairs:
06/25/2008 10:45:14.482
1991 Symm 000190300359 Number of Pairs: 4 Operation Flags: MultiEstablish
06/25/2008 10:45:14.491
1991
06/25/2008 10:45:14.873
1991 The BCV 'INCREMENTAL_ESTABLISH' operation SUCCEEDED.
06/25/2008 10:55:23.813
2019
1 EMC:SYMMIR
SymDgBcvControl()
06/25/2008 10:55:23.814
2019 STARTING a BCV 'SPLIT' operation for 4 [SRC-TGT] Pairs:
06/25/2008 10:55:23.859
2019 Symm 000190300359 Number of Pairs: 4 Operation Flags: MultiNone
06/25/2008 10:55:23.869
2019
06/25/2008 10:55:25.243
2019 The BCV 'SPLIT' operation SUCCEEDED.
06/25/2008 10:56:21.916
2028
06/25/2008 10:56:21.917
2028
1 EMC:SYMCLI
SymDgControl()
grp: cpgroup symid: 000190300359
ldev: director: N/A, port: N/A ()
06/25/2008 10:56:21.969 2028
1 EMC:SYMCLI
test_dev_state()
SymID: 000190300359 Dev: (0080) Remote: 0, Src: 0, BCV: 1, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW,
Consistency: DIS, Susp Pend: 0, BCV: 1024, BCV Paired: 1 BCV State: Synchronized, InvR1: 0, InvR2: 0, R2WPonR1: 0 Mode:
SYN, Dom: ENB, ACp: OFF, API sts: SYMAPI_C_INV_DEVICE_RDY_STATUS
06/25/2008 10:56:21.987
2028
06/25/2008 10:56:22.012
2028
Troubleshooting
235
Troubleshooting
B.1.1.7 Open Replicator incremental update of remote devices

to the example shown in Section 5.7.2, Incrementally update remote
devices from control devices, on page 101:
06/25/2008 10:56:36.792
06/25/2008 10:56:36.792
2031
1 EMC:SYMRCOPY
SymRemoteCopyControl STARTING a REMOTE Copy RECREATE
2031 STARTING a RCOPY 'RECREATE' operation.
06/25/2008 10:56:37.207
SUCCEEDED.
06/25/2008 10:57:05.256
06/25/2008 10:57:05.256
2031
06/25/2008 10:57:05.513
SUCCEEDED.
2034
1 EMC:SYMRCOPY
SymRemoteCopyControl The Rcopy 'RECREATE' operation
2034
1 EMC:SYMRCOPY
SymRemoteCopyControl STARTING a REMOTE Copy ACTIVATE
2034 STARTING a RCOPY 'ACTIVATE' operation.
1 EMC:SYMRCOPY
SymRemoteCopyControl The Rcopy 'ACTIVATE' operation
B.1.1.8 Open Replicator terminate and make source devices inaccessible

The following excerpt from the symapi-20080625.log and
symapi-20080709.log corresponds to the examples shown in
Section 5.8, Migration step 15, verify migration and symrcopy
terminate, on page 104 and Section 5.9, Cleanup step 16, make source
devices host inaccessible, on page 106:
06/25/2008 13:24:30.940
06/25/2008 13:24:30.941
2136
1 EMC:SYMRCOPY
SymRemoteCopyControl STARTING a REMOTE Copy TERMINATE
2136 STARTING a RCOPY 'TERMINATE' operation.
06/25/2008 13:24:31.543
2136
1 EMC:SYMRCOPY
SUCCEEDED.
. . .
07/09/2008 01:46:10.902
3594
1 EMC:SYMMASK
07/09/2008 01:56:15.452
3614
1 EMC:SYMMASK
device masking session for Symmetrix 000190300359 with devmask
07/09/2008 01:56:15.594
3614
1 EMC:SYMMASK
from the device masking database for Symmetrix 000190300359 by
07/09/2008 01:56:15.681
3614
1 EMC:SYMMASK
device masking session for Symmetrix 000190300359
07/09/2008 01:57:16.415
3621
1 EMC:SYMMASK
07/09/2008 01:57:16.538
3621
1 EMC:SYMMASK
from the device masking database for Symmetrix 000190300359 by
07/09/2008 01:57:16.613
3621
1 EMC:SYMMASK
07/09/2008 01:57:31.990
3624
1 EMC:SYMMASK
07/09/2008 01:57:33.262
3624
1 EMC:SYMMASK
device masking database for Symmetrix 000190300359
07/09/2008 01:57:33.319
3624
1 EMC:SYMMASK
07/09/2008 01:58:34.652
3633
1 EMC:SYMMASK
07/09/2008 01:59:13.635
3636
1 EMC:SYMMASK
236
SymRemoteCopyControl The Rcopy 'TERMINATE' operation
emcSetupLunMaskSessi Skipping call to emcSymLockSym

SymDevMaskSessionSta Successfully started a Symmetrix
handle 100
emcAddorRemoveDevice Removing the following devices
WWN 210000e08b927df4 for director 34 for port 0
SymDevMaskSessionEnd Successfully ended a Symmetrix
handle 100
emcAddorRemoveDevice Removing the following devices
WWN 210000e08b925cf5 for director 47 for port 0
handle 100
SymDevMaskControl
Refreshing FAs with contents of
Troubleshooting
B.1.2 Hot pull example log entries

The log entries related to Chapter 6, Hot Pull from CLARiiON
Migration Example, are very similar to the ones shown for the cold
push operation above. Therefore only the error related log entries for
missing zoning and missing masking are displayed in the following
sections.
B.1.2.1 Missing zoning error
to the example shown in Section 6.7.1, Discover missing zoning with
symrcopy create, on page 124:
07/17/2008 09:36:20.703
2328
07/17/2008 09:36:21.250
2328
3852 EMC:SYMRCOPY
checkForCreateFai
sid:000190300359, status:loc_sts:0x8 SYSC_SESSION_DISCOVER_FAILED
07/17/2008 09:36:21.250
2328
3852 EMC:SYMRCOPY
map_discover_erro
rem_sts:0x1SANCOPY_DEV_SUCCESS
07/17/2008 09:36:21.250
2328
3852 EMC:SYMRCOPY
map_discover_erro
rem_sts:0xaSANCOPY_DEV_NO_REMOTE_TARGETS
07/17/2008 09:36:21.250
2328
3852 EMC:SYMRCOPY
checkForCreateFai
sid:000190300359, status:10090
07/17/2008 09:36:22.328
2328
3852 EMC:SYMRCOPY
SymRemoteCopyControl
FAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)
Create failed on dev:0091,

loc_dir:02C, rem_num:0,
Discover failed on dev:0091,
The Rcopy 'CREATE' operation
B.1.2.2 Missing masking error

to the example shown in Section 6.7.3, Discover missing LUN masking
with symrcopy create, on page 126:
07/17/2008 11:16:18.265
2784
07/17/2008 11:16:18.875
2784
2780 EMC:SYMRCOPY
checkForCreateFai
sid:000190300359, status:loc_sts:0x8 SYSC_SESSION_DISCOVER_FAILED
07/17/2008 11:16:18.890
2784
2780 EMC:SYMRCOPY
map_discover_erro
rem_sts:0x1SANCOPY_DEV_SUCCESS
07/17/2008 11:16:18.890
2784
2780 EMC:SYMRCOPY
map_discover_erro
rem_sts:0x6SANCOPY_DEV_WWID_NOT_FOUND
07/17/2008 11:16:18.890
2784
2780 EMC:SYMRCOPY
checkForCreateFai
sid:000190300359, status:10090
07/17/2008 11:16:19.953
2784
2780 EMC:SYMRCOPY
SymRemoteCopyControl
FAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)
Create failed on dev:0091,

Discover failed on dev:0091,
The Rcopy 'CREATE' operation
Troubleshooting
237
Troubleshooting
B.1.2.3 Stopping and restarting application using the targets

The following excerpt from the symntctl-20080717.log
corresponds to the examples shown in Section 6.8, Migration step 9,
Stop the applications, on page 129 and Section 6.10, Migration step
11, Restart applications using targets, on page 132:
07/17/08 16:13:51InitLog
07/17/08 16:13:51GetEnvVar
07/17/08 16:13:51GetEnvVar
07/17/08 16:13:51InitEventLog
07/17/08 16:13:51SymapiConnect
07/17/08 16:13:51ProcessInput
07/17/08 16:13:51RebuildInputCommand
07/17/08 16:13:51ProcessUnmount
07/17/08 16:13:51VdsServiceInit
07/17/08 16:13:51CoCreateInstance
07/17/08 16:13:51GetVolumeNameFromVolumeGuid
07/17/08 16:13:51IsVolumeReady
07/17/08 16:13:51GetVdsVolumeByName
07/17/08 16:13:51GetVolumeExtentInfo
07/17/08 16:13:51GetDiskNumFromDiskGuid
07/17/08 16:13:51SymPdevShow
07/17/08 16:13:51IsDiskReady
07/17/08 16:13:51GetDisk
07/17/08 16:13:51SymPdevShow
07/17/08 16:13:51GetDiskVolumeInfo
07/17/08 16:13:51SplitVolumeName
07/17/08 16:13:51IsDiskReady
07/17/08 16:13:51IsVolumeReady
07/17/08 16:13:51IsVolumeClustered
07/17/08 16:13:51CreateFile
07/17/08 16:13:51DeviceIoControl
07/17/08 16:13:51IsVolumeClustered
failed.
07/17/08 16:13:51GetVdsVolumeByName
07/17/08 16:13:51IoctlUnmount
07/17/08 16:13:51CreateFile
07/17/08 16:13:51FlushFileBuffers
07/17/08 16:13:51DeleteVolumeMountPoint
to the volume.
07/17/08 16:13:51SymapiDisconnect
07/17/08 16:13:51Action Complete, exiting...
07/17/08 16:13:51EndEventLog
07/17/08 16:13:51EndLog
. . .
. . .
. . .
-symdev 91
. . .
238
Symntctl Log Opened

Enter GetEnvVar()
Enter GetEnvVar()
Enter InitEventLog()
Enter SymapiConnect()
Enter ProcessInput()
Enter RebuildInputCommand()
symntctl.exe umount -drive L:
Enter ProcessUnmount()
Enter VdsServiceInit()
Enter CoCreateInstance()
Enter GetVolumeNameFromVolumeGuid()
Enter IsVolumeReady()
Enter GetVdsVolumeByName()
Enter GetVolumeExtentInfo()
Enter GetDiskNumFromDiskGuid()
Enter SymPdevShow()
Enter IsDiskReady()
Enter GetDisk()
Enter SymPdevShow()
Enter GetDiskVolumeInfo()
Enter SplitVolumeName()
TRUE
TRUE
Enter IsVolumeClustered()
Enter CreateFile()
IOCTL_VOLUME_IS_CLUSTERED
WIN32 Error: 1
Incorrect function.
SYMNTCTL Error: 1
The operation
Enter GetVdsVolumeByName()
Enter IoctlUnmount()
Enter CreateFile()
FSCTL_LOCK_VOLUME
Enter FlushFileBuffers()
FSCTL_DISMOUNT_VOLUME
Successfully dismounted the volume.
IOCTL_VOLUME_OFFLINE
Successfully took the volume offline.
FSCTL_UNLOCK_VOLUME
Enter DeleteVolumeMountPoint()
Successfully removed all access paths
Enter SymapiDisconnect()
Enter EndEventLog()
Symntctl Log Closed
symntctl.exe rescan
symntctl.exe update -sid 359 -symdev 91
symntctl.exe mount -drive L: -sid 359
Troubleshooting
B.2 Audit Log

Data is written to a common audit file during Symmetrix control
operations initiated by host applications. The common audit log
correlates activity from all hosts into one file that is stored in the
Symmetrix. The symaudit command and the SMC Symmetrix Admin
- SymAudit Records display can be used to filter and display the
common audit log file for a specified Symmetrix array.
The symaudit list example below filters for Open Replicator
actions on 07/17/2008. The records briefly listed below correspond to
the examples shown in Section 6.7.5, Successful create verifies hot pull
setup, on page 128 and Section 6.9, Migration step 10, symrcopy
activate, on page 131:
c:\>symaudit list -sid 359 -function_class rcopy -start_date 07/17 -end_date
07/18
A U D I T
Symmetrix ID
Record
Number
-----8849
8850
8851
8861
8862
8863
. . .
L O G
D A T A
: 000190300359
Date
Time
-------- --------
Function Action
Application
Host
Class
Code
---------------- ------------ -------- ---------
07/17/08
07/17/08
07/17/08
07/17/08
07/17/08
07/17/08
SYMRCOPY
SYMRCOPY
SYMRCOPY
SYMRCOPY
SYMRCOPY
SYMRCOPY
12:27:09
12:27:09
12:27:10
17:21:03
17:21:03
17:21:03
LICOD194
LICOD194
LICOD194
LICOD194
LICOD194
LICOD194
RCopy
RCopy
RCopy
RCopy
RCopy
RCopy
Create
Create
Create
Activate
Activate
Activate
c:\>
Troubleshooting
239
Troubleshooting
Using the -v option shows details of each audit log record. For
example, details for the three Create audit log entries numbered
8849-8851:
c:\>symaudit list -sid 359 -v -record_num 8849 -n 3
A U D I T
Symmetrix ID
L O G
D A T A
: 000190300359
Record Number
:
8849
Records in Seq
:
2
Offset in Seq
:
1
Time
: 07/17/08 12:27:09
Vendor ID
: EMC Corp
Application ID
: SYMRCOPY
Application Version : 6.5.1.0
API Library
: SEK
API Version
: V6.5.1.0 (Edit Level: 882)
Host Name
: LICOD194
OS Name
: WinNT
OS Revision
: 5.2.3790Se
Client Host
:
Process ID
: 00003728
Task ID
: 00003732
Function Class
: RCopy
Action Code
: Create
Text
: STARTING a RCopy 'CREATE' operation for Device List. O
ptions=(Hot, Pull, CopyMode, DonorUpdate)
Username
: H:LICOD194\Administrator
Activity ID
: SE1ceeb91751
Record Number
:
8850
Records in Seq
:
2
Offset in Seq
:
2
Time
: 07/17/08 12:27:09
. . .
Text
: Symm 000190300359 Ctrl-Rem Devices: [ 0091-HK190807410
004:0 0092-HK190807410004:1 0093-HK190807410004:2 0094-HK190807410004:3 ]
Username
Activity ID
: SE1ceeb91751
Record Number
Records in Seq
Offset in Seq
Time
. . .
Text
Username
Activity ID
:
8851
:
1
:
1
: 07/17/08 12:27:10
: The Rcopy 'CREATE' operation SUCCESSFULLY COMPLETED.
: SE1ceeb91751
c:\>
240
Troubleshooting
B.3 PowerPath Migration Enabler (PPME) logs

PowerPath Migration Enabler (PPME) can log audit and error log
messages to a common file. The PowerPath Migration Enabler User Guide
includes details on how to configure the Solaris host syslog.conf(4)
file to write local0.info messages to a common log file. On
Windows hosts these messages appear in the Event Log without any
additional configuration.
Figure 79 shows the Windows Computer Management screen with the
Event Viewer selected so that Application Events are displayed. The
selected entry is of type Error and the source is EmcpLogMsgs which
includes PPME messages
ICO-IMG-000590
Figure 79
Windows Event Viewer with PPME error message selected
Troubleshooting
241
Troubleshooting
Double-clicking on the selected row or selecting the menu items

ActionProperties displays the details of the message in Figure 80,
which shows the missing PPME license corresponding to Section 9.3.2,
PPME license required, on page 207.
ICO-IMG-000591
Figure 80
242
Event Properties detail for missing PPME license
Troubleshooting
Figure 81 shows part of the Event Viewer screen with an informational

PPME message selected.
ICO-IMG-000592
Figure 81
Windows Event Viewer with PPME error message selected
Figure 82 shows the Event Properties detail for a powermig setup

command that was executed in Section 9.3, PPME Setup steps 5-6,
powermig setup, on page 205.
ICO-IMG-000593
Figure 82
Event Properties detail for missing PPME license
Troubleshooting
243
Troubleshooting
B.4 Reactivate Failed Session

Prior to Enginuity 5773, the state of the Open Replicator session was set
to Failed if a transient network or device issue was encountered. The
only option available from the Failed state was to terminate the
session. Enginuity version 5773 allows failed sessions to be reactivated
as long as certain criteria are met. Only sessions where no new data has
been written to the control device since the session failed can be
reactivated.
If new data has been written, the session should be terminated. This is
because when a hot push session fails, a write to the control device
succeeds, as does a full track write on a failed hot pull session. This
could lead to a situation where data on the control device that still needs
to be pulled or pushed is not part of the initial point-in-time.
Reactivating the Open Replicator session in these circumstances may
result in data being overwritten on the control device on a pull or
inconsistent data being written to the remote device on a push.
In the example shown below, the same Open Replicator device pairs in
Chapter 7, Hot Pull from Symmetrix Migration Example, were used
for a hot push. The remote devices were made not_ready to simulate a
transient failure. Notice the Status in the query output below
indicates both the failed state and that the failed session is eligible to be
reactivated:
Session Name
: hot_push
Control Device
Remote Device
Flags
--------------------------- --------------------Protected
SID:symdev
Tracks
Identification
RI
----------------- --------- ------------------ -000190300359:0098
29861 000187720450:0144 SD
000190300359:0097
40786 000187720450:0143 SD
000190300359:0096
42160 000187720450:0142 SD
000190300359:0095
28459 000187720450:0141 SD
Status
Done
----- ---------- ---CDSHU
----XXXX.
XXXX.
XXXX.
XXXX.
CTL<=>REM (%)
---------- ---Failed (*) N/A
Failed (*) N/A
Failed (*) N/A
Failed (*) N/A
Total
--------Track(s)
141266
MB(s)
8829.1
. . .
Flags:
. . .
(*): The failed session can be reactivated.
c:\>
244
Troubleshooting
Once the transient error condition is corrected (in this case making the
remote devices ready), the session can be reactivated. The syntax to
reactivate the session is the same as that used to originally activate
the session:
c:\>symrcopy -session hot_push activate -consistent
with session name 'hot_push' (y/[n]) ? y
with session name 'hot_push'. Please wait...
with session name 'hot_push'.
c:\>
After a short delay, the query action is repeated and the results show
that the Status has changed back to CopyInProg. Additionally, the
Protected Tracks values have decreased and the Done % values
have increased showing that the copy session is closer to completion:
Session Name
: hot_push
Control Device
--------------------------Protected
SID:symdev
Tracks
----------------- --------000190300359:0098
23936
000190300359:0097
34565
000190300359:0096
31869
000190300359:0095
22604
Total
Track(s)
MB(s)
. . .
c:\>
Remote Device
Flags Status
Done
--------------------- ----- ---------- ---Identification
-----------------000187720450:0144
000187720450:0143
000187720450:0142
000187720450:0141
RI
-SD
SD
SD
SD
CDSHU
----XXXX.
XXXX.
XXXX.
XXXX.
CTL<=>REM (%)
---------- ---CopyInProg
63
CopyInProg
47
CopyInProg
51
CopyInProg
65
--------112974
7060.9
Troubleshooting
245
Troubleshooting
246
Glossary
This glossary contains terms related to disk storage subsystems. Many

of these terms are used in this guide.
A
administrator
agent
allocate
allocated storage
audit
authority
A person responsible for administrative tasks such as access

authorization and content management. Administrators can also grant
levels of authority to users.
A software entity that runs on endpoints and provides management
capability for other hardware or software.
To assign a resource for use in performing a specific task.
The space that is allocated to volumes, but not assigned.
To review and examine the activities of a data processing system
mainly to test the adequacy and effectiveness of procedures for data
security and data accuracy.
The right to access objects, resources, or functions.
B
backup
bandwidth
A copy of computer data that is used to recreate data that has been lost,
mislaid, corrupted, or erased. The act of creating a copy of computer
data that can be used to recreate data that has been lost, mislaid,
corrupted or erased.
A measure of the data transfer rate of a transmission channel.
247
Glossary
C
cache
A random access electronic storage in selected storage controls used to

retain frequently used data for faster access by the channel.
CKD
Count Key Data, a data recording format employing self-defining

record formats in which each record is represented by a count area that
identifies the record and specifies its format, an optional key area that
may be used to identify the data area contents, and a data area that
contains the user data for the record. CKD can also refer to a set of
channel commands that are accepted by a device that employs the CKD
recording format.
CLI
See Command Line Interface (CLI).
client
A function that requests services from a server, and makes them

available to the user. A term used in an environment to identify a
machine that uses the resources of the network. See also client-server.
client-server
In TCP/IP, the model of interaction in distributed data processing in

which a program at one site sends a request to a program at another site
and awaits a response. The requesting program is called a client; the
answering program is called a server.
client-server
relationship
Any process that provides resources to other processes on a network is

a server. Any process that employs these resources is a client. A
machine can run client and server processes at the same time.
COFA
See copy on first access (COFA).
COFW
See copy on first access (COFA).
cold operation
Open Replicator mode where the Symmetrix DMX control device must
be offline to the host application. See also hot operation.
Command Line
Interface (CLI)
A mechanism for interacting with a computer operating system or

software by typing commands to perform a given task, referred to as
entering a command: the system waits for the user to conclude the
submitting of the text command by pressing the Enter key. A command
line interpreter then receives, analyses, and launches the requested
command. Upon completion, the command usually returns output to
the user in the form of text lines on the CLI.
248
Glossary
connection
consistent copy
console
In TCP/IP, the path between two protocol applications that provides

reliable data stream delivery service. In Internet communications, a
connection extends from a TCP application on one system to a TCP
application on another system.
A copy of data entity (for example, a logical volume) that contains the
contents of the entire data entity from a single instant in time.
A user interface to a server. That part of a computer used for
communication between the operator or user and the computer.
control side
The Symmetrix DMX, where Open Replicator runs, and its devices are
always referred to as the control side of the copy operation.
copy on first
access (COFA)
The Open Replicator copying of not-yet copied data from the remote to
the control when an application first attempts to read that data.
copy on first write

(COFW)
The Open Replicator copying of not-yet copied data from the control to
the remote when an application first attempts a write to the location of
that data.
D
data availability
data integrity
data migration
default
Access to any and all user data by the application.

The condition that exists as long as accidental or intentional
destruction, alteration, or loss of data does not occur.
The one-time movement of data from source to target, where the data
will subsequently only be accessed at the target.
A value, attribute, or option that is assumed when no alternative is
specified by the user.
249
Glossary
dependent-write
consistency
A data state where data integrity is guaranteed by dependent-write

I/Os embedded in application logic. Database management systems
are good examples of applications that utilize the dependent-write
consistency strategy. Database management systems must devise
protection against abnormal termination in order to successfully
recover from one. The most common technique used is to guarantee
that a dependent write cannot be issued until a predecessor write has
completed. Typically the dependent write is a data or index write while
the predecessor write is a write to the log. Because the write to the log
must be completed prior to issuing the dependent write, the application
thread is synchronous to the log write (that is, it waits for that write to
complete prior to continuing). The result of this kind of strategy is a
dependent-write consistent database.
dependent-write
I/O
An I/O that cannot be issued until a related predecessor I/O has

completed. Most applications, and in particular database management
systems (DBMS), have embedded dependent-write logic to ensure data
integrity in the event of a failure in the host or server processor,
software, storage subsystem, or if an environmental power failure
occurs. See also dependent-write consistency.
device type
director
The component in the Symmetrix subsystem that allows the Symmetrix

to transfer data between the host channels and disk devices.
directory
(1) A type of file containing the names and controlling information for
other files or other directories. Directories can contain subdirectories,
which can contain subdirectories of their own. (2) A file that contains
directory entries. No two directory entries in the same directory can
have the same name. (POSIX.1). (3) A file that points to files and to
other directories.
disaster recovery
disk director
250
The general name for a kind of device; for example, standard, BCV,
VDEV, or Clone.
The process of restoring a previous copy of the data and applying logs
or other necessary processes to that copy to bring it to a known point of
consistency.
The component in the Symmetrix subsystem that interfaces between
cache and the disk devices.
Glossary
E
Enterprise Systems
Connection
(ESCON)
ESCON
A set of products and services that provides a dynamically connected

environment using optical cables as a transmission medium.
Enterprise Systems Connection architecture; a set of IBM and vendor
products that connect mainframe computers with each other and with
attached storage, locally attached workstations, and other devices using
optical fiber technology and dynamically modifiable switches called
ESCON directors.
F
fabric
FBA
FC
Fibre Channel employs a fabric to connect devices. A fabric can be as

simple as a single cable connecting two devices. The term is often used
to describe a more complex network utilizing hubs, switches, and
gateways.
Fixed Block Architecture, disk device data storage format using
fixed-size data blocks.
See Fibre Channel.
FCP
See Fibre Channel protocol.
FCS
See Fibre Channel standard.
fiber optic
The medium and the technology associated with the transmission of

information along a glass or plastic wire or fiber.
Fibre Channel
A technology for transmitting data between computer devices at a data

rate of up to 4 Gbps. It is especially suited for connecting computer
servers to shared storage devices and for interconnecting storage
controllers and drives.
Fibre Channel
protocol
The serial SCSI command protocol used on Fibre Channel networks.
Fibre Channel
standard
An ANSI standard for a computer peripheral interface. The I/O

interface defines a protocol for communication over a serial interface
that configures attached units to a communication fabric. Refer to ANSI
X3.230-199x.
251
Glossary
FICON
An I/O interface based on the Fibre Channel architecture. In this new

interface, the ESCON protocols have been mapped to the FC-4 layer,
that is, the Upper Level Protocol layer, of the Fibre Channel Protocol. It
is used in the S/390 and z/Series environments.
file system
An individual file system on a host. This is the smallest unit that can be
monitored and extended. Policy values defined at this level override
those that might be defined at higher levels.
front-end director
The component in the Symmetrix subsystem that interfaces with host

bus adapters (HBAs). It transfers data between the host and Symmetrix
cache.
G
gatekeeper
A small logical volume on a Symmetrix storage subsystem used to pass

commands from a host to the Symmetrix storage subsystem.
Gatekeeper devices are configured on standard Symmetrix disks.
Gigabit Ethernet
Technologies for transmitting Ethernet frames at a rate of a gigabit per

second, as defined by the IEEE 802.3-2005 standard.
gigabyte (GB)
Graphical User
Interface (GUI)
GUI
109 bytes.
A type of user interface which allows people to interact with a
computer and computer-controlled devices. It presents graphical icons,
used in conjunction with text, labels or text navigation to fully represent
the information and actions available to a user. But instead of offering
only text menus, or requiring typed commands, the actions are usually
performed through direct manipulation of the graphical elements.
See Graphical User Interface (GUI).
H
hardware
Physical equipment, as opposed to the computer program or method of

use; for example, mechanical, magnetic, electrical, or electronic devices.
See also software.
hardware zoning
The members of a hardware zone are based on the physical ports on the
fabric switch. Zoning can be implemented in the following
configurations: one to one, one to many, and many to many.
HBA
252
See host bus adapter.
Glossary
highly parallel
host
Refers to multiple systems operating in parallel, each of which can have

multiple processors.
Any system that has at least one Internet address associated with it. A
host with multiple network interfaces can have multiple Internet
addresses associated with it. This is also referred to as a server.
host bus adapter
A Fibre Channel HBA connection that allows a workstation to attach to

the SAN network.
host not ready
In this state, the volume responds not ready to the host for all read and
write operations to that volume.
hot operation
Open Replicator mode where the Symmetrix DMX control device can
remain online to the host application.
hypervolume
A user-defined storage device allocated within a Symmetrix physical

disk.
hyper-volume
extension
The ability to define more than one logical volume on a single physical
disk device making use of its full formatted capacity. These logical
volumes are user-selectable in size. The minimum volume size is one
cylinder and the maximum size depends on the disk device capacity
and the emulation mode selected.
I
I/O device
internet protocol
(IP)
An addressable input/output unit, such as a disk device.

A protocol used to route data from its source to its destination in an
Internet environment.
K
KB
Kilobyte, 1024 bytes.
L
local volumes
Volumes that reside on an Symmetrix system but do not participate in

SRDF activity.
logical unit number

(LUN)
A volume identifier that is unique among all storage servers. The LUN
is synonymous with a physical disk drive or a SCSI device. For disk
subsystems such as the IBM Enterprise Storage Server, a LUN is a
253
Glossary
logical disk drive (a unit of storage on the SAN which is available for
assignment or unassignment to a host server). The LUNs are provided
by the storage devices attached to the SAN.
logical volume
A user-defined storage device.

Exclusive OR (XOR) of the accumulated bytes in the data record.
LUN masking
LUN
Allows or blocks access to the storage devices on the SAN. Intelligent

disk subsystems provide this kind of masking.
See logical unit number (LUN).
M
MB
media
microprocessor
mirrored pair
Megabyte, 106 bytes.

The disk surface on which data is stored.
A processor implemented on one or a small number of chips.
A logical volume with all data recorded twice, once on each of two
different physical devices.
mirroring
The Symmetrix maintains two identical copies of a designated volume

on separate disks. Each volume automatically updates during a write
operation. If one disk device fails, Symmetrix automatically uses the
other disk device.
mirroring (RAID 1)
The highest level of performance and availability for all mission-critical

and business-critical applications by maintaining a duplicate copy of a
volume on two disk drives.
multipath device
A device made visible to a host on more than one I/O path in order to
improve both fault tolerance (failover) and performance (load
balancing).
multiprocessing
multiprocessor
(MP)
254
The simultaneous execution of two or more computer programs or

sequences of instructions. See also parallel processing.
A CPC that can be physically partitioned to form two operating
processor complexes.
Glossary
N
native device
name
A path-specific device name provided by the host operating system that

represents a single path to a logical device. See also pseudo device
name.
network topology
A physical arrangement of nodes and interconnecting communication

links in networks based on application requirements and geographical
distribution of users.
O
open system
A system whose characteristics comply with standards made available

throughout the industry, and therefore can be connected to other
systems that comply with the same standards.
operating system
(OS)
Software that controls the execution of programs and that may provide
services such as resource allocation, scheduling, input/output control,
and data management. Although operating systems are predominantly
software, partial hardware implementations are possible.
P
parallel processing
password
The simultaneous processing of units of work by many servers. The

units of work can be either transactions or subdivisions of large units of
work (batch). See also highly parallel.
A unique string of characters known to a computer system and to a
user, who must specify the character string to gain access to a system
and to the information stored within it.
point of
consistency
A point in time to which data can be restored and recovered or restarted

and maintain integrity for all data and applications.
port
An endpoint for communication between applications, generally

referring to a logical connection. A port provides queues for sending
and receiving data. Each port has a port number for identification.
When the port number is combined with an Internet address, it is called
a socket address.
port zoning
In Fibre Channel environments, the grouping together of multiple ports

to form a virtual private storage network. Ports that are members of a
group or zone can communicate with each other but are isolated from
ports in other zones. See also LUN masking and zoning.
255
Glossary
protocol
pseudo device
name
The set of rules governing the operation of functional units of a

communication system if communication is to take place. Protocols can
determine low-level details of machine-to-machine interfaces, such as
the order in which bits from a byte are sent. They can also determine
high-level exchanges between application programs, such as file
transfer.
A location-independent name that represents a single logical device
and the path set leading to it. See also native device name.
pull operation
A Open Replicator pull operation copies data to the control device from
the remote device.
push operation
A Open Replicator push operation copies data from the control device
to the remote device.
R
RAID
RAID 0
A protection method where data is striped across several disks to

increase performance. Unless combined with RAID 1, does not natively
provide protection from data loss due to drive failure. See also RAID
10.
RAID 1
A protection method that provides the highest level of performance and

availability for all mission-critical and business-critical applications by
maintaining a duplicate copy of a volume on two disk drives. See also
mirroring.
RAID 5
A protection method that provides high performance with automatic

striping across hypervolumes. Lost hypervolumes are regenerated from
remaining members. RAID 5 is configured in (3+1) and (7+1) groups.
RAID 5 technology stripes data and distributes parity blocks across all
the disk drives in the RAID group.
RAID 6
A protection method that supports the ability to rebuild data in the

event that two drives within the RAID group fail.
RAID 10
256
Redundant array of inexpensive or independent disks. A method of

configuring multiple disk drives in a storage subsystem for high
availability and high performance.
A protection method that combines RAID 1 and RAID 0; used in

mainframe environments.
Glossary
read access
ready volume
recovery
remote operations
remote side
restore
resynchronization
Permission to read information.

A state indicating the volume is available for read/write operations.
The process of rebuilding data after it has been damaged or destroyed,
often by using a backup copy of the data or by reapplying transactions
recorded in a log.
Operation of remote sites from a host system.
The array and devices at the other side of an Open Replicator control
side Symmetrix DMX is referred to as the remote side. See also control
side.
A process that reinstates a prior copy of the data.
A track image copy from the primary volume to the secondary volume
of only the tracks which have changed since the volume was last in
duplex mode.
S
SAN
SCSI adapter
SCSI reservation
server
See storage area network.

Card in the Symmetrix subsystem that provides the physical interface
between the disk director and the disk devices.
A method to claim or free ownership of a LUN using the standard SCSI
Reserve/Release protocol.
A program running on a mainframe, workstation, or file server that
provides shared services. This is also referred to as a host.
shared storage
Storage within a storage facility that is configured such that multiple

homogeneous or divergent hosts can concurrently access the storage.
The storage has a uniform appearance to all hosts. The host programs
that access the storage must have a common model for the information
on a storage device. Programs must be designed to handle the effects of
concurrent access.
small computer
system interface
(SCSI)
An ANSI standard for a logical interface to computer peripherals and

for a computer peripheral interface. The interface utilizes a SCSI logical
protocol over an I/O interface that configures attached targets and
initiators in a multi-drop bus topology.
257
Glossary
software zoning
software
source device
stage
Is implemented within the Simple Name Server (SNS) running inside

the fabric switch. When using software zoning, the members of the
zone can be defined with a node WWN, port WWN, or physical port
number. Usually the zoning software also allows you to create symbolic
names for the zone members and for the zones themselves.
(1) All or part of the programs, procedures, rules, and associated
documentation of a data processing system. (2) A set of programs,
procedures, and, possibly, associated documentation concerned with
the operation of a data processing system. For example, compilers,
library routines, manuals, circuit diagrams. See also hardware.
The device which is read from in a data migration. See also target
device.
The process of writing data from a disk device to cache.
storage
administrator
A person in the data processing center who is responsible for defining,

implementing, and maintaining storage management policies.
storage area
network
A managed, high-speed network that enables any-to-any

interconnection of heterogeneous servers and storage systems.
switch
A component with multiple entry and exit points or ports that provide
dynamic connection between any two of these points.
switch topology
A switch allows multiple concurrent connections between nodes. There

can be two types of switches; circuit switches and frame switches.
Circuit switches establish a dedicated connection between two nodes.
Frame switches route frames between nodes and establish the
connection only when needed. A switch can handle all protocols.
T
target device
TCP
TCP/IP
topology
258
The device which is written to in a data migration. See also source

device.
See transmission control protocol.
Transmission Control Protocol/Internet Protocol.
An interconnection scheme that allows multiple Fibre Channel ports to
communicate. For example, point-to-point, arbitrated loop, and
switched fabric are all Fibre Channel topologies.
Glossary
transaction
transactional
consistency
transmission
control protocol
A unit of work performed by one or more transaction programs,

involving a specific set of input data and initiating a specific process or
job.
Transactional consistency is a DBMS state where all in-flight
transactions are either completed or rolled back.
A communications protocol used in the Internet and in any network
that follows the Internet Engineering Task Force (IETF) standards for
Internetwork protocol. TCP provides a reliable host-to-host protocol
between hosts in packet-switched communications networks and in
interconnected systems of such networks. It uses the Internet Protocol
(IP) as the underlying protocol.
V
virtual storage
virtualization
volume
(1) The storage space that can be regarded as addressable main storage
by the user of a computer system in which virtual addresses are
mapped into real addresses. The size of virtual storage is limited by the
addressing scheme of the computer system and by the amount of
auxiliary storage available, not by the actual number of main storage
locations. (2) An addressing scheme that allows external disk storage to
appear as main storage.
A technique for hiding the physical characteristics of computing
resources from the way in which another function interacts with those
resources.
A general term referring to a storage device. In the Symmetrix
subsystem, a volume corresponds to single disk device.
W
wait state
waiting time
WAN
Synonymous with waiting time.

(1) The condition of a task that depends on one or more events in order
to enter the ready condition. (2) The condition of a processing unit
when all operations are suspended.
Wide area network.
259
Glossary
web browser
world wide name
WWN
A software application which enables a user to display and interact

with text, images, videos, music and other information typically located
on a Web page at a website on the World Wide Web or a local area
network. Web browsers communicate with Web servers primarily using
HTTP (hypertext transfer protocol) to submit information to Web
servers as well as fetch Web pages from them.
A unique number assigned to Fibre Channel devices (including hosts
and adapter ports). It is analogous to a MAC address on a network
card.
See world wide name.
Z
zoning
260
In Fibre Channel environments, zoning allows for finer segmentation of

the switched fabric. Zoning can be used to instigate a barrier between
different environments. Ports that are members of a zone can
communicate with each other but are isolated from ports in other zones.
Zoning can be implemented in two ways: hardware zoning and
software zoning. See also hardware zoning and software zoning.
Index
A
Auto-provisioning Groups 153
C
Celerra
brief description 39
CLARiiON
discover 66
display information about 66
remote for cold push example 66
remote for hot pull example 112
cleanup steps
cold push example 84
definition 61
flowchart 61
flowchart for PPME 202
for hot pull 113
for PPME 199
clustered hosts
special considerations 64
cold
definition 23
cold pull
definition 50
replace with hot pull 51
cold push
cleanup example 83
definition 47
migration and cleanup steps flowchart 85
migration example 83
setup example 65
versus hot push 49

Connectrix
Connectrix Manager
zoning verification screen 72, 126, 148
control side
definition 22
ControlCenter
see EMC Ionix ControlCenter
create
and SCSI reservations 55
cutover
definition 22
D
data migration
definition 22
selection model 25
TechBook series 17
device masking
Symmetrix example 119
Symmetrix SMC example 150
diskpart 135
donor update
example 128
explanation 50
off (disable) 138, 185
E
EMC Ionix ControlCenter
261
Enginuity
definition 32
F
front-end directors
defined 32
H
hot
definition 23
hot pull
definition 49
from CLARiiON example 111
from Symmetrix example 139
setup, migration, and cleanup flowchart 114
hot push
definition 46
differences from cold push 104
versus cold push 49
I
ICDA
see Integrated Cached Disk Array
Integrated Cached Disk Array
definition 32
Invista
L
LUN masking
for Symmetrix see device masking 150
verify with Remote Report 173
verify with symsan -sanluns 77
M
migration
project steps 24
services 44
migration steps
flowchart 57
for PPME 197
hot pull example 112
262
MirrorView
mount 87, 108
multipathing 23
PowerPath 39
N
navicli
storagegroup operations 73, 107, 118, 128, 130
Navisphere
connectivity status example 71
invoke connectivity status 70
Storage Processor WWNs 71
O
offline
definition 23
online
definition 23
Open Replicator
control interface alternatives 63
data mobility 48
-force_copy 53
migration operation flow 52
pair file example 74, 123
Symmetrix V-Max and Symmetrix DMX
arrays 33
TimeFinder interaction 89, 100
tuning introduction 60
P
powerformat 108, 195
PowerPath
multipathing 39
PowerPath Migration Enabler
benefits 188
description 188
introduction 24
migration example 204
migration states 191
nondisruptive migration 189
role in migration operations 64
when to use 25
PPME
see PowerPath Migration Enabler
precopy
definition 47
pull
definition 23
push
definition 23
R
remote device
read-only access 23
remote side
definition 22
Replication Manager
S
SAN Copy
incremental use case 36
SAN Manager
SCSI reservations
cluster control 55
setup steps
definition 52
flowchart 53
PPME example 196
verify completion example 75
verify failure example 124
SIU
see Symmetrix Integration Utilities
SLV
see Symmetrix logical volume
SMC
see Symmetrix Management Console
SnapView
Solutions Enabler
SRDF
see Symmetrix Remote Data Facility

Symmetrix
architecture 32
logical volumes 33
remote for hot pull example 139
Symmetrix Integration Utilities
definition 129
symntctl command 129
Symmetrix logical volume
definition 33
Symmetrix Management Console
Remote Report 80
Symmetrix Remote Data Facility 34
symntctl
log 238
mount 134, 179
umount 129, 130, 174
update 132, 179
T
TimeFinder
initial establish 89
migration role 34
Open Replicator interaction 89, 100
split 90
TimeFinder family
U
umount 102
V
VxVM
vxdctl 108
vxdg 102, 108
vxdisk 102, 108, 109
vxprint 87, 109, 110
vxresize 110
vxvol 108
263
Z
zoning
verify with Remote Report 173
verify with symmask list logins 78
verify with symsan -sanports 75
264

h5765 Data Migration Open Replicator Symm Ppme Techbook

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

h5765 Data Migration Open Replicator Symm Ppme Techbook

Hochgeladen von

Copyright:

Verfügbare Formate

Data Migration:

EMC Open Replicator for Symmetrix

EMC Open Replicator for Symmetrix Features

Copyright 2008, 2010 EMC Corporation. All rights reserved.

Brief EMC Foundation and Migration Product

2.3.2 SnapView .....................................................................

EMC Open Replicator for Symmetrix

Cold Push to CLARiiON Setup Example

4.3.1 Determining Control Director WWN ......................

Cold Push to CLARiiON Migration Example

Hot Pull from CLARiiON Migration Example

Hot Pull from Symmetrix Migration Example

7.3.1 Determining control director World Wide Port

PowerPath Migration Enabler (PPME) Overview

PPME with Open Replicator Migration Example

9.2 PPME Setup steps 1-4 ......................................................... 205

Open Replicator Performance Tuning

Migration project steps ............................................................................. 25

Disk Management display of remote source drives P, Q, R, and S..

PPME migration steps flowchart..........................................................

As part of an effort to improve and enhance the performance and capabilities

EMC Symmetrix Logical Volumes (SLVs) including masking

CLARiiON or third-party array LUNs and masking for

EMC Solutions Enabler SYMCLI and Symmetrix Management

This TechBook is divided into nine chapters and two appendices:

Chapter 1, Introduction, provides an introduction to the

Chapter 2, Brief EMC Foundation and Migration Product

Chapter 3, EMC Open Replicator for Symmetrix,defines all Open

Chapter 4, Cold Push to CLARiiON Setup Example, provides an

Chapter 5, Cold Push to CLARiiON Migration Example, provides

Chapter 6, Hot Pull from CLARiiON Migration Example,

Chapter 7, Hot Pull from Symmetrix Migration Example,

Chapter 8, PowerPath Migration Enabler (PPME) Overview,

Chapter 9, PPME with Open Replicator Migration Example,

Appendix A, Open Replicator Performance Tuning, consolidates,

Appendix B, Troubleshooting, provides log examples that

This TechBook is the second in a series of Data Migration TechBooks.

Where to get help

EMC support, product, and licensing information can be obtained as

For technical support, go to EMC Customer Service on Powerlink. To

White paper: New Features in EMC Enginuity 5874 for Symmetrix

EMC uses the following type style conventions in this document:

User actions (what the user, clicks, presses, or selects

Arguments in examples of command-line syntax

Angle brackets enclose parameter or variable values supplied by the user

Square brackets enclose optional values

Vertical bar indicates alternate selections - the bar means or

Braces indicate content that you must specify (that is, x or y or z)

Ellipses indicate nonessential information omitted from the example

The author of this TechBook

This TechBook was written by Donald Fried-Tanzer, an employee of

Your feedback on our TechBooks is important to us! We want our books

This chapter provides a brief executive summary of the two migration

1.1 Introduction ..................................................................................

1.2 Data Migration definition

1.3 EMC Open Replicator for Symmetrix

1.3.2 Control FA "host" setup requirements

1.3.3 Terminology: push and pull, cold and hot

1.3.4 Multipathing with hot setup requirements

Open Replicator operations result in the greater requirement that all FA

1.4 EMC PowerPath Migration Enabler (PPME)

1.5 Migration project steps

Migration project steps

This TechBook is focused on operational migration examples, similar to