chr.istoph, der Blog

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

sudo lvs
  LV         VG Attr   LSize   Origin  Snap%  Move Log Copy%  Convert
  windows    vg owi-i-  40,00g                                       
  windows_81 vg swi-i-  40,00g windows 100,00

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:

sudo lvchange -ay /dev/vg/windows

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.

sudo lvs
  LV         VG Attr   LSize   Origin  Snap%  Move Log Copy%  Convert
  windows    gw owi-ao  40,00g                                       
  windows_81 gw swi-a-  40,00g windows  73,22

Ich habe mir 4 neue HGST Ultrastar A7K3000 2TB SATA6 Festplatten für meine Server gegönnt. Zum Vergleichen habe ich ein paar Tests mit LVM und mdadm gemacht.

Dafür habe ich je ein 5GB großes Setup gebaut und mit dd die Volumen erst gelesen und dann beschrieben. Dies habe ich in dieser Reihenfolge gemacht, um sicherzugehen, dass keine Daten aus dem cash gelesen werden.

Dabei bin ich zu folgenden spannenden Ergebnissen gekommen:

Mein Fazit: LVM ist doch deutlich langsamer als mdadm. Erschrocken hat mich die 2,6 fach schlechtere Schreibperformance bei LVM Raid5. Überrascht hat mich auch, dass ein mdadm raid10 fast die Nativ mögliche Geschmeidigkeit, 1/2 facht von reid0, erreicht hat.

Für die Testbedienungen habe ich ein aktuelles Ubuntu 14.04 LTS mit lvm2 2.02.98-6ubuntu2 und mdadm 3.2.5-5ubuntu4.2 verwendet.
(mehr …)

Ab und zu kommt es vor das bei VMs Festplatten vergrößert werden müssen. Bei den alten Systemen ohne LVM im Gastsystem muss dies leider noch offline geschehen.
Zur Sicherheit sollte man ein snappshot des LVs machen und/oder den MBR zuvor sichern.

lvcreate -L 500M --snapshot -n mysnap /dev/vg/lv

Zunächst wird das LV auf dem Träger System vergrößert:

# lvresize -L +20G vg/lv
Size of logical volume vg/lv changed from 80,00 GiB (20480 extents) to 100,00 GiB (25600 extents).
Logical volume lv successfully resized

Danach kann man den MBR neu anlegen. Hier ist auf folgende Fehler Meldung in fdisk zu achten:

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').

bzw. erschient nach dem anlegen der Partition folgender hinweise, welcher auch auf den falschen Modus hinweist.
Partition 2 does not start on physical sector boundary.

Dann muss wie im Beispiel fdisk mit -c für den DOS-compatible Modus angegeben werden:

fdisk -c /dev/mapper/vg-lv

Befehl (m für Hilfe): n
Befehl Aktion
e Erweiterte
p Primäre Partition (1-4)
p
Partitionsnummer (1-4): 1
Erster Zylinder (1-13054, Vorgabe: 1): 1
Last Zylinder, +Zylinder or +size{K,M,G} (1-13054, Vorgabe: 13054): +95G

Zunächst wurden die Vorhandenen Partitionen gelöscht. Dabei braucht man keine Sorge haben das alle Daten weg sind. (Das Löschen der Daten würde wesentlich länger dauern)
Dann wird eine „neue“ größere Partition angelegt.


Befehl (m für Hilfe): p

Befehl (m für Hilfe): n
Befehl Aktion
e Erweiterte
p Primäre Partition (1-4)
p
Partitionsnummer (1-4): 2
Erster Zylinder (12402-13054, Vorgabe: 12402):
Benutze den Standardwert 12402
Last Zylinder, +Zylinder or +size{K,M,G} (12402-13054, Vorgabe: 13054):
Benutze den Standardwert 13054

Nach einer Überprüfung der Partition habe ich auch die zweite Partition über den Rest der Festplatte angelegt.


Befehl (m für Hilfe): a
Partitionsnummer (1-4): 1

WARNING: Re-reading the partition table failed with error 22: Das Argument ist ungültig.
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)
Synchronisiere Platten.

Anschließend habe ich noch den Boot Modi a und die Art der Partition 82 angegeben. Nur wenn man sich wirklich Sicher ist sollte man w zum Speichen angeben.

# partprobe
Warning: WARNING: the kernel failed to re-read the partition table on /dev/sda (Das Gerät oder die Ressource ist belegt). As a result, it may not reflect all of your changes until after reboot.

Um den Kernel noch bekannt zugeben, dass es eine neue Partitionstabelle gibt, muss einmal partprobe ausgeführt werden. Alternativ kann man auch die VM Booten und das vergrößern Online durchführen. (Achtung: dann sollte die Partition aber im Readonly Modus mountet sein)

# resize2fs -p /dev/mapper/vg-lv
resize2fs 1.41.12 (17-May-2010)
Bitte zuerst »e2fsck -f /dev/mapper/vg-lv« laufen lassen.


# e2fsck -f -y /dev/mapper/vg-lv
...
/dev/mapper/vg-lv: ***** DATEISYSTEM WURDE VERÄNDERT *****
/dev/mapper/vg-lv: 512061/4825088 Dateien (0.1% nicht zusammenhängend), 18926485/19922384 Blöcke


# resize2fs -p /dev/mapper/vg-lv
resize2fs 1.41.12 (17-May-2010)
Die Grösse des Dateisystems auf /dev/mapper/vg-lv wird auf 24904448 (4k) Blöcke geändert.

Start von Durchgang 1 (max = 153)
Vergrößere die Inode-TabelleXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Das Dateisystem auf /dev/mapper/vg-lv ist nun 24904448 Blöcke groß.


Nach dem unsauberen entfernen einer USB Platte mit LVM und mdadm Raid kam es beim aufrufen jeglicher lvm Kommandos zu folgenden Fehlern:

# vgscan
Reading all physical volumes. This may take a while...
/dev/md0: read failed after 0 of 4096 at 0: Input/output error
/dev/md0: read failed after 0 of 4096 at 9997975552: Input/output error
/dev/md0: read failed after 0 of 4096 at 9998090240: Input/output error
/dev/md0: read failed after 0 of 4096 at 4096: Input/output error
/dev/dm-23: read failed after 0 of 4096 at 45097091072: Input/output error
/dev/dm-23: read failed after 0 of 4096 at 45097148416: Input/output error
/dev/dm-23: read failed after 0 of 4096 at 0: Input/output error
/dev/dm-23: read failed after 0 of 4096 at 4096: Input/output error
Found volume group "vg01" using metadata type lvm2

Mittels dmsetup kann man die lvs löschen. Die fehlen lvs kann man mittels ls auflisten und mit remove wieder löschen:
# dmsetup ls | grep ^vg01
vg01-lv66_hdd (254, 23)
# dmsetup remove vg01-lv66_hdd


# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdd1[2]
9763768 blocks super 1.2 [2/1] [_U]

Das raid device konnte man mittels mdadm dann einfach Stoppen. Siehe dazu auch: mdadm –stop

Ein Raid kann natürlich nicht gestoppt werden, wenn es noch verwendet wird. In meinem Fall:
# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb2[1]
966994808 blocks super 1.2 [2/1] [_U]

unused devices: < none >

# mdadm --stop /dev/md0
mdadm: failed to stop array /dev/md0: Device or resource busy
Perhaps a running process, mounted filesystem or active volume group?

Eigentlich war das System nicht mehr gemountet. Nur noch das LVM war auf der Platte in Verwendung. Dafür musste ich das VG erst mal stoppen:
# vgchange -a n vg0
0 logical volume(s) in volume group "vg0" now active

Dann ging es auch mit dem Aushängen der Platte.
# mdadm --stop /dev/md0
mdadm: stopped /dev/md0