2018年08月19日(日) - 23:16 | カテゴリ:
Linux
Linuxド素人な一般人が解析した結果なので、
原因究明・解析とは違うかもしれませんがご了承ください。
………
題名の通り _(:3」∠)_
実はコレが起きたのは1ヶ月程前の自宅鯖なのだが、
当時はコミケ前だった事もあり凄く忙しかったので切り戻して復旧させた。
また、それよりも前にはゲストサーバのCentOS6をkernel 4.17.0に更新すると、
GRUBでkernelを選択した後に強制再起動がかかり、
再度GRUB起動の上また再起動する無限ループ化するのも大きな問題だった。
そして、先日ふとコレの事を思い出したので夏休みを数日使ってデバッグしてみた。
最終的に原因は判らなかったが、LKML.ORGを見たりqemuのサポート情報を見た感じだと、
kernelに追加されたKPTIとホストサーバ・ゲストサーバのミスマッチっぽかった。
ちなみに、未だに解決はしていないのでどなたか詳細知っている方いたらおしえて下さい (´；ω；｀)
当初、ゲスト鯖のkernelが不具合を持っているのか、ホスト鯖の方が悪いのか判らなかった。
という事で、バージョンを変えながらkernelビルドを繰り替える事20回。
ゲストサーバのkernelを4.17.0に上げると再起動ループになる事が判明。
この再起動もKVMの機能で電源が落ちた後に自動復旧しているのか、
本当に再起動しているのか不明だった為、ゲスト鯖のlibvirt XMLを下記の様に変えながらテスト。
結果、on_rebootをdestroyすると再起動しなくなる事からゲスト側で本当に再起動していないと判明。
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
|
ぶっちゃけ、コレにたどり着くのに2日かかった _(:3」∠)_
………
最初からlibvirtdのログ出力は [log_level=1] にしていた事もあり、
QEMUのプロセスにstraceをかけてみた。
結果、再起動が発生する直前から「futex() error」が大量発生している事が判明。
状況からしてメモリマッピングが何か変なのかと推測。
kernel 4.17.0が出た頃と言えば、巷がCPUのmeltdown/spectre問題で賑わっていた時なので、
『何か実装ミスっているのかな…』と仮説を立てつつ、MLを漁ってみた。
………
最初に書いた通り明確な原因はわからなかったが、ARM64を使った場合に似た状態になる記述を発見。
状況が似ているので「KVM guest infinite reboot loop」の様に検索したら色々引っかかった。
それらを総合的に評価すると冒頭の通りとなった。
………
『色々とやった… が、ダメだったよパトラ○シュ』
qemuのリビルド＆アップグレード、libvirtdのトレースON(ログは出なかった)などなど。
Step1にも書いた通り、ゲストOS以下の物理寄りは普通に動いているわけなのでエラーが無かった。
今回、色々とやった訳なのだが目的であったエラーの解決は出来なかったが、
ヒントになりそうな所までは来れたので時間がある時に再チャレンジしようと思う。
解決は出来なかったが調査の副産物として、
今までなんとなく使っていたlibvirtd/qemuの挙動やら設定やらに詳しくなれたので、
まぁ良しとする事にしよう (´・ω・｀)
« 続きを隠す
