CentOS - Oct 2014 - Mounting LUNs from a SAN array - LUN mappings to devices in /dev/ - are they static?

Hi All :)

I am currently involved in a project in which there is a SAN array (Sun
Storagetek 2540) which exports LUNs for some servers with Centos 5.2 x86. I
will be performing a migration to Centos 5.9 x86_64 in some time and am
gathering needed info now :)

I am trying to find the place in the OS where there is the information
about LUN mappings to /dev/ devices.

For example on array level I have an exported LUN with number 8. I see it
on one of the servers with lsscsi as:

# lsscsi  | grep '7\:0\:0\:8'
[7:0:0:8]    disk    SUN      LCSM100_F        0735  /dev/sdj

As I said I need to perform migration of the OS to Centos 5.9 x86_64 and am
curious where from does the mapping

scsi device 7:0:0:8 <-> /dev/sdj

come?

I have some complex logical volume (Veritas Volume Manager) setup based on
/dev/ disks (which are derived from  LUNs imported from the array) and will
need to recreate it on destination servers. My coworker said that udev may
be assigning the /dev/sdj (and other) identifier so I checked this. In
/etc/udev/rules.d/* I see rules for scsi subsystem (sysfs type 0 is
"disk"):

ACTION=="add", SUBSYSTEM=="scsi",
WAIT_FOR_SYSFS="ioerr_cnt"
ACTION=="add", SUBSYSTEM=="scsi_device",
SYSFS{type}=="0",
RUN+="socket:/org/kernel/diskres/uevents"
ACTION=="remove", SUBSYSTEM=="scsi_device",
RUN+="socket:/org/kernel/diskres/uevents"

So I do not see anything which could answer my question. There have been
other rules for different sysfs types but I think they are not relevant in
my case.

In sysfs in /sys/bus/scsi/devices/7:0:0:8 I found:

# ll block\:sdj
lrwxrwxrwx 1 root root 0 Oct  4 17:57 block:sdj ->
../../../../../../../../../../block/sdj

Where else can I look for the LUN<->/dev/ device mapping rules? How are
the
LUNs mapped to operating system devices? Is there a way to add a static
mapping so that also on a new server after attaching SAN array LUN number 8
will be visible as /dev/sdj? I think that there is a possibility that on a
new server mentioned LUN will be visible as a different /dev/sd? :( That
could potentially break my logical volume setup on the destination server.

Any info will be greatly appreciated :)

BR,
Rafal.

Am 04.10.2014 um 18:22 schrieb Rafa? Radecki:

[ ... ]
> In sysfs in /sys/bus/scsi/devices/7:0:0:8 I found:
>
> # ll block\:sdj
> lrwxrwxrwx 1 root root 0 Oct  4 17:57 block:sdj ->
> ../../../../../../../../../../block/sdj
>
> Where else can I look for the LUN<->/dev/ device mapping rules? How
are the
> LUNs mapped to operating system devices? Is there a way to add a static
> mapping so that also on a new server after attaching SAN array LUN number 8
> will be visible as /dev/sdj? I think that there is a possibility that on a
> new server mentioned LUN will be visible as a different /dev/sd? :( That
> could potentially break my logical volume setup on the destination server.
>
> Any info will be greatly appreciated :)
>
> BR,
> Rafal.

Please see

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html

https://www.centos.org/docs/5/html/5.2/Virtualization/sect-Virtualization-Virtualized_block_devices-Configuring_persistent_storage_in_a_Red_Hat_Enterprise_Linux_5_environment.html

Alexander

On 10/04/2014 12:22 PM, Rafa? Radecki wrote:
> Hi All :)
>
> I am currently involved in a project in which there is a SAN array (Sun
> Storagetek 2540) which exports LUNs for some servers with Centos 5.2 x86. I
> will be performing a migration to Centos 5.9 x86_64 in some time and am
> gathering needed info now :)
>
You've gotten an answer related to the mappings, but you need to address 
the need to go to 5.9 which is known to be insecure. You have to be on 
5.11 in order to have security updates if you're going with CentOS, period.

Now, if you absolutely must run EL 5.9, then you really should 
investigate Scientific Linux, since you can install SL 5.9 and stay with 
it, only getting security updates. I suppose you could install C5.9 and 
point yum to the SL5.9 security updates repo, but that would be wildly 
unsupported.

Better would be educating whoever is insisting on 5.9 with the reality 
of knowingly installing an insecure OS.