跳转至

从 VMware 迁移

迁移的目标不是把 VMDK 换成 qcow2 就结束，而是让业务在 KVM/OpenNebula 上具备可验证、可运维、可回退的运行状态。

OpenNebula 为什么能作为 VMware 替代方案

OpenNebula 使用 KVM 和通用 Linux 基础设施构建私有云，提供 VMware 环境常见的资源池、模板、虚拟网络、数据存储、多租户、调度和高可用管理能力。官方 OneSwap 工具可从 vCenter 发现 VM，转换虚拟磁盘，并生成对应的 OpenNebula Image 和 VM Template；也支持导入 OVA/VMDK。

但“功能表里都有”不代表迁移没有差异。VMware 的分布式交换、存储策略、备份插件、监控、HA/DRS 规则和运维习惯都需要重新映射。

先做迁移盘点

每台 VM 至少记录：

类别 需要收集的内容
业务 负责人、重要级别、维护窗口、RTO/RPO、上下游依赖
计算 vCPU、内存、CPU 特性、NUMA、直通设备
启动 BIOS/UEFI、Secure Boot、TPM、操作系统版本
磁盘 数量、容量、格式、快照、精简置备、实际使用量
网络 vNIC、端口组、VLAN、IP、网关、防火墙、负载均衡
客户机 VMware Tools、VirtIO 驱动、QEMU Guest Agent、固定网卡命名
数据保护 备份产品、恢复点、数据库一致性和回退方式
许可 Windows、数据库、中间件以及与虚拟硬件绑定的许可

优先迁移无直通设备、无特殊许可、停机窗口明确、业务负责人能配合验证的普通 Linux VM。数据库、域控、核心中间件和大容量 VM 不适合作为第一批。

OneSwap 做了什么

vCenter / ESXi
    ↓ 读取 VM 配置和磁盘
OneSwap 转换主机
    ├─ virt-v2v / qemu-img 转换磁盘
    ├─ 处理 VirtIO、Context 和 VMware Tools
    └─ 生成 OpenNebula Image + VM Template
          ↓
OpenNebula KVM Cluster

大批量迁移时建议使用独立转换主机。它需要同时连通 vCenter/ESXi、OpenNebula Front-end 和目标 Datastore，并准备足够的工作目录空间。转换期间可能同时存在源盘、临时盘和目标镜像，不能只按 VM 已用空间估算。

三种迁移思路

方式 特点 使用前提
关机转换 流程最简单，源 VM 关机后完整转换 能接受较长停机窗口，无残留快照
Clone 模式 转换 vCenter 中的关机克隆，原 VM 可继续运行 源 VM 满足克隆条件，最终数据仍需同步或割接
Delta 模式 先传基础磁盘，最终停机同步增量 环境满足官方要求，必须通过专项验证

低停机不等于零风险。数据库和持续写入业务还需应用级复制、停写、最终同步或其他专用迁移方案。

标准迁移流程

1. 建立映射表

将 VMware 对象对应到 OpenNebula：

vSphere Cluster / Resource Pool → OpenNebula Cluster / 调度策略
Datastore                         → Image/System Datastore
Port Group / VLAN                 → Virtual Network
VM Template                       → Image + VM Template + Context
Role / Folder                     → Group + ACL + Quota
HA / DRS Rule                     → VM HA + Scheduler 策略

2. 完成目标平台基线

先验证 KVM Host、存储、VNet、DNS、NTP、备份、监控和权限。不要边搭平台边迁移生产 VM，否则出现问题时无法判断是目标平台故障还是转换问题。

3. 执行兼容性预检

  • 确认目标 Datastore 和转换工作目录空间。
  • 清理或合并不支持的 VMware 快照。
  • 验证 Linux initramfs 内含 VirtIO 驱动；Windows 准备对应驱动。
  • 检查 BIOS/UEFI、Secure Boot、磁盘控制器和网卡型号。
  • 确认目标 VNet 与源端口组/VLAN 的映射。
  • 为静态 IP、网卡名称、MAC 绑定和软件许可制定处理方式。

4. 小批量试迁

先迁 1～3 台代表性 VM，记录转换速度、临时空间、启动修复和业务验证时间。修订操作手册后再扩大批次。

5. 正式割接

  1. 冻结源 VM 配置变更。
  2. 完成并验证最后一次备份。
  3. 按方案停写、关机或同步增量。
  4. 转换并导入目标 Image/Template。
  5. 在隔离网络首次启动，检查磁盘、网卡、时间和服务。
  6. 切换生产网络、DNS、负载均衡或路由。
  7. 由业务负责人执行验收，而不只是确认“能 ping 通”。

6. 保留回退

在观察期内不要删除源 VM 和原备份。若需要回退，先关闭目标 VM 或阻止写入，避免源、目标两边同时提供写服务造成数据分叉。

迁移后检查

lsblk
ip -br addr
ip route
timedatectl
systemctl --failed
journalctl -b -p warning

还要验证应用端口、数据库一致性、监控、日志、备份、定时任务、许可证、性能基线和重启后的自动恢复。

不应直接迁移的情况

  • 强依赖 VMware 专用虚拟硬件、直通设备或第三方插件。
  • 旧操作系统缺少 KVM/VirtIO 支持且无法维护。
  • 超大数据库只能接受极短中断，但没有数据同步方案。
  • 软件许可与 ESXi 主机、虚拟硬件 UUID 或 CPU 强绑定。
  • 无业务负责人、无恢复备份、无测试窗口。

此类工作负载应先改造、重建、使用应用级迁移，或暂时保留在原平台，而不是强行批量转换。

官方参考：OneSwap、OVA/VMDK 导入。