robot inventory failed: Requested slot does not exist in robot (228)

[sushil_gulati]

I am very bad at explaining but will try my best. Also will try to add as much information as possible Environment Info: Netbackup Master Server (Replicated Data Clustered-VCS) ------------------------ HARDWARE LINUX_RH_X86 VERSION NetBackup 6.5.5 RELEASEDATE Thu Nov 05 20:53:50 CST 2009 BUILDNUMBER 20091105 Redhat Linux ------------ Linux xxxxxx15 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux 6 Media Servers (All at 6.5.5) 2 linux/2 windows/2 aix Problem Statement ----------------- Robot is not responding to any SCSI command issued from one master cluster node(xxxxxx15). If I failover to the other node (xxxxxx68) everything is working fine. When I say fine I mean I am able to inventory/run successful backups / restores / everything. As soon as I failback to the other node (xxxxxx15) it fails to issue any command to the robot. No Inventory / no robtest / no backups / no restores / nothing. Tried till now ----------------- 1> Removed all the devices from the environment (using nbemmcmd -deletealldevices -allrecords) 2> Device config wizard when one node is active (repeated steps wieth both nodes). 3> Failover to the other node, run device config wizard for that node. 4> After following these steps keeping both nodes as active one by one, the same behavior is noticed. 5> Also I tried to remove the devices a few times and added them using different combinations but no success. Logs ---- /var/log/messages Jun 29 17:03:12 xxxxxx15 tldcd[27154]: TLD(0) Library communications established, but no drives in library Jun 29 17:03:12 xxxxxx15 tldd[27005]: TLD(0) unavailable: initialization failed: Unable to initialize robot Logs while running inventory ---------------------------- /var/log/messages Jun 29 16:06:14 xxxxxx15 tldcd[27154]: TLD(0) 1 is an invalid slot Popup message robot inventory failed: Requested slot does not exist in robot (228) Message while running vmcheckxxx -------------------------------- robot inventory failed: Requested slot does not exist in robot (228) Additional Observations ----------------------- Robtest Result -------------- [root@xxxxxx15 bin]# ./robtest Configured robots with local control supporting test utilities: TLD(0) robotic path = /dev/sg91 TLD(1) robotic path = /dev/sg60 Robot Selection --------------- 1) TLD 0 2) TLD 1 3) none/quit Enter choice: 1 Robot selected: TLD(0) robotic path = /dev/sg91 Invoking robotic test utility: /usr/openv/volmgr/bin/tldtest -rn 0 -r /dev/sg91 Opening /dev/sg91 MODE_SENSE complete Enter tld commands (? returns help information) s s read_element_status ioctl() failed: Success s d read_element_status ioctl() failed: Success mode First transport addr = 0, Number transport elements = 258 First storage addr = 0, Number storage elements = 0 First media access port addr = 0, Number media access port elements = 0 First drive addr = 0, Number drive elements = 0 Library does not have a barcode reader MODE_SENSE complete init Initiating INITIALIZE_ELEMENT_STATUS initialize_element_status failed sense key = 0x5, asc = 0x20, ascq = 0x0, INVALID COMMAND OPERATION CODE q Robot Selection --------------- 1) TLD 0 2) TLD 1 3) none/quit Enter choice: 3 Most Important Point --------------------- This same library is accessible well when we switch to the other node (xxxxxx68) and we are able to eun every of this command including robtest. I am stuck now. Please help

[Kevin_Good]

/usr/openv/volmgr/bin

[Marianne]

First verify O/S accibility to library and tape drives before trying to config in NBU.

Confirm O/S device names as per the Device Config Guide  - Linux chapter, section called 'Configuring tape drive device files'. 

Also confirm that you have the latest Device mappings installed: http://seer.entsupport.symantec.com/docs/351807.htm


Are there two robots attached to this robot? You make mention of one only?

TLD(0) robotic path = /dev/sg91
TLD(1) robotic path = /dev/sg60

[sushil_gulati · Accepted solution]

Apology for a late reply.

It was a small thing which costed us 5 days. Case have to go to backline to find two entries in vm.conf which caused the above problem.

We removed both and we are good.

CLUSTER_NAME=BCKMASTERPROD
DEVICE_HOST=BCKMASTERPROD

I am not sure when and what caused these entries to appear in vm.conf however as soon as we removed these entries and failed over and back we were good. I will research further on these entries once i am done with this assignment and possibly post something more on this but for now this is what resolved the issue.

[Marianne]

Thanks for the feedback. That is quite interesting.

I have just checked our own lab cluster:
root@v240-1 # cat vm.conf
CLUSTER_NAME = nbuclus
DEVICE_HOST = nbuclus

It is most certainly the cluster_config script that has done this.
We only backup to disk, so that is why we're not experiencing failover problems.
I'd like to hear from other cluster users (with robot/tape on the master) to check their config and if they experience the same problems.