1. Front cover
Managing device addressing
of SAN attached tape
For use with Tivoli Storage Manager
Practical guidance for TSM
administrators
Manage your shared tape devices
with TSM
Understand Persistent
Naming
Steve Strutt
ibm.com/redbooks Redpaper

3. International Technical Support Organization
Managing the device addressing of SAN attached tape
for use with Tivoli Storage Manager
April 2002

4. Take Note! Before using this information and the product it supports, be sure to read the general
information in “Special notices” on page v.
First Edition (April 2002)
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. QXXE Building 80-E2
650 Harry Road
San Jose, California 95120-6099
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in
any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 2002. All rights reserved.
Note to U.S Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions set
forth in GSA ADP Schedule Contract with IBM Corp.

5. Contents
Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
IBM trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
About the author. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tivoli Storage Manager and tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Why does adding or removing devices cause an issue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Managing device addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Ensuring data integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Device name assignment in SANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Fibre device to SCSI address mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Persistent device addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
HBA persistent naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Gateway and router persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Host device name assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
TSM device definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Windows device naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
AIX device naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Sun Solaris device naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Managing without persistent naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Managing SAN tape devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
SAN hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Switch zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Systems Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SAN Management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
© Copyright IBM Corp. 2002 iii

6. iv Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

7. Special notices
References in this publication to IBM products, programs or services do not imply that IBM
intends to make these available in all countries in which IBM operates. Any reference to an
IBM product, program, or service is not intended to state or imply that only IBM's product,
program, or service may be used. Any functionally equivalent program that does not infringe
any of IBM's intellectual property rights may be used instead of the IBM product, program or
service.
Information in this document was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software products and
levels.
IBM may have patents or pending patent applications covering subject matter in this
document. The furnishing of this document does not give you any license to these patents.
You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation,
North Castle Drive, Armonk, NY 10504-1785.
Licensees of this program who wish to have information about it for the purpose of enabling:
(i) the exchange of information between independently created programs and other programs
(including this one) and (ii) the mutual use of the information which has been exchanged,
should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and conditions, including in
some cases, payment of a fee.
The information contained in this document has not been submitted to any formal IBM test
and is distributed AS IS. The use of this information or the implementation of any of these
techniques is a customer responsibility and depends on the customer's ability to evaluate and
integrate them into the customer's operational environment. While each item may have been
reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or
similar results will be obtained elsewhere. Customers attempting to adapt these techniques to
their own environments do so at their own risk.
Any pointers in this publication to external Web sites are provided for convenience only and
do not in any manner serve as an endorsement of these Web sites.
© Copyright IBM Corp. 2002 v

8. IBM trademarks
The following terms are trademarks of the International Business Machines Corporation in the
United States and/or other countries:
e (logo)® Redbooks™ Redbooks (logo)™
IBM® Tivoli®
Other company trademarks
The following terms are trademarks of other companies:
C-bus is a trademark of Corollary, Inc. in the United States and/or other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of
Sun Microsystems, Inc. in the United States and/or other countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United States and/or other
countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel
Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and other countries licensed exclusively
through The Open Group.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET
Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
vi Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

9. Preface
Fibre Channel based SANs provide a flexible way of connecting storage devices and hosts over a
shared network. Tivoli Storage Manager (TSM) exploits the bandwidth and connectivity to provide
LAN-Free backup and library sharing capabilities using shared tape devices over the SAN.
However, the building of SANs to support the use of shared tape devices must take into account a
number of considerations specific to the use of tape. These are required to ensure that the addition of
new storage devices, or that the removal or failure of existing devices on the SAN does not result in
TSM operational failures when using shared tape devices.
This paper is not intended to be an exhaustive description of the TSM or SAN hardware configuration
options that avoid tape device addressing issues, but it is intended to provide practical guidance for
TSM administrators and people implementing TSM in SAN environments. It covers the Microsoft
Windows, IBM AIX, and Sun Solaris platforms; as well as some of the common hardware components
used when building SANs.
About the author
Steve Strutt has worked with storage and storage management products for the last 15
years. Currently he works as a systems engineer for the IBM Software Group in the UK,
specializing in presales support for the Tivoli storage management product set. Before joining
the Software Group, he worked in IBM's S/390 and Storage Systems divisions on storage and
storage management products, working with the Tivoli Storage Manager (then called ADSM)
product since before it was first announced. His recent focus has been on Storage Area
Networks, concentrating on how they can be exploited and managed using Tivoli Software.
Steve is a recognized expert in his field and has worked with many major European
customers.
This paper was converted to Redpaper format by:
Barry Kadleck
International Technical Support Organization, San Jose Center
Notice
This publication is intended to help TSM administrators to configure and manage TSM in SAN
environments. The information in this publication is not intended as the specification of any
programming interfaces that are provided by Tivoli Storage Manager.
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about this
Redpaper or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
© Copyright IBM Corp. 2002 vii

10. redbook@us.ibm.com
Mail your comments to the address on page ii.
viii Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

11. Tivoli Storage Manager and tape
Fibre Channel based SANs provide a flexible way of connecting storage devices and hosts
over a shared network. Tivoli Storage Manager (TSM) exploiting the bandwidth and
connectivity to provide LAN-Free backup and library sharing capabilities using shared tape
devices over the SAN.
However, the building of SANs to support the use of shared tape devices must take into
account a number of considerations specific to the use of tape. These are required to ensure
that the addition of new storage devices, removal or failure of existing devices on the SAN
does not result in TSM operational failures when using shared tape devices.
Why does adding or removing devices cause an issue?
The potential for impact on TSM arises from the ability of Fibre Channel based SANs to allow
devices to be added and removed without disruption, and to be automatically mapped to
hosts without administrator involvement. This flexibility can affect access to existing devices
as the addition or removal of devices can result in the SCSI addresses and the device names
e.g. //./Tape0, assigned to existing devices changing. The impact of changes depends on the
host platform, and typically results in TSM losing access to the devices. Environments using
AIX are relatively insensitive to changes, but other platforms, such as Microsoft Windows and
Sun Solaris, require more attention and careful setup to avoid changes in device names and
SCSI addresses.
Current releases of TSM rely on pre-configured definitions for tape devices that assume the
relationship between the host device names specified in the TSM device definitions and the
physical devices does not change. Changes in the device name to physical device
relationship, or in the host SCSI address of a device, may result in invalid TSM device
definitions, where the specified SCSI addresses or device names point to the wrong device or
a device that does not exist. This can give rise to loss of access to the device, I/O errors, and
operational failures, which results in increased TSM administration.
As SAN configurations grow, the device definitions for many systems can be affected by a
single device change on the SAN. The impact of this on the reliability and operation of TSM
environments using library sharing or LAN-Free backup starts to become significant. Hence,
the challenge is to ensure that changes in the SAN configuration do not affect the device
addresses and names that TSM uses to access tape devices.
© Copyright IBM Corp. 2002 1

12. Managing device addressing
The main approach that is used to ensure that the relationship between a host device name
and a physical device does not change is the use of Host Bus Adapter (HBA) persistent
naming with a static device naming convention. Persistent naming or binding creates a fixed
physical device to SCSI address relationship, which does not change as devices are added or
removed. Static device naming ensures that the same device name is always assigned to the
same physical device and usually relies on persistent naming to ensure that the device's
SCSI address remains fixed to accomplish this.
The remainder of this paper looks at what persistent naming is and the device naming
conventions that can be used to ensure that no impact on TSM as SANs change. Then, for
environments where persistent naming is not available, it looks at the configuration options
and practices that can minimize the likelihood of device addressing changes and their impact
on TSM. The recommendations made are summarized at the end of this paper.
Ensuring data integrity
Typically, the first indication that a TSM device definition is invalid, and does not point to the
correct device, is when I/O errors occur while accessing the device. If the definition points to a
non-existent device, no harm results. However, if it points to another real tape device which is
already in use, then the integrity of data being written to the device may be compromised. To
avoid this and ensure the integrity of tape-based data, the SCSI command set enables
serialization of tape drive usage through the implementation of a protocol called
Reserve/Release.
During normal operation TSM performs SCSI Reserves against the tape devices it is using to
ensure that it is the sole user of the devices. This means that one host cannot accidentally
access a tape drive while another TSM server or Storage Agent is using it. After use,
ownership of the drive is released via a SCSI Release command. Any invalid access to a
drive currently in use will result in an I/O error on the host with the invalid device definition.
The existing SCSI Reserve blocks the invalid access, without impact on the host already
using the drive.
The use of SCSI Reserve/Release by TSM’s device driver avoids any possibly of data
corruption, but administrator involvement is required to correct the invalid device definition.
The best practice is to avoid device address changes in the first place. This Reserve/Release
capability is also provided in the IBM Ultrium LTO device drivers. For Windows 2000 it is
recommended that level 5.0.2.4 or higher of the LTO driver should be used, as levels prior to
this did not use SCSI Reserves.
Device name assignment in SANs
There are several stages in mapping a physical device to TSM. In this process there are a
number of different address mappings and all are potential causes of device address
changes.
2 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

13. Figure 1 shows the different stages in mapping a tape device to a TSM device name. The
operating system (OS) device name, which TSM uses for device access is typically assigned
when the HBA logs into the SAN fabric as the system is powered up. The HBA maps the
World Wide Names (WWNs) of the fibre devices presented by the fabric to the SCSI
addresses that the host OS understands. When using Qlogic adapters with Windows hosts,
an intermediate step of mapping the WWNs to loop ID by the HBA driver is also apparent.
The SCSI device addresses are then mapped to device names by the host OS.
HOST Tape
WWN Drives
OS SAN
TSM Device HBA Gateway/Router
Driver
OS Device SCSI ID Device WWN ID ID ID
Name to to WWN 1 2 3
Device WWN
TSM Device OS Device to
SCSI ID SCSI ID to LUN
Name Name
Figure 1 Stages of device name mapping
If the tape devices are not directly fibre attached, and are attached via a fibre to SCSI router
or gateway, an additional level of address mapping exists from the SCSI addresses of the
tape devices to the LUN addresses it presents to the fabric.
As mentioned earlier, the main approach to managing the issue of device address changes is
the use of persistent naming by the HBA coupled with a static device naming convention.
Persistent naming or binding creates a fixed SCSI address to the physical device relationship,
which does not change as devices are added or removed. Use of a static naming convention
ensures that the same device name is always assigned to the same physical device, and
typically refers to a device's SCSI address, which must remain unchanged. Together these
ensure that the relationship between the device name and the physical device do not change,
ensuring that there is no impact on TSM as the SAN changes.
Fibre device to SCSI address mapping
In a switched fabric the device driver for the HBA performs the mapping of Fibre Channel
device addresses (WWNs) to SCSI addresses. Using a Qlogic HBA as an example in a
Microsoft Windows environment, two address mappings occur. The WWN is mapped to a
loop ID which is then mapped to a corresponding host SCSI address.
Figure 2 is from the Qlogic QLconfig utility and shows the assigned loop IDs for a HBA
connected to a SAN that is comprised of Brocade switches. The loop ID is determined when
the HBA logs into the switched fabric. These are assigned dynamically and depend on the
devices that the HBA can see within the zones of which it is a member. In the example
Windows environment, the ordering of the devices by loop ID apparently comes from the
order in which the devices are found in the fabric Name Server table.
3

14. Figure 2 Qlogic QLconfig utility
Figure 3 shows the Name Server table for a fabric comprised of two Brocade 2400 switches.
Devices are ordered in the table by the switch domain number and then by the port number of
the switch they are connected to. The ordering of the devices in the Name Server table is
used for the sequence in which devices are assigned loop IDs by Qlogic HBAs in Windows
environments. A comparison of the Port WWN column in Figure 3 to the Device Port Name
column in Figure 2 shows the same device order.
4 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

15. Figure 3 Brocade Name Server Table
The loop IDs are then translated by the HBA device driver into the SCSI addresses that the
host OS sees. The seven devices shown in Figure 2 and Figure 3 have the following loop ID
to SCSI ID, and SCSI bus mapping using Qlogic HBAs in the example SAN (Table 1).
Table 1 SCSI mapping
Loop ID SCSI Target ID SCSI Bus
130 0 0
131 1 0
... ... ...
136 6 0
A consequence of using the order of the entries in the Name Server Table to determine the
assigned loop ID, and hence, SCSI ID, is that the relationship between device identified by a
WWN and its SCSI address can change. When devices are added, removed, fail or are
swapped from one switch port to another, the existing assigned loop ID, and hence, SCSI
address by which they and other devices are accessed may change. These changes may not
necessarily become apparent immediately at the attached hosts, but usually the next time the
system is restarted. If persistent naming is supported and used, then the issue of existing
SCSI addresses changing does not arise. The physical device as defined by its WWN is
always mapped to the same SCSI address.
As can be seen from the previous discussion, device changes can result in changes to the
SCSI addresses that are assigned to devices, though this is only if persistent naming is not
used or supported. Typically, this may cause any existing TSM device definitions to become
invalid, and the devices will not be accessible.
5

16. If device changes are properly planned and implemented via consistent change control
processes, then changes in SCSI addresses may be corrected in the TSM device definitions,
before failures occur. This will usually require systems to be restarted and the device
definitions updated. The unsocial hours when hardware changes can be made, and when
there are opportunities to restart systems, is a good incentive to avoid the issue. Change
Management, however, cannot help in a situation when unplanned changes occur due to
device failures.
The effects caused by unplanned changes can be minimized through use of SAN network
topology monitoring tools such as Tivoli Storage Network Manager (TSNM). Unplanned
changes due to device failures can be detected and any affected systems updated. In the
absence of proactive SAN network monitoring, operational failures caused by unplanned
changes can be identified through systems management monitoring of TSM device errors.
Persistent device addressing
There are two aspects to providing persistence of device SCSI addresses for tape devices in
a SAN. The first is the persistence in the relationship between the host SCSI address and a
fibre tape device. The second is when the tape devices are not attached directly to the SAN,
but via a gateway or router.
Most HBA vendors have already provided solutions to the problem of device addresses
changing by implementing static device mapping capabilities in their HBA drivers. This can be
known as SCSI mapping, persistent binding, or naming. This provides persistent device
mapping across system restarts, ensuring that once a SCSI address has been assigned to a
device, it does not change as devices are added or removed. This is usually performed by
fixing the SCSI address to the WWN of the device.
The previously discussed considerations relating to the assignment of SCSI addresses also
apply to a gateway or router as this is also a fibre attached device. However, in addition, the
gateway or router also applies its own address mapping from the SCSI addresses of its
attached devices to the LUN addresses that the gateway or router presents to the fabric. This
mapping must also remain static as devices are added or removed from behind the device.
HBA persistent naming
All HBAs provide persistence of SCSI addresses while a system is operating between
reboots. SCSI addresses assigned to devices at boot time or if detected during operation,
remain assigned until the system is shutdown. This is also true if devices are removed from
the SAN. The SCSI addresses assigned to existing devices remain unchanged until the
system is shutdown.
Emulex
The Emulex multi-protocol drivers for Microsoft Windows and Sun Solaris provide the
capability to track a Fibre Channel device, and ensure that the same SCSI addresses are
applied at all times. The term used is SCSI mapping.
With SCSI device mapping, the default is to track devices using their World Wide Port Names
(WWPN). Once a device has been assigned a bus/SCSI target ID, the device will always
continue to be mapped to the same bus/target ID based on WWPN or Nodename.
On the Windows platform, the elxcfg utility is provided with the multi-protocol driver to
configure the SCSI mapping and additionally to provide LUN mapping.
6 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

17. Figure 4 shows the elxcfg utility with the option selected to map SCSI addresses. By default
when new devices are detected, they are added to the end of the existing mapping with
higher SCSI addresses. The LUN Mapping checkbox can also be selected to perform tracking
of device LUNs behind gateways and routers.
Figure 4 Emulex elxcfg utility
Qlogic
Currently, Qlogic only provides persistent device addressing with their drivers for Sun Solaris.
The Qlogic term for this is persistent binding. This feature is not currently provided for the
Windows platform.
Gateway and router persistence
With fibre attached tape devices, the drive is usually mapped to LUN0 of the device. When
the tape drives are SCSI devices attached through a gateway or router an additional mapping
occurs. This is from the SCSI addresses of the devices attached to gateway or router to the
LUN addresses that are presented to the fabric.
From a TSM perspective, the LUN address for a device must also remain static. The addition
of new tape devices, removal or failure of a device behind a gateway or router should not
result in LUN addresses changing. The gateway or router must, therefore, be configured to
ensure static and persistent LUN mapping, regardless of device changes. In a Windows
environment that uses Emulex adapters, static LUN mapping can also be performed by the
HBA. The recommendation is to perform LUN mapping at the gateway or router as this
provides fixed LUN mapping for all platforms.
7

18. For SCSI tape devices attached to a SAN via a gateway or router, the HBA determines the
host SCSI target ID, bus and port address for the device. The LUN address used for the tape
device comes from the gateway or router itself and there are a number of different ways LUN
addresses can be mapped. Of the two commonly used gateways and routers, the persistent
LUN mapping options ensure that if devices fail or are removed the existing LUN mapping
remains unchanged.
CrossRoads
The CrossRoads CONxSAN 4x50 range of storage routers provide a number of LUN
mapping modes. The most relevant are Auto Addressing and Indexed Addressing.
Auto Addressing: A new SCSI to LUN address map is created each time the device is
rebooted. This is not useful in a TSM environment, as the failure of a device can result in the
LUN mapping changing at the next time the router is rebooted. This is the default.
Indexed Addressing: This provides a persistent and static mapping of SCSI ID to LUN
address, and is maintained by either editing the mapping table, or by an automatic population
of the mapping table initiated by an administrator when the device is configured.
ADIC and IBM SAN Data Gateway
The ADIC and IBM SAN Data Gateway by default use a static SCSI ID to LUN mapping.
When the gateway is first installed, and the attached SCSI devices have been powered up,
these are automatically mapped and the mapping is retained. If additional devices are added
to the gateway, these are added to the end of the existing device mapping without changing
previous entries.
If major device changes are made, then the mapping can be reset. This should not be
considered lightly as it may result in all the LUN addresses assigned to devices behind the
gateway changing, and may require updates to the device definitions for all the TSM Servers
and LAN-Free clients (Storage Agents).
Host device name assignment
In addition to persistent naming at the HBA, the second half of the solution to ensuring that
the device name to physical device relationship remains constant, is the use of static device
naming. This does not change as devices are added or removed.
The platforms supported by TSM use different approaches to device naming. The device
drivers on AIX perform intelligent tracking of physical devices, and ensure that the assigned
device name always points to the same physical tape device. It is, therefore, largely immune
from the effects of device changes. This device naming approach is static by its nature.
However, Microsoft Windows and Sun Solaris behave differently. Static device naming on
these platforms relies on HBA support for persistent device naming ensuring fixed SCSI
addresses in changing SANs.
Before looking at how device names are assigned by hosts to tape devices, we need to look
at how devices are defined to TSM. The current releases of TSM rely on preconfigured device
definitions, which assume a host device name to physical device relationship remains
constant over time. Without the use of persistent naming and static device names, this is not
guaranteed.
8 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

19. TSM device definitions
In TSM, libraries and tape devices are defined using DEFINE LIBRARY, DRIVE, DRIVEMAPPING
and PATH statements. The PATH statement is new in TSM 4.2.1 and supersedes the
DRIVEMAPPING statement.
The DEFINE LIBRARY and DEFINE DRIVE commands map the host OS assigned device names
to the TSM administrator assigned device names by which the libraries and tape drives are
known and accessed by TSM Servers, Library Managers, and Library Clients. The DEFINE
DRIVEMAPPING or DEFINE PATH commands define to the TSM Server how Storage Agents
access tape devices.
To set the device names used in these definitions, access is required to each TSM server or
Storage Agent to determine the device names used by each host to access the devices. The
utility TSMDLST is provided and can be executed on each host to determine the device names
that have to be defined to TSM.
Windows device naming
The default Microsoft Windows naming scheme for tape devices is dynamic and device
names change as devices are added and removed. It assigns device names in the form
.Tapex, where 'x' is a number. In this naming scheme, tape devices are given names
starting with the tape device with the lowest SCSI address first and then numbered in
ascending order starting from zero.
The disadvantage is that the name assigned to a physical device can easily change if new
devices are added with lower SCSI addresses, or if the SCSI addresses given to devices
change. Windows will name the new devices starting from .Tape0 and the names
assigned to existing devices will change. This means if devices are added, any existing TSM
DRIVE or PATH definitions using Windows device names may have to be changed to refer to
the correct physical device. Correspondingly, if devices fail or are removed from the fabric,
existing .Tapex device names can change.
With Windows NT, the mapping of SCSI addresses to OS device names is performed at boot
time. If new devices are added after boot time, it has no impact on the existing OS device
name mapping until the next time the system is rebooted. At the next restart, depending on
the SCSI addresses assigned by the HBA, a different device name to SCSI address mapping
can be applied, requiring changes to the TSM device definitions.
With Windows 2000, the SCSI address to OS device name mapping is performed both at
boot time and due to the plug-and-play capabilities of Windows 2000; it is also performed
when new devices are detected or devices removed. This means that in addition to the device
name mapping potentially changing at boot time, it can also change whenever a new device is
added, or a device is removed or fails. In-flight changes such as this can cause potentially
serious problems, and TSM ensures data integrity by issuing SCSI reserves against the
devices it is using to avoid an errant system accessing and writing to drives already in use by
other systems.
It is recommended that because of the potentially changing nature of .Tapex names on
Windows NT and Windows 2000 platforms, this naming convention is not used. The
alternative is to use a device alias name in the form of mtx.y.z.n for all tape devices. This
identifies a device explicitly by its SCSI target ID, LUN, SCSI bus number and SCSI port on
the host, rather than by its Windows assigned device name. On the Microsoft Windows
platforms, the TSM supplied device driver (ADSMSCSI) uses this device naming scheme by
default. This OS device name to physical device mapping remains constant if the SCSI
addressing remains unchanged, which is the case when HBA persistent naming is used.
9

20. This recommendation also applies to tape devices that do not use the TSM device driver,
such as IBM Magstar 3590, Ultrium LTO, or devices that use the native Windows device
drivers. From the TSM Device Driver, Device Information screen, the SCSI address of a
device can be determined and used to define the device to TSM in the form of mtx.y.z.n.
Figure 5 shows two tape devices .Tape1 and .Tape2. The device address information
can be taken from the ID, LUN, bus and port columns, and is used to define device addresses
of the form mtx.y.z.n where; 'x' is the SCSI target ID, 'y' is LUN, 'z' is the SCSI bus, 'n' is the
SCSI port.
Figure 5 TSM Device Driver, Device Information screen
Note that the SCSI target ID and bus values are determined by the HBA. The SCSI port
number depends on the number of SCSI and fibre adapters in the system, and can change if
adapters are added or removed. The LUN address will typically be 0 for a direct fibre attached
tape device, or if a SCSI device is behind a gateway, or determined by the gateway itself.
Using the devices from Figure 5 as examples, the alias definitions to be used by TSM are:
.Tape1 mt7.1.0.4
.Tape2 mt7.2.0.4
AIX device naming
AIX device drivers handle tape device addressing in a persistent and intelligent manner. Once
a device has been detected and assigned a device address such as /dev/mt0, or, if it is an
IBM tape device /dev/rmt0, AIX will ensure that at each restart or device reconfiguration, the
same device is always mapped to /dev/mt0 or /dev/rmt0. If the SCSI device address
changes due to a SAN configuration change, then these changes are transparent to any user
of the device, as it is always mapped to the same OS device name.
This remains true as long as the existing tape device definitions are not removed and
redefined when new devices are added. Addition or upgrading of device drivers may
sometimes make it necessary to remove all existing device definitions, in this case the TSM
device definitions should be rechecked after reconfiguring the devices to AIX.
10 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

21. Sun Solaris device naming
Sun Solaris uses a fixed device mapping from SCSI ID to OS device name. When using the
TSM device driver, device names are in the form of /dev/rmt/xmt, where x is a number. The
IBM tape devices, such as Ultrium LTO, Magstar 3570 and 3590, use the device name form
/dev/rmt/xst. Once the device definition has been created, the mapping of the device name
to SCSI address remains fixed.
Coupled with the static SCSI addresses provided by HBA persistent naming, ensures that the
device name to physical device relationship remains unchanged, as devices are added or
removed from the SAN. Both Emulex and Qlogic provide persistent naming capabilities with
their HBA device drivers on Solaris.
SCSI addresses are assigned depending on the number of devices visible to the HBA.
However different from Windows, it has been found that with Qlogic adapters, it is not safe to
say that the same SCSI mapping will be applied at each restart when persistent naming is not
used, even if no changes occur on the SAN.
If changes are required in the Solaris device name definitions because devices have been
added or removed, the device name mapping changes have to be manually performed by an
administrator.
Managing without persistent naming
In environments where persistent naming is not supported or used, the use of systems
management tools and processes can greatly help reduce or eliminate the impact that device
addressing changes might have on the operation of TSM. Currently, this is especially relevant
to Microsoft Windows environments using Qlogic HBAs for tape. The rest of this section
assumes that persistent naming is not being used, and that SCSI address will change as
devices are added or removed.
Even when persistent naming is not supported it is still recommended that on Windows 2000
the mtx.y.z.n approach to device naming is used. This avoids the additional problems
associated with changes in .Tapex device names resulting from the dynamic addition or
removal of devices.
Managing SAN tape devices
The largest opportunity for changes in device addressing occurs when systems and devices
are being powered up. In environments that are not changing, the application of consistent
processes to ensure that all storage devices have been powered up before servers are
restarted, will help to ensure that the same device addressing is applied at each restart.
As can be seen from the earlier explanation of how SCSI addresses are assigned to Microsoft
Windows hosts, the same device names and SCSI addresses will be assigned, as long as all
the storage devices are visible to the host when it is booted.
However, if devices fail to power up or have been removed, the device mappings for each
affected system must be checked to ensure that it is still as expected, or whether changes
must be made to the TSM device definitions.
If changes cannot be avoided, then there are a number of approaches to minimize or
eliminate the effects that device changes can have on TSM.
11

22. These can be broadly broken into two areas, hardware and systems management:
Hardware
SAN zoning
Systems Management
Change Management
SAN Management
Event Management
SAN hardware configuration
Careful use of SAN zoning can minimize the number of hosts affected by the addition or
removal of devices.
Switch zoning
Zoning can be used to restrict the number of devices that a specific host is able to see, to just
those that it uses, and hence, reduces the effects that adding new devices to the SAN has on
assigned SCSI addresses. At the logical extreme, this means one zone per host.
Only when devices are added to zones containing the host will possible changes occur to the
assigned SCSI addresses for existing devices. Devices added in different zones will not affect
the SCSI addresses that are already assigned.
By careful introduction of new devices and zoning, the impact of addressing changes can be
minimized, and the systems requiring device configuration changes can be easily identified.
However, this does imply restrictive zoning of devices and hosts, resulting in many zones, and
more complex zone administration.
To maintain maximum SAN flexibility and usability, the preference is for fewer zones with
device access being controlled by the applications or storage subsystems. This results in
lower administration requirements and easier addition of new devices and hosts.
Systems Management
The use of Systems Management tools and processes can greatly help reduce or eliminate
the impact that device changes have on the operation of TSM.
Change Management
The careful introduction of new devices, using Change Management procedures can
eliminate device issues for controlled changes. All systems affected by a change can be
identified prior to the device change, rebooted after the change, and their TSM device
definitions updated to refer to the correct devices.
This works well for controlled changes, but does not help with unplanned changes or device
failures.
12 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

23. SAN Management tools
SAN Network discovery and monitoring tools such as TSNM can alert administrators to the
fact that device changes have occurred on their SANs. Action can be taken to either repair or
replace failed devices. Or, no further action may be required, other than taking the effected
device offline to TSM. Systems can then be restarted and any addressing issues resolved at
the next available opportunity.
Event Management
If tools like TSNM are not available, the first indication of a problem will be TSM device access
failures and I/O errors. Event Management tools such as the Tivoli Event Console can be
used to monitor TSM operations and alert administrators if problems occur. Action can then
be taken immediately to determine the cause of the problem, and any device definitions
updated to affect the current device configuration.
Summary
The intent of this paper has been to show that the configuration of SANs for use with tape
devices and TSM, requires careful thought. It provides recommendations on how the device
addressing of SAN attached tape devices can be successfully managed to provide reliable
business recovery and continuity solutions.
Recommendations
The recommendations made in this paper on how to manage device addressing are
summarized below:
Where it is supported, use HBA persistent naming to ensure a fixed device WWN to SCSI
address mapping. This is sometimes also known as SCSI mapping or persistent binding.
Table 0-2 shows support for this feature by platform and by the HBA adapters looked at in
this paper.
Table 0-2 Persistent binding support
Platform Emulex Qlogic
AIX Not applicablea Not applicablea
Microsoft Windows Yes Nob
Sun Solaris Yes Yes
a. IBM 6227 or 6228 adapter is recommended
b. Not currently supported as of December 2001 at the 8.00.08 level
When SCSI tape devices are attached to a SAN via a gateway or router, ensure that a
static mapping of tape device SCSI addresses to LUN addresses by the gateway or router
is used.
On the Microsoft Windows NT and Windows 2000 platforms, when a device driver other
than the TSM driver is being used, use a static device naming convention. By default,
Windows uses a .Tapex device naming convention with non-TSM managed drives. The
recommendation is to use a device alias name in the form of mtx.y.z.n for all tape devices
which identifies a device by its SCSI and LUN address.
When using IBM Ultrium LTO devices on Windows 2000, it is recommended that level
5.0.2.4 or higher of the LTO driver should be used.
13

24. Device address and name persistence is central to building reliable SAN infrastructures for
tape devices, and fortunately this is available for most platforms and commonly used HBAs
today. For those platforms where device name persistence is not available, or cannot be
implemented, systems management tools and processes can help considerably in managing
device changes in these environments:
Use switch zoning to limit the number of devices visible to a host, and hence, minimize the
opportunity for device name changes.
Change Management can be used manage change in a controlled fashion and ensure the
device definitions of all effected systems are updated
SAN Management tools can be used to identify if unscheduled changes occur due to
device failures, and processes can be put in place to ensure that effected systems are
updated.
Event Management can be used to monitor TSM and determine if device errors are
occurring due to unplanned changes.
14 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

26. Back cover ®
Managing device addressing
of SAN attached tape
For use with Tivoli Storage Manager Redpaper
Practical guidance for Fibre Channel based SANs provide a flexible way of connecting
storage devices and hosts over a shared network. Tivoli Storage
INTERNATIONAL
TSM administrators
Manager (TSM) exploits the bandwidth and connectivity to TECHNICAL
provide LAN-Free backup and library sharing capabilities using SUPPORT
Manage your shared
tape devices with shared tape devices over the SAN. ORGANIZATION
TSM
However, the building of SANs to support the use of shared tape
devices must take into account a number of considerations
Understand Persistent specific to the use of tape. These are required to ensure that the
Naming BUILDING TECHNICAL
addition of new storage devices, or that the removal or failure of INFORMATION BASED ON
existing devices on the SAN does not result in TSM operational PRACTICAL EXPERIENCE
failures when using shared tape devices.
IBM Redbooks are developed
This paper is not intended to be an exhaustive description of the by the IBM International
TSM or SAN hardware configuration options that avoid tape Technical Support
device addressing issues, but it is intended to provide practical Organization. Experts from
IBM, Customers and Partners
guidance for TSM administrators and people implementing TSM from around the world create
in SAN environments. It covers the Microsoft Windows, IBM AIX, timely technical information
and Sun Solaris platforms; as well as some of the common based on realistic scenarios.
hardware components used when building SANs. Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:
ibm.com/redbooks