Earlier, we faced recurring issues with LPARs hanging during VIO failover - especially when one VIOS went down, the disks would temporarily lose path access.

After some deep-dive analysis and tuning, here's what fixed it 

# chdev -l hdiskX -a queue_depth=32 -P# chdev -l hdiskX -a hcheck_interval=60 -P# chpath -l hdiskX -p vscsiX -a priority=2   # adjusted one path per VSCSI# Reboot the LPAR before testing

Testing Results:

• Test 1 (Shutdown VIOS1): LPAR stayed accessible, paths auto-recovered.

• Test 2 (Shutdown VIOS2): Same result - no hang, smooth recovery.

✅ Issue resolved - stable VSCSI failover confirmed!

 Next step: Plan migration from VSCSI → NPIV for higher I/O performance and simplified management on modern FC adapters.

Earlier, we faced recurring issues with LPARs hanging during VIO failover - especially when one VIOS went down, the disks would temporarily lose path access.

After some deep-dive analysis and tuning, here's what fixed it 

# chdev -l hdiskX -a queue_depth=32 -P# chdev -l hdiskX -a hcheck_interval=60 -P# chpath -l hdiskX -p vscsiX -a priority=2   # adjusted one path per VSCSI# Reboot the LPAR before testing

Testing Results:

• Test 1 (Shutdown VIOS1): LPAR stayed accessible, paths auto-recovered.

• Test 2 (Shutdown VIOS2): Same result - no hang, smooth recovery.

✅ Issue resolved - stable VSCSI failover confirmed!

 Next step: Plan migration from VSCSI → NPIV for higher I/O performance and simplified management on modern FC adapters.

Just a small tip on the chdev commands: if you use -U instead of -P the reboot is not required. Any parameter shown as 'True+' in the output from lsattr -E -l can be updated this way:

[root@aix2 /]# lsattr -E -l hdisk0
PCM             PCM/friend/vscsi                 Path Control Module        False
algorithm       fail_over                        Algorithm                  True
hcheck_cmd      test_unit_rdy                    Health Check Command       True+
hcheck_interval 0                                Health Check Interval      True+
hcheck_mode     nonactive                        Health Check Mode          True+
max_transfer    0x20000                          Maximum TRANSFER Size      True
pvid            00d952faebba7f180000000000000000 Physical volume identifier False
queue_depth     8                                Queue DEPTH                True+
reserve_policy  no_reserve                       Reserve Policy             True+

Earlier, we faced recurring issues with LPARs hanging during VIO failover - especially when one VIOS went down, the disks would temporarily lose path access.

After some deep-dive analysis and tuning, here's what fixed it 

# chdev -l hdiskX -a queue_depth=32 -P# chdev -l hdiskX -a hcheck_interval=60 -P# chpath -l hdiskX -p vscsiX -a priority=2   # adjusted one path per VSCSI# Reboot the LPAR before testing

Testing Results:

• Test 1 (Shutdown VIOS1): LPAR stayed accessible, paths auto-recovered.

• Test 2 (Shutdown VIOS2): Same result - no hang, smooth recovery.

✅ Issue resolved - stable VSCSI failover confirmed!

 Next step: Plan migration from VSCSI → NPIV for higher I/O performance and simplified management on modern FC adapters.

Earlier, we faced recurring issues with LPARs hanging during VIO failover - especially when one VIOS went down, the disks would temporarily lose path access.

After some deep-dive analysis and tuning, here's what fixed it 

# chdev -l hdiskX -a queue_depth=32 -P
# chdev -l hdiskX -a hcheck_interval=60 -P
# chpath -l hdiskX -p vscsiX -a priority=2   # adjusted one path per VSCSI
# Reboot the LPAR before testing

Testing Results:

• Test 1 (Shutdown VIOS1): LPAR stayed accessible, paths auto-recovered.

• Test 2 (Shutdown VIOS2): Same result - no hang, smooth recovery.

✅ Issue resolved - stable VSCSI failover confirmed!

 Next step: Plan migration from VSCSI → NPIV for higher I/O performance and simplified management on modern FC adapters.

Earlier, we faced recurring issues with LPARs hanging during VIO failover - especially when one VIOS went down, the disks would temporarily lose path access.

After some deep-dive analysis and tuning, here's what fixed it 

# chdev -l hdiskX -a queue_depth=32 -P# chdev -l hdiskX -a hcheck_interval=60 -P# chpath -l hdiskX -p vscsiX -a priority=2   # adjusted one path per VSCSI# Reboot the LPAR before testing

Testing Results:

• Test 1 (Shutdown VIOS1): LPAR stayed accessible, paths auto-recovered.

• Test 2 (Shutdown VIOS2): Same result - no hang, smooth recovery.

✅ Issue resolved - stable VSCSI failover confirmed!

 Next step: Plan migration from VSCSI → NPIV for higher I/O performance and simplified management on modern FC adapters.