Remove Cluster Lock Flags from PV

[davesec]

I would like to remove the Cluster Lock Flag from a PV in a active vg without loosing the data on it and without data backup, new creation of vg, data restore.
How could this be possible?

History:
I created a cluster and defined a
FIRST_CLUSTER_LOCK_VG /dev/vg01
FIRST_CLUSTER_LOCK_PV /dev/disk/disk71

The vg01 is a cluster vg with data on it.

Then I changed the quorum from CLUSTER_LOCK_VG to a quorum server but the Locking information still exists on the disk:
# lvm.11 -a -d /dev/rdisk/disk71 | grep -i lock
/* Alternate block pool length. */ 56
/* Alternate block pool start. */ 125829052
/* Cluster-lock flags. */ LVM_CLUSTER_LOCK_INITIALIZED
/* Cluster-lock area start. */ 125829108
/* Alternate block pool length. */ 56
/* Alternate block pool start. */ 125829052
/* Cluster-lock flags. */ LVM_CLUSTER_LOCK_INITIALIZED
/* Cluster-lock area start. */ 125829108
CLUSTER LOCK fields
lock_state LVM_DISK_CL_LOCK_FREE

Now I'd like to do a vgmodify -a -E vg01 but this does not work because vgmodify thinks the disk71 is still a cluster lock lun. That leads to the question:
How can I remove this LVM_CLUSTER_LOCK_INITIALIZED flag and the Cluster-lock area from the disk71?

Can please someone provide me this lvm hack!?

Thank you

[Bob_Vance]

This does not help your situation, but

I always create a small, separate VG with no data on it for the lock VG/disks. In fact, it is kept deactivated.

Yours is a good case (which I have never run into) for my setup.


Anyway, I assume that you removed the LOCK disk config in SG.


This would appear to be a bug (or, if "bug" is too harsh, then "an area that requires further scrutiny", or "a needed enhancement" :>), in either vgmodify (why should it care) or SG (perhaps it should clear that info when a disk is removed from the LOCK configuration), and which other people have run into.

I'm surprised HP has not fixed this.


bv

[davesec]

Thank you for your reply. All your answers are definitly true.

BUT:
I'm still hoping that someone out there has a solution to edit this mf PV Header in a way that a vgmodify command is possible and no cluster locking information is on the PV anymore.

Thanks for helping me!

[Bob_Vance]

I'm not familiar with this technical term

"mf PV Header
.
It frightens and confuses me...
;>)

[davesec]

I'm sorry about that.

[Bob_Vance]

It would be painful, and maybe dangerous, but you may be able to halt the package and change the cluster flag on the disk

halt package
vgchange -a n # redundant
vgchange -c n

.
I would hope that this would remove any cluster lock flag, but no guarantees.

Then redo the cluster flag

vgchange -c y
vgchange -a e # test it
vgchange -a n # get ready for package start
start package

but it would hopefully not have any memory of LOCK.


I may play with this.

(Emil, where are you ?)


bv

[Viktor Balogh]

yepp, at first I also thought about the cluster flag on the disks (vgchange -c). but am not sure if it is related to the locking functionality.

[davesec]

I tried this allready but with the vgchange -c n only the Configured activation Modes Flags will change and the Lock information is still there...

[Bob_Vance]

yikes!

have you called HP?

[davesec]

Not yet: Because It's a really tricky issue that I'd like to discuss with the whole HP Professional community.

I think I have a better chance to resolve this issue via the forum than the HP Support.

But I'll call HP tomorrow to get additional help from there, hopping eather that someone can help me via the forum...

[Duncan Edmonstone]

I have a vague memory that the vgchgid command might sort this out (you'd need to export the VG before doing it though and re-import afterwards)

Worth a try I guess...

HTH

Duncan

[maslo64]

Hi Dave,
if you have valid VG backup before cluster lock was in place ,try to user vgcfgrestore.

Laco

[Emil Velez]

vgchange -c n vgxx
vgchange -c y vgxx or
cmapplyconf with the vg at the end of the file should mark the vg and each disk for activation with SG>

The lock information if the disk is defined as a lock disk is written to the bad block area of a disk (unless you use LVMv2).

I think that until you associate that disk with a new cluster and do cmapplyconf it may not change that area in the BBRA and it will not use that area unless that disk is configured as the lock disk of a cluster.

as long as the disk can be activated with this cluster after it is associated with this cluster
vgchange -c y vgxx
or cmapplyconf

You should be ok using the disk with thsi cluster as part of a vgchange -a e activated volume group.

[davesec]

1. Thanks to all you Answers. The solutions I adopted were the following:

Solution 1

If you have valid VG backup before cluster lock was in place, you can use vgcfgrestore.

1. Halt the cluster package that uses the vg01

# cmhaltpkg mypkg

2. Deactivate the vg01 on all nodes (normaly this is the case if you halt the package)

# vgchange -a n vg01

3. Restore the configuration from the

# vgcfgrestore -f /path/to/vg01.conf /dev/rdisk/disk71
Volume Group configuration has been restored to /dev/rdisk/disk71

4. Export and Import it on the other node

# vgex vg01 node2

* vgex is included in the HPUX Tools
5. Start the cluster package

# cmrunpkg mypkg

Solution 2

1. Halt the cluster package that uses the vg01

# cmhaltpkg mypkg

2. Deactivate the vg01 on all nodes (normaly this is the case if you halt the package)

# vgchange -a n vg01

3. Export the vg01

# vgexport -s -m /tmp/vg01.map vg01

4. Change the VGID of all disks that were member of the vg01

# vgchgid /dev/rdisk/disk71

5. Reimport the vg01

# vgimport -m /tmp/vg01.map vg01 /dev/disk/disk71
vgimport: Volume group "/dev/vg01" has been successfully created.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.

6. Cluster activate the vg01

# vgchange -c y vg01

7. Export the vg01 on the other node

node2# vgexport vg01

8. Export and Import it on the other node

# vgex vg01 node2

* vgex is included in the HPUX Tools
9. Check the newly created vg01

# vgchange -a r vg01
Activated volume group.
Volume group "vg01" has been successfully changed.
# vgdisplay -v vg01
--- Volume groups ---
VG Name /dev/vg01
VG Write Access read-only
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 1
Act PV 1
Max PE per PV 25599
VGDA 2
PE Size (Mbytes) 4
Total PE 25599
Alloc PE 1
Free PE 25598
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
VG Max Size 1638336m
VG Max Extents 409584

--- Logical volumes ---
LV Name /dev/vg01/lvol1
LV Status available/syncd
LV Size (Mbytes) 4
Current LE 1
Allocated PE 1
Used PV 1


--- Physical volumes ---
PV Name /dev/disk/disk71
PV Status available
Total PE 25599
Free PE 25598
Autoswitch On
Proactive Polling On

# lvm.11 -p -d /dev/rdisk/disk71 | grep -i lock
/* Alternate block pool length. */ 564
/* Alternate block pool start. */ 104857024
/* Cluster-lock flags. */
/* Cluster-lock area start. */ 0
/* Alternate block pool length. */ 564
/* Alternate block pool start. */ 104857024
/* Cluster-lock flags. */ <-- The lock has gone away
/* Cluster-lock area start. */ 0

10. Deactivate the vg01 again

# vgchange -a n vg01

11. Start the cluster package

# cmrunpkg mypkg