vgchange -a n on volume group does not show volume group as inactive on inactive server.

[Jack C. Mahaffey]

I've got two servers using a shared disk array with one volume group. I am not using Service Guard.

One of the servers acts as the primary server and will mount the disk array while it is acting as a production server. Only the production server will execute the init 4 command to transition to run-level 4.

As the production server transitions to run-level 3, vgchange -a n is executed to deactivate the volume group. The volume group is not removed via vgexport. So the volume group exists on both servers.

My question is as follows:

Shouldn't the inactive server show a status something other than "available" for the volume group when vgdisplay is executed on the inactive server? vigdisplay works just fine and it appears that I could mount the volume group if I wanted.


I was expecting to see a "not available" message on the inactive server.

jack..

[Duncan Edmonstone · Accepted solution]

No this is correct, and it's like this precisely because you haven't got MCSG installed.

LVM doesn't work in a shared mode, it expects exclusive access to the disks it is controling - you could indeed attempt to mount the file systems, and you would probably end up corrupting all of them...

HTH

Duncan

[Steve Lewis]

Mmmm, its an unsupported configuration.

I think that both groups may have the VG activated, if it gives you the info in vgdisplay.

I think you are better off editing /etc/lvmrc to set AUTO_VG_ACTIVATE=0. Then you will not have to de-activate the volume group on the standby and run the risk of mounting the filesystem LVs on both servers at once.

If you use /etc/lvmrc, you will only manually activate the VG on the live server so you will have less risk.

[Jack C. Mahaffey]

Okay... So the only time I would get the "Volume Group not activated" messaage from vgdisplay would be if I had Service Guard installed?

jack..

[A. Clay Stephenson]

I agree that the safest approach to this is to edit /etc/lvmrc and set AUTO_VG_ACTIVATE=0 and then add the non-vg00 VG's in this file that you want activate. You would then do an explicit vgchange -a y on the VG that you want for your 'package'.

You should be aware that if filesystems are ever mounted on both boxes absolute chaos is assured.

[Steve Lewis]

Sorry, my language wasn't very clear last response.

DO NOT EVER activate a VG on two nodes at once without Serviceguard (or MC/lockmanager).

Serviceguard is used to control exclusive access to a VG, to avoid corruption.

If you use /etc/lvmrc to set AUTO_VG_ACTIVATE=0, you will have to manually sort out the volume group activation yourself, again this sort of thing isn't supported by HP, but some sites have managed to get it working.

[John Palmer]

Part of setting up a Serviceguard configuration involves amending /etc/lvmrc so that the shared volume groups are not activated when you reboot the server.

Even without serviceguard, you can change /etc/lvmrc to do what you want. You can subsequently activate volume groups whenever the need arises.

There's no problem having the same volume group activated on more than one server. It's only an issue if you attempt to mount the same filesystem more than once.

Serviceguard gives you an extra feature 'activate exclusive' which ensures that the volume group is only activated once.

Regards,
John

[Jack C. Mahaffey]

Thanks to all....

The discussion got me to start checking my other systems that are similar and I found inconsistencies in the /etc/lvmrc file for the volume group activation. Even found a typo in one of the files where value was set to 0.


I'm surprised one of the systems activated vg00 because /etc/lvmrc executed the following two statements.
/sbin/vgchange -a y -s
/sbin/vvgsync "vg00"

Note first entry does not specify vg00 and the second entry has a typo for vgsync.

I suppose it was okay because vg00 was never deactivated.

Jack...

[John Palmer]

The root volume group gets activated automatically at reboot. The only way you can prevent this is by booting into LVM maintenance mode.

Regards,
John