内核

虚拟机无响应，virsh console 卡住进不去。一个思路是重启后快速进入 console，看内核启动日志，往往能直接暴露根因。 现象 虚拟机无响应，virsh console 卡在下面这个地方： virsh console vm-example Connected to domain vm-example Escape character is ^] 排查思路 virsh console 卡在这地方，分两步： 多等一会看看，能否进去，可能是启动慢； 等几分钟还不行，那就是有问题了。 一个思路是重新启动，然后快速的进入 virsh console，可能能看到 kernel 启动日志，可能有线索： virsh destroy vm-example; virsh create vm-example.xml virsh console vm-example 比如这里就打印了日志： [ 2.313329][ T1] Run /init as init process Fatal glibc error: CPU does not support x86-64-v2 # 这里就是关键点，cpu 不支持 x86-64-v2 [ 2.315336][ T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 2.316635][ T1] CPU: 0 PID: 1 Comm: init Not tainted 6.6.0-28.0.0.34.oe2403.x86_64 #1 [ 2.317855][ T1] Hardware name: QingCloud E3, BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 2.319339][ T1] Call Trace: 根因 日志里 Fatal glibc error: CPU does not support x86-64-v2 就是关键线索——CPU 不支持 x86-64-v2 指令集，导致 init 进程直接 panic。 ...

LXC 销毁后，hyper 内核报 unregister_netdevice 网卡错误，困扰了很久。根因是网卡 down 后 IPv6 协议栈仍持有 netdevice 引用，在 hyper 中加一个 disable_ipv6=1 的操作就好了。 现象 LXC 销毁后，hyper 内核报网卡错误 unregister_netdevice，这个问题困扰了很久没有解决。 按道理，应该是清理网卡之前，清理相关资源。但我们的程序是直接 down 网卡。 后来有人在网卡 down 后加了一个清理 ipv6 neigh 的操作，然后就好了。卧槽。 排查 先看接口没 down 的时候，比如 eth0 上有 neigh： root@host:~# ip n s 10.0.0.252 dev eth1 lladdr 36:95:2f:f5:af:85 STALE 10.0.0.1 dev eth0 lladdr 02:54:d7:af:4b:cb STALE 10.0.0.253 dev eth1 lladdr 52:54:d7:c6:e8:47 STALE fe80::5054:d7ff:fec6:e847 dev eth1 lladdr 52:54:d7:c6:e8:47 router STALE fd00:2024:822:0:167:ffff:ffff:fffd dev eth1 lladdr 52:54:d7:c6:e8:47 router STALE fe80::e01e:53ff:fe85:5ca0 dev eth0 lladdr 02:54:d7:af:4b:cb router STALE 把接口 eth0 down 掉： ...

热迁移后虚拟机卡死、CPU 100%，往往是时间处理出了问题。用 crash 看 dump 能确认死循环卡在内核路径，再用 perf 在虚拟机内和宿主机上对比，就能定位到时间中断处理异常。 现象 把一台虚拟机从 Ubuntu 20 宿主机热迁移到 Ubuntu 22 宿主机后，虚拟机卡死了。 从宿主机看，virsh migrate 是成功的，虚拟机处于 running 状态，qemu 进程也正常。但被迁移的虚拟机 CPU 占用 100%，完全无响应。 排查 用 crash 分析 virsh dump 出来的内存转储，发现内核一直在刷下面的报错，看起来是死循环卡在了调度进程 swapper 上： [7686175795.936645] Call Trace: [7686175795.936647] <IRQ> [7686175795.936651] run_timer_softirq+0x2a/0x50 [7686175795.936655] __do_softirq+0xd1/0x2c1 [7686175795.936658] irq_exit+0xae/0xb0 [7686175795.936660] smp_apic_timer_interrupt+0x7b/0x140 [7686175795.936662] apic_timer_interrupt+0xf/0x20 [7686175795.936662] </IRQ> [7686175795.936664] RIP: 0010:native_safe_halt+0xe/0x10 [7686175823.935201] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0] 0 号进程就是 swapper 进程，也就是调度进程。 这种 CPU 100% 表现出来的卡死，必然是因为某种原因让 CPU 进入了死循环——CPU 被占住放不出来，无法执行其他进程，所以表现出来就是"卡死"。 ...