Brownfield Import fails on retry with "vCenter Server no NSX Manager present" guardrail error in VCF 9.0.x

Products

• VMware SDDC Manager
• VMware Cloud Foundation

Issue/Introduction

• During a Brownfield Import operation in VCF 9.0.x, if the sub-task to deploy or join a shared NSX instance fails after the vCenter Server has been registered as a Compute Manager in NSX, retrying the parent import task will fail.
  
  
• The retry fails during the pre-import guardrail validation phase with the following error:

Check Name: vCenter Server no NSX Manager present
Description: Check that the vCenter Server does not have an NSX Manager connected to it
Details: Detected an NSX Manager connected to the vCenter Server
Remediation: Please ensure that no NSX Manager is connected to the vCenter Server to be imported/converted

• The SDDC Manager UI shows the import task as "Failed internally" with a warning message indicating the domain "...has previously failed a convert/import operation and can be rolled back."

Cause

• The Brownfield Import workflow in VCF 9.0.x spawns an isolated task for NSX Deployment/Joining. If this NSX task fails (e.g., due to a network glitch during VIB installation) after the Compute Manager connection is established between vCenter and NSX, retrying the parent import task triggers a rollback.
  
  
• This rollback cleans up the SDDC Manager inventory but does not remove the Compute Manager registration from the NSX instance.
  
  
• When the import is retried with the original specification (which states NSX needs to be newly deployed or joined), the guardrails detect the orphaned vCenter-to-NSX connection and block the operation, as it expects a clean vCenter with no pre-existing NSX connection.

Resolution

Do not retry the failed Brownfield Import task directly.

1. Ensure that the underlying issue causing the independent NSX configuration task to fail is resolved.
2. Discard the failed import task and start a fresh Brownfield Import operation.
3. In the new import specification, mark the vCenter as having an existing NSX (i.e., useExistingNsxDeployment set to true) instead of choosing to deploy or join an NSX instance, since the Compute Manager connection is already established from the previous attempt.