问题背景
分公司虚拟化平台是一套两节点 Hyper-V Server 2022 群集，承载 26 台业务虚拟机，日常靠实时迁移（Live Migration）做宿主机维护窗口的滚动重启。9 月以来每次滚动维护，运维都会在迁移记录里看到一两个虚拟机迁移失败并自动回滚，手动重试一次基本能过，因此一直没有立案处理。
9 月下旬情况变了：一次维护窗口内连续 5 台虚拟机迁移失败，重试也有两台过不去，其中一台是 ERP 数据库虚拟机，迁移卡在 87% 后回滚，回滚瞬间数据库短暂无响应约 20 秒——实时迁移的"透明维护"承诺被打破了，问题升级。
故障现象
整理 9 月以来的迁移记录，故障呈现清晰的固定模式：
- 失败的虚拟机分布在两个节点上，与虚拟机本身的业务类型、内存大小无明显关联。
- Hyper-V 事件日志（Microsoft-Windows-Hyper-V-VMMS）记录 Event ID 21024：实时迁移失败，原因字段为"目标主机上的网络配置与源主机不匹配"；部分记录伴随 Event ID 21073 回滚完成。
- 迁移失败总发生在传输阶段后半段（80% 上下），回滚后源虚拟机继续运行，但卡顿十几到二十秒。
- 两个节点的 Windows 更新级别一致，群集验证（cluster validation）的网络测试项全部通过——按官方判据，这套群集是"健康"的。
- 失败概率与当天负载相关：白天业务高峰几乎必失败，凌晨维护窗口偶发失败。
排查过程
先比对两台宿主机的网络配置。实时迁移走的是独立的迁移网络（10.90.2.0/24，专用网卡），两个节点该网卡的 IP、VLAN、MTU 完全一致，带宽足够，这是迁移校验报告没报错的原因——问题不在这张卡上。
第二步逐项对比两节点的虚拟交换机。用 PowerShell 导出两侧的 VMSwitch 与 VMNetworkAdapter 完整属性做 diff，差异浮出水面：两节点外部交换机 vSwitch-Prod 的 QoS 带宽权重不一致——节点 A 上 Set-VMSwitch -DefaultFlowMinimumWeight 的合计为 80，节点 B 上是 40。进一步查变更记录，8 月底一次固件升级前的"预防性网络重置"巡检脚本，在节点 A 上执行过 New-VMSwitch 重建，重建脚本里带了当时的 QoS 策略参数，而节点 B 没有跑这次重建，它的交换机还是 7 月的旧参数。此后两台宿主机的 vSwitch 就在事实上漂移了。
第三步解释失败机理。实时迁移建立阶段，源节点会把虚拟机网卡的 SR-IOV 与带宽能力快照发给目标节点做兼容校验；QoS 权重不同的两个交换机，对外通告的可用带宽池不一致，目标侧校验"该虚拟机申请的最小带宽在目标交换机上得不到保证"即拒绝迁移。这也解释了负载相关性：高峰期虚拟机的实际流量逼近其 QoS 保证值，校验更容易失败；凌晨流量低，同一校验余量变大，偶尔能过。
第四步解释 cluster validation 为何全绿：群集验证测试的是节点间网络连通性、带宽与延迟，不比对 vSwitch 的策略层属性——按官方判据健康、实际不可迁移的"半盲区"正是这么产生的。
最后排除其它嫌疑：迁移认证协议（CredSSP/Kerberos）两侧一致；SMB Bandwidth Limit 未配置；CSV 流量与迁移流量已按最佳实践分网卡，无争抢。
解决方案
- 配置收敛：以节点 A 的 vSwitch 参数为准，在节点 B 上补齐相同的 QoS 带宽权重（先导出
Export-VMSwitch基线，逐项Set-VMSwitch应用，不重建交换机以免中断业务网络）；随后挑凌晨窗口迁移一台测试虚拟机，一次成功。 - 漂移防线：把两节点 vSwitch/网卡属性基线导出存入运维知识库，巡检脚本每月做一次"双节点配置 diff"，发现不一致即告警；任何节点上的
New-VMSwitch类重建操作，强制要求"跑完必须在另一节点执行同样脚本或显式确认无需同步"。 - 迁移窗口纪律：群集验证通过不等于可迁移，滚动维护前先用 1 台非关键虚拟机做迁移冒烟，确认通过再滚动全量。
根因分析
直接根因是巡检脚本只在单侧节点重建了 vSwitch 并带入新的 QoS 策略，两节点交换机配置在策略层漂移，实时迁移的兼容校验在目标侧被拒。深层根因有两个：其一，巡检脚本按"单机思维"编写，没有把"两节点对称执行"作为约束；其二，群集验证测试的盲区让常规健康检查给了虚假的安全感，配置漂移潜伏了一个月才在业务高峰暴露。
预防措施
- 两节点群集的一切网络层变更（vSwitch、QoS、NIC 高级属性）必须以"成对脚本"交付，脚本内自动检测并同步对端；
- 每月巡检增加 vSwitch 基线 diff 项，输出到运维报表；
- 实时迁移失败 Event 21024 按周统计，非零即立案，不再允许"重试能过就放过"；
- 固件升级、系统变更类巡检上线前，先在测试群集验证脚本副作用。
总结
这次的故障链没有一帧是"坏"的：每次单点操作都合理，每项健康检查都通过，但单侧变更加上对称性无人校验，就让两台本该镜像的宿主机悄悄分道扬镳。双节点群集的运维纪律核心只有一句话：凡是一侧能做的变更，另一侧要么同步做了，要么显式记录为什么不做——“没碰到"永远不该是配置不一致的理由。