LUN Addition Reconfiguration Guidelines

Description

This document outlines the required multi-step LUN provisioning guidelines when adding access to a LUN to a Solaris Sparc environment

Automated enumeration (device detection) was initially introduced in Solaris 10 and is also available in Solaris 11

The storage stack should automatically detect new devices, assuming the target device can send unit attentions

KEY POINTS:

• Manual discovery may be required to discover newly presented devices by probing for devices using the cfgadm or fcinfo remote-port interfaces
   
• VxVM must be informed that the intended disk is being removed to ensure the cfgadm (Leadville stack) correctly reflects the access path state: unusable
   
• Adding and removing devices must be done at different times, and not under the same reconfiguration event
   
• Prior to adding or removing devices, the cfgadm -alo show_FCP_dev output should always be checked for existing failing or unusable access path states

It is essential that the /dev/rdsk contents do not contain any stale OS device handles , as the Veritas Device Discovery Layer (DDL) will build its DMP structures based on these device handles

If the cfgadm stack is clean of failing and unusable entries, then the OS device handles can be safely removed using:

# devfsadm -Cvc disk
 

The VxVM and DMP structures can then be refreshed using stable OS device tree information by running:

# vxdisk scandisks

# vxddladm assign names
 

MULTI-STEP ADDITION PROCESS:

The presentation of LUNs is also a multi-step process and requires manual intervention to detected newly presented devices;

Visual Illustration:

It is recommended that the above cfgadm output be checked prior to presenting new LUNs to the system

If I/O is ongoing to a LUN in the same storage enclosure, devices are detected automatically or a single LUN is already presented to the host from the same enclosure
 

If this is not the case or there is no traffic or access to the same storage enclosure, then a manual probe will be required
 

1.       A manual probe (rescan) of the devices will be required in some instance to detect newly provisioned LUNs, which can be achieved by running:

# cfgadm -alo show_FCP_dev

If the output is checked for failing or unusable path states beforehand, the optimized fcinfo remote-port approach can be used, if everything is reported as unknown:

In the below instance, the fcinfo remote-port command will probe controllers c3 and c4 for new devices

NOTE: The CTRLS variable can be modified to scan specific controllers
 

# cat oracle.sh

#! /bin/ksh

CTRLS="c3 c4" ;

for ctrl in $CTRLS ; do

      luxadm -e dump_map /dev/cfg/$ctrl |

      nawk '{if($1~"[0-9]+"){if($0~"Disk"){TPWWN=TPWWN" "$4}else if($0~"Adapter"){HBAPWWN=$4}}}END{print HBAPWWN" "TPWWN}' |

      while read HBAPWWNT TGTPWWNS ; do

            for tgtpwwn in $TGTPWWNS ; do

                  CMD="fcinfo remote-port -ls -p $HBAPWWNT $tgtpwwn" ;

                  echo "Ctrl "$ctrl": "$CMD ;

                  eval $CMD ; done ;

      done ;

done

2.       Prior to running the optimized fcinfo command, present the storage device through the required Storage Array interface:

3.       Discover the newly presented devices using the oracle.sh script

          # sh -x oracle.sh

4.       The Veritas vxdiskconfig command can used to execute two commands in a single operation:

  
The manual execution of 'devfsadm -c disk' should not be necessary, as the devfsadmd daemon will perform this operation when new devices are detected

Although the devfsadm command will not cause any harm, it may take a whle to complete, especially in larger configurations

NOTE: When removing devices, it is essential that 'devfsadm -Cvc disk' be executed

          # devfsadm -c disk

          # vxdctl enable

5.       The newly presented disk should now be visible to VxVM

           # vxdisk list

DMPDR TOOL:

The process can be automated using the DMPDR tool:

# /usr/lib/vxvm/voladm.d/bin/dmpdr -o refresh