Description

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

KEY POINTS:

• To discover newly presented device paths, a manual discovery is required by probing for devices using the cfgadm or fcinfo remote-port interfaces
   
• Adding and removing devices must be done at different times, and not under the same reconfiguration event
   
• Prior to adding or removing devices or device paths, 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:
 

For illustration purposes, paths from controller c3 will be presented at the storage layer and associated with Veritas disk access name "emc_clariion0_5":
 

1. Define the LUN variable, in this instance pointing to Veritas disk access (da) / DMPNODE name "emc_clariiion0_5":
   
   LUN="emc_clariion0_5
    
2. Verify the number of paths visible for the DMPNODE(s) where additional paths are to be presented
   
   # vxdisk path | egrep "(${LUN})"
   
   c4t500601613EA07595d1s2     emc_clariion0_5      -            -            ENABLED
   c4t500601693EA07595d1s2     emc_clariion0_5      -            -            ENABLED
   
   In this instance, the DMPNODE "emc_clariion0_5" has paths solely from a single controller c4
    
3. It is recommended that the above cfgadm output be checked prior to presenting new LUNs to the system
   
   A manual probe (rescan) of the devices will be required to detect newly provisioned LUNs or device paths, 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 for new devices/paths
   
   NOTE: The CTRLS variable can be modified to scan specific controllers
   
   # cat oracle.sh
   #! /bin/ksh
   CTRLS="c3" ;
   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
    
4. Prior to running the optimized fcinfo command, present the storage device through the required Storage Array interface:
5. Discover the newly presented devices using the oracle.sh script
   
   # sh -x oracle.sh
    
6. The Veritas vxdiskconfig command can used to execute two commands in a single operation:
   
   # devfsadm -c disk
   # vxdctl enable
    
7. The newly presented device paths should now be visible to VxVM
   
   # vxdisk path| grep
   
   or 
   
   # vxdisk path | egrep "(${LUN})"
   c4t500601613EA07595d1s2     emc_clariion0_5      -            -            ENABLED
   c3t500601693EA07595d1s2     emc_clariion0_5      -            -            DISABLED
   c3t500601613EA07595d1s2     emc_clariion0_5      -            -            DISABLED
   c4t500601693EA07595d1s2     emc_clariion0_5      -            -            ENABLED
   
   In this instance, we can see the newly presented c3 controller paths
   
   or
   
   # vxdisk path | sed "s/t/::/g;s/d/ /g;s/s2//g" | egrep "(${LUN})"
   c4::500601613EA07595 1     emc_clariion0_5      -            -            ENABLED
   c3::500601693EA07595 1     emc_clariion0_5      -            -            ENABLED
   c3::500601613EA07595 1     emc_clariion0_5      -            -            ENABLED
   c4::500601693EA07595 1     emc_clariion0_5      -            -            ENABLED
   
   The DMPNODE "emc_clariion0_5" now has 4 paths via two different controller c3 and c4

DMPDR TOOL:

The process can be automated using the DMPDR tool:

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