vgchange

[Seymur]

hi all.

I have created volume group and distributed to other node. Should I do activate volume group on both node?

thanks.

[Ludovic Derlyn]

Hi,

Vg will be activated by package , not manually

Regards

[Seymur]

how can I test the working package. for example xclock. I've created vg01 from EVA for one node and distributed to another node. but xclock program works from local node...

[Fabio Ettore]

Hi,

in SG the volume group will be activated only on a node. If you want just for testing purposes you can active the shared volume group on the first node before and then deactivate it from that node and activate the same VG on the second node. It just for testing purposes to check if there are problems.

Just a thought...

Best regards,
Fabio

[Stephen Doud]

If you list a VG in the package control script, starting the package will activate the VG on the node, regardless of whether you list any logical volumes or file systems.
Thus, after the package is started, you should be able to do a 'vgdisplay ' to determine whether it was activated after the package was started.
You will also note from its status that the VG is active in "exclusive" mode - an indication that it identifies with the SG cluster.
Halt the xclock package and start it on the other server and you should see the VG deactivate on the first node and activate on the next node.

[Sundar_7]

Seymur,

If the VG is part of the cluster, the package that uses the VG should be configured to activate/deactivate the volume group.

Having said that, it is perfectly fine to manually activate the VG from the command.

But remember, the HP-UX LVM has no means of communicating the VG activation status across the nodes. So the VG should be activated RW only in one node. You can activate the VG in Read-only mode in the other node.

In node 1

# vgchange -a e /dev/vgname

In node 2

# vgchange -a r /dev/vgname
# vgcfgbackup /dev/vgname

(vgcfgbackup wont exist in the adoptive nodes).

Now remember to deactive the VG before starting the package, or else the package startup will fail.

Sundar

[Stephen Doud]

lvmkd detects a) the cluster ID and b) the exclusive activation flag in the VGDA of the LVM structures on disk.
When lvmkd detects that a VG is marked to activate in exclusive mode, it cannot be activated on more than one node at any given time. Hence vgchange -a r on a second node will not succeed.

Incidentally, HP-UX does not have the ability to communicate inode changes performed on one server to another server. So if a 2nd server activates a VG and mounts a file system mounted in read-only mode that is already mounted on the 1st server, file system structures in-core on the 2nd node can quickly become unsync'd from what is being done to the file system from the 1st node. This can cause a file-system inconsistency panic on the 2nd node.

[Sundar_7]

lvmkd will not allow read-only activation in the second node ?? that is news to me, unless I am missing something here. I have done this zillion times before to create the vgcfgbackup of the cluster volume group, even with the SG version 11.14. I dont know if this is any different in 11.16.

[rariasn]

Hi Seymur,

# cmhaltpkg -pkg_name

In main node (nodea),

# vgchange -a e vgsample
# mount /dev/vgsample/lvsample /sample
# bdf /sample

# vgexport -p -m /tmp/vgsample.map vgsameple
# scp (or rcp) /tmp/vgsample.map nodeb;/tmp
# vgchange -a n vgsample

In adoptive node (nodeb),

# vgexport -m /tmp/vgsample.map.old
# mkdir /dev/vgsample
# mknod /dev/vgsample/group c 64 0xnnnnnn
# vgimport -m /tmp/vgsample.map vgsample pv_paths
# vgchange -c y vgsample
# vgchange -a e vgsample
# mount /dev/vgsample/lvsample /sample


rgs,

ran

[Stephen Doud]

Sundar,
You are correct. A VG can be activated in read-only mode even if it is activated in exclusive mode elsewhere.
I stand by my message that inode changes are not communicated from the read/write node to the read-only node, so it's not advisable to mount the file system on the read-only node.

[Seymur]

thanks all.

I've solved this problem with 'vgchange -a e'.

regards,
seymour.

[Stephen Doud]

Hi Seymur,
Although you found that you were able to activate the clustered VG using 'vgchange -a e', that manual operation will normally be done in a package control script.
Since a VG is only part of the requirements of a critical application, the package control script is used to coordinate and automate making the necessary system resources available to the application, under Serviceguard control.
Therefore, it seems like the next thing you need to do is make a package control script and add that VG to the script.