Data Protector Problem on Linux

[Sigurdur Bjornsson]

Hi there!
I have a rather irritating problem to say the least... I installed DP 5.5 locally on a computer running RHEL4. I have SAN connected tape drives and at first DP could detect them and use them (although devbra -dev took 5mins+ to complete) but then it stopped working. DP couldn't detect any tape drives even if they were available to the OS. After re-installing DP, pulling hair, trying this and that, and pulling some more hair, I tried re-installing and then upgrading (patching) from a Solaris installation server we have on our network.
Finally DP could detect the drives again but devbra -dev still takes a LONG time to complete.

Has anyone here had the same or similar problem?

(HP OpenView Storage Data Protector A.05.50: DEVBRA, internal build PHSS_32842/PHSS_32843/DPSOL_00151, built on Fri Jul 1 11:23:35 2005)

[Thayanidhi]

Hi,
As per support matrix (attached) RHEL 4.0 is supported as Disk agent only. MA connot be loaded. Posibly some new patches enables this. Read the patch texts.

Regds
TT

[Sigurdur Bjornsson]

Hi Thayanidhi!

I am afraid you are incorrect.
By applying patches:
PHSS_32842 - HP-UX 11.x (PA) CM / IS
PHSS_32843 - HP-UX 11.23 (IPF) CM / IS
DPSOL_00151 - Solaris 2.x CM / IS
you can use the media agent on RHEL4.

I have done so but I still have this problem.

http://www.openview.com/products/storage_data_protector/device_matrices/Platform_Integrtn_SptMtx_DP55.pdf

[Scott McIntosh_2]

You could try running it in debug mode and see what the devbra debug file shows the process sitting around doing.

devbra -dev -debug 1-500 scan.txt

then look for *scan.txt in /tmp.

Most likely it's trying an inquiry against every lun number on the HBA, which if waiting for a timeout everytime, could take a very long time.

Is there a way to limit the allowed LUN range on the HBA to limit the time it takes to scan the SAN?

Thanks,
Scott
HP Support

[Sigurdur Bjornsson]

Hi Scott!

Thanks for the info... here is a snippet from the log....

...
[ 10] AddToPhysicalDeviceList_File: checking token "/dev/nst0" read from "/usr/omni/.ls"

[199] 2005-10-04 16:50:47 ("ma/devtool/devlist_file.c /main/dp55/dp55_fix/1":455) A.05.50 bPHSS_32842/PHSS_32843/DPSOL_00151
[199] ===>> (4) CreatePhysicalDevice {
[199]

[199] 2005-10-04 16:50:47 ("ma/devtool/devlist_file.c /main/dp55/dp55_fix/1":359) A.05.50 bPHSS_32842/PHSS_32843/DPSOL_00151
[199] ===>> (5) DebugPhysicalDevice {
[199]
...

It reads /dev/nst0 ok but once it gets to nst1 funny things happen... (I have the HBA zoned with 4 tape drives)

...
[ 10] AddToPhysicalDeviceList_File: checking token "/dev/nst1" read from "/usr/omni/.ls"

[199] 2005-10-04 16:50:47 ("ma/devtool/devlist_file.c /main/dp55/dp55_fix/1":455) A.05.50 bPHSS_32842/PHSS_32843/DPSOL_00151
[199] ===>> (4) CreatePhysicalDevice {
[199]

[199] 2005-10-04 16:52:48 ("ma/devtool/devlist_file.c /main/dp55/dp55_fix/1":359) A.05.50 bPHSS_32842/PHSS_32843/DPSOL_00151
[199] ===>> (5) DebugPhysicalDevice {
[199]
...

It hangs at "CreatePhysicalDevice" for 2 mins 1 sec per nstXX device after that.

I have another machine running Red Hat Linux 8 or 9, can't remember (kernel 2.4.9)
The whole thing takes a second on that machine. And that one is zoned with 8 tape drives...

Any ideas?

[Kurt Beyers.]

Sigur,

You have to run the command 'hp_rescan -a' in order to make the RHEL4 detect the library.

I ended up by adding this command in a startup script. Still do not now why the library is not detected by default after a sustem reboot.

[Sigurdur Bjornsson]

Hi Kurt!

I'm afraid that's not the problem as I can see the devices in /proc/scsi/scsi and DP detects them in the end... It just takes 6 minutes...

[Scott McIntosh_2]

Looks exactly like another problem we have already in progress on SLES 9, another 2.6 kernel distro.

Log a support call and point out QXCR1000279713. The text all talks about SLES 9, even after they were told to verify this on SLES and RHEL.

So log a support call and remind them that this issue is on RHEL 4 as well. Looks like India just finished a fix candidate last week, so be more than happy to test it out on RHEL 4 for them. :-)

Thanks,
Scott
HP Support