我们的一个虚拟机崩溃了。 它不会回应ssh或ping。
由于几周前我已经崩溃了，我每10分钟logging一次top的输出，看是否有什么不妥的情况发生。 这是最后的输出：
---------------- 2017-07-06 06:40 ---------------- top - 06:40:01 up 9 days, 21:22, 0 users, load average: 0.05, 0.02, 0.00 Tasks: 165 total, 1 running, 164 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.1 us, 0.0 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16470612 total, 12609856 used, 3860756 free, 327476 buffers KiB Swap: 0 total, 0 used, 0 free. 10632360 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 43 root 20 0 0 0 0 S 25.8 0.0 1:01.36 ksoftirqd/7 3 root 20 0 0 0 0 S 12.9 0.0 15:20.34 ksoftirqd/0 38 root 20 0 0 0 0 S 12.9 0.0 1:32.62 ksoftirqd/6 63 root 20 0 0 0 0 S 12.9 0.0 1:10.70 ksoftirqd/+ 7 root 20 0 0 0 0 S 6.4 0.0 6:29.78 rcu_sched 23 root 20 0 0 0 0 S 6.4 0.0 2:33.56 ksoftirqd/3 48 root 20 0 0 0 0 S 6.4 0.0 1:08.70 ksoftirqd/8 1 root 20 0 30308 4496 3028 S 0.0 0.0 0:11.05 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.12 kthreadd 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:+ 6 root 20 0 0 0 0 S 0.0 0.0 0:06.66 kworker/u2+ 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh 9 root rt 0 0 0 0 S 0.0 0.0 0:00.28 migration/0
在syslog / kern.log ，我在崩溃之前发现了这个：
Jul 6 06:45:54 machine qemu-ga: info: guest-fsfreeze called Jul 6 06:49:09 machine kernel: [855120.260090] INFO: task jbd2/vda1-8:187 blocked for more than 120 seconds. Jul 6 06:49:09 machine kernel: [855120.478402] Not tainted 3.16.0-4-amd64 #1 Jul 6 06:49:09 machine kernel: [855120.478594] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jul 6 06:49:09 machine kernel: [855120.478903] jbd2/vda1-8 D ffff88042b78ef78 0 187 2 0x00000000 Jul 6 06:49:09 machine kernel: [855120.478909] ffff88042b78eb20 0000000000000046 0000000000012f40 ffff880036d9bfd8 Jul 6 06:49:09 machine kernel: [855120.478913] 0000000000012f40 ffff88042b78eb20 ffff88043fc137f0 ffff88043ffc5160 Jul 6 06:49:09 machine kernel: [855120.478916] 0000000000000002 ffffffff811da3c0 ffff880036d9bc30 ffff880036d91800 Jul 6 06:49:09 machine kernel: [855120.478920] Call Trace: Jul 6 06:49:09 machine kernel: [855120.478929] [<ffffffff811da3c0>] ? generic_block_bmap+0x50/0x50 Jul 6 06:49:09 machine kernel: [855120.478935] [<ffffffff81516f49>] ? io_schedule+0x99/0x120 Jul 6 06:49:09 machine kernel: [855120.478938] [<ffffffff811da3ca>] ? sleep_on_buffer+0xa/0x10 Jul 6 06:49:09 machine kernel: [855120.478942] [<ffffffff815172cc>] ? __wait_on_bit+0x5c/0x90 Jul 6 06:49:09 machine kernel: [855120.478948] [<ffffffff81280b40>] ? generic_make_request+0xb0/0x100 Jul 6 06:49:09 machine kernel: [855120.478951] [<ffffffff811da3c0>] ? generic_block_bmap+0x50/0x50 Jul 6 06:49:09 machine kernel: [855120.478955] [<ffffffff81517377>] ? out_of_line_wait_on_bit+0x77/0x90 Jul 6 06:49:09 machine kernel: [855120.478960] [<ffffffff810a9620>] ? autoremove_wake_function+0x30/0x30 Jul 6 06:49:09 machine kernel: [855120.478983] [<ffffffffa01092c5>] ? jbd2_write_superblock+0x95/0x1a0 [jbd2] Jul 6 06:49:09 machine kernel: [855120.478990] [<ffffffffa01093fe>] ? jbd2_journal_update_sb_log_tail+0x2e/0x80 [jbd2] Jul 6 06:49:09 machine kernel: [855120.478997] [<ffffffffa01035ac>] ? jbd2_journal_commit_transaction+0x185c/0x1a30 [jbd2] Jul 6 06:49:09 machine kernel: [855120.479003] [<ffffffff8105297b>] ? kvm_clock_read+0x1b/0x20 Jul 6 06:49:09 machine kernel: [855120.479008] [<ffffffff8101ca75>] ? sched_clock+0x5/0x10 Jul 6 06:49:09 machine kernel: [855120.479014] [<ffffffff810a4353>] ? pick_next_task_fair+0x3e3/0x820 Jul 6 06:49:09 machine kernel: [855120.479019] [<ffffffff8101255e>] ? __switch_to+0xde/0x5a0 Jul 6 06:49:09 machine kernel: [855120.479025] [<ffffffff810740d6>] ? lock_timer_base.isra.35+0x26/0x50 Jul 6 06:49:09 machine kernel: [855120.479032] [<ffffffffa0106d92>] ? kjournald2+0xb2/0x240 [jbd2] Jul 6 06:49:09 machine kernel: [855120.479036] [<ffffffff810a95f0>] ? prepare_to_wait_event+0xf0/0xf0 Jul 6 06:49:09 machine kernel: [855120.479043] [<ffffffffa0106ce0>] ? commit_timeout+0x10/0x10 [jbd2] Jul 6 06:49:09 machine kernel: [855120.479048] [<ffffffff8108952d>] ? kthread+0xbd/0xe0 Jul 6 06:49:09 machine kernel: [855120.479052] [<ffffffff81089470>] ? kthread_create_on_node+0x180/0x180 Jul 6 06:49:09 machine kernel: [855120.479057] [<ffffffff8151a3d8>] ? ret_from_fork+0x58/0x90 Jul 6 06:49:09 machine kernel: [855120.479061] [<ffffffff81089470>] ? kthread_create_on_node+0x180/0x180
从快速search，听起来像jbd2/vda1-8错误与磁盘上的写操作相关。
第一行是主机通过guest虚拟机代理为每日备份快照冻结VM。
挖掘更多一点，我意识到这个jbd2 / vda问题发生在不同的时间，在一天的同一时间，但不是每一天，只是在qemu冻结后，但它通常不会在机器崩溃结束。
现在，我想知道。
崩溃与jbd2 / vda问题有关吗？
这些问题是与虚拟机冻结/ snaphotted？ 通常情况下，冻结只会持续创build快照所需的less量时间，然后机器会在复制快照的同时执行操作，然后将虚拟机合并到快照中。 只有备份副本存在快照。 （万一重要， 这里是我用于备份的自定义脚本。）
主机每日cron备份虚拟机。 FWIW，我只是在虚拟机中更改了cron时间，以确保主机执行备份时不会运行。 这应该不重要，但至less它可以帮助我排除一些与VM上的croned任务有关的问题。