15000 台虚拟机、23 个月 —— 一家 Fortune 500 公司如何彻底告别 VMware

预计阅读时间：9 分钟

Broadcom 收购 VMware 后，许可模式从永久授权转向订阅制，大量企业面临成本骤增的现实。一位 Reddit 用户在 r/sysadmin 分享了其 Fortune 500 公司用 23 个月完成 15000 台虚拟机迁移的全过程，选择 OpenShift 承载 Linux 工作负载、Hyper-V 承载 Windows 工作负载。这不是一家小公司的冒险，而是大规模生产环境的硬核替换——每一步都有真实踩坑。

为什么是 OpenShift + Hyper-V，而不是"另一个 VMware"

迁移的核心决策不是找另一个全栈虚拟化平台，而是按工作负载类型拆分目标平台：

Linux 工作负载 → OpenShift（虚拟化）：大量 Linux VM 本质上是跑单一服务的容器宿主机，迁移到 OpenShift Virtualization（基于 KubeVirt）后，部分可以直接容器化，部分保留 VM 形态但获得 Kubernetes 的调度、监控和运维能力。
Windows 工作负载 → Hyper-V：Windows 在微软自家虚拟化平台上兼容性最好，驱动、补丁、集群行为都经过充分验证，迁移风险最低。

这个组合的关键优势：不再依赖单一厂商的全栈锁定。OpenShift 底层是开源的 Kubernetes + KubeVirt，Hyper-V 是 Windows Server 自带功能，两者都有成熟的生态和退出路径。

迁移前的摸底：你必须先回答的三个问题

15000 台 VM 不是一口气搬完的。原文作者强调，迁移前必须完成精确的资产摸底：

每台 VM 的 OS 版本、应用依赖、数据盘大小——决定它去 OpenShift 还是 Hyper-V，以及迁移方式。
哪些 VM 可以容器化，哪些必须保留 VM 形态——容器化意味着更小的迁移单元和更高的资源利用率。
备份和灾备方案是否已在新平台验证——原文提到备份方案是迁移中重新设计的重点环节。

下面是一个用 Ansible 自动采集 VMware VM 资产信息的示例，可以直接改造用于摸底阶段：

# inventory_vmware.yml — 从 vCenter 批量采集 VM 信息
- name: Gather VMware VM inventory for migration planning
  hosts: localhost
  vars:
    vcenter_hostname: "vcenter.corp.example.com"
    vcenter_username: "admin@corp.local"
    vcenter_password: "{{ vault_vcenter_password }}"
    datacenter_name: "DC-Prod"
  collections:
    - community.vmware
  tasks:
    - name: Collect VM facts from vCenter
      community.vmware.vmware_vm_info:
        hostname: "{{ vcenter_hostname }}"
        username: "{{ vcenter_username }}"
        password: "{{ vcenter_password }}"
        datacenter: "{{ datacenter_name }}"
        validate_certs: false
      register: vm_facts

    - name: Build migration target mapping
      ansible.builtin.set_fact:
        migration_map: "{{ vm_facts.virtual_machines | map('regex_replace', '(.*)', '') }}"

    - name: Write CSV report for planning
      ansible.builtin.copy:
        content: |
          VM Name,OS,CPUs,Memory(MB),Disk(GB),Target Platform
          {% for vm in vm_facts.virtual_machines %}
          {{ vm.guest_name }},
          {{ vm.guest_fullname }},
          {{ vm.cpu_count }},
          {{ vm.memory_size_mb }},
          {{ vm.total_disk_size_gb }},
          {% if 'Linux' in vm.guest_fullname %}OpenShift{% elif 'Windows' in vm.guest_fullname %}Hyper-V{% else %}Manual Review{% endif %}
          {% endfor %}
        dest: "./migration_inventory_{{ inventory_hostname }}.csv"
      delegate_to: localhost

运行方式：

# 安装依赖后直接执行
pip install pyvmomi
ansible-galaxy collection install community.vmware
ansible-playbook inventory_vmware.yml

输出的 CSV 可以直接导入 Excel 或 Python 做分组统计，确定每批迁移的范围。

实际迁移：分批推进，不是一刀切

15000 台 VM 的迁移是按批次进行的，原文作者透露的关键做法：

先迁低风险工作负载：开发环境、测试环境、非关键业务先行，验证流程和工具链。
每批控制在 200-500 台：规模大到能暴露批量问题，小到出问题时能快速回退。
并行迁移不同目标平台：OpenShift 和 Hyper-V 的迁移团队独立运作，互不阻塞。

Linux VM 迁移到 OpenShift Virtualization 的典型流程

# 1. 在 OpenShift 集群启用 Virtualization 功能
oc apply -f - <<EOF
apiVersion: operator.openshift.io/v1
kind: OpenShiftVirtualization
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  featureGates:
    - deployVmWithVCPU
  workload:
    highPerformance:
      enabled: true
EOF

# 2. 从 VMware 导出 VM 磁盘为 QCOW2 格式（在 ESXi 上执行）
vmkfstools -i /vmfs/volumes/datastore1/source_vm/disk0.vmdk \
  /vmfs/volumes/datastore1/export/disk0.qcow2 \
  -d thin

# 3. 上传镜像到 OpenShift DataVolume
virtctl image-upload dv source-vm-disk0 \
  --namespace migration-project \
  --size=50Gi \
  --access-mode=ReadWriteMany \
  --image-path=./disk0.qcow2

# 4. 创建 VM 并启动
oc apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: migrated-linux-app
  namespace: migration-project
spec:
  running: true
  template:
    spec:
      domain:
        cpu:
          cores: 4
        memory:
          guest: 8Gi
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
      volumes:
        - name: rootdisk
          dataVolume:
            name: source-vm-disk0
EOF

Windows VM 迁移到 Hyper-V 的典型流程

# 从 VMware 导出 Windows VM（使用 VMware PowerCLI）
Connect-VIServer -Server vcenter.corp.example.com
$vm = Get-VM -Name "win-app-server-01"
Export-VM -VM $vm -DestinationPath "D:\VMExport\win-app-server-01"

# 将 VMDK 转换为 VHDX（使用 StarWind V2V Converter 或 qemu-img）
qemu-img.exe convert -f vmdk -O vhdx \
  "D:\VMExport\win-app-server-01\disk0.vmdk" \
  "D:\HyperV\win-app-server-01\disk0.vhdx"

# 在 Hyper-V 主机上创建并导入 VM
New-VM -Name "win-app-server-01" `
  -MemoryStartupBytes 8GB `
  -Path "D:\HyperV\win-app-server-01" `
  -VHDPath "D:\HyperV\win-app-server-01\disk0.vhdx" `
  -Generation 2

Set-VMProcessor -VMName "win-app-server-01" -Count 4
Start-VM -Name "win-app-server-01"

注意：Generation 2 VM 需要 VM 内部已安装 UEFI 兼容的 bootloader。老旧 Windows Server 2012 R2 及更早版本建议使用 Generation 1。

备份方案：迁移中最容易被低估的部分

原文特别提到备份方案需要重新设计。VMware 生态中常见的 Veeam、Nakivo 等备份工具对 Hyper-V 和 KubeVirt 的支持程度不同，迁移团队需要：

Hyper-V 侧：Windows Server Backup 或 Veeam for Hyper-V，确保 VSS 集成正常。
OpenShift 侧：利用 CDI（Container Data Importer）的快照能力，或集成外部备份工具如 Velero + KubeVirt 的 CSI 快照。

# OpenShift Virtualization VM 快照示例
oc apply -f - <<EOF
apiVersion: snapshot.kubevirt.io/v1alpha1
kind: VirtualMachineSnapshot
metadata:
  name: migrated-linux-app-snap
  namespace: migration-project
spec:
  source:
    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    name: migrated-linux-app
EOF

# 查看快照状态
oc get vmsnapshot migrated-linux-app-snap -n migration-project -o yaml

23 个月换来的教训：迁移前的检查清单

把原文社区的讨论和实际经验合并，提炼出一份可操作的清单：

检查项	为什么重要
许可成本对比（VMware 订阅 vs 新平台 TCO）	这是迁移的根本驱动力，算不清就不要动
每台 VM 的目标平台归属已确认	Linux→OpenShift、Windows→Hyper-V 的映射必须精确
新平台备份恢复已通过灾备演练	备份方案不验证，迁移后出故障就是灾难
网络拓扑在新平台可复现	VLAN、防火墙规则、负载均衡配置必须提前映射
存储性能基准测试已完成	新平台的磁盘 IOPS 和延迟必须满足生产要求
回退方案已文档化	每批迁移必须有可执行的回退步骤
应用团队已确认迁移窗口	业务方不配合，技术团队再强也推不动

15000 台 VM 的迁移不是技术英雄主义，而是工程纪律：精确摸底、分批推进、每批验证、随时回退。OpenShift + Hyper-V 的组合证明了一点——摆脱单一厂商锁定后，你获得的不只是成本节省，还有按工作负载选择最优平台的自由。代价是运维复杂度上升：两个平台意味着两套技能栈、两套监控、两套故障处理流程。这笔账，每个准备离开 VMware 的团队都要自己算清楚。