5:44 p.m.
I did some checking and my disk is not in a state I expected. (The system doesn't even
know the VG exists in it's present state) See the results:
# pv
PV VG Fmt Attr PSize PFree
/dev/md127 onn_vmh lvm2 a-- 222.44g 43.66g
/dev/sdd1 gluster_vg3 lvm2 a-- <4.00g <2.00g
# pvs -a
PV VG Fmt Attr PSize PFree
/dev/md127 onn_vmh lvm2 a-- 222.44g 43.66g
/dev/onn_vmh/home --- 0 0
/dev/onn_vmh/ovirt-node-ng-4.2.7.1-0.20181216.0+1 --- 0 0
/dev/onn_vmh/root --- 0 0
/dev/onn_vmh/swap --- 0 0
/dev/onn_vmh/tmp --- 0 0
/dev/onn_vmh/var --- 0 0
/dev/onn_vmh/var_crash --- 0 0
/dev/onn_vmh/var_log --- 0 0
/dev/onn_vmh/var_log_audit --- 0 0
/dev/sda1 --- 0 0
/dev/sdb1 --- 0 0
/dev/sdd1 gluster_vg3 lvm2 a-- <4.00g
<2.00g
/dev/sde1 --- 0 0
# vgs
VG #PV #LV #SN Attr VSize VFree
gluster_vg3 1 1 0 wz--n- <4.00g <2.00g
onn_vmh 1 11 0 wz--n- 222.44g 43.66g
# vgs -a
VG #PV #LV #SN Attr VSize VFree
gluster_vg3 1 1 0 wz--n- <4.00g <2.00g
onn_vmh 1 11 0 wz--n- 222.44g 43.66g
# lvs
LV VG Attr LSize Pool Origin
Data% Meta% Move Log Cpy%Sync Convert
tmpLV gluster_vg3 -wi------- 2.00g
home onn_vmh Vwi-aotz-- 1.00g pool00
4.79
ovirt-node-ng-4.2.7.1-0.20181216.0 onn_vmh Vwi---tz-k 146.60g pool00 root
ovirt-node-ng-4.2.7.1-0.20181216.0+1 onn_vmh Vwi-aotz-- 146.60g pool00
ovirt-node-ng-4.2.7.1-0.20181216.0 4.81
pool00 onn_vmh twi-aotz-- 173.60g
7.21 2.30
root onn_vmh Vwi-a-tz-- 146.60g pool00
2.92
swap onn_vmh -wi-ao---- 4.00g
tmp onn_vmh Vwi-aotz-- 1.00g pool00
53.66
var onn_vmh Vwi-aotz-- 15.00g pool00
15.75
var_crash onn_vmh Vwi-aotz-- 10.00g pool00
2.86
var_log onn_vmh Vwi-aotz-- 8.00g pool00
14.73
var_log_audit onn_vmh Vwi-aotz-- 2.00g pool00
6.91
# lvs -a
LV VG Attr LSize Pool Origin
Data% Meta% Move Log Cpy%Sync Convert
tmpLV gluster_vg3 -wi------- 2.00g
home onn_vmh Vwi-aotz-- 1.00g pool00
4.79
[lvol0_pmspare] onn_vmh ewi------- 180.00m
ovirt-node-ng-4.2.7.1-0.20181216.0 onn_vmh Vwi---tz-k 146.60g pool00 root
ovirt-node-ng-4.2.7.1-0.20181216.0+1 onn_vmh Vwi-aotz-- 146.60g pool00
ovirt-node-ng-4.2.7.1-0.20181216.0 4.81
pool00 onn_vmh twi-aotz-- 173.60g
7.21 2.30
[pool00_tdata] onn_vmh Twi-ao---- 173.60g
[pool00_tmeta] onn_vmh ewi-ao---- 1.00g
root onn_vmh Vwi-a-tz-- 146.60g pool00
2.92
swap onn_vmh -wi-ao---- 4.00g
tmp onn_vmh Vwi-aotz-- 1.00g pool00
53.66
var onn_vmh Vwi-aotz-- 15.00g pool00
15.75
var_crash onn_vmh Vwi-aotz-- 10.00g pool00
2.86
var_log onn_vmh Vwi-aotz-- 8.00g pool00
14.73
var_log_audit onn_vmh Vwi-aotz-- 2.00g pool00
6.91
# pvscan
PV /dev/md127 VG onn_vmh lvm2 [222.44 GiB / 43.66 GiB free]
PV /dev/sdd1 VG gluster_vg3 lvm2 [<4.00 GiB / <2.00 GiB free]
Total: 2 [<226.44 GiB] / in use: 2 [<226.44 GiB] / in no VG: 0 [0 ]
# vgscan
ACTIVE '/dev/onn_vmh/pool00' [173.60 GiB] inherit
ACTIVE '/dev/onn_vmh/root' [146.60 GiB] inherit
ACTIVE '/dev/onn_vmh/home' [1.00 GiB] inherit
ACTIVE '/dev/onn_vmh/tmp' [1.00 GiB] inherit
ACTIVE '/dev/onn_vmh/var' [15.00 GiB] inherit
ACTIVE '/dev/onn_vmh/var_log' [8.00 GiB] inherit
ACTIVE '/dev/onn_vmh/var_log_audit' [2.00 GiB] inherit
ACTIVE '/dev/onn_vmh/swap' [4.00 GiB] inherit
inactive '/dev/onn_vmh/ovirt-node-ng-4.2.7.1-0.20181216.0' [146.60 GiB]
inherit
ACTIVE '/dev/onn_vmh/ovirt-node-ng-4.2.7.1-0.20181216.0+1' [146.60
GiB] inherit
ACTIVE '/dev/onn_vmh/var_crash' [10.00 GiB] inherit
inactive '/dev/gluster_vg3/tmpLV' [2.00 GiB] inherit
# lvscan
Reading all physical volumes. This may take a while...
Found volume group "onn_vmh" using metadata type lvm2
Found volume group "gluster_vg3" using metadata type lvm2
I sort of expect I may need to do a restore/rebuild of the disk using the data from the
lvm backup folder. I found some interesting articles:
https://www3.unixrealm.com/repair-a-thin-pool/ and
https://chappie800.wordpress.com/2017/06/13/lvm-repair-metadata/ I have read through them
and I'm trying to slowly digest the information in them. Working with thin volumes to
do a repair is definitely new to me. My past experience is that they just work as they
should. I am only now learning the hard way that thin disks have meta data and a very
specific structure. At least I'm not learning LVM and thin at the same time. Anyway,
I digress. Based on what I read I was able to download and install
device-mapper-persistent-data rpm to the node. I then went and checked the tools location
to see what tools are available:
# cd /usr/bin (checking for the existence of available tools)
# ls | grep pv
fipvlan
pvchange
pvck
pvcreate
pvdisplay
pvmove
pvremove
pvresize
pvs
pvscan
# ls | grep vg
vgcfgbackup
vgcfgrestore
vgchange
vgck
vgconvert
vgcreate
vgdisplay
vgexport
vgextend
vgimport
vgimportclone
vgmerge
vgmknodes
vgreduce
vgremove
vgrename
vgs
vgscan
vgsplit
# ls | grep lv
lvchange
lvconvert
lvcreate
lvdisplay
lvextend
lvm
lvmconf
lvmconfig
lvmdiskscan
lvmdump
lvmetad
lvmpolld
lvmsadc
lvmsar
lvreduce
lvremove
lvrename
lvresize
lvs
lvscan
Based on the scenario here, how do I get my disks in a state that I can both find and
rebuild the data for VG and VG metadata / LV and LV metdata ?