Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Can't move robotic control from media server to master

Created: 23 Apr 2013 • Updated: 05 Jun 2013 | 18 comments
This issue has been solved. See solution.

Hi,

Im trying to following TECH30490 as well as the Device Configuration Guide for Solaris but things are not lining up. Basically we are trying to split the robot control off from an existing media server since there is a process running on the box which keeps killing the robot, and vendors have not been able to produce a fix at the code level. The old media server must remain as it controls the drives. The master can see the robot via sgscan, but I cannot make the change as noted in that TN. It simply can't see the robot. During the work trying to move it over, it seems it unconfigured the robot from the media server so now nothing can control it. Is it safe to add a new robot or does it have to be "changed" in the existing one?

thanks!

Operating Systems:

Comments 18 CommentsJump to latest comment

mph999's picture

I would just delete the robot and drives, then select the master and media server in device wizard and readd the lot.

Move media to standalone first, then reinventory at the end. Make note of any barcode / media id rules so then can be readded if they disappear.

Martin

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
schrammd's picture

Ok, that was what I was thinking. The state of the thing now is that I cannot seem to force the old media server to take back over the robot, and, it cannot be remotely managed by the master. I was leary about deleting it since it always seems like there are things to tweak and fix afterwards.

thanks

Marianne's picture

Please show us sgscan output on the master?

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

schrammd's picture

sanjay # ./sgscan
/dev/sg/c0t0l0: Disk (/dev/rdsk/c0t0d0): "SEAGATE ST373207LSUN72G"
/dev/sg/c0t1l0: Disk (/dev/rdsk/c0t1d0): "SEAGATE ST373207LSUN72G"
/dev/sg/c0tw211f0090a500328el0: Changer: "SPECTRA PYTHON"
/dev/sg/c0tw211f0090a500328el1: Changer: "SPECTRA PYTHON"
 

Marianne's picture

So, is SPECTRA PYTHON the robot you need to move?

Master seems to see 2 paths to the robot,, no tape drives?

I don't understand this statement?

The master can see the robot via sgscan, but I cannot make the change as noted in that TN. It simply can't see the robot.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

schrammd's picture

Yes, that is the robot. It only has one path to it. I have no idea why it shows 2 paths. Only one zone, one port.

No tape drives. Not moving the drives to the master only robot.

Yeah, that's what I mean. If I try to "change" the robot control from the existing robot controler, the media server, to remote control by sanjay in the console/wizard, it takes the server name fine, restarts the services, no robot is seen after that.

mph999's picture

I suspect I know why ....

This shows a WWN

/dev/sg/c0tw211f0090a500328el1

Edit the files in /usr/openv/netbackup/volmgr/bin/driver called sg.links and sg.conf, remove the lines that sontains this WWN (one line in each file).  Make a copy of the files first.

Rebuild the sg driver.

ksh

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
 
Hopefully then, you will only see one path to the robot.
If no luck after this, try again, put the original files back, and then remove the other WWN lines instead.
 
Also, before starting, check that at least one of the paths works, if so, remove the one that doesn't, if both work, remove just one.
 
/usr/openv/volmgr/bin/scsi_command -d /dev/sg/c0tw211f0090a500328el0
/usr/openv/volmgr/bin/scsi_command -d /dev/sg/c0tw211f0090a500328el1
 
You should get the result back of the scsi 'inquiry' command.
 
I suspect that the path the robot is via one of the drives (similar to what some IBM libraries do), so it is a library config that causes two paths to be visible (NOTE.  This could be wrong, I'm not familiar with that library, it's just a possible cause).
 
Martin
Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
schrammd's picture

It's a Spectra robot and it can be configured to be controlled via a tape or direct. In our case, the hosts have a direct path to the QIP.

Both /usr/openv/volmgr/bin/scsi_command -d commands were able to talk to the QIP. I think these duplicate entries appeared from repeated failed attempts at getting NBU to recognize the robot, but I have cleaned them up.

I just finally got the entire works back to the state it was before I started this and wonder how I can predict the outcome will be different than last time I tried this. When doing the "change robot" wizard, if you can call it that, when selecting the remote host, all you get is a place to put the host name. How useful. So, if I set the remote control host again and it cannot see the robot, where to from there?

thanks

schrammd's picture

Another 2 attempts failed. If I delete the robot entirely, and the drives, I can add a NEW robot owned by sanjay and it can be inventoried just fine, but of course, go to add the stinking drives and tell them and NO robot is able to be selected at all - the field is BLANK. Recycled all processes after each robot removal/add. It makes no difference. So, I deleted it all again, added a new robot with device manager being my old trusty media server, tell it to use remote sanjay for robotics - can't see anything. It's enought to make me like Windows even more. So, after blowin a day on what should be a 15 minute task, I've rollled it all back to normal. I don't get why such a simple task seems to require a blessing from some higher power for it to just "work".

If anyone has any other suggestions, I'm all ears. I guess it's time to use the 800 number we pay for.

thanks to those who have suggested but no winners yet angry

mph999's picture

Hmm, odd - Solaris is usually very good with devices.

OK, it's real late here, I need some ZZzzz, can you try one more time, but this time delete the device like this :

nbemmcmd -deletealldevices -allrecords

Add it back with the wizard, be sure to select both the master and media server at the same time.

I'm wondering if something has not got cleaned up correctly, the above comand should splat everything.

I can't get to a machine right now to look, but from memory I though that when changing the robot, once you added the host there is an option to select the path - to be honest though, it is so long since I've done it I could be imaging things.  

Perhaps it's time to log a call as I really have to go now, but if you post up the case number I'll take a look.  As I'm sure you will understand, sometimes issues are difficult to fully understand without looking at the system.

What I would certainly recommend, is that you disable to the path to the robot from the 'old' robot control host - it shouldn't really matter, but if you're not using it ...  I had a slight issue myself on linux on a test server where two machine could see the robot (I didn't realise at the time) and I had to serious poke it in the ribs to get it to configure correctly.

Theres something slightly odd here, I have honestly configured solaris devices 100s of times with this issue.  It could be just that I have not quite understood the finer details, or possibly that there is a little something unknown about your system, probably very simple, but without seeing it ...

Apologies that I couldn't resolve this for you in the time we had.

Martin

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
schrammd's picture

I understand about the device thing. We add LUNs on the fly all the time to Solaris boxes. Tape drives and robots not so much. The existing media server is running RHEL and the adding part goes well usually but removals on the fly are about as consistent as the weather. I will try removing the zone for the robot to that server and see if anything changes.

thanks

schrammd's picture

Hi Martin/Marianne

I tried a variation on the them using your hint about the linux deal: I removed the robot port from the zone the linux media server was using. Changed the owner to the master, let the device manager restart. Looked ok until (as other attempts as well) I went to inventory the robot - can't select any robot - drop down is blank. Same story.

sanjay # ../sgscan changer
/dev/sg/c0tw211f0090a500328el0: "SPECTRA PYTHON"
sanjay # ../robtest
No robots are configuredcrying
 

I wasn't eager to run that nbemmcmd -deletealldevices -allrecords command (yet), but I have a question - does the master which we want to run the robot need to be in the bp.conf as a media server? Today, the only media server in the file is the original Linux box.

Is running that nbemmcmd -deletealldevices -allrecords command the only surefire way to purge out all the robot/drive info?

thanks

Marianne's picture

The SERVER entry for the master gives it all media server rights automatically.

Curious to see what 'scan' command reports. Please run it and post output?

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

schrammd's picture

Ok, thought so.

master:

sanjay # ./scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
------------------------------------------------------------
Device Name  : "/dev/sg/c0tw211f0090a500328el0"
Passthru Name: "/dev/sg/c0tw211f0090a500328el0"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "SPECTRA PYTHON          2000"
Vendor ID  : "SPECTRA "
Product ID : "PYTHON          "
Product Rev: "2000"
Serial Number: "901F00328E"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "SPECTRA PYTHON          901F00328E"
Device Type    : SDT_CHANGER
NetBackup Robot Type: 8
Removable      : Yes
Device Supports: SCSI-3
Number of Drives : 3
Number of Slots  : 200
Number of Media Access Ports: 10
Drive 1 Serial Number      : "101100328E"
Drive 2 Serial Number      : "101200328E"
Drive 3 Serial Number      : "101400328E"
Flags : 0x0
Reason: 0x0
 

Media Server with robot removed:

[root@backup104 ~]# /usr/openv/volmgr/bin/scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
------------------------------------------------------------
Device Name  : "/dev/nst4"
Passthru Name: "/dev/sg198"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULTRIUM-TD5     BBN2"
Vendor ID  : "IBM     "
Product ID : "ULTRIUM-TD5     "
Product Rev: "BBN2"
Serial Number: "101400328E"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULTRIUM-TD5     101400328E"
Device Type    : SDT_TAPE
NetBackup Drive Type: 10
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst1"
Passthru Name: "/dev/sg187"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULTRIUM-TD5     BBN2"
Vendor ID  : "IBM     "
Product ID : "ULTRIUM-TD5     "
Product Rev: "BBN2"
Serial Number: "101200328E"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULTRIUM-TD5     101200328E"
Device Type    : SDT_TAPE
NetBackup Drive Type: 10
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst3"
Passthru Name: "/dev/sg197"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULTRIUM-TD5     BBN2"
Vendor ID  : "IBM     "
Product ID : "ULTRIUM-TD5     "
Product Rev: "BBN2"
Serial Number: "101200328E"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULTRIUM-TD5     101200328E"
Device Type    : SDT_TAPE
NetBackup Drive Type: 10
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst0"
Passthru Name: "/dev/sg186"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULTRIUM-TD5     BBN2"
Vendor ID  : "IBM     "
Product ID : "ULTRIUM-TD5     "
Product Rev: "BBN2"
Serial Number: "101100328E"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULTRIUM-TD5     101100328E"
Device Type    : SDT_TAPE
NetBackup Drive Type: 10
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst5"
Passthru Name: "/dev/sg199"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULTRIUM-TD5     BBN2"
Vendor ID  : "IBM     "
Product ID : "ULTRIUM-TD5     "
Product Rev: "BBN2"
Serial Number: "101100328E"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULTRIUM-TD5     101100328E"
Device Type    : SDT_TAPE
NetBackup Drive Type: 10
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst2"
Passthru Name: "/dev/sg188"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULTRIUM-TD5     BBN2"
Vendor ID  : "IBM     "
Product ID : "ULTRIUM-TD5     "
Product Rev: "BBN2"
Serial Number: "101400328E"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULTRIUM-TD5     101400328E"
Device Type    : SDT_TAPE
NetBackup Drive Type: 10
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
 

thanks!

Marianne's picture

All looks fine. 

I can see no reason why Martin's advice won't work:

nbemmcmd -deletealldevices -allrecords

Add it back with the wizard, be sure to select both the master and media server at the same time.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

schrammd's picture

Ok folks, I think we have solved the problem. One of my peers here suggested adding the new robot solely to the master, making sure it is detected correctly. Then, add a "second" robot with the mediaserver as divce host, and master as remote control as the docs say.

Now, I can add the drives and select the robot just fine. Robtest works on the master. The weird thing, and I don't know if this matters, is when you go to inventory the robot, you cannot select the media srv as device host, else the robot is blank (just like before), but if the device host is master, then all is well. Does this make sense and what could be the fallout from this configuration verses the single robot entry with the combined media-remote robot master config?

schrammd's picture

Nope, it simply does not work as suggested. The method I described appears to be the only way in this environment. So, I guess my question is, if it works - is it OK to stick with it? Test duplications working as expected, all signs seem to point to success.

thanks

mph999's picture

Is running that nbemmcmd -deletealldevices -allrecords command the only surefire way to purge out all the robot/drive info?

No, it is the 2nd best way.  In 99% of cases it works, but if you had some real bad issue, the only way to be sure, is to use manual SQL commands.

However, SQL scripts come from Engineering, and they will first request that the deletealldevices command is used first, as it 'should' work.

If anything should be left, that would be when a manual SQL commands would be used to delete any unwanted entries in the DB.

Anyhow, from scan

On the master, in the chager part we see.

Drive 1 Serial Number      : "101100328E"
Drive 2 Serial Number      : "101200328E"
Drive 3 Serial Number      : "101400328E"

The changer should list each drive it has, with different serial numbers.

Look at the serial numbers of the drives on the media

101400328E

101200328E
101200328E
101100328E
101100328E
101400328E
 
Each is listed twice, fine, must be dual paths, and they match what is in the changer section, so no issues on this part.
 
The serial numbers are the imprtant part really, they are used by NBU to work out if drives are in a library, when running the wizard.
 
Apologies if I have missed this, but have you actualy tried to configure this with the device wizard, as opposed to adding the drives manually one-by-one.
 
If you run the device wizrad, and select both  the master and the media at the same time, it should auto configure the drives into the robot.
 
getting late here again, I'll check back tomorrow.
 
Martin
 
 
Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
SOLUTION