Deactivating and removing a vg from a running package

[Ajithkumar]

Hi Gurus,

There is a vg with only raw lvs which is not used by any applications on a running package.

This vg is a shared one in a RAC package.

I want to deactivate this vg and eventualy remove this one from the package, WITHOUT HALTING THE RUNNING PACKAGE.


Can I do it thru the following steps on BOTH nodes.

1.vgchange -c n -S n vg02
2.vgchange -a n vg02
3.Remove the entry of vg02 from the package control file.

Expecting your inputs....

Ajith.

[BrianDoyle]

Hi Ajith,

You can't remove or edit a VG in a running package. Must halt it first.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=998807

Rgds,
Brian

[Ivan Krastev]

You cannot remove it without package stop. For full process see DocID UXSGKBRC00000184 : http://www5.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000080075778

regards,
ivan

[Stephen Doud]

Outside of Serviceguard or SGeRAC, if there are no open files on any volume in the VG, it may be deactivated.
If the SGeRAC package is no longer referencing the VG or volumes, then it too may be deactivated.
Once done, it is safe to update the package control script to eliminate the VG reference, but be certain to resequence the VG index number of any following VGs.
Example:
Before:
VG[0]=vg01
VG[1]=vg02
VG[2]=vg03

After
VG[0]=vg01
VG[1]=vg03

If the VG will not longer be used in the cluster, update the cluster configuration file by deleting the OPS_VOLUME_GROUP reference for that VG.

[Ajithkumar]

Hi All,

Thanx for your feedback....

Stephen : - I have one more clarification to you.
By running vgchange -c n vg_name , will remove the vg entry from the cluster config file. So after that is it required to delete the OPS_VOLUME GROUP entry seperately...?

I wrote an action plan for the job ( Actually I want to reduce the size of the vg also.) Can you have a glance and give me the feedback...?

Removing and deactivating the VG

1.Make sure that this vg is not used by any of the applications.
2. DBNODE1# vgchange -c n -S n vgbh_b - removing the vg from the cluster.
3. DBNODE1# vgchange -a n vgbh_b - deactivating the vg from the first node
4. DBNODE2# vgchange -a n vgbh_b - deactivating the vg from the second node
5. Remove the entry of vgbh_b from both the package control files.

Reducing the size of VG.(This vg is of 200gb comprsing of 4 * 50 gb LUNs)

6. DBNODE1 Remove all the LVs from vgbh_b
7. DBNODE1# vgreduce vgbh_b c$t$d$ c#t#d# and create the new lvs as required.
8. DBNODE1# vgexport -v -p -s -m /tmp/vgbh_b.map vgbh_b
9. DBNODE1# rcp/vgbh_b.bap to DBNODE2
10.DBNODE2# vgimport -v -s -m vgbh_b.map vgbh_b

Creating new package with vgbh_b (The new package is not RAC. vgbh_b need not be shared)

11.DBNODE1#vgchange -c y vgbh_b
12.DBNODE1# cmmakepkg -v -p newpkg.conf
13.DBNODE1# cmmakepkg -v -s newpkg.cntl
14.edit.check and compile the newpkg.conf file
15.edit and copy the newpkg.cntl to other node
16.start the package


Thanx in advance...
Ajith.

[Stephen Doud]

'vgchange -c n vg_name' does NOT remove the volume group from the cluster configuration file. It simply removed the cluster identification from the volume group LVM metadata.

Remove the OPS_VOLUME_GROUP entry from the cluster configuration file prevent the disk LVM metadata from being loaded with the cluster ID on future cmapplyconf operations.

Your procedure looks good.

If the VG is to be converted to an 'exclusive' activated VG, add an entry in the cluster configuration file:
VOLUME_GROUP /dev/vgbh_b

[Emil Velez]

yes but if the package shuts down it will try to deactivate the VG. You also need to remove it from the run/halt script on all nodes.

[Ajithkumar]

Thank you sirs....for your valuable feedback.

In fact I had mentioned to remove the vg entry from the package control file in the 5th step.

Thanx again,..

Ajith