Your old tape robot, along with the drives inside it has inexplicably gone bad, you've spent hours and exhausted your support contract trying to fix it somehow, but, ultimately, you're left facing the fact that your trusty old steel-and-plastic-jukebox just isn't going to come back. Ever. If you're lucky, your warranty allows for replacement of the tape robot (A Tape Loading Device or TLD) and its internal drives (2, for now, to keep things simple - hcart2 drives, just because). Worst case you've purchased suitable replacements that match the specifications listed in the previous sentence.
Probably, your /dev/rmt directory is populated and you may even have some other logical paths created on your Solaris system that are no longer valid. Once you've connected your "MaxTape24" TLD (which exists only in my imagination, with it's two internal "FACTOTUM-TD2" drives, both working properly according to the on-board diagnostics), you should be able to verify that your system (at the very least) can recognize the TLD and, hopefully, the drives inside it. Assuming all of the equipment is good, and that it's been hooked up (however you like to daisy-chain it) properly, this shouldn't be an issue. You may choose to run:
host # devfsadm -C
before proceeding, to check for new symbolic links that need to made in your hardware device tree (and, with the -C option, remove ones you no longer need - Operating System's discretion, unfortunately), although it may not be necessary.
FINDING THE NEW HARDWARE WITH NETBACKUP FIRST: Now, contrary to what it seemed like I was leading in to, we're going to try to get NetBackup to do all the OS-work for us today (because, if it works, it's f'ing brilliant. Good job. Go home and relax :) Actually, you could probably look at this more as a way of giving NetBackup a good kick in the arse. The kind of kick that makes it stand up and take account of its surroundings ;) A good way to get started is to run the following at the command line (Oh yes, there will be no GUI instruction in these posts. If you use the GUI - which is okay - just right click on the type of thing you want to do something to and select whatever seems to be the most reasonable option from the drop-down menu. ...last on that:)
host # /usr/openv/volmgr/bin/sgscan <-- I would recommend including /usr/openv/volmgr/bin, /usr/openv/netbackup/bin and /usr/openv/netbackup/bin/admincmd in your PATH variable if you spend a lot of time working with NetBackup at the command line.
Your output may differ (even if you run this command on the same box, since I faked up the output to protect the guilty ;), but basically, this output is positive. You'll notice that sgscan has picked up a bit more than just your new TLD and its drives but that's okay. As it stands, this output is very positive, in that you can see that /dev/rmt/0 and /dev/rmt/1 have been properly mapped to the TLD's internal tape drives and the "TLDHAUS MaxTape24" TLD has been properly identified.
Other commands you could use to, basically, get the same information (or peace of mind) would include (but not be limited to) vmoprcmd, tpconfig and tpautoconf. A few examples at the bottom of the post, with the same setup as above (some whitespace has been clipped to save the virtual trees).
And that's it for today. Tomorrow we'll look at several commands (including some we're using today, but with different options) that can be used to "find" those drives if the system doesn't discover them automatically (the first thing you can try is "devfsadm -C" as noted above, followed by another sgscan).
Until then, enjoy the output and we'll continue on tomorrow. Here are a couple of handy anchor-href's for you, so you don't have to try to figure out where the command you're interested in is hiding out amongst all the flotsam below :)
vmoprcmd
tpconfig -d
tpconfig -dl
tpautoconf -t
tpautoconf -a
Probably, your /dev/rmt directory is populated and you may even have some other logical paths created on your Solaris system that are no longer valid. Once you've connected your "MaxTape24" TLD (which exists only in my imagination, with it's two internal "FACTOTUM-TD2" drives, both working properly according to the on-board diagnostics), you should be able to verify that your system (at the very least) can recognize the TLD and, hopefully, the drives inside it. Assuming all of the equipment is good, and that it's been hooked up (however you like to daisy-chain it) properly, this shouldn't be an issue. You may choose to run:
host # devfsadm -C
before proceeding, to check for new symbolic links that need to made in your hardware device tree (and, with the -C option, remove ones you no longer need - Operating System's discretion, unfortunately), although it may not be necessary.
FINDING THE NEW HARDWARE WITH NETBACKUP FIRST: Now, contrary to what it seemed like I was leading in to, we're going to try to get NetBackup to do all the OS-work for us today (because, if it works, it's f'ing brilliant. Good job. Go home and relax :) Actually, you could probably look at this more as a way of giving NetBackup a good kick in the arse. The kind of kick that makes it stand up and take account of its surroundings ;) A good way to get started is to run the following at the command line (Oh yes, there will be no GUI instruction in these posts. If you use the GUI - which is okay - just right click on the type of thing you want to do something to and select whatever seems to be the most reasonable option from the drop-down menu. ...last on that:)
host # /usr/openv/volmgr/bin/sgscan <-- I would recommend including /usr/openv/volmgr/bin, /usr/openv/netbackup/bin and /usr/openv/netbackup/bin/admincmd in your PATH variable if you spend a lot of time working with NetBackup at the command line.
/dev/sg/c0t0l0: Disk (/dev/rdsk/c0t0d0): "SUZUKI MBB2147RCSUN146G" /dev/sg/c0t1l0: Disk (/dev/rdsk/c0t1d0): "SUZUKI MBB2147RCSUN146G" /dev/sg/c0t2l0: Tape (/dev/rmt/1): "BMI FACTOTUM-TD2" /dev/sg/c0t3l0: Cdrom: "Hyundai DV-W28E-R" /dev/sg/c1t0l0: Changer: "TLDHAUS MaxTape24" /dev/sg/c1t1l0: Tape (/dev/rmt/0): "BMI FACTOTUM-TD2"
Your output may differ (even if you run this command on the same box, since I faked up the output to protect the guilty ;), but basically, this output is positive. You'll notice that sgscan has picked up a bit more than just your new TLD and its drives but that's okay. As it stands, this output is very positive, in that you can see that /dev/rmt/0 and /dev/rmt/1 have been properly mapped to the TLD's internal tape drives and the "TLDHAUS MaxTape24" TLD has been properly identified.
Other commands you could use to, basically, get the same information (or peace of mind) would include (but not be limited to) vmoprcmd, tpconfig and tpautoconf. A few examples at the bottom of the post, with the same setup as above (some whitespace has been clipped to save the virtual trees).
And that's it for today. Tomorrow we'll look at several commands (including some we're using today, but with different options) that can be used to "find" those drives if the system doesn't discover them automatically (the first thing you can try is "devfsadm -C" as noted above, followed by another sgscan).
Until then, enjoy the output and we'll continue on tomorrow. Here are a couple of handy anchor-href's for you, so you don't have to try to figure out where the command you're interested in is hiding out amongst all the flotsam below :)
vmoprcmd
tpconfig -d
tpconfig -dl
tpautoconf -t
tpautoconf -a
