Obsolete /dev/lvmconf/vgxx.conf on cluster standby node

[Mihails Nikitins]

Hi,

I transferred vg information from active MC/SG node to a standby one according to KB Document id: VIKBRC00009369.

On active:
vgexport -v -p -s -m /tmp/vgxx.map /dev/vgxx

On standby:
vgexport -v /dev/vgxx

mkdir /dev/vgxx
mknod /dev/vgxx/group c 64 0x010000
vgimport -v -s -m /tmp/vgxx.map /dev/vgxx


Problem: /etc/lvmtab now is up to date, but /etc/lvmconf/vgxx.conf is old.

I can't run vgcfgbackup (probably, becuase disks are in use by another node)

vgcfgbackup: Warning: couldn't query physical volume "/dev/dsk/c1t1d0":
The specified path does not correspond to physical volume attached to
this volume group

Question: Is it OK to stay with old vgxx.conf until the next switchover?

Many thanks and points for any ideas!

[G. Vrijhoeven · Accepted solution]

Hi,

You should be able to activate the volume group readonly:

# vgchange -a r vgXXXX
# vgcfgbackup vgXXXX
# vgchange -a n vgXXXX

HTH,

Gideon

[melvyn burnard]

yes you can, and in fact many customers do actually never do a vgcfgbackup of shared vg's once a cluster is created, sometimes they find out the hard way ;-/

My advuice is always once the cluster is up and tested, make sure you activate all shared vgs across each node, and do the vgcfgbackup, ESPECIALLY the cluster lock vg after the cluster lock is written

[Mihails Nikitins]

Many thanks to G. Vrijhoeven, the problem is solved. Now /etc/lvmconf/vgxx.conf is up to date. I didn't expect "vgchange -a r" to work when the volume group is activate in exclusive mode on the primary node. "man vgchange" is a bit foggy for "-a r".

Thank you, Melvyn. I'm afraid neither MC/Service Guard nor KB documents don't describe vgcfgbackup procedures for my case. :-(

Thank you once more!

BR,
Mihails