Logical Migration Using mksysb Backup and rsync – AIX LPAR Migration Procedure

This procedure describes how to perform a logical migration of an existing AIX LPAR to a new target LPAR using a combination of mksysb for restoring the OS and system configuration (rootvg) and rsync for transferring and synchronizing application/data filesystems (datavg).

This approach is suitable when the source and target reside on different storage subsystems or when SAN-level cloning is not possible. It allows the target LPAR to be built from the source system image, while application data is synchronized over the network, ensuring minimal downtime during the final cutover.

The process is fully controlled, reproducible, and allows incremental data synchronization to maintain consistency until the last moment.

Objective:

• Rebuild the target LPAR using mksysb for the OS and system configuration.
• Migrate application and database data using rsync, preserving file ownership, permissions, and timestamps.
• Enable a controlled cutover with minimal downtime.
• Ensure the target system is functionally equivalent to the source LPAR.

Scope:

• Migration of AIX operating system (rootvg) and application/data (datavg) from source LPAR to target LPAR.
• Target system restored from a mksysb image.
• Application/data synchronized using rsync.
• Suitable for environments with different storage subsystems or network-based replication.

Pre-Requisites:

• NIM server configured and reachable by the target LPAR.
• Target LUNs for rootvg and datavg allocated and mapped to the target LPAR.
• Network connectivity between source and target LPARs for rsync.
• Sufficient disk space on the target LPAR for the source data.
• Downtime window scheduled for final rsync and cutover.
• Application and database owners available for validation and controlled stop/start.

Step-by-Step Migration Procedure:

1. Create Target LPAR Profile
From HMC, create a new LPAR profile:
Configure CPU, memory, and adapter settings (match source or new specifications).
Add virtual FC adapters for SAN zoning.
Add virtual Ethernet adapters for network access.

2. Provide WWNs to Storage Team
Share target LPAR WWPNs with storage team.
Verify WWPN login:
# chnportlogin -m <manage_system> -o login -p <LPAR>
# lsnportlogin -m <manage_system> --filter "lpar_names=<LPAR>"

3. Storage Team: Allocate and Map LUNs
Allocate LUNs matching source rootvg and datavg sizes.
Map LUNs to target LPAR via virtual FC adapters.

4. Create mksysb Backup on Source LPAR
# mksysb -ieX /backup/$(hostname)_$(date +%Y%m%d)
# lsmksysb -lf /backup/$(hostname)_$(date +%Y%m%d)
Captures full system image including OS, rootvg, and configuration.

5. Transfer mksysb to NIM Server
# scp /backup/<hostname>_<date>.mksysb target_nimserver:/export/mksysb/

6. target NIM Server define NIM Resources
On NIM master, define backup and client:
# nim -o define -t mksysb -a server=master -a location=/export/mksysb/<file> mksysb_<hostname>
# nim -o define -t spot -a source=mksysb_<hostname> spot_<hostname>
# nim -o define -t client -a platform=chrp -a if1="net_<network> <target_ip> <target_hostname>" target_lpar

7. Install Target LPAR Using mksysb
Boot target LPAR via network (SMS menu).
Start NIM installation:
# nim -o bos_inst -a source=mksysb -a spot=spot_<hostname> -a mksysb=mksysb_<hostname> -a accept_licenses=yes target_lpar
Target system will have the same AIX configuration as source.
Reference: Building AIX LPAR using mksysb

8. Post-Installation Configuration
# hostname <new_hostname>
# chdev -l inet0 -a hostname=<new_hostname>
# chdev -l en0 -a netaddr=<new_ip> -a netmask=<mask> -a gateway=<gateway>
Update /etc/hosts and /etc/resolv.conf.
Verify connectivity:
# ping <gateway>

9. Create datavg on Target LPAR
# mkvg -y datavg hdiskX hdiskY
# mklv -t jfs2 -y lvname datavg <size>
# crfs -v jfs2 -d lvname -m /data/app -A yes -p rw
# mount -a
Recreate logical volumes and filesystems to match source layout.

10. rsync Data from Source to Target
Initial sync while source is online:

Login to the target LPAR and run:
# rsync -avz --progress root@source:/data/ /data/
Final sync during cutover window after stopping apps:
# rsync -avz --delete root@source:/data/ /data/
Preserves file ownership, permissions, and timestamps.

11. Application Cutover
Stop database and applications on source LPAR.
Perform final rsync.
Shutdown source LPAR:
# shutdown -F
Update DNS to target LPAR IP.
Start applications and database on target.

12. Post-Migration Validation
# oslevel -s
# lsvg -o
# df -g
# lsdev -Cc disk
# bootlist -om normal
# errpt -a | more
Verify all filesystems are mounted correctly.
Confirm applications and databases start and function as expected.

Fallback / Rollback Plan — Logical Migration (AIX LPAR):

Purpose:

To restore operations to the original source LPAR in case of a failure during migration or if post-migration validation on the target LPAR identifies critical issues. This ensures rapid restoration of services with minimal downtime and data loss.

Fallback Procedure:

1. Shutdown Target LPAR

Stop all applications and database services gracefully on the target LPAR.

Shutdown the LPAR:

# shutdown -F

Confirm the LPAR is powered off via HMC or CLI:

# lssyscfg -r lpar -m <managed_system> -F name,state

2. Revert DNS Configuration

Update DNS records to point back to the source LPAR IP address.

Confirm that clients and network services will resolve to the original source.

3. Start Source LPAR

Power on the source LPAR from HMC or CLI:

# chsysstate -r lpar -m <managed_system> -o on -n <source_LPAR>

Verify the system boots successfully and rootvg disks are accessible.

4. Mount Filesystems

Ensure all volume groups and filesystems are mounted:

# mount -a

# df -g

5. Start Database and Applications

Start database and application services on the source LPAR.

Validate application and database accessibility to confirm full service restoration.

Notes:

• Keep the target LPAR powered off until the issue is resolved to avoid conflicts with IPs, DNS, or shared storage.
• Document any errors observed on the target LPAR for post-mortem analysis.
• After successful rollback, the migration plan can be revisited and corrected before re-attempt.