V2V 与它解决的问题
V2V 是在两个虚拟化平台之间搬运整台虚机，最常见的路线是 VMware 搬到 KVM 或云主机。工具负责机械性工作：磁盘格式转换（vmdk 转 qcow2）、虚拟硬件版本调整、引导方式重写，以及为 Linux 注入 virtio 驱动并重建 initramfs。实施方负责工具做不到的部分：网段与 MAC 变更后的适配、软件授权衔接、监控与备份代理重建。转换完成只是阶段成果，能开机且能承载业务才算迁移成功。
基本信息
| 适用平台 | 源端 VMware（vCenter/ESXi 或 OVA 包），目标端 KVM/libvirt 或云主机 |
|---|---|
| 常用工具 | virt-v2v（Linux 侧）、云厂商主机迁移服务（SMC/SMS 等） |
| 转换内容 | 磁盘格式、虚拟硬件版本、引导方式 |
| 适配内容 | virtio 驱动、网卡命名规则、IP 与 MAC 变化 |
| 验证内容 | 开机自检、服务端口、业务抽检、性能基线 |
| 前置条件 | 目标侧 KVM/libvirt 环境就绪，临时空间约为磁盘实际占用量的两倍 |
典型使用场景
- 私有云 VMware 集群整体搬到 KVM 或 OpenStack 系平台
- 本地虚机搬到云主机，用主机迁移服务做在线增量搬运
- 把 OVA 模板转成 KVM 可用镜像，纳入统一镜像库
- 并购或整合后的资源归并：把两个虚拟化平台收敛成一套
- 为测试环境做平台无关的镜像转换，验证业务对 virtio 与网卡命名的兼容性
virt-v2v 转换与验证
virt-v2v 转换与验证
virt-v2v -i ova /data/ova/app.ova -o libvirt -os default -of qcow2 # 转换 OVA 到本地 libvirt
virt-v2v -ic vpx://user@vcenter/DC?no_verify=1 -o libvirt -of qcow2 app-vm # 直连 vCenter 搬指定虚机
sudo virsh define /etc/libvirt/qemu/app-converted.xml # 注册转换生成的域定义
sudo virsh start app-converted # 首次启动并观察引导
guess 2>/dev/null; virt-cat -a app-converted.qcow2 /etc/fstab | head # 检查挂载与磁盘对应
virsh dominfo app-converted | grep -E 'State|CPU|Max memory' # 核对规格是否与源端一致转换前后的风险点
| 项目 | 转换前后差异 | 风险与应对 |
|---|---|---|
| 网卡与 MAC | 网卡型号与 MAC 地址都会变 | 客户端白名单、软件授权与静态 IP 绑定会失效，需重新申请或改配置 |
| 引导方式 | 源端 UEFI 被按 BIOS 引导时启动失败 | 转换时保持固件类型一致，必要时手工重建引导记录 |
| 磁盘控制器 | IDE/SCSI 换成 virtio | 镜像不含 virtio 驱动会进不了系统，Linux 需重建 initramfs |
| 磁盘格式 | vmdk 转 qcow2 或 raw | 转换后核对实际占用与容量，瘦盘与置备类型要符合目标侧策略 |
| 规格与硬件 | CPU 型号、内存与 device 配置变化 | 授权按 CPU 或核心数计费的产品需重新评估 |
转换耗时与磁盘实际占用量成正比，和虚机标记容量关系不大；迁移窗口按实际用量估算，并预留转换失败重试的一次余地。
转换后的虚机首次启动前建议先把源虚机做成快照或克隆保底：转换产物引导失败时，源端仍在，可以重来一次而不影响业务。