Volume config not updating properly after running robot inventory

[Dave__G]

Hi

Basic Setup
=========

MSL6000 tape library connected to master/media server running Netbackup 7.6.0.1.

Problem
======

3 tapes that are not physically in the library are showing up in Netbackup as being in the library. The 3 slots show up as being empty on the library console panel, but they show up as having tapes allocated in Netbackup.

Trouble-shooting attempted
====================

I've tried re-inventorying the robot, resetting the unit, to no avail - the 3 slots show as empty on the robot device console, but Netbackup insists that these 3 slots (23, 25, 27) have a tape in the Netbackup Pool assigned to them. If I try to import the correct physical tape to it's reported slot, a get an error message "Barcode not unique in database (36)". If I try to rescan an empty slot, Netback reports it can't do this as the slot is empty, but still shows a tape being allocated to that slot. If I insert the tape into the slot and try to rescan the barcode, it reports as having done this successfully, but I sill get the "Barcode is not unique in database (36)" error when trying to inventory the robot.

In addition, the 3 tapes in question only show the netbios name for the Robot Control Host, all other tapes show the FQDN. Unsure if this is a red herring?

For troubleshooting purposes we can refer to a single tape/slot, the tape being PJ4900, slot number is 27.

Thanks in advance

[RamNagalla]

 whatt do you mean for  "  3 tapes in question only show the netbios name for the Robot Control Host, all other tapes show the FQDN."

"Barcode not unique in database (36)", indicates, netbackup find the same barcode in the DB that you are trying to insert..

do eject the 3 tapes from the netbackup and make sure they are removed from the MAP and do the inventory after you eject the tapes..

and then insert then again and see how it goes...

[jim_dalton]

What does robtest make of the situation?

And do you have any other interfaces that can you give an independant viewpoint eg something on the robotics side only ...MSL is HP right so you should be able to talk to the webadmin console for same.

Jim

[Dave__G]

In the admin console, under Media and Device Management, Media, Robots, highlight the robot. Looking at the tape details in the RHS pane, the 3 slots in question list the Robot Control Host as servername, all the other tapes listed (about 45) list the Robot Control Host as servername.domainname

The tapes are not physically in the library, so I can't eject them. I need to get Netbackup to accurately reflect this.

[RamNagalla]

since netbackup is considering them in library try to do the eject from Netbackup --GUI-->meida..

right click and eject... see how it goes..

[mph999 · Accepted solution]

You can't add another tape with the same barcoe, as you have found.

If you right click the tape in the GUI, select move, you can set it to non-robotic (effectivly eject it in NBU, without ejecting it i the library).

If an inventory doesn't, within NBU, put it back in a slot, then move to robtest.

If you have unix/ linux RCH, run tpconfig on the RCH and note the path to the library, I'll call it <lib_path>

echo 's s' |tldtest -r <lib_path> is a neat way to run the show slots robtest command straight to the screen.

If this doesn;t work for some reason, or you are on windows, just go into robtest and run s s command.

Do you see the tapes listed in those slots ? ('m guessing the answer is no, given what the library console shows).

What you see in robtest is what the library tells NBU is there, not what NBU sees - so put simply this is gong to be an issue with the library not displaying what is in it's slots correctly.

Unlikely, but if these these slots have somehow been set (within the library ) to cleaning slots, that would cause the tapes to be not visible in NBU.  If it's not this, then you have a library fault.

Not sure about the netbios name, buut hopefully setting the tapes to non-robotic will remove this from being an issue.

Other ideas ...

Does robtest a a output show these tapes anywhere,

If you move the tapes in the library physically to other slots, do then then appear in NBU.  Remember to first make the non-robotic.

[Marianne]

I would like to see what robtest shows for these slots:

s s23
s s25
s s27

As well as vmcheckxxx command:

<install-path>\veritas\volmgr\bin\vmcheckxxx  -rt <robot_type> -rn <robot_number> -rh <robot_control_host>

If lots of output, send output to a file, e.g.

vmcheckxxx  -rt tld -rn 0 -rh master-name >c:\temp\robot.txt 
(If robot type is tld, robot number is 0, master is the robot control host and if temp folder exists or to any other folder)

[Dave__G]

Thanks for all your suggestions.

I was able to resolve the issue by moving the volume in Netbackup to a standalone robot. The physical tape was then inserted into the correct slot, and the volume moved back to the correct robot and slot number in netbackup. The tape was correctly recognised, and the robot was correctly listed as servername.domainname rather than just the servername.

Many thanks

[Marianne]

If media location has changed without first removing it from the robot (to Standalone), you will experience this type of issue. 
A normal Inventory can change location from robotic to Standalone, or from Standalone to slot in robot, not from one slot to another.

Please try not to open the robot door and manually add/move/remove media.

This creates issues as you have experienced here.

Best to use the CAP/MAP to eject and insert media.

The steps you have followed to fix the issue as basically described in mph999's post:

If you right click the tape in the GUI, select move, you can set it to non-robotic (effectivly eject it in NBU, without ejecting it i the library).

Please mark his post as Solution.

[Dave__G]

Thanks for your advice, I've marked the post as a solution.

We normally use the MAP ports, but on this particular robot it isn't practical due to time constraints (only 2 MAP ports). This is the first time we've had such an issue, having recently upgraded to 7.6.0.1. We'll continue to monitor the situation.

Thanks again to everyone, thread can be closed from my point of view.