How To
Summary
This procedure covers the complete setup of NPIV (N_Port ID Virtualization) on new Power systems from initial vfchost creation through SAN readiness verification, before a client LPAR is activated. The procedure requires HMC for virtual adapter slot creation but does not require RMC at any step. Virtual FC adapter slots are created via HMC profile modification and a VIOS Shutdown/Activate cycle, eliminating any dependency on RMC connectivity throughout the entire procedure.
Objective
| IMPORTANT | RMC is the standard and recommended management framework for PowerVM environments. It enables live DLPAR operations, dynamic adapter management, and non-disruptive partition administration. This procedure is intended for exceptional cases where RMC connectivity is unavailable — such as new environment setup, network constraints, or initial SAN provisioning before OS installation. RMC should be established as soon as operationally possible after completing this procedure. |
| IMPORTANT | HMC is required to define virtual FC adapter slots in the VIOS and client LPAR profiles. RMC is NOT required at any step, all adapter creation is done via profile modification and Shutdown/Activate, not via live DLPAR. |
1. Overview
1.1 Purpose
On a new Power system, the VIOS and client LPAR partitions exist but have no virtual FC adapters defined yet. The HMC must define the virtual adapter slots in the partition profiles. Once the VIOS is reactivated with the updated profile, the vfchost devices appear in the VIOS device tree. The vfcmap command then maps each vfchost to its physical fcs adapter. This allows WWPNs to be extracted and SAN zoning to be completed before the client LPAR is ever activated.
1.2 Why No RMC is Required
RMC (Resource Monitoring and Control) is only needed for live DLPAR operations, adding or removing adapters while a partition is running. This procedure avoids that entirely by using the profile-based approach: virtual FC adapters are added to the VIOS profile on the HMC, the VIOS is shut down and reactivated using that profile, and the vfchost devices appear naturally via cfgdev. No live partition changes are made.
1.3 Scope
| Parameter | Details |
| Environment | New Power systems with dual VIOS, managed by HMC |
| HMC Requirement | Required for virtual adapter slot definition |
| RMC Requirement | NOT required — zero RMC dependency |
| Timing | Before client LPAR first activation |
| Impact | Requires one VIOS shutdown/activate cycle per VIOS |
| SAN Dependency | SAN team availability required for Phase 4 |
1.4 Procedure Flow
| Phase | Where Executed | RMC Needed |
| Prerequisites — baseline capture | VIOS (padmin) | No |
| Phase 1 — Infrastructure verification | VIOS (padmin) | No |
| Phase 2A — Add virtual FC adapter slots to profile | HMC CLI | No |
| Phase 2B — Shutdown/Activate VIOS | HMC CLI | No |
| Phase 2C — Map vfchost to physical fcs | VIOS (padmin) | No |
| Phase 3 — WWPN verification | VIOS (padmin) | No |
| Phase 4 — SAN coordination | SAN team | No |
| Phase 5 — Client LPAR activation and verification | HMC CLI + AIX | No |
2. Prerequisites
2.1 Environment Requirements
Verify VIOS version on each VIOS:
# On VIOS as padmin
ioslevel
Minimum Requirements:
Dual-VIOS configuration for redundancy
Physical FC adapters with NPIV capability on each VIOS
Sufficient NPIV capacity on SAN switches (typically 255 VPorts per port)
HMC managing both VIOS partitions
VIOS and client LPAR partitions defined in HMC but client LPAR not yet activated
2.2 Access Requirements
| Access Required | Purpose | RMC Needed |
| padmin on both VIOS | All VIOS-side commands | No |
| HMC CLI (hscroot or equivalent) | Virtual adapter profile management and VIOS restart | No |
| SAN team contact | Fabric and zoning coordination | No |
| Change control approval | If required by organization | No |
2.3 Pre-Work: Capture Configuration Baseline
| NOTE | Always capture a configuration baseline before starting. This enables rollback if needed. |
Execute on each VIOS as padmin:
Capture physical FC adapter status
lsdev -Cc adapter | grep fcs > /tmp/fcs_before_$(date +%Y%m%d_%H%M%S).txt
Capture NPIV port status
lsnports > /tmp/lsnports_before_$(date +%Y%m%d_%H%M%S).txt
Capture error log baseline
errlog > /tmp/errlog_before_$(date +%Y%m%d_%H%M%S).txt
Capture current VIOS profile from HMC (run on HMC as hscroot):
Verify VIOS partition state
lssyscfg -r lpar -m <managed_system> -F name,state | grep -i vios
Capture current VIOS profile — save this output before making any changes
lssyscfg -r prof -m <managed_system> --filter "lpar_names=<vios_name>"
Environment
3. Phase 1: Infrastructure Verification
| NOTE | Execute all Phase 1 steps on each VIOS individually before proceeding to Phase 2. |
Step 1.1: Verify Physical FC Adapters
Objective: Confirm all physical Fibre Channel adapters are healthy and available.
On VIOS as padmin
lsdev -Cc adapter | grep fcs
Validation Checklist:
All fcs adapters show Available status
Adapters are distributed across different physical cards (for redundancy)
No adapters in Defined, Stopped, or Failed state
| Status | Meaning | Action |
| Defined | Adapter not configured | Run cfgmgr to configure |
| Stopped | Adapter stopped | Check errlog for errors |
| Failed | Hardware failure | Replace adapter — do not proceed |
Step 1.2: Verify NPIV Capability
Objective: Confirm physical FC adapters support NPIV and have available VPort capacity.
On VIOS as padmin
lsnports
Validation Checklist:
Port State: Operational
NPIV Supported: yes
Fabric Name present — confirms physical fabric connectivity
Active VPorts < Max VPorts — confirms capacity available
| Available VPorts | Status | Action |
| > 10 | Good | Continue |
| 5-10 | Warning | Plan for capacity — continue with caution |
| < 5 | Critical | Add adapters before proceeding |
| 0 | Full | Cannot create vfchosts — must add adapters |
Step 1.3: Check Fabric Connectivity
Objective: Verify physical FC adapters are properly connected to SAN fabric.
On VIOS as padmin
fcstat fcs0
Key Fields to Verify:
Port Speed (supported): 16 GBIT
Port Speed (running): 16 GBIT
Port Type: Fabric
Port State: Operational
Check for existing errors:
errlog | grep fcs0
| NOTE | Expected: No recent errors. If errors are present, resolve them before proceeding. Use errlog -a | grep fcs0 for full error details. Engage SAN team for fabric-related errors or IBM support for hardware-related errors. |
Steps
4. Phase 2: vfchost Creation
| IMPORTANT | Phase 2 has three distinct sub-phases: (A) add virtual FC adapter slots to VIOS and client LPAR profiles on the HMC, (B) shutdown and reactivate the VIOS using the updated profile, (C) map the resulting vfchost devices to physical fcs adapters. No RMC is required at any point. |
Step 2A: Add Virtual FC Adapter Slots to Profiles (HMC)
Objective: Define the virtual FC server adapter on the VIOS profile and the corresponding virtual FC client adapter on the client LPAR profile. These profile changes take effect on the next Shutdown/Activate of each partition.
| NOTE | Slot numbers must be agreed between the VIOS server adapter and the client LPAR adapter before running these commands. Choose slot numbers that are not already in use. Use lssyscfg to verify current slot assignments before proceeding. |
Step 2A.1 — Verify existing virtual adapter assignments on VIOS (HMC):
On HMC as hscroot
lshwres -m <managed_system> -r virtualio --rsubtype fc --level lpar \
--filter "lpar_names=<vios_name>"
Step 2A.2 — Add virtual FC server adapter to VIOS profile (HMC):
On HMC as hscroot
Add virtual FC SERVER adapter to VIOS profile
adapter_type=server remote_lpar_name=future client LPAR name
remote_slot_num=slot number that will be used on the CLIENT side
-s = slot number to use on the VIOS side
chsyscfg -r prof -m <managed_system> \
-i 'name=<vios_profile_name>,lpar_name=<vios_name>,\
"virtual_fc_adapters+=""<vios_slot>/server/<client_lpar_id>/\
<client_lpar_name>/<client_slot>//0"""'
Example:
chsyscfg -r prof -m Server-9009-22A-SN1234567 \
-i 'name=default,lpar_name=VIOS1,\
"virtual_fc_adapters+=""30/server/5/AIXLPAR1/10//0"""'
| WARNING | The virtual_fc_adapters+= syntax appends to existing adapters. Using virtual_fc_adapters= (without +) will overwrite all existing virtual FC adapter definitions in the profile. Always use += unless you intend to replace all existing definitions. |
Step 2A.3 — Add virtual FC client adapter to client LPAR profile (HMC):
On HMC as hscroot
Add virtual FC CLIENT adapter to client LPAR profile
Slot numbers must match what was defined in Step 2A.2
chsyscfg -r prof -m <managed_system> \
-i 'name=<client_profile_name>,lpar_name=<client_lpar_name>,\
"virtual_fc_adapters+=""<client_slot>/client/<vios_lpar_id>/\
<vios_name>/<vios_slot>//0"""'
Example:
chsyscfg -r prof -m Server-9009-22A-SN1234567 \
-i 'name=default,lpar_name=AIXLPAR1,\
"virtual_fc_adapters+=""10/client/2/VIOS1/30//0"""'
Step 2A.4 — Verify profile changes were applied correctly (HMC):
Verify VIOS profile
lssyscfg -r prof -m <managed_system> \
--filter "lpar_names=<vios_name>,profile_names=<vios_profile_name>"
Verify client LPAR profile
lssyscfg -r prof -m <managed_system> \
--filter "lpar_names=<client_lpar_name>,profile_names=<client_profile_name>"
Confirm that virtual_fc_adapters field in the output shows the newly added slots for both profiles.
Step 2A.5 — Repeat for second VIOS and second path:
Repeat Steps 2A.2 and 2A.3 for VIOS2, using different slot numbers, to create the second redundant path. A dual-path configuration requires four profile updates in total: server adapter on VIOS1, client adapter on the LPAR pointing to VIOS1, server adapter on VIOS2, client adapter on the LPAR pointing to VIOS2.
Step 2B: Shutdown and Reactivate VIOS
Objective: Apply the profile changes by performing a controlled Shutdown/Activate of each VIOS. This causes the Hypervisor to instantiate the new virtual adapter slots, making vfchost devices available for cfgdev to discover.
| CRITICAL | Execute this step on ONE VIOS at a time. Ensure all client LPARs that depend on the first VIOS have a redundant path through the second VIOS before proceeding. Do not shut down both VIOS partitions simultaneously. |
Step 2B.1 — Verify client LPAR storage redundancy before shutting down VIOS1:
On each client LPAR (AIX) that uses this VIOS
lspath | grep -v Enabled
Expected: all paths Enabled — if any are Failed, resolve before proceeding
Step 2B.2 — Perform controlled shutdown of VIOS1 (HMC):
On HMC as hscroot
Initiate OS shutdown on the VIOS
chsysstate -r lpar -m <managed_system> -o shutdown \
-n <vios_name> --immed
Wait for VIOS to reach Not Activated state
lssyscfg -r lpar -m <managed_system> -F name,state \
| grep <vios_name>
Expected: <vios_name>,Not Activated
Step 2B.3 — Reactivate VIOS1 using the updated profile (HMC):
On HMC as hscroot
chsysstate -r lpar -m <managed_system> -o on \
-n <vios_name> -f <vios_profile_name>
Verify VIOS has restarted and is Running
lssyscfg -r lpar -m <managed_system> -F name,state \
| grep <vios_name>
Expected: <vios_name>,Running
Step 2C: Configure and Map vfchost Adapters (VIOS)
Objective: After VIOS reactivation, discover the new vfchost devices and map each to its physical fcs adapter using vfcmap.
Step 2C.1 — Discover new virtual FC adapters on VIOS:
On VIOS as padmin
cfgdev
Verify new vfchost devices are present and are in the "Available" state.
lsdev -dev vfchost*
| NOTE | If vfchost devices do not appear after cfgdev, verify the profile changes were saved correctly and that the VIOS was reactivated using the updated profile, not a stale one. |
Step 2C.2 — Map each vfchost to its physical fcs adapter:
On VIOS as padmin
Map first vfchost to first physical fcs adapter
vfcmap -vadapter vfchost0 -fcp fcs0
Map second vfchost to second physical fcs adapter (different card)
vfcmap -vadapter vfchost1 -fcp fcs1
Step 2C.3 — Verify vfchost mapping and login status:
On VIOS as padmin
lsmap -all -npiv
Validation Checklist:
- vfchost0 is listed and mapped to correct physical fcs adapter
Client Partition ID is empty — no LPAR assigned yet, this is expected
Status will show NOT_LOGGED_IN at this stage — this is normal and
expected. A vfchost cannot reach LOGGED_IN state until one of the
following occurs:
Client LPAR is booted to OS (Phase 5)
chnportlogin is issued from HMC (requires RMC)
SAN Zoning Support is used from the client partition SMS menu
- Verify the physical fcs fabric login instead using:
lsnports — confirm fabric=1 for the backing fcs adapter
| NOTE | The WWPN pair is displayed in lsmap -all -npiv output only when the vfchost status is LOGGED_IN. If WWPNs are not visible, retrieve them explicitly using: lsmap -vadapter vfchost0 -npiv |
| NOTE | Each vfchost exposes a pair of WWPNs: one active (used for current fabric login) and one inactive (reserved for failover or Live Partition Mobility). Both must be zoned by the SAN team. |
Step 2C.4 — Repeat Steps 2B and 2C for VIOS2:
Once VIOS1 is fully verified and all client LPARs have confirmed their first VIOS path is healthy, repeat the Shutdown/Activate cycle and vfchost mapping for VIOS2.
5. Phase 3: WWPN Verification
Step 3.1: Extract All WWPNs
Objective: Collect all WWPN pairs from both VIOS for SAN team documentation.
On each VIOS as padmin
lsmap -all -npiv
Or extract to file for handoff
lsmap -all -npiv > /tmp/wwpn_list_$(hostname)_$(date +%Y%m%d).txt
Data Collection - VIOS1:
| vfchost | Physical fcs | WWPN 1 | WWPN 2 | Status |
| vfchost0 | fcs0 | |||
| vfchost1 | fcs1 |
Data Collection - VIOS2:
| vfchost | Physical fcs | WWPN 1 | WWPN 2 | Status |
| vfchost0 | fcs0 | |||
| vfchost1 | fcs1 |
Step 3.2: Verify Login Status
On each VIOS as padmin
lsmap -all -npiv | grep -E "vfchost|Status:"
Decision Point:
- At this stage, NOT_LOGGED_IN is the expected status on all vfchosts
since no client LPAR is connected yet. Proceed to Phase 4. - If lsmap shows no vfchost entries at all, or vfchost is missing
from lsdev output, continue to Step 3.3 for remediation. - LOGGED_IN state will be achieved automatically when the client
LPAR is activated in Phase 5.
Step 3.3: Remediate NOT_LOGGED_IN Status
Objective: Fix vfchosts that are not logged into the fabric.
On VIOS as padmin
Step 1: Unmap vfchost from physical fcs adapter
vfcmap -vadapter vfchost0 -fcp
Step 2: Unconfigure vfchost (preserves device definition)
rmdev -dev vfchost0 -ucfg
Step 3: Allow fabric cleanup (mandatory)
sleep 10
Step 4: Reconfigure devices
cfgdev
Step 5: Remap to physical fcs adapter
vfcmap -vadapter vfchost0 -fcp fcs0
Step 6: Verify new login state
lsmap -vadapter vfchost0 -npiv
| NOTE | The vfcmap -vadapter vfchost0 -fcp command removes the mapping. The -ucfg flag on rmdev unconfigures but preserves the device definition, allowing cfgdev to restore it cleanly. The vfcmap remap step after cfgdev is required to restore fabric login. |
| NOTE | WWPNs typically remain unchanged when -ucfg is used instead of a full rmdev. Always re-verify WWPNs after remediation and re-document them before notifying the SAN team. |
6. Phase 4: SAN Coordination
Step 4.1: Prepare WWPN Documentation
| NOTE | If the SAN team requires virtual WWPNs to be physically visible lshwres -m <managed_system> -r virtualio --rsubtype fc \ --level lpar --filter "lpar_names=<client_lpar_name>" |
Complete the template below with all WWPN pairs collected in Step 3.1 and provide it as the handoff document to the SAN team.
===============================================================
NPIV WWPN ZONING REQUEST
===============================================================
PROJECT INFORMATION
---------------------------------------------------------------
Future Client LPAR Name: _______________________________
Managed System: _______________________________
Date of Request: _______________________________
Change Record Number: _______________________________
Requestor Name: _______________________________
Requestor Contact: _______________________________
VIOS 1 CONFIGURATION
---------------------------------------------------------------
VIOS Hostname: _______________________________
vfchost0: Physical FCS: fcs0 WWPN 1: ________ WWPN 2: ________
vfchost1: Physical FCS: fcs1 WWPN 1: ________ WWPN 2: ________
VIOS 2 CONFIGURATION
---------------------------------------------------------------
VIOS Hostname: _______________________________
vfchost0: Physical FCS: fcs0 WWPN 1: ________ WWPN 2: ________
vfchost1: Physical FCS: fcs1 WWPN 1: ________ WWPN 2: ________
STORAGE REQUIREMENTS
---------------------------------------------------------------
Storage Array: _______________________________
Storage Controller A WWPN: _______________________________
Storage Controller B WWPN: _______________________________
Number of LUNs Required: _______________________________
LUN Size: _______________________________
SAN TEAM VERIFICATION
---------------------------------------------------------------
[ ] All WWPNs logged into fabric
[ ] WWPNs on correct switches and ports
[ ] Zoning complete to storage targets
[ ] No FLOGI rejections or fabric errors
[ ] NPIV limits not exceeded
[ ] Path redundancy verified (4 paths total)
SAN Team Contact: _______________________________
Verification Date: _______________________________
Ticket/Case Number: _______________________________
===============================================================
Step 4.2: SAN Team Verification Checklist
| Verification Item | Expected Result |
| All WWPNs logged into fabric | Visible in fabric name server |
| WWPNs on correct switches/ports | Matches expected topology |
| Zoning complete to storage targets | Active zone set configured |
| No FLOGI rejections | Clean fabric login logs |
| NPIV limits not exceeded | Capacity available on switches |
| Path redundancy verified | All 4 paths (2 VIOS x 2 adapters) confirmed |
Step 4.3: Confirm Zoning Complete
| PREREQUISITE | Do NOT proceed to Phase 5 until SAN team confirms: all WWPNs visible in fabric, zoning activated on all fabric switches, no FLOGI rejections or fabric errors, storage target ports included in zones, and both VIOS paths confirmed. |
SAN Verification Complete: [ ] Yes [ ] No
Zoning Complete: [ ] Yes [ ] No
Ready for LPAR Activation: [ ] Yes [ ] No
SAN Team Name: _______________________________
Date/Time: _______________________________
Ticket Number: _______________________________
7. Phase 5: Client LPAR Activation and Verification
Step 5.1: Activate Client LPAR
Objective: Activate the client LPAR using its profile. The virtual FC client adapters defined in the profile in Step 2A will be instantiated by the hypervisor at activation time.
On HMC as hscroot
Verify client LPAR is in Not Activated state before proceeding
lssyscfg -r lpar -m <managed_system> -F name,state \
| grep <client_lpar_name>
Expected: <client_lpar_name>,Not Activated
Activate client LPAR using its profile
chsysstate -r lpar -m <managed_system> -o on \
-n <client_lpar_name> -f <client_profile_name>
Verify LPAR is Running
lssyscfg -r lpar -m <managed_system> -F name,state \
| grep <client_lpar_name>
Expected: <client_lpar_name>,Running
Verify vfchost login status updates on VIOS after client activation:
On each VIOS as padmin
lsmap -all -npiv | grep -E "vfchost|Status:|ClntName"
Step 5.2: Verify Multipath (Post OS Installation)
Objective: Confirm client LPAR has multiple paths to storage after OS installation.
On client LPAR (AIX) - verify virtual FC adapters
lsdev -Cc adapter | grep fcs
Verify multipath
lspath
| NOTE | Minimum requirement for production readiness is 4 active paths per LUN (2 VIOS x 2 adapters per VIOS). If fewer paths are shown, check vfchost status on each VIOS with lsmap -all -npiv, verify SAN zoning includes all WWPNs, and engage the SAN team. |
8. Troubleshooting
8.1 Issue: vfchost Devices Not Appearing After VIOS Reactivation
Symptoms: cfgdev completes but lsdev -dev vfchost* shows no new devices.
Resolution:
Verify the VIOS was activated using the updated profile: lssyscfg -r lpar -m <managed_system> --filter "lpar_names=<vios_name>" — check active_profile_name matches the profile that was updated
Verify the profile changes were saved: lssyscfg -r prof -m <managed_system> --filter "lpar_names=<vios_name>,profile_names=<profile_name>" — confirm virtual_fc_adapters field shows the new slots
If profile was not updated correctly, re-apply Step 2A and repeat Step 2B
8.2 Issue: vfchost Shows NOT_LOGGED_IN After vfcmap
| Check | Command | YES - Next Step | NO - Action |
| Physical fcs Available? | lsdev -dev fcs0 | Go to check 2 | Investigate hardware: errlog | grep fcs0 |
| lsnports shows Operational? | lsnports | Go to check 3 | Check physical connectivity (cables, SFPs) |
| vfcmap/rmdev/cfgdev resolves? | See Step 3.3 | Document; continue to Phase 4 | Go to check 4 |
| errlog shows fcs errors? | errlog | grep fcs | Investigate specific errors | Go to check 5 |
| SAN team confirms fabric OK? | Engage SAN team | Resolve fabric issue | Open IBM support case |
8.3 Issue: WWPNs Changed After Remediation
Symptoms: Different WWPN pair after vfcmap/rmdev -ucfg/cfgdev cycle; SAN team reports WWPNs not matching documentation.
Why this happens: WWPNs are generated by the PowerVM Hypervisor when virtual FC adapters are instantiated and persist with the virtual adapter device. Using rmdev -ucfg preserves the device definition, typically maintaining WWPN associations.
Resolution:
Document new WWPNs immediately: lsmap -vadapter vfchost0 -npiv
Notify SAN team of WWPN change immediately
SAN team must update zoning with new WWPNs before client LPAR can access storage
Update the client LPAR profile on HMC if WWPNs changed: lshwres -m <managed_system> -r virtualio --rsubtype fc --level lpar to verify
8.4 Rollback Procedure
| CRITICAL | Stop all remediation immediately if a client LPAR is running and storage access is lost. Engage IBM Support rather than attempting repeated vfcmap/rmdev/cfgdev cycles when hardware faults are suspected. |
On VIOS as padmin
Step 1: Unmap vfchost from physical fcs adapter
vfcmap -vadapter vfchost0 -fcp
Step 2: Unconfigure vfchost (preserves device definition)
rmdev -dev vfchost0 -ucfg
Step 3: Allow fabric cleanup
sleep 10
Step 4: Reconfigure devices
cfgdev
Step 5: Remap to original physical fcs adapter
vfcmap -vadapter vfchost0 -fcp fcs0
Step 6: Verify restoration
lsmap -vadapter vfchost0 -npiv
9. Quick Reference
9.1 Command Reference
| Command | Purpose | Shell |
| lssyscfg -r prof -m <sys> --filter "lpar_names=<name>" | View current partition profile | HMC |
| chsyscfg -r prof -m <sys> -i 'name=...,virtual_fc_adapters+=...' | Add virtual FC adapter to profile | HMC |
| chsysstate -r lpar -m <sys> -o shutdown -n <name> --immed | Shutdown VIOS | HMC |
| chsysstate -r lpar -m <sys> -o on -n <name> -f <profile> | Activate partition using profile | HMC |
| lshwres -m <sys> -r virtualio --rsubtype fc --level lpar | List virtual FC adapters | HMC |
| cfgdev | Discover and configure new devices | VIOS (padmin) |
| lsdev -dev vfchost* | List virtual FC server adapters | VIOS (padmin) |
| vfcmap -vadapter vfchost0 -fcp fcs0 | Map vfchost to physical fcs adapter | VIOS (padmin) |
| vfcmap -vadapter vfchost0 -fcp | Unmap vfchost from physical fcs adapter | VIOS (padmin) |
| lsmap -all -npiv | List all vfchosts with login status | VIOS (padmin) |
| lsmap -vadapter vfchost0 -npiv | Detail for specific vfchost; use when WWPNs not visible in lsmap -all -npiv | VIOS (padmin) |
| lsdev -dev fcs0 | Check physical adapter availability | VIOS (padmin) |
| lsnports | Verify NPIV capability and port state | VIOS (padmin) |
| fcstat fcs0 | Check FC adapter fabric connectivity statistics | VIOS (padmin) |
| rmdev -dev vfchost0 -ucfg | Unconfigure vfchost — preserves device definition | VIOS (padmin) |
| errlog | grep fcs | Filter error log for FC adapter entries | VIOS (padmin) |
| lspath | Verify multipath from client LPAR | AIX (client) |
9.2 Success Criteria
Procedure is complete when all of the following are true:
Virtual FC adapter slots defined in VIOS and client LPAR profiles on HMC
Both VIOS partitions reactivated with updated profiles
- All vfchosts on both VIOS mapped via vfcmap and verified with lsnports fabric=1 on backing fcs adapters
SAN team confirmed all WWPNs visible in fabric and zoning complete
No errors in errlog for fcs or vfchost on either VIOS
Path redundancy verified: 4 paths total (2 VIOS x 2 adapters)
Client LPAR activates successfully using updated profile
Multipath confirmed post OS installation: minimum 4 Enabled paths per LUN
Additional Information
References:
IBM PowerVM Virtualization Introduction and Configuration (SG24-7940)
https://www.redbooks.ibm.com/abstracts/sg247940.html
IBM PowerVM Best Practices (SG24-8062)
https://www.redbooks.ibm.com/abstracts/sg248062.html
IBM PowerVM Live Partition Mobility (SG24-7460)
https://www.redbooks.ibm.com/abstracts/sg247460.html
Introduction to IBM PowerVM (SG24-8535)
https://www.redbooks.ibm.com/abstracts/sg248535.html
lsmap – https://www.ibm.com/docs/en/powervm/4.1?topic=commands-lsmap
lsdev – https://www.ibm.com/docs/en/powervm/4.1?topic=commands-lsdev
lsnports – https://www.ibm.com/docs/en/powervm/4.1?topic=commands-lsnports
rmdev – https://www.ibm.com/docs/en/powervm/4.1?topic=commands-rmdev
errlog – https://www.ibm.com/docs/en/power10?topic=commands-errlog-command
lssyscfg – https://www.ibm.com/docs/en/power10/9080-HEX?topic=commands-lssyscfg
chsysstate – https://www.ibm.com/docs/en/power10/9080-HEX?topic=commands-chsysstate
| SUPPORT |
|---|
If you require more assistance, use the following step-by-step instructions to contact IBM to open a case for software with an active and valid support contract. 1. Document (or collect screen captures of) all symptoms, errors, and messages related to your issue. 2. Capture any logs or data relevant to the situation. 3. Contact IBM to open a case: -For electronic support, see the IBM Support Community: 4. Provide a clear, concise description of the issue. - For more information, see: Working with IBM AIX Support: Describing the problem. 5. If the system is accessible, collect a system snap, and upload all of the details and data for your case. - For more information, see: Working with IBM AIX Support: Collecting snap data |
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
11 May 2026
UID
ibm17271696