Forum Discussion

Shaf's avatar
Shaf
Level 6
12 years ago

Missing Drive Path

Already did

OS can see devices (/dev/rmt entries)

tpconfig -d

Shows

some drives up and

some drives with missing path.. 

-->cfgadm -al

-->cfgadm -c configure

-----------------------------------------------------

-->Reset HBA

-----------------------------------------------------

-->Hard reset Drives in Library

-----------------------------------------------------

-->mt -t /dev/rmt/## status

output:

no such file or directory

----------------------------------------------------------

Cluster Envir

NBU 7.1

Solaris

Drives SAN attached

7.1.x and Earlier
Backup and Recovery
NetBackup
  • mph999's avatar
    mph999
    12 years ago

    You didn't follow my advice (or if you did, apologies, but you have not explained that you did).

    As Maianne explained, forget NBU - the cause is not NBU (although it is affected).

    You need to prove at the OS level that all the drives are visible.

    Do exactly these steps, do not miss any out.

    1. Remove the drives from NBU config

    2. Remove the /dev/rmt/ files

    3. Run devfsadm or reboot server

    4. Run cfgadm -al  - do you see all the drives, if so, goto 6, if not goto 5

    5. Run cfgadm -al -o show_FCP_dev , do you see all the devices

    (If any are missing you have an OS / device issue) - if they are all there continue

    5b.  Confirm all the drives have a device file in /dev/rmt

    5c.  Confirm all the drives respond to this command 

     

     
    /usr/openv/volmgr/bin/scsi_command -d /dev/rmt/0cbn
    /usr/openv/volmgr/bin/scsi_command -d /dev/rmt/1cbn
    /usr/openv/volmgr/bin/scsi_command -d /dev/rmt/2cbn
     
    (Substitute in each device file, 0cbnm, 1cbn, 2cbn etc ...)
     
    For each drive, the command should give details like this:
     
    Inquiry data: removable dev type 1h HP      DAT72X6         B604
     

    6.  Run scan, do you see all the devices, if not rebuild the sgdriver like this

    7. (Follow these commands exactly ...)

     

    cd /usr/openv/volmgr/bin/driver
    cp sg.conf sg.conf.safe
    cp sg.links sg.links.safe
    ../sg.build all   (should not need mt /-mt options, drives will be using WWN)
    modunload -i $(echo $(modinfo |grep "sg (SCSA" |awk '{print $1}'))
    mv /kernel/drv/sg.conf /kernel/drv/sg.conf.old
    /usr/openv/volmgr/bin/driver/sg.install
     

     

    8.  Run scan - do you see all the devices, if so, configure the drive in NBU - if not you have device issues.

    Until scan shows the devices, do not run any other NBU commands.

     

    Martin

35 Replies

Sort By
Replies have been turned off for this discussion
  • revarooo's avatar
    revarooo
    Level 6
    12 years ago

    Ok so the device paths do not reference any hardware anymore. Either the hardware is now not presented at SAN level or you do not have persistant bindings set at the HBA level and they are now showing on another device path.

    Delete the drives that show the missing drive paths: volmgr/bin/tpconfig -delete -drive <drive index>

    then use volmgr/bin/scan to see if you can see the drives. If you can, volmgr/bin/tpautoconf -a will discover all devices and add them to NetBackup

    note: volmgr is located on unix in /usr/openv/     on windows usually c:\program files\veritas\

     

     

  • Marianne's avatar
    Marianne
    Level 6
    12 years ago

     

    mt -t /dev/rmt/## status

    output:

    no such file or directory

    The fact that device path exists does NOT mean that OS can see the device.

    Your OS has lost connectivity to the drive or else device path has changed due to non-existing Persistent Binding. Check /var/adm/messages for device-related errors.

    Do 'devfsadm -C -c tape' to remove non-existing device paths.

    Lookup 'Persistent Binding' for your HBA make/model. This will prevent device name change when system is rebooted.

     

  • Shaf's avatar
    Shaf
    Level 6
    12 years ago

    Revaroo,

    after I delete the drive with
    volmgr/bin/tpconfig -delete -drive <drive index>

    now I am unable to see drive with scan command

     

    Need to run cfgadm -c configure???

  • mph999's avatar
    mph999
    Level 6
    12 years ago

     

    after I delete the drive with
    volmgr/bin/tpconfig -delete -drive <drive index>

    now I am unable to see drive with scan command

     

    No - scan command will not have shown drives before you deleted the drive config.

    scan has absolutly 100% nothing to do with the drive config shown in any tpconfig or vmoprcmd command.

    cfgadm probably won;t help, I suspect the command you need is devfsadm.

    Persoanlly I would delete all the drives on this server from NBU and from the OS (rm the /dev/rmt files) and then reboot and see what comes back (hopefully all the drives).

    If after the reboot some drives are missing (at the OS level) then you have an issue between the OS and the drives, and thiss needs to be fixed first.

    Once all the drives are visiable at the OS level, check each responds with :

    mt -f /dev/rmt/xcbn stat

    Once this is confirmed, run scan - are all the drives visible.

    If yes, then reconfigure the drives in NBU and check that persistant binding is set.

    If scan does not show all the drives, you may need to rebuild the sg driver, but this is not that likely.

    Martin

  • Shaf's avatar
    Shaf
    Level 6
    12 years ago

    devfsadm -C -c tape' to remove non-existing device paths.

    does it remove all Drives with missing drive path, 
    after that how can i add them back to netbackup..and does it effect active jobs, tape and DD jobs are running..now..

     

    Thanks

     

     

  • Yasuhisa_Ishika's avatar
    Yasuhisa_Ishika
    Level 6
    12 years ago

    mt -t /dev/rmt/## status

    output:

    no such file or directory

    This means link target of /dev/rmt/## does not exist - OS can not see drive or OS can see drive through other device file. You said "OS can see devices", but it is unclear.

    For first, you have to run "devfsadm -C -c tape"(or simply "devfsadm -C") as Marianne suggested to get OS recognize tape drives.

    Then you have to rebuild sg driver configuration following this technote.

    http://www.symantec.com/docs/TECH71073

  • Yasuhisa_Ishika's avatar
    Yasuhisa_Ishika
    Level 6
    12 years ago

    After thar, you can see drives in scan command. Then, run Device Configuration Wizard("Configure storage devices") in GUI to configure tape drives.

  • Marianne's avatar
    Marianne
    Level 6
    12 years ago

    devfsadm -C -c tape will scan for devices, leave existing, valid device names, remove non-existing devices, create entries for devices with no valid device names. 

    You really need to forget about NBU and troubleshoot at OS level. 
    Device-related errors will be logged in /var/adm/messages.
    Also ensure Persistent Binding is in place.
     

  • Shaf's avatar
    Shaf
    Level 6
    12 years ago

    I run devfsadm -C -c tape

    but still, I see some drives with missing drive path

    in tpconfig -d