StoreEver Tape Storage
cancel
Showing results for 
Search instead for 
Did you mean: 

RedHat ES 3.0 + MSL5026 : device files not persistent

SOLVED
Go to solution
Bob_Vance
Esteemed Contributor

RedHat ES 3.0 + MSL5026 : device files not persistent

Added a MSL5026 into zones for 2 Linux servers.

When the Linux servers reboot, they do not see the tape drives. We have to do an "hp_rescan" in order for the device nodes to be recreated for the two tape drives in the library. Once rescanned, Data Protector can find /dev/nst0 and /dev/nst1 and I can back up and restore from them as expected.

This is not an issue for the EVA array LUNs that we have presented to these servers.

Any ideas on how we can maintain the device persistence?
Do I have to do something in SANsurfer?

tks
bv


"The lyf so short, the craft so long to lerne." - Chaucer
6 REPLIES
Kurt Beyers.
Honored Contributor
Solution

Re: RedHat ES 3.0 + MSL5026 : device files not persistent

Bob,

I had the same issue at several customers and ended up by adding a script that performs a 'hp_rescan' command during the startup of the server.

An easy work-around that works.

Kurt
Bob_Vance
Esteemed Contributor

Re: RedHat ES 3.0 + MSL5026 : device files not persistent

Thanks, Kurt.
I was hoping to avoid that, but it's good to know that someone has done that and has no issues.

I'm a little worried about using hp_rescan, because it goes out and deletes all LUNs, rescans, and then re-adds.
viz.,
I'm wondering what happens to the device names if, for example disk LUNs 1,2,3 are presented and then, for whatever reason, we decide that LUN2 is not needed anymore. On HPUX, we would just have a NO_HW for LUN2 in ioscan.

In Linux, we, of course, can't afford to have /dev/sdc disappear have /dev/sdb suddenly be LUN3 instead of LUN2. I just haven't had time to play around with it enough, yet.

bv



"The lyf so short, the craft so long to lerne." - Chaucer
Kurt Beyers.
Honored Contributor

Re: RedHat ES 3.0 + MSL5026 : device files not persistent

Bob,

Just add the following lines to /etc/rc.d/rc.local:

#detect HP Ultrium drives
/opt/hp/hp_fibreutils/hp_rescan -a

The rescan is than done after the normal startup scripts. I've done the hp_rescan already many times on servers with databases running on the SAN. No issues with the databases occured due to the hp_rescan.

best regards,
Kurt
Bob_Vance
Esteemed Contributor

Re: RedHat ES 3.0 + MSL5026 : device files not persistent

Thanks
will try it (in 3 hours;>) and let you know.

bv
"The lyf so short, the craft so long to lerne." - Chaucer
Bob_Vance
Esteemed Contributor

Re: RedHat ES 3.0 + MSL5026 : device files not persistent

OK.
Tested it out and a hp_rescan does cause the device names to change, as I suspected.

So:
LUNs 1,2,3 presented and
devices /dev/sda-> L1, /dev/sdb->L2, /dev/sdc->L3

unpresent LUN2
hp_rescan
and now devices are /dev/sda-> L1, /dev/sdb->L3

which is not good.


HOWEVER,
a reboot (without a hp_rescan at boot time) causes the same problem, which I also suspected.
So, the issue is no longer 'hp_rescan'.

The issue is simple LUN persistence across Linux reboot.


So, to solve the tape device problem, I added the hp_rescan to local as you suggested.

Now, I'm going to look for a resolution to the general Linux LUN persistence problem.


bv
"The lyf so short, the craft so long to lerne." - Chaucer
Bob_Vance
Esteemed Contributor

Re: RedHat ES 3.0 + MSL5026 : device files not persistent

I had left out a little info:

1) the HBA was a FCA2214DC (QLA2342) in a Proliant and the driver was Qlogic :
Firmware version: 3.03.11, Driver version 7.05.00-fo

2) The CHANGER *was* being seen after a reboot (as /dev/sg3) -- just the drives were not being seen.


I found 3 more things to try make the tape drives be seen without doing an hp_rescan and I tried 2 of them to no avail:


-----------
1) another thread in the forums
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=800564

suggested adding

options scsi_mod max_scsi_luns=255

to /etc/modules.conf.

A new initrd also had to be made:

# cd /boot
# cp initrd-2.4.21-32.ELsmp.img \
initrd-2.4.21-32.ELsmp.img.BAK20050811
# mkinitrd -f -v /boot/initrd-2.4.21-32.ELsmp.img 2.4.21-32.ELsmp

After the reboot, it DID see the tape devices,
BUT, now, the EVA Array LUNs were not seen !


-----------
2) This issue is apparently a known problem and I found a document somewhere explaining this exact problem and pointing to this patch at HP web site:

PATCH for HP Tape Library Devices with HBA's using the 7.01.01 driver:

http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?locale=en_US〈=English+%28US%29&pnameOID=315892&prodSeriesId=315890&prodTypeId=12169&basePartNum=COL9842&locBasepartNum=co-28051-1&os=Red+Hat+Enterprise+Linux+3+%28x86%29&tech=Driver++Storage+Controllers+-+FC+HBA

Even though it mentions drive 7.01, (not 7.05 which I am using), it is a simple source patch to a table, so I manually added the patch in.

This time after a reboot, it saw NEITHER the tape devices NOR the EVA LUNs (it did see the changer, however), so I had to back this patch out.

I'm not sure whether it was the patch or some other artifact of rebuilding the driver and initrd, because rebuilding without the patch still had a problem and I had to go back to my original saved initrd.


-------------
3) another thread

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=707820

suggested rebuilding the kernel with
CONFIG_SCSI_MULTI_LUN = yes
but I ran out of time.



I have not had time to look at LUN persistence yet.

bv

"The lyf so short, the craft so long to lerne." - Chaucer