Ensuring SAN LUN persistent names after reboot...

Arpotu arpotu at apathynews.com
Thu Nov 1 22:28:56 UTC 2007


Thanks!  I have another question now.  Using the example from the KB article:

KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id",
RESULT="3600a0b800013275100000015427b625e", NAME="mydevice%n"

Could I (for example) assign the UUID to /dev/sdb (if /dev/sdb did not
already exist)?  Like this:

KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id",
RESULT="3600a0b800013275100000015427b625e", NAME="sdb"

I assume yes, since the NAME could be any arbitrary string, but there
could be a looping issue, etc.. just want to be sure before I crater this
server ;)

Oh - one other thing.  If /dev/sda is already defined on the system, and I
comment out "options=-b", do I lose /dev/sda on next reboot, will I
manually need to redefine it, or will nothing happen to /dev/sda?

Thanks,
Arpotu.

>
> On Nov 1, 2007, at 2:22 PM, Arpotu wrote:
>
>> Hello,
>>
>> I have yet another SAN migration question.  We're going to add many
>> new
>> SAN LUNs, which will end up being /dev/sdp-/dev/sdas.  Once the new
>> storage is built as md devices and added to LVM, we are going to
>> release
>> the old /dev/sdb-/dev/sdo devices.
>>
>> My concern is that after a reboot, the new devices will rename
>> themselves
>> to /dev/sdb-/dev/sdae and it will break the md device pairing (and
>> LVM).
>> Is there any way to ensure that LUN names are persistent after a
>> reboot?
>
> http://kbase.redhat.com/faq/FAQ_85_8082.shtm
>
> ... use UUIDs to refer to the disks, instead of the /dev/sdX devices.
>
> (As an aside, maybe I'm stupid, but I find that SAN storage is so much
> more complicated and fragile on Linux then on Solaris or AIX.)
>
> 	-s-
>
> --
> Sandor W. Sklar, Unix Systems Administrator
> Stanford University Libraries & Academic Information Resources (SULAIR)
> http://library.stanford.edu
>
>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>




More information about the redhat-list mailing list