08-04-2017 04:33 AM
Currently have a server which is Windows Server 2003 running Netbackup 7.0.
I have a robot with two drives - Dell PowerVault 132T.
I have been having a problem readding the Robot to Netbackup, when i am running the scan it is only picking up the two drives.
I have had the robot on the netbackup before but i had to readd the drives which i had accidently removed the robot as well.
It is on a NDMP set up but i dont have the full info to manually add it in.
The medium changer can be seen in Device Manger. and the device can be accessed through its webGUI.
I know this is out of support officially but any help would be much appreciated?
08-04-2017 04:43 AM - edited 08-04-2017 04:45 AM
Hi
What is being returened by
tpautoconf -report_disc
tpautoconf -r
tpautoconf -t
tpconfig -d
vmglob -listall
Is this library SCSI or FC connected. I would have stopped NBU and restarted it...
08-04-2017 05:19 AM
FC i believe (assuming you mean fibre)
I have restarted the device management multiple times. Do you mean to restart the whole services?
tpautoconf -report_disc
C:\VERITAS\Volmgr\bin>tpautoconf -report_disc
======================= New Device (Drive) =======================
Inquiry = "IBM ULTRIUM-TD3 6B20"
Serial Number = 1210101036
Drive Path = Tape0
======================= New Device (Drive) =======================
Inquiry = "IBM ULTRIUM-TD3 6B20"
Serial Number = F09E8BD000
Drive Path = Tape1
tpautoconf -r
Blank
tpautoconf -t
C:\VERITAS\Volmgr\bin>tpautoconf -t
TPAC60 IBM ULTRIUM-TD3 6B20 1210101036 3 0 0 0 Tape0 - -
TPAC60 IBM ULTRIUM-TD3 6B20 F09E8BD000 3 0 1 0 Tape1 - -
tpconfig -d
C:\VERITAS\Volmgr\bin>tpconfig -d
Id DriveName Type Residence
SCSI coordinates/Path Status
****************************************************************************
Currently defined robotics are:
EMM Server = ac2bckcov01
vmglob -listall
C:\VERITAS\Volmgr\bin>vmglob -listall
=====================================================================
08-04-2017 05:24 AM
I have added some screenshots if it helps at all
08-04-2017 05:52 AM
Hi
Rescan this server under device manager, if possible reboot it. Please restart this library - power cycle. Double check on which drive the robot LUN is being assigned to - is this drive zoned with you media server? Check with some HBA native utility if the robotic arm LUN is there
08-04-2017 06:02 AM
Done the rescan multiple times, it stays the same. Rebooting will require me to physically press F1 on the keyboard, sadly i am 200 miles away. Power cycled the library multiple times as well.
Checking which drive the robot LUN is on. Would I be able to do this remotely? I believe it is zoned. I don't believe we have a utility.
08-04-2017 06:02 AM
There is a problem with VOX currently - attachments are not visible in forum posts.
(I have brought it to the admins' attention).
If you delete the Medium Changer in Windows Device Manager and rescan, does the device come back?
The fact that scan and tpautoconf do not show the robot, means that the device is not responding to scsi-commands.
This is caused by either a physical connection issue or something wrong with the hardware.
08-04-2017 06:09 AM
Possibly something wrong with the hardware, we had an engineer out regarding it. This Powervault does use 2 fibre connections. I assume one for the robot and one for the two drives.
Regarding deleting it, i can only disable and uninstall. i have already done the disable and reenable.
The strange thing is, is that i had connected the robot to Netbackup not 5 minutes before, removed it and the drives from netbackup and tried to scan again only the drives show. so physically nothing has changed.
08-07-2017 12:04 AM
Can you see the robot/medium changer in the volmgr\bin\scan command ?
Being Windows make sure you have deleted all ghost devices before rescanning with the OS.
Ghost devices can been seen by runnning
devmgr_show_nonpresent_devices=1
devmgmt
Then choosing show hidden devices
At least on Windows 2008 & 2012
08-07-2017 12:53 AM
Please remove the DELL driver for the library - Veritas recommends to use the default Windows driver that will show the library as 'Unknown Medium Changer'.
Uninstall the library, then rescan in Windows Device Manager.
The robot should now appear as 'Unknown Medium Changer'.
Check that Removable Storage Service is stopped and disabled.
Please run 'scan' and show us the output.
08-07-2017 02:37 AM
The DELL driver should work... we haven't changed anything on the server for years with no real problems, being it 2003 as well its out of support with Microsoft and NB7.0 its out of support with Veritas.
this has only been an issue when an engineer was called to resolve an issue with that very library, which makes me think there is an issue with it physically. Possibly the fibre cables plugged in the wrong ports.
08-07-2017 02:41 AM
You will need to get onsite along with the hardware engineer.
You are not going to get this fixed remotely.
08-07-2017 03:00 AM
Sadly I thought that was the case. 3 hours drive to set up now, the joys.
I will put forward what you have suggested about removing the drivers.
08-07-2017 03:44 AM
Curious do you have persistent binding setup for these tape and robot ? Helps keep the SCSI id the same over reboot.
Seem to remember that was an issue with Windows 2003, that the SCSI id's changed.
08-07-2017 05:59 AM
thats the issue. without being there i can't exactly check...the guiding i have to give to the people on site, wont be able to cover getting the information over the phone due to the fact I havent a clue what I am looking for in that case.
i am completely unfamiliar with the hardware.
I am assuming i wont be able to find this information on Windows 2003 after boot up?
08-07-2017 08:03 AM - edited 08-07-2017 08:07 AM
I can only sympathise. Without remote access by a skilled tech (i.e. you) then something like this is almost impossible to work via intelligent hands and feet and having someone read screen output to you and click a mouse for you and enter commands for you.
If you had remote login access to the server, and to the SAN switches, and to the tape library management console, then maybe you could prove that cables had been accidentally swapped, in which case - if the cable swap has not resulted in a loss of topology resilience then maybe, just maybe, a simple SAN re-zone would be the first step - but unlikely.
As for how to check whether persistent binding is in place... there is no simple answer... because all HBA manufacturers through different card families, and different card chip sets, and different card bus technologies, and different operating systems, and different actual HBA management tools, and different versions of all of that, and different "terminology", and in different places... you get the idea... there is no one single thing to look for in one single place that is always the same... but one thing that is common is that they pretty much all support "persistent binding". But where is it? Well, you'll certainly have a hard time finding it without access to the HBA management tool i.e. the HBA "admin GUI / console / CLI".
Persistent binding is not a SCSI thing (but it kind of is), and it's not a NetBackup thing (it really is not - really, it isn't), and it's not a FC SAN thing (but it kind of is)... and so really, persistent binding is an HBA thing... because persistent binding sits just below the SCSI layer and just above the FC layer - but as for where any vendor decides to put the controls for persistent binding in their HBA management software is anyone's guess. This is a fact of storage life, and it ain't gonna change any time soon.
Right then, no whatter what happens, and even if you do manage to implement persistent binding then it is highly likely that you are still going to have to in NetBackup... "delete devices, rescan, and reconfigure storage units" in NetBackup. Have you done this before?