How to remove cluster lock disk information from VG

[Ken Englander]

I haved switched from using a lock disk to a quorum server. I am trying to use vgversion to update the VG to v2.1, but it tells me that is not allowed for a cluster lock disk. I have already changed the cluster to use a quorum server, but apparently I need to remove the info written on the PV that is associated with the lock disk mechanism.

Does anyone know if I can do that without recreating the VG?

Thanks!

[Michael Steele_2]

Hi

You have to find out if there's data first. What does

pvdisplay -v /dev/dsk/... | more

...say?

Any filesystems written to that disk?

[Michael Steele_2]

Hi again:

This is a local disk, right? Not a lun?

If local disk, and nothing else on disk, deactivate and rerun cmquerycl.

cmapplyconf -k -v -C /etc/cmcluster/clust1.config

-k option means only disks in config file will be checked.

[Ken Englander]

Hi Michael,

I guess I do not understand what you are suggesting. The question I need answered is if this can be done without affecting data on the VG. This is essentially an exercise right now as I am testing vgversion.

So, I can wipeout the VG to fix the problem, but I need to know if it can be done without affecting data on the disk.

I believe it is what you are calling a "local disk" although it is a SAN lun. But, it is a lock disk, NOT a lock lun.

Also, I am NOT having a problem changing to the quorum server - that is done. The problem is using the vgversion command to try to update the VG to LVM v2.1.

Thanks for your input!

[Michael Steele_2]

Data will not be affected.

[Emil Velez]

Might want to make sure you have the LVM patches for ServiceGuard to support LVMv2. There is some patches to use LVMV2 in a volume group in the cluster and other patch to let a LVMv2 disk be a cluster lock. IF you have the ServiceGuard patches that recognize LVMv2 and cluster lock structures might help.

[Stephen Doud · Accepted solution]

The LVM metadata calls out the fact that the disk is used for cluster lock function. Example, using the proprietary lvm11 utility.

# lvm11 -a -d /dev/rdsk/c4t0d0 | grep -i lock
/* Alternate block pool length. */ 10708
/* Alternate block pool start. */ 71121280
/* Cluster-lock flags. */ LVM_CLUSTER_LOCK_INITIALIZED
/* Cluster-lock area start. */ 71131988

I tested changing my clusters' arbitration device from this lock disk to a quorum server and cmapplyconf.

# cmapplyconf -f -C CLS.ASC
# cmviewconf | grep -i qs
qs host: qsnode
qs ip address 1: 16.113.15.39

# lvm.11 -a -d /dev/rdsk/c4t0d0 | grep -i lock
/* Alternate block pool length. */ 10708
/* Alternate block pool start. */ 71121280
/* Cluster-lock flags. */ LVM_CLUSTER_LOCK_INITIALIZED

It didn't remove the cluster lock flag from the metadata:

If the /etc/lvmconf/.conf file is reliable (and created before the VG was clustered or marked for use as the cluster lock VG), vgcfgrestore it.

[Ken Englander]

Stephen - thank you for the analysis - I also have a case open with HP where I will probably ask if this issue can be fixed.

Thanks!