You can try it with vgs and customized column output:
vgs -o vg_name,vg_uuid,pv_uuid
It should look somewhat like this:
VG VG UUID PV UUID
rl lfTJTT-hCgr-nIfI-VB8o-i0ze-20F3-ReXssf akQG9K-H5x4-U0K1-ij7c-4JQw-rbvk-9NUND5
rl c70c76-sSDO-EjZd-Zfuc-w3Hw-Da3Y-GM9lf6 gwKY6m-aesa-XKZZ-TL0d-XdFt-...
Turns out all it needed was a grub2-install in order to fix the boot.
Full command was this:
grub2-install --directory /usr/lib/grub/i386-pc/ /dev/nvme0n1
I am writing this "for dummies" fix mostly for myself, I know I will run into this problem again :)
booted from a centos install stick
select troubleshooting > rescue a centos system
Before removing the disk you need to deactive the LVM Volume Group first with vgchange -an <vg_name>. This will also deactivate all the logical volumes and remove the device mapper mappings and thus removing the entries in /dev/mapper.
Your VG vg-cluster has three PVs -- /dev/sda2 (199.5G), /dev/sda3 (50G), and /dev/sde1 (50G) on the second disk, so you have approximately 300 GiB of space in the VG that is all used by your lv_root, lv_swap and lv_var LVs.
Note: When gathering information about storage when LVM is involved, using lvs/pvs/vgs is usually better than lsblk which cannot display ...
umount the filesystem
Reduce the size of the filesystem by at least the size of the PV you want to remove (with e.g. resize2fs or fsadm; this step can be integrated into the next one with lvresize --resizefs)
Reduce the size of the LV by at least the size of the PV you want to remove (lvresize); check the success with pvs and vgs.
Use pvmove for moving all ...
You can use lvdisplay -m to display LV segments and PVs these segments are allocated on:
--- Logical volume ---
LV Name root
--- Segments ---
Logical extents 0 to 17916:
Physical volume /dev/mapper/luks-dfcda59b-1322-4705-bb04-e09a72b2d678
Physical extents ...
The first two sectors in an ext4 filesystem are not used.
If you create a DOS partition table with only primary partitions then those writes affect the first sector only and no filesystem data has been destroyed.
If a logical partition has been created then it is possible that data has been destroyed (depending on the position of the partition).
If a GPT has ...
Most likely, you need to enable the scan_lvs option in your /etc/lvm/lvm.conf
If this still doesn't work, the device might be filtered out, in which case you might need to tinker with the filter option.