TL;DR · Key Takeaways
- In VCF 9, NSX is a managed component of the platform. SDDC Manager deploys it, lifecycles it, and is itself a component of every VCF 9 instance.
- The Simple deployment model collapses vCenter, SDDC Manager, and NSX Manager management into a tightly integrated set of appliances, so NSX is provisioned as part of bring-up rather than as a separate project.
- VCF Operations, with its new Fleet Management appliance, runs above the instances. A Fleet is multiple VCF deployments sharing common VCF Operations and Automation, and NSX health and lifecycle roll up there.
- Two paths get NSX into VCF 9: greenfield, where the VCF Installer deploys NSX for you, and brownfield, where an existing vCenter-plus-NSX environment is imported as a Workload Domain.
- The mental shift: stop treating NSX as a product you install and patch by hand. Treat it as a workload-domain capability the platform provisions and maintains, and design your operations around that.
The first time I helped a long-time NSX team adopt VCF 9, the hardest part was not technical. It was unlearning a habit. They had spent years owning NSX end to end: deploying the Managers, wiring the cluster, pushing VIBs, scheduling their own upgrades. In VCF 9 most of that is no longer their job, and the instinct to reach into NSX directly is the thing that gets people into trouble. NSX in VCF 9 is a managed component. The platform deploys it, runs it, and lifecycles it, and your job moves up a level. Understanding exactly where that line sits is what this Part is about.
SDDC Manager owns NSX inside the instance
Within a single VCF instance, SDDC Manager is the component that owns NSX. SDDC Manager 9 is installed or upgraded as part of any VCF 9 instance, and from there it deploys NSX, manages its lifecycle, and orchestrates the upgrades we walked through in Part 20. The Simple deployment model brings vCenter, SDDC Manager, and NSX Manager up as a tightly integrated set, so NSX is not a thing you stand up separately and then register. It comes with the instance. The SDDC Manager API can even deploy an NSX Edge cluster and place the VCF management components on an NSX overlay segment, which tells you how deep the integration goes: NSX is both managed by the platform and underpinning the platform.
What this means in practice is that the supported way to make NSX-affecting changes at the platform level is through SDDC Manager, not by logging into NSX Manager and improvising. NSX Manager is still where you configure networking and security intent (segments, gateways, DFW), but the lifecycle and the platform-level wiring belong to SDDC Manager. Cross that line, hand-edit something SDDC Manager believes it owns, and you create drift the platform will eventually fight you over.
Fleet Management runs NSX across instances
Above the individual instance sits VCF Operations, and this is the layer that changed most in VCF 9. From VCF 9, VCF Operations manages one or more VCF instances, and it ships with a new Fleet Management appliance alongside the Operations manager and the Operations collector. A Fleet is a set of VCF deployments that share common VCF Operations and VCF Automation instances. For NSX, this is where health, findings, and cross-instance lifecycle roll up. If you run three VCF instances each with their own NSX, you do not babysit three separate NSX operational consoles; the Fleet view is where you see them together.
This is the same fleet model the VCF 9 series covered for the whole platform, and NSX is simply one of the things that benefits from it. The practical effect is that NSX operations scale with the number of instances far better than they used to, because the management plane for running them is centralized even though each instance keeps its own NSX data and control plane.
Two ways NSX gets into VCF 9: deploy or import
There are two routes, and which one you are on changes your whole project plan. Greenfield is the clean path: the VCF Installer deploys NSX for you as part of bringing up the instance, fully under SDDC Manager from the first minute. Brownfield is the messier and more common one in established shops: you already run vCenter with NSX, and you import that environment into VCF 9 as a Workload Domain. The import path is what lets you adopt VCF without rebuilding your network from scratch, but it carries prerequisites, because the existing NSX has to meet the version and configuration requirements VCF expects before it will take ownership.
| Dimension | Greenfield deploy | Brownfield import |
|---|---|---|
| Who creates NSX | VCF Installer | Already exists, imported |
| Lands as | Native VCF component | Workload Domain |
| Main risk | Few, clean slate | Version and config prerequisites |
| Effort | Lower, automated | Higher, validate first |
| Typical for | New builds | Existing NSX estates |
Worked example
A shop runs vCenter with NSX 4.1.0.2 in production and wants VCF 9. They cannot just point the installer at it and walk away. The import path checks that the existing NSX meets the supported version and configuration baseline, and the conversion brings the environment in as a Workload Domain so SDDC Manager can take over lifecycle. Plan it as two phases: first get the existing NSX onto a version VCF will accept, then run the import. Teams that try to do both at once, upgrade and import in one window, are the ones that call me at 2 a.m.
The Bottom Line
NSX in VCF 9 is not a product you own end to end anymore, it is a capability the platform provisions and maintains. SDDC Manager owns the lifecycle and the platform wiring inside each instance; NSX Manager still owns your networking and security intent; VCF Operations and Fleet Management give you one place to run NSX across many instances. The operational discipline that follows is simple to state and hard to break old habits around: make lifecycle and platform changes through SDDC Manager, make intent changes in NSX Manager, and stop reaching past the platform to hand-edit things it believes it owns. Pick the deploy or import path deliberately, and for brownfield, separate the upgrade from the import. Teams that embrace the managed model get an NSX that scales operationally with the fleet. Teams that keep treating it as standalone get drift, surprises, and a platform that quietly disagrees with them. Which NSX are you running, the standalone one in your head or the managed one in your data center?
Day-2: the ownership line in practice
Knowing that SDDC Manager owns lifecycle and NSX Manager owns intent is the principle. The day-two operations where that line actually gets tested are certificates, credentials, drift and backups, and each one has a right side of the line to work from.
Certificates and credentials flow through SDDC Manager
Rotate NSX certificates and passwords through SDDC Manager, not by logging into NSX Manager and changing them directly. The platform keeps an inventory of the credentials it uses to manage NSX, and a direct change in NSX Manager desynchronizes that inventory. The result is the worst kind of break: NSX itself is fine, but SDDC Manager can no longer talk to it to run upgrades or workflows, and you find out at the least convenient moment. Treat credential and certificate operations as platform operations and route them through the layer that owns them.
Detecting and resolving drift
Drift happens when someone changes something SDDC Manager believes it owns, usually with good intentions during an incident. The fleet inventory and validation will surface the mismatch, and the fix is to reconcile through SDDC Manager rather than fighting it from the NSX side. The discipline that prevents the problem is simple to state and hard to enforce: platform-level changes go through SDDC Manager, day-to-day networking and security intent goes through NSX Manager, and nobody reaches past the platform to hand-edit what it manages. Most drift incidents I am called into trace back to a single well-meaning manual change made under pressure.
Backups belong to both layers
Because ownership is split, protection is split too. The NSX backup discipline from Part 19 protects your networking and security configuration, while the VCF and SDDC Manager backups protect the platform state that ties the instance together. You need both, and you need to have tested restoring both, because a recovery that brings back NSX intent but not the platform inventory, or the reverse, leaves you in a half-managed state that is harder to untangle than a clean rebuild.
Worked example
An NSX Manager certificate is about to expire and a well-meaning engineer replaces it directly in the NSX UI. NSX keeps working, so everyone relaxes. Two weeks later the team kicks off a VCF upgrade and it fails immediately at the NSX step, because SDDC Manager still holds the old certificate fingerprint and can no longer authenticate to NSX. The fix is to reconcile the credential through SDDC Manager, but the lesson is cheaper learned in advance: rotate the certificate through the platform in the first place, and the upgrade that was going to break never does.
Fleet operations scale the model, not the fault domain
As you add instances, the ownership model simply repeats: each instance has its own SDDC Manager that owns its NSX lifecycle, and VCF Operations gives you one place to watch them all. The trap is letting the single Fleet view convince you that you have built cross-instance resilience. You have not. Each instance’s NSX still fails, upgrades and recovers on its own, so your runbooks need to be per-instance even though your dashboards are fleet-wide. Design the operational procedures around the unit that actually fails, the instance, and use the Fleet view for what it is genuinely good at: seeing health and lifecycle status across the estate without logging into each one. Visibility scales beautifully here; resilience still has to be engineered instance by instance.
Import is a project, deploy is a step
The greenfield and brownfield paths feel similar on a slide and behave nothing alike in practice. A greenfield deploy is a step inside bring-up: the installer stands NSX up correctly, fully under SDDC Manager from the first minute, and you move on. A brownfield import is a project with its own plan, because the existing NSX has to be brought to a supported version and configuration before VCF will take ownership, and the conversion has to be validated at each stage. The mistake that turns the import into an incident is collapsing two changes into one window: upgrading the existing NSX and importing it as a workload domain at the same time. Separate them. Get the source NSX onto a version VCF accepts, confirm it is healthy and backed up, and only then run the import. Two boring changes in two windows beat one heroic change that fails halfway and leaves you unsure which half broke.
References
- VMware Cloud Foundation Blog: Deployment Pathways for VCF 9
- Broadcom TechDocs: Deploy VCF Management Components on an NSX Overlay Segment
- Broadcom TechDocs: VMware Cloud Foundation 9.0 Release Notes
About The Author
