KVM热迁移核心是迁移运行时状态而非磁盘文件，依赖共享存储（如NFS、iSCSI、Ceph）使源和目标宿主机同时访问同一磁盘，通过迭代同步内存脏页，最终毫秒级停机完成CPU、内存、设备状态切换。
跨宿主机迁移虚拟磁盘且不中断服务，核心在于不移动磁盘文件本身，而是让源和目标宿主机同时访问同一份磁盘数据——即依赖共享存储。真正的“热迁移”（如 kvm live migration、vsphere vmotion、hyper-v live migration）迁移的是运行时状态（内存、cpu、设备），磁盘始终留在原处或同步映射到共享位置。
必须用共享存储作为基础
虚拟机磁盘文件（如 qcow2、vmdk、raw）不能靠 scp/rsync 边复制边运行，否则会丢数据、损坏一致性。要不停机，就得让两台宿主机都能实时读写同一块“磁盘”。常见方式包括：
- NFS 或 SMB 共享目录：将磁盘文件放在 NFS 服务器上，两台宿主机都挂载同一路径（注意开启 sync、noac 等严格一致性选项）
- iSCSI 或 FC 存储：通过 LUN 映射，使两台宿主机看到同一个块设备，再由虚拟化层（如 libvirt/QEMU、ESXi）直接使用该设备
- 分布式存储系统：如 Ceph RBD、Sheepdog、OpenEBS，提供块/镜像级的高可用共享访问能力，天然适配热迁移
迁移过程只传运行状态，不传磁盘文件
当磁盘已位于共享位置后，热迁移实际执行的是以下动作：
- 在目标宿主机上预创建一个空的虚拟机实例（配置一致，但不启动）
- 开始多轮内存脏页预拷贝：把源 VM 的内存页发过去，同时监控哪些页又被修改（脏页），反复传输直到剩余脏页极少
- 短暂暂停源 VM（通常
- 在目标宿主机立即恢复运行，接管同一块共享磁盘上的数据
整个过程用户几乎无感，磁盘 I/O 始终由共享存储响应，未发生文件复制。
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
没有共享存储怎么办？也有可行方案
若受限于环境无法部署共享存储，仍可实现近似“不停机”的迁移，但需额外机制保障一致性：
- Storage vMotion（vSphere）：支持非共享存储下的磁盘在线迁移。它边运行虚拟机，边后台将磁盘文件从本地迁移到目标存储，同时保持 I/O 重定向，最终切换句柄。要求 vCenter 和 ESXi 版本支持，且目标存储需可达
- KVM 非共享热迁移（QEMU 4.0+）：通过 -incoming 参数配合 migrate_set_downtime 和 migrate_set_speed 控制，QEMU 可在迁移内存的同时，异步拉取磁盘镜像（需目标端有足够空间）。但对网络带宽和磁盘性能要求极高，生产环境慎用
- 应用层双写 + 切流：适用于数据库或有状态服务。先在目标虚拟机部署相同应用并接入同一套后端（如共享 DB、对象存储），待数据追平后，通过负载均衡切走流量，再关停源 VM —— 这不是虚拟机迁移，而是业务级迁移，但效果等效
关键注意事项
即使技术可行，忽略这些细节仍会导致失败或中断：
- CPU 指令集需兼容：源/目标宿主机的 CPU 型号或 flag 差异过大时，目标端可能无法加载虚拟机上下文，需在 XML 或 VM 设置中启用 CPU 模式（如 libvirt 的 mode='host-passthrough' 或 mode='custom'）
- 网络延迟影响迁移时间：万兆专用迁移网络能显著缩短脏页同步轮次，降低停机窗口；千兆网下大内存 VM 容易超时失败
- 磁盘缓存策略必须为 writethrough 或 none：避免源端缓存未刷盘导致目标端读到旧数据，尤其在 NFS 场景下极易出问题
- 迁移前检查 MAC 地址与 IP 冲突：若虚拟机使用静态 IP，目标网络中已有同 IP 设备，会导致通信异常，建议改用 DHCP 或提前规划网络段
