robotic path changed following library reboot

[tythecellist]

Hello friends.  Following a reboot of one of our libraries (Quantum Scalar i6000, 26 x IBM LTO5 drives)  after a repair, I see that although the RHEL host continues to see all the drives, the robotic path changes.

<IO card failure on library TLD(0)>

Jan 9 20:19:37 host1 tldcd[22163]: TLD(0) [22163] robotic path /dev/sg11 does not exist

<changed robotic path inside Media and Device Management --> Devices --> Robots.  Note sg19 device.>

Jan 9 20:25:23 host1 tldcd[22163]: TLD(0) Library communications established, but no drives in library
Jan 9 20:25:42 host1 kernel: ch0: ... finished
Jan 9 20:25:42 host1 kernel: ch 1:0:3:6: Attached scsi changer ch0
Jan 9 20:25:42 host1 kernel: ch 1:0:3:6: Attached scsi generic sg19 type 8
Jan 9 20:25:55 host1 tldcd[22163]: TLD(0) Library communications established, but no drives in library

<LIBRARY REPAIR AND REBOOT, THEN STOP/RESTART OF NETBACKUP>

Jan 11 09:23:24 host1 nbvault: Starting nbvault daemon
Jan 11 09:23:25 host1 vmd[42024]: ready for connections
Jan 11 09:23:35 host1 tldcd[42827]: starting tldcd
Jan 11 09:23:41 host1 tldd[42717]: TLD(0) going to UP state
Jan 11 09:23:42 host1 tldd[42717]: TLD(1) going to UP state

I've found that manually changing the path in Media  and Device Management --> Devices --> Robots allows me to regain connectivity with the library, but that stopping/restarting NBU is the most reliable process for getting the robot aware of the drives ... which, in our environment, is a lengthy one.

Here's my question: If the robotic path changes, is there any recourse other than stopping/restarting NBU on master and media servers ?  

Thanks!

[mph999 · Accepted solution]

Unfortunately not, if the path changes, then the NBU config will need to be changed to reflect this, which will require a restart of ltid on the robot control host.

Can you implement persistent binding (requires the HBA utility to be installed (sansurfer or HBAnywhere depending on HBA brand).  This should 'glue' the path in place and stop it from changing.

[tythecellist]

Yeah, as I suspected.  Thanks for the insight, mph999.   Since we have 15+ media servers, I was hoping to avoid the hassle of stopping/restarting NBU as a whole, but that may be a more reliable practice in this situation than stopping/restarting ltid. 

[tythecellist]

RESOLVED.  Although installation of Emulex HBAnyware will be a good long-term solution to this issue, we've meanwhile gained enough understanding of the interplay btwn RHEL and NBU from  a device perspective to reduce our downtime from several hours (reboots of each host, checking output of 'scan' for correct # of drives and libraries, etc) to less than 15 mins ... so we're pretty happy about that.

Thanks all!

[mph999]

When ltid starts, it queries nbemm for the devices, hence the need to restart when something in the config changes.