KVM虚拟机迁移方案主要有冷迁移、热迁移、基于共享存储的迁移和快照迁移；如果追求绝对安全稳定，首选冷迁移，只要停机时间能接受，它永远是最不容易翻车的方案。
很多人第一次接触KVM迁移，心里第一反应是“直接拷文件不就行了”，这话对了一半，但怎么拷、什么时候拷、拷完怎么让虚拟机认新环境，背后都有讲究，下面按我自己的运维经验,把常见方案摊开讲清楚。
kvm虚拟机迁移方案有哪些？先分清冷迁移和热迁移
KVM虚拟机迁移，本质上把虚拟机的CPU内存状态、磁盘数据、虚拟硬件配置从一台物理机搬到另一台，根据业务是否中断，业界把它们分成两大类：冷迁移和热迁移（在线迁移）。
冷迁移也叫静态迁移，操作窗口内虚拟机是关机状态，数据一次性复制，没有并发写入问题，热迁移则依靠KVM自带的live migration机制，让虚拟机在迁移过程中保持开机,业务几乎不停。
这两种方案还能再往下细分：
- 冷迁移：直接拷贝磁盘文件加配置文件，适合测试环境、允许计划停机的生产环境。
- 热迁移（预拷贝）：先把内存页循环同步到目标机，最后短暂切换,是KVM默认的在线迁移方式。
- 热迁移（后拷贝）：先传CPU和内存的最小上下文，再逐步拉取剩余内存，对带宽压力小,但性能损耗大。
- 基于共享存储的迁移：磁盘数据放在NFS、GlusterFS或SAN上，迁移时只需同步CPU和内存状态,磁盘无需复制。
- 基于块设备复制的迁移：用drbd或分布式存储做底层同步，再配合virsh migrate完成切换。
kvm冷迁移和热迁移区别对比
我用一张表直接说清差别，这也是百度上搜“kvm冷迁移和热迁移区别”最常见的答案。
| 对比项 | 冷迁移 | 热迁移 |
|---|---|---|
| 虚拟机状态 | 关机 | 开机 |
| 业务中断时间 | 分钟到小时 | 秒级 |
| 数据一致性风险 | 极低 | 中等，依赖网络和存储 |
| 对网络要求 | 低 | 高，需要专用网络 |
| 配置复杂度 | 低 | 高 |
| 适用场景 | 可计划停机 | 关键业务、7×24小时服务 |
冷迁移是“老老实实搬文件”，热迁移是“空中换引擎”，多数情况下，冷迁移更让人放心，因为每个步骤都能验证，出了问题能回滚，热迁移一旦内存脏页速率超过网络传输速率，就可能越迁越慢,最后卡死。
最安全稳定的方案：离线冷迁移实操步骤
如果你问我哪种方案最安全稳定，我的答案是离线冷迁移，原因很简单：虚拟机处于关机状态，磁盘数据固定不变,不存在两个物理机同时写同一份文件的情况。
业内专家指出，生产环境里相当一部分迁移事故发生在热迁移过程中，冷迁移只要按步骤来,几乎不会出问题。
冷迁移前要确认的三件事
动手之前，别急着敲命令,先确认以下三点：
- 目标主机上KVM版本和libvirt版本最好与源主机一致,否则配置文件可能无法识别。
- 虚拟机磁盘文件格式要明确，qcow2和raw的迁移方式略有不同，qcow2自带快照链,拷贝时可能需要合并。
- 目标主机的CPU型号要兼容，如果源虚拟机配置了
host-passthrough模式,目标CPU必须支持相同指令集。
冷迁移完整命令流程
假设源主机IP是192.168.1.10，目标主机是192.168.1.11,虚拟机名叫web01。
先在源主机上查看虚拟机的磁盘路径和配置文件：
virsh list --all
virsh dumpxml web01 > /tmp/web01.xml
virsh domblklist web01然后正常关机,不要用destroy强制断电：
virsh shutdown web01关机后用rsync把磁盘镜像传到目标机，注意，这里要等虚拟机完全关机,再检查进程是否退出：
ps aux | grep web01
rsync -avP /var/lib/libvirt/images/web01.qcow2 root@192.168.1.11:/var/lib/libvirt/images/磁盘传完后，把XML配置文件也传过去，但需要改动里面的磁盘路径和mac地址（如果目标机有冲突）：
scp /tmp/web01.xml root@192.168.1.11:/tmp/登录目标主机,用新配置定义虚拟机并启动：
virsh define /tmp/web01.xml
virsh list --all
virsh start web01最后在源主机上删除原虚拟机定义,避免两边的脏数据：
virsh undefine web01 --remove-all-storage这一套流程下来，虚拟机就稳稳当当地搬过去了。核心要点是：先拷贝磁盘，再定义配置，最后启动验证,顺序不能乱。
业务不能停？热迁移选型与风险控制
很多生产环境不允许关机，那就必须用热迁移，但热迁移不是“一键搬走”,它对底层的依赖比冷迁移多得多。
共享存储是热迁移的安全底座
行业共识认为，不基于共享存储的热迁移只能算“半迁移”，因为KVM的live migration默认要求磁盘文件是双方都能访问的，如果磁盘在本地，迁移时还得额外同步磁盘文件,既慢又不安全。
搭建共享存储最常用的方式是NFS,在存储服务器上导出目录：
echo "/data/images 192.168.1.0/24(rw,sync,no_root_squash)" >> /etc/exports
exportfs -r源和目标主机都挂载同一个NFS路径：
mount -t nfs 192.168.1.20:/data/images /var/lib/libvirt/images把虚拟机的磁盘文件放到共享存储上，然后源和目标主机的libvirt都指向这个路径，这样迁移时不需要传磁盘,只需传内存页和CPU状态。
用virsh migrate做在线迁移的注意事项
挂好共享存储后,用下面命令发起在线迁移：
virsh migrate --live web01 qemu+ssh://root@192.168.1.11/system tcp://0.0.0.0这里--live指定热迁移，tcp是数据通道，实际操作中，建议把迁移数据走独立网段，不要和业务流量混在一起,否则业务高峰时很容易把带宽占满。
迁移前还需要检查几个关键项：
- 目标主机的CPU型号，可以在源主机上执行
virsh capabilities查看,尽量保持一致。 - libvirtd版本差距过大时，迁移协议可能不兼容,需要两边升级到相同版本。
- 内存脏页速度，可以用
virsh migrate --live --timeout 30 web01 ...设置超时,如果30秒没完成就自动取消。
热迁移最怕的情况是虚拟机内存写入太快，迁移循环永远赶不上，这种情况下，要么降低虚拟机负载,要么改用后拷贝模式：
virsh migrate --live --postcopy web01 qemu+ssh://root@192.168.1.11/system后拷贝先把CPU和最小内存状态传过去，业务跑起来后再同步剩余内存，对带宽要求低，但目标机如果掉电，内存数据就全丢了,所以不建议对核心数据库用。
Q&A：kvm虚拟机迁移方案常见疑问
kvm冷迁移后虚拟机启动失败怎么办？
多数原因是磁盘路径或XML配置里的UUID冲突，先检查virsh list --all里是否有同名虚拟机，再用virsh edit修改磁盘路径，最后确认目标主机的SELinux上下文，执行restorecon -R /var/lib/libvirt/images，如果还是起不来，看/var/log/libvirt/qemu下的日志,里面会明确报错。
kvm热迁移需要多大带宽？
没有固定值，但迁移过程中虚拟机产生的内存脏页速率必须小于网络传输速率，普通的千兆网络很难支撑高负载虚拟机的热迁移，建议在虚拟交换机端口配置拥塞控制，或者直接使用万兆网卡，实测中，空闲虚拟机在千兆环境下迁移速度尚可，一旦业务流量上去,迁移时间会指数级拉长。
共享存储和本地存储迁移选哪个？
共享存储迁移是首选，因为磁盘文件在迁移前后是同一个位置，不存在同步失效的问题，本地存储迁移需要手动拷贝磁盘，还要保证数据完整性，适合测试或一次性迁机，据红帽官方文档建议，生产环境在线迁移一律使用共享存储,本地存储只用于离线迁移。
回到最初的问题：KVM虚拟机迁移方案有哪些？最安全稳定的还是冷迁移。 如果能接受短暂停机，就老老实实关机拷贝；如果业务不许停，那就做好共享存储和高带宽网络，再上热迁移，无论选哪种，迁移前备份配置、迁移后验证业务,永远是最保命的底线。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/624581.html
