当前位置：首页 > 物理机 > 正文

kvm物理机迁移

KVM物理机迁移需先停机，完整备份数据；迁移时同步存储、网络等配置，保障系统环境一致；迁移后测试验证，确保业务正常，实现高效

KVM（Kernel-based Virtual Machine）作为主流的开源虚拟化技术，其物理机迁移是企业IT运维中的关键场景，主要用于应对硬件更新换代、数据中心扩容、灾备建设或业务连续性保障等需求，以下从迁移背景与核心目标、前期准备要点、典型迁移方案及操作流程、关键注意事项四个维度展开详述,并附实践参考表格与常见问题解答。

迁移背景与核心目标

物理机迁移的本质是将运行中的KVM虚拟机及其关联资源（如磁盘镜像、网络配置、元数据）从源物理服务器完整转移至目标物理服务器，最终实现业务的无缝切换或平滑过渡，常见触发场景包括：
硬件生命周期管理：旧服务器因老化需替换为新设备；
资源优化：将低利用率的物理机集中至高性能服务器以提升整体效率；
容灾备份：构建异地/异构平台的冗余架构，降低单点故障风险；
架构调整：适配云化转型需求，将本地物理机纳入私有云资源池统一调度。

核心目标可归纳为三点：① 数据完整性（无丢失、无损坏）；② 业务连续性（最小化停机时间）；③ 环境一致性（迁移后虚拟机行为与原环境一致）。

kvm物理机迁移 第1张

前期准备要点

成功的迁移依赖于充分的预评估与资源协调,以下是关键准备事项及对应操作示例：

准备项 执行建议
环境调研 确认源/目标物理机的CPU架构（x86_64/ARM）、固件版本（BIOS/UEFI）、网卡型号、存储接口（SAS/SATA/NVMe）是否兼容 若跨架构迁移（如x86→ARM），需提前验证Guest OS对目标架构的支持性
数据备份 对源物理机上的虚拟机磁盘（qcow2/raw格式）、配置文件（/etc/libvirt/）、日志文件进行全量备份 推荐使用virsh vol-backup命令或第三方工具（如Clonezilla）完成块级备份
网络规划 统一源/目标物理机的IP网段、VLAN ID、网关及DNS解析记录，确保迁移后虚拟机网络可达 可通过静态路由或DHCP预留地址池实现网络互通
存储映射 定义目标物理机的存储路径（如/dev/mapper/volume-group），并与源存储建立挂载关系 优先选择支持iSCSI/FC协议的共享存储，避免直接复制本地磁盘导致的IO瓶颈
权限与认证 确保执行迁移的用户具备源/目标物理机的root权限，且两台机器可通过SSH免密登录 生成SSH密钥对并分发至两台机器，测试ssh user@target_ip能否直接登录
工具链验证 检查virsh、libguestfs、rsync等工具的版本一致性，必要时升级至最新稳定版 执行virsh --version对比源/目标端的QEMU版本号，差异过大可能导致指令不兼容

典型迁移方案及操作流程

根据业务对停机时间的容忍度，可分为冷迁移（停机迁移）和热迁移（在线迁移）两类方案,实际操作需结合具体场景选择。

方案1：冷迁移（适用于非实时业务）

冷迁移需暂停虚拟机运行，适合维护窗口期内的操作，步骤如下：

  1. 停用虚拟机：通过virsh suspend <vm-name>暂停虚拟机，记录当前状态；
  2. 复制磁盘文件：使用rsync -avzP /var/lib/libvirt/images/<disk>.qcow2 user@target_host:/var/lib/libvirt/images/同步磁盘镜像；
  3. 迁移元数据：复制/etc/libvirt/qemu/<vm-name>.xml配置文件至目标主机，并通过virsh define <xml-file>重新定义虚拟机；
  4. 校验启动：在目标主机执行virsh start <vm-name>，观察控制台输出是否正常；
  5. 清理残留：删除源主机上的临时文件（如/run/libvirt/），更新DNS指向目标主机IP。

方案2：热迁移（Live Migration，适用于高可用场景）

热迁移可在不中断业务的前提下完成迁移，依赖共享存储实现磁盘实时同步，操作步骤更复杂但停机时间趋近于0：

  1. 启用共享存储：在源/目标主机挂载同一LUN（如iSCSI卷），格式化为ext4/XFS文件系统；
  2. 启动迁移命令：在源主机执行virsh migrate --live <vm-name> qemu+ssh://target_host/system，其中qemu+ssh表示通过网络隧道传输内存页；
  3. 监控迁移进度：通过virsh domjobinfo <vm-name>查看总进度（Total）、已完成量（Data processed）及剩余时间（ETA）；
  4. 自动切换流量：迁移完成后，虚拟机会自动切换至目标主机运行，原主机解除对该VM的管理权；
  5. 验证功能：测试网络连通性（ping外部节点）、应用响应（如Web服务访问）、存储读写（dd测试）。

两种方案对比表：

维度 冷迁移 热迁移
停机时间 较长（分钟级~小时级） 极短（秒级，仅首次切换时短暂停顿）
依赖条件 无需共享存储 必须使用共享存储
适用场景 定期维护、非关键业务 生产环境、7×24小时运行的业务
复杂度 低（手动操作为主） 高（需提前配置共享存储+网络）
风险点 人为操作失误导致数据丢失 网络抖动/带宽不足引发迁移失败

关键注意事项

  1. 版本兼容性：源/目标物理机的QEMU版本差异超过2个小版本时，可能出现指令解析错误，建议升级至同一主版本（如均为QEMU 8.x）；
  2. 存储性能匹配：目标存储的IOPS、吞吐量需不低于源存储，否则可能导致迁移后虚拟机卡顿；
  3. 内存压力：热迁移过程中会占用额外内存（约为虚拟机内存的1.5倍），需确保目标主机有足够的空闲内存；
  4. 防火墙策略：开放源/目标主机间的TCP 49152-49216端口（默认迁移端口），避免防火墙拦截导致连接中断；
  5. 日志审计：迁移前后分别导出journalctl -u libvirtd日志，便于排查“虚拟机无法启动”“网络不通”等问题。

相关问答FAQs

Q1：迁移后虚拟机无法联网，可能是什么原因？
A：常见原因包括：① 目标主机未配置相同的VLAN标签或桥接模式；② 虚拟机网卡类型（virtio/e1000）与目标主机驱动不兼容；③ DNS解析未更新至目标主机IP，解决方法：检查brctl show确认网桥状态，尝试更换网卡类型（virsh edit <vm-name>修改 为），并在DNS服务器更新A记录。

Q2：热迁移过程中提示“Error: Unable to get migration capabilities”，如何处理？
A：此错误通常由以下原因导致：① 源/目标主机的QEMU版本不一致；② 未启用目标主机的libvirtd服务；③ 共享存储未正确挂载，排查步骤：① 执行virsh nodedev-list确认双方可见相同的存储设备；② 重启目标主机的libvirtd服务（systemctl restart libvirtd）；③ 统一升级QEMU至相同版本（如通过包管理器安装`qemu-kvm=8

KVM物理机
0

相关文章