Manually and forcibly remove LVM configuration
 

Unbeknownst to me the LVM volume (on LUN) that I removed from my server was in use by another system. So instead of vgexporting the volume group on one of the servers and then lv,vg,pv-removing it on the other I dismantled the LVM devices my servers (as belwo).

0. unmount the filesystem
1. Remove logical volume (lvremove <vg>/<lv>)
2. Remove volume group (vgremove <vg>)
3. Remove LVM metadata from disk device (pvremove <dm-xx>)
4. Remove multipaths to disk (echo 1 > /sys/class/scsi_device/<h:c:t:l>/device/delete)
5. Mask and destroy the underlying LUN

I am now in the position that I can not remove the LVM configuration or multipath devices from the other server because it does not know about the volume group and can't see the disk.

For example vgdisplay errors as below

[root@chclnxora3 ql-dynamic-tgt-lun-disc-2.17]# vgdisplay -v VolGroupSharedRefresh23
Using volume group(s) on command line
Finding volume group "VolGroupSharedRefresh23"
/dev/dm-6: read failed after 0 of 4096 at 0: Input/output error
/dev/VolGroupSharedRefresh23/SharedRefresh23: read failed after 0 of 4096 at 0: Input/output error
Wiping cache of LVM-capable devices
/dev/mapper/sharedrefresh: read failed after 0 of 4096 at 644245028864: Input/output error
/dev/mapper/sharedrefresh: read failed after 0 of 4096 at 644245086208: Input/output error
/dev/mapper/sharedrefresh: read failed after 0 of 4096 at 0: Input/output error
/dev/mapper/sharedrefresh: read failed after 0 of 4096 at 4096: Input/output error
/dev/mapper/sharedrefresh: read failed after 0 of 4096 at 0: Input/output error
/dev/mapper/VolGroupSharedRefresh23-SharedRefresh23: read failed after 0 of 4096 at 644140171264: Input/output error
/dev/mapper/VolGroupSharedRefresh23-SharedRefresh23: read failed after 0 of 4096 at 644140228608: Input/output error
/dev/mapper/VolGroupSharedRefresh23-SharedRefresh23: read failed after 0 of 4096 at 0: Input/output error
/dev/mapper/VolGroupSharedRefresh23-SharedRefresh23: read failed after 0 of 4096 at 4096: Input/output error
/dev/mapper/VolGroupSharedRefresh23-SharedRefresh23: read failed after 0 of 4096 at 0: Input/output error
Volume group "VolGroupSharedRefresh23" not found

How on earth can I tidy up this mess?

Oh snap.

This has never happened to me, but only because I have EXTREME paranoia about this kind of thing.

I see you got a flood of sympathetic responses! lol

I see the post is quite old, did you fix it?

My best guess would be to mess with a copy of /etc/lvm/backup/VolGroupSharedRefresh23 or any other LVM config backup you have...
Then try and load it with a 'vgcfgrestore'...

But I'd do some serious Google'ing and drink a bottle of Jack first!

All the best.

Sadly not; either no one knows or no one cares. *SOB!*

Exactly how was it 'shared'; NFS, cluster, sshfs, samba... ?
Assuming you want to destroy it ie not try to recover in situ (impossible imho), you need to 'disconnect' the 2 systems using the approriate cmds depending on how it was 'shared'.
If the 2nd server has no other LVMs, you could next try uninstalling LVM sw on there, or try these 2 links to help you edit the cfgs as needed.
http://tldp.org/HOWTO/LVM-HOWTO/
http://sunoano.name/ws/public_xhtml/lvm.html

As far as I can discern the LUN was presented to one of the servers and the LVM structures created; then the same LUN was presented simultaneously to the other server (to provide read only access to the data(?)) and the LVM stuctures were detected and imported (They are stored on the disk device, right?). My problem is that I have effectively removed the LVM structures from the LUN (and destroyed the LUN) when removing it from the first server. This has left the second server with some limited knowledge of the LVM configuration but absolutely no access to the LUN or it's LVM info. My task is to tidy up the second server so that it has absolutely no trace of the PV, VG and LVs. Sadly it uses LVM for many other volumes so I can not just uninstall LVM.

this is the key pt as per my prev qn; how was it 'presented' ie what protocol eg via a SAN, sshfs, nfs ... ?
Which system is the LVM disk(s) actually/primarily attached to? If the 1st system, then check those links to fix the cfgs on the 2nd system.
If the disk(s) are attached to the 2nd system, then you may also have to look at fdisk.

The LUN was presented by the SAN.
I don't know in which order the hosts were presented the disk.
The configuration is completely removed from one host and the disk is no longer there.