Mit ‘lvm2’ Tagged einträge

Vergrößern eine Partition mit LVM

Montag, November 19th, 2018

Leider kommt es bei VMs immer wieder vor das die Festplatte im laufenden betrieb vergrößert werden muss. Im folgenden Beispiel habe ich eine LVM Partition im laufenden betrieb vergrößert.

Zunächst habe ich die Partition vergrößern müssen:

fdisk /dev/vda

Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/vda: 135 GiB, 144950685696 bytes, 283106808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xec02ef62

Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 585727 583680 285M 83 Linux
/dev/vda2 585728 33552383 32966656 15.7G 8e Linux LVM

Zunächst habe ich die Partien gelöscht:

Command (m for help): d
Partition number (1,2, default 2): 2

Partition 2 has been deleted.

Anschließend habe ich eine neue Partition angelegt:
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2):
First sector (585728-283106807, default 585728):
Last sector, +sectors or +size{K,M,G,T,P} (585728-283106807, default 283106807):

Created a new partition 2 of type 'Linux' and of size 134.7 GiB.
Partition #2 contains a LVM2_member signature.

Do you want to remove the signature? [Y]es/[N]o: n

Achtung: hier umbedingt N für no angeben. Wir wollen die Daten ja nicht löschen.

Den Type der Partition wieder richtig angeben:
Command (m for help): t
Partition number (1,2, default 2):
Partition type (type L to list all types): 8e

Changed type of partition 'Linux' to 'Linux LVM'.

Mit p noch einmal überprüfen:
Command (m for help): p
Disk /dev/vda: 135 GiB, 144950685696 bytes, 283106808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xec02ef62

Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 585727 583680 285M 83 Linux
/dev/vda2 585728 283106807 282521080 134.7G 8e Linux LVM

Wenn man sich sicher ist das alles richtig angegeben wurde kann man die Partition mit w Speicher:
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

Jetzt machen wir die Partition noch dem Kernel bekannt:
apt install partprobe
...
partprobe /dev/vda

Jetzt vergrößern wir das PV und dann das VG:
Das PV (Physical Volumes):
pvresize /dev/vda2
Physical volume "/dev/vda2" changed
1 physical volume(s) resized / 0 physical volume(s) not resized

Die VG (Volumen Gruppe):
vgextend VolGroup1
Command failed with status code 5.

Und zum Abschluss noch einmal Prüfen ob alles geht:
vgs
VG #PV #LV #SN Attr VSize VFree
VolGroup1 1 3 0 wz--n- 134.71g 121.36g

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.