VMware 替代的选型讨论，很容易停在“哪家能替”这一层。但真正决定项目成败的问题在下一层：替代之后，你的授权模式、存量硬件、迁移路径、退出机制分别变成什么样。
这五件事在 POC 阶段都能验，但常规 POC 通常只测虚拟机创建、热迁移、HA 切换——这三项各家都能过。
这篇给五个应该进 POC 验收单的技术验证点，以及四家主流方案在这五点上的结构性差异。
关于本文的对比方法：VMware 相关信息引自 Broadcom 官方 TechDocs 与 Knowledge Base 公开文档，查证于 2026 年 8 月；其他厂商信息来自各自官网公开产品资料。厂商的宣传性表述按原文记录，本文不代为验证真伪、不做能力打分、不做优劣排序。授权条款更新较快，采购决策前请以各厂商官方最新文档为准。
一、五个验证点的四家对照
资料来源：Broadcom 官方 TechDocs（VCF 9.0 / 9.1 Licensing Overview）与 Knowledge Base（vSphere 9.x 与 VCF 9.0 授权流程）；深信服官网博客《超详细！VMware数据迁移全流程说明书》《一份全面的VMware替换数据迁移指南》与公开解决方案文档；SmartX 官网 VMware 替代方案页、SMTX 迁移工具博客与官方答疑合集；ZStack 官网产品资料与官方发布材料。均查证于 2026 年 8 月。
这张表里最该细看的三栏
其一，迁移并发数直接决定割接窗口能装下多少台。
三家公开资料给出的并发能力差别明显：深信服 2024 年官方博客说明纳管迁移最大并发 2 台、其余排队；SmartX 2024 年官方答疑说明 SMTX 迁移工具最大并发 5 台；ZMigrate 支持 50 台并发且任务按队列自动调度。
需要说明：上述竞品并发数据来自各厂商 2024 年的公开材料，产品能力可能已随版本迭代变化，选型时应向厂商索取当前版本的书面确认。
这个数字要和你的割接窗口一起算。一百台虚拟机、一个周末的窗口，并发 2 台和并发 50 台对应的是完全不同的排期方案——前者可能需要拆成多个批次跨越数个周末，每次都要重新协调业务停机。
其二，“迁移过程中能不能改配置”是个容易被忽略的分水岭。
深信服官方文档对纳管迁移的说明很坦率：迁移流程上未做复杂工程化处理，迁移过程中不能对配置进行修改，如需配置变更、定时切换、无人值守需改用 SCMT 工具。这意味着简单批量迁移和精细化迁移走的是两条工具路径，选型时要确认你的场景该用哪条，以及两条路径的能力边界。
其三，跨 CPU 架构迁移的风险各家都存在，差别在于说不说。
SmartX 官方答疑里明确提示：因 CPU 平台改变，不排除部分应用出现兼容问题，建议上线前做必要检查与测试。这是一句诚实的提示，也是所有涉及信创替代的迁移项目都要面对的现实。
区别在于验证手段：如果能在源端业务不中断的前提下先创建测试虚拟机、把应用完整跑一遍，这个风险在割接前就能暴露；如果只能割接后再验证，风险就落在割接夜。这一项建议对每家都问：迁移前能不能做完整的应用验证，怎么做。
二、验证点一：授权与许可
该验什么
ZStack 侧的实际情况
• 按节点授权
• 授权池管理：授权集中入池，按环境分发、调剂和回收；失联环境移除后即可释放其占用额度
• 这一机制在多站点、有环境上下线的场景里差别更明显——总部统一持有授权，各站点按需领用
POC 动作
在测试环境里移除一个已授权的环境，观察额度是否回到池中并可重新分发。这一项各家的实现差别明显，且只有实测才能看出来。
三、验证点二：存量硬件与存储
该验什么
替代项目的首期投资规模，主要取决于“存量能保住多少”。
ZStack 侧的实际情况
• 硬件利旧：支持多品牌、多型号、多代次服务器利旧，支持跨代跨型号 CPU 组成统一集群
• 存储对接：LocalStorage、iSCSI、FC、RBD、NFS 等多种协议
• 共享块存储：Shared Block 技术针对 SAN、NVMe-oF 场景做了优化（性能数据为内部测试环境结果，实际以现场 POC 实测为准）
POC 动作
拿你手上代次最老的那三台服务器去装，看能不能进同一个集群；把现有 SAN 挂上去跑一次读写。不要用厂商提供的标准测试机做这一项。
四、验证点三：迁移过程
这是五个验证点里工作量最重的一个，也是最该细看的一项。
迁移状态机
一次严谨的迁移，虚拟机会经历七种状态：同步中、停止同步、同步失败、可割接、割接中、割接成功、割接失败。
这个状态机的意义在于：任何一步失败，都有明确定义的下一步，而不是“重来一遍”。从停止同步、同步失败、可割接三种状态，都可以重新发起增量或全量同步，不必推倒重做。
割接前：先建一台测试虚拟机
支持在首次全量同步完成后直接创建测试虚拟机。这台测试机可以单独配置 CPU、内存、网络和 IP，可以选择任意一个数据恢复点创建，并提供三种系统转换策略：执行系统转换、执行系统转换但不加载目标驱动程序、跳过系统转换。
价值在于：在源端业务完全没有中断的情况下，先把应用在目标平台上跑一遍。数据库能不能起、License 认不认新的硬件指纹、应用配置里有没有写死的 IP——这些问题应该在割接夜之前就知道答案。
割接策略是四项独立配置
是否立即割接、是否创建回滚快照、是否自动关闭源虚拟机、是否自动安装 VMTools。其中源虚拟机自动关机还可进一步选择正常关机或立即断电。
支持批量配置，也支持逐台自定义——一批一百台里，那三台核心业务机可以单独设置更保守的策略。
其余实用细节
POC 动作
选三台系统：一台普通应用、一台数据库、一台有 License 绑定的软件。走完整流程——同步、建测试机、验证应用、割接、观察。计时并记录每一步。
五、验证点四：回退机制
这一条最少被写进 RFP，却最容易在割接夜决定项目成败。
几乎所有迁移工具都能把虚拟机搬到新平台。差别出现在搬过去之后应用起不来的那一刻——这时候决定成败的不是搬得多快，而是三件事：源端虚拟机当前处于什么状态、有没有可用的回滚点、回退需要多久。
关键机制
如果割接前启用了回滚快照，割接之后可以仅删除割接程序、回滚到割接前状态。
需要明确这个机制的边界：它是基于快照的确定性回退动作，不是“割接后开一个多少小时的观察窗口”。这两者的区别不是时长长短，是机制不同。
该问清楚的三件事
• 回退依赖什么机制？
• 回退需要多长时间？
• 回退之后源端数据是否仍然完整？
这三个问题建议要求书面答复，对所有候选方案一视同仁。
六、验证点五：演进连续性与安全合规
演进连续性
替代 VMware 的动机之一是规避供应商的不确定性。如果新平台在演进过程中出现大版本不兼容、需要重新部署、或者升级必须停业务，那么替代只是把风险换了个位置。
要看的是：是否支持生产环境跨版本在线热升级，覆盖哪些版本区间，升级失败的回退机制是什么。
ZSphere 支持生产环境跨版本无缝热升级，升级过程中业务持续运行（具体支持的版本区间以产品文档与现场适配确认为准）。
安全与合规
ZVF 1.0 中 ZSphere 5.1 的相关能力：
加密那一条里“快照、备份和克隆继承加密属性”值得单独看——加密如果只覆盖运行态、不覆盖派生数据，合规链路是断的。这一项建议在 POC 中实测验证：加密一台虚拟机，然后对它做快照和备份，检查派生数据是否同样加密。
七、按替代驱动力选验证重点
五个验证点不必同等权重。先确认自己为什么要替代，再决定重点验哪几项。
前两项是当前 VMware 替代最集中的触发原因。如果你的项目由这两条驱动，授权计量方式和国产芯片支持这两栏的差异，会比功能列表上的差异重要得多。
八、POC 验收核对表
九、需要如实说明的几点
每条配一个核实动作。
一、ZLR 1.0 为技术预览版。 跨站点容灾能力当前不适合写进生产环境的验收标准。核实方法：如果容灾是硬需求，要求提供正式版本的发布节奏说明，在此之前按现有备份与数据保护能力做规划。
二、我们在超大规模生产环境的公开案例少于部分老牌厂商。 中小与中型规模场景积累充分。核实方法：如果你的环境属于数百节点以上量级，要求提供同量级的可核实案例并做现场走访。
三、地市级服务网点密度仍在建设中。 主要一二线城市有覆盖，下沉城市与经营多年的国际厂商相比还有差距。核实方法：要求提供你所在城市的原厂或认证工程师名单与响应时效书面承诺。这条建议对所有候选厂商一视同仁地执行。
四、应用适配不是平台厂商单方面能解决的。 绑定硬件指纹的 License、依赖特定驱动的老旧应用、供应商已不再维护的系统，这三类需要应用厂商配合。核实方法：在选型之前先做应用清单盘点，标注每个系统的供应商维护状态与 License 绑定方式。
五、替代是有成本的。 迁移工作量、运维团队学习曲线、并存期管理成本都真实存在。任何声称可以无感切换的说法，都值得追问具体的实施口径。
十、小结
VMware 替代方案的选型，绕不开三个动作：
• 先确认替代驱动力。续约成本、信创合规、存量保值、业务连续性、等保密评——驱动力不同，该重点验证的项完全不同。
• 再比结构，不比功能。授权计量方式、国产芯片支持、存量存储协议、迁移与回退机制。这四项都不写在功能对比表上，但决定替代之后三年的处境。
• 最后把退路写进 RFP。测试验证、回滚快照、状态机完整性、日志可追溯——这四项应该和功能清单一样，成为合同条款的一部分。
有一个问题建议对每一家都问一遍：割接失败之后，回退依赖什么、需要多久、源端数据是否完整。这三个答案组合起来，就是这个项目的风险底线。
数据来源与说明
• 竞品信息来源：VMware 相关信息引自 Broadcom 官方 TechDocs（VCF 9.0 / 9.1 Licensing Overview、Offerings and Components）与 Broadcom Knowledge Base（vSphere 9.x 与 VCF 9.0 授权流程说明）；深信服相关信息来自其官网产品页、技术支持站点公开产品文档及官方博客《超详细！VMware数据迁移全流程说明书》《一份全面的VMware替换数据迁移指南》；SmartX 相关信息来自其官网 VMware 替代方案页、SMTX 迁移工具技术博客与官方答疑合集。均查证于 2026 年 8 月；其中并发数据等具体规格来自各厂商 2024 年发布的公开材料，可能已随版本迭代变化。厂商官网的宣传性表述按原文记录，本文不代为验证真伪。各厂商产品与授权条款更新较快，采购决策前请以各厂商官方最新文档为准。
• 对比方法说明：本文只列结构性事实，不做能力打分、不做优劣排序。标注“公开资料未明确”表示在公开渠道未检索到明确说明，不代表该厂商不具备相应能力，建议向厂商直接确认。
• ZStack 产品能力数据来自官方产品资料与官方发布材料；标注为内部测试环境的数据，实际表现以现场 POC 实测为准。
• 本文为选型方法参考，不构成采购结论。
