排障

热迁移后虚拟机卡死、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 被占住放不出来，无法执行其他进程，所以表现出来就是"卡死"。 ...

报 no space left on device，看上去是磁盘空间不足，但有可能不是存储满了，而是 inode 满了。用 df -i 查看 inode 使用情况，如果有 100% 的就是 inode 满了。 现象 报 no space left on device，看上去是磁盘空间不足了，那么找没用的文件删了即可。 但有可能不是存储满了，而是 inode 满了。 排查 使用 df -i 查看 inode 的使用情况，如果有 100% 的，那就说明是 inode 满了： root@host:~# df -i Filesystem Inodes IUsed IFree IUse% Mounted on udev 16059428 1017 16058411 1% /dev tmpfs 16078645 1812 16076833 1% /run /dev/sda2 3276800 154963 3121837 5% / tmpfs 16078645 4 16078641 1% /dev/shm tmpfs 16078645 13 16078632 1% /run/lock tmpfs 16078645 18 16078627 1% /sys/fs/cgroup /dev/sda4 31162368 4308 31158060 1% /data /dev/sdb1 182939648 564 182939084 1% /data/container 然后查找哪里小文件特别多。 ...

删除文件后磁盘空间没释放，是因为文件被进程打开，进程还持有文件描述符。用 lsof | grep deleted 找到占用进程，最好的方法是在线清空文件。 现象 在 Linux 或者 Unix 系统中，通过 rm 或者文件管理器删除文件，磁盘空间却没有释放。 根因 通过 rm 删除文件，只是将它从文件系统的目录结构上解除链接（unlink），也就是说只是删除了文件和系统目录结构的链接。 如果文件在删除时是被打开的（有一个进程正在使用该文件，文件被进程锁定或者有进程一直在向这个文件写数据等）状态，那么进程将仍然可以读取该文件，进程还持有文件的文件描述符 fd，所以磁盘空间也就会一直被占用。 一个文件在文件系统中的存放分为两个部分：数据部分和指针部分。 指针位于文件系统的 meta-data 中，数据被删除后，这个指针就从 meta-data 中清除了； 而数据部分存储在磁盘中，数据对应的指针从 meta-data 中清除后，文件数据部分占用的空间就可以被覆盖并写入新的内容； 之所以出现删除文件后空间还没释放，就是因为有进程还在一直向这个文件写入内容，导致虽然删除了文件，但文件对应的指针部分由于进程锁定，并未从 meta-data 中清除； 而由于指针并未被删除，那么系统内核就认为文件并未被删除，因此通过 df 命令查询空间并未释放也就不足为奇了。 解决办法 1. 找到占用进程并 kill 通过 lsof | grep deleted 命令获取到已经被删除但是仍然被应用程序占用的文件列表，然后 kill 掉还在占用所删除文件的进程。 需要注意的是：如果有很多进程都在使用所删除文件，那么采用这种方式 kill 进程就有点麻烦了，而且风险也比较大。 因为 kill 进程是通过截断 proc 文件系统中的文件可以强制要求系统回收分配给正在使用的文件。 必须要确定不会对运行中的进程造成影响时才能使用，应用程序对这种方式支持的并不好，当一个正在使用的文件被截断可能会引发不可预知的问题。 2. 停掉或重启应用 停掉或重启使用这个所删除文件的应用，让 OS 自动回收磁盘空间。 3. 重启操作系统 也可以重启操作系统，不过这并不是最好的方法。 4. 在线清空文件（推荐） 对待这种进程不停对文件写日志的操作，要释放文件占用的磁盘空间，最好的方法是在线清空这个文件。 通过这种方法，磁盘空间不但可以马上释放，也可保障进程继续向文件写入日志。 在线清空文件（比如 /var/log/app.log）的方式： ...

virsh detach 后 domblklist 有短暂延时，detach 成功后立即 detach 相同卷也能成功，两次重复 detach 后再 attach 会失败。根因是 libvirt 不是实时状态，有一定延时。 现象 已测试：连续 attach、detach、attach、detach… 反复是没有问题的。 有问题的： detach 后，virsh domblklist 是没有卸载的，要过一两秒，有短暂延时； detach 成功后，立即 detach 相同的卷，居然也可以成功。预期应该是会报错提示没有对应的卷； 两次重复的 detach 后，再 attach，attach 命令成功，但实际没有把卷挂载上。 根因 我们挺多奇怪的问题，可能都是类似的原因造成的。 libvirt 和 qemu： libvirt 不是实时状态，有一定延时； 然后一些重复操作，看上去是幂等的，但是它对后续操作有影响（其实也是 libvirt 的 bug）。 比如之前有过 domblk 和 qmp 查询卷不一样的情况，造成后续丢数据等。 设计思考 做重试之前，要充分测试。 是否达到了重试条件（状态、时间）； 这个动作是否幂等； 对后续动作是否有影响。 重试不是灵药，可能是毒药。 小结 virsh detach 后 domblklist 有短暂延时，要过一两秒； detach 成功后立即 detach 相同卷也能成功，不符合预期； 两次重复 detach 后再 attach，attach 成功但实际没挂载上； 根因是 libvirt 不是实时状态，有一定延时； 做重试之前要充分测试，重试不是灵药，可能是毒药。

ARM 虚拟机配置中 <features> 区块缺少 <acpi/>，表面现象是 virsh console 登录没反应。根因是 ACPI 缺失导致系统底层硬件/服务初始化异常，间接引发登录流程失败。 现象 ARM 虚拟机配置中 <features> 区块里缺少 <acpi/>，虚拟机异常。 表面现象是 virsh console 的时候登录没有反应。 这种时候其实都是虚拟机启动阶段就有问题了。 排查 各 feature 的作用 <apic/> - 高级可编程中断控制器（Advanced Programmable Interrupt Controller） 这是 x86 架构的中断控制器标准，替代老式的 8259 PIC； 负责管理 CPU 的中断请求（比如硬件设备的信号、定时器中断等）； 支持多核心 CPU 的中断分发、中断优先级控制、中断重映射等； 对 ARM 环境的意义：ARM 架构不使用 APIC，这个配置属于冗余配置（无实际作用），是兼容 x86 配置模板留下的，删除也不会影响 ARM 虚拟机运行。 <pae/> - 物理地址扩展（Physical Address Extension） 这是 32 位 x86 架构的内存扩展技术，让 32 位 x86 系统突破 4GB 物理内存的访问限制（最大支持 64GB）； 对 ARM 环境的意义：你的环境是 64 位 ARM（aarch64），天然支持大于 4GB 的内存寻址，<pae/> 完全无作用，属于冗余配置。 <acpi/> - 高级配置与电源接口（Advanced Configuration and Power Interface） ...

sdf 设备总是加不到 multipath 下，配置没问题，重启 multipathd 也不行。根因是 /etc/multipath/wwids 被人手动加了个 # 注释，导致对应的盘一直加载不上。 现象 sdf 的设备总是加不到 multipath 下。 /etc/multipath.conf 的配置没有问题，重启 multipathd 依然不行，报错也不明显。 排查 后来发现是 /etc/multipath/wwids 下有人手动改了： # Multipath wwids, Version : 1.0 # NOTE: This file is automatically maintained by multipath and multipathd. # You should not need to edit this file in normal circumstances. # # Valid WWIDs: /wwid-example-0001/ /wwid-example-0002/ /wwid-example-0003/ #wwid-example-0004/ # 这里多一个 # 导致对应的 sdf 一直记载不上 /wwid-example-0005/ /wwid-example-0006/ 问题就出在那一行多了一个 #，导致对应的 sdf 一直加载不上。 ...

pvscan 报 Global lock failed 且没有返回信息，不一定是数据没了。停掉 sanlock 和 lvmlockd 再 pvscan，只要 pv 在，一切都好说。 现象 在 ubuntu18 arm 上，pvscan 没有返回信息： root@host:/etc/lvm/archive# pvscan Global lock failed: error -210 No matching physical volumes found 这个时候不要慌，不一定是数据没了。 排查 把 sanlock 和 lvmlockd 停掉，再 pvscan 看看是否有，一般来说是在的： root@host:/etc/lvm/archive# pvscan WARNING: lvmlockd process is not running. Reading without shared global lock. Reading VG vg_b without a lock. PV /dev/mapper/mpath-b VG vg_b lvm2 [<500.00 GiB / <499.00 GiB free] Reading VG vg_a without a lock. PV /dev/mapper/mpath-a VG vg_a lvm2 [<1000.00 GiB / <545.00 GiB free] Total: 2 [1.46 TiB] / in use: 2 [1.46 TiB] / in no VG: 0 [0 ] 只要 pv 在，那么一切都好说。 ...

k8s 环境里 pod 之间 ICMP 通但 TCP 不通，client 收到 synack 却不响应。根因是 server 端 tunl 设备的 tx-checksumming 没生效，发出的包校验和错误，被 client 丢弃。 现象 有个 k8s 的环境，pod 之间 ICMP 是通的，TCP 不通。 client 发送的 SYN 报文，可以收到 server 的 SYNACK 回复，但是 client 并不响应这个 SYNACK 报文。 排查 通过 tcpdump -vvv 抓包，看到 server 发出的包，在 client 端依然 checksum incorrect。 怀疑是 server 端的 tx-checksumming: on 功能对 tunl 设备没有生效。 关闭 server 的该功能后正常： ethtool -K tunl0 tx off 根因 1. tunl0 是个软件设备 client 和 server 用 tunnel 隧道来通信，这里的 tunl0 是个软件设备。 ...