IC SunsetThe developerWorks Connections platform will be sunset on December 31, 2019. On January 1, 2020, this blog will no longer be available. More details available on our FAQ.

Comments (5)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (5)

cggibbo commented May 17 2012 Comment Permalink

Hi Ashoky, yes you should change fc_err_recov to fast_fail and dyntrk to yes, on the physical FC adapters in the VIOS. This is considered best practice. Thanks for your comment.

AshokY commented May 15 2012 Comment Permalink

When we change value for the vscsi_err_recov attribute to fast_fail on a VIOC do we need to set fc_err_recov to fast_fail for fscsiX on the VIOS Is there any co-relation between Error RECOVERY Policy settings of vscsiX ( VIOS) and fscsiX (VIOC)

cggibbo commented July 6 2011 Comment Permalink

Absolutely Anthony. I highly recommend you change both attributes e.g. vscsi_path_to = 30, and vscsi_err_recov=fast_fail. The point of my post was to demonstrate that it is possible to update these attributes without rebooting your AIX system. Yes, I've read some of the APARs that relate to the issues you describes. Unfortunately it highlights the need to update you systems with the latest fixes as often as you can. Thanks for your feedback. Always interesting. Cheers. Chris

AnthonyEnglish commented July 6 2011 Comment Permalink

On one VSCSI adapter I ran rmpath for all the hdisks, but when I tried to run chdev on the VSCSI adapter, I still got a Method error. I had forgotten about the virtual CD-ROM which was also using vscsi0. I ran rmdev -l cd0 on the VIO client, then changed the adapter attributes and was able to bring the paths and CD-ROM online again.

AnthonyEnglish commented July 6 2011 Comment Permalink

I had to make this change after a DS4800 controller rebooted (due to a firmware bug) and paths through that VIO server hung. Client LUNs that had a chpath priority pointing to that VIO server didn't failover, and cfgmgr hung on the clients. I found it worth looking at the vscsi_path_to attribute as well.This fails all outstanding MPIO I/O requests and retry them down another path. (http://goo.gl/l35hL).