Implementing PowerPath Migration

Enabler in Open Replicator and

Invista Environments

P/N 300-003-978
Rev A01

August 30, 2006

This document provides best practices and advice for using EMC®
PowerPath® Migration Enabler.

Topics include:
◆ Executive summary.............................................................................. 2
◆ Introduction........................................................................................... 3
◆ Overview of PowerPath Migration Enabler ..................................... 4
◆ Open Replicator scenario 1: Pseudo device to pseudo device....... 6
◆ Open Replicator scenario 2: Native device to pseudo device...... 14
◆ Invista encapsulation scenario ......................................................... 30
◆ VERITAS volume management........................................................ 45
◆ Tips and best practices....................................................................... 65
◆ Conclusion........................................................................................... 75
◆ References ............................................................................................ 76
◆ Appendix: Scripts ............................................................................... 77

1
Executive summary

Executive summary
EMC PowerPath Migration Enabler is a tool designed to leverage
existing EMC replication technologies and allow faster and easier
data migrations. PowerPath Migration Enabler is also designed to
significantly decrease application downtime and provide enhanced
data protection. As a new product, there is a need for a deeper
understanding of how to best perform a successful implementation.
In its initial release, PowerPath Migration Enabler enhances the
capabilities of EMC Open Replicator by maintaining both source and
target devices in a consistent state. Mirroring the two devices allows
auditioning the migration and returning to the initial state with no
downtime. Additional benefits will be provided to users of EMC
Invista, through transparent encapsulation of existing storage
devices. This functionality allows hosts that are using devices
presented through an existing array/SAN a potentially
nondistruptive method of accessing the same devices.
This offering will be released with PowerPath version 5.0 for each
supported operating system.
To aid in the deployment of the new offering, these technical notes
focus on use case scenarios, as well as tips and best practices to follow
during implementations.
This document contains some information that is specific to the
Solaris operating system used to implement the use cases. However,
the majority of the information is generic, and focuses on the
PowerPath Migration Enabler and the underlying replication
technologies.

2 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Introduction

Introduction
This document provides best practice guidelines for PowerPath
Migration Enabler. To highlight these capabilities, the document
examines the following use case scenarios:
◆ Perform a migration between PowerPath pseudo devices with no
disruption, using Open Replicator as the underlying replication
technology.
◆ Perform a migration from native devices to PowerPath pseudo
devices with minimum disruption, using Open Replicator as the
underlying replication technology.
◆ Demonstrate the ability to increase file system size without
disruption after migration is complete. This scenario highlights
the case of performing capacity uplift migrations.
◆ Provide the steps necessary to complete a transparent,
nondisruptive Invista encapsulation of devices on a system that is
currently accessing PowerPath pseudo devices.
This document also provides some tips and best practices not covered
in the use case scenarios. Many focus on environmental issues.
PowerPath Migration Enabler leverages the I/O filter of PowerPath
and existing EMC replication technologies. Proper setup and
functioning of these offerings is the key to success when using
PowerPath Migration Enabler.
These technical notes are not a substitute for PowerPath Migration
Enabler training and user documentation. These notes assume that
the reader has a basic understanding of PowerPath, PowerPath
Migration Enabler commands, the underlying replication technology
involved, and any volume management software (such as VERITAS
Volume Manager or Solstice DiskSuite) referenced herein.

Note: Most importantly, this document is not a replacement for the PowerPath
Migration Enabler User's Guide or the release notes. Be sure to read and
understand both documents, as well as the documentation for any asoociated
product, before proceeding with implementation.

Audience
This document is intended for customers who are interested in
maximizing their Open Replicator environment or who are
investigating implementing Invista storage virtualization product.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 3

Overview of PowerPath Migration Enabler

Overview of PowerPath Migration Enabler

PowerPath Migration Enabler is a host-based migration tool that
allows migration of data between storage systems. This is
accomplished by using PowerPath technology in conjunction with
other underlying technologies, such as Open Replicator or Invista.
PowerPath Migration Enabler is independent of PowerPath
multipathing technology, and requires a separate license to activate.
PowerPath Migration Enabler does not require that PowerPath for
multipathing be enabled.
When data is being migrated by PowerPath Migration Enabler, the
data continues to be accessible to the host application. This greatly
reduces—and potentially eliminates—downtime. The level of
disruption necessary to complete a migration depends on whether
the data is referenced by a PowerPath pseudo device or a host
system’s native device, and on whether PowerPath is installed on the
host. If PowerPath has not been installed, a reboot may be necessary
to completely configure the host.
The possible scenarios for performing migrations in the current
release of PowerPath Migration Enabler for Solaris include:
◆ Pseudo-to-pseudo devices
◆ Native-to-native devices
◆ Native-to-pseudo devices
PowerPath pseudo devices are location-independent devices that
represent a single logical device accessible over one or more paths.
Also, a pseudo device is named in a location-independent way. This
ability to access data without the use of a pointer to any of the
physical devices associated with the data allows migrations that do
not require reconfiguration of the application. When a migration is
performed from one pseudo device to another, the migration is
nondisruptive.
Native devices are operating system-specific, location-dependent
names for devices that are presented to the host, and may reference a
single path or multiple paths to a logical device. When migrating data
from a native device, the application requires an outage so that access
to the new target device can be properly configured. This may be a
one-time disruption if the application is reconfigured to use a pseudo
device. In this event, future migration performed to pseudo devices
would be nondisruptive.

4 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Overview of PowerPath Migration Enabler

PowerPath Migration Enabler is designed to work in conjunction

with an underlying technology, such as Open Replicator for EMC
Symmetrix® systems. Future releases may access other migration
engines. Generally, differences in how the underlying technologies
interact with PowerPath Migration Enabler are transparent to the
user. Some pre/post-migration steps might differ depending on the
underlying technology; however, the goal is to provide a common
user interface for performing migrations.
When using Open Replicator as the underlying technology, data is
copied from the source device through the fabric to the target device.
Software on the Symmetrix system where the target device resides
controls the data movement. The mirroring of I/O to keep the source
and target devices synchronized throughout the migration process is
performed by PowerPath Migration Enabler on the host.
In an Invista migration, Invista encapsulates the source device; no
actual data is copied. Invista provides a method for nondisruptively
migrating devices from their original source into the virtualized
environment when EMC pseudo devices are involved. When
migrating data to an Invista Virtual Volume, the device is presented
through a parallel path to Invista, and the Virtual Volume is also
presented to the host as the target device. The original device as seen
on the host is the source device. The migration is then performed
using the standard PowerPath Migration Enabler commands.
The specific steps required for each migration depend on the
underlying technology involved. This is a critical point to
understand; the setup of the underlying technology is key to the
success of PowerPath Migration Enabler. Most challenges lie in
proper implementation of the underlying technology. Once this has
been thoroughly verified, PowerPath Migration Enabler is simple to
use, and very effective.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 5

Open Replicator scenario 1: Pseudo device to pseudo device

Open Replicator scenario 1: Pseudo device to pseudo device

The first use case scenario is the nondisruptive migration of pseudo
device pairs. In the example presented here, PowerPath 5.0 has been
installed as an upgrade to a system that had been using PowerPath
4.5, and the application was configured to use pseudo devices. This
migration requires an outage for the application so PowerPath 4.5 can
be removed from the Solaris system and PowerPath 5.0 installed. The
command emcpreg -add was used to install the PowerPath Migration
Enabler license.
Open Replicator was also installed in the environment. To verify that
the Open Replicator setup was properly configured, some minor
migrations were performed to a Symmetrix DMX system from an
EMC CLARiiON® array.
For this use case scenario, the mounted file system /u01, which is
currently using emcpower10c, will be migrated to emcpower27c.
We use powermt display commands to verify the configuration
information that will be used in the migration. As Figure 1 on page 7
shows, the output from the powermt display commands for the
source (emcpower10c) and target (emcpower27c) identifies the
correct emcpower device and verifies the array LUN.

6 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 1: Pseudo device to pseudo device

Figure 1 Listing the source/target pair

This method can be repeated or scripted to generate the source/target

pairings that will be needed to perform the migration. Once all of the
pairs have been identified, each pair can be used to generate a
PowerPath Migration Enabler session.
The migration steps are as follows:
1. Type the following command to specify Open Replicator as the
technology type and establish the source/target pair:
powermig setup -tt OR -src emcpower10c -tgt emcpower27c

2. To verify the setup, we type powermig info -all (as shown in

Figure 2 on page 8).

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 7

Open Replicator scenario 1: Pseudo device to pseudo device

Figure 2 Establishing a source/target pair

The session for the first migration is ready to proceed and is in the
setup state.
3. To initiate the movement of data from the source to the target, we
must synchronize the source and target devices (using the handle
that was specified in the powermig setup output):
powermig sync -handle 4 -no

Note: The -no is short for -noprompt, which causes the command to be
executed without requiring a user response.

4. To display a detailed progress of the migration, we type a query:

powermig query -hd 4

Figure 3 on page 9 shows an output example.

8 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 1: Pseudo device to pseudo device

Figure 3 Displaying the migration progress

5. As Figure 3 shows, the output from powermig query includes a

Throttle Value, which is a performance/resource utilization
setting that is used to adjust the performance of Open Replicator.
The default value of 5 is a conservative, middle-speed setting that
attempts to balance the speed of the data migration against the
load that Open Replicator will place on the arrays involved.
The throttle value is passed on to the Open Replicator software,
and adjusts the throughput for the particular session. The Open
Replicator parameter set ceiling can be applied directly to the
Open Replicator software to globally control throughput of all
migration sessions managed by PowerPath Migration Enabler.
To accelerate the migration, a throttle setting is available. (0 is the
fastest, but creates the highest demand for resources; 9 is the
slowest, but requires fewer resources.) Using the default value,
the migration of the 8 GB device used in this example on a system
with a light load took 64 minutes. The same migration with a
throttle value of 0 took only three minutes. In EMC testing, the
impact to the application is negligible with the fastest speed
setting; however, performing a large number of migrations in an
I/O-intensive environment could cause some impact. The only

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 9

Open Replicator scenario 1: Pseudo device to pseudo device

way to know for sure is through experimentation in the actual

environment, as the number of possible variables are too many to
document.
For this example, we chose to accelerate the migration by setting
the throttle value to 0:
powermig throttle -hd 4 -tv 0 -no

A query (shown in Figure 4) displays the new throttle value.

Figure 4 Accelerating the migration

When the data transfer is complete, a query shows that the

session is in the sourceSelected state (as shown in Figure 5 on
page 11). This indicates that, while both the source and target
LUNs are being mirrored and the data is current on both, all reads
are being performed from the source LUN.
6. Before the migration can be completed, the session must be set to
use the LUN onto which the data was migrated:
powermig selectTarget -hd 4 -no

The lower portion of Figure 5 shows the output from a query sent
after selecting the target.

10 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 1: Pseudo device to pseudo device

Figure 5 Setting the LUN to be used

For further testing of the environment to reverse the migration,

we can type powermig selectSource -hd 4 to make the system
resume all read activity to the source LUN. We can toggle
between the source and target multiple times; this state of
mirroring will remain, even through system reboots.
7. Once the data synchronization is complete, we must set the
session to selectTarget state and execute powermig commit -hd 4,
as shown in Figure 6.

Figure 6 Committing the migration

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 11

Open Replicator scenario 1: Pseudo device to pseudo device

8. To clear the informational status, we type powermig cleanup -hd

4, as shown in Figure 7.

Figure 7 Clearing the informational status

9. An investigation of the results (Figure 8 on page 13) shows that

the file system is still active and mounted on the host, and is
available for use by any application the host is configured to
support. However, an investigation of the devices associated with
the source/target pair involved shows that while the pseudo
device in use remains the same, the underlying native devices
have been migrated.

12 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 1: Pseudo device to pseudo device

Figure 8 Displaying the migration results

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 13

Open Replicator scenario 2: Native device to pseudo device

Open Replicator scenario 2: Native device to pseudo device

In this scenario, we migrate a Solstice DiskSuite metadevice (built
from two native devices) to PowerPath pseudo devices, with
minimum disruption. Studies have indicated that when migrations
occur, the opportunity is often taken to expand the capacity for the
application. To address this opportunity, a procedure is provided for
increasing the volume size after the migration is complete.
In this example, PowerPath 5.0 was installed on the host for the first
time. This procedure requires a reboot of the system for the
PowerPath 5.0 installation.
Open Replicator was also installed in the environment. To verify that
the Open Replicator setup was properly configured, some minor
migrations were performed to a Symmetrix DMX system from an
earlier Symmetrix model.
The major advantage of this scenario is that after the first
implementation all future migrations on this system should not
require an outage unless the metadevice is migrated to larger devices
and is to be increased again. As long as the operating system can
discover the newly added disk devices, and the applications that had
previously used native names to access data are now using the
pseudo devices defined during this initial migration, PowerPath
Migration Enabler can migrate data transparently to the system and
applications.

Note: The brief outage is required only for reconfiguring the Solstice
DiskSuite device, not for the operating system. If this migration were
performed using PowerPath pseudo devices that were formatted with UFS
and no volume manager was involved, the file system could be migrated and
increased without interruption.

14 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 2: Native device to pseudo device

Identifying the devices

To identify the devices to be migrated:
1. As Figure 9 shows, we start by confirming the native devices
used for the DiskSuite metadevice to be migrated.

Figure 9 Confirming native devices used for migratation

Typing df -k displays the mounted file system, as shown in

Figure 10.

Figure 10 Displaying the mounted file system

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 15

Open Replicator scenario 2: Native device to pseudo device

2. Next we type powermt display dev=device_name to verify the

devices. (This is considered a best practice.)
Figure 11 below and Figure 12 on page 17 are output for the
devices that have been identified for use in this migration.

Figure 11 powermt display output for emcpower14a

16 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 2: Native device to pseudo device

Figure 12 powermt display output for emcpower16a

PowerPath Migration Enabler acts on devices in a one-to-one

relationship. After the pairs have been confirmed, the procedure is
nearly the same for each migration. Variations occur when native
devices are involved. The difference is based on the fact that for
migrations that involved pseudo device names, the underlying
operating system-defined native device names are shuffled to
associate with the pseudo name and the application can continue
referencing the data as it always has.
When native device names are used for the migration, the data is
transferred in the same manner as the pseudo device migration, and
the application remains active and online, using the original source
device name. The difference here is that when the migration is
commited, the I/O map redirection supplied by PowerPath
Migration Enabler, which allows the application to access the data

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 17

Open Replicator scenario 2: Native device to pseudo device

from the defined target device by calling the original source device
name, is stopped, and the application must be reconfigured to use the
target device's native device name.

Performing the migration

To perform the migration:
1. We type a powermig setup command:
powermig setup -tt TechType -src device -tgt device

Figure 13 shows the output.

Figure 13 Confirming the setup

2. Once the setup has been confirmed, we can begin the

synchronization by typing the following command for each
device:
powermig sync -hd handle

Figure 14 on page 19 shows the output.

18 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 2: Native device to pseudo device

Figure 14 Performing the synchronization

3. As Figure 14 also shows, we can adjust the throttle value for each
device:
powermig throttle -hd handle -tv value

4. When the data synchronization is complete, the displayed state is

sourceSelected (as shown in Figure 15 on page 20). We can toggle
between the source and target devices by typing powermig
selectTarget -hd handle and 'powermig selectSource -hd handle as
many times as necessary to confirm that the new target devices
are functioning as desired. The state is maintained through
reboots of the host.
When verification is complete and a brief outage window is available
for the host, we perform the following steps to reconfigure the
metadevice, increase the size of the file system, and complete the
migration.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 19

Open Replicator scenario 2: Native device to pseudo device

Note: In this scenario, the application itself does not require reconfiguration,
since the Solstice DiskSuite metadevice will not change its name, but only its
available capacity. The metadevice configuration will need to be updated.
Had this been a migration in which the application was configured to use the
native devices, it would require a reconfiguration to access the correct device.
In this example, Solstice DiskSuite is the application.

Figure 15 Completing the migration

5. Once the application has stopped, we umount the file system.

This is necessary for the alterations that are needed in Solstice
DiskSuite to reconfigure the metadevice to access the new devices
that replaced the previous ones.

Note: Figure 16 on page 22 shows the commands and output described in

steps 5 through 7.

6. We type powermig commit -hd handle for the migrations

involved.
The output from powermig info -query -all now shows a state of
committedAndRedirected, which indicates that PowerPath is
redirecting all I/O that was being sent to the original source

20 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 2: Native device to pseudo device

devices so that the I/O now goes to the selected target devices,
that all reads are performed from the new target devices,
and—most importantly—the mirroring relationship between the
source/target pair has ended. Any change now made to the
selected device will not be replicated.

Note: As a best practice, do not run in the the committedAndRedirected

state for very long unless necessary. In this state, the system cannot be
reverted to its previous setup state, and confusion is possible concerning
exactly what data is on which device. This issue exists because the source
device name is accessing the target device. To avoid potential
mismanagement of resources, stop the application(s) involved, type
powermig undoRedirect -hd handle to complete the commit, and
perform all required application reconfiguration.

7. Lastly, we type powermig cleanup -hd handle to update the disk

header information on the original source devices. This requires
that a format label be placed on the devices before they can be
reused.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 21

Open Replicator scenario 2: Native device to pseudo device

Figure 16 Updating the disk header information

22 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 2: Native device to pseudo device

Growing the Solstice DiskSuite metadevice after a native-to-pseudo migration

Now we can perform the steps required to reconfigure the Solstice
DiskSuite metadevice to use the new target devices. When this is
complete, we can proceed to expanding the associated file system:
1. First we identify the slices used by the Solstice DiskSuite
database, as shown in Figure 17. To change the configuration, we
must rebuild the database. The process is quick and easy.

Figure 17 Identifying the slices used by the Solstice DiskSuite database

2. With the information for the metadb ready, we clear the

metadevice that we want to reconfigure, and then flush the meta
database, as shown in Figure 18.
With the system now in a clean slate, we update the configuration
information for the metadevice, so that the information will point
to the new target devices.

Figure 18 Clearing the metadevice and flushing the meta database

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 23

Open Replicator scenario 2: Native device to pseudo device

Figure 19 is an example of md.tab entry for the metadevice.

Figure 19 Example of md.tab entry

3. Before the metadb can be recreated and the metadevice

initialized, we must perform the most critical step. The
powerformat command is a new tool provided with PowerPath
5.0. The command enables the ability to update disk header
information so the operating system can now recognize
and—more importantly—use the proper disk geometry.
4. The next step in our example is to type the command
powerformat -gx /dev/rdsk/device_name for each new target
device.
When PowerPath Migration Enabler with Open Replicator
performs a migration, Open Replicator does a block copy of the
source—including header information—to the target. When the
target device is viewed by executing the Solaris format command
after the commit and cleanup, the display includes the geometry
of the source device, including the LUNs size and partition
information. The host is unaware of the LUN’s true capacity. The
powerformat command provides the correct information.

24 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 2: Native device to pseudo device

Figure 20 shows powerformat usage; Figure 21 on page 26 and

Figure 22 on page 27 are examples of output.

Figure 20 powerformat command usage

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 25

Open Replicator scenario 2: Native device to pseudo device

Figure 21 powerformat example for emcpower26c

26 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 2: Native device to pseudo device

Figure 22 powerformat example for emcpower27c

5. Now that the operating system has the correct information for the
disk layout, we re-establish the metadb and perform the metainit.
As Figure 23 on page 28 shows, the system is still unaware of the
new capacity, but the metadevice is back and functional.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 27

Open Replicator scenario 2: Native device to pseudo device

Figure 23 Example of metainit output

6. The last step to expand the volume to use the new capacity is to
type the Solaris growfs command, as shown in Figure 24 on
page 29. This can be done with the file system mounted; however,
I/O to this disk will be halted while the newfs portion of the
command is executed, so this step should be performed just
before restarting the application that requires access to the file
system.

28 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Open Replicator scenario 2: Native device to pseudo device

Figure 24 Example of growfs output

Note: When performing any operations with Soltice Disksuite or any other
volume management software, carefully review the release notes for
additional information.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 29

Invista encapsulation scenario

Invista encapsulation scenario

The scenario of Invista encapsulation is designed to aid in the
adoption of Invista technology by providing a method of migrating
existing host devices into an Invista instance seamlessly, with little or
no disruption of services. This can be achieved for systems already
configured to use PowerPath pseudo devices presented through a
SAN or direct-attached to storage arrays. The same LUNs are
presented as Storage Elements to an Invista instance and back to the
host system as Invista Virtual Volumes.
The environment for this use case consists of a system on which
PowerPath 5.0 was previously installed and the applications were
configured to leverage emcpower devices as presented from storage
arrays through a SAN. These same storage array LUNs must be
presented to the Invista instance.
All of the devices the system is using from the SAN must be
presented to the Invista instance as Storage Elements, which must be
set to a Not Ready state (preventing the volumes from being used in
other operations) and imported into the Invista instance. Invista
Virtual Volumes are created from the Storage Elements and assigned to
Virtual Frames, which are connected to the host(s). The last step before
the encapsulation process is to refresh the device list on the system so
these LUNs can be seen, and the associated PowerPath pseudo
devices built so the proper source/target pairs can be identified.
One of the major issues with this scenario is understanding the
topographical layout of the devices in the SAN and their access from
the host system through both the SAN and the Invista instance, as
well as their presentation as Storage Elements into the Invista
environment.
Here are the steps in this scenario:
1. The first step in any data migration is identifying the resource to
be moved. For this use case, we will use Symmetrix device
8200198491 and PowerPath pseudo device
/dev/dsk/emcpower7c (shown in Figure 25 on page 31).

30 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Invista encapsulation scenario

Figure 25 Identifying the device to be moved

2. The first step in the creation of a target device is to identify the

back-end device as an Invista Storage Element and import it into
the Invista instance. On the Invista Element Manager GUI
(graphical user interface), we select the Unimported folder, as
shown in Figure 26 on page 32. In the Unique ID column in the
right pane, we find the associated device. (The Storage Element
used for this example is SE_0_5_2.)

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 31

Invista encapsulation scenario

Figure 26 Listing unimported Invista Storage Elements

3. Now we open the Unimported folder, right-click the desired

Storage Element, and select Set Not Ready (Reserve) from the
pop-up menu that appears.
This step is very important because, when the device is presented
to the system, the ability to maintain data consistency is critical.
Allowing access to the same data over multiple paths presents a
possibility for data corruption.
4. Now we right-click the Storage Element, and select Import from
the pop-up menu.

32 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Invista encapsulation scenario

The Storage Element moves from the Unimported folder to the

Imported folder.
5. To create a Virtual Volume, we right-click the Storage Element in
the Imported folder, and select Create Virtual Volume from the
pop-up menu.
6. In the Create Virtual Volume dialog box (Figure 27), we accept
the default Virtual Volume Name or give the volume a
more-useful name. To match to the current mount point, the name
ppme_u01 was selected for this example.
Notice in Figure 27 that the Number of Virtual Volumes to
Create and Virtual Volume Size fields are not accessible because
the Set Not Ready (Reserve) option was enabled. When
performing a PowerPath Migration Enabler encapsulation, the
LUN layout is predetermined, and this process is designed to
protect the existing data.

Figure 27 Creating an Invista Virtual Volume

Clicking OK saves any changes and closes the dialog box.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 33

Invista encapsulation scenario

7. To make the Virtual Volume available to the system, we must

assign it to a Virtual Frame. After creating the Virtual Volume, we
expand the Virtual Frames folder, right-click the Virtual Frame
associated with the host, and select Select Virtual Volumes from
the pop-up menu.
This displays a Virtual Frame Properties window (Figure 28),
which allows us to add the Virtual Volume to the Virtual Frame.

Figure 28 Adding an Invista Virtual Volume to a Virtual Frame: Before

8. Double-clicking the Virtual Volume in the left pane moves it to

the right pane, as shown in Figure 29 on page 35.

34 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Invista encapsulation scenario

Figure 29 Adding an Invista Virtual Volume to a Virtual Frame: After

9. As Figure 29 shows, we now select the volume and assign a LUN

to it.
Clicking OK saves any changes and closes the dialog box.
This completes the work required on the Invista instance to present
the LUN to the host. Now we return to the host system for the next
phase of the encapsulation:
1. The device that is to become the target of the migration has been
presented to the system. Now we must make the device visible to
the host.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 35

Invista encapsulation scenario

The command devfsadm -C updates the operating system to

create the proper device files. The commands powermt config
and powermt save create the desired PowerPath pseudo device
entry.
The syminq command (shown in Figure 30) starts the process of
verifying that this is the correct device.

Figure 30 Example of syminq output

2. The verification process requires investigating the information on

both the host system and the Invista instance. First, we type
powermt display dev=Invista_target_device, as shown in Figure 31
on page 37.

36 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Invista encapsulation scenario

Figure 31 Example of powermt display output

Note the Logical device ID

(60001440906024E40148C31020000023) in Figure 31.
3. On the Invista Element Manager GUI, we display the properties
of the Virtual Volume from within the Virtual Frame (as shown in
Figure 32 on page 38).
Note that the logical device ID from the powermt display output
is the same as the Unique ID for the selected Virtual Volume.

Note: New with the PowerPath 5.0 release is the command powermt
display nonvirtual [dev=device|all]. The output from this command
lists the devices presented to the host by the Invista instance. The man
page on powermt contains more details.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 37

Invista encapsulation scenario

Figure 32 Displaying the Invista Virtual Volume properties

Note: PowerPath Migration Enabler perform this same logical device ID

verification when an attempt is made to execute powermig setup. If the
incorrect source/target pair is selected, an error occurs. This step is used
to save time and prevent wasted efforts in attempting to generate correct
source/target pairs.

With the information for generating the source/target pairs available,

the procedure is the same as with any PowerPath Migration Enabler
migration: establish the source/target pair, synchronize (which for
Invista encapsulation entails no actual data movement), select the
target, and commit the migration. The only major difference is in the
cleanup procedure, which is described later in this document.
4. Begin the process by establishing the source/target pairs:
powermig setup -tt INVE -src device -tgt device

5. Verify that the setup was successful; then perform the

synchronization for the encapsulation to occur:
powermig sync -hd handle

38 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Invista encapsulation scenario

Since no data is actually being migrated, this is merely a step to

redirect I/O to use the selected target/source path. As Figure 33
indicates, the query should show that the migration is in the
sourceSelected state almost immediately.

Figure 33 Redirecting the I/O

6. With the device in the selectSource state, typing the following

commands (as shown in Figure 34 on page 40) completes the
encapsulation:
powermig selectTarget -hd handle

powermig commit -hd handle

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 39

Invista encapsulation scenario

Figure 34 Completing the encapsulation

After the commit, the display of the mounted file system shows
that the mount point has not changed, and any I/O that had been
accessing this device continued without interruption.
Figure 35 on page 41 and Figure 36 on page 42 are powermt
displays of the emcpower devices used before and after this
encapsulation. Notice that only the native paths that were used to
construct the pseudo device names changed; the pseudo device
names themselves did not change.

40 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Invista encapsulation scenario

Figure 35 Devices before migration

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 41

Invista encapsulation scenario

Figure 36 Devices after migration

7. The final step to complete this migration involves executing a

powermig cleanup for this migration. Because the encapsulated
device is actually the same LUN, the cleanup cannot act in the
same manner as in the Open Replicator migration and alter the
disk header information. Therefore, before the cleanup can be
completed successfully, the source LUN involved must be
removed from view of the operating system.
This can be accomplished by physically removing the cables from
the HBAs that had provided access to this LUN (although
normally this is not an option) or through the use of zoning the
device so that it is removed effectively. The method used to
perform this zoning update is optional; use whatever method is
most familiar and comfortable; for example, Volume Logix,

42 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Invista encapsulation scenario

Access Logix or any other tool available. For the example in

Figure 37, a simple script containing symmask commands was
used.

Figure 37 Removing the source LUN from the operating system’s view

8. With the device no longer visible to the system, the remaining

cleanup can be performed by typing the following commands, as
shown in Figure 38 on page 44:
powermig cleanup -hd handle

powermt remove dev=target_device

Also, as whenever configuration changes are made in PowerPath,

save the changes:
powermt save

Note: The pseudo device name removed from PowerPath was the target.
The original source device name is still in use, but the logical units that
were referenced by it have changed. Therefore, as displayed in the
Aftermig.lis, the pseudo device name to be cleared is the one that
references the original devices.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 43

Invista encapsulation scenario

Figure 38 Finishing the cleanup

Much of the work that is needed to perform Invista encapsulation is

manual, but could be scripted. The Invista Element Manager GUI
also facilitates implementation. The major benefit of this
encapsulation is that—with proper planning, forethought, and
configuration—it can be executed without downtime to the host or
application.

44 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

VERITAS volume management

Many environments looking to use a migration tool are
enterprise-level solutions that often implement volume management
software. VERITAS Volume Manager is one of the most common
solutions used by customers who perform data migrations. This
section is provided to help with the adoption of PowerPath Migration
Enabler in such an environment.

Using native-to-native migration to expand VERITAS VxVm 4.0 volumes

VxVM 4.0 volumes can be expanded after performing a powermig,
but only when the volumes were constructed using native devices. If
emcpower devices were used, you should migrate to like-size devices
and expand by adding LUNs to the Volume Group. This section
describes the process to expand if native devices were used.

Note: This is a disruptive procedure, since the Volume Group must be

deported/imported for the new devices to be recognized.

In this example, we will use a handle of 27. As Figure 39 shows, the

output from powermig commit -hd 27 shows the new state as
committedAndRedirected.

Figure 39 Displaying the device state

The output shown in Figure 39 indicates that while the host system is
still calling source device c4t0d34s0, PowerPath is providing
redirection to new target c3t0d34s0. This state can be held as long as
is necessary to find a maintenance window during which the final
reconfiguration steps can be performed to allow the application
(VxVM 4.0 in this case) the opportunity to be resized.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 45

VERITAS volume management

1. When the application is available, we begin by unmounting any

file systems associated with the Volume Group, as shown in
Figure 40 on page 46.

Figure 40 Unmounting file systems

2. Now we type vxdg deport jpmc_ppmefs, as shown in Figure 41.

This allows the Volume Group to be brought back onto the host
utilizing the new devices.

Figure 41 Output from vxdg deport jpmc_ppmefs

3. With the Volume Group removed, we end the redirection process

by typing powermig undoRedirect -hd 27 -no, as shown in
Figure 42 on page 47.

46 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Figure 42 Ending the redirection process

4. With the migration now in the committed state, we return the

Volume Group to the system.
5. The next step is to bring the Volume Group back by typing vxdg
import jpmc_ppmefs, and verifying that the proper devices are
present, as shown in Figure 43.

Figure 43 Verifying that the correct devices are present

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 47

VERITAS volume management

6. Next, we type vxdisk -g jpmc_ppmefs resize c3t0d34s2 (as

shown in Figure 44) so the Volume Group can recognize the
additional capacity.

Figure 44 Allowing the Volume Group to recognize the additional capacity

7. Now that the additional capacity is available, we type vxvol -g

jpmc_ppmefs startall to restart the Volume Group, and then
mount the devices as before, as shown in Figure 45 on page 49.

48 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Figure 45 Restarting the Volume Group

8. To make the extra capacity available to the system, we type the

VxVm commands shown in Figure 46 on page 50. We use vxassist
to identify and expand the underlying device, and fsadm to
expand the actual file system.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 49

VERITAS volume management

Figure 46 Expanding the file system

9. Finally, we type powermig cleanup -hd 27 to flush the table of

historical information.

50 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Using pseudo-to-pseudo migration to expand VERITAS VxVm 4.1 volumes

In this example, a VxVM Volume Group was created using two 8 GB
PowerPath pseudo devices. Three 5 GB UFS file systems were then
presented to the system. Using PowerPath Migration Enabler, these
two devices will be migrated to two 16 GB devices, and the usable
space of one of the file systems will be expanded. This will be
performed without disruption:
1. First we examinine the devices that will be involved in the
migration, as shown in Figure 47 and Figure 48.

Figure 47 Displaying mounted file systems

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 51

VERITAS volume management

Figure 48 Displaying VxVM volume information

2. We have identified emcpower28s2 and emcpower33s2 as the

target devices to use for this migration. As displayed in the VxVM
Volume information (Figure 48), emcpower17s2 and
emcpower18s2 will be the source devices.
We can save the information for the source and target devices to a
file by typing powermt display dev=emcpowerXX. Figure 49 on
page 53 and Figure 50 on page 54 show the output from the
command.

52 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Figure 49 Source device information from powermt display command

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 53

VERITAS volume management

Figure 50 Target device information from powermt display command

3. With the file systems mounted and the application continuing to

process data, we perform the migration as described under
“Using pseudo-to-pseudo migration to expand VERITAS VxVm
4.1 volumes” on page 51 (and as shown in Figure 51 on page 55).

54 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Figure 51 Performing setup and initiating migration

4. As was demonstrated in the previous use case scenarios, we can

adjust the throttle value. Figure 52 on page 56 displays a query of
the current setting for the default synchronization that was
started and the process of adjusting the throttle to accelerate the
migration.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 55

VERITAS volume management

Figure 52 Identifying and adjusting the migration throttle setting

5. Once the data synchronization is complete and has entered the

sourceSelected state, we type powermig selectTarget and
powermig commit (as shown in Figure 53 on page 57), and finish
the migration by typing powermig cleanup. The VxVM 4.1
volume is now ready to be expanded.

56 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Figure 53 Completing the migration

6. Before proceeding, we execute powermt display to verify each

device. As Figure 54 on page 58 and Figure 55 on page 59 show,
while the emcpower devices are still attached and in use by the
VxVM 4.1 Volume Group, the underlying native devices
referenced by these pseudo names have changed to reflect the
source/target migration.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 57

VERITAS volume management

Figure 54 Source device information from powermt display command

58 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Figure 55 Target device information from powermt display command

With the migration complete and verified as successful, we can

examine the VxVM Volume Group and see that nothing has changed.
Using the following steps, we can expand the Volume Group and
increase the usable disk capacity of the file system without
interruption:
1. The first step is to update the VxVM Volume Group with
information that the capacity of the associated devices has indeed
increased. This is accomplished by typing vxdisk -g group resize
device (as shown in Figure 56 on page 60) and verifying that the
capacity has changed.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 59

VERITAS volume management

Figure 56 Resizing and verifying a device

2. As Figure 56 shows, the length associated with the emcpower17s2

device has increased from 17669376 to 35348736. To access the
remaining capacity, we type vxdisk -g group resize device for each
remaining device in the migration.
3. Once the Volume Group has been configured to use the increased
capacity, we type vxassist -g group maxsize to query the Volume
Group for the exact amount that can be expanded.
4. To see the potential for the file system, we type vxassist -g group
maxgrow vg_filesystem.
5. With the information we got from step 4, we type vxassist -g
group growto vg_filesystem size to expand the VxVM file system to
the desired size, as shown in Figure 57 on page 61.

60 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Figure 57 vxassist commands for expanding a VxVM file system

6. As Figure 58 on page 62 shows, a quick verification of the vxassist

grow process reveals that the ppmefs_1 file system has grown
from 10485760 to 32045056.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 61

VERITAS volume management

Figure 58 Display of increased capacity for ppmefs_1 file system

7. The last step to increase the usable size of the UFS file system
while that system continues to use the device is to execute the
Solaris growfs command (shown in Figure 59 on page 63).

Note: I/O to the file system will stop for the time required to complete
the newfs portion of growfs. This very short time is not a disruption of
service, but creates a temporary performance degradation.

62 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 VERITAS volume management

Figure 59 growfs command output

8. To verify the success of the operation, we type df -k, as shown in

Figure 60.

Figure 60 Display of increased capacity for ppmefs_1 file system

The system has now expanded the usable capacity of the ppmefs_1
file system without disruption of service.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 63

VERITAS volume management

Summary The process of performing migrations with PowerPath Migration

Enabler is clean, straightforward, and, with the use of emcpower
devices, nondisruptive. For larger-scale jobs, you can construct
intelligent scripts that can set up, synchronize, and commit sessions,
with testing performed along the way to verify success. And,
throughout the migration process, the state of the data is continually
protected.

64 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Tips and best practices

Tips and best practices

The vast majority of issues involving successful use of the PowerPath
Migration Enabler are those that concern the underlying
technologies, rather than the product itself. PowerPath Migration
Enabler is a simple tool; any complications reside in the underlying
technologies. This section focuses on a few issues that have been
discovered as potential challenges, and attempts to aid in the
deployment of PowerPath Migration Enabler.

Open Replicator setup

The key to using PowerPath Migration Enabler in the Open
Replicator environment is proper establishment of the Open
Replicator infrastructure. Most of the issues uncovered during the
initial beta testing of the product involved the procedure for setting
up the first migration. Once these problems were resolved, the
product functioned smoothly and effectively.
The key to implementing Open Replicator successfully is the
understanding of the access required between the storage array
initiators that will be performing the Open Replicator hot pull. Each
Symmetrix Fibre Channel director (FA) port that can view a LUN that
is seen as the target of the migration within an array must be viewed
by the source array as a host system. This is not intuitive to the
normal practice of SAN management, since ports on arrays are not
thought of as host systems.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 65

Tips and best practices

Figure 61 demonstrates the access necessary.

SP A FA-1

FA-2

Source Target
LUN FA-3 LUN

SP B FA-4

CLARiiON Symmetrix
SAN

HBA 1 HBA 2

Source device (CLARiiON)

c1t1d0s2 / c2t1d0s2 / emcpower2c

Target device (Symmetrix)

c1t5d5s2 / c2t5d5s2 / emcpower12c

IVA-000016

Figure 61 Open Replicator SAN configuration

In Figure 61, the host system can see the source LUN through both
HBAs. The target LUN is seen through both HBAs, but is presented
to the system through only two of the Symmetrix FA ports. To
correctly configure the SAN for Open Replicator performing a hot
pull, all FA ports presenting the target LUN require access to the
CLARiiON SPs that are presenting the source device as if those FAs
were host initiators accessing the CLARiiON LUN.
In a Symmetrix-to-Symmetrix environment, all FA ports presenting a
target device require access to all FA ports presenting the source
device.
The final point of interest is that the host system has to see the source
and target devices only down a single path; no extra consideration is
needed.

66 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Tips and best practices

Solutions Enabler setup

Correct installation of Open Replicator is critical for the success of
PowerPath Migration Enabler. The following is a refresher for the
components of the Solutions Enabler required for proper operation:

Note: PowerPath Migration Enabler requires Solutions Enabler Version 6.2.x

or higher.

1. Download, uncompress, and untar the software onto the system.

2. Perform the installation. Figure 62 on page 68 through Figure 64
on page 70 are from a typical installation.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 67

Tips and best practices

Figure 62 Installing Solutions Enabler: Screen 1

68 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Tips and best practices

Figure 63 Installing Solutions Enabler: Screen 2

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 69

Tips and best practices

Figure 64 Installing Solutions Enabler: Screen 3

3. Once Solutions Enabler has been installed, it must be licensed.

The licenses required for proper operation of Open Replicator
with PowerPath Migration Enabler are Base, Symapi Server, and
RcopyonlinePull. (Additional licenses should also be installed at
this time.)

70 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Tips and best practices

Here are some sample commands to install the licenses:

=> symlmf XXXE-YYY0-ZZZC-CCCD

=> symlmf 3A33-6444-CDEF-01AB

=> symlmf A999-1666-F111-666A

=> more /var/symapi/config/symapi_license.dat

The sample license keys are:

• XXXE-YYY0-ZZZC-CCCDSYMAPI Feature: BASE /
Symmetrix
• 3A33-6444-CDEF-01ABSYMAPI Feature: SERVER /
Symmetrix
• A999-1666-F111-666ASYMAPI Feature: RcopyOnlinePull /
Symmetrix
4. Discover the arrays and populate the Solutions Enabler database:
=> symcfg discover

This completes the requirements for Solutions Enabler with

PowerPath Migration Enabler.

Invista encapsulation SAN management

There are two major issues when performing Invista encapsulation
using PowerPath Migration Enabler. The first is to identify the source
and target pairs of LUNs as viewed by the system from both the SAN
and the Invista instance. “Invista encapsulation scenario” on page 30
contains an example of the steps to complete this process.
The second issue involves successful execution of powermig
cleanup, which is the final step of the encapsulation procedure. To
successfully perform the cleanup of the migration, the host can no
longer physically see the LUN that is being acted upon.
The PowerPath Migration Enabler User's Guide recommends
disconnecting the cable from the host system, to ensure that the host
can no longer see the LUN nor access the data on it. Unfortunately,
there are many valid reasons for maintaining the physical connection
to the SAN/storage array that had been used for access to the
migrated LUN; particularly the probability that the host is still using
other LUNs that are not, and might not ever be, encapsulated.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 71

Tips and best practices

“Invista encapsulation scenario” on page 30 contains an example of

how to isolate a LUN after migration and perform the required
powermig cleanup.

Performance results for various ThrottleValues for Open Replicator

PowerPath Migration Enabler contains a parameter called
ThrottleValue that can be used to adjust the rate of data movement
against the array resources used. (A setting of 0 is the fastest, but
creates the greatest demand for resources; 9 is the slowest, but
requires fewer resources.) The PowerPath Migration Enabler User's
Guide provides more detail on this parameter, as well as information
on using the Open Replicator command symrcopy set ceiling to
adjust the global performance of Open Replicator migration. (The
Open Replicator User's Guide provides more details about the Open
Replicator application.)

Note: If the Open Replicator parameter set ceiling is set, Open Replicator
disables the PowerPath Migration Enabler throttle command.

Using the default ThrottleValue setting of 5, the migration of the 8

GB device used in this example on a system with a light load was 64
minutes. The same migration with a throttle value of 0 was
completed in only three minutes. In the testing done by EMC, the
impact to the application is negligible with the fastest speed setting;
however, it is possible that with a large number of migrations being
performed, or in a very I/O-intensive environment, some impact
may be noticed.
As a best practice recommendation, schedule migration for a time of
reduced I/O activity, and use the fastest possible setting. PowerPath
Migration Enabler is nondisruptive while the data migration is
occurring, and migration could be performed safely during the
busiest peaks of I/O activity. However, it is generally considered best
for overall performance of applications and migrations to wait for a
slower I/O activity period.
The following table compares the times required on a host with
minimal activity while an 8 GB migration was underway for each of
possible ThrottleValue setting. The performance that can be achieved

72 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Tips and best practices

in every environment will vary; these numbers are provided as an

overall guideline for expectations and, more importantly, as a
demonstration of the large-scale differences between settings.

ThrottleValue Time to sourceSelected

0 3 minutes

1 8 minutes

2 12 minutes

3 15 minutes

4 38 minutes

5 1 hour 4 minutes

6 1 hour 39 minutes

7 2 hours 6 minutes

8 4 hours 4 minutes

9 12 hours 23 minutes

Scripts
PowerPath Migration Enabler is designed to function on one pair of
devices at a time. However, there may be times when many devices
must be migrated at the same time. To aid in such a scenario, this
white paper contains some templates for scripts that were designed
to aid in large-scale migrations.
“Appendix: Scripts” on page 77 contains a series of scripts that can be
edited and tailored to assist in performing a migration using
PowerPath Migration Enabler.
Be aware that these scripts are not production code, and are provided
only to aid in understanding the process and to assist in the effective
use of PowerPath Migration Enabler.

Note: The final PowerPath Migration Enabler step of executing a cleanup of

the committed pairs is not provided. This step can be added or performed
manually.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 73

Tips and best practices

Identifying device The key to any successful migration, regardless of the tool used to
pairs perform the task, is proper planning. Before performing a migration,
the LUNs to be migrated must be identified, and the information
concerning these devices should be viewable from both the host
system and the arrays involved. The script VerifyPairsTSPairs.sh
uses this information to verify the migration pairs of source and
target devices on which PowerPath Migration Enabler will act.
“VerifyTSPairs.sh” on page 77 contains the script.

Setting up a group of If the migration to be performed involves only a small number of

pairs LUNs, executing the series of commands manually is probably
preferable. If the task is of a larger scale, however, or if the migration
requires automation, the script SetupPairs.sh can be used to set up a
selected list of source/target migration pairs. “SetupPairs.sh” on
page 82 contains the script.

Synchronizing data Once the source/target migration pairs are established within the
PowerPath Migration Enabler framework, the next step is to begin
the data transfer, while maintaining the consistency of the
information between the devices involved. The script SyncPairs.sh
can be used to initiate the data migration between the established
source/target pairs and report when complete. “SyncPairs.sh” on
page 87 contains the script.

Selecting targets and The last template script is supplied to provide a method for finishing
commiting the the migration in an automated fashion. PowerPath Migration Enabler
migration provides the ability to switch continually between the source and
target devices for testing purposes, and maintains consistent
mirrored copies of data on both devices (even through system
reboots). Once the powermig commit is executed, that consistency is
broken, and the data on the source device will be, for all intents and
purposes, unusable. Use caution when automating the final step of
any migration. Also be aware that once the commit is performed, you
cannot revert to the pre-migration configuration.
The script SelTargComPairs.sh is built to perform a selectTarget on
all pairs currently in the selectSource state. A variable in the script
can be set to perform the commit for these pairs.
“SelTargComPairs.sh” on page 93 contains the script.

74 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Conclusion

Conclusion
The ability to perform data migrations with the minimum
interruption to services is a major challenge through all industries.
The reasons are plentiful: the need to grow an environment, the need
to refresh equipment, the need for Information Lifecycle
Management strategies, and so on. EMC has identified the needs and
has supplied many tools to aid in this key function. From SRDF®,
MirrorView™, SAN Copy™, Open Migrator, Open Replicator and so
on, the ability to migrate data is critical.
PowerPath Migration Enabler addresses one of the most difficult
issues concerning the performance of data movement—time to
completion. With the use of PowerPath pseudo devices, downtime to
applications can virtually be eliminated, and the true value of the
replication technologies can be leveraged.

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 75

References

References
The following documents, available on EMC Powerlink™, contain
additional information. Note that all but the last two items are
available in the Powerlink Documentation and White Papers Library:
◆ PowerPath Version 5.0 Product Guide
◆ PowerPath for Solaris Version 5.0 Installation and Administration
Guide
◆ PowerPath for Solaris Version 5.0 Migration Enabler User’s Guide
◆ PowerPath for Solaris Version 5.0 Release Notes
◆ PowerPath for Solaris Version 5.0 Migration Enabler Release Notes
◆ Invista 1.0 Element Manager Administration Guide
◆ EMC Invista Deployment Scenarios (Powerlink EMC World
presentation)
◆ TS Kit: Open Replicator for Symmetrix Implementation Service
Send any comments or questions concerning this document to
cse-powerpath@EMC.com.

76 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

Appendix: Scripts
This appendix contains four scripts that can be tailored to assist in
performing a migration using PowerPath Migration Enabler. Be
aware that these scripts are not production code, and are provided
only to aid in understanding the process and to assist in the effective
use of PowerPath Migration Enabler.

VerifyTSPairs.sh
#!/usr/bin/sh
#
#---------------------------------------------------------------------
#
# File Name: VerifyTSPairs.sh
#
# Script Description: Script to supply detailed information
# about the source/target devices selected
# for a PowerPath Migration Enabler migration
#
#---------------------------------------------------------------------
#
# Author Identification
#
# SRT Steven R Thellen EMC
#
#---------------------------------------------------------------------
#
# Revision History
#
# REV Who Date Comment
# --- --- ---- -------
# 000 SRT 13-JUL-2006 Initial Release
#
#---------------------------------------------------------------------
#
#############################
#
# Script-specific variables

DAT=`date +%y%m%d_%H%M%S`
Sysn=`hostname`

#
##########
#
# OUTF -> location and name of output file

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 77

Appendix: Scripts

OUTF="PPmigVerf_${DAT}.out"

#
############
#
# WATCHERS -> If using the 'send_email_alarm' function,
# set this variable to contain list of recipients
# Example:
# WATCHERS="user1@company.com user2@company.com"

WATCHERS=""

#
# ENBmail -> Value 0 / 1
# 0 = No emails will be sent using the send_email_alarm function
# 1 = emails will be sent using the send_email_alarm function
ENBmail=0

#
##########
#
# DISPLAY -> Value 0 / 1
# 0 = No additional messages or information displayed
# 1 = Additional information and OUTF file displayed
#

DISPLAY=1
#
##########################################################
#
# dlist -> Populate the variable below with pairs of
# <Source device>:<Target device> separated by spaces
# Example:
# dlist="c4t0d16s2:c3t0d16s2 c4t0d17s2:c3t0d17s2"
#
# If this program is supplied with an additional file name
# on the command line, and populated with
# <Source device>:<Target device>
# in the format of one per line, then that will be the set
# acted upon.
# Example of file format:
# c4t0d16s2:c3t0d16s2
# c4t0d17s2:c3t0d17s2
# emcpower2a:emcpower21a
############################
# Edit the Variable below if you wish to execute using the "dlist"
variable

dlist=""

# Test is file name was supplied

78 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

SupFile=$1
if [ "${SupFile}X" = "X" ]
then
# No file was supplied / Test is dlist is valid
if [ "${dlist}X" = "X" ]
then
# Ok, no file and no dlist. We are exiting
echo " "
echo " <--------------------------------> "
echo " Sorry, but either a file with"
echo " the properly format info -or- "
echo " The 'dlist' variable must be set"
echo " Please try again with correct info"
echo " Thank You"
echo " <--------------------------------> "
echo " "
exit 1
else
# Ok, we have something in the dlist variable
# Lets attempt to proceed.
GO=3
fi
else
# Ok, let's test if file is valid
if test -f ${SupFile}
then
# Ok, found path to file, do quick test and populate dlist
QTest=`grep ":" ${SupFile} | wc -l`
if test $QTest -ge 1
then
# Passed quick test, attempt to populate
dlist=`grep -v "#" ${SupFile}`
GO=3
else
# No ":" found in SupFile, format can not be correct
echo " "
echo " <--------------------------------> "
echo " Sorry, but file is not in the"
echo " proper format "
echo " Please try again with correct info"
echo " Thank You"
echo " <--------------------------------> "
echo " "
exit 1
fi
else
# Path to the SupFile is not valid
echo " "
echo " <--------------------------------> "
echo " Sorry, but file: ${SupFile}"
echo " Not Found "
echo " Please try again with correct info"

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 79

Appendix: Scripts

echo " Thank You"

echo " <--------------------------------> "
echo " "
exit 1
fi
fi

#
#################################
#
# --> Subroutines <--
#
###############################################################
# FUNCTION NAME: send_email_alarm
# DESCRIPTION: send an alarm via email
#
# INPUTS: 1 - Subject of email
# 2 - who to send message to
# 3 - log file to mail
# OUTPUTS: None
#
############################################################
SEA_FILE=$OUTF
SEA_TO=$WATCHER
send_email_alarm()
{
# Give passed arguments meaningful names
#SEA_SUBJECT=$1
#SEA_TO=$2
#SEA_FILE=$3
if [ "${SEA_FILE}" = "" ]; then
SEA_FILE=/dev/null
fi
# Figure out which mailer to used based on the OS_TYPE
case ${OS_TYPE} in
"Linux")
MAIL=/bin/mail
;;
"SunOS")
MAIL=/usr/ucb/mail
$MAIL -s "$SEA_SUBJECT" $SEA_TO < $SEA_FILE 1>/dev/null 2>&1
;;
"HP-UX")
MAIL=/usr/bin/elm
cat $SEA_FILE | $MAIL -s "$SEA_SUBJECT" $SEA_TO 1>/dev/null 2>&1
;;
esac
}
#
#
#######################
#

80 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

# Main
#
#######

# Parse pair info as provided

echo " " > $OUTF

echo "Beginning run at `date` " >> $OUTF

for n in $dlist
do
src=`echo $n | sed s:s0:s2:g | awk -F: '{ print $1 }'`
tgt=`echo $n | sed s:s0:s2:g | awk -F: '{ print $2 }'`

# Populate header info

echo " ############################################# " >> $OUTF
echo " " >> $OUTF

if test $DISPLAY -ge 1

then
echo " src: $src " >> $OUTF
echo " src: $src "
else
echo " src: $src " >> $OUTF
fi
# Populate output file with $src device info
powermt display dev=${src} >> $OUTF

#
# .... proceed to target info for this pair

echo " " >> $OUTF

if test $DISPLAY -ge 1
then
echo " tgt: $tgt " >> $OUTF
echo " tgt: $tgt "
else
echo " tgt: $tgt " >> $OUTF
fi
# Populate output file with $tgt device info
powermt display dev=${tgt} >> $OUTF

echo " " >> $OUTF

# --> Repeat process till listed pairs complete
done
#
# Display output if selected
#
if test $DISPLAY -ge 1
then
cat $OUTF
fi

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 81

Appendix: Scripts

if test $ENBmail -ge 1

then
send_email_alarm "VerifyPair information for ${Sysn}"
fi

SetupPairs.sh
#!/usr/bin/sh
#
#---------------------------------------------------------------------
#
# File Name: SetupPairs.sh
#
# Script Description: Script to establish PowerPath Migration
# Enabler device pairs and report when complete
#
#---------------------------------------------------------------------
#
# Author Identification
#
# SRT Steven R Thellen EMC
#
#---------------------------------------------------------------------
#
# Revision History
#
# REV Who Date Comment
# --- --- ---- -------
# 000 SRT 13-JUL-2006 Initial Release
#
#---------------------------------------------------------------------
#
#############################
#
# Script-specific variables

DAT=`date +%y%m%d_%H%M%S`
Sysn=`hostname`
#
##########
#
# OUTF -> location and name of output file

OUTF="PPmigSetupinfo_${DAT}.out"
#
############
#
# TechType -> Select either OR for OpenReplicator or INVE for Invista
# (default: OR)
TechType=OR

82 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

#
############
#
# WATCHERS -> If using the 'send_email_alarm' function,
# set this variable to contain list of recipients
# Example:
# WATCHERS="user1@company.com user2@company.com"

WATCHERS=""

#
# ENBmail -> Value 0 / 1
# 0 = No emails will be sent using the send_email_alarm
# function
# 1 = emails will be sent using the send_email_alarm
# function
ENBmail=0

#
##########
#
# DISPLAY -> Value 0 / 1
# 0 = No additional messages or information displayed
# 1 = Additional information and OUTF file displayed
#

DISPLAY=0
#
##########################################################
#
# dlist -> Populate the variable below with pairs of
# <Source device>:<Target device> separated by spaces
# Example:
# dlist="c4t0d16s2:c3t0d16s2 c4t0d17s2:c3t0d17s2"
#
# If this program is supplied with an additional file name
# on the command line, and populated with
# <Source device>:<Target device>
# in the format of one per line, then that will be the set
# acted upon.
# Example of file format:
# c4t0d16s2:c3t0d16s2
# c4t0d17s2:c3t0d17s2
# emcpower2a:emcpower21a
###########################
# Edit the Variable below if you wish to execute using
# the "dlist" variable

dlist=""

# Test is file name was supplied

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 83

Appendix: Scripts

SupFile=$1
if [ "${SupFile}X" = "X" ]
then
# No file was supplied / Test is dlist is valid
if [ "${dlist}X" = "X" ]
then
# Ok, no file and no dlist. We are exiting
echo " "
echo " <--------------------------------> "
echo " Sorry, but either a file with"
echo " the properly format info -or- "
echo " The 'dlist' variable must be set"
echo " Please try again with correct info"
echo " Thank You"
echo " <--------------------------------> "
echo " "
exit 1
else
# Ok, we have something in the dlist variable
# Lets attempt to proceed.
GO=3
fi
else
# Ok, let's test if file is valid
if test -f ${SupFile}
then
# Ok, found path to file, do quick test and populate dlist
QTest=`grep ":" ${SupFile} | wc -l`
if test $QTest -ge 1
then
# Passed quick test, attempt to populate
dlist=`grep -v "#" ${SupFile}`
GO=3
else
# No ":" found in SupFile, format can not be correct
echo " "
echo " <--------------------------------> "
echo " Sorry, but file is not in the"
echo " proper format "
echo " Please try again with correct info"
echo " Thank You"
echo " <--------------------------------> "
echo " "
exit 1
fi
else
# Path to the SupFile is not valid
echo " "
echo " <--------------------------------> "
echo " Sorry, but file: ${SupFile}"
echo " Not Found "
echo " Please try again with correct info"

84 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

echo " Thank You"

echo " <--------------------------------> "
echo " "
exit 1
fi
fi

#
#################################
#
# --> Subroutines <--
#
#######################################################
#
# FUNCTION NAME: InfoPPmig
# DESCRIPTION: Collect information about current list of jobs
# scheduled to be executed
#
# INPUTS: none
#
# OUTPUTS: <Job Handle>:<Source dev>:<Target dev>:<Current Status>
#
##################################################################
#
InfoPPME ()
{
MigInfo=`powermig info -query -all |grep -v Source| grep -v "=" \
| awk '{ print $1":"$2":"$3":"$NF }'|grep -v "::"`
}
#
############################################################
#
# FUNCTION NAME: send_email_alarm
# DESCRIPTION: send an alarm via email
#
# INPUTS: 1 - Subject of email
# 2 - who to send message to
# 3 - log file to mail
# OUTPUTS: None
#
###########################################################
SEA_FILE=$OUTF
SEA_TO=$WATCHER
send_email_alarm()
{
# Give passed arguments meaningful names
#SEA_SUBJECT=$1
#SEA_TO=$2
#SEA_FILE=$3
if [ "${SEA_FILE}" = "" ]; then
SEA_FILE=/dev/null
fi

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 85

Appendix: Scripts

# Figure out which mailer to used based on the OS_TYPE

case ${OS_TYPE} in
"Linux")
MAIL=/bin/mail
;;
"SunOS")
MAIL=/usr/ucb/mail
$MAIL -s "$SEA_SUBJECT" $SEA_TO < $SEA_FILE 1>/dev/null 2>&1
;;
"HP-UX")
MAIL=/usr/bin/elm
cat $SEA_FILE | $MAIL -s "$SEA_SUBJECT" $SEA_TO 1>/dev/null 2>&1
;;
esac
}
#
#
#######################
#
# Main
#
#######

# Parse pair info as provided

echo " " > $OUTF

echo "Beginning run at `date` " >> $OUTF

for n in $dlist
do
src=`echo $n | sed s:s0:s2:g | awk -F: '{ print $1 }'`
tgt=`echo $n | sed s:s0:s2:g | awk -F: '{ print $2 }'`

# Populate header info

echo " ###################################################### " >>
$OUTF
echo " " >> $OUTF

if test $DISPLAY -ge 1

then
echo " src: $src " >> $OUTF
echo " src: $src "
else
echo " src: $src " >> $OUTF
fi
#
# .... proceed to target info for this pair

if test $DISPLAY -ge 1

then
echo " tgt: $tgt " >> $OUTF
echo " tgt: $tgt "

86 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

else
echo " tgt: $tgt " >> $OUTF
fi
echo " " >> $OUTF

#
# Now, we setup the src/tgt pairs for execution

powermig setup -tt ${TechType} -src ${src} -tgt ${tgt} -no 1>>${OUTF}
2>&1

# --> Repeat process till listed pairs complete

done
#
##################
#
# Now place info in OUTF
#
powermig info -query -all >> $OUTF
#
##################
#
# Lastly, verify that no errors were encountered
#
TERR=`grep -i err $OUTF | wc -l`
if test $TERR -ge 1
then
if test $ENBmail -ge 1
then
send_email_alarm "PPMigration Setup Error ${Sysn}"
else
echo " "
echo " ---> PPMigration Setup Error ! ! ! <--- "
echo " "
fi
fi
#
if test $DISPLAY -ge 1
then
cat $OUTF
fi
#
# End

SyncPairs.sh
#!/usr/bin/sh
#
#---------------------------------------------------------------------
#

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 87

Appendix: Scripts

# File Name: SyncPairs.sh

#
# Script Description: Script to will examine current state of PowerPath
# Migration Enabler database and commences the sync
# process on ANY jobs that are presently in the
# "setup" state.
#
# Additionally, will provide control of the
# powermig throttle_value to aid in management of
# the Open Replicator resources and performance
# of migration
#
# Lastly, if desired, will report when all
# migrations are complete
# Note:(additional configuration required)
#
#---------------------------------------------------------------------
#
# Author Identification
#
# SRT Steven R Thellen EMC
#
#---------------------------------------------------------------------
#
# Revision History
#
# REV Who Date Comment
# --- --- ---- -------
# 000 SRT 13-JUL-2006 Initial Release
#
#---------------------------------------------------------------------
#
#############################
#
# Script-specific variables

DAT=`date +%y%m%d_%H%M%S`
Sysn=`hostname`
#
##########
#
# OUTF -> location and name of output file

OUTF="PPmigSyncinfo_${DAT}.out"
#
############
#
# ThrottleValue -> Select value between 0 and 9
# 0 = Fastest/Most resources consumed
# 9 = Slowest/Least resources consumed
# (default: 5)

88 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

ThrottleValue=0
#
############
#
# MonTillDone -> Value 0 -or- 1
# This variable will enable the Monitoring till done
# functionality. If set to '1', this script will
# continue to execute and wait till ALL migrations
# have completed before sending a report.
#
# Set to '0' (default) and a report will be generated
# immediately
#

MonTillDone=0
#
# RepInt -> This is the report interval in seconds to wait to check on
# progress of migrations monitored

RepInt=180
#
#
############
#
# WATCHERS -> If using the 'send_email_alarm' function,
# set this variable to contain list of recipients
# Example:
# WATCHERS="user1@company.com user2@company.com"
#

WATCHERS=""
#
# ENBmail -> Value 0 / 1
# 0 = No emails will be sent using the send_email_alarm
# function
# 1 = emails will be sent using the send_email_alarm
# function

ENBmail=0
#
##########
#
# DISPLAY -> Value 0 / 1
# 0 = No additional messages or information displayed
# 1 = Additional information and OUTF file displayed
#

DISPLAY=0
#
##########################################################
#
# --> Subroutines <--

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 89

Appendix: Scripts

#
################################################################
#
# FUNCTION NAME: InfoPPmig
# DESCRIPTION: Collect information about current list of jobs
# scheduled to be executed
#
# INPUTS: none
#
# OUTPUTS: <Job Handle>:<Source dev>:<Target dev>:<Current Status>
#
###############################################################
#
InfoPPmig ()
{
MigInfo=`powermig info -query -all |grep -v Source| grep -v "=" \
| awk '{ print $1":"$2":"$3":"$NF }'|grep -v "::"`
}
#
######################################################
#
# FUNCTION NAME: send_email_alarm
# DESCRIPTION: send an alarm via email
#
# INPUTS: 1 - Subject of email
# 2 - who to send message to
# 3 - log file to mail
# OUTPUTS: None
#
#######################################################
SEA_FILE=$OUTF
SEA_TO=$WATCHER
send_email_alarm()
{
# Give passed arguments meaningful names
#SEA_SUBJECT=$1
#SEA_TO=$2
#SEA_FILE=$3
if [ "${SEA_FILE}" = "" ]; then
SEA_FILE=/dev/null
fi
# Figure out which mailer to used based on the OS_TYPE
case ${OS_TYPE} in
"Linux")
MAIL=/bin/mail
;;
"SunOS")
MAIL=/usr/ucb/mail
$MAIL -s "$SEA_SUBJECT" $SEA_TO < $SEA_FILE 1>/dev/null 2>&1
;;
"HP-UX")
MAIL=/usr/bin/elm

90 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

cat $SEA_FILE | $MAIL -s "$SEA_SUBJECT" $SEA_TO 1>/dev/null 2>&1

;;
esac
#
}
#
#
#######################
#
# Main
#
#######
# Parse pair info as provided

echo " " > $OUTF

echo "Beginning run at `date` " >> $OUTF

#
# First, get the current list of setup jobs
#
InfoPPmig

for n in $MigInfo
do
# Check if handle is in 'setup' state
state=`echo $n | awk -F: '{ print $NF }'`
if [ "${state}X" = "setupX" ]
then
# Get 'handle' and start sync with preset ThrottleValue
handle=`echo $n | awk -F: '{ print $1 }'`

powermig sync -hd ${handle} -noPrompt 1>>${OUTF} 2>&1

powermig throttle -hd ${handle} -tv ${ThrottleValue} -no 1>>${OUTF} 2>&1
fi

# --> Repeat process till listed pairs complete

done
#
##################
#
# Now place info in OUTF
#
powermig info -query -all >> $OUTF
#
##################
#
# Lastly, verify that no errors were encountered
#
TERR=`grep -i err $OUTF | wc -l`
if test $TERR -ge 1
then
# Error(s) encounter alert - uncomment to send email alarm

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 91

Appendix: Scripts

if test $ENBmail -ge 1

then
send_email_alarm "PPMigration Setup Error"
else
echo " "
echo " ---> PPMigration Setup Error ! ! ! <--- "
echo " "
fi
fi
#
###############
#
# If MonTillDone enabled, commence loop
#
if test $MonTillDone -ge 1
then
WT=1
until [ ${WT} -eq 0 ]
do
Tsync=0

InfoPPmig

for n in $MigInfo
do
Tstate=`echo $n | grep sync | wc -l`
Tsync=`echo $Tsync $Tstate`
done
Tst=`echo $Tsync | grep 1 | wc -l`
if test $Tst -eq 0
then
# No jobs currently in 'sync' state - send report

powermig info -query -all >> $OUTF

echo " " >> $OUTF
echo " Jobs completed: `date` " >> $OUTF
echo " " >> $OUTF
WT=0
else
# Someone still running, update log file
echo "##############################################" >> $OUTF
echo " Still executing at: `date` " >> $OUTF
powermig info -query -all >> $OUTF
echo "##############################################" >> $OUTF

sleep $RepInt
fi
done
else
# Send status now
if test $ENBmail -ge 1
then

92 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

send_email_alarm "Status of PPMig on ${Sysn}"

else
if test $DISPLAY -ge 1
then
cat $OUTF
fi
fi
fi
# End

SelTargComPairs.sh
#!/usr/bin/sh
#
#---------------------------------------------------------------------
#
# File Name: SelTargComPairs.sh
#
# Script Description: Script to will examine current state of PowerPath
# Migration Enabler database and perform a
# 'selectTarget' on ALL devices in the
# 'sourceSelected' state.
#
# In addition, if desired, a 'commit' will be
# performed on ALL devices in the 'targetSelected'
# state.
#
# PLEASE USE EXTREME CAUTION!!!
#
# Once a device pair has been commited, the data on
# the 'source' device will no longer be readily
# available.
#
# Lastly, if desired, will report when all migrations
# are complete (additional configuration required)
#
#---------------------------------------------------------------------
#
# Author Identification
#
# SRT Steven R Thellen EMC
#
#---------------------------------------------------------------------
#
# Revision History
#
# REV Who Date Comment
# --- --- ---- -------
# 000 SRT 13-JUL-2006 Initial Release
#

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 93

Appendix: Scripts

#---------------------------------------------------------------------
#
#############################
#
# Script-specific variables

DAT=`date +%y%m%d_%H%M%S`
Sysn=`hostname`
#
##########
#
# OUTF -> location and name of output file

OUTF="PPmigComitinfo_${DAT}.out"
#
############
#
# DO_COMMIT -> Value 0 / 1
# 0 -> (default) Do NOT perform commit, just set to
# 'targetSelected' state
# 1 -> After completing the 'selectTraget', attempt
# to perform the 'commit'
# USE EXTREME CAUTION

DO_COMMIT=0
#
############
#
# WATCHERS -> If using the 'send_email_alarm' function,
# set this variable to contain list of recipients
# Example:
# WATCHERS="user1@company.com user2@company.com"
#

WATCHERS=""
#
# ENBmail -> Value 0 / 1
# 0 = No emails will be sent using the send_email_alarm
# function
# 1 = emails will be sent using the send_email_alarm
# function

ENBmail=0
#
##########
#
# DISPLAY -> Value 0 / 1
# 0 = No additional messages or information displayed
# 1 = Additional information and OUTF file displayed
#

DISPLAY=0

94 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

#
##########################################################
#
# --> Subroutines <--
#
##########################################################
#
# FUNCTION NAME: InfoPPmig
# DESCRIPTION: Collect information about current list of jobs
# scheduled to be executed
#
# INPUTS: none
#
# OUTPUTS: <Job Handle>:<Source dev>:<Target dev>:<Current Status>
#
##########################################################
#
InfoPPmig ()
{
MigInfo=`powermig info -query -all |grep -v Source| grep -v "=" \
| awk '{ print $1":"$2":"$3":"$NF }'|grep -v "::"`
}
#
######################################################################
########
#
# FUNCTION NAME: send_email_alarm
# DESCRIPTION: send an alarm via email
#
# INPUTS: 1 - Subject of email
# 2 - who to send message to
# 3 - log file to mail
# OUTPUTS: None
#
######################################################################
########
SEA_FILE=$OUTF
SEA_TO=$WATCHER
send_email_alarm()
{
# Give passed arguments meaningful names
#SEA_SUBJECT=$1
#SEA_TO=$2
#SEA_FILE=$3
if [ "${SEA_FILE}" = "" ]; then
SEA_FILE=/dev/null
fi
# Figure out which mailer to used based on the OS_TYPE
case ${OS_TYPE} in
"Linux")
MAIL=/bin/mail
;;

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 95

Appendix: Scripts

"SunOS")
MAIL=/usr/ucb/mail
$MAIL -s "$SEA_SUBJECT" $SEA_TO < $SEA_FILE 1>/dev/null 2>&1
;;
"HP-UX")
MAIL=/usr/bin/elm
cat $SEA_FILE | $MAIL -s "$SEA_SUBJECT" $SEA_TO 1>/dev/null 2>&1
;;
esac

}
#
#
#######################
#
# Main
#
#######

# Parse pair info as provided

echo " " > $OUTF

echo "Beginning run at `date` " >> $OUTF

#
# First, get the current list of setup jobs
#
InfoPPmig

for n in $MigInfo
do
# Get 'handle' and prepare to 'commit'
handle=`echo $n | awk -F: '{ print $1 }'`

# Check if handle is in 'sourceSelected' state

state=`echo $n | awk -F: '{ print $NF }'`

if [ "${state}X" = "sourceSelectedX" ]
then
# Perform selectTarget
powermig selectTarget -hd ${handle} -noPrompt 1>>${OUTF} 2>&1
sleep 5
fi

# If DO_COMMIT is set, check to see if this one is ready

if test $DO_COMMIT -ge 1
then
# Get updated state information
state=`powermig info -query -hd ${handle}|grep ${handle}|awk '{ print
$NF }'`
if [ "${state}X" = "targetSelectedX" ]
then

96 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

 Appendix: Scripts

# Perform commit
powermig commit -hd ${handle} -noPrompt 1>>${OUTF} 2>&1
else
echo "state is ${state}"
fi

# IF this is a native device migration...

# 'powermig undoRedirect -hd <#>'
# will need to be performed AFTER the application is disabled
# and reconfigured to use new device location

# Check if handle is in 'committedAndRedirected' state

# Get updated state information
state=`powermig info -query -hd ${handle}|grep ${handle}|awk '{ print
$NF }'`
if [ "${state}X" = "committedAndRedirectedX" ]
then
echo " " >> $OUTF
echo " PP Migration: ${handle} requires " >> $OUTF
echo " 'powermig undoRedirect' be performed " >> $OUTF
echo " " >> $OUTF
fi
fi

# --> Repeat process till listed pairs complete

done
#
##################
#
# Now place info in OUTF
#
powermig info -query -all >> $OUTF
#
##################
#
# Lastly, verify that no errors were encountered
#
TERR=`grep -i err $OUTF | wc -l`
if test $TERR -ge 1
then
# Error(s) encounter alert - uncomment to send email alarm
if test $ENBmail -ge 1
then
send_email_alarm "PPMigration commit Error"
else
echo " "
echo " ---> PPMigration commit Error ! ! ! <--- "
echo " "
fi
fi
#
###############

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 97

Appendix: Scripts

#
# Send status now
if test $ENBmail -ge 1
then
send_email_alarm "Status of PPMig on ${Sysn}"
else
if test $DISPLAY -ge 1
then
cat $OUTF
fi
fi
#
# End

98 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments