VMware 到 KubeVirt 大规模迁移技术分析

博主： admin
发布时间：2026 年 01 月 15 日
53 次浏览
暂无评论
4135字数
分类： kubernetes VMware kubevirt 虚拟化迁移

# VMware 到 KubeVirt 大规模迁移技术分析

# 一、背景概述

## 1. 迁移动机

本次迁移项目源于 VMware 续费报价上涨 3 倍，成本压力迫使企业寻找替代方案。原环境运行约 2000 台虚机，涵盖业务系统、数据库、中间件等各类工作负载。

## 2. 技术选型分析

在方案评估阶段，团队对多个虚拟化平台进行了对比分析：

| 方案 | 优点 | 缺点 | 最终评估 |
|------|------|------|----------|
| OpenStack | 成熟稳定，社区活跃 | 架构复杂，运维成本高 | 排除 |
| Proxmox VE | 开源免费，界面友好 | 企业级功能欠缺 | 备选 |
| oVirt | Red Hat 支持 | 社区萎缩，未来不明 | 排除 |
| KubeVirt | 云原生，统一管理 | 相对年轻，学习曲线陡 | 最终选择 |

## 3. 选择 KubeVirt 的核心原因

- 统一技术栈：现有容器平台已使用 Kubernetes，虚机和容器统一管理可降低运维复杂度
- 渐进式迁移：同一集群可同时运行容器和虚机，业务可逐步迁移
- 避免厂商锁定：纯开源方案，避免被单一厂商卡脖子
- 成本控制：年度基础设施成本预期降低 60% 以上

# 二、技术架构分析

## 1. KubeVirt 核心组件

KubeVirt 在 Kubernetes 之上构建虚拟化管理层，通过自定义资源定义（CRD）扩展 Kubernetes API。

```mermaid
graph TB
    subgraph KubeVirt
        A[virt-api]
        B[virt-controller]
        C[virt-handler<br/>DaemonSet]
    end
    subgraph Libvirt
        D[libvirt + QEMU/KVM]
    end
    subgraph Node
        E[Linux with KVM support]
    end
    A --> F[VirtualMachine CRD]
    B --> G[VMI]
    C --> D
    D --> E
```
![KubeVirt 架构图](https://static.op123.ren/static/df/df089040066ca941.svg)

### 组件功能说明

- virt-api：提供 KubeVirt API 入口，处理 VirtualMachine 等 CRD 的请求
- virt-controller：监听 VM 相关资源变化，负责创建对应的 VMI（VirtualMachineInstance）
- virt-handler：以 DaemonSet 形式部署在每个节点，负责虚机生命周期管理
- virt-launcher：每个虚机对应一个 Pod，内部运行 libvirt 和 QEMU 进程

## 2. 环境配置

### 硬件配置

- 计算节点：Dell PowerEdge R750xs
  - 双路 Intel Xeon Gold 6348（28 核 56 线程）
  - 512GB DDR4 ECC 内存
  - 2 x 1.92TB NVMe SSD（本地缓存）
- 存储：Dell PowerStore 5200T，100TB 可用容量，iSCSI 连接
- 网络：Mellanox ConnectX-6 Dx 100GbE 双端口网卡，配置 bond

### 软件版本

| 组件 | 版本 |
|------|------|
| 操作系统 | Rocky Linux 8.9 |
| Kubernetes | 1.28.4（kubeadm 部署） |
| KubeVirt | 1.1.1 |
| CDI | 1.58.1 |
| Longhorn | 1.5.3（后期替换） |
| Rook-Ceph | 1.12.9（最终采用） |
| Multus | 4.0.2 |
| OVN-Kubernetes | 与 K8s 集成 |

### 节点规模

- Master 节点：3 台
- 计算节点：42 台（其中 18 台专用于虚机负载）

# 三、迁移实施

## 1. 迁移流程

## 2. 存储方案演进

存储是迁移过程中最关键的组件。项目初期采用 Longhorn，但在大规模虚机场景下性能不足，两个月后切换至 Rook-Ceph。

### Rook-Ceph 配置要点

- 使用 NVMe 设备作为 OSD 存储介质
- 配置三副本策略保证数据可靠性
- 启用压缩模式降低存储占用
- 为虚机负载创建专用存储池

### RBD StorageClass 配置

```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rook-ceph-block-vm
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
  clusterID: rook-ceph
  pool: replicapool-vm
  imageFormat: "2"
  imageFeatures: layering,fast-diff,object-map,deep-flatten,exclusive-lock
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate
```

## 3. 网络架构

虚机需要使用原 VMware 环境的 VLAN 网络，采用 Multus + OVN-Kubernetes 实现二层网络透传。

### Multus 配置示例

```yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: vlan100-production
  namespace: vm-production
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "vlan100-production",
      "type": "ovn-k8s-cni-overlay",
      "topology": "localnet",
      "vlanID": 100,
      "mtu": 9000,
      "subnets": "10.100.0.0/16"
    }
```

# 四、虚机迁移策略

## 1. 虚机分类

根据业务影响和迁移难度，将 2000 台虚机分为五类：

| 优先级 | 类型 | 数量 | 迁移方式 |
|--------|------|------|----------|
| Priority 1 | 已关机、无共享磁盘 | 342 | 批量离线迁移 |
| Priority 2 | 无状态服务 | 567 | 从模板重建 |
| Priority 3 | 标准业务 | 845 | 有停机时间的迁移 |
| Priority 4 | 关键业务 | 198 | 计划窗口迁移 |
| Priority 5 | 复杂配置 | 48 | 手动验证迁移 |

## 2. 迁移工具

采用 virt-v2v + 自研批量脚本的组合方案：

- virt-v2v：官方转换工具，负责 VMDK 到 qcow2 的格式转换
- 自研脚本：实现批量调度、状态跟踪、错误处理

### virt-v2v 转换命令

```bash
virt-v2v -ic "vpx://${VCENTER_USER}@${VCENTER_HOST}/${ESXI_HOST}?no_verify=1" \
    "${VM_NAME}" \
    -o local -os "${OUTPUT_DIR}" \
    -of qcow2 \
    --password-file <(echo "${VCENTER_PASSWORD}")
```

## 3. Windows 虚机特殊处理

Windows 虚机迁移需预先安装 VirtIO 驱动：

```powershell
# 安装 VirtIO 存储驱动
pnputil.exe /add-driver E:\vioscsi\w10\amd64\*.inf /install

# 安装 VirtIO 网络驱动
pnputil.exe /add-driver E:\NetKVM\w10\amd64\*.inf /install

# 安装 QEMU Guest Agent
msiexec.exe /i E:\guest-agent\qemu-ga-x86_64.msi /qn
```

# 五、性能优化

## 1. CPU 优化

对延迟敏感的工作负载启用 CPU 绑定：

```yaml
spec:
  template:
    spec:
      domain:
        cpu:
          cores: 4
          dedicatedCpuPlacement: true
          isolateEmulatorThread: true
          model: host-passthrough
          numa:
            guestMappingPassthrough: {}
```

实测数据显示，开启 CPU 绑定后数据库虚机 P99 延迟降低 40%。

## 2. 内存优化

内存密集型工作负载使用大页内存：

```yaml
domain:
  memory:
    guest: 32Gi
    hugepages:
      pageSize: 1Gi
```

节点配置：

```bash
# 配置 1GB 大页
echo 34 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

# 持久化配置
cat >> /etc/sysctl.conf << EOF
vm.nr_hugepages = 34
EOF

# 标记节点
kubectl label node node-vm-01 kubevirt.io/hugepages-1Gi=true
```

## 3. 存储 IO 优化

数据库工作负载的 IO 调优：

```yaml
domain:
  devices:
    disks:
      - name: datadisk
        disk:
          bus: virtio
          io: native
          cache: none
          dedicatedIOThread: true
```

在此配置下，MySQL 虚机达到 85000 IOPS（4K 随机读）。

# 六、高可用与监控

## 1. 实时迁移配置

```yaml
spec:
  configuration:
    migrations:
      parallelMigrationsPerCluster: 10
      parallelOutboundMigrationsPerNode: 4
      bandwidthPerMigration: 1Gi
      completionTimeoutPerGiB: 800
      progressTimeout: 300
      allowAutoConverge: true
      allowPostCopy: false
```

## 2. 监控指标

使用 Prometheus + Grafana 监控关键指标：

- CPU 使用率：kubevirt_vmi_cpu_system_usage_seconds_total
- 内存使用：kubevirt_vmi_memory_used_bytes
- 网络 IO：kubevirt_vmi_network_receive_bytes_total
- 磁盘 IO：kubevirt_vmi_storage_iops_read_total
- 迁移状态：kubevirt_vmi_migration_phase_transition_time_seconds

# 七、迁移成果

经过 6 个月实施，项目取得以下成果：

| 指标 | 数据 |
|------|------|
| 迁移完成率 | 1987 台成功（99.35%） |
| 成本节省 | 年度基础设施成本降低 62% |
| 运维效率 | 团队规模从 12 人优化到 8 人 |
| 故障恢复时间 | 从 45 分钟降至 12 分钟 |

# 八、经验总结

## 1. 关键经验

- 存储是核心：Longhorn 在大规模虚机场景下性能不足，Ceph 虽复杂但稳定可靠
- 网络提前规划：VLAN 透传配置繁琐，需在项目初期设计好网络架构
- 分批迁移：每批 50 台可控，问题影响面小
- Windows 需专门模板：驱动和激活问题需提前准备
- 监控先行：迁移前建好监控体系，便于问题排查

## 2. 常见问题

| 问题 | 原因 | 解决方案 |
|------|------|----------|
| Guest agent 未连接 | QEMU Guest Agent 未安装 | 安装并启动 qemu-guest-agent |
| 网络不通 | Multus 配置错误 | 检查 NetworkAttachmentDefinition 和 VLAN 透传 |
| 磁盘性能差 | 缓存策略不当 | 改为 cache: none + io: native |
| 实时迁移失败 | 带宽或存储问题 | 调整迁移带宽，检查存储可达性 |

# 九、参考资料

1. [KubeVirt 官方文档](https://kubevirt.io/user-guide/)
2. [KubeVirt GitHub 仓库](https://github.com/kubevirt/kubevirt)
3. [virt-v2v 文档](https://libguestfs.org/virt-v2v.1.html)
4. [Rook-Ceph 文档](https://rook.io/docs/rook/latest/)
5. [OVN-Kubernetes 文档](https://github.com/ovn-org/ovn-kubernetes)

最后修改：2026 年 01 月 15 日

如果觉得我的文章对你有用，请随意赞赏

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

VMware 到 KubeVirt 大规模迁移技术分析

admin • 2026 年 01 月 15 日

# VMware 到 KubeVirt 大规模迁移技术分析

# 一、背景概述

## 1. 迁移动机

## 2. 技术选型分析

在方案评估阶段，团队对多个虚拟化平台进行了对比分析：

## 3. 选择 KubeVirt 的核心原因

# 二、技术架构分析

## 1. KubeVirt 核心组件

KubeVirt 在 Kubernetes 之上构建虚拟化管理层，通过自定义资源定义（CRD）扩展 Kubernetes API。

### 组件功能说明

## 2. 环境配置

### 硬件配置

### 软件版本

### 节点规模

- Master 节点：3 台
- 计算节点：42 台（其中 18 台专用于虚机负载）

# 三、迁移实施

## 1. 迁移流程

## 2. 存储方案演进

存储是迁移过程中最关键的组件。项目初期采用 Longhorn，但在大规模虚机场景下性能不足，两个月后切换至 Rook-Ceph。

### Rook-Ceph 配置要点

- 使用 NVMe 设备作为 OSD 存储介质
- 配置三副本策略保证数据可靠性
- 启用压缩模式降低存储占用
- 为虚机负载创建专用存储池

### RBD StorageClass 配置

## 3. 网络架构

虚机需要使用原 VMware 环境的 VLAN 网络，采用 Multus + OVN-Kubernetes 实现二层网络透传。

### Multus 配置示例

# 四、虚机迁移策略

## 1. 虚机分类

根据业务影响和迁移难度，将 2000 台虚机分为五类：

## 2. 迁移工具

采用 virt-v2v + 自研批量脚本的组合方案：

- virt-v2v：官方转换工具，负责 VMDK 到 qcow2 的格式转换
- 自研脚本：实现批量调度、状态跟踪、错误处理

### virt-v2v 转换命令

## 3. Windows 虚机特殊处理

Windows 虚机迁移需预先安装 VirtIO 驱动：

```powershell
# 安装 VirtIO 存储驱动
pnputil.exe /add-driver E:\vioscsi\w10\amd64\*.inf /install

# 安装 VirtIO 网络驱动
pnputil.exe /add-driver E:\NetKVM\w10\amd64\*.inf /install

# 安装 QEMU Guest Agent
msiexec.exe /i E:\guest-agent\qemu-ga-x86_64.msi /qn
```

# 五、性能优化

## 1. CPU 优化

对延迟敏感的工作负载启用 CPU 绑定：

实测数据显示，开启 CPU 绑定后数据库虚机 P99 延迟降低 40%。

## 2. 内存优化

内存密集型工作负载使用大页内存：

```yaml
domain:
  memory:
    guest: 32Gi
    hugepages:
      pageSize: 1Gi
```

节点配置：

```bash
# 配置 1GB 大页
echo 34 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

# 持久化配置
cat >> /etc/sysctl.conf << EOF
vm.nr_hugepages = 34
EOF

# 标记节点
kubectl label node node-vm-01 kubevirt.io/hugepages-1Gi=true
```

## 3. 存储 IO 优化

数据库工作负载的 IO 调优：

```yaml
domain:
  devices:
    disks:
      - name: datadisk
        disk:
          bus: virtio
          io: native
          cache: none
          dedicatedIOThread: true
```

在此配置下，MySQL 虚机达到 85000 IOPS（4K 随机读）。

# 六、高可用与监控

## 1. 实时迁移配置

## 2. 监控指标

使用 Prometheus + Grafana 监控关键指标：

# 七、迁移成果

经过 6 个月实施，项目取得以下成果：

# 八、经验总结

## 1. 关键经验

## 2. 常见问题

# 九、参考资料

VMware 到 KubeVirt 大规模迁移技术分析

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

搭建国内LabHub

CentOS 7.9 编译并使用rpm方式升级openssh9.6p1（包括后续更新9.8p1等）

一天从 redis 大 key 开始

安装eve-ng

重装ensp

Sentinel 应急响应自动化分析工具技术分析

OBS+CDN实现HTTPS及文件分发功能

使用容器部署dnsmasq一般做法

打造镜像站点同步常用linux软件仓库

ClawX：让 AI 智能体走出终端的桌面图形界面

VMware 到 KubeVirt 大规模迁移技术分析

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

VMware 到 KubeVirt 大规模迁移技术分析

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款