|
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. 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. 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. 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. 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. I hope this helps, I certainly know the feeling when a system blows away all of the cluster data when this happens :) Corey From: kickstart-list-bounces@xxxxxxxxxx [kickstart-list-bounces@xxxxxxxxxx] on behalf of Allen, Jack [Jack.Allen@xxxxxxxxxxxx]
Sent: Thursday, January 24, 2013 1:41 PM To: kickstart-list@xxxxxxxxxx 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@xxxxxxxxxxxx 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 Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
