vgextend: The volume group "/dev/vgdata06" is active in Shared Mode.

[Ignacio Luis Uzcategui]

My goal is extend two VGS in a CLUSTER ServiceGuard. Each node is HP-UX 11.11.

After I halted the package in one of the nodes, I tried to extend one of the VGS but I got the following error :

#vgextend vgdata06 /dev/dsk/c32t12d2
vgextend: The volume group "/dev/vgdata06" is active in Shared Mode.
Cannot perform configuration change.

I tried to activate the VG with the following command

#vgchange -a y /dev/vgdata06
vgchange: Activation mode requested for the volume group "/dev/vgdata06" conflicts with configured mode.

Could you give me any suggestion about the procedure to apply for successfully extend the VGS in both nodes.

Thanks in advance !!!

[Mel Burslan]

If this was a clustered volume group, you first may need to take it out of clustered mode

vgchange -c n vgXX

then extend it

vgextend vgXX /dev/dsk/cXtXdX

then

vgchange -c y vgXX

[Vivek_Pendse]

After vgchange -c n, you need to activate vg on one node of cluster with vgchange -a y.
Then you can extend the vg & create and import the vg-map file in to the other node.

Thanks,
Vivek

[Pramod M]

vgchange -c n vgdata06
vgchange -a y vgdata06
vgextend vgdata06 /dev/dsk/c32t12d2
vgchange -c y vgdata06

Do a vgscan on the 2nd node.
hope this will work

[Bob_Vance]

I don't believe that the cluster membership has to be changed.

This is similar to just extending a non-shared, clustered VG, with the wrinkle of being shared, which means that it can be active and in use on all nodes by your applications.

HOWEVER, any changes to the VG (vgextend, lvcreate, etc) MUST be done while the VG is active on *ONLY ONE* node and VG must be in EXCLUSIVE mode.

In your case, the VG is still active on the other node,
which is OK, because THAT is where you'll make the VG changes.


So, the trick is to get it into exclusive mode, which is where we usually are in SG without shared VGs.


The steps will be

1) stop package on all but one node

2) on remaining active node
node1 ## vgchange -a e -x vgXX
-x is required to force the VG from shared to exclusive

3) Do the vgextend

4) Change back to shared mode
node1 ## vgchange -a s -x vgXX


Now, you must re-import the newly configured VG
on the OTHER, inactive nodes.

5) on ACTIVE node, create map file for import
node1 ## vgexport -p -s -m /tmp/vgXX_mapfile vgXX

6) on each other node export/import the vgXX
node2 ## scp -p node1:/tmp/vgXX_mapfile /tmp # get map
node2 ## ll /dev/vgXX/group # find VG current minor number
crw-r--r-- ... 64 0xPP0000 ... /dev/vgXX/group
node2 ## vgexport vgXX
node2 ## mkdir /devgXX
node2 ## mknod /dev/vgXX/group c 64 0xPP0000 # minor
number from above
node2 ## vgimport -v -s -m /tmp/vgXX_mapfile vgXX

7) You should now be able to activate the VG
on this non-active node in shared mode
node2 ## vgchange -a s vgXX

If the VG activates correctly, then the package should work

8) de-activate VG
node2 ## vgchange -a n vgXX

9) start the package



bv

[Ismail Azad · Accepted solution]

Buenas Dias Ignatio Luis,

Well if you examine this thread you will end up coming to a conclusion that there are two ways to do this. Since we are speaking in terms of shared mode i.e the -s option, we could be typically under the umbrella of a higher volume manager like SLVM. The functionality missing in this thread is what is termed as SNOR which is part of the shipped operating system on 11.31 and requires patches on a 11.11 and a 11.23 operating system.


The first 3 posts go on to elongate the functionality of how your procedure is done on what is now termed as conventional *pre SNOR*.

However, SLVM SNOR which is amusingly expanded to Single node Online Volume reconfiguration comes Bob's post. SLVM SNOR fine tunes the high availability aspect of serviceguard and you can use Bob's procedure on a 11.31 O.S. However, I would like to creep in one command at around step 7. That --one-- node which was left active has to be converted back to shared using the command vgchange -a s -x /dev/vg06. The command on step 7 of Bob's post should be done on all other nodes except the one you kept active.

Since online has become a fancy and sometimes an extremely necessary word SNOR gives a slight finishing touch to what is termed as high availability on SG. Don't forget to assign points to forumers who help you out.

Regards!
Ismail Azad

[Bob_Vance]

@Ismail
Thanks for the elaboration!


> one command at around step 7. That --on

I had that at step 4.
Are you saying that it is not correct at step 4 ?


> The command on step 7 of Bob's post should be done on all other node

My step 6 says

"6) on each other node export/import the vgXX"

but I guess the step 7 statement was a little ambiguous,
athough it does show as being on "node2" ;>)



If the vgchange supports -s and -x on 11.11,
would that be sufficient to show that this system has been patched to support this procedure?



bv

[Ismail Azad]

Hey Bob,

> If the vgchange supports -s and -x on 11.11,
would that be sufficient to show that this system has been patched to support this procedure

Well one way would be to check whether the patches for SNOR are available that would be PHKL_33390 and PHCO_33310 or any of the succeeding patches and patch PHSS_33834. The former two being LVM patches and the latter being an SG patch.

Converting everything to shared on the same step just looked nicer... :) { speakin' bout the step 4 step 7 thing}

Regards
Ismail Azad

[Bob_Vance]

> on the same step just looked nicer..

Ohh... Nice catch.
I agree with that!


bv