White Paper
EMC POWERPATH
WPAR Data Migration using PowerPath
Migration Enabler
Abstract
This white paper focuses on WPAR migration using EMC PowerPath
Migration enabler Host Copy, which is entirely host-based. It moves
WPAR data nondisruptively from a source to a target while application
is online on WPAR. This paper covers procedure, recommendations to
do WPAR migration using PPME.
January 2014
1
Table of Contents
Abstract ..................................................................................................................................................... 1
Executive Summary................................................................................................................................... 3
Introduction .............................................................................................................................................. 4
Audience ................................................................................................................................................... 4
WPARS....................................................................................................................................................... 5
WPAR migration support with EMC PPME ............................................................................................... 6
Migration Process ..................................................................................................................................... 7
Prerequisites ......................................................................................................................................... 7
Preparation ........................................................................................................................................... 8
Procedure to perform migration ............................................................................................................ 10
Setup: .................................................................................................................................................. 10
Synchronization................................................................................................................................... 11
SourceSelected.................................................................................................................................... 12
TargetSelected .................................................................................................................................... 13
Commit................................................................................................................................................ 13
Abort ................................................................................................................................................... 14
Cleanup ............................................................................................................................................... 15
Post Migration..................................................................................................................................... 16
Conclusion ............................................................................................................................................... 17
2
Executive Summary
Workload partitions (WPARs) provide a software solution for creating virtualized operating-system
environments for managing multiple workloads. A WPAR is a software-created, virtualized OS
environment within a single AIX image. Each workload partition is a secure and isolated environment for
the application it hosts. The application in a WPAR thinks that it is being executed in its own dedicated
AIX instance.
There are two types of Workload partitions:
System WPAR: almost a full AIX environment.
Application WPAR: a light environment suitable for execution of one or more processes.
WPARs data would be required to migrate for number of scenarios including, Consolidation of storage
arrays, supportability requirements, technology refresh. There are different types of migration options
available to leverage which includes array based migration, host based tools. Every migration has
potential to disrupt application availability and data integrity. This disruption may cause productivity and
revenue loss to business. Choosing the appropriate solution for data migration depends on several
factors such as ease of configuration and management, rate of data movement and cost.
EMC PowerPath migration enabler enables organizations to migrate System WPARs data seamlessly in a
non-disruptive manner. EMC PowerPath migration enabler requires very minimal of planning effort and
reduces the amount of time taken to migrate data and the costs associated with any data migration.
This paper provides recommendations and procedure to migrate System WPARs data seamlessly by
using EMC PowerPath Migration enabler.
3
Introduction
In AIX 6.1 and AIX 7.1, workload partitions (WPARs) provides an additional operating system softwarebased layer for the virtualization of operating environments. Each WPAR can host applications and
isolate them from applications executing within other WPARs. WPARs work with data storage at the file
system level.
Storage migrations are often performed in order to handle storage growth, consolidation of storage
boxes or data centers, supportability requirements or technology refresh to achieve higher
performance. Data migration can adversely impact application availability and performance. This
process can be very complex, time-consuming and requires proper planning. This white paper presents
migration of System WPAR running on AIX 6.1 and AIX 7.1 seamlessly by using EMC PowerPath
Migration Enabler.
Audience
This white paper is intended for EMC employees, partners and customers who intend to perform
migration of WPAR data between storage arrays or logical units within a storage system using EMC
PowerPath Migration Enabler.
4
WPARS
WPARs are virtualized operating system environments that are created within a single AIX image.
Operating system virtualization through WPAR technology allows more granular approach of resource
management. It does this by sharing OS images across WPARs and provides most efficient use of
Hardware resources. WPARs secure and isolate the environment for the processes and signals that are
used by applications
There are two types of WPARs
1) System WPARs
2) Application WPARs
The system WPAR is much closer to a complete version of AIX. The system WPAR has its own dedicated,
completely writable filesystems along with its own inetd and cron. Application WPARs are real
lightweight versions of virtualized OS environments. They are extremely limited and can only run
application processes, not system daemons such as inetd or cron. One cannot even define remote
access to this environment. These are only temporarily objects; they actually disintegrate when the final
process of the application partition ends, and as such, are more geared to execute processes than entire
applications. WPARs provide the flexibility of creating new environments without having to create and
manage new AIX partitions.
Within AIX 7.1, WPARs has the capability to run AIX 5.2 partitions which are referred as Versioned
workload partitions. A versioned workload partition (WPAR) provides a different version runtime
environment than the global system. These are identical in structure to the AIX 7.1 WPAR, but the
application is executed within an environment using the AIX 5.2 system libraries and commands.
Figure 1 - Global instance and System WPARs
5
WPAR migration support with EMC PPME
By using EMC PowerPath Migration Enabler, System WPAR configured with shared rootvg’s
user/application data can be migrated from one disk to another while WPAR continue to run. These
disks can be on the same storage array or they can be on different storage arrays. Data Migration by
using PPME will reduce the risk of migration and has the capability to migrate data nondisruptively.
However System WPARs configured with dedicated rootvg cannot be migrated by using EMC PowerPath
Migration Enabler as PowerPath does not support boot disk migration.
Figure 2 - WPARs running with shared rootvg
6
Migration Process
Prerequisites
 Check appropriate migration license is added for PowerPath by executing “emcpreg –l”
command.
For Eg.
bash-4.0# emcpreg -l
Key XXXX-XXXX-XXXX-XXXX-XXXX-XXXX
Product: PowerPath
Capabilities: All
If necessary PowerPath license is not installed, Install by executing “emcpreg –add” command as
follows:
For Eg.
bash-4.0# emcpreg -add XXXX-XXXX-XXXX-XXXX-XXXX-XXXX
1 key(s) successfully added.
bash-4.0# emcpreg -l
Key XXXX-XXXX-XXXX-XXXX-XXXX-XXXX
Product: PowerPath
Capabilities: All
Key XXXX-XXXX-XXXX-XXXX-XXXX-XXXX
Product: PowerPath Migration Enabler
Capabilities: HOSTCOPY
 Make target devices visible to the host by provisioning Luns and ensure that these devices are
under PowerPath control.
 The target device must be the same size or larger than the source device.
 The target device cannot be in use by any application.
7
Preparation
 Perform Health check of complete system
 Check “powermt display” output for any errors or Dead paths.
 Identify source device for migration
 Identify target device for migration
 Collect “powermt display dev=all” output and note “Array ID”, “Logical device ID” of devices
involved in migration
For eg:
In the following example device with logical device id “036F” is used as source device and logical
device id “0137” is used as target device:
Source device:
bash-4.0# powermt display dev=hdiskpower4
Pseudo name=hdiskpower4
Symmetrix ID=000194901016
Logical device ID=036F
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
=========================================================================
1 fscsi1
hdisk151 FA 7fA active alive
0 0
1 fscsi1
hdisk181 FA 8fA active alive
0 0
0 fscsi0
hdisk44 FA 7fA active alive
0 0
0 fscsi0
hdisk74 FA 8fA active alive
0 0
Target device:
bash-4.0# powermt display dev=hdiskpower27
Pseudo name=hdiskpower27
Symmetrix ID=000194901016
Logical device ID=0137
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
=========================================================================
1 fscsi1
hdisk174 FA 7fA active alive
0 0
1 fscsi1
hdisk204 FA 8fA active alive
0 0
0 fscsi0
hdisk67 FA 7fA active alive
0 0
0 fscsi0
hdisk97 FA 8fA active alive
0 0
8
Check for max_transfer parameter set for devices pertaining to migration by executing
“lsattr –El hdiskpowerX” command as follows.
For eg:
bash-4.0# lsattr -El hdiskpower4
PR_key_value none
Reserve Key.
True
clr_q
yes
Clear Queue (RS/6000)
True
location
Location
True
lun_id
0x1b000000000000
LUN ID
False
lun_reset_spt yes
FC Forced Open LUN
True
max_coalesce 0x100000
Maximum coalesce size
True
max_transfer 0x800000
Maximum transfer size
True
pvid
000e63c10118c5720000000000000000 Physical volume identifier
False
pvid_takeover yes
Takeover PVIDs from hdisks
True
q_err
no
Use QERR bit
True
q_type
simple
Queue TYPE
False
queue_depth 16
Queue DEPTH
True
reassign_to 120
REASSIGN time out value
True
reserve_policy single_path
Reserve Policy used to reserve device on open.
True
rw_timeout 40
READ/WRITE time out
True
scsi_id
0x670038
SCSI ID
False
start_timeout 180
START unit time out
True
ww_name
0x50000972c00fe15c
World Wide Name
False
 Set “max_transfer” value of target migration device as same as source device as follows:
#chdev –l hdiskpowerX –a max_transfer=<same size of source> -P
 Check duplicate odm entries by running “lsattr -El hdiskpowerX” for both Source and Target
device.
NOTE: If duplicate entries are present, halt PPME preparation and contact PowerPath support
team.
 Check PdAt attributes if present as well through odmget command as follows:
#odmget -q"uniquetype=disk/fcp/SYMMETRIX and attribute like 'reserve_*'" PdAt
 Check Source and Target device reserve_policy by executing “lsattr -El hdiskpowerX” command.
Target device reserve_policy need to set same as source device. Need to set/change
reserve_policy for native paths as well as pseudo devices.
# chdev –l hdiskpower<target> -a reserve_policy=<same as source> -P
9
 Check log messages for any alerts/errors related to Filesystem, disk or I/O Cards. If there are any
critical alerts/warning, resolve it before proceeding further.
 Check that the devices are not part of another migration by executing
“powermig info -query –all” command
 If there are any pending migrations, cleanup or complete the pending migrations.
 Collect complete configuration details of system (EMCGrab) for future reference.
Procedure to perform migration
The following procedure provides PPME migration steps. Please refer PPME product guide for detailed
explanation of the steps given below.
Setup:
After the prerequisites are met, run powermig setup command to enter the Setup state.
Perform the following actions:
 Specify the source and target device names.
 Specify the technology type.
 Optionally set the throttle values to configure the migration speed of the synchronization and
host copy ceiling.
For Eg.
bash-4.0# powermig setup -src hdiskpower4 -tgt hdiskpower27 -techType HOSTCOPY
Setup migration? [yes]/no: yes
Migration Handle = 1
Check the status:
bash-4.0# powermig info -query -all
===============================================
Hnd Source
Target
Tech State
=== =========== ============ ======== =====
1 hdiskpower4 hdiskpower27 HostCopy setup
10
Figure 3 - WPAR data migration
Synchronization
After the Setup state, run powermig sync command to enter the Syncing state. You must specify the
handle (returned from Setup) for the migration pair. In the Syncing state, host applications continue to
access the source logical unit, as data is copied to the target. Migration Enabler also ensures all new host
writes are written to both source and target.
The time for completing synchronization depends on various factors including the size of the logical
(Source) unit, Data volume on the Logical unit and application IO load.
For Eg.
bash-4.0# powermig sync -handle 1
Start sync? [yes]/no: yes
11
While the migration is syncing, check the status:
(or)
bash-4.0# powermig info -query -all
=====================================================
Hnd Source
Target
Tech State
=== =========== ============ ======== ===========
1 hdiskpower4 hdiskpower27 HostCopy syncing(1%)
bash-4.0# powermig -handle 1 query
Handle: 1
Source: hdiskpower4 (5.00 GB, thin)
Target: hdiskpower27 (5.00 GB, thin)
Technology: HostCopy
Migration state: syncing
Throttle Value: 2
Percent InSync: 7% (371.50 MB copied)
While in the Syncing state, you can perform the following options:
 Query one or more migrations to determine percentage completion and throttle value.
 Speed up or slow down the synchronization rate by changing the throttle value.
 Optionally control the speed of synchronization by setting the Host Copy ceiling (in MB/s).
 Optionally pause the migration and then resume at a later time.
 Abort the migration, returning it to the Setup state.
SourceSelected
After all data has been copied from source to target, the migration enters the SourceSelected state
when the following occurs:
 I/O reads are directed to the source.
 I/O writes are written to the source and target to keep them synchronized.
For Eg.
bash-4.0# powermig info -query -all
========================================================
Hnd Source
Target
Tech State
=== =========== ============ ======== ==============
1 hdiskpower4 hdiskpower27 HostCopy SourceSelected
12
From the SourceSelected state, you can:
 Transition to the TargetSelected state.
 Optionally abort the migration and return the migration to the Setup state
TargetSelected
When you execute powermig selectTarget command, the migration transitions to the TargetSelected
state from the SourceSelected state. The TargetSelected state must be entered before committing the
migration. In this state, all I/O reads are sent to the target while writes continue to be written to both
source and target. This gives an opportunity to determine that all data is intact on the target.
After entering the TargetSelected state, perform the following actions:
 Move to the Committed state
 Optionally abort the migration and return the migration to the Setup state.
 Optionally return to the SourceSelected state.
For Eg.
bash-4.0# powermig -handle 1 selectTarget
Transition to targetSelected state? [yes]/no: yes
Check the status:
bash-4.0# powermig info -query -all
========================================================
Hnd Source
Target
Tech State
=== =========== ============ ======== ==============
1 hdiskpower4 hdiskpower27 HostCopy targetSelected
Commit
The Commit state permanently designates the target as the recipient of all I/O requests. After this
command is run, PowerPath Migration Enabler no longer keeps the source and target synchronized, and
I/O is no longer sent to the source.
13
For Eg.
bash-4.0# powermig commit -handle 1
Commit migration? [yes]/no: yes
Check the status:
bash-4.0# powermig info -query -all
===================================================
Hnd Source
Target
Tech State
=== =========== ============ ======== =========
1 hdiskpower4 hdiskpower27 HostCopy committed
To successfully enter the Commit state, PowerPath Migration Enabler performs the following actions:
 When committing pseudo device mapping of source and target LUNs are swapped, allowing an
application to continue using the original source pseudo device without any disruption.
NOTE:
Once in the Commit state, there is no returning to the previous state.
 All reads and writes are directed to the target.
 The source and target are no longer synchronized.
Abort
Optionally you can abort the migration and return the migration to the Setup state as follows:
For Eg.
bash-4.0# powermig info -query -all
=====================================================
Hnd Source
Target
Tech State
=== =========== ============ ======== ===========
1 hdiskpower4 hdiskpower27 HostCopy syncing(1%)
2 hdiskpower5 hdiskpower28 HostCopy setup
bash-4.0# powermig abort -handle 1 -no
14
bash-4.0# powermig info -query -all
===============================================
Hnd Source
Target
Tech State
=== =========== ============ ======== =====
1 hdiskpower4 hdiskpower27 HostCopy setup
2 hdiskpower5 hdiskpower28 HostCopy setup
Cleanup
Cleanup is the final step in the migration process or after abort of any migration.
 When entered from the Commit state, powermig cleanup command removes enough data from
the former source device to prevent the existence of two identical logical units, ensuring that
the operating system or applications do not become confused.
For Eg.
bash-4.0# powermig cleanup -handle 1
Cleanup migration? [yes]/no: yes
Check the status:
bash-4.0# powermig info -query –all
No migrations found.
15
Post Migration
 Collect “powermt display dev=all” output and note “Symmetrix ID”, “Logical device ID” of
devices involved in migration.
 After migration successfully completed as shown above, “Symmetrix ID”, “Logical device ID” of
source and target devices will be swapped as shown below:
For Eg.
bash-4.0# powermt display dev=hdiskpower4
Pseudo name=hdiskpower4
Symmetrix ID=000194901016
Logical device ID=0137
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
=========================================================================
1 fscsi1
hdisk174 FA 7fA active alive
0 0
1 fscsi1
hdisk204 FA 8fA active alive
0 0
0 fscsi0
hdisk67 FA 7fA active alive
0 0
0 fscsi0
hdisk97 FA 8fA active alive
0 0
Before migration “hdiskpower4” was mapped to “Symmetrix ID=000194901016“ and
“Logical device ID=036F”.
bash-4.0# powermt display dev=hdiskpower27
Pseudo name=hdiskpower27
Symmetrix ID=000194901016
Logical device ID=036F
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
=========================================================================
1 fscsi1
hdisk151 FA 7fA active alive
0 0
1 fscsi1
hdisk181 FA 8fA active alive
0 0
0 fscsi0
hdisk44 FA 7fA active alive
0 0
0 fscsi0
hdisk74 FA 8fA active alive
0 0
Before migration “hdiskpower27” was mapped to “Symmetrix ID=000194901016“ and
“Logical device ID=0137”
16
Figure 4 - WPAR data migration
Conclusion
EMC PowerPath Migration Enabler is a free migration tool that enables non-disruptive WPAR data
migration between storage systems or between logical units within a single storage system. EMC PPME
resides on the host and allows WPAR to have continued data access through the migration process. By
using EMC PPME WPAR data can even migrated to third party storage systems.
17