From the below, it's fairly obvious you are not running the IBM ATape
driver to your new drives. I know both of our Sun servers are running
with ATape to 3590Es - 4 drives attached by direct SCSI and 3 shared
over a SAN, all working fine.
The 'st' entries in /dev/rmt/* are those drives attached with the ATape
driver. See /usr/kernel/drv/IBMtape.conf and /kernel/drv/st.conf.
There shouldn't be any overlaps, otherwise the drivers will fight
and there be problems.
You may have to configure the QLC driver to bind the drives WWNs to
SCSI IDs that are probed by ATape. I don't have access to our Sun
boxes ATM, but hopefully this may help.
On Tuesday, Sep 30, 2003, at 04:54 Australia/Sydney, Luke Dahl wrote:
We're having issues defining our 3590H1A SAN attached drives to tsm.
TSM v: 5.2.0.2
Server: Solaris 9 (v480 - attached to the 2109 and in the AL drive
zone)
Switch IBM 2109-F16
Library: 3494
IBMtape version: 4.0.7.7
We are in the process of migrating from 3590B1A'a to H1A's (total of
eight drives in the library)
Four of the drives have been updated to H1A (testing), three of the
drives are SCSI attached B1A's (in production) and one drive is not
attached at all (pending an upgrade to H1A). I can't seem to define a
path to the H1A drives and test with them. My transition is held up
and
the library is at capacity right now - I'm beginning to have to move
tapes out (a big no no here). Any thoughts? Anyone else done the same
thing (Solaris, 2109, H1A's)??? I've got a ticket open with tech
support (now at level 3) but haven't received any good information -
they don't even seem to be sure if we need the "st" device. I assumed
"st" was for scsi entries only. I tried defining a path using the
existing entries but keep getting errors. Thanks in advance for your
assistance.
The issue is in attempting to define the four H1A's to our test server.
In /dev/rmt/ there are no "st" entries to allow us to define a path to
the drives. Output from /dev/rmt/ ls:
(2)eis-smn-bk05{ldahl}: ls
0 0cn 0lb 0mn 1 1cn 1lb 1mn 2 2cn 2lb 2mn
3 3cn 3lb 3mn
0b 0h 0lbn 0n 1b 1h 1lbn 1n 2b 2h 2lbn 2n
3b 3h 3lbn 3n
0bn 0hb 0ln 0u 1bn 1hb 1ln 1u 2bn 2hb 2ln 2u
3bn 3hb 3ln 3u
0c 0hbn 0m 0ub 1c 1hbn 1m 1ub 2c 2hbn 2m 2ub
3c 3hbn 3m 3ub
0cb 0hn 0mb 0ubn 1cb 1hn 1mb 1ubn 2cb 2hn 2mb 2ubn
3cb 3hn 3mb 3ubn
0cbn 0l 0mbn 0un 1cbn 1l 1mbn 1un 2cbn 2l 2mbn 2un
3cbn 3l 3mbn 3un
sample from ls -la
# ls -la
total 204
drwxr-xr-x 2 root sys 1536 Sep 26 18:34 .
drwxr-xr-x 15 root sys 4096 Sep 29 10:54 ..
lrwxrwxrwx 1 root root 68 Sep 26 18:30 0 ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:
lrwxrwxrwx 1 root root 69 Sep 26 18:30 0b ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:b
lrwxrwxrwx 1 root root 70 Sep 26 18:30 0bn ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:bn
lrwxrwxrwx 1 root root 69 Sep 26 18:30 0c ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:c
lrwxrwxrwx 1 root root 70 Sep 26 18:30 0cb ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:cb
lrwxrwxrwx 1 root root 71 Sep 26 18:30 0cbn ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:cbn
lrwxrwxrwx 1 root root 70 Sep 26 18:30 0cn ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:cn
lrwxrwxrwx 1 root root 69 Sep 26 18:30 0h ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:h
lrwxrwxrwx 1 root root 70 Sep 26 18:30 0hb ->
../../devices/pci@8,600000/SUNW,qlc@2/fp@0,0/st@w5005076300406311,0:hb
We've commented out the scsi entries in the st.conf file and the only
remaining entry is:
#
#name="st" class="scsi" target=0 lun=0;
#name="st" class="scsi" target=1 lun=0;
#name="st" class="scsi" target=2 lun=0;
#name="st" class="scsi" target=3 lun=0;
#name="st" class="scsi" target=4 lun=0;
#name="st" class="scsi" target=5 lun=0;
#name="st" class="scsi" target=6 lun=0;
#
#In case there are wide tape drives, one can use these targets
#
#name="st" class="scsi" target=8 lun=0;
#name="st" class="scsi" target=9 lun=0;
#name="st" class="scsi" target=10 lun=0;
#name="st" class="scsi" target=11 lun=0;
#name="st" class="scsi" target=12 lun=0;
#name="st" class="scsi" target=13 lun=0;
#name="st" class="scsi" target=14 lun=0;
#name="st" class="scsi" target=15 lun=0;
# This line adds support for Fibre Channel Tapes
name="st" parent="fp" target=0;
Attempts at defining a path using the existing entries (sample):
09/29/03 11:35:59 AM ANR2017I Administrator LDAHL issued command:
DEFINE PATH
TSM05 0H SRCTYPE=SERVER DESTTYPE=DRIVE
LIBRARY=3494 DEV
VICE=/dev/rmt/0c ONLINE=YES
09/29/03 11:35:59 AM ANR8315E DEFINE PATH: The device type of drive 0H
is not
supported in 349X libraries.
09/26/03 11:37:24 AM ANR2017I Administrator LDAHL issued command:
DEFINE PATH
TSM05 0H SRCTYPE=SERVER DESTTYPE=DRIVE
LIBRARY=3494 DEV
VICE=/dev/rmt/Oh ONLINE=YES
09/26/03 11:37:24 AM ANR8420E DEFINE PATH: An I/O error occurred while
accessi
ing drive 0H.
So is 0h an accepted device driver? I'm up against a wall here.
Thanks
everyone.
Luke Dahl
Service Engineer, JPLIS Backup/Recovery
NASA-Jet Propulsion Laboratory
818-354-7117
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams
|
