Nach Update 7.0.14-23-pve Fehler: activating LV 'pve/data' failed: Check of pool pve/data failed (status:64)

[Proximoxi20]

Hallo an alle Proxmox Spezialisten,

Heute habe ich Update/Upgrade an meinem Proxmox durchgeführt. Nach den das System neu gestartet ist bekam ich den Fehler: activating LV 'pve/data' failed: Check of pool pve/data failed (status:64). Manual repair required! (500) von meiner local-lvm.
Nach dem ich den Beitrag hier gelesen habe: https://forum.proxmox.com/threads/t...iled-status-64-manual-repair-required.169356/
habe ich versucht mit: lvconvert --repair pve/data meine lvm zu reparieren. Leider ohne Erfolg. Mit: vgchange -ay data ebenfalls nicht.

#vgchange -ay data
Volume group "data" not found
Cannot process volume group data

#lvs -a data:
Volume group "data" not found
Cannot process volume group data


# pvs
PV VG Fmt Attr PSize PFree
/dev/nvme0n1p3 pve lvm2 a-- <930,51g 16,00g

#vgs
VG #PV #LV #SN Attr VSize VFree
pve 1 9 0 wz--n- <930,51g 16,00g

#lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi---tz-- 794,30g
root pve -wi-ao---- 96,00g
swap pve -wi-ao---- 8,00g
vm-101-disk-0 pve Vwi---tz-- 20,00g data
vm-109-disk-1 pve Vwi---tz-- 100,00g data
vm-111-disk-1 pve Vwi---tz-- 8,00g data
vm-114-disk-1 pve Vwi---tz-- 10,00g data
vm-115-disk-0 pve Vwi---tz-- 50,00g data
vm-150-disk-1 pve Vwi---tz-- 50,00g data

#pvesm status
activating LV 'pve/data' failed: Check of pool pve/data failed (status:64). Manual repair required!
Name Type Status Total (KiB) Used (KiB) Available (KiB) %
QNAP_Backup_NUC7 nfs active 2917062688 1880474240 1036588448 64.46%
SSD_CTVM zfspool active 967618968 183727772 783891196 18.99%
local dir active 98497780 51490332 41957900 52.28%
local-lvm lvmthin inactive 0 0 0 0.00%

# cat /etc/pve/storage.cfg
dir: local
path /var/lib/vz
content backup,iso,vztmpl,import
shared 0

lvmthin: local-lvm
thinpool data
vgname pve
content rootdir,images

zfspool: SSD_CTVM
pool SSD_CTVM
content images,rootdir
mountpoint /SSD_CTVM
nodes proxmox-nuc7

nfs: QNAP_Backup_NUC7
export /PVE_NUC7
path /mnt/pve/QNAP_Backup_NUC7
server 192.168.xxx.xxx
content backup
prune-backups keep-all=1


Wenn gar nichts mehr klappt kann ich zum Not aus mein Backup die fehlerhaften Dateien überschreiben aber welcher sin das genau?:

/etc/pve
/var/lib/pve-cluster/config.db
/etc/network/interfaces
/etc/network/interfaces.d
/etc/hostname
/etc/hosts
/etc/resolv.conf
/etc/fstab
/etc/ssh
/etc/apt
/etc/default/grub
/etc/kernel/cmdline
/etc/modules
/etc/modprobe.d
/etc/systemd/system
/etc/systemd/network
/etc/cron.d
/etc/crontab
/var/spool/cron
/etc/passwd
/etc/shadow
/etc/group

noch neine:
#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 953,9G 0 disk
├─sda1 8:1 0 953,9G 0 part
└─sda9 8:9 0 8M 0 part
zd0 230:0 0 48G 0 disk
├─zd0p1 230:1 0 32M 0 part
├─zd0p2 230:2 0 24M 0 part
├─zd0p3 230:3 0 256M 0 part
├─zd0p4 230:4 0 24M 0 part
├─zd0p5 230:5 0 256M 0 part
├─zd0p6 230:6 0 8M 0 part
├─zd0p7 230:7 0 96M 0 part
└─zd0p8 230:8 0 47,3G 0 part
zd16 230:16 0 50G 0 disk
├─zd16p1 230:17 0 1M 0 part
├─zd16p2 230:18 0 2G 0 part
└─zd16p3 230:19 0 48G 0 part
nvme0n1 259:0 0 931,5G 0 disk
├─nvme0n1p1 259:1 0 1007K 0 part
├─nvme0n1p2 259:2 0 1G 0 part /boot/efi
└─nvme0n1p3 259:3 0 930,5G 0 part
├─pve-swap 252:0 0 8G 0 lvm [SWAP]
└─pve-root 252:1 0 96G 0 lvm /

Kann mir vielleicht jemand von Euch dabei helfen?

Danke schon im voraus.

 

[Bu66as]

Hallo @Proximoxi20, deine VG heißt pve, nicht data. data ist der Thin-Pool darin, deshalb laufen vgchange -ay data und lvs -a data ins Leere. Die Config-Dateien aus deiner Liste zurückzuspielen bringt hier auch nix. /etc ist ja intakt, kaputt bzw. "nicht sauber" sind die Metadaten vom Thin-Pool selbst.

Was genau kam denn bei lvconvert --repair pve/data raus? Poste mal bitte die komplette Ausgabe:

lvs -a pve
lvchange -an pve/data
lvconvert --repair pve/data

Da sieht man auch die versteckten data_tmeta/data_tdata und ob von deinem ersten Versuch schon ein data_meta0 rumliegt. Mit den 16G frei in der VG hast du genug Platz für die Reparatur.

Nach Updates prüft thin_check öfter strenger als vorher und status:64 ist dann eher ein Fehlalarm, der Pool läuft trotzdem. Bin mir nicht 100% sicher, ob das bei dir auch so ist, aber als Test kannst du in /etc/lvm/lvm.conf im global-Abschnitt thin_check_options = [ "-q", "--skip-mappings" ] setzen und dann lvchange -ay pve/data probieren. Das umgeht aber nur den Check und repariert nichts. Bevor du weiter rumprobierst, schau mal ob du von den VMs auf local-lvm (101, 109, 111, 114, 115, 150) aktuelle Backups auf dem QNAP hast.

 

[Proximoxi20]

vielen Dank für Deine Blitzschnelle Antwort.

meine Ergebnisse:

# lvs -a pve
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi---tz-- 794,30g
[data_tdata] pve Twi------- 794,30g
[data_tmeta] pve ewi------- 8,10g
[lvol0_pmspare] pve ewi------- 8,10g
root pve -wi-ao---- 96,00g
swap pve -wi-ao---- 8,00g
vm-101-disk-0 pve Vwi---tz-- 20,00g data
vm-109-disk-1 pve Vwi---tz-- 100,00g data
vm-111-disk-1 pve Vwi---tz-- 8,00g data
vm-114-disk-1 pve Vwi---tz-- 10,00g data
vm-115-disk-0 pve Vwi---tz-- 50,00g data
vm-150-disk-1 pve Vwi---tz-- 50,00g data

# lvchange -an pve/data
# lvconvert --repair pve/data (keine Ausgabe. lvm immer noch nicht da.)

Nachdem ich die Option: thin_check_options = [ "-q", "--skip-mappings" ] gesetzt habe und noch einmal lvconvert --repair pve/data probiert habe, ging es. Nach einem reboot waren alle meine vm's wieder ansprechbar. Alles läuft wie gehabt. Perfekt!

# lvconvert --repair pve/data
Cannot repair active pool pve/data. Use lvchange -an first.

Die Backups von dem vm's von heute Nacht habe ich natürlich auf meinem QNAP, wie auch von Proxmox selber.
Du hast mir Haufen Arbeit gespart.

Meine Farge noch zum Schluss: soll ich die Option in der lvm.conf so lassen oder lieber auskommentieren?

Danke vielmals für Deine Hilfe.

 

[Bu66as]

Laut deinem lvs -a pve ist der Pool nur inaktiv (twi---tz--), repariert ist da noch nix. Was bei lvconvert --repair pve/data rauskommt, fehlt noch, poste mal bitte die komplette Ausgabe. Danach lvchange -ay pve/data oder einfach rebooten. Kommt dann wieder status:64, ist eher der strengere thin_check nach dem Update das Problem. Dann kannst du in /etc/lvm/lvm.conf bei thin_check_options --skip-mappings ergänzen, vergiss aber nicht, das später wieder rauszunehmen. Mit --skip-mappings fallen genau die Fehler durch, die man mitbekommen will.

Ein data_meta0 ist in deiner Ausgabe nicht dabei, vom ersten Versuch liegt also nix rum. Nach einem erfolgreichen Repair taucht es auf. Da sichert lvconvert die alten Metadaten hin und das belegt nochmal ~8G in der VG. Wenn ein paar Tage lang alles sauber läuft, kannst du es mit lvremove pve/data_meta0 wegräumen.

 

[Proximoxi20]

ok.
Die komplette Ausgabe:
------------------------------------------------
root@proxmox-nuc7:~# lvs -a pve
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-aotz-- 794,30g 17,77 0,82
[data_tdata] pve Twi-ao---- 794,30g
[data_tmeta] pve ewi-ao---- 8,10g
[lvol0_pmspare] pve ewi------- 8,10g
root pve -wi-ao---- 96,00g
swap pve -wi-ao---- 8,00g
vm-101-disk-0 pve Vwi-aotz-- 20,00g data 42,34
vm-109-disk-1 pve Vwi-aotz-- 100,00g data 99,45
vm-111-disk-1 pve Vwi-aotz-- 8,00g data 43,81
vm-114-disk-1 pve Vwi-aotz-- 10,00g data 93,48
vm-115-disk-0 pve Vwi---tz-- 50,00g data
vm-150-disk-1 pve Vwi-aotz-- 50,00g data 24,23
root@proxmox-nuc7:~# lvchange -an pve/data
root@proxmox-nuc7:~# lvconvert --repair pve/data
Cannot repair active pool pve/data. Use lvchange -an first.
root@proxmox-nuc7:~#
root@proxmox-nuc7:~# lvchange -ay pve/data
root@proxmox-nuc7:~# reboot
root@proxmox-nuc7:~#
--------------------------------------------------

Nach dem Reboot laufen alle vm's kein status:64.

Danach --skip-mappings entfernt und wieder reboot.

Jetzt habe ich wieder (status:64)

die Ausgabe:
----
root@proxmox-nuc7:~# lvs -a pve
lvchange -an pve/data
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi---tz-- 794,30g
[data_tdata] pve Twi------- 794,30g
[data_tmeta] pve ewi------- 8,10g
[lvol0_pmspare] pve ewi------- 8,10g
root pve -wi-ao---- 96,00g
swap pve -wi-ao---- 8,00g
vm-101-disk-0 pve Vwi---tz-- 20,00g data
vm-109-disk-1 pve Vwi---tz-- 100,00g data
vm-111-disk-1 pve Vwi---tz-- 8,00g data
vm-114-disk-1 pve Vwi---tz-- 10,00g data
vm-115-disk-0 pve Vwi---tz-- 50,00g data
vm-150-disk-1 pve Vwi---tz-- 50,00g data
root@proxmox-nuc7:~#
root@proxmox-nuc7:~# lvchange -an pve/data
root@proxmox-nuc7:~#
root@proxmox-nuc7:~# lvconvert --repair pve/data
WARNING: LV pve/data_meta0 holds a backup of the unrepaired metadata. Use lvremove when no longer required.
root@proxmox-nuc7:~#
-----

Nach der Reparatur ist (status:64) nicht mehr gekommen. Ich habe noch mal reboot zur Sicherheit durchgeführt. Alles O.k.

Dei Ausgabe von jetzt:

#lvs -a pve
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-aotz-- 794,30g 17,77 0,67
data_meta0 pve -ri-a----- 8,10g
[data_tdata] pve Twi-ao---- 794,30g
[data_tmeta] pve ewi-ao---- 8,10g
[lvol1_pmspare] pve ewi------- 8,10g
root pve -wi-ao---- 96,00g
swap pve -wi-ao---- 8,00g
vm-101-disk-0 pve Vwi-aotz-- 20,00g data 42,34
vm-109-disk-1 pve Vwi-aotz-- 100,00g data 99,45
vm-111-disk-1 pve Vwi-aotz-- 8,00g data 43,81
vm-114-disk-1 pve Vwi-aotz-- 10,00g data 93,48
vm-115-disk-0 pve Vwi-a-tz-- 50,00g data 16,56
vm-150-disk-1 pve Vwi-aotz-- 50,00g data 24,23

Vorsichtig gesagt es schein alles gut zu laufen auch mit ausgeblendeten --skip-mappings .

Ich lasse das paar Tage laufen und dann lösche ich die data_meta0.

Danke dass du mich aufgeklärt hast. Ich war zu euphorisch und wollte schon die Fehlersuche abbrechen.

Ich hoffe, jetzt habe ich alles richtig gemacht.

Danke und schönen Abend noch.