IV94438: VIOS UPDATE AND RULESCFGSET CAN SAVE/DEPLOY INCORRECT SETTINGS

APAR status

• Closed as program error.

Error description

• **************************************************************
  * USERS AFFECTED:
  * Systems running the AIX 6100-09 Technology Level
  * with ios.artex_profile.rte between and including the 6.1.9.0
  * and 6.1.9.202 levels.
  **************************************************************
  * ERROR DESCRIPTION:
  * This problem affects VIOS users who have deployed VIOS
  * rules by using 'rulescfgset' or 'rules -o deploy' on
  * VIOS 2.2.4.x or 2.2.5.x.
  * Updating VIOS to version 2.2.4.0 - 2.2.4.40 or
  * 2.2.5.0 - 2.2.5.20 after previously applying VIOS rules can
  * incorrectly capture the current rules during the update.
  * Subsequent execution of 'rulescfgset' or 'rules -o deploy'
  * will apply those incorrect rules to the system.
  * When these changes take effect (after reboot for in-use
  * disks), they may have unintended results to the environment.
  * Most notably, the reserve_policy of backing devices may be
  * changed to single_path, removing client LPAR I/O redundancy
  * in a dual-VIOS environment.
  *
  * To fix this problem, you can re-deploy the default rules
  * with:
  *     $ rules -o deploy -d
  * Then re-capture those into the current rules with:
  *     $ rules -o capture
  * Note: if you have modified any of the VIOS default rules,
  * those changes will be overwritten by this procedure, so
  * they will have to be re-modified.
  *
  * Ideally these steps can be run after updating VIOS and
  * before rebooting to avoid any incorrect attributes from
  * taking effect.
  * However, if the devices have been reconfigured and the
  * incorrect attributes have taken effect, then further
  * steps will be needed to correct those devices, please see
  * below.
  *
  * The simplest way to ensure the corrected attributes take
  * effect is to reboot the VIOS again after deploying the
  * default rules (as above).
  * However, in a dual VIOS environment, extra care may need to
  * be taken if the effective reserve_policy attribute of the
  * disks has become single_path on both VIOSes.  One VIOS may
  * have lost access to the disk(s) and the client LPAR(s) may
  * only have one active path.  In this case, for AIX MPIO disks,
  * the reserve_policy of each disk can be changed to
  * no_reserve dynamically, without reboot, by running chdev
  * with the -U option.  This will require being in the root
  * shell, for example:
  *     $ oem_setup_env
  *     # chdev -l <hdiskX> -a reserve_policy=no_reserve -U
  * For other disk types that do not support this option, both
  * VIOSes may need to release and reconfigure the devices to be
  * able to each have them open with no_reserve.  This may
  * require the client LPAR(s) to be stopped and both VIOSes to
  * be shut down.
  *
  * Note: there is no ifix available to prevent this from
  * happening as the issue is in the update packages themselves.
  * Updates to levels containing this APAR (2.2.4.50+,
  * 2.2.5.30+, and 2.2.6.x) will not encounter this problem.
  **************************************************************
  * RECOMMENDATION:
  * Install APAR IV94438.
  **************************************************************
  

Local fix

• The latest default rules can be deployed to the system
  with
  $ rules -o deploy -d
  Then they can be captured to the current rules file with
  $ rules -o capture
  

Problem summary

• During VIOS update, VIOS may incorrectly capture the temporary
  default ODM values present prior to reboot/cfgmgr.  This causes
  desired settings to be lost from the current rules, and worse,
  if not caught, and rulescfgset is run, then the bad values get
  applied to the ODM.
  This can cause things like disks in dual VIOS having
  their reserve_policy set to single_path, or other tunables
  to be set to undesired base default values.
  

Problem conclusion

• Modify the VIOS rules fileset update scripts so that they will
  capture any modified default values instead of the temporary
  defaults in place at the time the fileset is updated.
  Also avoid removing current rules during some updates where we
  were erroneously doing that, and add a couple prereqs for the
  rules fileset to ensure scripts run without issue.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  IV96102 IV96105

Fix information

• Fixed component name

  VIRTUAL I/O SER

• Fixed component ID

  5765G3400

Applicable component levels

• R220 PSY U870056

     UP17/10/17 I 1000 Ž

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.