Xen-DomU eingefroren - warum?

[Paul Muster]

Hallo zusammen,

mir ist eine DomU, d.h. eine virtuelle Maschine (VM), meiner virtuellen
Umgebung eingefroren. Dies steht als erste, meiner Einschätzung nach
kritische Meldung in den Logs, danach noch diverse andere Tasks mit
demselben Problem.

xvda ist dabei das Blockdevice, das der VM von der
Virtualisierungumgebung Xen bereitgestellt wird. "Physisch" (aus Sicht
der Dom0, des Virtualisierungs-Hosts) ist es ein Logical Volume einer
LVM-Volume Group. Andere DomU, die mit derselben Volume Group arbeiten,
funktionieren problemlos.

[98720.732086] INFO: task jbd2/xvda-8:162 blocked for more than 120 seconds.
[98720.732124] Not tainted 4.9.0-12-686-pae #1 Debian 4.9.210-1
[98720.732130] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[98720.732137] jbd2/xvda-8 D 0 162 2 0x00000000
[98720.732147] 00000246 000053f1 00000000 eb967c00 e9983cd4 c15c31b3
c44d1800 f51d8b40
[98720.732159] f51d8b40 e9983ce0 00000001 ebb40504 eb924100 eb924100
ed0bbb00 ebb40100
[98720.732170] c1055e4f ebb40100 7fffffff 7fffffff e9983ce0 c15c36ee
00000000 e9983d2c
[98720.732183] Call Trace:
[98720.732201] [<c15c31b3>] ? __schedule+0x263/0x770
[98720.732208] [<c1055e4f>] ? pvclock_clocksource_read+0x8f/0x140
[98720.732215] [<c15c36ee>] ? schedule+0x2e/0x80
[98720.732222] [<c15c6435>] ? schedule_timeout+0x1a5/0x340
[98720.732229] [<c101a3f1>] ? xen_clocksource_get_cycles+0x11/0x20
[98720.732236] [<c10e42ca>] ? ktime_get+0x4a/0x110
[98720.732243] [<c15c2eee>] ? io_schedule_timeout+0x8e/0xf0
[98720.732249] [<c15c3e15>] ? bit_wait_io+0x15/0x50
[98720.732255] [<c15c3a60>] ? __wait_on_bit+0x50/0x80
[98720.732261] [<c15c3e00>] ? bit_wait+0x50/0x50
[98720.732270] [<c116d997>] ? wait_on_page_bit+0x67/0x80
[98720.732282] [<c10ad670>] ? wake_atomic_t_function+0x70/0x70
[98720.732295] [<c116da84>] ? __filemap_fdatawait_range+0xd4/0x130
[98720.732306] [<c116db02>] ? filemap_fdatawait_range+0x22/0x40
[98720.732318] [<c116db63>] ? filemap_fdatawait+0x43/0x60
[98720.732339] [<edaaf68c>] ?
jbd2_journal_commit_transaction+0x64c/0x1500 [jbd2]
[98720.732356] [<c10b8c36>] ?
__raw_callee_save___pv_queued_spin_unlock+0x6/0x10
[98720.732371] [<c15c76a9>] ? _raw_spin_lock_irqsave+0x19/0x50
[98720.732381] [<c10b8c36>] ?
__raw_callee_save___pv_queued_spin_unlock+0x6/0x10
[98720.732395] [<c10d9995>] ? try_to_del_timer_sync+0x45/0x70
[98720.732407] [<edab4808>] ? kjournald2+0xa8/0x230 [jbd2]
[98720.732417] [<c10ad5c0>] ? prepare_to_wait_event+0xd0/0xd0
[98720.732431] [<c1088bb7>] ? kthread+0xb7/0xd0
[98720.732444] [<edab4760>] ? commit_timeout+0x10/0x10 [jbd2]
[98720.732454] [<c1088b00>] ? kthread_park+0x50/0x50
[98720.732464] [<c15c7a40>] ? ret_from_fork+0x30/0x3c

[note to self: 30.03.2020, 12:43:29]

Es war noch eine ssh-Session offen, auf der ich "top" zwar eingeben
konnte - tat aber nicht. "echo r > /pr<TAB>" war eine dumme Idee, denn
nun hängt die SSH-Session...

Blöd, dann versuchen wir es halt über die "virtuelle Konsole" von Dom0 aus:

***@Dom0 ~ # xl console DomU

Debian GNU/Linux 9 DomU hvc0

DomU login: root

[Ctrl-5, weil kein Prompt für das Passwort kommt]
***@Dom0 ~ # xl sysrq DomU r
***@Dom0 ~ # xl console DomU
[119784.006582] xen:manage: sysrq_handler: Error -13 writing sysrq in
control/sysrq

[Ctrl-5, Schade, dass das nicht geht]
***@Dom0 ~ # xl reboot DomU
Rebooting domain 50

[Nix passiert....]


Ideen, was der VM zugestoßen sein könnte, ob/wie ich sie ohne harten
Reset wiederbeleben könnte und wie ich den Zustand für die Zukunft
verhindern könnte?

Sollte ich mich für Punkt 3 (für die Zukunft verhindern) mit
vm.dirty_ratio und vm.dirty_background_ratio beschäftigen?

Sind die Platten zu langsam für die Last der VMs?


Bitte ggf. Followup-To: setzen, abhängig von der richtigen Gruppe!


Vielen Dank & viele Grüße

Paul

[Marcel Mueller]

Post by Paul Muster
mir ist eine DomU, d.h. eine virtuelle Maschine (VM), meiner virtuellen
Umgebung eingefroren. Dies steht als erste, meiner Einschätzung nach
kritische Meldung in den Logs, danach noch diverse andere Tasks mit
demselben Problem.
xvda ist dabei das Blockdevice, das der VM von der
Virtualisierungumgebung Xen bereitgestellt wird. "Physisch" (aus Sicht
der Dom0, des Virtualisierungs-Hosts) ist es ein Logical Volume einer
LVM-Volume Group. Andere DomU, die mit derselben Volume Group arbeiten,
funktionieren problemlos.

Da hat sich die virtuelle Platte bzw. ihr Dateisystem verabschiedet.

Post by Paul Muster
Es war noch eine ssh-Session offen, auf der ich "top" zwar eingeben
konnte - tat aber nicht. "echo r > /pr<TAB>" war eine dumme Idee, denn
nun hängt die SSH-Session...

Klar beim ersten Disk-Zugriff ist Ende.

Post by Paul Muster
Debian GNU/Linux 9 DomU hvc0
DomU login: root
[Ctrl-5, weil kein Prompt für das Passwort kommt]
[119784.006582] xen:manage: sysrq_handler: Error -13 writing sysrq in
control/sysrq
[Ctrl-5, Schade, dass das nicht geht]
Rebooting domain 50
[Nix passiert....]

Logisch. Ohne root FS macht Linux genau gar nichts mehr.
Aber es ist sowieso egal, denn ohne das FS ist alles, was du jetzt noch
tust ohnehin nicht mehr persistent. Du kannst Sie also einfach hart
ausschalten. Logisch gesehen ist das längst passiert.

Post by Paul Muster
Ideen, was der VM zugestoßen sein könnte, ob/wie ich sie ohne harten
Reset wiederbeleben könnte und wie ich den Zustand für die Zukunft
verhindern könnte?

Ohne Reset? Gar nicht. Du kannst, wenn es dumm läuft froh sein, wenn du
nicht die gesamte Virtualisierungsumgebung neu starten musste. Es wäre
nämlich auch denkbar, dass es im Hypervisor hängt. Meist reicht aber VM
abschießen.

Post by Paul Muster
Sollte ich mich für Punkt 3 (für die Zukunft verhindern) mit
vm.dirty_ratio und vm.dirty_background_ratio beschäftigen?

Nein.

Die Wahrscheinlichste Ursache ist ein Bug. Aber wenn der nur alle
Schaltjahre mal auftritt, ist der natürlich schwer zu finden.

Post by Paul Muster
Sind die Platten zu langsam für die Last der VMs?

Alle Platten sind zu langsam für die Last von Betriebssystemen. ;-)
1993 hatte ich 70 IOPS. Heute hat man, wenn man nicht gerade rasende
Serverplatten (zum Preis einer SSD) hat, vielleicht 100 IOPS. Nur das
der Rest vom Rechner in der Zeit um etliche Zehnerpotenzen schneller
geworden ist. Deshalb sind alle Platten ein Bremsklotz.
(Nur in ganz großen Arrays ist das noch anders. Wenn sich Dutzende VMs
200 Spindeln teilen, dann ist immer irgendeine gerade idle.)


Marcel

[Paul Muster]

Post by Marcel Mueller

Post by Paul Muster
mir ist eine DomU, d.h. eine virtuelle Maschine (VM), meiner
virtuellen Umgebung eingefroren. Dies steht als erste, meiner
Einschätzung nach kritische Meldung in den Logs, danach noch diverse
andere Tasks mit demselben Problem.
xvda ist dabei das Blockdevice, das der VM von der
Virtualisierungumgebung Xen bereitgestellt wird. "Physisch" (aus Sicht
der Dom0, des Virtualisierungs-Hosts) ist es ein Logical Volume einer
LVM-Volume Group. Andere DomU, die mit derselben Volume Group
arbeiten, funktionieren problemlos.

Da hat sich die virtuelle Platte bzw. ihr Dateisystem verabschiedet.

Wirklich? Oder war die Platte "nur" zu langsam?

Hier
https://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/
steht, dass die Meldung bedeutet, dass der Kernel es in 120s nicht
geschafft habe, den Schreibcache auf die Platte zu bringen.

Dass der Kernel in der Folge das Dateisystem als nicht verfügbar
ansieht, finde ich ein bisschen übertrieben. Ist das wirklich so? Warum
versucht er es nicht nochmal, seinen Cache zu schreiben?

Post by Marcel Mueller

Post by Paul Muster
Sollte ich mich für Punkt 3 (für die Zukunft verhindern) mit
vm.dirty_ratio und vm.dirty_background_ratio beschäftigen?

Nein.

Hmm, ich habe trotzdem gestern abend noch weiter zu der Fehlermeldung
recherchiert und an den Parametern gedreht. Mal schauen, ob die
Situation wieder auftritt...


Viele Grüße

Paul

[Marcel Mueller]

Post by Paul Muster

Post by Marcel Mueller

Post by Paul Muster
mir ist eine DomU, d.h. eine virtuelle Maschine (VM), meiner
virtuellen Umgebung eingefroren. Dies steht als erste, meiner
Einschätzung nach kritische Meldung in den Logs, danach noch diverse
andere Tasks mit demselben Problem.
xvda ist dabei das Blockdevice, das der VM von der
Virtualisierungumgebung Xen bereitgestellt wird. "Physisch" (aus
Sicht der Dom0, des Virtualisierungs-Hosts) ist es ein Logical Volume
einer LVM-Volume Group. Andere DomU, die mit derselben Volume Group
arbeiten, funktionieren problemlos.

Da hat sich die virtuelle Platte bzw. ihr Dateisystem verabschiedet.

Wirklich? Oder war die Platte "nur" zu langsam?

Also, 120000ms Zugriffszeit alias 0,008 IOPS schafft sogar ein
Bandlaufwerk! ;-)

Ich kenne nur sehr wenige Fälle, wo eine solche Zeit tatsächlich
begründbar ist. SCSI Format Unit ist so ein Befehl, der Sowohl bei
Platten als auch bei Bändern länger dauert.

Post by Paul Muster
Hier
https://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/
steht, dass die Meldung bedeutet, dass der Kernel es in 120s nicht
geschafft habe, den Schreibcache auf die Platte zu bringen.

Üblicherweise ist das das letzte, was man sieht.

Post by Paul Muster
Dass der Kernel in der Folge das Dateisystem als nicht verfügbar
ansieht, finde ich ein bisschen übertrieben. Ist das wirklich so? Warum
versucht er es nicht nochmal, seinen Cache zu schreiben?

Das Problem ist, dass ein Thread im State D hängt. Und aus dem kommt er
von außen nur durch Reboot wieder raus. Alle Ressourcen, die er geblockt
hat, bleiben für immer verloren. Beispielsweise können alle
Speicherbereiche, die zu den DMA-Anforderungen für die Scatter Gather
List des hängenden IOs gehören nicht mehr verwendet werden. Auch kann
nicht mehr auf die betroiffenen Dateisystemblöcke zugegriffen werden.
Sobald jemand anderes es versucht hängt er ebenfalls. In dem Fall dann
an der Sperre. Erst wenn die Sperre weg ist, könnte man es erneut versuchen.

Dieser Zustand darf einfach nicht auftreten. Der Kerneltreiber müsste
die IO-Operation spätestens durch Timeout abbrechen. Ob das wieder zu
einem funktionierenden System führt, ist eine andere Frage. Wenn
beispielsweise eine Anforderung infolge eines Page-Fault nicht erfüllt
werden kann, ist der Prozess, der darauf wartet i.a. auch tot. Wenn das
der Kernel ist, dann gibt's Kernel-Panic.

Post by Paul Muster

Post by Marcel Mueller

Post by Paul Muster
Sollte ich mich für Punkt 3 (für die Zukunft verhindern) mit
vm.dirty_ratio und vm.dirty_background_ratio beschäftigen?

Nein.

Hmm, ich habe trotzdem gestern abend noch weiter zu der Fehlermeldung
recherchiert und an den Parametern gedreht. Mal schauen, ob die
Situation wieder auftritt...

Vielleicht hast Du ja Glück. Es kann genauso gut sein, dass der Fehler
auch ohne weitere Maßnahmen nur alle Schaltjahre mal auftritt. Wegen
einem Einzelfall würde ich noch keine Panik schieben, auch wenn es nervt
und ein flaues Gefühl zurück bleibt.
Jede Software ist fehlerhaft. Der Unterschied ist nur, ob die Fehler
stören. Manche treten so selten auf, dass sie keiner jemals findet.
Die Vorstellung, Computer würden sich immer deterministisch verhalten,
ist längst überholt. Das tun sie nicht. Das beginnt schon auf unterster
Ebene mit Rauschen in den Nutzsignalen. Und die Software ist, wenn man
genau genug hinguckt, auch allenfalls chaotisch deterministisch.
Meistens klappt es halt; das muss reichen. Ich würde aber keine Zeit
daran verschwenden, solange das "meistens" nicht zu wenig wird.


Marcel