chr.istoph, der Blog

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.

cat /sys/block/sda/queue/max_sectors_kb
32767

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:

ACTION=="add|change", ENV{ID_FS_USAGE}!="filesystem", ENV{ID_PATH}=="*-iscsi-*", RUN+="/bin/sh -c 'echo 4096 > /sys$DEVPATH/queue/max_sectors_kb'"

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

Beim editieren des Keybord Layout einer VM ist mir folgender Fehler unterlaufen.
virsh start server1
Fehler: Domain server1 konnte nicht gestartet werden
Fehler: internal error: process exited while connecting to monitor: Could not read keymap file: 'de-de'

Die Sprache „de-de“ gibt es einfach nur nicht es muss nur „de“ heißen. Siehe den Auszug aus dem Wiki:

(mehr …)

Heute musste ich mal wieder an eine KVM Image heran. Da diese Images immer auch eine Partitionstabelle am Anfang der Datei haben, muss man dieses Image erst loop mounten. Dafür legt man zuerst das loop device an. Mit kpartx werden dann die Partitionen dem Kernel unter /dev/mapper/loop0pX bekannt gemacht.

Ein RAW Image monuten:

losetup /dev/loop0 /var/lib/libvirt/images/vm.img
kpartx -av /dev/loop0
mount /dev/mapper/loop0p1 /mnt

Ein loop device wieder umounten:

umount /mnt
kpartx -dv /dev/loop0
losetup -d /dev/loop0

Heute musst ich eine KVM Image Mounten. Da es raw in einem LV lag musste ich die Partitionen im LV mounten. Dies geht mit einem loop device.

losetup /dev/loop0 /dev/mapper/server
kpartx -a /dev/loop0

Dann stehen einem die Partitonen entweder als:
mount /dev/mapper/loop0p1 /mnt/server

oder wieder rum als lv zur verfügung:
vgscan
mount /dev/vg-server/server /mnt/server

Mit KVM kann man dynamische HDs eine bestimmte größer geben. Will man nun aber mehr Daten darin Speichern, kann man im virt-manager die HD nicht mehr vergrößern. Dann hilft folgender Befehl um den Container virtuell größer zu machen.

dd conv=notrunc bs=1 count=1 seek=40971520000 if=/dev/zero of=./hd.img