• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (5)

1 AnthonyEnglish commented 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. <div>&nbsp;</div> 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).

2 AnthonyEnglish commented 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.

3 cggibbo commented 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. <div>&nbsp;</div> 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. <div>&nbsp;</div> Thanks for your feedback. Always interesting. <div>&nbsp;</div> Cheers. <div>&nbsp;</div> Chris

4 AshokY commented 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 <br /> Is there any co-relation between Error RECOVERY Policy settings of vscsiX ( VIOS) and fscsiX (VIOC)

5 cggibbo commented 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. <br /> Thanks for your comment.

Add a Comment Add a Comment