Mit ‘lvm2’ Tagged einträge

Kernel Bug in CentOS 7

Sonntag, Februar 12th, 2017

Nach dem neu starten unserer VServer Plattform mit dem Kernel 3.10.0-514, traten nach sofort nach dem Booten folgende schwerwiegenden Fehler im Log auf:

kernel: Buffer I/O error on dev dm-15, logical block 8892681, lost async page write
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 4:0:0:0: [sdc] Sense Key : Not Ready [current]
kernel: sd 4:0:0:0: [sdc] Add. Sense: Logical unit communication failure
kernel: sd 4:0:0:0: [sdc] CDB: Write(16) 8a 00 00 00 00 00 37 7d 48 00 00 00 40 00 00 00
kernel: blk_update_request: I/O error, dev sdc, sector 930957312
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Aber auch folgende syslog events traten auf, nachdem mittels:

lvmcreate -L 10G -n lv_snapshot -S vg/lv

ein snapshot erzeugt wurde.

kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4718: Filesystem error recorded from previous mount: IO fail
ure
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4719: Marking fs in need of filesystem check.
kernel: EXT4-fs (dm-28): recovery complete
kernel: EXT4-fs (dm-28): mounted filesystem with ordered data mode. Opts: (null)
kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs (dm-28): orphan cleanup on readonly fs
kernel: EXT4-fs (dm-28): 6 orphan inodes deleted
kernel: EXT4-fs (dm-28): recovery complete

Schlimmer noch, die VMs wechselten nach kurzer Zeit in den read only Modus. Und konnten ohne erweitertes Filesystem Check nicht wieder gestart werden.

Zugglück sind wir schnell auf den Kernel Parameter gekommen, der das Problem verursacht hat.

Dieser Wert war bei älteren Servern noch auf 512 eingestellt. Bei den von dem Bug betroffenen Server durfte er nicht über 4096 eingestellt sein, stand aber immer wieder auf 8192.

Der CentOS Bug Report 12725, in dem das selbe verhalten mittels:

parted -s /dev/sda unit s print

beschrieben wurdet, half uns den Fehler weiter auf den Kernel einzuschränken. Immer wenn eine Partitionsabfrage, oder eine Änderung am LVM Stattgefunden hat, änderte sich der Wert plötzlich wieder auf 8192.

Folgende udev Regel, die wir unter /etc/udev/rules.d/99-san.rules eingefügt haben, verhinderte das umstellen des wertes:

Fazit:
Ein so schwerwiegenden Kernel Bug ist mit schon lange nicht mehr untergekommen. Er hatte für uns zufolge das wir bei einzelnen VMs nur noch teile retten konnten und komplett aus dem Backup wiederhergestellt werden mussten. Auch das Rechercheiren des Bugs ist bei CentOS kaum möglich. Da es zu RedHat binär kompatibel kann man nicht einfach durch ein git repository zu scrolen und sich die Änderungen und Kommentare anschauen. Wo bei mir die Überlegung offen ist, zukünftig auf einen Vanilla-Kernel zu wechseln und/oder CentOS zu vermeiden.

Unser Kernel: 3.10.0-514.6.1.el7.x86_64
Quelle Burgreport: https://bugs.centos.org/view.php?id=12725

drbd: storage live migration

Montag, August 1st, 2016

Um VMs zwischen HDD und SSD zu migrieren wäre ein „lvmove“ äquivalent ganz praktisch. Dies kann es aber nicht geben, da der Pfad zum lv dann auch angepasst werden muss. Um meine Master Slave Setup dennoch Live migrieren zu können, habe ich ein neues gleich großes lv erstellt, die Platte ausgehangen und die neue wie folgt eingegangen.

Zunächst habe ich geprüft ob ich Master oder Slave bin (ro:Secondary)

Dann habe ich dem DRBD Verbund die Storage aus gehangen:

Dies DRBD Config Datei editiert und bei der localen node das neue lv auf der neuen vg eingetragen.

Danach muss das neue lv von DRBD initialisiert werden:

Anschließend wird alles wieder gestartet und die Synchronisation begibt automatisch.

lvm mounten mit dmsetup

Sonntag, März 6th, 2016

Um die Daten einer Festplatte zu retten auf unter anderem ein LVM Raid1 war, habe ich versucht mit vgchange -ay vg das vg zu starten. Andernfalls waren die LVS nicht unterhalb von /dev/mapper/ nicht aufgeführt.
Nach dem ich aber vgchange -ay vg aufrief war die Festplatte nur noch mit Lesezugriffen beschäftige. Die LVS waren vorhanden aber leisen sich nicht mounten. Somit habe ich den Vorgang mit vgchange -an vg wieder abgebrochen.

Um von hinten am LVM vorbei an die Daten heranzukommen half mir folgende Option mit der ich an die Festplatte bzw. die Position des lvs heran kam:

In der Datei /etc/lvm/backup/vg fand ich zusätzlich noch folgend Informationen, alle anderen habe ich an dieser stelle ausgelassen:

Mit diesen Werten kann man die Position des LVs auf der Festplatte lokalisieren und mit dmsetup einen eigenes device anlegen.

(48385-38146+1)*8192
(Partitionsende – Paritionsanfang + 1) * extent_size = ergibt die gesamt Größe: 83886080

384+38146*8192
pe_start + Paritionsanfang * extent_size begin auf der Parition: 312492416

Unter /dev/mepper/lv_ro befindet sich nun das LV das gemountet werden kann.

Wie man an dieser stelle das readonly device mounten kann folgt im nächsten Blog Eintrag.

drbd online resize

Sonntag, Januar 24th, 2016

Heute musst ich einer VM mehr Speicherplatz zuweisen. Da die VM auf einem DRBD Cluster lag bin ich folgendermaßen vorgegangen.

lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
vm1 vg1 -wi-ao--- 67,00g

1. auf beiden VM Host Systemen habe ich das LV vergrößert.

2. Anschließend habe ich auf dem Primary DRBD Konten das DRBD Online vergrößert.

cat /proc/drbd
4: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---a-
ns:86370276 nr:9144 dw:86259976 dr:3566560 al:274 bm:129 lo:2 pe:8 ua:8 ap:1 ep:1 wo:f oos:71188220
[>....................] sync'ed: 0.2% (69516/69628)Mfinish: 0:42:04 speed: 28,192 (28,192) K/sec

Schon während der Synchronisation stand der vergrößerte Platz in der VM zur Verfügung.

LV nicht lesbar

Mittwoch, Januar 6th, 2016

Bei einem LVM Basierten KVM Server konnte ich eine VM nicht Starten. Das Kommando lvs zeigte an das ein Snapshot voll gelaufen sei.

Da ich den Rechner aber zuvor gebootet hatte und dies vor dem Reboot nicht der Fall war. Zudem greift meine VM nicht auf das Snapshot zu, so bin ich auf die Suche nach dem Fehler gegangen und geholfen hat folgender Befehl:

Quelle: man bash
--ignorelockingfailure
This lets you proceed with read-only metadata operations such as
lvchange -ay and vgchange -ay even if the locking module fails.
One use for this is in a system init script if the lock
directory is mounted read-only when the script runs.

Und schon wurde auch das LV wieder richtig angezeigt und konnte von KVM wieder gelesen werden.