TL;DR · Key Takeaways
- Your first login is to the organization named system, as admin, with the password you set at deployment. This is the provider control plane.
- You get two paths: Quick Start, a guided wizard, and Manual Setup. Quick Start to learn, Manual for a production you will live with.
- Provider infrastructure is built in order: create a Region, define at least one IP Space, then create a Provider Gateway for north-south connectivity.
- A Region binds an NSX Manager, a vSphere Supervisor, and a storage class. The IP Space feeds the provider gateway routing.
- Creating an organization auto-provisions its quota and networking, including a transit gateway and VPC. The org name becomes its URL, so choose it deliberately.
Your first login to VCF Automation is not to your cloud. It is to a portal where the organization name you type is the literal word system, the user is admin, and the password is the one you set during deployment. What you do in the hour after that login decides the shape of every tenant that follows. Get the provider foundation right and tenants drop in cleanly. Rush it and you redraw networking later, with workloads already sitting on it.
First login: the system organization
The system organization is the provider control plane, the top of the model from Part 1. This is where infrastructure attaches before any tenant exists. Point a browser at your VCF Automation deployment, enter system as the organization, admin as the user, and the deployment password. From there you are offered two setup paths, and the choice matters more than it looks.
Quick Start or Manual Setup
Quick Start is a wizard that creates a fully functional organization with sensible defaults in a few clicks. Manual Setup walks the same ground but hands you every decision. They are not equivalent for a production build.
| Dimension | Quick Start | Manual Setup |
|---|---|---|
| Speed | Minutes, guided | Longer, deliberate |
| Control over networking | Defaults chosen for you | You define every value |
| Best for | Labs, learning, a first look | Production you will operate for years |
| Redo cost later | Higher if defaults do not fit | Lower, you chose on purpose |
My recommendation: run Quick Start once on a lab to see the shape of a working organization, then build production with Manual Setup so the IP ranges, region names, and gateway match your network design rather than a wizard’s defaults. The defaults are fine until they collide with your existing addressing, and by then there are workloads on them.
Building the provider infrastructure
Manual Setup builds the provider foundation in a fixed order, and the order is not arbitrary. Each step depends on the one before it. Get them in sequence and the gateway has what it needs; skip ahead and you backtrack.
Step 1: Create a Region
A Region binds VCF Automation to real infrastructure. You give it a name, select the NSX Manager instance that integrates with the paired vCenter, select the vSphere Supervisor, and select the storage class tenants will consume. This is where the abstract provider meets your actual cluster, so the values must match a real, healthy environment.
Step 2: Define IP Spaces
An IP Space is the set of addresses organizations draw from, and you need at least one per region. It is not decoration: the IP Space defines the routing the provider gateway uses. Size it for the tenants and workloads you expect, and carve it from address space your physical network already knows how to route, or north-south traffic will leave the gateway and go nowhere.
Step 3: Create the Provider Gateway
The provider gateway is the north-south door that tenant organizations use to reach the outside world. It consumes the IP Space you just defined and rides on your NSX edge. This is the step where a wrong IP Space or a mismatched uplink shows up as tenants that deploy fine but cannot talk to anything, so validate connectivity here before you hand out a single tenant.
# Provider manual-setup inputs (example values)
region:
name: region-a
nsx_manager: nsx-mgmt.lab.local # integrates with the paired vCenter
supervisor: wld-supervisor-01 # the vSphere Supervisor
storage_class: vsan-default
ip_space:
name: ipspace-region-a
cidr: 10.50.0.0/16 # routable in your physical network
provider_gateway:
name: pgw-region-a
uplink: nsx-t0-edge # north-south for tenant orgs
# Rule: at least one IP space per region, and the gateway routes from it.Creating the first organization
With the provider foundation in place, you create the first tenant organization. You give it a name, which becomes the unique identifier in its URL, so pick something stable and meaningful rather than a placeholder you will regret seeing in every link. You create its first user with a password of at least 15 characters spanning the required character categories, and you assign a role. VCF Automation then does real work for you: it automatically sets up the organization’s quota and networking, including a transit gateway and a VPC.
Worked example
A clean first build looks like this: one region, region-a, bound to your workload-domain NSX Manager and Supervisor; one IP Space carved from a routable /16, say 10.50.0.0/16, sized to grow; one provider gateway on the NSX T0 edge consuming that space. Then one organization named for its owner, with a 15-character first-user password and an admin role, after which the transit gateway and VPC appear on their own. That is a working provider plus a first tenant from a standing start, and every value in it was chosen, not defaulted.
Validating the provider before you onboard tenants
A green provider portal is not the same as a working provider. Before you hand a tenant to anyone, run a short validation pass, because every problem you catch here is a problem you do not catch in front of a user. The list is short and each item maps to one of the steps you just completed.
| Check | How | Pass criteria |
|---|---|---|
| Region binding | Open the region in the provider portal | NSX Manager, Supervisor and storage class all healthy |
| IP Space routing | Confirm the range is advertised in your network | The CIDR is reachable from outside the gateway |
| North-south egress | Deploy a throwaway VM in the first org, ping out | It reaches the outside and can be reached |
| Org auto-networking | Open the first org after creation | Transit gateway and VPC present and healthy |
| Identity | Log in to the org URL as the first user | Login succeeds with the 15-character password |
The one I never skip is the north-south test. Deploy a throwaway workload in the first org, give it an address from the IP space, and confirm it can reach out and be reached. If that works, your region, IP space, and provider gateway are wired correctly together, which is most of what can go wrong at this layer. If it does not, you have found a routing fault while the only thing on the platform is a test VM you are about to delete, which is exactly when you want to find it rather than during a tenant’s first real deployment.
What you have not done yet
It is worth being honest about scope, because a working provider and a first organization can feel like the finish line and it is not. You have built the provider control plane and stood up one tenant with networking and a quota. You have not yet defined projects inside that tenant, you have not authored a single VMware Cloud Template, and there is nothing in the catalog for a user to request. The tenant exists, but it cannot do anything self-service yet, and that gap is by design.
That is the right place to stop for this Part, because each of those is a topic of its own. Tenant organization design, projects with their roles and limits, cloud accounts and zones, the mappings and profiles, templates, and the catalog are the next several Parts, and every one of them assumes the provider foundation you just built and validated. The mistake I see is rushing to publish a catalog item on a provider whose networking was never tested, because then a broken catalog item and a broken gateway look identical and you debug both at the same time under pressure. Build the floor, prove it holds, then build the rooms on top of it.
What I’d Do
Treat the provider setup as the foundation it is, not a wizard to click past. My recommendation: run Quick Start once in a lab to learn the shape, then build production with Manual Setup so every IP range and name is yours. Follow the order, region then IP space then gateway, and validate north-south connectivity at the gateway before any tenant exists, because that is the cheapest moment to find a routing mistake. When you create the first organization, name it as if it is permanent, because it is, and let the platform hand you the transit gateway and VPC. Get this hour right and the rest of the series, projects, templates, catalog, is built on ground that holds.
Next we go a level down, into tenant organizations and how to scope them. For the tenancy concepts behind all of this, revisit Part 1 on the provider and tenant model. Did you start with Quick Start or go straight to Manual? Tell me how it went in the comments.
Previous: Part 5, licensing. Next: Part 7, tenant organizations (coming soon). Up: VCF Automation Guide (pillar).
References
- Quick Start Your VCF Automation Setup (Broadcom TechDocs)
- Create a VCF Automation Organization (Broadcom TechDocs)
- Configuring VCF Automation 9.0 (William Lam)
About The Author
