1829440 Members
1633 Online
109992 Solutions
New Discussion

Re: EVA Lun problem

 
SOLVED
Go to solution
Marco_113
Frequent Advisor

EVA Lun problem

Hi all,
i've a problem with a Redhat AS 3.2
I configured two luns on an EVA3000.
My problem is that if the server reboot, sometimes it change the special files associated to LUN.
The /dev/sda become /dev/sdb and this is a huge problem.

Any suggestion please?
Thanks
6 REPLIES 6
Court Campbell
Honored Contributor

Re: EVA Lun problem

what kind of fiber card do you have?
"The difference between me and you? I will read the man page." and "Respect the hat." and "You could just do a search on ITRC, you don't need to start a thread on a topic that's been answered 100 times already." Oh, and "What. no points???"
Ivan Ferreira
Honored Contributor

Re: EVA Lun problem

The devlabel software attempts to address the device naming issue in a different manner than file system labels. The devlabel software is run by Red Hat Enterprise Linux whenever the system reboots (and whenever hotpluggable devices are inserted or removed).

When devlabel runs, it reads its configuration file (/etc/sysconfig/devlabel) to obtain the list of devices for which it is responsible. For each device on the list, there is a symbolic link (chosen by the system administrator) and the device's UUID (Universal Unique IDentifier).

The devlabel command makes sure the symbolic link always refers to the originally-specified device â even if that device's name has changed. In this way, a system administrator can configure a system to refer to /dev/projdisk instead of /dev/sda12, for example.

Because the UUID is obtained directly from the device, devlabel must only search the system for the matching UUID and update the symbolic link appropriately.

# devlabel add -s /dev/my_stable_disk_name -d /dev/sda
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
CelesteG
Advisor
Solution

Re: EVA Lun problem

Marco, here is a snippet from the SecurePath manual for Linux that addresses your issue...

""The Linux operating system does not provide built-in LUN persistence. Lack of
LUN persistence means that if you add or delete physical LUNs or disks and
reboot your system, there is a probability that the device mnemonics will change
in an undesirable way.""

The SecurePath software can be installed on your system to address device persistance with the sps program, however if you don't have SP installed, there are ways of identifying your LUNS when adding and removing EVA devices from your linux system. Is that what you are looking for, a means of identification?
Marco_113
Frequent Advisor

Re: EVA Lun problem

Thanks for reply.
Yes Celeste, is exactly what i need.
I think i have to edit /etc/CPQswsp/sppf file?
Thanks
Marco_113
Frequent Advisor

Re: EVA Lun problem

Editing the sppc Secure Path file it works great.
Thanks.
Now I' ve another problem.
When system boots, it don't see the lun until i do hp_rescan -a command.

Sometimes i solved this problem:
1)put in /etc/modules.conf options scsi_mod max_luns=127

2)rebuilding image with mkinitrd -v

But this time it still doesn't work...
Any suggestion??
Thanks
CelesteG
Advisor

Re: EVA Lun problem

Marco,
I didn't make any changes to my modules.conf file.

Question: Does your secure path not work. if you have SP installed then you can do a 'spmgr display' and that will show you all the luns that you have presented to the server from the EVA.

The sppf file is the persistence file for the sps program. I use it on other systems for mappings but I don't trust it as much because I have seen duplicate LUN entries in that file that I think have caused us problems in the past. I'm glad it worked for you.

To address your last inquiry - and then some:
(NOTE: This is LUN EVA mgmt with NO SecurePath involved. Just the Linux OS and the fibre utilities.)
When a LUN is added, you have to do a pvcreate on that LUN before it will be acknowledged by the system as a physical device to be utilized. SP does this but remember we are not utilizing SP on this system).
So, to identify which LUN to perform the pvcreate on do a df to get the logical volume info.
Then do a pvscan to tie that logical volume to a physical device on your system. We use spvXX for all our EVA LUN assignments (/dev/spv01, /dev/spv02, etc..)

df -->gives me--> /dev/spv01/lvol1
pvscan -->gives me--> pvscan -- ACTIVE PV "/dev/sdh" of VG "spv01"

So I see that /dev/spv01 is created on the sdh device. Do this for all your logical volumes and you'll have the correct mappings for your currently utilized physical devices. Now execute
/opt/hp/hp_fibreutils/hp_rescan to resan your LUNS (if you have just performed a reboot you shouldn't have to do this.)
and
/opt/hp/hp_fibreutils/lssd

The devices you see listed from the lssd command that were not in the list when you verified your current physical devices are the devices that you need to perform a pvcreate on. Once you do a pvcreate on the device you can do a pvscan and you will see the newly added device and their sizes.

You can now perform LVM configurations on these devices they will not disappear or move unless they are removed from the system for additional LUN configuration.