HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
cancel
Showing results for 
Search instead for 
Did you mean: 

vgscan at system boot

 
SOLVED
Go to solution
Ulf Sandberg
Occasional Advisor

vgscan at system boot

I am installing ServiceGuard on RedHat 2.4.21-20. I have problem with "Prevent Boot-Time vgscan". I have followd the instruction on page 40 in Version A.11.16 Release Notes, Second Edition. It dosen't work, some idea?
11 REPLIES
Steven E. Protter
Exalted Contributor

Re: vgscan at system boot

Are you trying to prevent volume group activation. LVM on HP-UX requires you change auto activation from 1(do it) to 0(don't). The file is /etc/lvmrc

This may be the same on Linux.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Ulf Sandberg
Occasional Advisor

Re: vgscan at system boot

There is no /etc/lvmrc in RedHat, i have done the chnges in /etc/rc.d/rc.sysinit
Serviceguard for Linux
Honored Contributor

Re: vgscan at system boot

Please put in a call to support.

I also have asked someone in the lab but it may take a day (or so) to get an answer back here.
Slawomir Gora
Honored Contributor

Re: vgscan at system boot

Hi,
did you comment both LVM initialization sections in /etc/rc.d/rc.sysinit file ?
Ulf Sandberg
Occasional Advisor

Re: vgscan at system boot

Yes I have now a call at support.
I have done the change on the two places.
I am now running an up2tape, perhaps it will help.
Ulf Sandberg
Occasional Advisor

Re: vgscan at system boot

Here is the solution from HP:
> So the customer has 2 choices:
> - change the "vgchange -ay" command to "vgchange -ay Volume00" in
> initrd-2.4.21-37.ELsmp.img/linuxrc every time a new initrd is created
> - reinstall the system without using LVM for the root filesystem
>
> The script /sbin/mkinitrd, which creates the linuxrc file, could be changed
> to have the required result:
>
> - make a copy of /sbin/mkinitrd
> # mv /sbin/mkinitrd /sbin/mkinitrd.orig
> # cp /sbin/mkinitrd.orig /sbin/mkinitrd
>
> - edit the script /sbin/mkinitrd
> # vi /sbin/mkinitrd
> Change the line:
> echo "vgchange -ay" >> $RCFILE
> To:
> echo "vgchange -ay Volume00" >> $RCFILE
>
> - create a new initrd file with the mkinitrd command or the
> /opt/hp/src/hp_qla2x00src/set_parm command.
>
> - reboot the system
Ulf Sandberg
Occasional Advisor

Re: vgscan at system boot

It is solved by HP support.
I have also made a workaround, that runs
"vgchange -a n my_vg" in rc3.d before the cluster starts.
Matti_Kurkela
Honored Contributor
Solution

Re: vgscan at system boot

Your workaround is not appropriate.

On Linux LVM, the vgchange command will write the new status to disk(s) of the volume group in question.

If your cluster is down, you can get away with your workaround.

But consider a situation when the cluster is active and node A fails. The node B takes over the disks and starts running the application.
You shutdown the node A and do some hardware maintenance. After that, you start it up again.

Now, the disks and the application are active on the node B, so node A *MUST NOT TOUCH* the disks *AT ALL* until node B stops using them.

If you use your workaround, node A will make a mark to the LVM data area of the disk, stating that the volume group is not active... without the knowledge that node B is actually using the disks and the volume group at the time!

With luck, your node B might not notice this immediately... but when it is time to do a LVM operation on node B (say, deactivate the volume group when preparing to move the package back to node A) it will get very confused.
MK
Serviceguard for Linux
Honored Contributor

Re: vgscan at system boot

Matti,
Did you try this?

One of our engineers did on RedHat 4 (LVM2) and did not see that the deactivate on one node had any affect on the activated volume on the other. We've never seen any problems on RedHat 3. Also, you can deactivate a volume multiple times with no affect.

If you did try this, maybe there is something that we've missed and we may appreceate more details.

Thanks
Ulf Sandberg
Occasional Advisor

Re: vgscan at system boot

Thank you for the information, I see that my workaround is not useable.
I will implement the HP Support solution:

change the "vgchange -ay" command to "vgchange -ay Volume00" in
initrd-2.4.21-37.ELsmp.img/linuxrc every time a new initrd is created
Matti_Kurkela
Honored Contributor

Re: vgscan at system boot

Sorry, my experience was from older Linux installation. I checked back and found that it was using LVM1.

This seems to have changed in LVM2; if so, that is a good change.

Nevertheless, I would feel uneasy about blindly activating and deactivating cluster VGs while ServiceGuard is not yet running: after all, VG activation is the primary "lock" that prevents the node from writing to the cluster disks.

If this lock is defeated during boot, it may be harmless by itself; but it allows an opportunity for further damage.

For example, at least here I've seen cluster (originally stand-alone application servers, converted to two-node clusters when more availability was needed) in which the cluster volumes were still listed in /etc/fstab. A small mistake, which usually causes some error messages at boot time, nothing more.

If the VG gets activated at boot, this will easily lead to the booting node running a fsck on the cluster disks... while yet unaware that the other node is actively using that disk. This WILL lead to corruption and data loss.
MK