Ensuring SAN LUN persistent names after reboot...
Sandor W. Sklar
ssklar at stanford.edu
Thu Nov 1 23:42:50 UTC 2007
On Nov 1, 2007, at 3:28 PM, Arpotu wrote:
> 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 ;)
Hrm. I'd assume that yes, you probably could do that, but you might
be entering a world of pain there.
I'm not sure I'm the best person to offer practical advice on this; as
I said earlier, I find the various interactions of HBA drivers, udev
configuration, dm-multipath configuration, and then LVM implementation
to be horribly, overly complicated and under-documented.
I have eight systems, each with two QLogic HBAs, connected to a SAN
fabric of two QLogic switches, with storage from four Nexsan SATABeast
arrays; about 60 TB of usable storage. I've just recently discovered
some apparently minor choices made when this was all set up is now
causing enumerable headaches, data loss, and unplanned outages.
Personally, I would suggest that you come up with your own naming
scheme for SAN LUNs, and use that scheme consistently (for example,
maybe /dev/sanlun1, /dev/sanlun2, and so on.)
>
>
> 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?
Sorry, I can't answer that ... maybe someone else can.
-s-
--
Sandor W. Sklar, Unix Systems Administrator
Stanford University Libraries & Academic Information Resources (SULAIR)
http://library.stanford.edu
More information about the redhat-list
mailing list