存储集群未完全就绪时计算节点抢拉虚拟机并非配置错误，而是调度逻辑在Ceph PG未active+clean、iSCSI LUN未完成recovery或NFS stale handle未刷新等“假性健康”信号下作出的误判，导致虚机启动后IO路径随机卡死。
存储集群未完全就绪时，计算节点抢拉虚拟机（尤其是PVE、OpenStack或VMware中常见）不是配置错误，而是调度逻辑在“假性健康”信号下做出的误判——比如Ceph OSD刚启动但PG未active+clean、iSCSI target已上线但LUN未完成recovery、或NFS挂载看似成功但实际stale handle未刷新。这种状态下虚机可能启动成功却在IO路径上随机卡死，排查必须绕过“服务端口通了就行”的惯性思维。
确认存储后端真实就绪状态，别信挂载点或进程存在
计算节点看到/mnt/storage能ls、systemctl status iscsid显示active，不代表IO可用。真实就绪要看存储层内部一致性状态：
- Ceph场景：必须执行
ceph -s，重点检查pgmap中active+clean比例是否100%，若出现degraded或peering，即使OSD全up，虚机写入也可能触发hang - iSCSI场景：在计算节点运行
iscsiadm -m session -P 3 | grep "State\|recovery"，若输出含recovery pending或State: LOGGED IN (non-flash)，说明LUN尚未完成SCSI协议级ready - NFS场景：用
showmount -e <storage-ip></storage-ip>确认export列表后，必须sudo nfsstat -m查挂载选项，若含soft且timeo=600，则存储短暂不可用时内核会静默重试而非报错，导致虚机IO卡在uninterruptible sleep
抓取计算节点侧IO路径阻塞证据，定位是存储响应慢还是计算层误判
虚机卡住时，宿主机上常表现为ps aux | grep qemu里进程状态为D（uninterruptible sleep），但这不等于存储真挂了——可能是计算节点IO调度器或驱动层卡在等待超时。关键动作是：
- 立刻执行
iostat -x 1 5，观察%util是否持续100%且await飙升（>100ms），若r/s和w/s接近0，说明请求根本没发到存储，堵在本地块设备层 - 检查
dmesg -T | tail -30，重点找end_request: I/O error、qemu-kvm: timeout waiting for device或nvme nvme0: controller is down类日志，这些比journalctl里的service日志更早暴露底层失败 - 对PVE环境，直接查
qm config <vmid></vmid>中scsi<n>: ... cache=none</n>配置——若存储后端不支持write-through但虚机磁盘设了cache=none，IO会因等待存储确认而堆积，尤其在PG未clean时
临时阻断计算节点自动拉起虚机，避免雪崩式IO挤压
存储未就绪时，计算节点上的高可用管理器（如PVE的pmxcfs、OpenStack的nova-compute）仍会按心跳恢复策略尝试重启虚机，形成IO风暴。必须快速干预：
- PVE：执行
systemctl stop pve-ha-lrm（停高可用资源管理器），再qm stop <vmid> --skiplock</vmid>强制关虚机，避免qm start自动触发 - OpenStack：在控制节点运行
nova service-list | grep compute找到对应host，然后nova service-disable <host> nova-compute</host>，禁止该节点接受新调度 - 通用方法：在计算节点临时卸载存储挂载点并禁用自动挂载，例如
umount -l /var/lib/vz/images后注释/etc/fstab中对应行，防止reboot后自动重连故障存储
真正容易被忽略的是：存储集群“看起来正常”的窗口期（比如Ceph OSD up但PG recovery中）往往只有几十秒，而计算节点的健康检查间隔默认是30–60秒。这意味着你看到ceph -s输出OK时，很可能刚跨过那个危险临界点——必须把ceph pg stat和ceph osd df加入监控告警，而不是只盯ceph -s的summary行。
