VM Disks nach dem Verschieben auf anderes Storage defekt/korrupt

aL1aL7 said:
Das saferemove ist der Haken beim Storage "Daten sicher löschen" - weiß jetzt die genaue Bezeichnung der UI nicht, aber Du findest die Option dann in der Storage Konfiguration.
Click to expand...
Vermutlich meinst du Wipe removed Volumes. Das habe ich nicht angehakt und das hat mit dem Phänomen garantiert nix zu tun.
aL1aL7 said:
Das Discard bei der Disk ist ja eine Stufe darunter, das betrifft ja Daten innerhalb einer Disk die gelöscht werden. Das saferemove bezieht sich auf kpl. Disks die auf einem LVM gelöscht werden
Click to expand...
Ich habe da nicht genau drauf geachtet, aber wenn ein gelöschtes LV nicht auch per discard/Trim an das Storage weitergegeben werden würde, hätte ich schon einige Storages vollaufen sehen müssen.
aL1aL7 said:
BTW: Habe heute noch ein paar Disks von laufenden VM's verschoben - alles stressfrei
Click to expand...
Aber trotzdem interessant, wenn man mal eine alte ausgeschaltete VM verschiebt, muss die ja konsistent bleiben.
 
Falk R. said:
Vermutlich meinst du Wipe removed Volumes. Das habe ich nicht angehakt und das hat mit dem Phänomen garantiert nix zu tun.
Click to expand...
Das würde ich in der Doku anders lesen (ich habe ja - siehe vorne - auf einer Linux Platte dann plötzlich Fragmente von Windows dll's):

Code: 
saferemove
Called "Wipe Removed Volumes" in the web UI. Zero-out data when removing LVs. When removing a volume, this makes sure that all data gets erased and cannot be accessed by other LVs created later (which happen to be assigned the same physical extents). This is a costly operation, but may be required as a security measure in certain environments.

Storage devices that support the "write zeroes" operation will use blkdiscard to zero blocks. Otherwise, a fallback to cstream is performed.
 
Last edited:
aL1aL7 said:
Das würde ich in der Doku anders lesen (ich habe ja - siehe vorne - auf einer Linux Platte dann plötzlich Fragmente von Windows dll's):

Code: 
saferemove
Called "Wipe Removed Volumes" in the web UI. Zero-out data when removing LVs. When removing a volume, this makes sure that all data gets erased and cannot be accessed by other LVs created later (which happen to be assigned the same physical extents). This is a costly operation, but may be required as a security measure in certain environments.

Storage devices that support the "write zeroes" operation will use blkdiscard to zero blocks. Otherwise, a fallback to cstream is performed.
Click to expand...
Dann braucht die ME4 das eventuell, aber alle anderen Storages mit Thinpool löschen selbstständig und nullen aus. Ich werde das mal testen.
 
Warum sollte das Storage die Sachen wipen?

Code: 
When removing a volume, this makes sure that all data gets erased and cannot be accessed by other LVs created later

Da steht doch, dass die Daten da bleiben - das Löschen der Disk löscht doch nur das LV lässt aber die Daten da
 
Ich sehe bei anderen Storages nach dem löschen eines LV (VM Disk) dass ein Reclaim auf dem Pool startet. Da wird Speicher frei gegeben und somit im Background ausgenullt.
Eventuell liegt das daran, dass ich eine VM Disk gelöscht habe wo Discard eingeschaltet war.
 
VM aus lassen und auch nicht kurz starten, sonst schreibt der Gast dir gleich wieder rein und der Vergleich ist wertlos. Größe vom zvol holen und den Vergleich damit begrenzen, das LV ist auf Extent-Größe aufgerundet und hinten drüber wäre immer ein Unterschied:

Code: 
SIZE=$(blockdev --getsize64 /dev/zvol/rpool/data/vm-100-disk-0)
cmp -n $SIZE /dev/zvol/rpool/data/vm-100-disk-0 /dev/<vg>/vm-100-disk-0

cmp sagt dir direkt, bei welchem Byte der erste Unterschied sitzt. Liegt der Offset weit hinten oder gibt es nur ein paar Stellen, riecht das nach nicht geflushten letzten Blöcken. Sind die Unterschiede über die ganze Platte verstreut, ist es was anderes und ich würd Richtung Storage/Pfade schauen. Wenn dir ein ja/nein reicht, tuts auch head -c $SIZE /dev/zvol/... | sha256sum auf beiden Seiten, dauert bei 7T halt.

Dass der e2fsck sauber durchläuft und dir danach ein apt mit Segfault wegfliegt, heißt im Klartext, dass die Nutzdaten selbst verbogen sind und nicht bloß Metadaten. Das ist schon heftig und wenn der cmp einen Unterschied zeigt, gehört das direkt in einen Bugreport.

Was mir noch auffällt: dein global_filter wirft nur zd und rbd raus, LVM schaut also auch auf die einzelnen sdX-Pfade. Normalerweise fängt die Multipath-Component-Detection von lvm2 das ab, aber schau doch mal mit pvs -a drüber, ob da wirklich nur das dm-Device als PV auftaucht und nicht zusätzlich noch die nackten sdX.
 
pvs -a liefert jeweils nur ein Device für ein iSCSI Volume - das passt in meinen Augen.

Ich hatte vorgestern noch die beiden Disks (vor/nach dem Verschieben) Byteweise verglichen.
Die geschriebenen Originaldaten waren ohne einen einzigen Fehler auf der neuen Platte, jedoch waren in Bereichen wo nix stehen sollte Daten - bei einer 80 GB Disk waren 13GB mit Fremddaten versehen.
Ich habe mal einen Bug reported, mal schauen was raus kommt.
In der Zwischenzeit weiß ich auf was ich achten muss (normalerweise Verschiebe ich eh nicht viel, nur in diesem Fall mit weg von der NVMe).
Meinen freien Platz habe ich zwischenzeitlich mal mit Platten befüllt, und danach wider gelöscht (saferemove vorher auf 1)
 
Last edited:
Die Daten stimmen 1:1, die leeren Bereiche enthalten Müll - beim Offline-Weg erklärt sich das: qemu-img convert überspringt Nullbereiche, schreibt sie gar nicht erst, und das frische LV bringt die alten Extents halt mit. Online läuft das über den Blocklayer anders, deshalb hattest du bei laufenden VMs keine Probleme damit. 13GB Fremddaten in einer 80er Disk ist aber ein sauberer Fund für den Bugreport.

Statt saferemove dauerhaft anzulassen (kostet beim Löschen ordentlich Zeit) würd ich issue_discards = 1 im devices-Abschnitt von /etc/lvm/lvm.conf probieren. Dann setzt LVM beim Entfernen/Verkleinern von LVs ein Discard ab und der Thin-Pool auf der ME sollte die Extents freigeben. Ob die ME4 nach dem Unmap auch wirklich Nullen zurückliefert, musst du kurz nachmessen - das funktioniert nicht bei jedem Array.

Hast du den Link zum Bugreport? Würd ich gern mitlesen.
 
Bu66as said:
Was mir noch auffällt: dein global_filter wirft nur zd und rbd raus, LVM schaut also auch auf die einzelnen sdX-Pfade. Normalerweise fängt die Multipath-Component-Detection von lvm2 das ab, aber schau doch mal mit pvs -a drüber, ob da wirklich nur das dm-Device als PV auftaucht und nicht zusätzlich noch die nackten sdX.
Click to expand...
Ich weiß nicht wo du das gesehen hast, aber das klingt nach falsch eingerichteten Multipathing. Sollte man wirklich mal drauf schauen.
 
Multipath können wir abhaken, das hatte @aL1aL7 in #27 schon geprüft: pvs -a zeigt pro iSCSI-Volume nur das dm-Device, keine nackten sdX daneben. Die Component-Detection von lvm2 funktioniert sauber, meine Vermutung von vorhin ist damit vom Tisch.

Danke für den Link zum Bug, bin da jetzt auch drauf. Ob 13% oder 13GB ändert am Kern nichts: die Nutzdaten kommen 1:1 rüber, nur die Bereiche die eigentlich leer sein sollten bringen den alten Extent-Inhalt mit. Hast du issue_discards = 1 eigentlich mal getestet, oder bleibst du erstmal bei saferemove?
 
Multipathing passt in meinen Augen, das dargestellte /dev/sda1 ist wirklich eine physikalische Platte im Host. Das Ergebnis ist auf allen Hosts das Gleiche.

Code: 
❯ pvs -a
  PV                        VG                 Fmt  Attr PSize  PFree 
  /dev/mapper/vm_pve_sas_01 me4-sas-01         lvm2 a--  <7.28t   <2.12t
  /dev/mapper/vm_pve_ssd_01 ME4_PVE_SSD_01_LVM lvm2 a--   3.18t <484.59g
  /dev/nvme0n1p2                                    ---      0        0
  /dev/nvme0n1p3                                    ---      0        0
  /dev/sda1                                         ---      0        0

Nee das mit issue discards = 1 habe ich noch nicht versucht. Wenn es zeitlich passt mache ich mich da nächste Woche mal dran
 
Last edited:
  • Like
Reactions: Bu66as
You must log in or register to reply here.
Top Bottom
Back