计算虚拟机迁移要做到业务不中断，核心是把迁移拆成“资源预检数据同步流量切换业务验证可回滚”五段，每一段都留可观测、可暂停、可退回的硬开关。 计算迁移从来不是点一下“迁移”按钮，而是边营业边换店面,功夫在按钮之外。
虚拟机在线迁移如何保证业务不中断？先解决三个硬条件
计算资源与CPU兼容性先对齐
在线迁移的第一步不是迁，而是确认目标宿主机接得住，CPU型号不同、BIOS特性开启不一致、大页内存配置不同，都可能让迁移在最后阶段失败，实操中用virsh cpu-compare对比源宿主机和目标宿主机能力，用virsh dominfo、virsh domblklist、virsh domiflist把虚拟机磁盘和网卡摸清，目标端预留内存不能只看当前占用，要给热迁移内存迭代留余量，生产环境里，迁移带宽用virsh migrate-setspeed限速,避免把存储和业务网络打满。
存储通道和网络路径不能临时补课
计算迁移常伴随存储迁移，共享存储场景相对简单，非共享存储要提前做块复制或快照同步，检查多路径用multipath -ll，检查MTU可用ping -M do -s 1472 <目标IP>，避免迁移后大包不通，网络侧提前确认安全组、ACL、ARP缓存、VIP漂移权限和负载均衡健康检查路径。很多迁移后的“业务异常”不是虚拟机没起来，而是网络路径和会话保持没接上，据统计,这类配置类问题在计划内迁移中占相当一部分。
迁移前把“可回滚”做成默认配置
- 源虚拟机保留到业务稳定运行一个完整业务周期后再清理。
- 迁移前做应用一致性快照，文件系统可用
fsfreeze -f /mountpoint冻结后打快照，再fsfreeze -u解冻。 - DNS TTL提前调低，负载均衡权重可逐步切,不要一次性全量。
- 准备回退脚本：VIP回漂、DNS回切、负载均衡权重归零、应用连接池重启。
同城双活和跨地域迁移方案对比：停机窗口与回退成本
| 迁移方式 | 业务中断 | 数据一致性风险 | 适用场景 | 回退难度 |
|---|---|---|---|---|
| 冷迁移 | 分钟级到小时级 | 低，停机复制 | 非核心、可停业务 | 低 |
| 热迁移 | 秒级到分钟级 | 中，依赖内存迭代 | 同集群、共享存储 | 中 |
| 存储复制加流量切换 | 秒级到分钟级 | 中，需追平复制延迟 | 跨机房、同城 | 中高 |
| 双活加灰度切换 | 接近无感 | 高，需应用配合 | 核心在线业务 | 高 |
行业共识认为，同城双活更适合低时延的在线切换，跨地域迁移要先接受RPO和RTO约束，再谈业务不中断，计算虚拟机迁移最怕把计算、存储、网络三件事混成一个动作,拆开做才有刹车。
把迁移拆成五段：从预检到流量切换的实操路径
预检：用命令和监控把未知项压到最低
- 监控基线：CPU就绪时间、内存脏页速率、磁盘IO延迟、网络丢包和重传。
- 时间同步：
chronyc tracking确认时钟偏差,迁移后时钟漂移会坑数据库和证书。 - 驱动与内核：确认virtio驱动、多路径软件、安全Agent在目标端可用。
- 许可证：绑定MAC、绑定磁盘序列号、加密卡和HSM的设备映射要提前登记。
数据同步：块复制、快照和应用一致性
计算在线迁移靠内存预拷贝和脏页迭代，业务写入越猛，收敛越慢，对写密集型虚拟机，迁移窗口要避开批处理和备份任务，数据库不要只靠文件系统快照，MySQL可用主从复制追平后切VIP，切换前执行SET GLOBAL read_only=ON;，确认SHOW REPLICA STATUS无延迟再切，Redis集群用槽迁移，消息队列先停生产再迁消费者。迁移不是备份，源端快照和备份链要独立保留。
流量切换：DNS、VIP、负载均衡拆开操作
- DNS先改TTL到较短值,切换时先改记录再观察解析生效。
- VIP用Keepalived或云负载均衡漂移,健康检查路径要能反映真实业务。
- 负载均衡权重从0到10到50再到100,逐级观察错误率和延迟。
- 有状态服务先禁止新会话进入，再切老会话,最后回收旧节点。
业务验证与回滚：看业务指标不看ping
迁移后先跑拨测：登录、下单、支付、查询链路，看APM事务成功率、日志错误量、数据库连接数、缓存命中率，回滚触发条件提前写死，例如核心接口错误率持续升高、数据库复制中断、VIP漂移失败。回滚不是失败，是迁移方案的一部分。
分批节奏：先无状态后有状态，先边缘后核心
不少团队会顺带问虚拟机迁移服务收费模式，常见报价按虚拟机数量、数据量、割接次数、是否含数据库和回退演练拆分，单看单台单价容易误判，北京地区企业做同城机房迁移时，最好要求服务方把现场值守、演练次数和回退责任写进清单，否则低价方案容易在割接夜变成加钱项，迁移顺序建议是无状态Web、中间件、缓存、数据库、核心账务,每批留观察窗口。
金融行业虚拟机不停机迁移场景：从无状态到核心库的分批策略
金融行业对审计、双人复核和变更窗口要求更严，无状态应用可以热迁移加负载均衡灰度；中间件先摘节点再迁；缓存做槽迁移；数据库用主从加VIP切换，业内专家指出，迁移窗口不是越短越好，越短越依赖前期演练和自动化回退，核心库切换要确认GTID追平、应用重连、对账任务恢复,涉及加密机和HSM的虚拟机还要验证设备直通和密钥可用性。
迁移完成的标准不是虚拟机启动，而是业务稳定跑完一个周期
迁移不中断不是某个命令的功劳，而是预检、复制、切换、验证、回滚五段都留了刹车，把源机和快照保留到业务稳定运行一个完整业务周期后再清理,才算真正完成。
计算虚拟机迁移业务不中断常见问答
虚拟机迁移时数据库一定要停机吗？
不一定，主从复制加VIP切换可以把中断压到秒级，但前提是复制延迟可控、应用支持重连、切换后有一致性校验，强一致核心库仍建议保留短维护窗口，并把只读切换、追平确认、回退动作写成清单。
同城双活和跨地域迁移方案对比，哪个更适合业务不中断？
同城双活时延低，适合在线流量灰度切换；跨地域迁移受限于复制延迟和链路质量，更适合容灾和分批迁移，先做同城在线切换，再评估跨地域,回退路径会更清晰。
虚拟机迁移服务收费模式怎么判断是否合理？
看报价是否拆出虚拟机数量、数据量、割接次数、数据库复杂度、演练和现场值守，要求服务方列明回退责任人、回退时限和验收指标，报价单里没有割接清单、演练次数和回退责任人的方案,不具备可比性。