虚拟机迁移时死机，别慌，先切断迁移进程保住宿主机，再用强制关机和快照回滚恢复系统，最后从存储、网络和驱动三个方向排查根因。这个流程能解决八成以上的迁移卡死问题。
迁移死机最紧急的处理措施
虚拟机迁移中画面定格、管理界面无响应，第一步不是重启物理机，而是快速隔离故障域。
切断迁移任务的三种操作路径
操作前先确认你是通过Web客户端还是命令行执行迁移,不同入口的救援方式不同。
- vCenter Web Client：直接刷新浏览器会话，如果任务卡在0%或99%，尝试右键虚拟机点击“取消迁移”，等待2分钟没反应再走下一步。
- ESXi命令行：通过SSH登录宿主机，执行
esxcli vm process list找到卡死的虚拟机World ID，然后运行esxcli vm process kill --type=force --world-id=ID强制终止迁移进程。 - 物理控制台：登录iDRAC或iLO，重启管理代理服务，执行
/etc/init.d/vpxa restart或services.sh restart，注意这个操作只重置管理通道，不中断VM运行。
死机后宿主机失联的兜底方案
如果迁移把宿主机的CPU或存储I/O吃满，连SSH都连不上，只能硬重启物理机，但有前提条件：
- 启动前在BIOS里确认CPU虚拟化技术（VT-x/AMD-V）保持开启。
- 进入系统后立刻检查虚拟机配置文件（.vmx）是否完整，
.vswp交换文件是否存在。 - 如果VM处于“已暂停”而不是“已停止”状态，用
vmware -q命令恢复运行。
行业共识是硬重启是最后手段,因为未写入磁盘的内存数据会丢失，但相比宿主机整体宕机，牺牲单台VM更划算。
迁移死机的常见原因排名与排查清单
多数情况下,死机不是虚拟机本身的问题，而是底层基础设施撑不住迁移动作，看下面这个优先级排查表格，按顺序做能节省大量时间。
| 排查项 | 具体表现 | 验证命令 | 解决方向 |
|---|---|---|---|
| 存储延迟 | 迁移进度条卡住，vCenter提示“Storage vMotion”超时 | esxtop按u查看存储设备延迟 |
检查存储链路、更换低速LUN |
| 网络丢包 | 热迁移速度极慢，中途反复回退 | ping -f宿主机管理IP检测丢包率 |
调整MTU、确认vMotion专用VLAN |
| CPU兼容性 | 迁移到新主机后蓝屏或不断重启 | 对比两台的CPU型号与微码 | 开启EVC模式、升级驱动 |
| 内存热插拔 | 迁移目标机内存配置冲突 | vmware -v查看版本信息 |
取消勾选“启用内存热插拔” |
存储延迟是迁移卡死的头号元凶
虚拟机迁移需要把内存和磁盘状态持续同步到目标节点,如果后端存储是机械硬盘RAID5阵列，或者NAS链路只跑千兆网，迁移时的写入瓶颈会直接拖垮响应时间。
推荐做法：迁移前先跑一轮存储性能测试，把4K随机写延迟压到20毫秒以内再动工，使用fio命令在本机做预测试：
fio --filename=/tmp/testfile --direct=1 --rw=randwrite --bs=4k --size=1G --numjobs=4 --runtime=30 --group_reporting当Average Latency超过50ms，不适合做在线迁移。
vMotion网络带宽不足引发的假死
相当一部分“死机”其实是vMotion流量挤占了业务带宽，如果物理网卡只有1Gbps，迁移一台64GB内存的虚拟机需要传输约64GB数据，耗时约9分钟，这期间网络稍有抖动就会导致迁移暂停。
加速方案：
- 给vMotion配置独立的10G网卡或双25G网卡绑定
- 启用VSS/VDS的“vMotion流量”标记，确保QoS优先
- 关闭巨型帧（Jumbo Frame）如果在交换机上没打通的配置，不如用标准MTU
CPU型号不一致导致迁移后系统蓝屏
跨代CPU迁移很常见,比如从Intel Haswell迁移到Skylake主机，如果没开启EVC（增强vMotion兼容性），虚拟机直接报GPF异常或蓝屏死机。
行业共识是EVC模式只能掩码CPU指令集,如果虚拟机已经装了旧驱动，掩码也救不了，所以日常工作要养成好习惯：新建虚拟机时选择兼容性模式为“ESXi 6.7及更高版本”，这样虚拟机不会依赖宿主机特定CPU特性。
死机后的虚拟机修复与数据拯救
迁移中断后,虚拟机配置文件可能进入锁定状态，表现为“无法打开虚拟机”或“文件已被锁定”。
解锁虚拟机配置文件
这招救急很常用,先解锁再启动，能避免很多启动失败问题。
在目标ESXi宿主机上执行：
vmkfstools -e /vmfs/volumes/datastore1/虚拟机名/虚拟机名.vmx输出Lock is held by host的话，手动删除.lck目录：
rm -rf /vmfs/volumes/datastore1/虚拟机名/虚拟机名.vmx.lck
再在Web界面尝试开机,如果还是卡在启动界面，把虚拟机的.vmdk文件挂载到另一台正常VM上，复制关键数据出来后重建VM。
磁盘一致性校验与快照回滚
迁移死机最怕磁盘元数据损坏,在VM能启动但文件读写异常的情况下，用以下操作顺序恢复：
- 登录VM后执行
fsck（Linux）或chkdsk /f（Windows），修复文件系统错误 - 检查VMware Tools是否响应，如果Tools图标变灰，重装Tools
- 如果系统连续重启,进VM的BIOS关闭“自动重启”功能，死循环会消耗宿主机更多资源
日常建议：给重要VM配置每夜快照策略，保留3天，迁移前手动打一个快照，出问题能直接回滚到几分钟前的状态。
实际没有死机，只是迁移后网络配置丢失
有时候虚拟机面板显示运行正常,但业务连不上，这是迁移后虚拟网卡MAC地址变化导致的。
排查方法：
- 在VM内执行
ip a或ipconfig /all，看IP地址是否为169.254开头 - 如果IP丢了,检查VMX文件里
ethernet0.addressType是否等于vpx生成的静态MAC - 重新挂载原网络端口组,把
ethernet0.generatedAddress设为FALSE并写死原MAC
招聘电商服务器怎么避免迁移死机？备好方案再动手
如果你们的业务是电商大促扩容,服务器迁移必须提前演练，这里说几个足以避免问题的前置准备步骤。
迁移前的环境体检报告
打快照、查延迟、看兼容性是铁三角，缺一个都别开工。
- 存储余量：目标数据存储至少留有源端虚拟机5倍大小的空间
- CPU类型：用
vim-cmd /hostsvc/hostsummary对比源和目标CPU型号 - 配置约束：不用开启内存热插拔、CPU热添加的VM迁移，这类VM迁移死机概率翻倍
分批迁移策略，别赌一把大的
涉及多台VM的场景,建议按业务优先级排序，先迁测试机，再迁非核心业务机，最后动数据库主节点，每批次间隔半小时，观察宿主机的CPU内存负载曲线。
- 如宿主机超过80%内存分配率，暂停下一批迁移
- 数据盘特别大的VM优先用Cold Migration，关机状态迁移最稳妥
- 配置不一的异构VM,统一在新平台重建配置再挂载旧磁盘
虚拟化专家教你判断迁移死机是硬伤还是软伤
硬伤指硬件层面的光路中断、控制器掉盘、内存故障；软伤主要指系统配置冲突。
硬伤特征
- 协处理器错误日志（MCE）大量刷屏
- 目标宿主机的RAID卡BBU（电池）失效，写缓存强制关闭
- 存储阵列端口光模块收发功率异常
这类问题要联系硬件厂商更换部件,单纯重启解决不了。
软伤特征
- 迁移到特定一台宿主机会死,换另一台就正常
- 卸载虚拟机声卡、USB控制器后再迁移就没问题
- VM里装的杀毒软件实时监控占用了超量内存
软伤可以进入单用户模式禁用冲突服务，或用干净启动排查，多数情况下，重装VMware Tools就能恢复兼容性。
虚拟机迁移死机如何快速处理？三个高频问题解答
迁移卡在99%不动，是死机了吗？
99%属于同步收尾阶段，数据正在做最终校验，需要先等待10-15分钟，如果超过半小时进度纹丝不动，用vCenter的“取消迁移”功能主动终止，然后检查目标主机是否能正常访问源存储，如果取消按钮灰色，通过SSH杀掉vmimport或vmfs相关进程即可。
强制关闭迁移进程会弄坏虚拟机磁盘吗？
根据虚拟机磁盘类型而定,使用精简置备（Thin Provisioning）的磁盘损坏概率较大，需要运行vmkfstools --fixcheck做一致性检查，厚置备磁盘的元数据结构简单，损坏概率较低，强制杀进程后应立刻为VM打一个新快照，作为恢复基线。
虚拟机迁移死机的常见原因怎么从系统日志里找？
登录宿主机的/var/log/vmkernel.log，搜索vMotion关键词，如果看到Fatal error related to storage I/O，说明存储超时；看到KMVMIH（Kernel Module VMknix Install Helper）报错，则和内存兼容性相关，Windows客户端日志则看系统日志里的Hyper-V-VMMS事件源，其中的Event ID 19502和12400分别指向配置问题与虚拟设备冲突。
迁移死机不可怕,怕的是病急乱投医式的反复重启，记住一个认知：先稳宿主机，再救虚拟机，最后查根因，这套顺序能保住你的业务数据，还能快速恢复生产，不管你是运维新手还是老手，把上面的操作步骤熟记在心，下次遇到虚拟机迁移死机，你就能像个专家一样从容解决。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/624852.html
