Corey:
Thanks for the reply and information. See comments below.
-------------------------
Jackson C. Allen
McKesson Provider Technologies
5995 Windward Parkway
Alpharetta, GA 30005
(404) 338-2023
[email protected]<mailto:[email protected]>
Confidentiality Notice: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
From: [email protected]
[mailto:[email protected]] On Behalf Of Kovacs, Corey J.
Sent: Friday, January 25, 2013 9:09 AM
To: Discussion list about Kickstart
Subject: RE: Disable automatic enabling of multipathd
Jackson,
This isn't a problem with multipathd, rather that the SAN volumes are visible
during the kickstart I'd say. I was bitten by this long ago... once... and it
sucked :) Now I am very careful to say the least.
[JCA] I agree the problem itself is not multipath, but that anaconda found SAN
devices accessible and decided to enable multipath and then run pvcreate on the
LUNs it mapped to /dev/mapper/mpath*. This is the part that I feel is somewhat
of a bug.
You have a couple of options right off the bat.
1. I think the "nostorage" flag still works, put that on the kernel line and
then in the kickstart specify which device drivers you need loaded in the
kickstart. On a newer HP box running rhel6 I add the "hpsa" driver via a
"device" flag. On an older rhel5 install, it's still "cciss" for the smart
array. This has worked for me.
[JCA] This could be a problem because the same KickStart is used on several
vendors' hardware, Dell, HP, IBM and ESX/VMs. The vendors tend to change the
local storage HBA from time to time. But this is something we can investigate.
2. In the %pre section, you can remove/unload the fibre channel card drivers,
then those volumes will not get scanned since they will not be seen.
[JCA] Again this could be problematic in making sure we remove all possible FC
HBAs the vendors may have installed. We try to standardize on specific local
and FC HBAs, but the vendors sometime install newer models that could have a
different name.
Your description doesn't indicate (to me anyway) if you are booting from the
san devices so I am assuming you are booting from local storage, and then
accessing the san after the fact.
[JCA] I did state the system has local storage and the OS is/was loaded on it.
You also didn't include the partition layout so I am suspecting that you might
be using autopart. If that is the case, and your primary storage is local, then
one of the two options above should work. If you aren't using autopart, then
you might think about being a bit more specific in the partition information
when designing the setup.
[JCA] We are only partitioning the local storage via the KickStart and had
assumed nothing would be done to any other storage found. Our instructions
state the SAN should not be connected when kick starting the system, but our
customer did not follow the instructions. So I am looking for a way to keep our
customers from shooting themselves in the foot so to speak when they don't
follow the instructions.
I hope this helps, I certainly know the feeling when a system blows away all of
the cluster data when this happens :)
[JCA] Yes, this gives me some things to think about. Maybe some others will
suggest some other options as well.
Corey
Corey Kovacs
Sr. System Architect
Technology Management Associates<http://www.techma.com>
RHCA:
110-541-489<https://www.redhat.com/wapps/training/certification/verify.html;jsessionid=o9SSOewROoS4SL45ag0TaQ**.87c55fb5?certNumber=110-541-489&verify=Verify>
________________________________
From:
[email protected]<mailto:[email protected]>
[[email protected]] on behalf of Allen, Jack
[[email protected]]
Sent: Thursday, January 24, 2013 1:41 PM
To: [email protected]<mailto:[email protected]>
Subject: Disable automatic enabling of multipathd
First some history; we have a customer that will be implementing
Clustering between 2 physical system that will share some storage on a SAN. One
system was already running RHEL 5.8 32-bit and they are upgrading to RHEL 6.3
64-bit over all. So on the second system a RHEL 6.3 64-bit KickStart provided
by us was installed. Our instructions stated to disconnect the system from the
SAN before doing the KickStart, but they did not. The system has local storage
for the OS and the OS was installed on it as it should have been. But because
the SAN was connected and the LUNs zoned to the system, the KickStart
identified the multiple paths to the LUNs and enabled multipathd, ran pvcreate
on the /dev/mapper/mpath* names which over wrote the existing header/labels on
each LUN and put new uuid on each and cleared the LVM label information. On the
system running RHEL 5.8 the VG and the LV could still be access but all command
such as lvs, pvs and vgs would not show information because of the missing LVM
labels.
We had to reboot the active system and then run pvcreate with the -uuid
option to put the correct uuid back in place on each LUN, there were 16 of
them. And then run vgcfgrestore on the VG and everything is fine now.
Once the RHEL 6.3 64-bit system is working properly the RHEL 5.8 32-bit
system will be brought down and the SAN storage will be accessed from the RHEL
6.3 64-bit system. Then the RHEL 6.3 64-bit KickStart will be run on the old
RHEL 5.8 32-bit system to upgrade it, which means both systems will be running
RHEL 6.3 64-bit and the Cluster software will be activated.
So what option or whatever can be specified in the KickStart to not
automatically scan for SAN storage and enable multipathd and run pvcreate?
-------------------------
Jackson C. Allen
McKesson Provider Technologies
5995 Windward Parkway
Alpharetta, GA 30005
(404) 338-2023
[email protected]<mailto:[email protected]>
Confidentiality Notice: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
_______________________________________________
Kickstart-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/kickstart-list
