Disable automatic enabling of multipathd

Fri Jan 25 15:08:17 UTC 2013

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
Jack.Allen at McKesson.com<mailto:Jack.Allen at McKesson.com>
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: kickstart-list-bounces at redhat.com [mailto:kickstart-list-bounces at redhat.com] 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: kickstart-list-bounces at redhat.com<mailto:kickstart-list-bounces at redhat.com> [kickstart-list-bounces at redhat.com] on behalf of Allen, Jack [Jack.Allen at mckesson.com]
Sent: Thursday, January 24, 2013 1:41 PM
To: kickstart-list at redhat.com<mailto:kickstart-list at redhat.com>
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
Jack.Allen at McKesson.com<mailto:Jack.Allen at McKesson.com>
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/kickstart-list/attachments/20130125/67368949/attachment.htm>