Posts

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 在，那么一切都好说。 ...

sanlock 的 wdmd 看门狗在多 vg 场景下不适合启用：只要一个锁空间续约失败，wdmd 就不喂狗，导致宿主机被强制重启。上层的事应该上层做，双写并发控制应该用业务全局锁，而不是依赖底层存储机制。 现象 sanlock 这里，还是应该把 wdmd 给禁用了。尤其是在多 vg 场景下，不太适合。 根因 wdmd 是什么 wdmd 是 Watchdog Multiplexing Daemon（看门狗多路复用守护进程）。 为什么多 vg 场景下不适合 一个锁空间，sanlock 会和 wdmd 建立一个连接。一个 vg 一个锁空间。 只要有一个锁空间续约失败，wdmd 就不会喂狗。 所以，如果一个 vg 断联了，其他 vg 正常，客户其实不希望关闭宿主机。 哪些情况会触发 reset 存储 IO 压力大，也会导致 sanlock 续约失败，但是上面的虚拟机是正常的； 如果 wdmd 自身异常了，也会触发 watchdog reset； 如果 sanlock 服务异常了，也会触发 watchdog reset； 有些慢存储，sanlock 容易锁过期、失效，也会触发 reset。 这些都不是用户想看到的。 设计思考 sanlock 是个底层存储锁，但是上层应用有自己的场景和控制逻辑。 底层做，只能一刀切： 要么很严格，动不动就关宿主机了； 要么很宽松，那可能还是会造成双写数据不安全。 上层的事上层做。 双写，终究是因为有两个虚拟机。 所以，要在创建虚拟机那里使用业务的全局锁，来做并发控制，而不是依赖底层存储机制。 小结 wdmd 看门狗在多 vg 场景下不适合启用； 只要一个锁空间续约失败，wdmd 就不喂狗，导致宿主机被强制重启； 存储 IO 压力大、wdmd 异常、sanlock 异常、慢存储锁过期，都可能触发 reset； 底层锁只能一刀切，双写并发控制应该用业务全局锁，上层的事上层做。

在 ARM（aarch64）架构下，libvirt/QEMU 的 CPU 模型与特性禁用设置不生效，虚拟机看到的 CPU 依然是透传的物理 CPU。所以 ARM 架构下，别探索什么指令集、热迁移了，全部用 passthrough。 现象 将虚拟机 CPU 设置为 custom 模式，指定 Kunpeng-920 指令集，并通过 <feature policy="disable"> 禁用 asimddp、asimdfhm 两个 CPU 特性。 对比宿主机与虚拟机内的 lscpu / /proc/cpuinfo 输出，发现设置未生效。 尽管 QEMU 进程命令行已携带 -cpu Kunpeng-920,asimddp=off,asimdfhm=off，虚拟机内部看到的 CPU 依然是透传的物理 CPU（特性、implementer、part 号与宿主机完全一致）。 排查 测试环境 项目 值 宿主机架构 aarch64 (ARM64) 宿主机 CPU HUAWEI Kunpeng 920 3210 (HiSilicon) 虚拟机架构 aarch64, machine virt-4.1 QEMU qemu-system-aarch64 (4.1.0.2) 虚拟化 KVM (accel=kvm) 虚拟机内存/CPU 1024 MiB / 1 vCPU 虚拟机 XML 的 CPU 部分 <cpu mode="custom" match="exact"> <model>Kunpeng-920</model> <feature policy="disable" name="asimddp"/> <feature policy="disable" name="asimdfhm"/> <topology sockets="1" cores="1" threads="1"></topology> <numa> <cell id="0" cpus="0" memory="1048576" unit="KiB" discard="yes"></cell> </numa> </cpu> QEMU 进程的 -cpu 参数 虚拟机启动后，QEMU 进程实际命令行中的 CPU 相关参数： ...

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 是个软件设备。 ...