When converging or importing a vCenter Server environment that does not already include NSX, VMware Cloud Foundation (VCF) will automatically deploy NSX as part of the converge or import workflow. While the deployed NSX version will be compatible with the existing environment, it may have implications for future VCF upgrade paths.
The current behavior in VCF 9.1.0 is to deploy the latest NSX version that is compatible with the source vCenter Server version. However, depending on when the converge or import workflow is performed, that NSX version could be a back-in-time release that does not have a direct upgrade path to the current version of VCF.
Below is an example to help illustrate the current behavior. Let us assume we are starting with a vCenter Server 8.0 Update 3c environment. As of this blog post, the Interoperability Matrix, which is the source used to determine component compatibility, shows NSX 4.2.4.1 as the latest compatible version.
While this specific combination of vCenter Server and NSX is perfectly compatible, it becomes an issue if your intention is to upgrade to VCF 9.1.0. There is currently no supported upgrade path from this NSX version to NSX 9.0.x, let alone 9.1.0, which prevents the resulting VCF deployment from being upgraded to VCF 9.1.0.
Reference: https://interopmatrix.broadcom.com/Upgrade?productId=912&isHidePatch=false
What are your options if you would like to upgrade to VCF 9.1.0?
- Option 1: If you have NOT yet performed the VCF Converge or Import workflow, you can identify an NSX version that has a supported upgrade path to VCF 9.1.0 and manually deploy the corresponding NSX Manager OVA into your environment. You can then register your vCenter Server as a Compute Manager within NSX. There is no need to prepare the ESX hosts for NSX as part of this process. When you perform the VCF Converge or Import workflow, it will detect that NSX is already deployed and use the existing NSX deployment rather than deploying a new instance. As long as the NSX version you selected is compatible with the source vCenter Server and has a supported upgrade path to VCF 9.1.0, you can proceed with the upgrade without any issues. This is the most straightforward approach if you have not yet performed the Convert or Import workflow.
- Option 2: If you have NOT yet performed the VCF Converge or Import workflow and would prefer to have NSX automatically deployed as part of the process, you can override the default NSX Manager version within the VCF Installer or SDDC Manager using instructions outlined in KB 429205. This allows you to specify the desired NSX version rather than automatically deploying the latest compatible version.
- Option 3: If you have already performed the VCF Converge or Import workflow and later discover that you cannot upgrade to VCF 9.1.0 due to a pre-check failure caused by an NSX back-in-time release, you can follow KB 430524 to undo the VCF Converge or Import for your vCenter Server. Once the workflow has been reverted, you can follow either Option 1 or Option 2 to deploy a compatible NSX version before re-attempting the VCF Converge or Import. This will ensure that the resulting deployment has a supported upgrade path to VCF 9.1.0.
An area for improvement is making it easier for both the VCF software and our users to understand upgradability at the VCF release level rather than evaluating individual component versions. In a future VCF 9.1.x release, instead of defaulting to the latest NSX version compatible with the source vCenter Server, the VCF Converge and Import workflow will select the latest compatible NSX version that is part of a supported VCF release.
This means users will no longer need to independently verify the future upgrade path of the selected NSX version, as the deployment will be aligned with the latest supported VCF Bill of Materials (BOM). It is still possible for an entire VCF release to become a back-in-time release, but in that scenario, the upgrade compatibility will be much easier to identify at the VCF release level rather than having to reason about individual component versions.
Lastly, another NSX scenario that has been coming up involves customers running older NSX releases, such as NSX 4.1.x, who want to know whether there is a direct upgrade path to VCF 9.1.0. The answer is no. A two-hop upgrade is required, where NSX must first be upgraded from 4.1.x to a supported 4.2.x release before it can be upgraded to VCF 9.1.0. To help clarify this requirement, the NSX Interoperability Matrix now includes an additional footnote identifying the applicable versions that require an intermediate upgrade.
Thanks for the comment!