IBM Support

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

Subscribe

You can track all active APARs for this component.

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 number

    IT20468

  • Reported component name

    TSM SERVER

  • Reported component ID

    5698ISMSV

  • Reported release

    71L

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2017-05-05

  • Closed date

    2017-06-23

  • Last modified date

    2017-06-23

  • 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

  • R63L PSY

       UP

  • R71L PSY

       UP

  • R81L PSY

       UP



Document information

More support for: Tivoli Storage Manager

Software version: 7.1.3

Reference #: IT20468

Modified date: 23 June 2017