The SmartX replaces VMware solution .pdf

SmartX replaces VMware solution

1. VMware 升级替代专题
⽅案评估｜产品对⽐｜迁移与替代实践
4⼤章节，100+⻚⼲货内容
详解替代⽅案、产品功能与企业实践
渐进式实现VMware 虚拟化与全栈产品的升级替代

2. ⾃博通收购VMware，VMware产品组合和订阅模式屡次调整，⼀步步提升企业⽤户的
VMware订阅成本与使⽤⻛险。同时，持续变化的国际形势和逐步升级的国产化转型要求，
也让越来越多的企业⽤户开始思考从VMware“撤退”的必要性：
•现阶段是否有必要替代VMware？有哪些需要考虑的因素？
•如何选择VMware替代⽅案与产品？从哪个产品开始替换？怎么规划整体替换策略？
•如何将VMware虚拟机迁移⾄新平台？怎么保证迁移过程平稳可靠？
•哪些企业在⽣产环境实现了VMware替代？新⽅案的使⽤体验如何？
为了帮助企业⽤户在VMware 替代评估、选型、迁移、落地中的每个环节都做出更好的决
策，本专题电⼦书将解读VMware产品组合和订阅模式调整带来的⽤户影响，分析
VMware替代⽅案与技术路线，介绍基于SmartX企业云平台的VMware替代⽅案，对⽐
SmartX企业云平台各重要模块与VMware产品组件在功能和性能上的异同，提供虚拟机
迁移规划指导，并分享⾦融、医疗、制造等多个⾏业⽤户以SmartX企业云平台实现
VMware⼤规模替代的实践案例（含虚拟化、vSAN、Tanzu、NSX等全栈替代实践），以
期为企业⽤户的VMware替代与IT基础设施升级提供参考。
2025年6月更新
2

3. 第⼀章节：VMware 替代策略与技术路线评估
VMware by Broadcom 产品组合调整与⽤户应对策略······5
VMware 替代技术路线评估：如何实现“⽣产级”替代······20
VMware 替代技术路线评估：先替代存储，再替代vSphere······28
VMware 替代技术路线评估：渐进式替代vSphere······30
VMware 升级替代的重要关注点······32
第⼆章节：以SmartX 企业云平台替代VMware的⽅案解读与产品对⽐
以SmartX 企业云平台替代VMware 的4 种⽅案······37
SmartX 企业云平台与VMware 产品组件的能⼒对⽐······43
第三章节：从VMware 迁移⾄SmartX 企业云平台：⽅案、规划与问题处理
从VMware 迁移到SmartX 平台的两种⽅式······66
虚拟机跨平台迁移：常⻅问题与⽤户实践······69
第四章节：VMware 替代实践案例
⾏业⽤户以SmartX 企业云平台替代VMware······80
⾦融⾏业VMware 升级替代实践······81
医疗⾏业VMware 升级替代实践······89
制造⾏业VMware 升级替代实践······100
更多⾏业VMware 升级替代实践······114
更多资料······115
3

4. 第⼀章节
VMware替代策略与技术路线评估
ØVMware by Broadcom 产品组合调整与⽤户应对策略······5
ØVMware 替代技术路线评估：如何实现“⽣产级”替代······20
ØVMware 替代技术路线评估：先替代存储，再替代vSphere······28
ØVMware 替代技术路线评估：渐进式替代vSphere······30
ØVMware 升级替代的重要关注点······32
4

5. VMware by Broadcom 产品组合调整与⽤户应对策略
5
VMware by Broadcom 时代的市场趋势
l2023 年底，VMware byBroadcom 宣布
所有解决⽅案转向订阅许可证模式，并按
Core 使⽤数量授权。
l2024 年起逐步将原有的50+ 独⽴产品精简
为4 个产品组合：VVS、VEP、VVF 和
VCF。
l2025 年初，为每个产品组合设置了“最低购
买72 Core”的数量限制，并向VMware 永
久许可证⽤户发出勒令停⽌通知函，拒绝为
这些⽤户提供新的补丁或错误修复程序。
VMware 授权模式
与产品组合调整
VMware 售后服务
调整带来稳定性⻛险
订阅成本上升稳定性⻛险上升
l已有服务到期/进⾏产品升级/扩容原有集群，
必须订阅新产品组合，或购买新的add-on，
否则系统不得不“裸奔”。
l售后服务由VMware 中国区唯⼀授权总代理
伟仕佳杰提供，中国区不保留原⼚销售和售
前。

6. 6
注：
1、相⽐ESX Standard，ESX Enterprise Plus 允许⽤户使⽤更多⾼级虚拟化功能，包括分布式交换机、DRS、虚拟机加密、SR-IOV、vGPU等。
2、VVF 每Core ⾃带250GB vSAN 试⽤容量，VCF 每Core ⾃带1TB vSAN 试⽤容量，超过试⽤容量需要按容量购买vSAN 订阅，每增加1TiB 需要額外⽀付210 美元；
3、VVS 和VEP 不⽀持订阅vCenter 和ESXi之外的组件。
产品组合变化
只可使⽤传统SAN 存储，
不⽀持vSAN，按Core
收费，不⽀持VDS、
DRS、vGPU、SR-IOV
等⾼级虚拟化功能
只可使⽤传统SAN 存储，
不⽀持vSAN，按Core
收费，具备⾼级虚拟化功
能
⾃带250GB/Core vSAN
试⽤容量，更多存储容量
需购买add-on，不含
NSX
⾃带1TB/Core vSAN 容
量，更多存储容量需购买
add-on，全家桶产品包，
含NSX
VMware by Broadcom 产品组合调整与⽤户应对策略

7. 7
授权规则变化
VMware by Broadcom 产品组合调整与⽤户应对策略

8. 8
售后服务变化
•已有服务到期/进⾏产品升
级/扩容原有集群，必须订
阅新产品组合，或购买新
的add-on，否则系统不
得不“裸奔”。
•售后服务由VMware 中国
区唯⼀授权总代理伟仕佳
杰提供，中国区不保留原
⼚销售和售前。
⽤户
选择
不续保的情况下继续使⽤原有产品
•缺少维保服务，出现严重事故⾮常考验运维⼈员专业技术能⼒，
处理不当可能带来经济损失。
•⽆法进⾏扩容与产品升级，⽆法享受到最新功能与特性。
转向新产品组合并接受总代提供的维保服务
•缺少原⼚提供的维保服务，遇到严重事故难以提供原⼚级别的快
速响应与问题根因，且中国区提供的维保服务在vSAN 层⾯能⼒
有限。
•未来VMware 市场策略会持续调整，国内⽤户⾯临的使⽤⻛险将
越来越⼤。
VMware by Broadcom 产品组合调整与⽤户应对策略

9. VMware by Broadcom 产品组合调整与⽤户应对策略
⾯对VMware的收购⻛波和⼀系列订阅模式、产品组合、许可模式调整，不少⽤户会犹豫，是继续使⽤原有VMware产品，还
是采⽤新的产品组合，或是转向其他替代⽅案？
⾸先需要明确的⼀点是，并⾮所有⽤户都必须⽴刻决定是否要对原有VMware产品进⾏替代或更换为新的产品组合。⽤户的“决
策缓冲时间”取决于以下两个因素：
•原来订购的产品服务是否即将到期？如果⽤户使⽤的产品服务即将到期，由于⽆法按原价格续保，可能必须选择使⽤新的订阅
许可，或者停⽌对原产品的使⽤。如果不进⾏续保，相关系统可能不得不“裸奔”（即在没有官⽅⽀持服务的情况下继续运
⾏）。虽然在不进⾏版本升级和功能更新的情况下，部分业务也能在⼀定时期内保持稳定运⾏，暂时不需要更换产品，但缺乏
原⼚技术⽀持终究是⼀个潜在的⻛险点。
•仍在使⽤中的VMware产品是否需要进⾏版本升级或扩容？版本升级⼀⽅⾯可以增加功能、提升性能、修补bug和安全漏洞；
另⼀⽅⾯，正在使⽤的系统可能需要随业务规模增⻓⽽扩容。如果不采⽤Broadcom的新订阅模式，将⽆法对原先使⽤的
VMware产品进⾏升级或扩容。在没有版本升级或扩容需求的时期内，不必急着做出更换产品的决定。
⽤户在“决策缓冲期”内，需要根据当前系统对于现有VMware产品的使⽤情况进⾏有针对性的分析，对可替代的产品和⽅案进
⾏调研和充分测试验证，才能做出最符合⾃身利益的选择。另外需要注意的是，VMwarebyBroadcom的订阅模式与产品组合
调整已经持续了⼀年多的时间，企业⽤户的决策期越⻓，未来可能⾯对的⻛险也将越⼤。以下，我们也将深⼊分析Broadcom
进⾏的产品和订阅模式调整对不同类型⽤户带来的影响，帮助原VMware⽤户找到合适的应对⽅案，更好地适应、利⽤新的产
品组合和订阅许可模式。
9
应对策略：继续跟随还是寻找替代⽅案？不同⽤户如何选择？

10. ⼀、仅使⽤vSphere的⽤户
VMware企业产品的核⼼是计算虚拟化平台vSphere（包括vCenter作为其管理平台，以下不再重申），其丰富的虚拟机管理
功能、灵活性、易⽤性、稳定性得到⽤户的⼴泛认可。在VMware原有的客户群中，很⼤⼀部分⽤户仅使⽤了vSphere。若基
于Broadcom新⽅案使⽤vSphere，国内⽤户需⾄少以订阅⽅式购买VEP产品包。要选择使⽤Broadcom的新产品订阅⽅式，
还是其他⼚商的虚拟化产品，⽤户需要考虑的主要是这两个⽅⾯。
10
1.原业务系统对vSphere虚拟机的依赖程度
vSphere作为最成熟的Hypervisor，已经被⼤量客户⽤于承载⽣产经营的核⼼系统。因此，⽤户需要评估现有业务系统对
vSphere虚拟化的依赖程度，并结合替代决策缓冲期，整体评估是否以及如何替代vSphere。
vSphere 替代评估路线图
VMware by Broadcom 产品组合调整与⽤户应对策略

11. 若出于成本考虑，或不执着于VMware的⽤户，可以考虑其他成熟的虚拟化替代⽅案可以选择。2024年Gartner《Market
GuideforServerVirtualization》报告中提到的可选替代产品包括RedHat（OpenShift）、Microsoft（Hyper-V）、
Nutanix、华为、志凌海纳SmartX等。⽬前，国内的创新虚拟化产品都是基于KVM进⾏开发。在替代产品评估时，⽤户应该
关注产品的可靠性、稳定性和业务连续性⽀持能⼒，以及替代⽅案在⽣产环境的落地案例与实际业务承载能⼒。
2.原业务系统中使⽤的存储产品
如果将应⽤的核⼼抽象为⼯作负载和数据，其中数据的载体就是存储。⽤户在使⽤vSphere时通常依赖外部存储资源，因为单
靠节点内部硬盘⽆法满⾜⽣产业务对数据容量和可靠性的要求。将应⽤从vSphere虚拟化迁移到其他系统上时，必须保持数据
的完整和⼀致，因此考虑虚拟化替换时，也必须考虑与之配合的存储产品。
举个例⼦：假设，⽤户在原有的vSphere 环境下使⽤了第三⽅存储产品，拥有200 TiB 的总容量，实际上使⽤了100 TiB。那
么在迁移到新的虚拟化环境时，转换虚拟机格式过程中，使⽤中的100 TiB 数据也将被转移到新环境的存储资源上，但考虑到
系统冗余和维持与原有系统相同的容量性能标准，也需要配置⾄少200 TiB 的存储资源。这个例⼦说明，当考虑替换虚拟化核
⼼时，这项⼯作不仅仅涉及更换Hypervisor 软件，还需要另⾏准备⼀整套完整的新系统。这个新系统除了采购新的虚拟化软件
（Hypervisor）之外，还需要新的服务器硬件，以及新存储解决⽅案配套的硬件和软件。
vSphere 与其使用的存储必须整体替换
11
VMware by Broadcom 产品组合调整与⽤户应对策略

12. 如果当前使⽤的服务器硬件和存储系统仍然处于有效的服务期，且运⾏稳定⽆需重⼤更新，仅仅为了避免Broadcom 订阅费⽤
的⽀出⽽全⾯换⽤新系统，从TCO ⻆度计算，未必能实现节省。因此，在做出是否替换虚拟化核⼼的决策时，⽤户也需同时
考虑由此带来的存储系统的额外开销。
在考虑vSphere 和存储的替换可⾏性时，⼀种可供选择的⽅案是将“虚拟机与外置存储分离部署”的⽅式升级替换为更加简单、
弹性敏捷的超融合（HCI）系统。
采⽤“超融合”思路，可以继续使⽤vSphere 作为虚拟化核⼼，同时以更加经济的分布式存储替换传统集中式存储。这种替换不
仅可以实现虚拟化软件的平滑过渡和对原有硬件设备的有效利⽤，还能够同时实现架构升级，满⾜应⽤对存储I/O 性能的需求，
并更加灵活地⽀持系统规模的扩容。
以超融合系统对vSphere 和原有存储进行整体升级替换
12
⼆、使⽤VMware HCI（即vSphere + vSAN）的⽤户
另⼀些⽤户不仅使⽤vSphere，还同时在使⽤VMware 的超融合（HCI）解决⽅案，由vSAN 作为和vSphere 紧耦合的分布
式存储资源池。在Broadcom 新的订阅产品系列中，不再提供⾯向HCI 的专⻔产品。
VMware by Broadcom 产品组合调整与⽤户应对策略

13. 原VMware HCI ⽤户若想继续使⽤vSAN 功能，⾄少需要购买VVF 订阅许可。如果⽤户需要的vSAN 容量超过250GB/Core
试⽤容量，需要在VVF 基础上从0 开始按容量购买vSAN 的add-on 许可，每份add-on 许可扩展了1 TiB 的vSAN 存储容
量。VVF 的订阅许可费⽤再加上vSAN add-on 许可费⽤，可能会让⽤户继续使⽤vSphere 和vSAN 的总成本⾼于从前。
⽽且，在VVF 的订阅价格中，还包含了另外两种产品：Tanzu Kubernetes Grid 和Aria Operation（含原vRealize
LogInsight和vRealizeOperation）。如果⽤户没有同时使⽤这些组件的需求，仅仅为了能够继续使⽤vSAN ⽽选择订阅VVF，
也增加了不必要的⽀出。
因此，在决定是否继续使⽤vSphere 和vSAN 时，⽤户应仔细计算可能需要的存储容量以及相应的成本，来确定今后的使⽤⽅
式。归纳起来，⽤户可以有以下三种选择。
1. 使⽤外置存储替换/补充vSAN
我们前⾯提到过，vSphere 常常与外置存储解决⽅案配合使⽤。如果⽤户⾼度依赖vSphere 作为虚拟化核⼼且希望保留在
vSphere 上运⾏的虚拟机，但不⼀定要使⽤vSAN 作为存储，可以考虑将⼤部分数据迁移⾄外置存储，并配置与原有vSAN 相
同的存储容量。保留的vSphere 虚拟机仅需要购买VEP 订阅许可。当然，这将涉及新的外部存储软硬件的选型、测试、购买、
部署和迁移⼯作。⽤户可以将VEP 订阅费⽤加上与新增外置存储的费⽤，并与订阅VVF + vSAN add-on 的费⽤相⽐较，以
确定哪⼀种⽅案可以在满⾜业务需求的同时更经济。
2. 以其他超融合存储替换vSAN
⽤户也可以选择使⽤⽀持vSphere 虚拟化的其他分布式存储产品，并与vSphere 组成超融合系统。这种⽅式下，⽤户仅需购
买VEP 订阅许可，辅之以第三⽅超融合存储许可。相⽐于采⽤传统集中式存储，从基于vSAN 的超融合转为基于其他分布式
存储的超融合，可以极⼤地降低额外的存储硬件投资：因为第三⽅超融合软件可以安装在vSphere 虚拟化集群现有硬件上，并
不⼀定需要为存储系统新购服务器。⼀旦原有vSAN 上的存储数据迁移到新的超融合存储，原来被vSAN 所使⽤的硬盘资源就
可以被清空，并可以被重新加⼊到新的超融合存储资源池中，实现了数据迁移后的硬件重复利⽤。如果正在使⽤的硬件仍在正
常的⽣命周期和维保周期内，利旧这些硬件可以节省成本。相⽐之下，若选⽤外置存储产品替换vSAN，则很难利⽤原有服务
器硬件或硬盘。
13
VMware by Broadcom 产品组合调整与⽤户应对策略

14. 保留vSphere，仅替换vSAN 存储
在vSphere 虚拟化集群中内嵌其他⼚商的分布式存储组成超融合系统，国内的志凌海纳SmartX，海外的Nutanix 都有⾮常
成熟的解决⽅案，我们将在后⾯的篇章⾥详细展开。
3. 对VMware HCI（vSphere+ vSAN）进⾏整体替换
也可将vSphere 和vSAN 整体替换为其他超融合⽅案。⽅案评估时，决策者需要综合考量多个要素，确保选出的解决⽅案能
够满⾜⽣产级环境的稳定性、性能、可⽤性、可靠性，并且在总拥有成本⽅⾯具有竞争⼒。
⾸先，稳定性是⽣产环境中的关键因素。在评估替代⽅案时，实际客户⽣产环境中的部署案例是⾮常重要的参考，以确保所选
⽅案的稳定性与成熟度。
其次，在进⾏具体技术对⽐时，会涉及到以下⽅⾯：
•计算虚拟化能⼒：需要分析不同备选⽅案所⽀持的虚拟化类型，以及它们在成熟度和性能上的表现。正如之前提到的，国
内的许多虚拟化产品都是基于KVM 开发的。这些产品在虚拟机⽣命周期管理、⾼可⽤性、资源负载均衡等基本功能上，看
似与vSphere 相差⽆⼏。然⽽，当具体执⾏每项功能时，它们在性能、便利性以及执⾏结果的确定性⽅⾯的表现，则需要
通过测试或在备⽤环境中的⻓期使⽤来进⾏仔细评估和对⽐。
14
VMware by Broadcom 产品组合调整与⽤户应对策略

15. •存储虚拟化能⼒：vSAN 基于VMware ⾃有技术，能够保持⽐较稳定的研发路线图和⾃我突破能⼒，并与VMware 其他产
品之间保持良好的兼容性。国内⼤部分分布式存储是基于Ceph 或GlusterFS 进⾏开发，即便是同样基于Ceph 开发的存储
产品，在与基于KVM 的虚拟化技术组成超融合系统时，其性能表现也各不相同。因此，需要通过充分的测试对各⼚商存储
产品实际⾃主能⼒和性能表现进⾏摸底，也要对各⼚商采⽤的存储技术路线和⻓期发展潜⼒进⾏评估。
•虚拟化与存储的融合：VMware HCI 可以通过vCenter 对虚拟计算资源和分布式存储资源进⾏统⼀管理，并且可以通过增购
Aria Operation 产品实现对计算和存储资源的⻓期可视化监控和预测分析。客户选择替换⽅案时，“超融合集群的统⼀管理
能⼒”也应是重点评估的项⽬。但对备选替换⽅案管理界⾯的要求，不是对vCenter 界⾯的“机械复刻”，⽽是要通过亲⾃使
⽤，确认集群内的资源管理真正实现了⼀体化、图形化和⾃动化。
此外，软硬件的兼容性也是⼀个重要的考量因素。VMware HCI 是⼀个纯软件超融合解决⽅案，它⽀持多种硬件，并且在其官
⽅⽹站上提供了⼀个详细的兼容性列表。这使得客户可以根据这个列表挑选最合适的硬件规格和组件。对于那些不提供⼴泛硬
件兼容性的超融合替代⽅案来说，客户可能需要改变原有的采购模式和渠道，且现有的硬件设备在替代⽅案中可能⽆法得到重
复利⽤。因此，软硬件的兼容性不仅仅是技术问题，⽽且直接影响到客户超融合系统的总拥有成本（TCO）。
15
将vSphere & vSAN 整体替换为新超融合系统
VMware by Broadcom 产品组合调整与⽤户应对策略

16. 三、使⽤VMware SDDC 解决⽅案的⽤户
原VMware 的软件定义数据中⼼（SDDC）解决⽅案提供了全⾯⽽集成的IT 基础架构，通过多种VMware 的产品组件（包
括但不限于vSphere、vSAN、NSX、TKG、vRealize Suite），⽤户可以轻松管理和部署虚拟化资源。
Broadcom 新的订阅产品中VVF 和VCF 都包含了多种原VMware SDDC ⽅案中的产品组件。⼆者区别如图：
16
其中，VCF包含的组件更丰富，可以提供SDDC⽅案
使⽤的功能全集。但在国内使⽤VMwareSDDC⽅案
的客户中，⼤多数只使⽤了以上VVF/VCF产品中的
部分组件，如NSX、TKG、AriaOperation。
Broadcom新⽅案的VCF“全家桶”配置超出了⼤多数
国内⽤户的使⽤范围。⽤户如果只因为要继续使⽤其
中的某些功能，⽽必须订阅全套产品，⽆疑将导致许
可费⽤的极⼤增加。
在这种情况下，SDDC⽤户可以考虑采⽤“先周边，再
核⼼”的分步替代策略。鉴于⽤户对VMware最依赖
的产品是计算虚拟化的核⼼——vSphere，其他组件的
替换不会对核⼼⽣产系统造成致命影响。
因此，⽬前使⽤VMwareSDDC解决⽅案的⽤户可以
继续使⽤仅包含vSphere的VVS订阅产品，并⽤具
有相似功能的第三⽅软件替换SDDC⽅案中的其他组
件。这样，在减少费⽤的同时，逐步摆脱对VMware
byBroadcom的依赖。
VMware by Broadcom 产品组合调整与⽤户应对策略

17. 以下将逐⼀分析BroadcomVCF产品套件
中，除vSphere和vSAN（前⽂已分析）以
外，其他主要产品的可替代⽅式。
从表格可以看出，如果选择替换NSX，将可
能遇到业务连续性的挑战，替换难度⼤；⽽
其他⼏种产品组件的替换则相对容易。
如果⽤户正在使⽤的只是以上1~2种产品/
组件，其替换过程会⽐较顺利（除了NSX），
“逐步替代”的策略较为可⾏且⾼效。
如果⽤户正在使⽤上述的全部产品，则不建
议采⽤来⾃多家⼚商的产品进⾏零星替换。
这是因为，所选择的替代产品可能五花⼋⻔，
将vSphere与新引⼊的各种产品整合起来，
需要相当⻓的时间，并且要达到熟练的运维
⽔平也不易。在这种情况下，最佳的选择是
要么保持原有的技术⽅案（但需更改为
BroadcomVCF的订阅许可），要么选择其
他⼚商提供的⼀体化“全栈替代”⽅案。
17
VMware by Broadcom 产品组合调整与⽤户应对策略

18. 四、如何全⾯替换原VMware 产品构成的系统
以上⼏类⽤户在经过对现状和未来需求的分析后，出于成本考虑、信创合规或其他原因，可能最终决定对包括vSphere 在内的
VMware 产品进⾏全栈替换。这个“全栈替换”该从何⼊⼿呢？
⾸先，⽤户应确保维持现有使⽤VMware 产品的⽣产环境稳定运⾏。同时，开始对虚拟化核⼼软件vSphere 的替代产品进⾏
调研和测试。备选⼚商最好有能⼒提供与VMware SDDC ⽅案相匹配的全栈产品（包括但不限于虚拟化计算、存储、⽹络与安
全、容器管理、运维管理、灾备、迁移等全⾯的IT 基础设施能⼒），以减少⽤户在多个独⽴⼚商的产品之间进⾏选择的⼯作量
和难度，更快地形成可⽤的备选⽅案。
根据Gartner 发布的全球《全栈超融合软件市场指南》，⽬前具备VMware 替代能⼒的成熟超融合⼚商包括Nutanix、
Microsoft、志凌海纳SmartX 等。选择替换⽅案时，需要重点评估Hypervisor、分布式存储和虚拟化⽹络与安全这三个核⼼
产品组件的功能、稳定性和性能是否满⾜⽣产级替换的要求。对“⽣产级替换”的评估条件包括但不限于：
1.⽣产级稳定性、性能和实际案例
2.开放性和兼容性
3.信息技术应⽤创新适配状况、⾃主研发能⼒、本地服务能⼒
具体“⽣产级”能⼒要求与评估⽅法，我们将在后⾯章节详细展开。
接下来，基于初步选择的备选⽅案，构建⼀个新的基础设施平台⽤于测试，或作为⽣产集群的备⽤集群。在这个新平台上，⽤
户可以通过应⽤迁移、存储迁移或应⽤重构等⽅法，将⽣产环境的应⽤软件、虚拟机、备份数据转移过来，组成完整的⽣产系
统。随后，需要经过⼀段时间的全⾯测试和压⼒条件下的性能与稳定性验证，才能确保新系统的完整性、稳定性、可靠性和业
务连续性符合“⽣产级”要求。并且，在IT 部⻔⼈员熟悉了新系统的运维操作后，⽤户才可以考虑将新⽣产系统正式代替原来
基于VMware 基础设施平台的系统。
18
VMware by Broadcom 产品组合调整与⽤户应对策略

19. 只有经过以上严谨细致的替换准备，才能确保替代⽅案顺利接替原VMware 产品的⼯作，从⽽逐步减少对Broadcom 产品的
依赖。否则，如果新系统未经充分验证仓促上线，不断的故障反⽽会对⽤户正常的业务开展和后续替换⼯作带来负⾯影响。
在选择替换⽅案时，除了评估软件功能和性能之外，还应当对当前运⾏VMware 软件的硬件平台进⾏评估。如果现有的硬件仍
在正常的使⽤周期和维保期内，应考虑其再利⽤潜⼒。
尽管这些硬件在替换后不再承载基于VMware 软件的⽣产系统，但它们的性能和容量仍能满⾜⽣产级要求，应当继续得到妥善
利⽤。⼀些⼚商的整体替换⽅案要求必须使⽤特定的硬件型号，⽆法兼容其他服务器，甚⾄⽆法继续使⽤原有⽹络设备，这会
造成⽤户资产的浪费。
因此，在评估替代VMware 的产品时，可优先考虑那些能够实现与现有硬件平台兼容的软件解决⽅案。这样，在⽣产系统迁移
到新平台之后，新的全栈软件⽅案也可以在原有硬件资源上运⾏，作为新系统的备份或其他⽤途。通过硬件利旧，⽤户可以降
低总体拥有成本(TCO)，获得更加经济、⾼效和可靠的过渡路径。
总的来说，对于那些过去⼏年内已经累积了替代VMware 的产品和技术储备、进⾏了充分产品选型和⽅案验证的⽤户来说，⾯
对Broadcom 对产品销售和定价模式的改变，现在就可以从容应对，依托于已验证的全栈解决⽅案，顺利替换掉现有的
VMware 体系。
对于尚未进⾏这些准备⼯作的⽤户，现在开始着⼿也为时不晚。我们经常听到这样的说法，“种⼀棵树，最好的时间点是⼗年前，
其次是现在。”在VMware 替代这件事上也可以套⽤这句话：“进⾏VMware 替换的技术准备，最好的时间点是⼀年前，其次
是现在”。
点击链接，阅读原⽂：
⼀⽂解读VMware by Broadcom
产品组合与⽤户应对策略
19
VMware by Broadcom 产品组合调整与⽤户应对策略

20. VMware 替代技术路线评估：如何实现“⽣产级”替代
⽬前市场上已出现许多替换VMware 的⽅案，尤其是在替换vSphere 上选择颇多，但⽤户的痛点问题依然没有得到解决。
VMware 的替换⽅案不能仅仅停留在能⽀持虚拟桌⾯、开发测试等⼀般业务上，还需具备能运⾏在⽣产环境、承载⽣产业务的
能⼒，才能解决真正的问题。
替换VMware 为核⼼的基础设施从何⼊⼿
如果将应⽤的核⼼精炼抽象为⼯作负载和数据，那么虚拟化应⽤的核⼼就是Hypervisor 和存储。VMware 的vSphere 作为最
成熟的Hypervisor，⽆论在国外或是国内的虚拟化市场都占据着举⾜轻重的地位。这也是为什么在⾯临当今环境时，必须⾸先
考虑⽤什么样的技术和产品可以⽀撑vSphere 留下的空⽩。与应⽤⼯作负载关联最紧密的是数据，⽽数据的载体是存储。将应
⽤从vSphere 虚拟化迁移到其他系统上的同时，必须保持数据的完整和⼀致，那么是否要同时更换存储产品，也是要与替换
Hypervisor 同步考虑的问题。
因此，⾸先要确定这两部分的替换⽅式和⽅法，尽量使得现有应⽤可以平滑迁移到新的虚拟化系统和存储上
（Replatforming）；再以新的虚拟化和存储为核⼼考察其他组件的替代产品，分阶段、分步骤完成所选全部产品组件在⽣产
环境的集成。
其次，如果现有应⽤环境中正在使⽤的VMware 组件不仅仅是vSphere 和vSAN ，那么进⾏组件对位替换的复杂度和⼯作量
就会⼤⼤增加，⽽替换效果也难以预期。我们从计算、存储、管理、灾备、⽹络等各个⽅⾯，对需要考虑的因素进⾏了梳理，
并将要点概况在下图中，供读者参考。
20

21. 可能读者觉得上图太过复杂。这也正反映出对使⽤中的⼏种、⼗⼏种相关软硬件进⾏逐⼀评估和替换操作的难度。如果换⼀个
思路，不是在组件级进⾏逐⼀替换，⽽是采⽤私有云或专有云⽅式整体替换现有VMware 环境，也是应当被考虑的⽅式。那就
不仅仅是对基础设施层进⾏重建（Replatforming）了，还需要做应⽤和数据的迁移。有些⽤户选择使⽤免费的容器虚拟化技术
⾃建平台来替代商业产品，那还需要重构应⽤（Rearchitecting）。
VMware 替代技术路线评估：如何实现“⽣产级”替代
组件级替换要考虑哪些方面
21

22. 下⽂中，我们对可能性⽐较⾼的国产化替换技术路线进⾏了分析。⽆论采⽤哪种技术路线、哪种⽅案和产品对现有VMware 环
境进⾏替换，都不能100% 保证在功能特性和使⽤体验⽅⾯的完全⼀致。因此，最终的替换决策必然是在认真评估后做出的主
动调整：放弃部分⾮核⼼、不必要的功能，或通过应⽤层、架构层的改造以达到同样的效果。
可选技术路线：组件级对位替换或整体重构
22
VMware 替代技术路线评估：如何实现“⽣产级”替代

23. 技术路线⼀：聚焦替换vSphere 并兼顾存储
虚拟化基础设施的核⼼是Hypervisor 和存储。⾸先，从Hypervisor 技术和产品⻆度考虑：有可能⽤于填补vSphere 空⽩的国
内虚拟化产品都是基于KVM 进⾏的开发。我们从Gartner 2024《全球服务器虚拟化市场指南》：Market Guide for Server
Virtualization可以看到，国产虚拟化代表⼚商和产品包括华为DCS、浪潮InCloudSphere、新华三H3CCAS、志凌海纳
SMTXOS等。替换的⽅式可以参考上⼀章节“仅使⽤vSphere 的⽤户”中的内容。
再考虑虚拟化环境中使⽤的存储：在国内⽤户的vSphere 部署中，⼤部分采⽤了集中式SAN 存储与之配合。那么，替换
vSphere 的⽅案，也必须包含对集中式SAN 存储部分的考虑。⽐如，既有SAN 存储产品是否为国外品牌？是否在vSphere
替换的同时，将SAN 存储也替换为国内⾃主研发的、符合信创要求的产品？
2024年IDC 报告列出的中国企业级外置存储头部⼚商包括华为、新华三和浪潮，采⽤的都是全⾃研的存储产品。在vSphere
的国内部署中，已经有很⼤部分⽤户采⽤了这些国产存储产品，以国产存储替代国外同类产品，并不存在障碍。对于这⼀部分
⽤户，⾸先考虑选择成熟的KVM 虚拟化软件作为vSphere 的替代者。虚拟化与存储之间通过iSCSI、NFS 等标准接⼝连接，
这就为保留现有国产集中存储、并逐步将⾮国产存储产品进⾏替换创造了条件。
针对这个⽅案需要注意的是：由于SAN 存储系统的复杂性，应对企业数字化业务快速增⻓的弹性需求已经捉襟⻅肘，⽬前
SAN 存储的分布式和软件定义转型也已经是⼤势所趋。这时也可以选择⽀持vSphere 虚拟化的国内超融合⼚商，先完成存储
部分的转型和替换，再逐步实现对vSphere 的替换。
技术路线⼆：置换为超融合HCI
在虚拟化和存储的改造过程中，有些⽤户也有可能将“虚拟机与外置存储分离部署”的⽅式替换为更加简单、弹性敏捷的超融合
（HCI）⽅式。
23
VMware 替代技术路线评估：如何实现“⽣产级”替代

24. 在这个领域，Gartner2025 中国区超融合市场竞争格局报告：Competitive Landscape: Chinese HCI Vendors显示，中国
超融合⼚商包括以华为、浪潮、联想为代表的⼤型数据中⼼基础设施⼚商、以志凌海纳SmartX为代表的专业超融合⼚商，以
及以深信服为代表的来⾃安全、云等相关领域的跨界⼚商。其中SmartX 作为独⽴的超融合⼚商，在IDC超融合软件中国市场
份额统计中连续两年（2023-2024）位列第⼀，受到众多⾦融、医疗、制造等领域的头部企业⻘睐。
从SmartX 等⼚商的⾏业案例可以看到，对于现有基础架构为vSphere + SAN 存储的⽤户，将其替换为国产超融合⽅案已经
得到⽣产环境的验证。同时，选择国产⾃主研发的超融合产品不仅意味着实现VMware 替换，更能实现从传统架构到分布式架
构和软件定义⽅式的转型——简化了虚拟化计算和存储的层次结构，落地容易，弹性很好，按需扩展（通常3 个节点起步），
⻛险更低。Gartner报告中也明确对⽐了超融合相⽐其他替代⽅案的优势——架构简单、不改动业务流程、迁移难度⼩、适⽤
场景更⼴泛。
24
Gartner为企业⽤户提供的VMware替代路线对⽐
以SmartX为代表的专业超融合⼚商，也可提供全栈超融合基础设施解决⽅案，帮助企业⽤户逐步实现VMware虚拟化、
vSAN及其他周边组件的全栈替代，并进⼀步实现信创转型。
VMware 替代技术路线评估：如何实现“⽣产级”替代

25. 技术路线三：转向整体私有云⽅案
国内的整体私有云解决⽅案⼤部分以OpenStack 为基本技术栈进⾏开发。OpenStack 基于⼤量开源项⽬组成，并经过各个⼚
商的商业开发，形成了多种商⽤云⽅案。OpenStack 全⾯的云⽅案可以同时管理IaaS 层的资源池（服务器、存储和⽹络），
将不再需要分别从计算、存储或⽹络的⻆度考虑对VMware 的替换路线图，⽽是从整体“私有云”维度进⾏重建。
基于开源OpenStack ⽅案的⼀个优势是，可以快速从社区获得最新的功能。在OpenStack 社区贡献度排⾏榜上，国内云企业
近年来也名列前茅。
不过⽬前基于Openstack、Ceph 构建的私有云⽅案，由于模块众多、商⽤化程度有限、稳定性⽋佳，因⽽⼤部分部署在开发
测试环境，不能实现对⽤户架构的真正统⼀，没有真正达到⽤户云化转型的预期效果，在热度过后，理性⽤户已经开始更加谨
慎地选择类似的架构。
技术路线四：依托公有云技术栈的专有云/专属云
专有云（Dedicated Cloud）是以公有云为基础，⾯向特定⾏业、特殊需求的云客户，提供全栈资源池的私有化解决⽅案。专
属云客户可以选择在公有云上独占机架、服务器和⽹络，通过基础设施隔离获得资源的专属使⽤权和安全性。
专有云/专属云在⼀定程度上减轻了国内⽤户对公有云资源共享模式带来的安全合规、数据私密性等⼀系列顾虑，也在规模化部
署、快速交付和集中运维⽅⾯享有了公有云深厚技术底蕴带来的福利。国内的主要公有云服务商都可以提供专有云/专属云服务，
通常⾯向规模较⼤的国企、央企、集团公司、⾦融等⾏业。
由于专有云/专属云所依赖的公有云技术在管理平⾯的开销较⼤，起步即要求⼗⼏个甚⾄更多节点（管理节点的要求）。这导致
专有云/专属云的⾸次投⼊占⽐⼤，⽽且普通⽤户往往不具备运维这种规模的云平台的能⼒。除了⼤型客户以外，其他客户很难
承受其巨⼤的投⼊和运维压⼒。因此，专有云和专属云的建设和运维通常仍由公有云提供商承担。
25
VMware 替代技术路线评估：如何实现“⽣产级”替代

26. ⽣产级替换评估要点
以上给出的⼏种对VMware 进⾏替换、升级的⽅式⽅法，也要根据不同⾏业、不同规模的企业⽤户的具体情况进⾏适⽤程度分
析和选择。但⽆论哪种⾏业、何等规模的替换，都必须以“符合⽣产级要求”作为⽅案的核⼼评估准则。
替换⽅案的核⼼要求是“⽣产级”：如果选择的替换⽅案在性能、可靠性、安全性和⽀持⼒度⽅⾯不能达到“⽣产级”标准，那么
为了替换⽽替换将对业务带来直接影响，得不偿失。
替换的可⾏之路是“取舍”：针对⽅案中的“⽣产核⼼”相关组件和功能，必须以最严格的要求衡量可⽤的替代产品和⽅案；⽽对
于⾮⽣产核⼼相关部分，可以暂不替换，或者选择接受现在还不那么完美的⾃主研发⽅案。
26
VMware 替代技术路线评估：如何实现“⽣产级”替代

27. 对“⽣产级替换”的评估条件包括但不限于：
1、⽣产级稳定性、性能和实际案例
新⽅案必须具备在⽣产环境实际部署的案例，以及在真实⽣产中证明的稳定性和性能指标。前述国内主要的IT 解决⽅案或云运
营商的产品和系统已经在国内客户获得了普遍的应⽤。企业和单位⽤户需要根据本⾏业特点和本企业应⽤规模，在众多⽅案案
例中选择最匹配的作为参考，从⽽建⽴对替换效果的准确预期。同时，在产品评估时更应该针对业务连续性和数据可靠性相关
的能⼒，以及实际⽣产业务承载能⼒（⽽不是⼚商“标称”性能）进⾏评估。
2、开放性和兼容性
VMware 已经形成了⼀个开放的⽣态系统，很多场景中，⽤户仅仅使⽤了vSphere 作为虚拟化系统，其余组件都来⾃VMware
⽣态圈的其他⼚商，也有很多国内的软硬件产品与vSphere 兼容共⽣。在国产化、⾃主研发和信创环境下，提⾼开放性和兼容
性，有助于促进原有配合vSphere 的产品和⽅案快速转向与国产虚拟化和云计算平台的合作共赢。
3、信创适配状况、⾃主研发能⼒、本地服务能⼒
在当前背景下选择⽤于替换VMware 的产品和⽅案，必然要考虑到新⽅案的⾃主可控程度，与国内的“信创”⽣态环境的适配程
度，既要考虑现有信创硬件与软件之间的适配，也要考虑提供商的⾃主研发实⼒，确保产品和⽅案的⻓期路线图可以适应信创
⽣态系统的不断发展。
不仅是产品和⽅案本身，被选中的新⽅案提供者是否具备⾜够的技术服务能⼒，是否可以协助最终⽤户完成迁移并稳定运维，
也是⼀项重要的考虑因素。特别是，与具有成熟⽣态的商业⽅案相⽐，当前很多信创产品和⽅案仅能由原⼚进⾏实施和维护，
原⼚服务⼈员的技术能⼒就成为了重要的影响因素。
点击链接，阅读原⽂：
⽣产级VMware 虚拟化⽅案替换
路线与评估
27
VMware 替代技术路线评估：如何实现“⽣产级”替代

28. VMware 替代技术路线评估：先替代存储，再替代vSphere
基于不同环境的具体情况，VMware 替代过程或许需要逐步推进。例如，您的架构在短期内还需要持续采⽤vSphere。或者，
您希望优先解决SAN 存储带来的性能瓶颈和运维复杂问题。
通过引⼊超融合架构，企业⽤户可以先完成存储的分布式云化转型和转型，再从vSphere 平台逐步迁移，实现虚拟化的转型，
有效降低转型的难度和⻛险。
由SAN 存储引起，且亟待解决的问题
难以快速应对业务及资源需求变化
对于业务系统来说，很多时候计算资源和存储资源的需求增⻓并不同步。对于已上线的业务系统，在⼀段时间内计算资源的消
耗通常是固定的（除⾮业务量短时间内爆发增⻓），但存储资源消耗的增⻓却是持续的（系统每⼀秒钟都在产⽣新的数据并要
求存储下来）；⽽对于新业务增⻓，计算和存储资源的需求是同时发⽣的。这个因素也使得存储资源的需求变化来得更为剧烈。
⽽在传统架构中，计算资源和存储资源是独⽴管理的。服务器虚拟化使得计算资源的扩展变得简单，并且服务器的采购流程和
上线流程⼀般都⽐较短（通常可以控制在2-3 周左右），企业甚⾄可以库存少量服务器，应对突发的需求。
当存储资源不⾜的时候，由于SAN 存储设备采购和部署的流程很⻓（通常需要1-2 个⽉，甚⾄更⻓），并且库存也更为困难
（配置难以标准化，成本更⾼）。最终导致的结果是：基础架构难以快速适配业务的资源需求变化。
28

29. VMware 替代技术路线评估：先替代存储，再替代vSphere
加剧基础架构管理的复杂性
•性能问题难以解决：随着服务器的CPU 核数越来越多，虚拟机部署密度越来越⼤，并发访问存储的压⼒也随之增⼤；然⽽
单台SAN 存储的性能则受限于存储控制器（上限基本固定），即使存储容量在扩展，但存储性能并⽆法得到线性的扩展
（反⽽呈现抛物线）。随着数据量增加，并发访问压⼒增⼤，最终导致存储的延时不断增⼤，系统响应不断变慢，业务部⻔
频繁投诉；对于这⼀切，管理员似乎(除了申请另购新的存储设备之外)束⼿⽆策。
•繁重的数据迁移⼯作：新增存储设备并不能轻易解决问题，多个存储设备的资源并没有实现池化，管理员需要不断地在不同
的存储之间执⾏数据迁移以维持负载的平衡；在⼀些新⽼存储替换时，管理员甚⾄需要处理上百个存储卷的迁移，⼯作不但
繁复，且容易误操作。
•数据管理，运维压⼒⼤：RAID 组数据恢复窗⼝⻓这件事⼀直困扰着管理员，⼀块TB 级别容量硬盘发⽣故障，恢复时间数
⼩时到数天不等，数据恢复过程对存储性能影响较⼤，并伴随数据丢失⻛险，甚⾄恢复过程经常需要⼈⼯⼲预；因此，管理
员经常承受较⼤的压⼒。
⽐较新的SAN 存储控制器升级已经可以⽀持在线执⾏，但前提是多链路的设计得当，否则很容易出问题，对管理员的专业性
要求⽐较⾼。
当你同时拥有多套SAN 存储时，以上问题会迅速蔓延，管理复杂性⼤幅增加。当然有⼈会说传统存储更通⽤，但当你的业务
越来越多运⾏在虚拟化环境中，那就更难找到⾮传统存储不可的理由。正是这些问题促进了超融合架构的诞⽣。
点击链接，阅读原⽂：
⼀⽂了解信创背景下SAN 存储转
型路线
29

30. VMware 替代技术路线评估：渐进式替代vSphere
vSphere作为核⼼虚拟化组件，已经被⼤量企业⽤户⽤于承载⽣产经营的核⼼系统。因此，⽤户对于vSphere的替代往往更加
谨慎，也希望以“先试点验证，再逐步迁移”的渐进式策略推进vSphere替代进程。针对不同的使⽤情况与替代需求，我们在下
图中梳理了企业⽤户的vSphere渐进式替代路线图。
30
vSphere渐进式替代路线图

31. VMware 替代技术路线评估：渐进式替代vSphere
决策⼀：是否继续使⽤vSphere
如果企业⽤户IT系统和应⽤系统对vSphere依赖程度较⾼，且国产化/信创转型需求不严格，可能选择保留vSphere使⽤习
惯，降低核⼼虚拟化替代⻛险。此时，⽤户可选择所有集群均使⽤vSphere，先替代存储或其他周边组件，再推进vSphere替
代。具体可参考上⼀篇⽂章“VMware 替代技术路线评估：先替代存储，再替代vSphere”。
⽤户也可选择仅核⼼⽣产环境继续使⽤vSphere，新建具备全栈国产化替代能⼒的新平台，承载⾮核⼼⽣产业务系统或新上业
务系统，同时完成存储（及周边组件）的替代，降低vSphere的依赖程度。
若企业⽤户未来不希望继续使⽤vSphere，可以采⽤“新建具备全栈国产化替代能⼒的新平台，与原vSphere集群并⾏”的策略，
在验证新平台能⼒后进⾏整体迁移。
决策⼆：替换时间是否紧迫
我们在“VMware by Broadcom 产品组合调整与⽤户应对策略”⽂章中提到，企业⽤户的“决策缓冲期”取决于已有VMware服
务何时到期，以及使⽤中的产品是否需要升级/扩容这两个因素。如果⽤户希望替换vSphere且替换时间不紧迫，则可以针对
新平台在多种业务场景下的替代能⼒进⾏全⾯验证，随后将vSphere虚拟机迁移⾄新平台。若⽤户的替换时间⽐较紧迫，则可
针对核⼼业务场景重点验证新虚拟化平台的替代能⼒，随后进⾏业务迁移。
更多资料：
基于VMware vSphere 的超融合
平台怎么选？
31

32. VMware 升级替代的重要关注点
SmartX举办的VMware升级替代研讨会重点分享了VMware改采订阅制的影响和⽤户可采⽤的应对策略。会后我们共收到
143份调研反馈（其中56份来源于⾏业⽤户），以下数据可供参考：
Q. 贵单位计划采用哪种技术路线实现VMware 替代？(单选)
约29% 的用户倾向“使用超融合架构实现VMware 虚拟化和存储替换”，18%
的用户倾向“VMware 和三方技术共存”，仅3% 的客户选择了“仅虚拟化产品
的直接替换”。
32

33. VMware 升级替代的重要关注点
Q. 对于VMware 产品替代，以下哪一项是您比较担忧的问题？（多选）
约24% 的用户担心其“迁移过程太复杂，对现有业务影响大”；19 % 的用户担
心“第三方产品可靠性无法达到要求”；18% 的用户担心“第三方产品缺乏成熟
的技术服务与支持，进而对业务造成影响”。此外，产品兼容和产品也是
用户们较为担忧的问题，其分别占比17% 和13%。
33

34. VMware 升级替代的重要关注点
Q. 贵单位是否在使用超融合基础架构？（单选）
大部分用户（约52%）对超融合技术较为熟悉，正在使用VMware 超融合或
第三方超融合产品。剩余约23% 的用户，虽未使用过超融合，却正在评估该
技术。
34

35. VMware 升级替代的重要关注点
35
基于问卷数据，我们也整理了企业⽤户在进⾏VMware替代⽅案选型时，需要重点关注的4⼤⽅⾯——稳定可靠、易于运维、
灵活开放、迁移平滑。

36. 第⼆章节
以SmartX企业云平台替代VMware
的⽅案解读与产品对⽐
Ø以SmartX 企业云平台替代VMware 的4 种⽅案······37
ØSmartX 企业云平台与VMware 产品组件的能⼒对⽐······43
36

37. 以SmartX企业云平台替代VMware的4种⽅案
作为具备⾃研实⼒的专业⼚商，志凌海纳SmartX为企业⽤户提供基于超融合架构的SmartX企业云平台，可实现VMware
全栈⽣产级替代——运维管理平台CloudTower 可替代vCenter Server 及Aria，SMTX Kubernetes 服务可替代Tanzu，
SMTX OS 中的原⽣虚拟化和分布式存储可分别替代vSphere 和vSAN，⽹络与安全Everoute 可替代NSX，SMTX 备份与恢
复可替代VMware vReplication和SRM。
37

38. 以SmartX企业云平台替代VMware的4种⽅案
38
针对不同使⽤场景，SmartX提供4种以SmartX企业云平台替代VMware的⽅案。

39. 以SmartX企业云平台替代VMware的4种⽅案
39
⽅案⼀：替代vSphere并升级⾄超融合架构
使⽤VMware虚拟化和集中式存储的⽤户，可以整体升级⾄SmartX超融合架构，实现虚拟化国产替代的同时，获得更可靠、
灵活、⾼性能的分布式存储服务。
•SmartX原⽣虚拟化ELF：基于KVM 深
度研发，具备完整的计算虚拟化、虚拟机
全⽣命周期管理等功能。
•SmartX⾃主研发的分布式存储ZBS：
提供⾼性能、⾼可靠的分布式块存储与⽂
件存储服务。
•多集群管理平台CloudTower：⼀套软件
管理分布在多数据中⼼中的SmartX集
群，提供全⾯的集群管理、监控、运维、
升级等功能。
替代优势
•架构升级：以超融合架构替代传统虚拟化+集中式存储架构，获得更灵活的⾼性能分布式存储服务。
•国产虚拟化：基于KVM 深度研发，具备DRS、SR-IOV、vGPU等对标vSphere Enterprise Plus 的⾼级虚拟化功能。
•免费迁移⼯具：提供免费的⽆代理迁移⼯具SMTX 迁移⼯具，将VMware 虚拟机灵活迁移⾄SmartX平台。

40. 以SmartX企业云平台替代VMware的4种⽅案
40
⽅案⼆：替代vSAN并保留vSphere使⽤习惯
使⽤VMware 原先独⽴售卖的vSphere 和vSAN 的⽤户，可以整体替换为SmartX 超融合，或保留vSphere 使⽤习惯，仅将
vSAN 替换为SmartX 分布式存储，避免转向VMware vSphere Foundation/VMware Cloud Foundation 等新的VMware 产
品组合。此时，⽤户可选择两种部署形式，包括与vSphere 融合部署在同⼀硬件服务器上的超融合架构，和基于SMTX ZBS
的存算分离架构。
•SMTX OS ⽀持vSphere 融合部署的形
式，可在沿⽤VMware 虚拟化完整⽣态
的同时享有SmartX 超融合的优势。
•SMTX ZBS采⽤存算分离的部署形式，
可为⼤规模虚拟化、私有云和容器环境提
供⽣产级分布式块存储和⽂件存储。
替代优势
•灵活替代：原VMware ⽤户可以仅替换vSAN 但保留vSphere 使⽤习惯，避免转向新的VMware 产品组合。
•双重架构选择：⽀持与vSphere 融合部署的超融合架构，和基于SMTX ZBS 的存算分离架构。
•⾃主可控：基于⾃主研发的分布式存储，具备⽣产级⾼可⽤特性，提供优于vSAN 的性能和稳定性表现。
•统⼀纳管：以CloudTower和vCenter统⼀管理ELF 和vSphere 集群，降低管理难度，帮助⽤户实现逐步替代。

41. 以SmartX企业云平台替代VMware的4种⽅案
41
⽅案三：以SmartX企业云平台提供虚拟机-容器融合解决⽅案
有容器使⽤需求的⽤户，可以采⽤SmartX 企业云平台提供的虚拟机-容器融合解决⽅案，以SmartX 超融合和Kubernetes
服务（SKS）模块替代VVF ⽅案，避免⾼昂的订阅成本，并获得更简单的使⽤与管理体验。
替代优势
•模块化组件，灵活选配：SmartX 企业云平台⽀持⽤户以模块化的⽅式按需选配多项基础设施组件，构建灵活、弹性的企业
云平台。
•按需购买，成本更低：SmartX 企业云平台多种⽅案均⽀持选配SKS 服务，可按需购买，⽆需⾼昂的VVF 订阅成本。
•虚拟化-容器统⼀管理：⽀持以⼀套可视化界⾯统⼀管理虚拟化-容器混合⼯作负载及其⽹络安全策略，提供优于VMware
的使⽤与管理体验。
SMTX Kubernetes 服务（SKS）不仅提供
简单易⽤的Kubernetes 集群⽣命周期管理
功能，还具备相⽐vSphere with Tanzu 更
友好的图形化界⾯、更细致的多租户管理粒
度和更丰富的可观测能⼒。⽀持基于虚拟化
和物理机两种部署⽅案。⽀持以⼀套可视化
界⾯统⼀管理虚拟化-容器混合⼯作负载及
其⽹络安全策略。

42. 以SmartX企业云平台替代VMware的4种⽅案
42
⽅案四：以SmartX企业云平台实现VMware全栈替代
SmartX企业云平台与VCF类似，可以提供云基础资源池的全栈功能。但相⽐⽽⾔，SmartX企业云平台更加灵活，允许客户
以模块化的⽅式按需选配容器管理、备份与容灾、⽹络与安全、⾃服务平台等多种组件，灵活推进基础设施全栈国产化转型，
同时避免⾼昂的订阅成本。
替代优势
•模块化组件，灵活选配：SmartX 企业云平台⽀持⽤户以模块化的⽅式按需选配多项基础设施组件，构建灵活、弹性的企业
云平台。
•全栈⽀持，成本更低：以SmartX 企业云平台实现VMware 全栈替代，更贴合国内⽤户使⽤需求，同时节省⾼昂的VCF 订
阅成本。
•⼀套平台全局管理：⼀套可视化平台实现企业云基础设施集群统⼀管理、运维、监控、升级、⽹络流量可视化、VPC、异常
隔离等能⼒，避免VMware 复杂的多平台管理。
•SMTX ⾃服务中⼼为云服务器（虚拟机）
最终⽤户提供⾃助申请和使⽤SmartX
企业云资源的途径，帮助⽤户实现⾃助交
付。
•SMTX 备份与容灾为SmartX 超融合和
分布式存储提供原⽣的备份与容灾功能，
可通过简单的操作，为数据中⼼⼯作负载
提供提供⼀体化、更易⽤的灾备解决⽅案。
•Everoute提供分布式防⽕墙、负载均衡、
虚拟专有云⽹络（VPC）、容器⽹络等⽹
络与安全能⼒，提供"⼀站式"管理体验。

43. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
对VMware 的替代往往涉及到多个⽅⾯的评估，尤其是各类功能特性。以下，我们将针对SmartX 和VMware ⽅案中的重要
组件及其功能进⾏详细对⽐，并针对关键功能/特性进⾏解读，帮助您进⾏深⼊的产品评估。
43
虚拟化组件：SmartX原⽣虚拟化ELFvsVMwarevSphere

44. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
替代优势
•⽣产就绪：通过虚拟机⾼可⽤、虚拟机热迁移、虚拟机快照、虚拟机克隆、原⽣⽀持的备份与容灾等多种⽅式保障业务⾼可
⽤。
•简单易⽤：提供简单易⽤的管理功能，优化使⽤体验，包括动态资源调度（DRS）、USB 跨主机直通、⽀持内容库与跨集群
热迁移实现便捷的多集群资源管理等。
•深度优化：基于KVM 深度研发，实现虚拟化功能优化，满⾜⾼性能需求，包括Boost 模式、NUMA 亲和性调度等。
•信创⽀持：适配多种国产CPU、国产操作系统、国产GPU、国产加密卡、国产万兆⽹卡，满⾜安全合规要求，提供全⾯信
创⽀持。
44
虚拟机⾼可⽤故障场景覆盖与处理机制

45. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
45
存储组件：SmartX⾃研分布式存储ZBS和SFSvsVMwarevSAN

46. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
磁盘架构、配置要求与限制对⽐
46

47. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
替代优势-块存储
•更卓越的性能：
üZBS 在基准性能、⻓期压⼒性能、快照后性能、故障场景性能等多个场景下均表现出优于vSAN 的性能表现，虽然vSAN
8.0 引⼊了ESA 架构，在空间利⽤率、性能等⽅⾯实现了提升，但ESA 架构需要采⽤全NVMe SSD，硬件采购成本更⾼。
ü混闪配置或多种类型SSD 全闪配置的集群中，ZBS 可以利⽤常驻缓存功能保证部分卷的数据不下沉，更为灵活地在单⼀
集群中满⾜不同应⽤的性能要求。
üZBS 在数据空间分配时，综合考虑本地优先、拓扑安全、局部化、容量均衡等多种因素，并在可靠性和空间利⽤之间实现
均衡的同时提供最佳的性能。
•更灵活的存储策略：
üZBS 的纠删码策略最⾼可达到90%+ 空间利⽤率。
üZBS ⽀持通过IOPS 或带宽对单个虚拟机磁盘或虚拟机整体进⾏QoS 控制，并允许IO 突发。
ü除了与VMware ESXi融合部署外，ZBS 还可以独⽴的分布式存储（SMTX ZBS）的形态与ESXi分离式部署，同时兼容
第三⽅虚拟化平台，⽣态更开放，并⽀持更⾼速的NVMe-oF访问协议。
üZBS ⽬前不⽀持去重、压缩、数据传输加密（已规划在路线图中）。
•更可靠的架构：
ü除了采⽤checksum 在数据读写时进⾏数据校验，ZBS 还会在后台周期性地执⾏⾃动数据巡检，避免数据静默损坏对业
务造成的影响。
ü除了对硬盘进⾏健康检测、预警和⾃动处理，ZBS 还会对⽹⼝和⽹络进⾏健康检测、预警和处理，全⽅位保障数据安全。
ü混闪配置或多种类型SSD 全闪配置下，与vSAN OSA 相⽐，ZBS：
-⽆缓存盘单点故障。
-缓存上限远⾼于vSAN，避免缓存击穿。
-在⾼空间利⽤率下仍然可以保持稳定、优异的性能。
-在线增加缓存盘和容量盘，不影响业务运⾏。
47

48. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
替代优势–⽂件存储
•更灵活的使⽤模式
ü除了部署在SMTX OS (ELF) 集群中之外，独⽴的分布式存储（SMTX ZBS）也包含了SFS 这⼀⽂件存储组件，可根据⽤
户的存储规模灵活选择部署模式。
üSFS 与vSAN File 的控制器均以虚拟机形式部署在集群中，但SFS ⽀持客户⾃⾏配置⽂件存储集群节点数并按需扩容，
vSAN File 则规定了FSVM 必须在vSAN 集群的每个主机上运⾏。
üSFS ⽀持客户端从每个⽂件控制器接⼊⽂件系统，对于⽀持多点挂载并有⼤量并发读请求的客户端，可以分散访问时的压
⼒，提供更快的响应速度；vSAN File 的⽂件系统仅会分配给某个特定的接⼊服务。
•更精准的场景优化和验证
üSFS 针对⽂件存储的关键业务场景提供功能⽀持，并持续进⾏⽣态验证：
pPACS 影像资源池：可同时为近期诊疗和⻓期存储影像提供所需的⾼性能或性能成本均衡的存储空间；已和蓝⽹、明
天医⽹完成⽣态互认。
p⼤数据（2025 Q3）：提供HDFS 协议，可为企业⼤数据平台提供⽐原⽣HDFS 更可靠、资源调度更灵活、运维更
简便、总拥有成本更低的⽅案。
p容器云存储（2025 Q3）：计划提供⾃研NFS CSI Driver，⽀持配额、加密等关键能⼒。
•更低的订阅成本
üvSAN File 仅在VVF 和VCF 中包含，且包含的vSAN 容量存在限制，如要使⽤更多存储容量则需要额外购买Add-on 许
可。SFS 作为SMTX OS(ELF) 集群标准版和企业版的内置组件，⽆需额外购买许可即可使⽤，且SFS 可使⽤的容量⽆
软件授权上的上限，仅与集群硬件容量有关。
48

49. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
49
⽹络与安全组件：软件定义的⽹络与安全组件Everoute

50. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
替代优势
•统⼀管理平台
üVMware 的各种⽹络功能分散在多个独⽴的平台中，包括vCenter、NSX Manager、NSX Advanced LoadBalancler
（Avi）Manager、vRNI、vRLogInsight 等，需要在不同界⾯间切换，增加了操作复杂度。
üEveroute ⽹络解决⽅案通过CloudTower 统⼀管理平台，将⽹络、安全及运维功能完全整合，提供"⼀站式"管理体验。
•操作简单、⽅便
ü⽀持“三段式”安全策略配置，通过清晰的图形化界⾯展示业务间的⽹络关系。
ü可快速响应虚拟机安全事件，通过“⼀键隔离”避免安全威胁扩散。
ü通过标签和安全组，根据虚拟机的业务属性进⾏标识。安全策略跟随虚拟机在不同集群、主机间⾃由移动。
•丰富的运维、可观测能⼒
ü⽹络流量可视化功能与Everoute 结合，可以更清晰地展示业务间的流量拓扑。
ü集成可观测性平台，⽀持流⽇志的在线查看、筛选、导出、Syslog 等功能。
50

51. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
51
容器管理组件：SmartXKubernetes服务（SKS）

52. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
52
替代优势
•适配国内⽤户需求
ü兼容国产软硬件。
ü按需付费，更灵活。
ü根据业务特性选择虚拟机或物理机集群。
•更友好的图形化界⾯
ü全图形化界⾯管理集群⽣命周期。
ü图形化配置故障节点⾃动替换、节点⾃动伸缩功能。
ü图形化管理容器应⽤。
•混合架构安全策略的统⼀管理
ü同⼀管理平台中完成虚拟机和Pod 的安全策略配置与数据流的查看。
ü对虚拟机、Pod 等对象的全链路数据流透视。
•细致的多租户管理粒度
ü提供Namespace 级别的隔离和集中管理能⼒，适合需要简单、⾼效的多租户解决⽅案的⽤户。
•丰富的可观测能⼒
ü提供了覆盖集群、节点和应⽤等多个维度的可视化功能，有助于⽤户更全⾯地了解集群运⾏状态。

53. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
53
灾备组件：SMTX备份与容灾

54. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
54
灾备组件：SMTX备份与容灾

55. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
替代优势
•容灾⼀体化解决⽅案
üvSphere Replication 是VMware 的基础复制组件，仅⽀持虚拟机级别的数据复制，不具备⾃动恢复编排能⼒，如启动顺
序、延迟、⽹络切换及IP 映射等，需⼿动操作，RTO ⾼。要实现完整容灾能⼒，需额外依赖Site Recovery Manager
（SRM），多组件分散配置，增加运维复杂度和故障响应成本。
üSMTX 备份与容灾具备原⽣的故障恢复编排能⼒，内置⽀持虚拟机启动顺序、启动延迟、⽬标⽹络切换及IP 映射等功能，
统⼀在⼀个平台中完成配置与管理，简化操作流程，⼤幅降低RTO 和运维成本。相较于vSphere Replication 需依赖
SRM 实现容灾编排，SMTX 提供了更⼀体化、更易⽤的容灾解决⽅案。
•全⾯覆盖数据保护场景
üVShpere Replication 只能进⾏虚拟机级别的异步复制，⽆法提供⽤户所需的备份功能，以满⾜版本管理、⻓期保存、归
档等功能，必须依赖第三⽅备份产品才能补⻬备份能⼒。
üSMTX 备份与容灾原⽣集成备份和容灾，同⼀个⼯具即可完成VM 的定时备份、复制和故障转移/恢复功能。其中备份⽤
于数据⻓期保存/误删找回，复制⽤于保证业务连续性。
ü统⼀管理备份和灾备资源，统⼀调度与运维，降低运维⼈员灾备软件学习成本。
•多功能原⽣集成
üSmartX 通过CloudTower 原⽣整合⽹络安全、VPC 功能，⽀持流量可视化、异常隔离、沙箱演练与⽹络⽆感切换，跨站
点业务故障切换⽆需更改IP 或路由即可完成，真正实现平台级⼀体化、⽹络感知的灾备⽅案，简化操作流程，提升安全
性与恢复效率。
ü相⽐之下，VMware 实现类似能⼒需依赖vSphere Replication、SRM、NSX 等多个独⽴组件，存在部署配置复杂、组件
间耦合度低、运维界⾯割裂等问题，导致运维成本⾼、出错率⼤，灾备流程⾃动化与可控性有限。
55

56. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
56
运维与管理组件：CloudTower

57. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
替代优势
•巡检中⼼提供集群健康巡检功能
ü通过巡检中⼼可以⾃主对SMTX OS、SMTX ZBS 以及SMTX ELF 提供健康状况检测，帮助⽤户识别系统内当前存在的
问题及潜在的⻛险，并提供提升健康状况的建议，确保⼀切资源和运⾏处于最优状态。
•升级中⼼提升集群⾃动化运维效率
ü通过升级中⼼对各类SMTX 集群及系统服务提供⽣命周期管理功能，提供⾃动化流程，能够做到在提交升级任务之后，让
整个升级期间全程⽆需⼈⼯⼲预，并确保升级期间集群业务正常运⾏，此功能能够帮助客户更加快捷、简单、⾼效地完成
集群运维⼯作。
57

58. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
58
⾃服务组件：SMTX⾃服务中⼼
为云服务器（虚拟机）最终⽤户提供⾃助申请和使⽤SmartX企业云资源的途径。⽤户可通过服务⽬录选择所需云服务器及相
关资源，系统⾃动完成审批和云资源配置，降低企业内部的云⽤户对IT⼈员的依赖，提⾼交付效率。
核⼼优势与价值
•⾃助交付：加快云资源的交付速
度，提⾼企业IT 资源响应的灵活
性和速度，减少IT 部⻔的负担，
提⾼⼯作效率。
•安全可控：确保不同⽤户和租户
的数据与资源隔离，防⽌越权使
⽤，降低安全⻛险。
•精细运营：避免资源超⽤或浪费，
提⾼资源利⽤率，降低成本。
应⽤场景
•⾃助云资源创建。
•多租户使⽤与权限管理。
•资源配额与⽤量监控。
•异构云环境统⼀管理。

59. SmartX 企业云平台与VMware 产品组件的能⼒对⽐
59
更多关键特性与性能对⽐
快照机制
SMTX OS 的快照技术显著改善了快照运⾏后I/O 性能下降的时间和可恢复，同时能够保证多个快照间的独⽴性，⽅便运维⼈
员对快照进⾏删除等操作和管理。
点击链接，阅读原⽂：
VMware 与SmartX 快照原理浅
析与I/O 性能对⽐

60. I/O 路径
不同的超融合软件，其读写机制有⼀定的差异性，I/O 路径也不尽相同，这使得它们在I/O 读写效率以及资源占⽤上都有不同
的表现。ZBS 在不频繁发⽣虚拟机在线迁移（⼏⼩时就发⽣⼀次迁移）的环境下具有明显的优势，反之，vSAN 会有⼀定优势。
⽽在实际⽣产环境下，频繁的在线迁移并不常⻅。
•基于SDS 的超融合架构中，I/O 既可能发⽣在主机内部的本地磁盘上，也有可能发⽣在外部的⽹络主机上。相同软硬件配
置下，本地I/O 操作时延更短。
•在写⼊场景下，vSAN ⾄少有1 个副本需要经过⽹络写⼊。在读取场景下，读I/O 路径在正常状态下不会出现100% 本地
读取情况；在故障状态下仅有25% 概率出现100% 本地读取，其余情况均为100% 远程读取，且易因故障恢复导致性能
瓶颈。
•在写⼊场景下，ZBS 在正常状态下不会发⽣100% 远程写⼊的情况，并针对虚拟机迁移后的I/O 路径进⾏了优化，最⼤限
度避免100% 远程写⼊的情况。在读取场景下，正常状态时可确保100% 本地读；数据恢复时优先进⾏本地恢复，并通过
弹性副本恢复策略平衡恢复速度与业务I/O。
•在正常和数据恢复状态下，ZBS 的本地I/O 访问概率⽐vSAN 更⾼，理论上时延会更低；⽽在需要频繁迁移的场景下，
vSAN 本地I/O 访问概率更⾼。
•即使超融合的整体I/O 性能有富余，更多的远程I/O 也可能引起⽹络资源争抢等问题。
点击链接，阅读原⽂：
浅析VMware 与SmartX 超融合
I/O 路径差异及其影响
60
SmartX 企业云平台与VMware 产品组件的能⼒对⽐

61. 扩容机制
SmartX 单节点内部、同集群不同节点间、多集群等不同层级的扩容机制，能够达到甚⾄超越VMware 的⽔平，更加弹性和灵
活。
SMTX OS 分布式存储组件 vSAN 7.0
单
节
点
内
部
存储资源
（HDD/SSD）
组织结构
⽀持全闪盘或SSD + HDD 混合模式。
全闪配置下⽀持“分层”或“不分层”模式。
分层模式下：
•缓存盘上的OS 和元数据通过软件RAID1 进
⾏保护
•缓存盘上的缓存数据和存储⽇志采⽤跨节点副
本保护
•系统盘/缓存盘可⼆合⼀
⽀持全闪或SSD + HDD 混合“硬盘组”。
每节点1~5 个硬盘组：
•盘组内必须采取“分层”模式
•每盘组1 个缓存盘，必须为SSD，仅对本盘组内的I/O 操作提供缓存
服务
•盘组内的缓存盘⽆冗余，因此单节点内推荐配置盘组数量≥2
•每盘组必须配置1~7 个容量盘
•系统盘不能⽤作缓存盘
是否允许灵活
增加数据盘
是。
•推荐所有节点上的数据盘性能⼀致
•允许在每个节点内增加不同容量、不同数量的
数据盘，节点内总容量不超过256TB
•节点内缓存盘/数据盘容量⽐：10~20%，缓
存盘不⾜时可灵活添加
•可以在不同容量的数据盘间⾃动均衡分配数据
存储量
不推荐。
•允许单独增加某⼀盘组内的容量盘，每盘组不超过7 块
•盘组内的缓存盘/容量盘之⽐：10~20%，增加容量盘可能导致缓存盘
不⾜，且不能灵活增加缓存盘
•推荐所有硬盘组内的容量盘数量、型号⼀致，新增硬盘数量与节点数量
x 硬盘组数量成正⽐（⽐如：3 节点，每节点2 硬盘组，⾄少需增加6
硬盘）
注：以预设的硬盘利⽤率(%) 阈值作为⾃动均衡条件，不⼀致的数据盘容
量会导致频繁告警和性能下降。
是否允许灵活
增加缓存盘
是。
•⽀持缓存盘在线替换和添加
•逐⼀替换缓存盘过程中，数据不丢失、业务不
中断
•节点内总量不超过50TB
否。
•缓存盘数量必与硬盘组数量⼀致
•不⽀持缓存盘在线替换：
•需将原缓存盘所属盘组整体离线，再更换为更⼤容量SSD
•或将盘组进⾏拆分，添加新的缓存盘后重建盘组
•以上过程需要预先清空该盘组内数据，需较⻓的数据准备时间；
或完成后从副本恢复，期间数据冗余度下降，有⻛险
61
SmartX 企业云平台与VMware 产品组件的能⼒对⽐

62. SMTX OS 分布式存储组件 vSAN 7.0
同
集
群
不
同
节
点
间
是否允许
数据盘
容量不⼀致
允许。
可在不同节点间智能分配数据存储量。
允许。
注：以预设的硬盘利⽤率(%) 阈值作为⾃动均衡条件，
不⼀致的数据盘会导致频繁告警和性能下降。
是否允许
缓存盘
容量不⼀致
允许。
缓存盘与本节点上的数据盘⽐例适当即可。
允许。
推荐在所有节点的盘组上使⽤具有同样性能指标和容量的
缓存盘。
多
集
群
多架构集群
统⼀管理
管理平台CloudTower，可以同时管理多个超融合集
群，每个集群内部所有服务器节点应使⽤⼀致的CPU
架构，但不同集群可以采⽤不同CPU 架构
（Intel/AMD/鲲鹏/海光/⻜腾）。
管理中⼼vCenter，可以同时管理多个超融合集群，每个
集群内部所有服务器节点应使⽤⼀致的CPU 架构
（Intel/AMD）。
点击链接，阅读原⽂：
SmartX 超融合扩容配置详解以及
VMware ⽅案对⽐
62
SmartX 企业云平台与VMware 产品组件的能⼒对⽐

63. 性能对⽐
某银⾏⽤户计划将IBM ⼩机数据库下移⾄x86 平台，因此对SmartX（SMTXOS5.1）与VMware 超融合（vSAN 8）承载
Oracle 数据库的能⼒进⾏了测试。结果显示，在1500 并发⽤户压⼒下，SmartX超融合性能（24613 TPS）远⾼于VMware
超融合（11101 TPS），提升超120%；在⾼负载测试下，SmartX超融合也具备更好的稳定性。
点击链接，阅读原⽂：
性能翻倍！SmartX超融合与vSAN
8 在数据库场景下的性能对⽐
63
•12 ⼩时3P3V 256K 顺序写测试：在存储使⽤率⾼于90% 的⾼负载情况下，SMTX OS 性能更优、更稳定。
vSAN8.0 SMTXOS5.1
•Swingbench压⼒测试：在1500 并发⽤户压⼒下，SMTX OS 性能
可达到24631 TPS，较vSAN 8 (11101 TPS）提升120%，同时也优
于Oracle 数据库⼀体机和裸⾦属+集中式存储架构的表现。
SmartX 企业云平台与VMware 产品组件的能⼒对⽐

64. 通过以下三本电⼦书，您可以了解SmartX 产品更多技术细节。
SmartX 超融合技术原理与特性解析
合集（⼀）虚拟化与存储
SmartX 超融合技术原理与特性解析
合集（⼆）管理与运维
《虚拟化与存储》篇，深⼊解读快照、
缓存、I/O 路径等关键技术与特性，包
含与VMware 和Nutanix 的详细对⽐。
《管理与运维》篇，深⼊解读磁盘亚健
康检测、存储性能管理、升级、扩容、
迁移等关键技术与特性。
64
《全栈能⼒》篇，深⼊解读K8s 服务、
分布式防⽕墙、负载均衡、VPC、备份
容灾等等关键技术与特性。
SmartX 超融合技术原理与特性解析
合集（三）全栈能⼒
SmartX 企业云平台与VMware 产品组件的能⼒对⽐

65. 第三章节
从VMware迁移⾄SmartX企业云
平台：⽅案、规划与问题处理
Ø从VMware 迁移到SmartX 平台的两种⽅式······66
Ø虚拟机跨平台迁移：常⻅问题与⽤户实践······69
65

66. 从VMware 迁移到SmartX 平台的两种⽅式
确定好VMware 国产化替代⽅案之后，将运⾏在VMware 平台上的虚拟机迁移到新平台上，也是⼀项不⼩的挑战。针对企业
⽤户的不同替代需求，SmartX提供两种迁移⽅案：
•保留vSphere使⽤习惯：利⽤vMotion 将VMware 虚拟机迁移⾄SMTX OS（vSphere融合部署）集群。
•替代vSphere：利⽤SMTX 迁移⼯具将VMware 虚拟机迁移⾄ELF 平台。
将VMware 虚拟机迁移⾄SMTX OS（vSphere 融合部署）
66
对于希望保留vSphere 使⽤习惯的⽤户，可以以
SMTX OS 替代原有集中式存储或vSAN。此时可
采⽤融合部署vSphere的SmartX超融合⽅案，
并通过vMotion将VMware虚拟机迁移⾄SMTX
OS集群，降低成本的同时逐步推进VMware 替代
进程。
迁移时⽆需引⼊第三⽅迁移⼯具，仅需将新建的
SMTXOS集群加⼊VMware vCenter，执⾏
vMotion 即可将虚拟机和应⽤在线迁移⾄SmartX
超融合（融合部署vSphere）。

67. 从VMware 迁移到SmartX 平台的两种⽅式
67
将VMware 虚拟机迁移⾄ELF：采⽤⾃研⽆代理SMTX 迁移⼯具
SmartX为⽤户提供了跨平台虚拟机迁移⼯具——SMTX 迁移⼯具。该⼯具⽀持将运⾏在VMware虚拟化平台的虚拟机迁移⾄
基于SmartX原⽣虚拟化ELF 的超融合集群。
作为⼀款跨平台虚拟机迁移⼯具，SMTX 迁移⼯具有以下优势：
•灵活部署：SMTX 迁移⼯具⽀持灵活部署，可选择部署在源端或者⽬标端虚拟化平台。
•⽆代理：待迁移的虚拟机⽆需安装任何代理插件，⽀持的虚拟机类型覆盖CentOS、Windows Server、Redhat、Linux、
Ubuntu等主流的操作系统。
•在线迁移：全量数据同步时虚拟机可保持在线，只需在迁移接近完成时关机以完成增量数据同步。
•节约时间：⽀持全量数据传输完成后⼿动同步增量数据，此时源端虚拟机可保持在线，降低停机时间，帮助客户在有限的
业务变更窗⼝内迁移现有的⼯作负载，加速业务交付速度。

68. 迁移整体流程（左）和安排（右）
点击链接，阅读原⽂：
VMware 虚拟机向国产虚拟化平台
迁移？⼀⽂了解SMTX 迁移⼯具
原理与实践
68
从VMware 迁移到SmartX 平台的两种⽅式

69. 常⻅问题
Q：虚拟机跨平台迁移的原理是什么？
不同⼚商提供的跨平台⼯具迁移原理不尽相同，以SMTX 迁移⼯具为例，主要利⽤虚拟机快照功能进⾏数据的传输和同步：
•对源端虚拟机执⾏快照并进⾏全量数据传输：迁移⼯具会先对虚拟机执⾏快照记录虚拟机当前状态，然后在线执⾏全量的数
据拷⻉，这⼀过程中源端虚拟机可以保持在线，因此不会影响原有VMware 集群中虚拟机的正常运⾏。
•对源端虚拟机执⾏增量数据同步⾄⽬标端虚拟机：全量数据传输过程中，虚拟机是正常运⾏的，数据状态也同步发⽣变化。
在全量数据传输完成后，⽤户可以选择⼿动同步（不停机）增量数据，或者直接关闭源虚拟机以执⾏增量数据同步。采⽤⼿
动同步的好处是：可在虚拟机保持在线的情况下，完成绝⼤部分增量数据的复制，将⼤幅减少停机同步时间。源端虚拟机关
机后，除了完成必要的数据增量同步外，迁移⼯具也会⾃动完成对⽬标端虚拟机的驱动注⼊、必要的系统配置等。完成相关
⼯作后就可以在新集群中启动已完成迁移的虚拟机。由于迁移过程涉及短暂停机，因此需要合理安排停机窗⼝。
Q：所有虚拟机都可以进⾏跨平台迁移吗？
以SMTX 迁移⼯具为例，部分虚拟机不适合通过迁移⼯具执⾏迁移，如：
•带共享虚拟磁盘的虚拟机（如Oracle RAC 等）：SMTX 迁移⼯具以及vMotion 都⽆法⽀持共享磁盘的迁移。
•VDI 桌⾯虚拟机（如Horizon View、Citrix XenDesktop 等）：这类虚拟机也⽆法通过SMTX 迁移⼯具或者vMotion 迁移。
•AD 域控制器虚拟机：由于这类型虚拟机严格绑定硬件信息，v2v 迁移后可能会导致AD 服务运作不正常。
•不兼容的操作系统：⼀些过于⽼旧的操作系统或者⽐较⼩众的操作系统可能⽆法通过SMTX 迁移⼯具直接完成迁移，具体
可参考SMTX OS 的Guest OS 兼容列表。
这类虚拟机需要进⾏⼿动迁移，除此之外的⼤部分虚拟机均可使⽤SMTX 迁移⼯具完成跨平台迁移。
Q：将虚拟机从VMware 迁移⾄其他平台，整个过程对业务有什么影响？
如Q1 所述，全量数据传输和⼿动同步增量数据时，源端虚拟机可正常运⾏，只有在最后的增量同步时需要关闭源端虚拟机，
因此需要安排停机窗⼝。
69
虚拟机跨平台迁移：常⻅问题与⽤户实践

70. 虚拟机跨平台迁移：常⻅问题与⽤户实践
•测试类虚拟机可在⼯作时间启动迁移任务。
•正式虚拟机尽可能安排在⾮繁忙时间启动迁移任务，以避免数据传输对业务带来性能下降的影响。
•为有效减少业务系统的停机及最终交割时间，可以在全量数据传输完成后，选择执⾏虚拟机增量迁移（增量迁移的时间间隔
可以根据业务需求和⽹络条件进⾏调整），将源端虚拟机产⽣的增量数据同步⾄⽬标端。
•最后阶段需要⼿⼯停机执⾏切换，需计划合理的停机时间。使⽤SMTX 迁移⼯具进⾏迁移时，⼤部分情况下停机同步时间
不会超过30 分钟，但如果增量数据较多可能导致停机同步时间延⻓（停机同步时间根据数据增量和⽹络传输效率决定，数
据增量指从触发迁移的时间点到全量同步完成的时间点之间发⽣的数据变化量）。
整体⽽⾔，迁移过程中的全量传输阶段业务可正常提供服务，但性能可能会略有下降；在增量同步阶段，业务虚拟机在执⾏最
后⼀个快照前需要停机，但停机时间较短，只需要合理安排停机窗⼝（⾮业务时间切换），可将业务影响降⾄最低。
Q：跨平台迁移会遇到兼容性问题吗？对迁移⼯具有哪些要求？
由于迁移⼯具同时关联VMware 环境和新平台环境，迁移⼯具对vCenter/ESXi 版本、虚拟机操作系统、服务器架构、
VMware ⽹络连接等⽅⾯的兼容⽀持，是保证迁移能够顺利进⾏的关键。⽬前，⼀些国内⼚商的迁移⼯具⽆法⽀持基于
vSphere Distributed Switch（VDS，分布式交换机架构）的迁移，仅⽀持标准交换机架构（VSS），⽽将虚拟机从VSS 迁移
到VDS 有可能会引起业务⽹络中断，因此会对⽤户的迁移场景带来⼀定的限制。
⽬前，SMTX 迁移⼯具对源端和⽬标端环境的兼容⽀持能⼒，可满⾜绝⼤部分⽤户的跨平台迁移需求，具体如下：
1. 对vCenter 版本/ESXi 版本的兼容能⼒：SMTX 迁移⼯具可⽀持关联vCenter 或者ESXi 主机（没有部署vCenter 的场景）
作为源站点执⾏虚拟机迁移。但在迁移前需要确认当前VMware 集群的vCenter 版本或者ESXi 版本是否在SMTX 迁移⼯具
的⽀持范围。以SMTX 迁移⼯具1.5 版本为例，该版本对vSphere 版本兼容列表如下：
版本5.05.15.56.06.56.77.08.0
ESXi☑☑☑☑☑☑☑☑
vCenter ☑☑☑☑☑
70

71. 虚拟机跨平台迁移：常⻅问题与⽤户实践
SMTX 迁移⼯具对ESXi版本的兼容要⽐vCenter 的版本更丰富⼀些，当计划为版本⽐较⽼的VMware 集群执⾏迁移时，可
通过关联ESXi主机解决vCenter ⽆法兼容的问题。
2. 对虚拟机操作系统（Guest OS）兼容能⼒：SMTX 迁移⼯具已针对企业常⽤的操作系统进⾏适配和验证（包括CentOS、
Windows Server、Redhat、Linux、Ubuntu 等），在迁移前请确认待迁移的虚拟机操作系统是否在兼容⽀持列表当中。如果
操作系统不在兼容列表中，需要与SmartX技术⼈员进⾏沟通。
3. 对服务器芯⽚的兼容能⼒：SMTX 迁移⼯具⽀持源端（VMware 集群）为Intel x86_64 架构芯⽚，⽬标端（SmartX超融
合集群）则⽀持Intel x86_64 架构芯⽚和Hygonx86_64 架构芯⽚。
另外，SMTX 迁移⼯具也可⽀持基于vSphere Distributed Switch 架构的虚拟机迁移，满⾜更多迁移场景需求。
Q：虚拟机跨平台迁移的效率如何？如何提升迁移速率？
迁移速率会受到多种因素影响，包括迁移⽹络带宽、并发任务数量、迁移⼯具的部署位置等。以SMTX 迁移⼯具为例，SMTX
迁移⼯具可通过虚拟机的形式在原有的VMware 集群或新建的SMTX OS 超融合集群进⾏部署，迁移⼯具同时关联VMware
集群和SMTX OS 集群，经过⽹络将VMware 虚拟机磁盘数据拷⻉到新建SMTX OS 集群，因此迁移效率会受到集群之间的
⽹络带宽以及磁盘性能等因素影响。以下是SMTX 迁移⼯具在1GbE 迁移⽹络环境下的迁移效率测试，供⽤户参考。
测试1：迁移⼯具部署位置不变（部署位置均为VMware 集群），不同存储介质下（源端）的迁移速度对⽐：下图左。
测试2：源端存储介质不变（存储介质均为SSD），v2v 迁移⼯具位于不同部署位置的迁移速度对⽐：下图右。
SSDHDD
迁移速度（MBps）147.546.4
位于VMware 集群位于SMTX OS 集群
迁移速度（MBps）147.554.8
71

72. 虚拟机跨平台迁移：常⻅问题与⽤户实践
此外，SMTX 迁移⼯具可选择接⼊2 块虚拟⽹卡，其中⼀块⽹卡（必须）⽤于连接VMware 集群管理⽹络和SMTX OS 集群
管理⽹络，另外⼀块⽹卡（可选）可接⼊存储⽹络⽤于提升数据传输速度，可有效缩短迁移时间。
Q：如何制定VMware 虚拟机迁移计划？
制定迁移计划之前，需要了解企业当前VMware 虚拟机的基本情况。从VMware vCenter 中可以导出虚拟机的清单信息，具
体操作为：登录vSphere Client -选择全局清单列表-单击虚拟机选项卡以显示所有虚拟机的列表，然后根据实际情况选择
筛选的信息。⼀般需要收集的信息包括：CPU、内存、内存使⽤率、置备空间、已⽤空间、⽹卡数量、端⼝组等。该环节的⽬
的是了解虚拟化环境的总体资源需求，⽽新建集群可根据待迁移虚拟机的资源需求总量进⾏配置，确保有⾜够资源运⾏所有待
迁移的虚拟机。
在确认迁移时间窗⼝和兼容性后，可制定详细的迁移⽇程。⽬前SMTX 迁移⼯具执⾏迁移任务最⼤并发数为5，并可设定任务
队列。在实际迁移中，需根据迁移带宽控制迁移并发数量，当带宽利⽤率过⾼有可能导致迁移中断或者失败。当迁移⽹络带宽
为1G，建议并发数是1-2；当前迁移⽹络带宽为10G，可设置并发数为5（并发数量还需要考虑原有集群性能影响）。
迁移顺序可按照虚拟机对应的业务的重要程度从低到⾼、磁盘空间从⼩到⼤进⾏排序。此外，建议在正式迁移之前安排⼀次预
迁移（虚拟机不包含真实业务），熟悉和打通整个迁移流程。
Q：如何保障迁移过程的可靠性？
除了上⾯提到的确认虚拟机是否适合利⽤迁移⼯具进⾏⾃动迁移、确认虚拟机信息、迁移⼯具兼容性、迁移时间窗⼝等，⽤户
还需要进⾏环境检查和预迁移以保证迁移的顺利进⾏。
1.环境检查
•确认⽹络连通性：主要是v2v 迁移⼯具与vCenter 以及ESXi 主机的⽹络连通性，例如，如果它们之间有防⽕墙，需提前
开通相关端⼝。
•确认vCenter 与ESXi 主机之间是否通过DNS 域名进⾏关联：如果是，需要确保迁移⼯具、新平台集群主机都能正常解释
DNS 域名。
72

73. 虚拟机跨平台迁移：常⻅问题与⽤户实践
•确认待迁移的虚拟机是否包含快照：如有快照需先删除快照再执⾏迁移。
•清理待迁移的虚拟机上⾮必要的虚拟外设，如USB 直通设备、ISO 镜像等。
•卸载待迁移的虚拟机VMware VMTools。
2. 预迁移：⽤户可选择VMware 集群中常⽤的虚拟机模板，通过迁移⼯具迁移到新平台的新建集群。通过预迁移可以验证整
个迁移流程是否通畅。在预迁移过程中，⽤户可记录虚拟机磁盘容量、迁移速度、迁移时间等信息，作为正式迁移的参考。
Q：正式迁移时具体需要执⾏哪些操作？
以从VMware 迁移⾄SmartX超融合集群为例，正式迁移的具体步骤包括：
1.选择待迁移虚拟机：根据迁移计划选择待迁移的虚拟机（⼀台或多台并发）。
2.选择迁移⽬标集群和主机：如果环境中有多个SMTX OS 集群，根据资源利⽤情况选择合适的集群作为⽬标集群。
3.选择虚拟⽹络：⼀般选择与原虚拟机相同的⼦⽹。如有多张虚拟⽹卡，则根据需⼀⼀对应，以确保迁移完成后虚拟⽹络的正
常通讯。
4.虚拟机数据传输：数据传输阶段需通过⽹络完整拷⻉虚拟机的磁盘数据，整个过程耗时较⻓。如传输过程中发⽣⽹络中断，
可使⽤SMTX 迁移⼯具的断点续传功能，⽆需重新开启迁移任务。
5.虚拟机数据增量同步：当数据传输完成后，⽤户可以选择⼿动同步增量数据，再对源虚拟机执⾏关机操作。关机后，迁移⼯
具会⾃动完成剩余增量数据同步、执⾏必要的驱动注⼊和系统配置操作。
6.虚拟机检查：迁移完成后，需对新迁移到SMTX OS 集群的虚拟机进⾏必要的检查，确保操作系统可正常登录、⽹络可正
常通讯、虚拟磁盘全部已正常挂载，并检查关键的应⽤程序是否能够正常启动。
Q：迁移过程中出现“意外”应如何应对？
SMTX 迁移⼯具⽀持断点传输功能和迁移回退⽅案，并针对兼容问题提供了更多解决⽅案。
1. 操作系统不在迁移⼯具兼容性范围
如果虚拟机的操作系统不在SMTX 迁移⼯具兼容⽀持范围内（但GuestOS 在SMTX OS 兼容范围），可尝试先通过SMTX
迁移⼯具迁移到SMTX OS 集群。若迁移结束后出现⽆法正常进⼊操作系统的情况，请参考以下检查步骤，初步定位原因，并
制定下⼀步解决⽅案。
73

74. 虚拟机跨平台迁移：常⻅问题与⽤户实践
•⽆法找到启动设备：虚拟机启动后提示⽆法找到启动设备，可能因为虚拟磁盘Virtio驱动⽆法成功注⼊，导致启动分区⽆法
识别。该情况下，可通过虚拟机控制台进⼊紧急模式确认是否能识别虚拟磁盘，可尝试安装驱动以及修改启动配置信息进⾏
修复。
•⽆法启动图形界⾯：Linux 虚拟机可正常进⼊操作系统，但⽆法启动图形界⾯，有可能因为虚拟显卡的配置⽂件不匹配，可
通过重置配置⽂件进⾏修复。
2. 迁移回退
如虚拟机⽆法正常完成迁移，或在迁移后业务⽆法正常⼯作，可以采取回退⼿段。回退流程如下：
•登录CloudTower管理界⾯，将SMTX OS 集群中已迁移的虚拟机执⾏关闭操作。
•登录原有VMware vCenter，找到原有业务虚拟机，重新开启该虚拟机
•检查虚拟机是否可正常登录，以及业务是否能正常服务。
74
观看视频：
SMTX 迁移⼯具流程讲解与操
作实践

75. 虚拟机跨平台迁移：常⻅问题与⽤户实践
常⻅迁移失败原因与解决⽅案
驱动注⼊失败：迁移后存在⼩部分驱动注⼊失败的虚拟机，⼤多数运⾏相对较⽼的操作系统，例如Windows 2003、RHEL
5.0 等，此时需要⼿动安装VMtools。若不⽀持安装VMtools，或由于驱动注⼊失败后使⽤virtio格式⽆法登⼊系统内，则需
要切换为IDE 总线，通过⼿动安装virtio驱动，随后再进⾏相应配置。
NAS⾃动挂载失败：部分虚拟机配置了开机⾃动挂载NAS 设备，由于迁移后⽹络配置不会⽴刻⽣效，会导致⽹络不通⽽⽆法
挂载NAS、⽆法启动系统的问题。此时需要先通过单⽤户/救援模式取消NAS 挂载，随后启动虚拟机。
热数据同步时间久：发起迁移任务后，在既定时间进⾏V2V 数据同步时，由于有些虚拟机的数据变化量较⼤，导致增量数据
迁移时间较久，期间可能会出现虚拟机停机窗⼝超过预定时间段情况。此时建议⽤户在全量数据传输完毕后，先⼿动同步增量
数据，此时源端虚拟机可保持开机，随后再执⾏短暂的停机以同步开机时产⽣的增量数据，可有效降低虚拟机停机窗⼝。
激活问题：通过KMS 激活的Windows Server 虚拟机在迁移之后可能显示未激活，这是由于在迁移之后Windows Server 检
测到所在的硬件环境发⽣了变化，导致激活失效，需要⽤户在迁移完成后⼿动处理。
磁盘离线：Windows Server 虚拟机迁移完成后如果出现SAN 磁盘离线的情况，可能是Windows Server SAN 策略配置造成
的，在迁移虚拟机之前进⾏合理配置即可规避。
DNS 配置问题：Windows Server 虚拟机迁移完成后如果出现⽹络异常，例如Outlook 服务器⽆法连接、IP ⽆法共享等，需
要检查并调整DNS 配置。
75

76. 虚拟机跨平台迁移：常⻅问题与⽤户实践
76
⾏业⽤户实践
某保险⽤户：⼀期项⽬迁移500+ 业务虚拟机，同时实现VMware 和Nutanix 替代
某头部保险机构原采⽤Nutanix 超融合（集成VMware vSphere 虚拟化）承载⽣产业务系统，⽽随着Nutanix “退出”中国以
及IT 基础架构国产化转型的深⼊开展，⽤户希望以SmartX超融合（采⽤原⽣虚拟化ELF）对Nutanix 超融合进⾏国产化替
代。
为确保Nutanix 超融合上的业务虚拟机可顺利迁移⾄SmartX超融合平台，⽤户先对SMTX 迁移⼯具进⾏了测试。结果显示，
基于Windows Server、RedhatEnterprise Linux、CentOS 等常⽤的操作系统并结合业务部署的虚拟机，均可完整迁移
SmartX超融合平台。在测试过程中，迁移⼯具经过⽤户实际⽣产迁移场景的严格考验，在功能性、易⽤性、兼容性、可靠性
及效率性中均获得客户认可：
•操作界⾯⼀⽬了然，⽤户可根据运维经验快速理解界⾯的各种功能。
•迁移时源端和⽬标端的选定也⼗分简单，⽤户只需要简单指定好两端，点击“开始”即可启动迁移。
•迁移过程中⽆需⼈⼯⼲预，即使迁移失败也不影响源端数据，待条件允许重新发起迁移任务即可。
•迁移任务发起后，⽀持⼿动触发增量数据迁移以缩短迁移过程中虚拟机停机时⻓。
基于以上测试，⽤户计划使⽤SMTX 迁移⼯具将VMware 集群的700+ 业务虚拟机和300+ 开发测试虚拟机分批次迁移⾄
SmartX超融合平台。⽤户将虚拟机迁移项⽬拆分为两期，第⼀期将运⾏寿险和财险的相关业务系统、运维管理类业务系统、
集团管理类系统和办公系统等200+ 业务虚拟机和300+ 开发测试虚拟机迁移⾄SmartX超融合集群。鉴于当前集群资源⽆法
完全承载700+ 业务虚拟机，待集群扩容完成后，计划在第⼆期迁移剩余所有业务虚拟机。
为确保迁移⼯作的顺利进⾏，每次迁移任务前，SmartX⼯程师都会与⽤户核对本次迁移任务的虚拟机情况：如确认虚拟机操
作系统严格符合兼容性列表，核对虚拟机的名称与IP 信息、虚拟磁盘置备容量的⼤⼩、计算资源使⽤情况、具体变更时间，
以及检查客户操作系统内是否存在⾃动挂载的⽹络存储（迁移前取消NAS 存储⾃动挂载，迁移完成后重新恢复）。此外，迁
移任务安排在业务闲时进⾏，以确保迁移⼯作不会对⽤户的正常业务带来负⾯影响。SmartX⼯程师也严格按照每台虚拟机20
分钟的停机时间的标准，完成虚拟机增量同步和开机验证，并在⽤户确认业务可正常运⾏后，该批次迁移任务才算完成（具体
迁移操作与上⽂Q8 部分⼀致，此处不再赘述）。

77. 虚拟机跨平台迁移：常⻅问题与⽤户实践
⽬前，第⼀期项⽬的200+ 业务虚拟机已顺利完成，开发测试虚拟机也完成200+ 台迁移，剩余迁移⼯作正在如期进⾏中。⽤
户对整体迁移过程的控制、迁移效率、任务成功率以及在有效控制迁移停机时间等⽅⾯都⽐较满意。伴随迁移流程的持续优化，
在项⽬后期，SmartX ⼯程师不仅在规定停机窗⼝内完成迁移任务，更多的情况是提前完成，为⽤户减少停机时间。
上海绿地：迁移SAP 应⽤虚拟机，避免应⽤授权迁移后失效
作为酒店旅游⾏业头部企业，上海绿地原采⽤“VMware 虚拟化+ 集中式SAN 存储”的传统架构承载核⼼⽣产业务系统。由于
原有设备⽼化以及集团数字化转型需求，上海绿地希望以SmartX 超融合（采⽤原⽣虚拟化ELF）对VMware 虚拟化架构进
⾏整体替换，并采⽤SMTX 迁移⼯具进⾏虚拟机跨平台迁移。
⽤户⾸先对SMTX 迁移⼯具的迁移速率以及系统兼容性进⾏了验证，确认迁移⼯具的可⾏性。在进⼀步探讨迁移细节时，⽤户
提出了关于业务系统授权⽅⾯的担忧：在将虚拟机迁移⾄新平台后，由于业务系统绑定的硬件信息发⽣变化，软件授权是否会
失效，以⾄于业务系统⽆法使⽤？为规避业务系统许可失效⻛险，SmartX 技术⼈员提前与⽤户充分探讨，并在进⾏⼀系列相
关测试后，验证了可通过移植⽹卡MAC 信息结合⼿⼯修改业务系统绑定信息的⽅式，解决许可在迁移后失效的问题。⽤户对
这⼀⽅案充分认可，认为可以避免软件⼚商反复沟通以及重新授权等繁琐流程，既简单⼜节约时间。
77

78. 虚拟机跨平台迁移：常⻅问题与⽤户实践
在相关应⽤迁移之前，SmartX ⼯程师与客户运维团队以及业务团队进⾏了详细的沟通与规划：确认业务虚拟机信息以及资源
使⽤情况、合理安排迁移启动时间、根据虚拟机数据量、预期迁移速度合理与业务团队协商停机窗⼝，并制定迁移超时的应急
预案。迁移详细操作步骤如下：
•迁移任务选择在业务闲时启动，避免执⾏快照时对业务性能产⽣影响。
•在迁移向导中选择为源端虚拟机保留⽹卡MAC 地址，确保迁移后⽹卡信息不变。
•虚拟机完成全量复制后，将源端虚拟机关机，执⾏增量数据同步。
•增量数据传输完成后，对虚拟机进⾏开机验证，确认虚拟机和系统可正常运⾏。
•对虚拟机进⾏关机，修改虚拟硬件信息。
•重新开机，待客户确认业务可正常提供服务后后，该虚拟机迁移⼯作正式完成。
⽬前，上海绿地已经完成了所有VMware 虚拟机的迁移⼯作，将承载SAP、BI、OA 办公等业务系统的近30 台虚拟机全部迁
移⾄SmartX 超融合（ELF）集群。⽤户对整体迁移过程的便捷性和迁移稳定性表示⾼度认可。
此外，某财务公司也利⽤SmartX 迁移⼯具，将⽣产环境VMware 超融合平台上100+ 虚拟机全部迁移⾄基于ELF 的
SmartX 超融合平台。整体迁移⼯作在⼀周内完成，迁移数据量超40TB，迁移期间业务虚拟机全部保持在线状态（重启仅需
5 分钟）。中再保险、ConnectWave 等企业⽤户，也使⽤SMTX 迁移⼯具成功替换VMware 虚拟化。
78
点击链接，阅读原⽂：
VMware 虚拟机迁移指南：10
⼤关键问题与3 例⽤户实践

79. 第四章节
VMware替代实践案例
虚拟化｜vSAN｜Tanzu｜NSX
Ø⾏业⽤户以SmartX 企业云平台替代VMware······80
Ø⾦融⾏业VMware 升级替代实践······81
Ø医疗⾏业VMware 升级替代实践······89
Ø制造⾏业VMware 升级替代实践······100
Ø更多⾏业VMware 升级替代实践······114
79

80. ⾏业⽤户以SmartX企业云平台替代VMware
SmartX 已帮助众多来⾃⾦融、医疗、制造等⾏业的头部⽤户，利⽤SmartX 企业云平台进⾏vSphere、vSAN、Tanzu、NSX
乃⾄VMware 全栈基础设施替换与架构升级。根据SmartX 出货统计，近65%的⽤户都选择了SmartX 超融合原⽣的ELF
作为虚拟化⽅案（所有使⽤SMTX OS 的⽤户中采⽤ELF 作为虚拟化⽅案的⽐例），替代核⼼虚拟化的同时降低订阅成本。
80

81. ⾦融⾏业VMware 升级替代实践
⾦融⾏业国产化政策要求严格，在虚拟化层⾯也要保证技术的⾃主可控能⼒。虽然国内⼤部分虚拟化⽅案均基于KVM 开发，
但不同产品的性能、稳定性、可靠性和硬件兼容能⼒可能⼤相径庭，是否具备完美替代VMware 虚拟化的⽔平，需要⽤户通过
⻓期测试进⾏验证。
⽬前，众多⾦融⾏业头部⽤户，在对SmartX 超融合（基于原⽣虚拟化ELF）的替代能⼒进⾏充分验证后，逐步以SmartX 超
融合替代⽣产环境中原有的VMware 虚拟化平台，⽀撑⾦融核⼼⽣产业务系统、信创数据库、⼀般应⽤系统、办公系统、灾备
等多种应⽤场景，同时实现了虚拟化平台国产化替代与IT 基础架构升级。其中，⼤部分⽤户使⽤SMTX 迁移⼯具将原
VMware 平台业务虚拟机迁移⾄基于ELF 的超融合集群，在保证迁移稳定性和兼容性的同时避免业务中断带来的影响。
某⼤型国有银⾏
总⾏+分⾏部署1500+个基于ELF 虚拟化的超融合节点，⽀撑上万台虚拟机
某⼤型国有银⾏很早就开始对VMware 替代进⾏调研，并于2017 年对多种国内外主流超融合产品进⾏了测试。其中，在对
SmartXELF 虚拟化和VMware 虚拟化构建的超融合集群进⾏对⽐测试时，该银⾏充分认可SmartX原⽣虚拟化的功能和稳定
性，于2019 年在总⾏数据中⼼⽣产环境部署60+ SmartX超融合节点（基于ELF 虚拟化），承载C 类及D 类应⽤、DB2
数据库、Redis 缓存数据库等，运⾏多个⽣产系统。
随后的6 年时间⾥，该银⾏持续探索超融合的应⽤场景，基于SmartXELF 虚拟化构建超融合信创云平台，并在全国30+家
分⾏快速复制超融合落地实践，⽬前已总计部署1500+个超融合节点，⽀撑上万台虚拟机运⾏。所有超融合集群全部采⽤原⽣
虚拟化ELF，替代VMware虚拟化的同时降低运维难度与总体投⼊成本。
81
点击链接，阅读原⽂：
某⼤型国有银⾏VMware 替代实践

82. ⾦融⾏业VMware 升级替代实践
82
某头部保险机构
3 年时间验证ELF 虚拟化⽣产级能⼒和迁移可⾏性，灵活实现VMware 替代
某头部保险机构原采⽤传统虚拟化架构⽀持⽣产环境业务系统，为了进⼀步提升IT 基础架构的性能和敏捷⽀撑业务的能⼒，
在经过前期充分验证的基础上，决定采⽤超融合架构作为其未来基础设施的主要形态。在虚拟化平台的选择上，考虑到⾦融⾏
业IT 系统的国产化要求，希望考察国产虚拟化平台的替代能⼒，逐步推进VMware 虚拟化平台的替代。
2018 年，该机构在开发测试环境部署若⼲节点的SmartX超融合（采⽤ELF 虚拟化），经过⼀年的使⽤和探索，充分验证了
SmartXELF 虚拟化平台的可靠性和稳定性，以及从VMware 迁移虚拟机到ELF 的可⾏性。此后的3 年时间⾥，⽤户分阶段
以SmartX超融合（ELF 虚拟化）替代原⽣产环境中的VMware 虚拟化架构，稳定承载包括团险销管系统、个险核⼼、团险
核⼼、团险规则引擎在内的所有⽣产业务系统和100+MySQL 数据库，并以“SmartX超融合+ VMware 虚拟化”融合部署的⽅
式⽀撑Oracle 数据库，两种环境统⼀管理，灵活实现VMware 替代。
某头部券商
陆续部署1400+ SmartX超融合节点替代Nutanix、VxRail等国外产品，推进信创转型
作为国内领先的证券公司，某证券公司的IT 基础设施需要⽀撑海量的交易和⾮交易业务，对稳定性、性能、安全性以及⾃主
可控都有着极⾼的要求。为了应对不断增⻓的业务需求、提升IT 效率并响应国家信创战略，该券商经历了从传统架构到多种
超融合⽅案的探索，最终选择SmartX超融合作为基础架构之⼀，并在全国范围内进⾏了⼤规模部署，构建了稳固的⾦融云底
座。
点击链接，阅读原⽂：
保险私有云IaaS 资源池选型与演进之路

83. ⾦融⾏业VMware 升级替代实践
83
•早期超融合探索（2016 年）：该券商开始关注并尝试超融合技术，初期采⽤了Nutanix、Hyperflex、VxRail等国外⼚商的
产品，主要⽤于外围系统POC 和部分⽣产环境。
•国产化选型（2017 年）：随着国内超融合技术的发展和信创战略的提出，⽤户开始将⽬光投向国内⼚商，对多家国内超融
合解决⽅案进⾏了考察和测试，其中包括SmartX。
•选型考量与最终选择：多家⼚商参与选型，该券商综合考量了产品技术、⽣态兼容性、性能表现、服务⽀持和⻓期发展战略
等因素，最终选择了SmartX，其在与现有云管平台的集成⽅⾯展现了良好的兼容性，降低了集成难度。
⾃2017 年底起，该券商稳步推进SmartX超融合的部署与扩展，并逐步将其应⽤于核⼼交易系统和信创场景。⽬前SmartX
超融合已应⽤于该券商全国多个数据中⼼，总计部署1400+节点，承载20000+ 个虚拟机，⽀撑包括核⼼交易系统、信创系
统在内的各类关键业务。同时，该券商也积极推进虚拟化平台的演进，从最初的VMware 逐步转向SmartX⾃主研发的ELF
虚拟化平台，实现了技术⾃主可控。
某⼤型保险机构
⼀期项⽬迁移500+ 业务虚拟机，同时实现VMware 和Nutanix 替代
某头部保险机构原采⽤国外超融合平台承载⽣产业务系统，⽽随着国外⼚商调整中国区服务策略，该⽤户希望将原平台虚拟机
批量迁移⾄SmartX企业云平台。为确保迁移的顺利开展，⽤户先对SMTX 迁移⼯具进⾏了测试。
点击链接，阅读原⽂：
常⻅误区解读之⼆：超融合不⽀持⼤规模
部署，也没有落地案例？

84. ⾦融⾏业VMware 升级替代实践
84
结果显示，基于多种常⽤的操作系统，业务虚拟机均可完整迁移⾄SmartX企业云基础设施集群，整体迁移操作也⼗分简单，
⽤户只需要指定好源端和⽬标端，即可⼀键发起迁移，迁移过程⽆需⼈⼯⼲预，即使迁移失败也不影响源端数据，待条件允许
重新发起迁移任务即可。
基于以上测试，⽤户计划使⽤SMTX 迁移⼯具将源端虚拟化集群的700+ 业务虚拟机和300+ 开发测试虚拟机分批次迁移⾄
SmartX企业云平台。为确保迁移⼯作的顺利进⾏，每次迁移任务前，SmartX⼯程师都会与⽤户核对本次迁移任务的虚拟机情
况，并在迁移过程中严格按照每台虚拟机20 分钟停机时间的标准，甚⾄以更快的速度，完成虚拟机增量同步和开机验证，并
在⽤户确认业务可正常运⾏后标记迁移任务完成。
⽬前，⼀期迁移项⽬已顺利完成500+ 业务虚拟机和开发测试虚拟机的批量迁移任务，剩余迁移⼯作正在如期进⾏中。⽤户对
整体迁移过程的控制、迁移效率、任务成功率以及在有效控制迁移停机时间等⽅⾯都⽐较满意。
某保险资管⽤户
以SmartX超融合替代VMware 并开展容灾演练
某保险资管⽤户依据IT 建设现状，计划针对不同业务系统分别开展VMware 替代与信创改造，并建设异地灾备集群保障数据
可靠性。在⼀期项⽬中，⽤户分别基于Intel 和鲲鹏芯⽚架构服务器构建了两个SMTX OS（ELF）集群，承载PUB 集群、OA
点击链接，阅读原⽂：
VMware 虚拟机迁移指南：10
⼤关键问题与3 例⽤户实践

85. ⾦融⾏业VMware 升级替代实践
85
集群等周边⽣产系统与DMZ 集群，并分别建设相应的灾备环境，通过SMTX 备份与容灾的复制与恢复功能，将主机房的业务
虚拟机复制到灾备备份机房进⾏保护（间隔12 ⼩时）。复制通过150Mbps 专线完成，并可按需进⾏容灾备份演练。⽬前，
SmartXECP ⼤幅缩短⽤户灾备演练⽤时，实现“基础设施20 分钟、⾼优先级业务30 分钟、主要业务1 ⼩时“的RTO 灾备
⽬标。后续建信资管将根据实施效果进⾏节点扩容，以实现业务系统的全⾯迁移以及更完善的⾼可⽤保护。
某信托公司
SmartX超融合替代VMware vSphere 和Tanzu，实现双重容灾保护
某信托公司为了满⾜业务灵活发展需求，在前期建设⽅案中使⽤SmartX超融合集群（采⽤VMware vSphere 虚拟化）部署
VMware TKG，承载容器化开发测试和⽣产⼯作。由于VMware 替代等需求不断凸显，⽤户需要对现有IT 基础架构及容器平
台进⼀步改造。
基于⽤户侧SmartX超融合集群多年的稳定运⾏表现，⽤户使⽤3 台海光服务器部署了基于ELF 虚拟化的SmartX超融合集
群，对SKS 进⾏了测试。结果显示，SKS 通过了功能、性能、集成插件以及可靠性等数⼗个项⽬的测试，尤其是在⾃动化运
维、滚动更新、⽇志管理和故障诊断等关键功能上，具备VMware 同等替代能⼒。
基于此，⽤户重新设计并建设了业务架构，同时替换了VMware 虚拟化，以SmartX超融合平台（搭配原⽣虚拟化ELF）和
SKS 承载了虚拟化及容器化业务，并通过CloudTower实现了两个环境的统⼀管理。其中，容器化业务通过SKS 承载，涵盖
了四⼤模块：信托类、权益类、APP 服务和⼯具类服务。
点击链接，阅读原⽂：
⽤户实战：灾备建设场景的VMware
虚拟机迁移规划与实操经验分享

86. ⾦融⾏业VMware 升级替代实践
86
点击链接，阅读原⽂：
某信托公司：替代VMware 虚拟化与容器
平台，构建业务双活超融合集群
SKS通过全部NSX替代能力测试项目

87. ⾦融⾏业VMware 升级替代实践
87
某⾦融投资机构
以SmartX企业云替代VMware 虚拟化和NSX，实现异构芯⽚集群同城容灾
某投资公司原使⽤VMware 虚拟化和NSX ⽀持⽣产业务系统，为迎接国产化转型浪潮，⽤户决定以国产超融合软件+信创硬
件构建新集群，同时利旧原VMware 集群的硬件搭建灾备集群，保障信创集群的稳定、连续运⾏。
在超融合选型时，⽤户⾮常看重⼚商的⾃研能⼒，尤其是平台的安全防护能⼒和备份容灾能⼒，需要具备与VMware 同等的⽔
平。经过多重测试验证，⽤户选择以SmartX超融合（采⽤原⽣虚拟化ELF）搭配海光架构服务器构建信创集群，⽀持办公类
应⽤系统及相关组件，包括国产数据库、中间件等。同时，以Everoute替代VMware NSX，并引⼊SMTX 备份与容灾，为
信创集群提供双重保障：
•部署Everoute分布式防⽕墙，保障数据中⼼⽹络三层互联，实现⽹络流量的微分段防护，满⾜国产化需求的同时获得更精
细、更严格、更简洁的⽹络安全管理能⼒。
•利⽤SMTX 备份与容灾的复制与恢复功能，将⽣产环境数据复制到基于原VMware 硬件（Intel 架构服务器）搭建的
SmartX超融合灾备集群。同时，利⽤备份与恢复功能，将⽣产环境虚拟机备份⾄利旧的NAS 存储，提供数据可⽤性的同
时降低灾备成本。
某基⾦公司
替代VMware 虚拟化承载O32、TA、FA、CC 等核⼼业务系统
某基⾦公司在经过2 年多的测试验证后，选择以SmartX超融合承载核⼼⽣产应⽤：德邦基⾦先引⼊SmartX超融合⽀撑办公
⽣产业务系统、⽹站业务系统和开发测试环境，在⽣产环境验证了超融合架构的性能和稳定性后，分别基于SmartX超融合
（采⽤原⽣虚拟化ELF）搭建两个⽣产集群，承载ToB和ToC端应⽤系统，包括O32、TA、FA、CC、反洗钱等核⼼业务
系统及数据库，以及订单、⽹站、直销等业务系统，在进⾏基础架构升级的同时实现了VMware 虚拟化的替代。

88. ⾦融⾏业VMware 升级替代实践
88
某头部期货机构
SmartX超融合替代VMware 虚拟化，承载绝⼤部分业务系统
某头部期货机构原有环境中硬件设备超出使⽤年限，需整体进⾏更换，同时客户正规划建设灾备中⼼。对于性价⽐、稳定性、
平滑迁移的需求，是当时机房改造和灾备中⼼建设的重点。为此，SmartX推荐客户采⽤三套SmartX超融合集群分别承载
CTP 主席系统（包含⽣产库、历史库核⼼数据库）、仿真系统、主席灾备系统。原单机ESXi上的虚拟机通过SmartX⾃研的
SMTX 迁移⼯具，平滑迁移⾄超融合集群。改造前，客户环境中有⼏⼗台ESXi宿主机及物理机，管理复杂度很⾼；基于
SmartX超融合改造后，通过三套集群共13 个节点即承载了绝⼤部分业务系统，并新建了灾备中⼼，完成改造⽬标。
某财务公司
同时替代vSphere和vSAN，以SMTX迁移⼯具实现100+虚拟机平稳迁移
⽤户原⽣产环境基于物理机和VMware 超融合两种架构部署，其中VMware 超融合在使⽤过程中遇到了vSAN 软件升级复杂、
故障恢复触发时间过⻓等问题，影响了业务的正常开展。加上⽤户⼀直有国产化替代的需求，于是借着⽣产环境资源扩容的机
会，⽤户引⼊SmartX超融合（基于ELF 虚拟化），运⾏数据仓库等⽣产业务系统，验证国产超融合的性能和稳定性。
经过半年的稳定运⾏，客户认为SmartX超融合具备⽣产级VMware 超融合替代能⼒，随即利⽤SMTX 迁移⼯具，将⽣产环
境VMware 超融合平台上100+ 虚拟机全部迁移⾄基于ELF 的SmartX超融合平台。整体迁移⼯作在⼀星期内完成，期间业
务虚拟机全部保持在线状态，没有对⽣产业务带来影响。⽬前，SmartX超融合集群已稳定承载⽤户⼀般⽣产财务类应⽤系统、
数据库（Oracle 和MySQL）、中间件（Nginx、JDK、Redis 等）等应⽤系统近⼀年时间，帮助⽤户在实现VMware 整体替
代的同时提升了架构稳定性。
点击链接，阅读原⽂：
⼀⽂了解SmartX⽤户的VMware 国产化
替代实践

89. 医疗⾏业VMware 升级替代实践
89
⾯对VMware 订阅制转型以及数字化业务对IT 基础设施带来的更⾼的能⼒要求，不少医院正在评估VMware 虚拟化（ESXi
和vSphere）、vSAN，甚⾄全栈架构的国产替代⽅案。⽽作为关乎国计⺠⽣的重要⾏业，医院对替代⽅案的关键业务⽀持能
⼒、稳定性、安全性、迁移可靠性等⽅⾯，都提出了更⾼的要求：
•替代⽅案需要具备VMware 同等能⼒，能够满⾜绝⼤多数核⼼业务场景下的云计算平台及存储功能需求。
•医院业务需要7*24 不间断运⾏，因此替代⽅案需要能够为医疗核⼼业务系统（包括HIS、EMR、LIS、PACS、集成平台等）
及对应数据库提供⾼效、稳定的基础设施⽀持。
•医院数据中⼼分为内外⽹区域，替代⽅案需要提供可满⾜不同区域计算、存储与⽹络安全要求的完整数据安全保护⽅案。
•从VMware 迁移到新平台，需要保证整个迁移过程的可靠性与稳定性，确保替代项⽬不会对医院业务运⾏带来负⾯影响。
为了帮助医疗机构顺利实现VMware 替代，SmartX 为医疗⽤户提供了基于SmartX 企业云平台的VMware 替代⽅案——以
⼀套技术栈提供⾃主研发的计算、存储、⽹络、数据保护和管理能⼒，并通过⾃研的SMTX 迁移⼯具⽀持⼤规模虚拟机跨平台
迁移，满⾜医疗⽤户VMware 虚拟化、vSAN，甚⾄全栈架构的替代需求。
⽬前，SmartX 已帮助全国50+ 各类型与规模的医院完成了VMware 替代，替代产品包括VMware 虚拟化、vSAN 以及数据
中⼼全栈基础设施，⽀撑医疗核⼼应⽤系统、数据库、灾备、开发测试、DMZ 区域等多种场景。以下，我们将分享17 家医疗
机构VMware 替代的实践经验，供读者参考。
1.VMware虚拟化替代实践
⽬前，众多⼤型三甲医院和中⼩型医院已采⽤SmartX 原⽣虚拟化ELF 替代或接替VMware 虚拟化，⽀撑HIS、EMR、LIS、
PACS、集成平台等医疗核⼼业务系统及对应数据库，节约虚拟化授权成本的同时实现IT 基础架构的现代化升级。

90. 医疗⾏业VMware 替代实践
90
⼴州医科⼤学附属第三医院
搭建异构超融合集群，从VMware 虚拟化到国产虚拟化
作为国内最早的⻄医医院之⼀，⼴州医科⼤学附属第三医院（⼴医三院）原使⽤⼑⽚服务器和物理机⽀持医院业务系统与数据
库，⾯对快速增⻓的业务需求，存在机房空间有限、难以灵活扩展、投⼊成本过⾼等问题。⾃2018 年起，⼴医三院引⼊
SmartX 超融合平台，基于不同品牌的服务器搭建了异构超融合集群。在建设初期，⼴医三院选择了基于VMware 虚拟化的
SmartX 超融合部署⽅案，⽀持⽼院区PACS 等业务系统。⽽经过多年的稳定运⾏，⽤户在⽣产环境中验证了SmartX 超融合
的替代能⼒，于是在进⾏新院区建设时选择使⽤SmartX 原⽣虚拟化ELF 构建新集群，承载ERP、HIS 中间件等业务系统，
实现了从VMware 虚拟化到国产虚拟化的过渡。
中⼭⼤学附属第⼀医院
SmartX超融合替代VMware 虚拟化，部署300+ 虚拟机
作为始建于1910 年的百年⽼院，中⼭⼤学附属第⼀医院（中⼭⼀院）原采⽤物理机/VMware 虚拟化+全闪双活存储的部署形
式⽀持医院主要应⽤系统。随着信息业务不断推陈出新，⾯对机房空间紧张、虚拟机数量增速过快等问题，2018 年起，中⼭
⼀院选择超融合作为IT 基础架构转型升级的技术路线，依托SmartX 超融合平台，逐渐部署300 多台虚拟机，⽀持集成平台
ESB 服务器、PACS 应⽤、HIS 应⽤、重症系统、互联⽹医院、⾏政、科研、教学等多个应⽤场景，显著提升了IT 云化⽔平
和临床服务效率，赋能智慧医院建设。
点击链接，阅读原⽂：
客户访谈视频| SmartX 超融合落地⼴医三
院，重塑IT 基础架构
点击链接，阅读原⽂：
中⼭⼀院：华南第⼀综合性三甲医院的IT
基础架构转型实践

91. 91
⾸都医科⼤学宣武医院
ELF 承载HIS 数据库备库、IIH 基础架构（Redis）等应⽤系统，稳定运⾏2 年+
⾸都医科⼤学宣武医院（宣武医院）是以神经科学和⽼年医学为重点的三级甲等综合医院。基于对IT 基础架构的云化转型、
横向扩展、稳定性、国产化替代等⽅⾯的考虑，宣武医院分阶段引⼊SmartX 超融合（基于原⽣虚拟化ELF），替换原有
VMware 虚拟化集群，承载HIS 数据库备库、IIH 基础架构（Redis）、岱嘉PACS 前端，⼿麻、数据质量检测等应⽤系统。
其中，HIS 数据库备库集群通过Oracle ADG 技术实现源端数据库⼀体机的灾备保护。⽬前，超融合集群已稳定运⾏超过2 年，
⽤户亦对SmartX 专业、及时的服务⾮常满意。
北京积⽔潭医院
基于ELF 虚拟化的超融合⼀体机承载DMZ 区互联⽹医疗业务，多次扩容承载全院业务系统
北京积⽔潭医院主院区⻓期依赖物理机/VMware 虚拟化+集中式存储的传统架构⽀撑核⼼业务系统与数据库。借着新院区上线
新业务的契机，医院希望引⼊国产虚拟化⽅案，探索VMware 虚拟化替代的可⾏性。经过⻓期验证，医院选择采⽤基于
SmartX 原⽣虚拟化ELF 的超融合⼀体机，承载DMZ 区域的互联⽹医疗业务，包括互联⽹诊疗、挂号、视频问诊三⼤板块。
此次替代实践不仅帮助⽤户节约了虚拟化采购成本，还实现了IT 基础架构的分布式转型，⽀持未来业务的创新发展与快速发
布。
点击链接，阅读原⽂：
宣武医院：超融合承载HIS 等核⼼业务应
⽤，加速智慧医疗转型
医疗⾏业VMware 替代实践

92. 92
⾃贡市第⼀⼈⺠医院
引⼊SmartX 超融合搭建信创集群，并部署SKS，承载HIS 等核⼼业务应⽤
作为四川省医疗信创试点单位，⾃贡市第⼀⼈⺠医院在对传统VMware 虚拟化架构进⾏信创改造时⾯临FC SAN 交换机“卡脖
⼦”和⾼昂硬件投⼊的双重挑战。为了在实现信创⽬标的同时降低转型成本，⽤户选择了“云原⽣+国产超融合”的转型路线，先
基于openEuler 操作系统进⾏应⽤容器化改造，后引⼊SmartX 超融合（搭配SMTX Kubernetes 服务）基于海光C86 架构
服务器构建超融合信创集群，统⼀⽀持、管理部署在容器环境的HIS、EMR 等应⽤系统和部署在虚拟化环境的数据库系统。通
过转型，⽤户不仅⾼效实现了整套架构的国产化替代，也有效提升资源利⽤效率和⽹络传输效率达2 倍以上。
某⻄南省份三甲综合医院
基于ELF 的超融合替代VMware 虚拟化+集中式存储，实现虚拟机迁移⽆感知
某⻄南省份三综合甲医院原使⽤“VMware 虚拟化+集中式存储”的传统虚拟化架构⽀撑核⼼⽣产业务系统，⽽存储与计算容量
不⾜，⾯临⾼额的扩容成本。为了降低未来持续的投⼊成本，医院计划整体以SmartX 超融合为核⼼开展IT 基础架构转型，
替换⽼院区传统架构——以8 节点超融合集群（基于SmartX 原⽣虚拟化ELF）替换⽼院区VMware 虚拟化平台，承载⽼院
区内⽹除HIS 数据库以外的全部业务，包括HIS、电⼦病历、PACS、LIS 等各类应⽤系统。虚拟机迁移由SMTX 迁移⼯具⽀
持，整体过程⼗分顺畅，前端业务⼏乎⽆感知。
点击链接，阅读原⽂：
⾃贡市第⼀⼈⺠医院：超融合与SKS 承载
HIS 等核⼼业务应⽤，加速国产化与云原⽣
转型
点击链接，阅读原⽂：
某⻄南省份三甲综合医院VMware 虚拟化
替代实践
医疗⾏业VMware 替代实践

93. 93
榆林市中医院
SmartX 超融合⽀撑全院业务系统及HIS 系统的多套Oracle RAC 数据库，利旧原有服务器
榆林市中医院原使⽤基于VMware 虚拟化的传统架构⽀持全院业务系统，在进⾏新院区数据中⼼建设时，医院希望使⽤国产虚
拟化⽅案，避免VMware 虚拟化⾼昂的投⼊成本。最终，榆林市中医院采⽤SmartX 超融合组建内⽹和外⽹两个集群，稳定⽀
持包括HIS、EMR、HRP、合理⽤药、OA 在内的全院业务系统，并⽀撑HIS 系统的多套Oracle RAC 数据库稳定运⾏。同时，
⽅案中有效利旧原有服务器，与超融合⼀体机实现统⼀管理，在降低建设成本的同时简化运维。
四川省乐⾄县中医医院
SmartX 超融合双活集群承载⼏乎全部核⼼应⽤系统和对应数据库，基于SMTX 迁移⼯具平滑迁移
四川省乐⾄县中医医院原本使⽤VMware 虚拟化+集中式存储承载院内核⼼业务系统，⾯对VMware 收购后⻛险，⽤户开始寻
求国产化替代⽅案。经过⻓时间评测，⽤户最终选择采⽤SmartX 超融合双活集群作为医院私有云底座，承载包含HIS、EMR、
集成平台、PACS 在内的⼏乎全部核⼼应⽤系统和对应数据库，还进⼀步适配了坐标软件新操作系统阿⾥⻰蜥8 版本，并以
SMTX 迁移⼯具实现原有VMware 业务虚拟机的平滑迁移，通过SmartX 超融合双活集群，实现虚拟化、存储、⽹络统⼀管
理的同时，充分提升了集群可靠性和数据安全。
点击链接，阅读原⽂：
4 个超融合利旧⽤户实践，揭秘如何以更低
成本实现架构转型
医疗⾏业VMware 替代实践

94. 94
某军队三甲医院
基于ELF 的SmartX 超融合接替Nutanix 集群，并通过SMTX 迁移⼯具实现⾼效迁移
某军队三甲医院原采⽤Nutanix 超融合（搭配VMware 虚拟化）⽀持内⽹应⽤系统，⽽随着Nutanix 调整中国区服务策略，
⽤户发现Nutanix 的售后服务经常出现反馈不及时的情况；同时，⽤户的Nutanix 集群维保服务也即将到期。考虑到售后服务
缺失对业务连续性和IT 运维效率的影响，⽤户选择以SmartX 超融合（搭配原⽣虚拟化ELF）接替Nutanix 集群，承载部分
内⽹业务系统和部分新上线的⻔诊类业务系统。其中，承载内⽹业务系统的虚拟机，由⽤户通过SMTX 迁移⼯具⾃⾏迁移⾄
SMTX OS 集群，整个过程简单且⾼效。
某军队综合三甲医院
核⼼业务系统迁移⾄ELF，通过SMTX 备份与容灾及双活保障业务连续性
某军队综合三甲医院原采⽤VMware 虚拟化⽀持医院业务系统，为了满⾜国产化转型要求，医院采⽤SMTX 迁移⼯具整体迁
移⾄ELF 虚拟化平台，承载HIS、HIP、EMR、LIS、合理⽤药、院感等核⼼业务系统。在此基础上，为了进⼀步保障数据可
靠性，⽤户通过SMTX 备份与容灾，将关键业务虚机备份⾄外置NAS 存储，同时针对核⼼业务集群进⾏了双活保护（数据库
采⽤Oracle RAC 实现双活），实现了IT 基础设施国产化与现代化的双转型。
点击链接，阅读原⽂：
某军队三甲医院VMware 虚拟化与
Nutanix 超融合替代实践
医疗⾏业VMware 替代实践

95. 95
昌吉州⼈⺠医院
3 节点SmartX 超融合集群⽀撑除PACS 外的所有业务系统，稳定运⾏1 年+
昌吉州⼈⺠医院原采⽤物理机/VMware 虚拟化+集中式存储的传统架构⽀持院区业务系统，⽽随着使⽤年限不断增⻓，基础设
施计算和存储资源即将消耗殆尽，即使扩容也将⾯临⾼昂的虚拟化授权成本和存储设备采购成本。基于此，医院希望采⽤⼀套
全新的超融合架构，接管VMware 虚拟化平台和物理机承载的业务系统，同时避免存储单点故障⻛险，实现基础架构的“降本
增效”。
在SMTX 迁移⼯具的帮助下，医院顺利将原有VMware ESXi 虚拟机迁移⾄SmartX ELF 虚拟化平台，以三节点SmartX 超
融合集群⽀撑除PACS 以外的所有业务系统，包括HIS 应⽤及数据库（cache 数据库，主备库模式）、EMR、LIS、集成平台
等。⽬前，整套架构已稳定运⾏超1 年时间，充分验证了ELF 虚拟化对VMware 虚拟化的替代能⼒。
此外，⾼州市中医院、北京北⼤医疗康复医院、腾冲市⼈⺠医院、温县⼈⺠医院等医疗⽤户，也采⽤ELF 虚拟化⽀持⽣产业务
系统，实现VMware 虚拟化替代或降低VMware 依赖程度。
点击链接，阅读原⽂：
宣武医院：超融合承载HIS 等核⼼业务应
⽤，加速智慧医疗转型
医疗⾏业VMware 替代实践

96. 96
2.VMwarevSAN及全栈替代实践
越来越多的医疗机构也选择以SmartX 超融合实现VMware 虚拟化和vSAN 的整体替代，并结合SmartX ⽹络与安全组件
Everoute、SMTX 备份与容灾、SMTX Kubernetes 服务（SKS）等多种服务，实现全栈的基础设施国产化转型。
某省级⼈⺠医院
基于SmartX 超融合构建信创集群，承载红帆OA 管理平台和多个新建综合业务
某省级⼈⺠医院原先使⽤VMware 虚拟化和vSAN ⽀持医疗业务系统，作为省级医疗信创试点单位，计划引⼊国产超融合系
统，在验证VMware 替代能⼒的同时完成信创转型。在经过多重评估后，医院基于SmartX 超融合（搭配海光信创服务器）构
建了信创集群，承载红帆OA 管理平台和多个新建综合业务，包括流调平台、隐私计算平台、肿瘤规范化平台等。在进⾏迁移
时，医院根据不同的业务需求，分别采⽤SMTX CloudMove 和SMTX 迁移⼯具，将多个虚拟化平台中的业务机器平滑迁移⾄
超融合信创集群。SmartX 超融合信创集群不仅成功帮助⽤户树⽴起“信创转型标杆”，还可为实际业务开展提供⾼性能、⾼可
靠⽀持。⽬前，经过约1 年的稳定运⾏，医院决定继续扩容SmartX 超融合集群，承载更多业务系统。
医疗⾏业VMware 替代实践
点击链接，阅读原⽂：
某省级⼈⺠医院：基于SmartX 超融合开启
信创转型探索，部署红帆OA 等应⽤

97. 97
某省级重点三甲医院
基于ELF 搭建信创集群，并与vSphere 融合部署的超融合集群实现统⼀纳管
某省级重点三甲医院原先主要采⽤VMware 虚拟化+vSAN+Horizon、Nutanix 超融合等国外产品进⾏基础设施建设。⽽在信
创转型与国外产品“撤出”中国的背景下，医院希望以国产超融合产品⽀撑集成平台与新建院区云桌⾯业务。经过对产品稳定性
与可靠性评测后，医院选择使⽤SmartX 超融合替代vSAN，以统⼀的架构⽀持双虚拟化平台并推进信创转型：
•基于SmartX 原⽣虚拟化ELF 构建⼀个超融合信创集群（搭配鲲鹏信创服务器），全⾯适配国产化硬件，并尝试采⽤
SMTX Kubernetes 服务（SKS）承载容器化应⽤，实现虚拟化与容器环境的统⼀管理。
•构建多个与vSphere 融合部署的超融合集群，承载全院集成平台业务和新院区虚拟桌⾯应⽤系统，ELF 与vSphere 集群可
采⽤CloudTower 实现统⼀纳管。
复旦⼤学附属华⼭医院
SmartX 超融合纯软件架构搭配国产服务器构建超融合集群，顺利迁移40+ 虚拟机
复旦⼤学附属华⼭医院原有IT 基础架构⻓期依赖VMware vSphere 与vSAN 承载核⼼业务。随着VMware 被博通收购带来
的服务⻛险及国产化政策要求，医院亟需稳定、⾃主可控的替代⽅案，同时需满⾜多院区统⼀运维、业务平滑迁移等需求。
在进⾏多⽅验证后，医院选择采⽤SmartX 超融合纯软件架构（基于ELF 虚拟化）搭配国产服务器构建超融合集群，⽬前已
通过SMTX 迁移⼯具将40+ ⽣产环境的VMware 虚拟机（运⾏⼿麻系统、财务系统等）在线迁移⾄超融合平台，整个过程业
务零中断。同时，⽤户还通过Everoute 分布式防⽕墙和SMTX 备份与容灾，进⼀步实现数据安全加固。
医疗⾏业VMware 替代实践

98. 98
⽬前，⽤户已通过POC 测试，验证了SmartX 超融合平台的性能与稳定性可充分满⾜VMware 替代需求，提升业务连续性的
同时减少50% 运维复杂度。未来，⽤户将分阶段利旧8 台vSphere 服务器构建SmartX 超融合集群，结合CloudTower 统
⼀管理多资源池，⽀撑未来业务扩容。
江苏省中⻄医结合医院
以SmartX 超融合替代vSAN，建设超融合双活数据中⼼
江苏省中⻄医结合医院通过两期项⽬，逐步实现了从vSAN 到vSphere 的国产化替代：
•先以SmartX 超融合替换了VMware 超融合架构中的vSAN 存储，运⾏除HIS 以外的所有核⼼业务系统和数据库，在保留
vSphere 使⽤习惯的同时，以SmartX ⾃研分布式存储ZBS 为应⽤系统提供相较vSAN 更⾼的性能和稳定性，为医疗机构
进⾏VMware 替代提供灵活选择。
•在充分验证SmartX 超融合的性能和稳定性后，⽤户以SmartX 超融合（采⽤ELF 虚拟化）构建超融合双活数据中⼼，⽀
持新建机房的⽣产业务系统，进⼀步节省VMware 虚拟化授权成本，实现超融合架构的国产化转型，并为后续的信创建设
奠定基础。
点击链接，阅读原⽂：
江苏省中⻄医结合医院VMware 替代实践
点击链接，阅读原⽂：
复旦⼤学华⼭医院实践案例
医疗⾏业VMware 替代实践

99. 99
复旦⼤学附属肿瘤医院
在性能与稳定性测试中表现最佳，SmartX 超融合（采⽤ELF 虚拟化）逐步替代VMware
复旦⼤学附属肿瘤医院原有基础架构主要使⽤VMware vSphere+vSAN 和Nutanix 超融合，⽽随着VMware 订阅制调整以及
信创转型需求提上⽇程，医院希望逐步实现从VMware 向国内平台的转型，并为未来的信创转型打下基础。在测试评估众多超
融合产品后，医院选择了性能与稳定性表现最好的SmartX 超融合（采⽤ELF 虚拟化），利⽤SMTX 迁移⼯具将部分
VMware 虚拟机迁移⾄SmartX 超融合集群。SmartX 技术团队也帮助医院制定了整体的VMware 替代⽅案，梳理已有集群情
况并规划未来迁移节奏。后续，医院将采⽤“⼩步快跑”的策略，将承载核⼼业务系统、PACS 系统和DMZ 环境、开发测试环
境、备份环境的虚拟机，分批次迁移⾄SmartX 超融合，实现整体的VMware 国产化替代。
湖州市中医院
新院区搭建两个SmartX 超融合集群承载除HIS 外所有业务系统，以⾃研分布式存储接替vSAN
湖州市中医院⻓期依赖VMware 构建基础设施，主要采⽤“VMware 虚拟化+集中式存储”的架构承载⽣产业务系统，以及
“VMware 虚拟化+vSAN”的架构⽀持虚拟机桌⾯集群。在进⾏新院区建设时，考虑到国产化转型趋势，医院希望引⼊新的国产
基础设施承载新院区业务系统，同时可⽀持将⽼院区业务系统平稳迁移⾄新集群。
在了解到SmartX 超融合可实现基于VMware 虚拟化的融合部署后，医院对SmartX 超融合与VMware 超融合进⾏了多⽅⾯
的论证研讨，参考了省内三甲医院测试及使⽤效果，发现SmartX超融合性能更佳（并且在超融合部署后进⼀步测试验证了这
⼀结果）。⽬前，医院已在新院区构建了两个SmartX 超融合集群（搭配VMware 虚拟化）承载新院区除HIS 以外的所有业
务系统，包括联众集成平台体检、⻔诊输液、质控、随访、验⾎等业务系统，以⾃研分布式存储接替vSAN 提供⾼性能、⾼可
靠的存储服务。⽼院区虚拟化和物理机环境的业务也通过VMware vMontion 和SmartX P2V 迁移⼯具平稳迁移⾄新院区
SmartX 超融合集群。
医疗⾏业VMware 替代实践

100. 制造⾏业VMware 升级替代实践
100
在“中国制造2025”政策的推动下，国内的新能源、汽⻋制造、半导体、⾼端装备等⾼端制造产业迎来了蓬勃发展，成为全球
制造业版图中举⾜轻重的⼒量。订单数量的激增与国产化转型的趋势，也为制造企业的IT 基础设施带来了新的挑战：不仅需
要在⾼并发情况下保证关键业务系统能够⾼效、稳定地运⾏，还需要完成VMware 虚拟化（ESXi/vSphere）和vSAN 的国产
化替代，以更好地满⾜国内业务需求。
作为核⼼技术⾃主研发的专业超融合⼚商，SmartX 已帮助众多制造企业以SmartX 企业云平台实现VMware 虚拟化和vSAN
的国产替代，为MES、PLM、ERP、⼯业控制、SCADA 等关键应⽤系统、数据库、开发测试环境、灾备环境，以及⻋联⽹、
IoT、⼤数据平台等创新应⽤场景，提供⾼性能、⾼可靠、灵活易运维的IT 基础设施⽀持。
某服装⾏业⻰头集团
从VMware 替代到IT 基础架构全栈升级
某服装⾏业⻰头集团数据中⼼包含机架式服务器、数据库⼀体机、超融合⼀体机与SAN 存储等多种技术架构，运维复杂度较
⾼，由于承载核⼼业务的硬件陆续进⼊报废周期，企业技术决策团队开始重新设计数字化底座的演进⽅向，选择使⽤VMware
vSphere+SMTX OS 的融合部署⽅式，保留VMware vSphere 作为计算平台，与SMTX OS 的分布式存储组合形成超融合架
构，使⽤全闪服务器承载集团和上市公司的核⼼数据库、财务系统等业务系统。
随后企业技术团队对SmartX 原⽣虚拟化ELF 的能⼒进⾏验证，结果表明其在性能、成本、管理等⽅⾯更具优势，相较
vSphere+SmartX 超融合的融合部署模式，SmartX 原⽣计算虚拟化+存储虚拟化的组合可以带来10%～20% 的性能提升，降
低虚拟化授权成本，并简化运维，同时相⽐VMware，SmartX 能够提供更及时的技术服务。

101. 制造⾏业VMware 升级替代实践
101
基于此，该企业在扩容时陆续采⽤SmartX 原⽣虚拟化ELF 的超融合架构，并在随后的3 年间陆续扩容4 次，逐步承载ERP、
Oracle 数据库等更多重要业务系统。此外该企业还引⼊SMTX Kubernetes 服务（SKS）、SMTX 备份与容灾模块的原⽣⽆代
理备份、Everoute ⽹络与安全模块中的分布式防⽕墙等解决⽅案，并通过CloudTower 统⼀管理，满⾜⼤量业务系统在稳定
性、⾼可⽤、安全性等⽅⾯等要求。⽬前该服装企业已在⽣产和测试环境部署共45 个SmartX 超融合节点，实现从基础替代
到全栈升级。
信义玻璃
基于SmartX 企业云基础设施构建数据中⼼双活集群，并替代VMware 虚拟化承载核⼼数据库
信义玻璃原有基础设施包含公有云与私有云，并主要采⽤vSphere + Dorado 全闪存储的架构⽀持核⼼数据库业务。为了更好
满⾜极致可⽤性与⻛险防控需求，信义玻璃经过充分调研论证，辅以严苛的基于实际环境的压⼒测试，最终选择采⽤SmartX
企业云基础设施⽅案构建数据中⼼双活集群，以更低的投资成本建设完全满⾜需求的⾼可⽤IT 基础架构。
同时信义玻璃以SmartX 企业云基础设施整体接替原先承载⾮双活业务数据库的“vSphere+全闪集中式存储”架构，⽀持资⾦管
理、TSM 等应⽤系统数据库。经过实测，相较于原有VMware+全闪集中式存储架构，SmartX 企业云基础设施进⼀步提升了
核⼼数据库的性能，核⼼数据库实测Swingbench 平均TPS 性能提升18%，且总体投⼊成本降低约30%。
此外，信义玻璃采⽤Everoute 微分段防⽕墙模块提供虚拟化环境“东-⻄向”安全防护能⼒，增强数据中⼼⽹络安全。
点击链接，阅读原⽂：
信义玻璃：构建跨数据中⼼业务双
活，实现企业云基础架构转型

102. 制造⾏业VMware 升级替代实践
102
某全球知名电⼦科技智造服务商
以SMTX OS（ELF）、SKS 和Everoute ⽀撑全球多地分⽀⼯⼚重要产线业务
该企业原本⾃有OpenStack + Ceph 架构的私有云，并基于VMware vSphere 承载核⼼⽣产业务系统与数据库。借由分公司
MES 系统和产线相关系统建设的契机，该企业验证了SMTX OS（搭配ELF 虚拟化）相⽐OpenStack+Ceph 能够以更少的
节点提供更⾼的性能。基于此该企业采⽤SmartX 超融合替代原VMware 虚拟化，承载ERP、MES、产线综合等核⼼⽣产系
统，以及Oracle RAC、开发测试。随后该企业将SmartX 超融合陆续推⼴⾄全球多地区分⽀⼯⼚，同时引⼊SKS，为MES
和产线综合业务提供统⼀的虚拟化和容器⽀撑平台，并以Everoute 提供DMZ 区⽹络安全防护。
国内某动⼒锂电池领军制造商
以ELF 作为未来新建集群唯⼀虚拟化平台，100+ SmartX 超融合节点⽀撑MES 等核⼼业务系统
国内某动⼒锂电池领军制造商原采⽤VMware 虚拟化+集中式SAN 存储的IT 基础架构，但该架构在⾯对电池⽹私有云、客服、
HR 以及⼤数据等新业务系统的上线需求时，存在基础架构整体资源利⽤率低下、分⽀机构平台和硬件设备运维复杂、设备⽼
旧稳定性差、扩展性有限等问题，难以跟上企业业务快速发展的步伐。
基于上述问题，⽤户希望以新的国产化平台进⾏IT 基础架构升级与VMware 替代。⽤户经多轮测试评估后发现，SmartX 超
融合⽅案（采⽤ELF 虚拟化）不仅能完美适配业务需求，还可显著节省虚拟化授权成本，因⽽果断选⽤。在数⽉的实际运⾏中，
基于ELF 平台的SmartX 超融合凭借卓越的性能表现和⾼度的可靠性，赢得⽤户充分信赖。
点击链接，阅读原⽂：
如何构建简单、智能⼜可靠的分
⽀⼯⼚IT 基础设施？

103. 制造⾏业VMware 升级替代实践
103
基于此，⽤户将ELF 平台确⽴为未来新建集群的唯⼀虚拟化平台，并陆续部署100+ 节点，全⾯承载总部及多地分⽀⼯⼚的核
⼼业务系统，包括MOM（AI-MES）、⼤数据平台、电池⽹私有云、客服、HR 等多种⽣产系统与数据库。
某全球知名新能源创新科技公司
7 个基地/分公司部署100+ ELF 节点，承载MES 等核⼼业务系统
某全球知名新能源创新科技公司致⼒于为全球新能源应⽤提供⼀流的解决⽅案和服务。⽤户早期各基地均采⽤VMware
vSphere 作为虚拟化平台，然⽽随着VMware 被博通收购，在中国市场的服务与技术⽀持逐渐减弱，且订阅模式带来了⾼额成
本与资产不确定性。为此，⽤户希望寻找⼀个⾼稳定、⾼可靠、⾼性能的国产替代，以承载分公司产线系统。
经深⼊技术调研，客户发现SmartX ⾃研分布式存储ZBS 在同等硬件下，可提供更⾼稳定性、可靠性与性能，且SmartX 超
融合在多⾏业已有⼤量关键业务承载实践。基于此，客户以SmartX 超融合（采⽤ELF 虚拟化）逐步替代7 个基地/分公司的
100+ VMware 虚拟化集群，承载MES、AGV、化成、⼯艺管理、园区⼀卡通、综合管理等业务系统。该⽅案采⽤纯软件部署，
⽀持多品牌服务器，通过ELF 虚拟化与ZBS 组合的永久许可模式降低授权成本，并可与现有运维、备份平台对接，有效降低
替换建设成本。
点击链接，阅读原⽂：
SmartX 在新能源-国内某动⼒锂电
池领军制造商实践案例
点击链接，阅读原⽂：
SmartX 在新能源-某全球知名新能
源创新科技公司实践案例

104. 制造⾏业VMware 升级替代实践
104
某头部锂电池制造集团
引⼊SmartX 超融合⽀撑MES、PLM 等应⽤系统，降低VxRail 依赖程度
某头部锂电池制造集团多年来与Dell EMC 保持深度合作，⼤量引⼊预装VMware vSphere、vSAN、vCenter 等软件的
VxRail 超融合产品。但⾃VMware 产品许可模式转为订阅制，⽤户在新购设备与扩容⽅⾯的成本将⼤幅增加。与此同时，
VMware 在中国市场的原⼚技术⽀持团队逐步撤离，售后服务质量难以保障。在此背景下，⽤户对该产品未来的技术演进与服
务保障产⽣了诸多担忧，迫切寻求更稳定可靠的国产替代⽅案，希望新⽅案能满⾜如下需求：
•产品成熟度⾼，在运维功能、存储性能、稳定性、可靠性及市场⼝碑等⽅⾯均能实现VxRail 超融合的同等替代。
•新架构需要为MOMS、SCADA、储电平台、PLM、MES 等业务系统提供稳定、⾼性能⽀持。
•核⼼技术⾃主可控，降低许可成本和转型⻛险。

105. 制造⾏业VMware 升级替代实践
105
基于测试评估结果，⽤户最终从诸多供应商中选择了SmartX 超融合（采⽤ELF 虚拟化）⽅案，并于下属两家⼦公司的多地
⼯⼚部署了SmartX 超融合集群，以验证其VMware 替代能⼒：
•⼦公司A：在⼴东和越南⼯⼚分别部署3 节点SmartX 超融合集群，承载MES、PLM 等关键⽣产业务系统及其数据库。
•⼦公司B：在⼦公司A 部署SmartX 超融合并稳定运⾏半年后，⼦公司B 也在⼴东⼯⼚先后部署了6 节点SmartX 超融合，
运⾏MOM、SCADA、储电平台等业务系统。
基于SmartX 超融合的稳定表现，未来⽤户计划循序渐进地推进VMware 替代项⽬，实现国产化转型的同时降低投⼊成本。
兰钧新能源
SmartX 超融合（ELF）⽀撑AGV 等业务系统，逐步替代VXRail
兰钧新能源科技有限公司（以下简称“兰钧新能源”）是“世界500 强企业”⻘⼭实业旗下的新能源创新⾼科技锂电池公司，主
要从事锂离⼦电池、电池模组、电池系统等研发、⽣产和销售。
兰钧新能源原有IT 架构主要使⽤VXRail ⼀体机，由于VMware 授权模式转变，带来成本增⻓和稳定性⻛险，因此⽤户希望
引⼊新基础设施平台进⾏整体替代。在深⼊调研论证多家产品⽅案后，⽤户认为基于SmartX 超融合的基础设施⽅案具备稳定
可靠、⽣态开放、⽀持利旧（保护现有硬件投资）等优势，最终选择以SmartX 超融合承载⽣产环境的AGV 和锂电池包装等
业务系统。
兰钧新能源在⼀期项⽬先构建了10 节点SmartX 超融合集群（基于原⽣虚拟化ELF），待在⽣产环境验证超融合稳定性后，
不久便于⼆期项⽬继续扩容4 节点SmartX 超融合，并引⼊Everoute 提供分布式防⽕墙，进⼀步保护业务稳定安全运⾏。⽬
前，SmartX 超融合集群运⾏稳定，未来⽤户计划逐步对VMware 架构进⾏整体替换。

106. 制造⾏业VMware 升级替代实践
106
某头部新能源汽⻋制造商
30+ 超融合节点承载关键⾃研系统和整⻋⼯⼚业务，逐步推进vSphere 和vSAN 替代
某头部新能源汽⻋制造商在现有基础架构中采⽤VMware 超融合⽅案，但⾯临vSAN 性能与稳定性问题，且随着VMware 转
向订阅制，采购成本增加，促使⽤户寻求替代产品。为确保⾃研业务系统和MES 系统的稳定运⾏，⽤户希望新的⽅案既可兼
容VMware 虚拟化，⼜可提供优于vSAN 性能和稳定性的分布式存储服务，满⾜制造运营系统和MES 系统的⾼性能与连续稳
定运⾏需求。
经过对多家超融合⼚商的深⼊考察，⽤户对SmartX 超融合⽅案给予⾼度认可，最终选择引⼊6 节点的SmartX 超融合，承载
⾃研业务系统、MES / MOM 系统以及综合业务系统。其中，SmartX 超融合集群继续沿⽤VMware 虚拟化，保持了与原⽣
VMware 环境⼀致的运维能⼒。⽽SmartX 的⾃研分布式存储核⼼ZBS ，在性能和可靠性上相较vSAN 有显著提升，进⼀步
保障了⽤户的关键业务稳定运⾏。
⽬前，经过前期的⼩范围尝试，SmartX 超融合的⾼性能和⾼稳定性受到企业内部⼀致好评，于是在今年继续扩容27 节点
SmartX 超融合集群⽀撑整⻋⼯⼚业务。未来，⽤户计划逐步替换vSAN 和vSphere，以期实现对VMware 的整体替换，最终
形成更具性价⽐且⾼效稳定的超融合基础架构。
点击链接，阅读原⽂：
SmartX 在汽⻋-某头部新能源汽⻋
制造商实践案例

107. 制造⾏业VMware 升级替代实践
107
⻓安跨越
构建⻋联⽹业务系统新⽣态，以SmartX 原⽣虚拟化ELF 替代VMware 虚拟化
为了满⾜⽇益增⻓的市场需求，⻓安跨越持续推动IT 智能化转型，在⻋联⽹领域不断发⼒。其原有IT 基础架构采⽤VMware
虚拟化+ 集中式存储，存在灵活性差、管理复杂度⾼等问题，不适宜建设⻋联⽹业务。因此⽤户计划新建平台承载⻋联⽹业务，
并借此机会验证国产虚拟化平台对VMware 的替代能⼒。
在深⼊开展技术调研后，⽤户发现基于原⽣虚拟化ELF 的测试数据相较于VMware 虚拟化性能⾼出60%，且具备部署管理便
捷、硬件解耦灵活、可利旧服务器等优点，具备充分的VMware 虚拟化替代能⼒。
基于测试结论，⽤户引⼊3 节点的SmartX 超融合（采⽤ELF 虚拟化），承载包含Kafka 、HDFS 等组件的⻋联⽹⼤数据业
务系统，并在数⽉后继续扩容4 节点，形成异构集群。借助SmartX 研发的SMTX 迁移⼯具，⽤户成功在极短的停机时间内，
实现了从原VMware 平台到ELF 平台的平滑过渡，保障了业务的连续性。
此次⻋联⽹业务的成功实践，证明了国产超融合替代VMware 以及ELF 平台承载⼤数据业务的可⾏性。⽤户规划，未来将⻋
辆产销类核⼼业务包括PLM，DMS（经销商管理系统）等产线的⽣产数据库类业务迁移⾄SmartX 超融合（采⽤原⽣虚拟化
ELF），全⾯完成VMware 的替代。
点击链接，阅读原⽂：
⻓安跨越：超融合守护⻋联⽹系统
稳定⾼效运⾏

108. 制造⾏业VMware 升级替代实践
108
某⻋辆制造与研发机构
以SmartX 超融合（ELF）重构数据中⼼，实现基础架构国产化升级演进
作为中国轨道交通装备⾏业的核⼼研发机构，某⻋辆制造与研发机构过往数据中⼼IT 基础架构采⽤VMware vSphere 虚拟化
平台结合传统SAN 存储阵列，以及部分VxRail 超融合⼀体机产品构建。随着轨道交通装备智能化、⽹联化的快速发展，⽤户
承担的科研项⽬和产业化业务规模持续扩⼤，现有架构在资源利⽤率、横向扩展能⼒和运维复杂度⽅⾯逐渐难以满⾜业务需求。
此外，⾯对国际供应链不确定性增加和国产化替代政策导向，⽤户需要寻找能够⻓期稳定⽀撑其关键业务的⾃主可控技术⽅案。
为应对上述挑战，⽤户于2023 年启动数据中⼼基础架构升级，经过多轮技术验证和产品选型，最终采⽤SmartX 超融合解决
⽅案构建新⼀代基础设施。SmartX 超融合凭借其在制造业领域的丰富实践经验、对异构环境的兼容性，以及⽀持VMware 环
境⽆缝迁移的能⼒脱颖⽽出。项⽬实施过程中，⽤户采⽤“并⾏验证、平滑迁移” 的策略：⼀⽅⾯基于SmartX 超融合（采⽤
ELF 虚拟化）构建统⼀资源池，实现现有Intel 集群的业务迁移；另⼀⽅⾯部署SMTX ZBS 分布式存储集群，逐步替换原有
SAP 业务依赖的传统SAN 存储，解决了传统架构下存储扩展困难、资源利⽤率低的问题。
⽬前，⽤户数据中⼼已形成VMware 与SmartX 超融合双架构并⾏的混合基础架构平台。其中，SmartX 超融合集群承载了超
过30% 的原有业务系统，包括部分涉及⽣产制造、流程管理的关键业务系统。通过⽣产环境的实际验证，SmartX 超融合在
IOPS 性能、存储扩展性以及跨地域容灾能⼒⽅⾯均达到国际同类产品⽔平，特别是在SAP 等关键业务场景中，SmartX ZBS
分布式存储的读写性能较传统SAN 存储提升40%，有效⽀撑了⽤户全球化业务拓展。
未来，⽤户计划按照“先边缘后核⼼、先新后旧” 的原则，逐步将现有VMware 环境中的ERP、OA 等系统迁移⾄SmartX 超
融合平台，形成以SmartX 超融合为核⼼的新⼀代IT 基础设施，为中国轨道交通装备⾏业的数字化转型提供坚实⽀撑。

109. 制造⾏业VMware 升级替代实践
109
汇川新能源汽⻋
以SmartX 超融合（ELF）承载MES、WMS、ERP 等关键业务系统，在⽣产环境中验证VMware 替代可
⾏性
汇川新能源汽⻋技术（常州）有限公司（以下简称“汇川新能源汽⻋“）过往数据中⼼IT 基础架构主要使⽤VMware vSphere
+ vSAN / SAN 存储。在双基地建设中，数据中⼼业务逐步增多，汇川新能源汽⻋对于基础设施层⾯的稳定性、运维的便利性
提出了更⾼的要求。此外，随着VMware 销售策略的调整，⽤户担⼼VMware 提供的国内服务在未来存在不确定性，可能会
对企业数据中⼼的⻓期稳定运⾏产⽣负⾯影响。
为保障企业数据中⼼关键业务的可持续发展，汇川新能源汽⻋针对多个国产⽅案进⾏对⽐。最终，SmartX 凭借其在制造业领
域积累的⼤量实际⽣产环境业务承载经验脱颖⽽出。此外，SmartX 超融合可⽀持⽤户构建异构集群，实现对不同品牌、不同
类型硬件设备及虚拟化平台的统⼀纳管，为渐进式的VMware 替代提供便利；同时提升资源利⽤率，保障业务在不同架构间的
平滑迁移，满⾜企业在转型过程中对基础设施动态调整的需求。
⽬前，汇川新能源汽⻋数据中⼼采⽤VMware 虚拟化架构和SmartX 超融合（ELF 虚拟化）两套基础设施集群并⾏的⽅案，
形成基础设施异构集群。其中，新上业务系统运⾏在SmartX 超融合集群上，包括MES、WMS、OA、ERP 等从办公到⽣产
的多种业务系统。未来，汇川新能源汽⻋计划结合硬件替换周期，有序推进现有VMware 环境向SmartX 超融合（ELF）环境
的过渡。

110. 制造⾏业VMware 升级替代实践
110
某头部半导体封测企业
SmartX 超融合（ELF）替代vSphere，承载各地⼯⼚关键业务
作为集成电路封测领域全球知名企业，某头部半导体制造商⻓期依赖物理机和VMware 虚拟化⽀撑业务系统。然⽽，随着设备
⽼化亟需更新，加之各⼯⼚建设标准不⼀、异构服务器混杂，统⼀管理难度⽇益增⼤。在此背景下，⽤户决⼼借新上业务系统
之机，对现有IT 架构进⾏全⾯转型升级，并提出三⼤核⼼需求：
•构建敏态弹性的架构，以承载当前及未来新增业务，逐步搭建企业云平台。
•新架构必须具备⾼可⽤性，确保在部分硬件故障时，数据和业务仍能持续稳定运⾏。
•在将业务从原有VMware 环境迁移⾄新平台的过程中，必须保障业务连续性，实现⽆缝迁移。
经过深⼊技术调研，⽤户计划采⽤超融合架构，并要求该架构满⾜关键业务系统（SAP 应⽤、MES 等）对可靠性和性能的严
苛要求。在对多家⼚商和产品评估时，SmartX 在制造⾏业丰富的MES 承载经验，以及成功实现从VMware 到原⽣虚拟化
ELF 平滑迁移的众多案例，在众多⽅案中脱颖⽽出，成为⽤户的最终选择。
⽤户在升级⽅案中以SmartX 原⽣虚拟化ELF 替换VMware vSphere，承载各地分⽀⼯⼚除SAP HANA 数据库外的所有系统
（包括MES、SAP、OA 等应⽤），并利⽤SMTX 迁移⼯具实现业务平稳迁移。此外，⽤户还通过CloudTower 统⼀管理各
⼯⼚，显著提升了运维效率。最终，SmartX 超融合架构助⼒⽤户实现快速部署，各⼯⼚集群部署时间缩短⾄2 天以内，不仅
有效⽀撑了关键业务系统稳定运⾏，更为企业未来的IT 发展提供了按需投资的灵活空间。

111. 制造⾏业VMware 升级替代实践
111
三安半导体
引⼊SmartX 超融合（ELF）和SMTX 备份与容灾，同步实现VMware 替代和架构升级
三安光电作为国内光电及第三代半导体领域的⻰头企业，其全资⼦公司重庆三安半导体有限责任公司（以下简称“三安半导体”）
主要从事半导体新材料、外延、芯⽚与器件的研发、⽣产与销售。此前，三安光电总部及各基地均采⽤VMware 虚拟化搭配集
中式存储的架构，但随着业务发展，原有架构暴露出诸多问题：
•各基地存储品牌与型号繁杂，导致运维难度剧增。
•总部远程统⼀运维模式下，⼈员少、任务重的⽭盾突出。
•VMware 被博通收购后，中国市场服务与技术⽀持⼒度逐渐削弱，新的订阅模式也带来更⾼的成本与资产不确定性。
为此，三安半导体开始寻求VMware 的国产替代⽅案。经过对多家国产超融合产品的严格测试，SmartX 凭借优异的性能与稳
定性脱颖⽽出，构建5 节点超融合集群（采⽤ELF 虚拟化）⽀撑产线综合系统、设备⾃动化管理系统（EAP）和部分Oracle
RAC 数据库。为了进⼀步提升架构可⽤性，⽤户还以SmartX 超融合成功对接了现有的zabbix 平台（监控告警），并利⽤
SMTX 备份与容灾的备份功能，将虚拟机整机备份⾄本地NAS 存储。
⽬前，整套系统已稳定运⾏超1 年，⽤户计划在未来逐步推进VMware 替代进程，以SmartX 超融合实现架构升级与国产化
转型。

112. 制造⾏业VMware 升级替代实践
112
某半导体研发和制造企业
SMTX 迁移⼯具迁移数⼗台VMware 虚拟机，⽀持办公与研发业务
某半导体研发和制造企业提供涵盖数据中⼼芯⽚、IoT 芯⽚的端云⼀体全栈产品。⽤户原有IT 基础架构采⽤VMware 虚拟化
平台+ 国产集中式存储的组合模式，承载内部办公和部分研发设计系统。随着VMware 订阅政策调整及IT 资源需求量⽇渐增
⻓，亟需寻找具备⾼性能、⾼稳定性且⾃主可控的替代⽅案，在实现降本增效的同时保障业务平稳运⾏。
经过严格的产品测试，⽤户最终选择SmartX 超融合解决⽅案（采⽤ELF 虚拟化）承载内部办公系统和研发测试组件。
•⾼性能⼤容量⽀撑：采⽤5 节点NVMe 混闪架构的SMTX Halo 超融合⼀体机，配置25GB ⽹卡和RDMA ⽹络，单节点
裸容量达120TiB，保证⾼性能的同时显著降低硬件采购成本。
•⽆缝迁移能⼒：通过SMTX 迁移⼯具将数⼗台VMware 虚拟机平滑迁移⾄新平台，省去业务重新部署的复杂流程。
•全栈管理能⼒：引⼊SMTX 备份与容灾，实现虚拟机数据备份，并通过CloudTower 统⼀管理平台实现超融合集群中虚拟
化、存储、⽹络、备份的⼀站式管理，完整替代原有的VMware + CommVault ⽅案，简化运维复杂度。
后续，⽤户将不断扩⼤SmartX 超融合集群，在更多场景探索可能性，逐渐实现VMware 的全部替换。

113. 制造⾏业VMware 升级替代实践
113
某珠三⻆知名印刷电路板（PCB）制造商
SmartX 超融合替代传统VMware 虚拟化架构，提升架构灵活性与业务连续性
某珠三⻆知名PCB 制造商原来的IT 基础架构主要使⽤了VMware 虚拟化+ SAN 存储的传统架构。此前，⽤户的服务器硬件
和存储设备上线年限⽐较⻓，⾯临资源不⾜和扩容困难等问题，⽆法响应MES 等新业务系统的上线需求。同时，硬件故障⻛
险越来越⾼，不能稳定⽀撑MES 等核⼼业务系统，随时可能对⼯⼚产线的正常运⾏带来严重影响。
基于此，⽤户希望从“烟囱式传统架构”向更稳定、更灵活的“云架构”进⾏转型，经过多次技术交流和⽅案沟通，最终选择了最
稳定可靠的SmartX 超融合进⾏VMware 传统架构替代。项⽬实施交付后，⽤户逐步将MES、WPT、报价、EAP、APS 等核
⼼⽣产业务系统迁移到SmartX 超融合集群当中。后续根据容灾需求，⽤户计划利⽤SmartX 超融合的双活集群技术，从单数
据中⼼架构逐步转化为双活数据中⼼架构，提⾼业务访问的连续性，进⼀步保证⼯⼚产线的稳定运⾏。
翰博⾼新材料
引⼊SmartX 超融合⽀撑核⼼产线业务，推进VMware 虚拟化和vSAN 替代
翰博⾼新材料是国内领先的光学整体解决⽅案提供商，专注于显示设计、光学开发、智能制造和供应链整合，提供背光显示模
组、导光板等多种产品。⽤户数据中⼼原先⼴泛采⽤VMware 虚拟化+ vSAN 架构承载核⼼业务系统，在VMware 调整授权
⽅式后，⽤户开始寻求国产化替代⽅案。同时，⼯⼚新MES 产线上线，也为IT 基础架构提出了更⾼的性能和稳定性要求。
⽤户先调研了同⾏业头部企业的国产⽅案使⽤情况，并深度体验了多种产品⽅案，最终决定采⽤SmartX 超融合（搭配ELF
虚拟化）承载新上线的核⼼MES 产线。未来，随着产业布局的进⼀步拓展，⽤户还将在国外等地⼯⼚⼤规模部署SmartX 超
融合，为产线业务提供稳定、⾼性能的底座⽀撑。

114. 更多⾏业⽤户VMware 升级替代实践
114
韩国电商ConnectWave
传统虚拟化架构运维压⼒⼤，SmartX ELF 虚拟化为300+ 虚拟机提供统⼀⽀持
ConnectWave 是韩国专业的电⼦商务服务和解决⽅案提供商，其原来的⼤部分IT 基础设施基于物理服务器和单节点传统虚拟
化，运维⼯程师需要同时维护分布在两个IDC 机房的多个⼤型机架及独⽴系统，导致运维⼯作量⼤，运维效率低。为了减轻运
维负担，实现多套设备统⼀管理，ConnectWave 在SmartX 韩国团队的帮助下，以SmartX 企业云整合分公司多种IT 基础架
构，替代VMware 虚拟化⽀撑核⼼业务、⼤数据分析等系统，并采⽤SMTX 迁移⼯具将⽀持订单、⽀付、库存管理、配送管
理等购物服务系统的300~400 台虚拟机迁移⾄SmartX 超融合集群。此外⽤户引⼊SMTX Kubernetes 服务（SKS），为⾃
研⼤语⾔模型PLAi 的训练和使⽤，提供虚拟化和容器平台统⼀调度和编排，并结合GPU/vGPU能⼒提供⾼性能。
国药现代
基于超融合架构提升平台性能及稳定性，实现VMware 替代
国药现代原有基础架构存在资源分散、利⽤率低的问题，⽽⼤量设备导致机房空间不⾜，资源扩展也难以开展。同时部分设备
⽼旧，性能⽆法达到要求，因此国药现代计划采⽤SmartX 超融合对基础架构平台进⾏转型升级。共部署3 个集群，包含15
个节点，承载内部办公（AD、邮件、CRM 等）、核⼼⽣产（ERP、HR、财务等）、研发测试的所有业务系统，并采⽤SMTX
OS 超融合+ 原⽣虚拟化ELF 替换原有的VMware 虚拟化+ 传统架构平台。国药现代1 周内完成了整个平台搭建以及
VMware 虚拟化平台的迁移⼯作，⼤幅提升了平台的性能及稳定性，满⾜核⼼业务系统的SLA 标准。

115. 更多资料
电⼦书
SmartX 超融合技术原理与特性解析合集（⼀）
虚拟化与存储
SmartX 超融合技术原理与特性解析合集（⼆）
管理与运维
博客
如何制定VMware 替换⽅案？Gartner 这样建
议｜SmartX 趋势分享
>>访问专题⻚⾯，获取更多资料
视频
SMTX 迁移⼯具流程讲解与操作实践
医疗⾏业VMware升级替代视频合集
115
VMware 替代常⻅问题合集：评估、选型、迁
移与落地
⼀⽂了解超融合虚拟化与虚拟机管理关键技术与
特性（含视频解读）SmartX 超融合技术原理与特性解析合集（三）
全栈能⼒
VMware升级替代视频合集
国产虚拟化如何选型评估？
VMware 虚拟化和容器平台替代实践

116. Copyright©2025北京志凌海纳科技股份有限公司(SmartX);保留所有权利。
本文档和本文包含的信息受国际公约下的版权和知识产权的管辖。版权所有。未经SmartX事先书面许可,不得以任何方式,包含
但不限于电子、机械或光学方式对本文档的任何部分进行复制,存储在检索系统中或以任何形式传播。所有非SmartX公司名称、
产品名称和服务名称仅用于识别目的,可能是其各自所有者的注册商标、商标或服务标记。所有信息都未获得该所有方的参与、授
权或背书。
SmartX会定期发布产品的新版本。因此,对于当前使用的某些版本,本文档中介绍的一些功能可能不受支持。有关产品功能的最新
信息,请参阅相关产品的发行说明。如果您的SmartX产品未提供本文档所述的功能,请联系SmartX以获取硬件升级或软件更新。
您的建议有助于我们提升文档内容的准确性或组织结构。将您对本文档的意见发送到[email protected]来帮助我们持续改进本
文档。