device files MSL6030 library HP-UX

[Kurt Beyers.]

Hi,

I've got an MSL6030 library with two LTO2 drives that is (or should be) seen by four HP-UX servers through the SAN.

An old library (Surestore E2/20) was removed from the SAN switch and the new library was connected to the same switch port.

The NSR was configured wel (mappings were created and the FC HBA WWN were seen by the NSR). However an 'ioscan -fnC tape' and 'ioscan -fnC autoch' didn't give any results. I've been double checking the NSR setup and any zoning (mis)configurations, but it was all fine. At the end one of the HP-UX server (non critical) was rebooted and then the Ultrium drives and robot arm was detected.

Why is a reboot required or what extra commands should I run from a shell in order to detect the new library? I thought the ioscan should pick up the new library (as stape and schgr were alreaydy in the kernel)?

And I still got a second question. The output of the ioscan -fnC tape shows for 1 of the 2 drives 8 device files as I would expect:

/dev/rmt/1m
/dev/rmt/1mn
/dev/rmt/1mb
/dev/rmt/1mnb
/dev/rmt/c41t0d0BEST
/dev/rmt/c41t0d0BESTn
/dev/rmt/c41t0d0BESTnb
/dev/rmt/c41t0d0BESTB

while for the other drive only 4 device files are shown:

/dev/rmt/c41t0d2BEST
/dev/rmt/c41t0d2BESTn
/dev/rmt/c41t0d2BESTnb
/dev/rmt/c41t0d2BESTB

The device files for the first tape drive /dev/rmt/1mn and /dev/rmt/c41t0d0BESTn should be the same pointing to the device file that is used in Data Protector.

If I run an autoconfigure of the library in DP, only the drive with the 8 device files is detected automatically by the software. The other is not seen, but can be added of course manually. However the usage of the tape drive (with 4 device files) is having difficulties in DP (slow response and so on). The other behaves as one should expect.

So how does it come that there are 8 device files for the first drive and only 4 for the second drive? I've done already an 'insf -e' of course but that does not change anything.

Thanks for any advice, I must be missing something some where.

best regards,
Kurt

[Torsten.]

Hi Kurt,

did you remove the device files for your old lib? I guess, you have to recreate the device files for your new (and different!) drives. Use SAM->periph. devices->recreate dev files, that's better then insf.

[Leif Halvarsson_2]

Hi,

Was the devicefiles for the old library removed before connecting the new library ?

Have you tried rebooting the library ?

Last, what happens if you remove the devicefiles (with rmsf) and recreate again with insf.

[Kurt Beyers.]

The device files were not removed when the new library was connected.

But as it was not detected by the HP servers (although there FC HBA WWN was seen by the NSE) and they only showed up after a reboot of the HP-UX server, the old device files should have been removed and the new device files should be created during the startup of the server (I think).

I'll check it tomorrow what happens if I remove and recreate the device files of the drives and update then the thread again.

best regards,
Kurt

[Kurt Beyers.]

Good morning,

After a better search this morning on the ITRC forums, I've found and solved the issue with the device files.

The tape drive for which were only 4 device files created had an instance number (eg 3) for which existed already 'old' /dev/rmt/3mn files. After removing the old /dev/rmt/3* device files and running an insf -e once more, all of the device files were created too. Data Protector detects the two drives now as well.

But I still don't see why a reboot of the server was required in order to detect the new library. In the ioscan -fn, the following is not being claimed:

fcp 3 0/5/0/0.2 fcp CLAIMED INTERFACE FCP Domain
ext_bus 28 0/5/0/0.2.0.255.0 fcpdev NO_HW INTERFACE FCP Device Interface
target 21 0/5/0/0.2.0.255.0.0 tgt NO_HW DEVICE
autoch 3 0/5/0/0.2.0.255.0.0.0 schgr NO_HW DEVICE HP C7200-8000
/dev/rac/c28t0d0
tape 4 0/5/0/0.2.0.255.0.0.1 stape NO_HW DEVICE QUANTUM DLT8000
/dev/rmt/4m
/dev/rmt/4mb
/dev/rmt/4mn
/dev/rmt/4mnb
/dev/rmt/c28t0d1BEST
/dev/rmt/c28t0d1BESTb
/dev/rmt/c28t0d1BESTn
/dev/rmt/c28t0d1BESTnb

This is the old library that has been removed but why is the FCP Device Hardware not claimed either. This is probably why the new library is not detected untill after a reboot.

regards,
Kurt

[Torsten.]

Hello Kurt,

your server remembers your old lib until you reboot. You are right, ioscan is showing no hardware. But the FC driver may prevent the new lib to log on, because it's also "remember" the old device. Check the syslog file for any message regarding fc driver.

[Kurt Beyers.]

@Torsten,

You are probably right, in the syslog the following messages are logged:

Aug 4 10:04:02 SERVER vmunix: 0/5/0/0: 'World-wide name' (unique identifier) for
device at nport ID 0x20000 has
Aug 4 10:04:02 SERVER vmunix: changed. If the device has been replaced intentiona
lly, please use the
Aug 4 10:04:02 SERVER vmunix: fcmsutil(1M) command's replace_dsk option to allow
the new device to be used.
Aug 4 10:04:02 SERVER vmunix: 0/5/0/0: Fibre Channel Driver detected a parse erro
r in the FLOGI/PLOGI response
Aug 4 10:04:02 SERVER vmunix: returned by nport ID 0x20000. FLOGI/PLOGI Fail Code
= 0x6.
Aug 4 10:04:02 SERVER vmunix:
Aug 4 10:04:02 SERVER vmunix: 0/5/0/0: Unable to access previously accessed devic
e at nport ID 0x20000.

I'll have to dig further into the command fcmsutil replace_dsk, but the access to the SAN disks must not be interrupted of course as there are production databases running on it. A reboot is planned in a few hours.

best regards,
Kurt

[Torsten. · Accepted solution]

Kurt,

the fc driver compares nport id and wwn of the device with his own tables. If one of them is changed, the device is not allowed to log on. You can switch this behaviour off for one logon, so the driver can update the table. By typing

fcmsutil /dev/td.. replace_dsk 0x20000

If you run an ioscan after this, the device is logged on. But in this case it's a good idea to reboot the server, because the server will forget the old lib and welcomes the new one.

[Kurt Beyers.]

The server was rebooted to play it safe and then the LTO2 drives were seen as well.

I had to cleanup the device files a bit as well too.

So Torsten pointed me in the good direction of the issue and Leif answer was also true (should have given more points)

thanks for the assistance,
Kurt

[Bob_Vance]

Did you do a 'rmsf' in your testing prior to the reboot that "fixed" it.

I believe that the following should have worked:

... rmsf -H .... for the changer and each tape path.
... ioscan
... insf -e


bv