IBM Support

All hdisks and vpath devices must be removed from host system before upgrading to SDD host attachment script 32.6.100.21 and above. All MPIO hdisks must be removed from host system before upgrading to SDDPCM host attachment script 33.6.100.9.

Flashes (Alerts)


Abstract

When upgrading from SDDPCM host attachment script devices.fcp.disk.ibm2105.mpio.rte version 33.6.100.8 or below to 33.6.100.9, all SDDPCM MPIO hdisks must be removed from the AIX host system before the upgrade. When upgrading from SDD host attachment script ibm2105.rte version 32.6.100.18 or below to 32.6.100.21 or later, all AIX hdisks and SDD vpath devices must be removed from the AIX host system before the upgrade.

Content

This document pertains to OLD host attachment levels which are no longer supported, you must upgrade to the current releases.

Please note that this document contains the following sections:
 
  • Problem description, symptoms, and information
  • SDD/host attachment upgrade procedures link (in SDD Users Guide)
  • Recovery procedures should the ODM become corrupted for SDD hosts
  • Recovery procedures should the associations become corrupted for SDD hosts
  • Procedures for upgrading if rootvg is on an ESS disk link (in SDD Users Guide)

Problem description, symptoms, and information:

Starting with SDDPCM host attachment script devices.fcp.disk.ibm2105.mpio.rte version 33.6.100.9 and SDD host attachment script ibm2105.rte version 32.6.100.21, ESS FCP devices are configured as "IBM MPIO FC 2105" for MPIO devices, and "IBM FC 2105" for ESS devices. This information can be seen in the "lsdev -Cc disk" output. Prior to these host attachment script versions, ESS FCP devices were configured as "IBM MPIO FC 2105XXX" for MPIO devices and "IBM FC 2105XXX" for ESS devices, where 'XXX' is the ESS device module, such as F20 or 800.

SDD Host ODM Corruption Symptom:

If all the hdisks are removed without removing all SDD vpath devices, then the associations between an SDD vpath device and its hdisks may be corrupted because the hdisk's device minor number may change after reconfiguration. The ODM corruption may look something like the following in the "lsdev -Cc disk" output:

>lsdev -Cc disk
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device hdisk1.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device hdisk2.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device hdisk3.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device hdisk4.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device hdisk5.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device hdisk6.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device hdisk7.
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device hdisk8.
hdisk0 Available 10-60-00-8,0 16 Bit SCSI Disk Drive
hdisk1 Available 20-60-01 N/A
hdisk2 Available 20-60-01 N/A
hdisk3 Available 20-60-01 N/A
hdisk4 Available 20-60-01 N/A
hdisk5 Available 20-60-01 N/A
hdisk6 Available 20-60-01 N/A
hdisk7 Available 20-60-01 N/A
hdisk8 Available 20-60-01 N/A

SDD/host attachment upgrade procedures:

In order to prevent ODM corruption and vpath/hdisk association corruption, all hdisks and SDD vpath devices must be removed prior to the upgrade. Please refer to the SDD User's Guide for the latest upgrade and OS migration procedures.

* Upgrading the AIX OS will always require you to install the SDD which corresponds to the new AIX OS level.

Prior to upgrading the OS and/or the SDD/ host attachment:
save output of lspv command to remember pvids of VGs.

After the upgrade or migration procedures have been followed, use the lspv command to find out one physical volume which has a pvid matching the previous SDD VG's pv.

SDD lspv VG Example:
===================================================

lspv output before upgrade


hdisk0 000bc67da3945d3c None
hdisk1 000bc67d531c699f rootvg active
hdisk2 none None
hdisk3 none None
hdisk4 none None
hdisk5 none None
hdisk6 none None
hdisk7 none None
hdisk8 none None
hdisk9 none None
hdisk10 none None
hdisk11 none None
hdisk12 none None
hdisk13 none None
hdisk14 none None
hdisk15 none None
hdisk16 none None
hdisk17 none None
hdisk18 none None
hdisk19 none None
hdisk20 none None
hdisk21 none None
vpath0 000bc67d318fb8ea SDDVG0
vpath1 000bc67d318fde50 SDDVG1
vpath2 000bc67d318ffbb0 SDDVG2
vpath3 000bc67d319018f3 SDDVG3
vpath4 000bc67d319035b2 SDDVG4

lspv output after upgrade:

hdisk0 000bc67da3945d3c None
hdisk1 000bc67d531c699f rootvg active
hdisk2 000bc67d318fb8ea None
hdisk3 000bc67d318fde50 None
hdisk4 000bc67d318ffbb0 None
hdisk5 000bc67d319018f3 None
hdisk6 000bc67d319035b2 None
hdisk7 000bc67d318fb8ea None
hdisk8 000bc67d318fde50 None
hdisk9 000bc67d318ffbb0 None
hdisk10 000bc67d319018f3 None
hdisk11 000bc67d319035b2 None
hdisk12 000bc67d318fb8ea None
hdisk13 000bc67d318fde50 None
hdisk14 000bc67d318ffbb0 None
hdisk15 000bc67d319018f3 None
hdisk16 000bc67d319035b2 None
hdisk17 000bc67d318fb8ea None
hdisk18 000bc67d318fde50 None
hdisk19 000bc67d318ffbb0 None
hdisk20 000bc67d319018f3 None
hdisk21 000bc67d319035b2 None
vpath0 none None
vpath1 none None
vpath2 none None
vpath3 none None
vpath4 none None

In this case, hdisk2, hdisk7, hdisk12, and hdisk17 from the current lspv output
has the pvid which matches the pvid of SDDVG0 from the previous lspv output.
So, use either hdisk2, hdisk7, hdisk12, or hdisk17 to import the volume group
with the name SDDVG0.
===================================================


SDD Recovery procedures should the ODM become corrupted:


If a SDD host system is upgraded without removing all of the hdisks first, then the AIX host system ODM will be corrupted.

If the host system's ODM is already corrupted as a result of upgrading without removing the hdisks, please contact IBM Customer Support at 1-800-IBM-SERV to request a script to fix the corrupted ODM.


SDD Recovery procedures should the associations become corrupted:

If vpath/hdisk association corruption has occurred because hdisks were removed without removing SDD vpath devices, all SDD vpath devices must be removed and reconfigured in order to correct this corrupted association.

SDD Procedures for upgrading if rootvg is on an ESS disk:

If rootvg is on an ESS device and cannot be moved to local scsi disks, all hdisks cannot be removed prior to the upgrade. In this case, the following procedure should be used to upgrade the SDD host attachment script to version 32.6.100.21 or later:
  1. Contact IBM Customer Support at 1-800-IBM-SERV to request the script SDDrestoreCuDv.sh to fix the corrupted ODM referenced above.
  2. Without removing ESS hdisks, use smitty to upgrade the SDD host attachment script on the host system.
  3. Immediately run the script to fix the corrupted ODM on the host system.
  4. Run bosboot on the host system.
  5. Reboot the host system so that the hdisks can be configured with the new ODM attributes.
  6. Return to the "SDD/host attachment upgrade procedures" above and follow the appropriate upgrade steps now that the SDD host attachment script upgrade is complete.

This issue only occurs when upgrading to devices.fcp.disk.ibm2105.mpio.rte version 33.6.100.9 and SDD host attachment script ibm2105.rte version 32.6.100.21 and above.

[{"Product":{"code":"ST52G7","label":"Storage software-\u003ESystem Storage Multipath Subsystem Device Driver"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Component":"--","Platform":[{"code":"PF002","label":"AIX"}],"Version":"32.6.100.21;33.6.100.9","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
26 September 2022

UID

ssg1S1002295