今年上半年我还在盯着 vCenter 的许可证到期提醒发愁。公司虚拟化平台从最初的 20 台物理机一路扩到 100 多台VMware 的许可费用翻了快三倍加上各类业务系统都在推进国产化适配运维团队很早就开始物色能接住现有业务的替代平台。ZSvirt 就是这样进入我们视野的一款基于 KVM 的国产虚拟化管理平台支持集中式 Web 管理配合 virt-v2v 和 qemu-img 这套工具链迁移路径理论上比较清晰。这篇文章不是厂商文档的搬运是我把 ZSvirt 从部署到迁移全流程跑完之后的完整 PoC 记录包括环境规划、部署细节、迁移操作、性能对比和我踩过的坑。如果你也在评估 ZSvirt 或其他 KVM 系平台是否适合替代 VMware这份指南可以帮你少走不少弯路。1. 我为什么推动这次 PoC1.1 触发这件事的三个直接原因第一个原因自然是钱。VMware 的许可模式这些年调整频繁按 CPU 插槽计费叠加 vCenter 管理授权规模上来之后每年的维护成本非常可观。我们这边还只是一百多台虚拟机的中小规模大厂动辄几千台虚拟机许可费更是天文数字。第二个原因是运维开放度。VMware 的管理面是封闭的很多时候只能依赖 vCenter 的 API 和 UI 操作底层细节被封装得很严实。对于习惯了 Linux 生态、喜欢用命令行和脚本解决批量操作的运维团队来说这种封闭性其实是一种束缚。KVM 系平台天然贴近开源生态批量操作、故障诊断、二次开发都更顺手。第三个原因是国产化迁移的大趋势。业务侧已经有不少系统在往国产 CPU 和国产操作系统上靠底层虚拟化平台如果还是依赖国外商业软件整个技术栈从根上就谈不上自主可控。当然这不是说 VMware 一定会被立刻替换但作为基础设施团队提前做一次 PoC、跑一遍迁移演练后面决策的时候才有真实数据可参考。1.2 PoC 想验证的三件事我定义这次 PoC 的目标很明确就三件事。第一ZSvirt 能不能平稳接管现有虚拟机。虚拟化的核心能力无非是计算、存储、网络三块。计算上 KVM 本身经过十几年的打磨已经很成熟存储和网络是更需要验证的部分尤其是多路径、快照、VLAN 这些常用功能在 ZSvirt 里怎么配置、效果如何。第二从 VMware 迁移到 ZSvirt 的过程中虚拟机能不能保证数据完整性。我们这边有数据库、缓存服务、文件服务不少是有状态应用迁移过程一旦丢数据或者损坏磁盘那就是事故。所以 PoC 里迁移路径的可靠性优先级最高。第三迁移前后的性能有没有断崖式下跌。虚拟化平台的性能会直接影响业务响应时间我需要用基准测试工具跑出迁移前后的对比数据用数据说话而不是凭感觉。2. ZSvirt 技术底座与核心架构2.1 底层不是换皮是 KVM 血统很多人一听到国产虚拟化平台第一反应是“是不是套壳 OpenStack”我一开始也有这个顾虑但深入看下来ZSvirt 走的路线和 OpenStack 不太一样。它的底层虚拟化能力完全来自 Linux 内核自带的 KVM 模块管理面通过 libvirt 和 QEMU 完成对虚拟机的生命周期控制。说得直白一点你在 ZSvirt 里创建的每一台虚拟机本质上就是一个跑在宿主机上的 QEMU/KVM 进程数据盘是 qcow2 或 raw 格式的文件网络通过 Linux Bridge 或 Open vSwitch 实现。这种架构带来的好处是可预测。你不需要理解一套全新的虚拟化实现只要熟悉标准 Linux 体系排查问题的时候能直接用 virsh、ps、ss 这些常规命令去验证虚拟机的真实状态。我在 PoC 过程中不止一次直接登上计算节点查看 QEMU 进程的参数这在 VMware ESXi 里几乎做不到。2.2 管理端、计算节点与存储的拓扑ZSvirt 的平台拓扑分三层管理端、计算节点和共享存储。管理端是平台的中枢负责提供 Web 控制台、API 服务和数据库存储。控制台能完成的虚拟机创建、删除、快照、克隆、迁移等操作本质上都是管理端调用计算节点上的 agent 去执行。计算节点就是安装了 ZSvirt agent 的物理服务器agent 负责接收管理端的指令通过 libvirt 实际操控 KVM。存储层面ZSvirt 支持本地存储和共享存储两种模式。本地存储就是直接用宿主机上的磁盘目录适合测试环境或者对高可用要求不高的业务共享存储可以对接 NFS 或者 iSCSI生产环境建议用共享存储这样虚拟机支持热迁移宿主机宕机后还能在其他节点快速拉起。2.3 网络模型从端口组到虚拟交换机VMware 里最核心的网络概念是 vSwitch 和分布式端口组。ZSvirt 这边的对应物是虚拟交换机和网桥。理解这一点迁移的时候才能做到网络规划心中有数。计算节点上物理网卡会绑定到 Linux Bridge 上虚拟机的虚拟网卡再挂接进这个 Bridge。这样虚拟机之间的通信、虚拟机与外网的通信都走同一套二层交换机制。如果你需要做隔离可以在虚拟交换机上配置 VLANZSvirt 在 web 界面里也提供了 VLAN ID 的设置入口和 VMware 的 VLAN trunk 配置逻辑本质相同。网络这块我最关心的 VLAN 功能PoC 里用三个业务 VLAN 做了验证结果是通透的后面部署部分细说。3. PoC 环境搭建与部署细节3.1 硬件清单、网络规划与系统准备PoC 的硬件不需要一步到位但至少要保证三台独立的服务器才能验证管理端和计算节点分离的场景。我这里用的是一台管理节点加两台计算节点的组合以下是具体配置角色CPU内存系统盘数据盘网卡管理节点Intel Xeon Silver 431016C64 GB2×480GB SSDRAID1无4×1GbE计算节点-1AMD EPYC 735224C128 GB2×480GB SSDRAID12×1.92TB NVMe4×1GbE 2×25GbE计算节点-2AMD EPYC 735224C128 GB2×480GB SSDRAID12×1.92TB NVMe4×1GbE 2×25GbE网络规划我分了三个平面管理网、存储网和业务网分开走避免互相干扰。管理网用 10.10.140.0/24 网段负责管理端与计算节点 agent 的通信存储网独立走 10.10.142.0/24挂 NFS 共享存储业务网用 10.10.141.0/24承载虚拟机流量。如果物理环境只有一张千兆网卡也可以把所有流量合在一个平面里但强烈不建议虚拟化环境一旦出现业务环路或者广播风暴管理面也跟着瘫掉就麻烦了。操作系统我统一装了 CentOS 7.9内核版本 3.10。ZSvirt 官方对 CentOS 7 系的兼容性做得很成熟安装依赖的坑比较少。如果你的环境里有国产化系统要求可以换成对应版本的系统基本原理一样。3.2 管理平台安装与初始化管理端的安装比想象中简单。ZSvirt 官方提供 ISO 镜像和一键安装脚本两种方式。我这边因为要批量复现选了脚本安装的方式。安装前需要先把系统基础环境调整到位核心是这三步配置静态 IP关闭 NetworkManager改用 network 服务管理网络关闭 firewalld 和 SELinux避免安全组件拦截平台服务端口如果是生产环境建议后续自定义放行规则而不是直接关闭时间同步配置 NTP 服务器管理端和计算节点的时间偏差不能太大。之后执行 zsvirt 的安装脚本脚本会自动安装数据库、消息队列、Web 服务等依赖组件。大概跑十几分钟脚本结束会在终端打印管理端访问地址和默认管理员账号。我第一次安装的时候默认账号密码忘记改就放到内网访问了后来安全扫描被通报这里必须提醒一下安装完成后第一件事就是改掉默认密码绑定管理白名单。3.3 计算节点接入与存储配置计算节点的接入分两步。第一步在节点上执行 agent 安装脚本指定管理端地址和通信密钥agent 会自动注册到平台第二步在管理端 Web 界面里把注册上来的节点标记为“可用”然后添加存储。我这里用一个 4TB 的 NFS 文件系统作为共享存储挂在所有计算节点的 /srv/zsvirt/nfs 目录下。在管理端添加存储的时候填 NFS 服务器地址和挂载路径平台会校验挂载点是否可写、目录是否为空校验通过后就能在创建虚拟机时选择这个存储池了。需要注意一个细节共享存储路径的权限要统一。如果是 NFS 挂载确认服务器的 root_squash 配置和挂载目录属主一致避免一台节点上的虚拟机磁盘文件在另一台节点上因为权限问题无法读取。这个坑我在后续热迁移时踩过一次虚拟机迁过去之后起不来查了一圈才发现是 NFS 目录的属主没对齐。3.4 第一台虚拟机验证平台搭建完成以后我的第一个动作不是马上迁移而是先创建一台全新的 CentOS 虚拟机把创建、开机、关机、快照、克隆、VLAN 配置这些基本功能从头到尾过一遍。这一步相当于“冒烟测试”如果基础功能就不稳后面的迁移工作就是白搭。这台测试虚拟机我分配了 4 vCPU、8GB 内存、100GB 磁盘网卡接入业务网的 VLAN 101。登录 Web 控制台填完虚拟机名称、规格、镜像 ISO 路径点创建之后虚拟机自动启动VNC 控制台正常出现安装界面。整个流程很顺畅和 vCenter 里创建虚拟机的体验不相上下。第一台虚拟机跑通后我又测试了冷迁移和快照回滚。冷迁移是指在关机状态下把虚拟机从计算节点 1 迁移到计算节点 2平台后台做的实际是把 NFS 上的磁盘文件重新定义到另一台宿主机的 QEMU 进程里几十秒完成。快照回滚则是把磁盘状态恢复到创建快照的时间点用于验证后续迁移前备份方案的可行性。4. 迁移前的 VMware 环境盘点4.1 虚拟机清单与依赖关系梳理迁移前最重要的工作不是操作而是盘点。我先把 vCenter 里 100 多台虚拟机导出了一份完整清单字段包括虚拟机名称、操作系统类型、CPU 核数、内存大小、磁盘数量与容量、网络连接情况、是否安装 VMware Tools、运行状态。拿到清单后做了三件事第一按操作系统分类统计 Windows 和 Linux 各占多少比例第二按业务重要性分类标注哪些是有状态的应用服务器哪些是无状态的 Web 前端第三找出那些明显是“僵尸虚拟机”的长期关机或者 CPU 内存配置畸形的顺手做了清理这些机器迁移过去只会浪费资源。盘点结果显示Linux 虚拟机占比约 60%主力是 CentOS 7 和 Ubuntu 18.04Windows 虚拟机占比约 40%以 Windows Server 2016/2019 为主。这个比例对迁移方案影响很大因为 Linux 虚拟机的转换工具链很成熟Windows 虚拟机需要处理驱动注入和激活问题。4.2 网络与存储映射方案VMware 里面的网络结构是 vSphere 标准交换机加 VLAN 端口组。我在映射到 ZSvirt 时把同一 VLAN 的端口组简单地对应到 ZSvirt 里相同 VLAN ID 的虚拟交换机上不做网络重设计。这样迁移后虚拟机的 IP 地址不用变对业务的影响面最小。存储映射要复杂一些。VMware 的数据存储分三层高频交易的数据库虚拟机放在全闪存储普通业务虚拟机放在混合存储池备份和归档类虚拟机放在大容量机械盘存储。我在 ZSvirt 侧准备了两个共享存储池一个放在 NVMe 全闪节点上一个放在普通 SATA SSD 节点上尽量保证存储性能分层和迁移前对齐。4.3 迁移工具链选择迁移工具链我对比了三种方案平台自带迁移工具、基于 OVF 导出的手动迁移、基于 virt-v2v 的命令行批量迁移。ZSvirt 平台本身提供了从 VMware 导入虚拟机的向导本质上也是调用底层转换工具适合少量虚拟机操作OVF 导出方式在 VMware 侧操作简单但导出的文件往往较大而且批量操作不方便virt-v2v 这工具是红帽出品的虚拟化迁移利器支持直接读取 vCenter 里的虚拟机并转换为 KVM 需要的格式和驱动配置批量执行和脚本化程度最高。我最终的方案是混合使用少量关键虚拟机用 ZSvirt 自带导入向导逐步操作剩余的批量虚拟机用 virt-v2v 脚本化处理。下面详细讲实际操作过程。5. 迁移实操两条路径的完整过程5.1 离线迁移vmdk 转 qcow2 手工流程离线迁移的核心思路是把 VMware 的虚拟磁盘格式从 vmdk 转换为 KVM 侧的 qcow2 格式然后在 ZSvirt 里重新挂载。这个过程适合对虚拟机做停机迁移的场景简单直接可控性最强。具体操作分五步。第一步在 vCenter 里给需要迁移的虚拟机关机然后用 vmkfstools 或者 vSphere Web Client 导出 vmdk 文件。第二步把 vmdk 文件拷贝到 ZSvirt 的管理节点或者一台中转机器上执行 qemu-img 转换命令qemu-img convert -f vmdk -O qcow2 testvm-disk1.vmdk testvm-disk1.qcow2这个命令会把 vmdk 格式转换为 qcow2 格式。转换过程中可以根据需要增加 -p 参数显示进度条用大文件转换时能看到百分比避免心里没底。第三步把转换生成的 qcow2 文件上传到 ZSvirt 的共享存储目录或者通过管理端界面里的“镜像导入”功能上传到对应存储池。第四步在 ZSvirt 里创建一台新虚拟机CPU、内存、磁盘参数按原虚拟机的配置填写磁盘部分选择“使用已有磁盘”指定刚才上传的 qcow2 文件。第五步开机验证。这套流程看起来简单实操中有两点容易疏忽。一是 qemu-img 转换期间如果源 vmdk 还在被使用会导致磁盘数据不一致所以迁移前一定要确保虚拟机关机状态二是转换后的 qcow2 文件大小只反映实际使用量创建虚拟机的时候给磁盘预留空间要略大于原文件否则后续扩容会很麻烦。5.2 在线迁移virt-v2v 批量转换对于数量较多的虚拟机手动 qemu-img 转换效率太低这里我用了 virt-v2v 的批量方案。virt-v2v 支持直接从运行中的 vCenter 里读取虚拟机配置和磁盘内容并把虚拟机转换为 KVM 可用的配置。基本命令格式如下virt-v2v -ic vpx://rootvcenter.example.com/Datacenter/Cluster -o local -os /data/vms centos7-db01这个命令连接 vCenter读取 centos7-db01 这台虚拟机的配置转换完成后输出到本地的 /data/vms 目录。-o local 表示输送到本地文件系统-os 指定输出路径。转换过程中 virt-v2v 会安装必要的 virtio 驱动、调整磁盘控制器类型、修复 boot 引导配置。批量操作时我写了一个简单的 shell 循环从虚拟机清单文件里逐行读取虚拟机名称循环执行 virt-v2v。线上转换大约 30 台 Linux 虚拟机按每台平均 30GB 磁盘计算总耗时两个多小时速度可接受。转换完成后批量导入 ZSvirt 的方式和离线流程一样在创建虚拟机时选择已有磁盘即可。virt-v2v 的优势是自动化程度高但也有一些场景需要手动干预。比如虚拟机里有 LVM 卷组结构virt-v2v 虽然能识别但转换后建议检查一下分区表和 fstab 配置是否还指向正确的设备名。还有虚拟机用了 VMware 特定的虚拟硬件版本转换时 virt-v2v 可能出现警告但不影响最终启动可以忽略。5.3 Windows 虚拟机的特殊处理Windows 虚拟机的迁移比 Linux 复杂得多核心问题有三个驱动不兼容、启动配置错误、激活失效。驱动问题的根源是 VMware 的虚拟设备驱动和 KVM 的 virtio 驱动不匹配。迁移前如果没装好 virtio 驱动Windows 开机后会直接蓝屏提示 INACCESSIBLE_BOOT_DEVICE。解决办法有两种一种是在 VMware 虚拟机里预先安装 virtio-win 驱动包让 Windows 提前具备 KVM 环境下可用的存储和网卡驱动另一种是在 virt-v2v 转换后挂载 Windows 桌面注册表用注册表注入驱动信息操作难度大不推荐新手尝试。我采用的方案是迁移前在 VMware 机内先装 virtio-win 驱动然后关机执行 virt-v2v 转换。这样转换后的虚拟机能直接找到可用的磁盘控制器网卡也能识别出来。启动配置问题主要是 Windows 的 BCD启动配置数据和磁盘签名。virt-v2v 在转换时通常会自动修复这些但个别情况下还是会出现“找不到操作系统”的报错。遇到这种问题可以从 ZSvirt 里挂载一个 Windows PE 引导盘进入修复模式执行启动修复命令。激活问题相对敏感。Windows Server 的激活绑定到虚拟硬件迁移到 KVM 后由于主板信息和硬盘控制器变化激活状态会丢失。生产环境里建议先和厂商确认授权范围或者使用支持 KVM 环境的批量激活方式避免迁移后出现授权风波。这也是 Windows 虚拟机迁移中最容易忽略但影响最大的一个问题。6. 迁移后验证与问题排查6.1 功能性验证清单虚拟机迁移完成后不能直接丢给业务部门就说“迁移完成”。我整理了一份验证清单每台虚拟机都要逐项确认确认完成后才更新资产台账。验证项方法通过标准开机状态控制台/SSH/Ping能正常进入系统控制台有登录界面CPU 核数与内存系统内 lscpu/free 命令与迁移前一致磁盘容量df -h / 磁盘管理分区挂载正常容量无缩水网卡连通性ping 网关和同网段主机丢包率 0%业务端口ss -lntp 查看监听端口原业务端口均在监听系统日志journalctl/dmesg 检查异常无 kernel panic、无磁盘 I/O 报错数据完整性校验关键文件 md5 / 数据库完整性检测与迁移前一致这项验证我安排了两轮。第一轮是运维自验逐台执行脚本巡检第二轮是业务确认由各业务系统的负责人自己检查系统是否可用。两轮都通过后才算一台虚拟机迁移完成。6.2 性能基准测试对比性能数据是证明“替换后性能没有明显下降”的关键证据。我在迁移前的 VMware 虚拟机和迁移后的 ZSvirt 虚拟机上分别跑了同一套基准测试尽量保证测试环境一致同一台物理机型、同样的 CPU 核数和内存、同样版本的操作系统。测试工具选了三组磁盘用 fio网络用 iperf3CPU 用 sysbench。fio 的测试命令大致如下fio -filename/tmp/testfile -direct1 -iodepth 32 -rwrandrw -ioenginelibaio -bs4k -numjobs4 -size2G -nametest -group_reporting测试结果整理对比后让人心里踏实了不少。随机读写性能在 ZSvirt 上比 VMware 略好大约有 5% 到 10% 的提升这部分要归功于 qcow2 的缓存机制和本地 NVMe 存储的发挥顺序读写的性能基本持平网络带宽在千兆网卡环境下差异不大跑满 1GbE 没有压力CPU 性能因为用的是同一套物理 CPU差异可以忽略。值得说明的是这次 PoC 的 VMware 虚拟机原本运行在全闪存储上ZSvirt 侧用的也是 NVMe 存储两边的硬件档次是对齐的。如果你的迁移是往性能只有机械盘的存储上迁移那性能下降基本是必然的这个问题应该在迁移规划阶段就考虑清楚。6.3 踩坑记录五个坑三种解法这次 PoC 过程不是一帆风顺的前后踩了不少坑。挑几个有代表性的记录在这里。第一个坑是 Linux 虚拟机迁移后网络不通。检查发现是网卡名称从 eth0 变成了 ens3网络配置文件还在绑定 eth0。解决方法是迁移后统一更新网络接口配置按 MAC 地址绑定而不是按设备名绑定。第二个坑是 NFS 共享存储权限不一致导致虚拟机在某台计算节点上无法启动。前面已经提过解决方法是统一挂载目录属主和权限确保两台计算节点看到的文件权限一致。第三个坑是 Windows 虚拟机迁移后重启蓝屏。原因就是 virtio 驱动没提前注入后来补装了 virtio-win 驱动重新转换一遍解决。第四个坑是 qcow2 磁盘文件坏块。有一台虚拟机转换完成后 md5 校验不一致重新转换才发现是源 vmdk 在导出时没有完全静默主机上还挂着数据库进程。这个教训是离线迁移前务必彻底关机不能只靠快照就导出。第五个坑是 VLAN 配置了但虚拟机之间还是能互通。排查后确认是 ZSvirt 虚拟交换机默认只做了网桥不做过滤需在管理端给网桥绑定对应 VLAN 的物理接口非 Tagged 接口不要混接。7. ZSvirt 到底能不能替代 VMware7.1 从 PoC 数据来看的结论跑完整个 PoC我的总体结论是对绝大多数中小规模虚拟化场景ZSvirt 完全有能力替代 VMware并且在成本、开放性、迁移友好度上有明显优势。容量方面两台计算节点稳定运行了 40 多台虚拟机CPU 平均负载在三成左右内存使用率四成出头远没到瓶颈。功能方面虚拟机的全生命周期管理、快照、克隆、冷迁移、热迁移这些核心能力都用过一遍没有发现明显的功能缺失。稳定性方面PoC 跑了一个多月没有出现过无故重启或者存储异常的情况。7.2 哪些场景适合替换哪些场景要慎重适合替换的场景很清晰。存量虚拟机以 Linux 为主、规模在几百台以内的替换工作量和风险都可控业务系统对虚拟化平台没有深度绑定要求的比如没有用 VMware 的 Distributed Switch、NSX、vSAN 等高级特性迁移过来功能完全覆盖对整体成本敏感、希望减少商业软件依赖的团队ZSvirt 的方案明显更划算。需要谨慎的场景主要是两类。一是深度使用了 VMware 生态高级特性的环境比如 vSAN 超融合、NSX 网络虚拟化、Site Recovery Manager 容灾这些在 ZSvirt 里没有对应的等价物强行迁移需要重新设计方案不是简单替换能搞定的。二是规模极大、有非常复杂的资源池权限模型的场景VMware 的权限体系和资源池配额管理经过多年迭代非常精细ZSvirt 的权限模型相对扁平需要在 PoC 里专门验证是否能满足合规要求。7.3 分阶段迁移的建议如果决定要替换我建议不要搞“一夜切换”而是分三步走。第一阶段做试点迁移。挑几台无状态、影响小的应用服务器先迁整个流程跑通让业务部门对平台建立起信任。第二阶段做批量迁移。把没有状态依赖的应用服务器先迁完积累批量操作经验同时完善脚本和验证清单。第三阶段做关键业务迁移。数据库、缓存这类有状态应用放在最后迁移窗口选在业务低峰期提前准备好回退方案一旦迁移后验证不通过能从 ZSvirt 侧把虚拟机关机再导回 VMware。我这次 PoC 实际上就是把第一阶段到第三阶段的完整演练做了一遍整个过程下来最大的心得体会是迁移工具再成熟也很难解决环境差异带来的所有问题。很多问题不是靠工具能提前发现而是要建立一套“迁移前检查、迁移中监控、迁移后验证”的闭环流程。按这个节奏推进不管是迁 20 台还是 200 台心里都是有底的。