IT20468: SAN DISCOVERY MAPPING DOES NOT MAP A CORRECT DEVICE IF A DEVICE HAS TWO CONNECTIONS TO A LINUX SYSTEM

8.1.3.000-IBM-SPCMS-WindowsX64
8.1.3.000-IBM-SPCMS-WindowsI32
8.1.3.000-IBM-SPCMS-Linuxx86_64
8.1.3.000-IBM-SPOC-WindowsX64
8.1.3.000-IBM-SPOC-Linuxx86_64
8.1.3.000-IBM-SPOC-Linuxs390x
8.1.3.000-IBM-SPOC-LinuxPPC64le
8.1.3.000-IBM-SPOC-AIX
8.1.3.000-IBM-SPSRV-WindowsX64
8.1.3.000-IBM-SPSRV-Linuxx86_64
8.1.3.000-IBM-SPSRV-Linuxs390x
8.1.3.000-IBM-SPSRV-Linuxppc64le
8.1.3.000-IBM-SPSRV-AIX
IBM Spectrum Protect Server V8.1 Fix Pack 3 (V8.1.3) Downloads
IBM Spectrum Protect Server V7.1 Fix Pack 8 (7.1.8.000) Downloads

APAR status

• Closed as program error.

Error description

• If a device has two connections to a Linux system, SAN discovery
  mapping does not map a device correctly, and thus when the
  library is in use,
  query san will not display all available paths to the tape
  drives.
  
  Consider the following scenario:
  A library has two drives. This library has two FC ports. Two FC
  cables are inserted into both ports of this library and the
  other ends of these two FC cables are connected to the host
  system. Therefore, the host system sees two identical devices,
  two libraries, four drives. But each device has its own physical
  location on the system, therefore, the sg driver generates a
  device file for each device (two libraries have two different
  sgX file names).
  For an example in this case, the library A has the device file
  as /dev/sgA (lb0) and the library B has the device file as
  /dev/sgB (lb1). These two libraries have the same serial number
  ABCDEFG.
  If the library is not in use, Q SAN will get all device info
  from the HBA API. Then the Q SAN will compare device info with
  device info in lbinfo file and mtinfo file. In this case, the Q
  SAN will give correct output.
  ie. query san shows:
  
  DRIVE        STK          T10000D
  333333333333               /dev/tsmscsi/mt0
  DRIVE        STK          T10000D
  222222222222               /dev/tsmscsi/mt1
  LIBRARY      STK          SL3000
  111111111111               /dev/tsmscsi/lb0
  DRIVE        STK          T10000D
  333333333333               /dev/tsmscsi/mt2
  DRIVE        STK          T10000D
  222222222222               /dev/tsmscsi/mt3
  LIBRARY      STK          SL3000
  111111111111               /dev/tsmscsi/lb1
  
  
  
  
  So each library and drive is displayed twice with their correct
  device files which are correct by autoconf.
  
  If the library is in use with /dev/sgA (lb0) file, the HBA API
  is unable to access the /dev/sgA and it gives /dev/sgB (lb1)
  info
  to Q SAN. When Q SAN does the device comparison, it tries to
  find the first matched device from the lbinfo file based on the
  device serial number. It does not compare the physical location
  (port wwwn). In this case, the first matched one is lb0 in the
  lbinfo file. So Q SAN picks this lb0. Since the HBA API provides
  only one library info, the Q SAN only displays the lb0.
  Therefore, only  this lb0 is seen in the output. However, this
  lb0 is incorrect.
  
  ie. now query san shows:
  
  LIBRARY      STK          SL3000
  111111111111               /dev/tsmscsi/lb0
  DRIVE        STK          T10000D
  111111111111                /dev/tsmscsi/mt0
  DRIVE        STK          T10000D
  222222222222               /dev/tsmscsi/mt1
  LIBRARY      STK          SL3000
  111111111111               /dev/tsmscsi/lb1
  
  Each drive is now only displayed once.
  
  
  
  
  Tivoli Storage Manager and IBM Spectrum Protect versions
  affected:
  Server 7.1.x and higher, and 8.1.x and higher on  Linux platform
  
  
  
  Initial Impact: Medium
  
  Additional Keywords:  TSM IBM Spectrum Protect query san
  sandiscovery paths
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All IBM Spectrum Protect and IBM Tivoli Storage Manager      *
  * server                                                       *
  * and storage agent users of SANdiscovery.                     *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * See error description.                                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply fixing level when available. This problem is projected *
  * to                                                           *
  * be fixed in level 7.1.8.                                     *
  * Note that this is subject to change at the discretion of     *
  * IBM.                                                         *
  ****************************************************************
  

Problem conclusion

• This problem was fixed.
  Affected platform: Linux.
  Fixed platform: Linux.
  

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:

Fix information

• Fixed component name

  TSM SERVER

• Fixed component ID

  5698ISMSV

Applicable component levels