Question & Answer
Question
This document lists data collection needed to investigate partition mobility failures. More data might be requested later on depending on the nature of the problem.
Cause
Partition mobility is failing in an HMC managed environment and needs to submit data to IBM for problem determination.
Answer
This document applies to VIOS V3.1
MustGather data:
- README.log with high overview of the partition mobility environment
- Clear config logs on all VIOs
- Re-create failure (if possible) by using HMC CLI to increase debugging level
- Gather snap from source and destination VIO Servers
- Gather AIX client snap
- Gather PE Debug from the HMC
- Package the data
- Where to Submit the Testcase
Notes:
- If partition mobility fails with the same errors for more than one client, submit snap from just one client for problem determination purposes
- For root cause analysis (RCA), be advised LPM logs are automatically cleared after 10 days to avoid getting full file system problem. If data collection is for RCA investigation and the partition mobility failure occurred more than 10 days ago, wait to gather the data immediately after the next re-occurrence. Otherwise, RCA is limited to the data provided
1. README.log
Include a high overview of the partition mobility environment in question. Ensure the following information is included to avoid delays:
c. Mobile AIX partition name and ID (uname -L), 'oslevel -s' and storage type
1. Include multipathing software level and SAN switch type/model/firmware level of all switches involved.
2. If multiple switches involved, what is their "general" configuration, such as Access Gateway, Fabric, VSAN ...
Use WWN Zoning as recommended by most switch vendors best practice guides. Contact vendor for details.
e. For RCA investigation, include:
- Date and time the failure occurred
- Error details
- Workaround (details of what you did to fix the problem, if applicable)
2. Clear up cfglog file for all VIO Servers (source and target) before re-creating the failure.
Log in to each VIOS, as padmin, and run:
$ oem_setup_env
# rm /var/adm/ras/cfglog
# echo "log cleared" | alog -t cfg
# echo "Create cfg log1" | alog -t cfg
Create file name /etc/drlog.cmd and add the following line:
CFGLOG=timestamp,detail,verbosity:9
3. Re-create the failure (if possible) by using HMC migrlpar command to increase debugging level partition mobility and gather virtual mapping data from the HMC by using lshwres command. Capture all data to a file named, migrlpar_lshwres.log
a. How to Capture HMC Output to a File
SSH to the HMC by using PuTTY and enable "All session output" to capture data to a file. Example:

Then, proceed to part 3b & c.
Alternatively, you can SSH to the HMC from an AIX host and use AIX script command to capture the console output. To do so, log in to AIX host, as root, and run:
# script -a /tmp/migrlpar_lshwres.log
# ssh -l hscroot <HMC_hostname>
Run all needed HMC commands (part b & c)
# exit (from HMC)
# exit (AIX script)
b. Re-create the failure by using migrlpar HMC command
List the source and destination system names by running:
# lssyscfg -r sys -F name
To re-create a validation failure (-o v), run:
# migrlpar -o v -m <source_system> -t <destination_system> -p <mobile_partition_name> -i "source_msp_id=<source_VIO_lpar_ID>,source_msp_ipaddr=<source_VIO_IPaddr>,dest_msp_id=<destination_VIO_lpar_ID>,dest_msp_ipaddr=<destination_VIO_IPaddr>" -d 5 -v
To re-create failure of an actual migration, change '-o v' (validation) to '-o m' (migration).
c. Capture virtual (lshwres) mapping data
$ lshwres -r virtualio -m <source_managed_system_name> --rsubtype fc --level lpar
$ lshwres -r virtualio -m <source_ managed_system_name> --rsubtype eth --level lpar
# lshwres -r mempool -m <source_managed_system_name>
# lshwres -r mempool -m <source_managed_system_name> --rsubtype pgdev
4. Gather snap from source and destination VIO Servers
$ mv snap.pax.Z source1.<vio hostame>.snap.pax.Z
Repeat these steps for the other source and destination VIO Servers. Then, rename files by using the following naming convention:
For VIOS snap issues, see Related URL section of this technote.
source2.<vio hostame>.snap.pax.Z
target1.<vio hostame>.snap.pax.Z
target2.<vio hostame>.snap.pax.Z
# snap -r (to remove old snap)
# snap -ac Creates /tmp/ibmsupt/snap.pax.Z
# cd /tmp/ibmsupt
# mv snap.pax.Z client.AIX_HOSTNAME.snap.pax.Z
6. Gather PE Debug from the HMC
HMC Enhanced View: Collecting PEDBG from the HMC v8
Gathering and Transmitting PE Debug Data from an HMC v7, v8 or v9
7.How to Initiate a Resource Dump from the HMC (SupportLine may request this data for certain situations.)
8. Package the Data
Transfer files created on steps 1, 3, 4, and 5 to an AIX host to package them into a single archive using AIX pax command to preserve the file names.
Log in to AIX host, as root, and run:
# mkdir /tmp/lpmdata
FTP the files created in steps 1-5 to this directory
# cd /tmp/lpmdata
# ls -la Ensure all files are listed
- README.log
- migrlpar_lshwres.log
- Snaps from source and destination VIO servers
- Client snap
# pax -wf YOUR_CASE_NUMBER.pax ./* Creates a single archive using your IBM service request information. For example, if your Support Case Number is TS123456789, you would run: pax -wf TS123456789.pax ./*
This is the file you want to send in.
9. Where to Submit the Testcase.
Was this topic helpful?
Document Information
Modified date:
06 September 2024
UID
isg3T1011601