Fabric Device Addressing Changes

When you migrate from an existing Fibre Channel private loop configuration to a switched Fibre Channel fabric configuration, the hardware path to the attached target devices will change to reflect the presence of a fabric/switch in the route from the host initiator to the target device. When the I/O path information to a given disk changes, a new device file is created for this device.

Your system administrator will need to change the appropriate configuration files to allow the correct devices to be used by the file system or application that accesses these disk device files.




	NOTE: Device file names and iotree paths will change when a fabric switch replaces a loop. Device file names and iotree paths will change when you move a target from one port on a fabric switch to another port on the switch. Device files and iotree nodes will change if the switch domain changes.

How to Make Configuration Changes

Check all references to device files. The two most common files to check are:

/etc/lvmtab
/etc/fstab

In all cases where you move an LVM device, you can use the vgexport and vgimport commands to easily migrate existing volume groups. Use vgexport to export your volume groups before changing your SAN configuration or installing the switch. Then use vgimport to import your volume groups using the new device files.

Please refer to the vgexport and vgimport man pages and to the LVM portions of your administrator’s guides for details.

Device Addressing in a Fabric Environment

HP’s current model of addressing associates devices with their hardware path information. In the case of Fibre Channel disk devices, the device file names are little more than tags that are associated with a node in the system iotree. Using the ioscan command, ioscan -kfn -C disk, you can obtain this association.

During the kernel initialization phase of the boot process, ioscan scans the hardware I/O subsystem for attached devices, and builds an iotree. Any new devices that are found during this scan process will have new device files created for them.

The current Fibre Channel implementation over a Private Arbitrated Loop uses the Hard Address (HPA) of the FC target to generate a portion of the hardware path to the Fibre Channel port. Behind this port, virtual SCSI buses, targets and LUNs will exist.

In a fabric environment, the N_Port address is used to generate this portion of the hardware path to the Fibre Channel port. Behind this port, virtual SCSI buses, targets, and LUNs exist in the same manner as the existing configurations. The fabric/switch is responsible for the generation of the N_Port address. Three fields comprise this address:

Domain

Generally associated with the physical instance of a switch. (To determine how the domain is assigned on a particular switch, refer to that switch vendor’s documentation.)

Area

Generally associated with a port on the switch.

Port

Set to 0 for direct fabric attached devices (N_Port to F_Port).

Set to the AL_PA associated with the Hard Physical Address or loop identifier of a Fibre Channel target for public loop devices. (See the FC-AL-2 annex K for this mapping. Figure 1-6 “Annex-K - Assigned Loop Identifier” shows an example of the annex K table).

For private loop devices, the port field(s) in the HW path in an ioscan output contains the Hard Physical Address or loop identifier of the target device.

Figure 1-6 Annex-K - Assigned Loop Identifier

Note that the values are from lowest to highest priority. AL_PA=00 is reserved for an FL_Port; “-” is not available.

Because HP continues to use Physical Path addressing, loop devices (public and private) will be required to continue using Hard Physical Addresses.

Private Loop to Fabric Example

Following is a simple example of migrating an HP disk device from a private loop configuration to a fabric topology.

Figure 1-7 “Private Loop Configuration” shows a private loop configuration.

Figure 1-7 Private Loop Configuration

The ioscan output for a Private Loop Configuration could be as follows:

Class     I  H/W Path             Driver   S/W State   H/W Type       Description
----------------------------------------------------------------------------
fc        0  0/1/2/0              td        CLAIMED    INTERFACE    HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
fcp       1  0/1/2/0.8            fcp       CLAIMED    INTERFACE    FCP Protocol Adapter
ext_bus   3  0/1/2/0.8.0.11.0     fcparray  CLAIMED    INTERFACE    FCP Array Interface
target    6  0/1/2/0.8.0.11.0.0   tgt       CLAIMED    DEVICE
disk      3  0/1/2/0.8.0.11.0.0.0 sdisk     CLAIMED    DEVICE       HP OPEN-8
                                    /dev/dsk/c3t0d0    /dev/rdsk/c3t0d0
disk     10  0/1/2/0.8.0.11.0.0.7 sdisk     CLAIMED    DEVICE       HP OPEN-8
                                    /dev/dsk/c3t0d7    /dev/rdsk/c3t0d7
target    7  0/1/2/0.8.0.11.0.1   tgt       CLAIMED    DEVICE
disk     18  0/1/2/0.8.0.11.0.1.7 sdisk     CLAIMED    DEVICE       HP OPEN-9
                                    /dev/dsk/c3t1d7    /dev/rdsk/c3t1d7

Figure 1-8 “Direct Fabric Attachment Configuration” shows a Direct Fabric Attachment configuration.

Figure 1-8 Direct Fabric Attachment Configuration

The ioscan output for this configuration could be as follows:

Class     I  H/W Path             Driver   S/W State   H/W Type    Description
-----------------------------------------------------------------------------
fc        0  0/1/2/0              td       CLAIMED     INTERFACE   HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
fcp       1  0/1/2/0.1            fcp      CLAIMED     INTERFACE   FCP Domain
ext_bus   3  0/1/2/0.1.19.0.0     fcparray CLAIMED     INTERFACE   FCP Array Interface
target    6  0/1/2/0.1.19.0.0.0   tgt      CLAIMED     DEVICE
disk      3  0/1/2/0.1.19.0.0.0.0 sdisk    CLAIMED     DEVICE      HP OPEN-8
                                  /dev/dsk/c4t0d0    /dev/rdsk/c4t0d0
disk     10  0/1/2/0.1.19.0.0.0.7 sdisk    CLAIMED     DEVICE      HP OPEN-8
                                  /dev/dsk/c4t0d7    /dev/rdsk/c4t0d7
target    7  0/1/2/0.1.19.0.0.1   tgt      CLAIMED     DEVICE
disk     18  0/1/2/0.1.19.0.0.1.7 sdisk    CLAIMED     DEVICE      HP OPEN-9
                                  /dev/dsk/c4t1d7    /dev/rdsk/c4t1d7

Looking at the iotree examples, you can see the following:

There has been no change to the adapter path or the associated device file which is used for the fcmsutil diagnostic tool.
The node 0/1/2/0.8, FCP Protocol Adapter, is in the first ioscan output file. In a private loop configuration, the interface and target devices will reside behind this node. In a fabric environment, this node may be created as a dummy node generated by the scan logic if the HBA is scanned when it cannot see the fabric (for example, no cable attached, switch down, etc.).
In the original Private Loop implementation of the Fibre Channel driver, this node of the iotree was used to indicate the Fibre Channel FC4 “TYPE”. A type of “8” denotes that the FCP protocol is being used to encapsulate the SCSI protocol. With the introduction of fabric, this node contains the domain portion of the N_Port address. To maintain backward compatibility, the domain of 8 is reserved for use with Private Loop devices.
CAUTION: Do not configure switches with a domain of 8. This configuration is unsupported and will not work. HP systems reserve domain 8 for Private Loop devices.
The fabric configuration now contains an iotree node of 0/1/2/0.1 described as FCP Domain. A node of this type will be built for each domain the fabric contains. (Domains generally correspond one to one with a physical instance of a switch).
The FCP Array Interface iotree node has changed from 0/1/2/0.8.0.11.0 to 0/1/2/0.1.19.0.0. The address is still at hardware path 0/1/2/0, but the next three elements of the path, which represent the N_Port ID, have changed. The old N_Port ID of 8.0.11 uses the reserved domain of 8 and area of 0. In this case, the HPA or Port portion of the N_Port ID is 11. In the fabric iotree, the new N_Port ID is 1.19.0. This N_Port ID corresponds to the following:
- domain ID of 1 = Brocade switch #1
- area ID of 19 = port 3
- port ID of 0 = Direct Fabric Attach
In the ioscan example, the area ID is 19. The switch will show a hexadecimal value of “1x” because it has a fixed “1” in the upper four bits of the area field (0001xxxx). However, ioscan shows a decimal value for this field. Therefore, you must subtract decimal 16 from the number 19 to get the actual port number, which is 3.
For most switches, the domain ID generally will map to a switch. An area ID will map to a physical connector on the switch. This mapping may not be a direct numerical correlation; that is, physical port “3” may map to an area ID other than “3,” depending on the decimal value shown in this field.
If the switch port is an F_Port (Direct Fabric Attach), the port ID is set to 0. If the switch port is an FL_Port, the port ID is set to the AL_PA associated with the Hard Physical Address or loop identifier of a Fibre Channel target for public loop devices. The AL_PA is then used as the Port portion of the iotree address.
New device files will be generated for the new iotree nodes. The old device files will continue to exist until they are removed with the rmsf command or a system reboot.

Fabric Device Addressing Changes

Technical documentation

» Table of Contents

» Glossary

How to Make Configuration Changes

Device Addressing in a Fabric Environment

Private Loop to Fabric Example