虚拟机FT切换失败，先别急着重启主机，核心动作是确认FT日志网络、辅助虚拟机状态和资源预留，再按日志判断是网络、存储还是兼容性问题。
FT切换失败通常不是“主机坏了”这么简单，它更像主虚拟机与辅助虚拟机之间的同步链条断了，只要复制网络抖动、辅助虚拟机资源不足、存储锁冲突或版本不兼容，接管就会失败，下面按排查顺序拆开讲。
虚拟机FT切换失败怎么办？先判断“没切”还是“切了又断”
看vCenter事件和虚拟机摘要
登录vCenter,选中故障虚拟机，进入“监控”>“事件”，过滤FT、Fault Tolerance、vLockstep，重点看三类信息：
- 是否提示FT日志网络不可达
- 是否提示辅助虚拟机进入未同步状态
- 是否出现创建辅助虚拟机、迁移辅助虚拟机失败
同时看虚拟机“里的FT状态，显示“已启用”不等于同步正常，有时会变成“已降级”或“已禁用”。
分清已启用、已降级、已禁用三种状态
- 已启用：主辅虚拟机同步中，但不代表网络和存储没有隐患。
- 已降级：FT仍在运行，复制可能中断，此时切换大概率失败。
- 已禁用：FT保护已经失效，需要重新配置或重建辅助虚拟机。
如果状态是“已降级”，先查FT日志网络和主机资源，不要直接关闭FT再开启，关闭再开启只能临时刷新状态，根因不解决还会复发。
生产环境虚拟机FT切换失败怎么排查？按网络、资源、存储、兼容性逐层查
第一步：检查FT日志网络
FT日志网络是主辅虚拟机复制状态的专用通道,它和业务网络、管理网络混用，失败概率会明显升高，据公开的vSphere管理文档，FT要求主辅虚拟机配置一致，并建议使用独立FT日志网络。
在ESXi主机SSH执行：
esxcli network ip interface list esxcli network vswitch standard portgroup list vmkping -I vmk1 -d -s 1472 192.0.2.2
如果MTU是9000,改用：
vmkping -I vmk1 -d -s 8972 192.0.2.2
重点看丢包、超时、不分片失败，端到端MTU不一致，是FT切换异常的常见原因，交换机、物理网卡、vmkernel、对端主机都要一致。
再查防火墙规则：
esxcli network firewall ruleset list | grep -i ft esxcli network firewall ruleset allowedip list --ruleset-id=ft
FT规则未放通,或允许IP列表漏了辅助虚拟机所在主机，切换就会卡住。
第二步：检查资源预留与主机状态
FT要求主虚拟机、辅助虚拟机都预留全部内存和CPU资源，主机超分严重时，辅助虚拟机可能无法创建或无法接管。
在vSphere Client检查：
- 虚拟机内存预留是否等于配置内存
- CPU预留是否足够
- 主机是否处于维护模式、断开状态
- 集群HA接入控制是否阻止辅助虚拟机启动
命令行可看进程和资源：
esxcli vm process list esxtop
esxtop里按m看内存，按c看CPU，如果主机内存接近饱和，先迁移其他虚拟机，再重试FT。
第三步：检查存储与快照
FT虚拟机不能有快照,存在快照时，FT可能显示正常，但切换时无法创建辅助虚拟机，检查快照：
vim-cmd vmsvc/get.snapshotinfo <vmid>
还要确认主辅虚拟机使用共享存储,且数据存储有可用空间、无锁冲突，存储性能抖动较大时，FT同步会超时，近年来，不少生产环境把FT和普通虚拟机混放在同一数据存储，结果切换时被存储延迟拖垮。
第四步：检查版本、CPU、EVC兼容性
FT对主机版本、CPU型号、虚拟硬件版本有要求，主辅主机CPU代差太大，或未启用EVC，辅助虚拟机可能无法运行。
检查点：
- 主辅ESXi版本尽量一致
- 集群开启EVC,且模式兼容两台主机CPU
- 虚拟机硬件版本符合FT支持范围
- 主辅虚拟机配置文件、网卡类型、磁盘类型一致
第五步：检查证书、时间、vCenter连通性
证书过期、主机时间不同步，会导致FT复制握手失败，在ESXi执行：
date ntpq -p openssl x509 -in /etc/vmware/ssl/rui.crt -noout -dates
时间偏差大时,先同步NTP，证书异常则重新生成或替换，并重启管理代理：
services.sh restart
VMware FT切换失败和HA重启有什么区别？别把两件事混在一起
机制差异
HA是在主机故障后,把虚拟机在其他主机上重新启动，FT是主辅虚拟机同步运行，故障时辅助虚拟机立即接管，HA会中断应用，FT理论上不中断。
行业共识认为,FT不是备份，它解决的是单台虚拟机因主机硬件故障导致的中断，不能替代应用层高可用。
排查侧重点
- HA失败：看主机网络、管理网络、隔离响应、集群接入控制。
- FT失败：看FT日志网络、辅助虚拟机同步、资源预留、CPU兼容。
- HA和FT同时开启时,要确认HA不会错误重启正在接管的辅助虚拟机。
| 现象 | 优先怀疑 | 快速验证 |
|---|---|---|
| 切换时提示FT网络不可达 | FT日志网络或MTU | vmkping -d -s 1472 |
| 辅助虚拟机已启用但不同步 | 资源预留或CPU兼容 | 查预留、EVC |
| 任务卡在创建辅助虚拟机 | 存储锁、快照、权限 | 查vmware.log和快照 |
| 切换后应用断连 | 应用无集群或交换机未收敛 | 查应用日志和MAC表 |
北京企业虚拟机FT切换失败怎么解决？远程和现场排查路径
远程先做五项自检
- 查vCenter事件,确认失败发生在主辅复制还是接管阶段。
- 查FT日志网络丢包,确认MTU和VLAN一致。
- 查主机资源,确认内存、CPU预留足够。
- 查快照和存储锁,确认辅助虚拟机可创建。
- 查EVC、主机版本、证书时间。
现场重点看交换机和存储链路
北京不少企业机房跨机柜部署,FT日志网络经过多层交换机，现场要查：
- 交换机端口错包、CRC错误
- VLAN Trunk是否放通FT VLAN
- 链路聚合是否哈希不均
- 存储交换机是否出现拥塞
如果远程命令显示丢包,但物理交换机有错包，先换端口或光纤，再重试FT。
预算有限时虚拟机FT切换失败排查要花多少钱？先做三项零成本自检
免费工具与命令
用vCenter事件、ESXi Shell、vmkping、esxtop、vmware.log，就能覆盖多数FT切换异常，不需要先买新监控。
什么时候需要付费支持
出现以下情况,再考虑原厂或第三方支持：
- 日志明确提示存储锁竞争,但找不到具体卷
- 多主机、多虚拟机反复FT降级
- 需要重建FT辅助虚拟机并调整集群策略
- 硬件、交换机、存储链路同时异常
业内专家指出,FT切换失败往往不是单一故障，而是网络、存储、版本三条链路中至少一条先出问题。
把FT切换失败当成链路问题处理
FT切换异常的核心不是反复开关FT,而是恢复主辅虚拟机之间的同步链路，先保业务，再查网络、资源、存储、兼容性，最后才考虑重建FT。只要辅助虚拟机无法稳定同步，切换就一定会失败。
虚拟机FT切换失败怎么办：高频Q&A
虚拟机FT切换失败后，主虚拟机数据会丢吗？
通常不会,FT失败主要影响接管能力，主虚拟机若仍在运行，数据一般还在，但若主虚拟机同时发生主机硬件故障，辅助虚拟机又未同步，就可能丢失最近未复制的写入，此时要按存储快照和备份恢复。
FT显示已启用，为什么故障时没有自动切换？
“已启用”只说明配置存在，不代表vLockstep同步健康，常见原因是FT日志网络超时、辅助虚拟机资源不足、存储锁冲突、CPU兼容性异常，先查vCenter事件和ESXi的vmware.log，再查vmkping丢包。
预算有限没有商业监控，如何判断FT切换异常？
看三个信号：vCenter事件里FT网络超时、虚拟机摘要从“已启用”变“已降级”、辅助虚拟机频繁创建失败，再用vmkping -d -s 1472和esxtop验证网络与资源，当vCenter事件出现FT网络超时且vmkping丢包时，优先处理网络链路，而不是反复重启虚拟机。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/749276.html
