I had a drive (LTO1) replaced in a StorageTek L180 and since then, I have been unable to get the windows media server or the esx media server to see the new drive. On the ESX media server, I went into /dev and moved the driver files to another location and rebooted the server to see if it would pick up the new drive. No dice. Through the NB admin console i tried to scan for new devices, but then I thought that was pointless, if the esx server and the windows server do not see the drive, then scanning for it will not produce any results. I log into the interface of the library and it sees the drive there, the technician says he hooked it up properly, but I am not sure what to do at this point. Any suggestions on steps to get this drive to recognize?
You are correct that it is pointless to try to add this drive in NBU if the operating systems can't see the drive.
And, since 2 different media servers can't see the drive, it suggests some other common point of failure. If you are convinced that the drive is properly connected, a switch or bridge could be a likely culprit. There could be a hung SCSI reservation on that type of device that is causing the problem. The best thing to do would be to power down all devices and servers and reboot "backwards in the chain." That is, boot the devices in the following order, giving each device a few minutes to properly initialize.
Library Switches / Bridges Media Servers
If that still doesn't work, contact STK and find out how to install their Web interface into the library. There should be one available. The significance of this is that rather than seeing the drive directly at the robot, you introduce the same elements (O/S, switches, etc.) upon which NBU depends.
If you are unable to see the drive via the Web interface, you can force STK to take more ownership. You can say, "Hey guys, it's your drive and I'm trying to use your utility, what's up?"
Assuming this is a Fibre connected drive. Can you see it online on switch? Usually, WWN for drives remains same even after replacing the dirve, but if there was anything else changed along with drive, you may have a new WWN. If you are using persistent binding, you will have to update the binding/zoming for this WWN change.
thanks for the post. The problem did happen to be WWN. I find it interesting, but worth looking into. I have two libraries, each in different states. The same day I had a drive replaced in both libraries. One drive recovered without problems, and the one I posted about, of course, caused me problems. I am wondering if the technician at the remote location replaced the component holding the drive as well as the drive and not just the drive itself. In my location the tech replaced only the drive and the WWN did not change, and as a result, came up immediately. At the DR site, I am thining the drive and power supply unit were replaced causing a change in the WWN and then on the switch had to be reconfigured.
If the L180 firmware is similar to the L700 firmware, it can operate in 1 of 2 WWN modes - drive based or library based : what you describe is consistent with one example of each of these options (there are more technically accurate ways to describe this concept, but off-hand, I can't recall the exact terms).
If naming is drive-based, you see the drive's WWN : if it's library-based, you see a WWN that reflects the drive slot occupied in the library; obviously, one of these changes, the other doesn't. You can check which of these you're using from the library's configuration settings.