VCF9.1 Converge&Import：无NSX的vCenter接入场景完整解析

VCF9.1执行Converge（收敛）或者Import（导入）棕地vCenter环境时，如果源vCenter尚未部署NSX‑T，工作流会自动部署一套与源vCenter兼容的NSX版本；当前VCF9.1.0逻辑会选择对vCenter兼容性最好的最新NSX，该版本有可能属于“回溯版本back‑in‑time”，不存在直接升级到VCF9.1配套NSX 9.0.x/9.1.0的路径，后续整个VCF环境无法升级。本文拆解版本陷阱，给出三种生产可选处置方案，同时说明未来VCF9.1.x版本的改进规划，以及老NSX4.1.x跨大版本升级的两跳限制。

有VMware全系列产品官方资源和定制版资源需求的可以移步：

VMware全系列产品官方镜像和定制版下载汇总(更新到2026年8月）

时间：2026-08-01

查看

VCF9.1对不带NSX的外部vCenter做Converge/Import时会自动部署NSX；默认选vCenter兼容的最新NSX，该版本可能没有直通VCF9.1的升级链路，造成后续VCF整体升级预检查失败；未执行工作流可提前手动部署合规NSX或者通过KB429205覆盖版本；已经做错可通过KB430524回滚Converge/Import后重来；后续9.1.x版本会改为优先选取VCF BOM内的NSX版本；NSX4.1.x不能直接升到VCF9.1，必须先两跳升级到4.2.x中间版本。

一、问题产生原理与实例

注意：该版本兼容性以Broadcom官方Interoperability Matrix互操作矩阵为准。

二、三种业务处置方案

方案1：尚未执行Converge/Import，提前手动部署合规NSX（推荐）

1. 提前查阅互操作矩阵，挑选同时满足两点的NSX版本：①和源vCenter兼容；②具备升级到VCF9.1配套NSX的官方升级路径。

2. 手动部署该NSX‑Manager OVA，将源vCenter注册为NSX内的Compute Manager计算管理器。

3. 本阶段不需要准备ESXi主机安装NSX主机组件，只需要NSX‑Manager管理面就绪。

4. 再运行VCF Converge/Import工作流；SDDC‑Manager检测到已有NSX实例，会复用现有部署，不再自动新建NSX。

5. 条件满足即可保留完整后续VCF升级链路。

方案2：尚未执行Converge/Import，工作流内覆盖NSX版本

1. 仍然使用VCF工作流自动部署NSX，但是不使用系统自动挑选的“对vCenter最新兼容版”。

2. 参照VMware KB429205，在VCF Installer或者SDDC‑Manager中手动重写指定NSX版本参数。

3. 强制工作流部署我们预先选好、具备VCF升级路径的NSX版本。

方案3：已经做完Converge/Import，发现版本陷阱，升级预检查失败

1. 参考KB430524执行undo操作，撤销本次vCenter的Converge或者Import结果。

2. 环境恢复接入之前的状态。

3. 再执行方案1或者方案2，部署符合升级链路要求的NSX。

4. 重新运行Converge/Import接入vCenter，保证整套环境拥有VCF9.1升级路径。

三、VCF后续版本改进规划（9.1.x迭代）

• 现状VCF9.1.0：Converge/Import优先取“对源vCenter兼容的最新NSX”，不考虑VCF整体BOM升级链路，容易落入回溯版本陷阱。

• 未来VCF9.1.x优化：工作流不再单纯看vCenter兼容性，优先选择属于VCF官方BOM物料清单、具备VCF升级链路的兼容NSX版本。

• 价值：管理员不用再独立去核对NSX跨版本升级矩阵；但依然存在整个VCF大版本本身属于回溯版本的可能性，不过排查粒度提升到VCF发布级别，比单独核对组件简单很多。

四、额外场景：存量老NSX 4.1.x环境升级限制

已有环境运行NSX‑T 4.1.x，想要升级到VCF9.1.0：不支持直接一跳升级。

1. 必须两跳升级：NSX4.1.x → 先升级到受支持的NSX4.2.x中间版本；

2. 再由NSX4.2.x升级到VCF9.1配套NSX9.x版本。

3. 互操作矩阵文档已经增加脚注，专门标注该类需要中间跳转的版本约束。

五、实施前检查清单（生产运维）

• ☑ 确认源vCenter版本，查询互操作矩阵，区分“vCenter兼容”和“可升级到VCF9.1”两个条件。

• ☑ 未做Converge：优先方案1手动前置部署NSX；如果要用自动部署，走KB429205强制指定版本。

• ☑ 已做完Converge出现升级报错：使用KB430524回滚，禁止直接原地升级回溯版NSX。

• ☑ 存量NSX4.1.x：规划两跳升级路径，不可直接对接VCF9.1。

• ☑ 等待9.1.x版本后，可依赖VCF BOM自动选择NSX版本，但上线前仍建议复核。

六、高频问答

Q1：Converge/Import不带NSX的vCenter，能不能完全不部署NSX？ A：不能，VCF工作流会强制部署一套NSX‑Manager，这是VCF架构约束，无法跳过NSX组件部署。

Q2：手动提前部署NSX的时候，ESXi需要安装NSX主机模块吗？ A：不需要，只需要NSX‑Manager管理面就绪并注册vCenter为Compute‑Manager，主机准备工作交给后续VCF工作流。

Q3：已经部署了back‑in‑time回溯NSX，能不能直接单独升级NSX绕过VCF？ A：该类NSX版本本身就没有通往目标版本的升级路径，无法单独升级，只能撤销Converge重来。

Q4：KB429205、KB430524是什么？ A：KB429205：VCF安装器/SDDC‑Manager覆盖NSX部署版本；KB430524：撤销vCenter的Converge/Import棕地接入任务。

Q5：VCF9.1.0这个版本问题会永久存在吗？ A：9.1.0行为不变；在后续9.1.x小版本迭代中会修改逻辑，优先选取VCF‑BOM清单内NSX版本。

全文总结

VCF9.1.0执行Converge/Import接入原本无NSX的棕地vCenter时，系统会自动部署NSX；当前逻辑优先选择与源vCenter兼容的最新NSX，该NSX有可能是back‑in‑time回溯版本，缺少升级到VCF9.1配套NSX9.x的链路，直接造成后续VCF整体升级受阻。尚未执行接入可以手动提前部署合规NSX，或参照KB429205在工作流强制指定版本；已经部署出错，通过KB430524撤销Converge/Import再重新实施。未来VCF9.1.x将优化逻辑，优先选取VCF BOM物料清单内的NSX版本，降低版本陷阱风险；存量NSX4.1.x环境不支持直接升级VCF9.1，必须执行两跳中间版本升级。生产实施棕地接入，必须同时核对vCenter兼容性与VCF整体升级链路两个维度。