NSX Multi-Tenancy and VPC

Hi, Today I would like to talk about NSX Multi-tenancy and VPC.


Multi-tenancy is the ability to offer NSX networking and security services to multiple tenants completely isolated from each other. Every tenant will also have its own RBAC configuration and can be assigned quotas to limit the number of objects that can be created inside a tenant. Multi-Tenancy has been a long-awaited feature in NSX which enables not only service providers but also end customers to provide NSX services tailored and scoped down to a department/team level on the same NSX instance, previously that was only possible by deploying different NSX instances per tenant/department.

Multi-Tenancy in NSX is achieved by creating NSX projects, where every project represents a logical container of network and security resources (tenant) where every project can have its own set of users, assigned privileges, and quotas. Multi-Tenancy has different use cases such as offering networking as a Service, Firewall as a Service, and so on.

Multi-Tenancy was introduced in NSX UI starting from VMware NSX 4.1, and it uses a two-tier data model, the first tier is called /Infra tier which is referred to as Default space, Default space contains non-isolated objects and is accessible to Enterprise admin and other system-wide users who are not a member of projects. In short, the Default view contains NSX objects that do not belong to any project. The other data model is referred to as the Org model (branch) under which projects (tenants) provision their resources, which implies that every tenant (project) will also have a sub-Infra branch with only objects that are created and available to that project (tenant).

Project configurations are set up under /orgs/default/projects/<project-id>/infra

NSX Virtual Private Clouds (VPC)

Starting in NSX 4.1.1, a project can optionally contain one or more NSX Virtual Private Clouds (VPC).

A VPC represents a self-contained private network within an NSX project that application developers or DevOps engineers in your organization can use to host their applications and consume networking and security objects by using a self-service consumption model.

NSX VPCs can be created only in projects. They cannot be created in the default space.

VPC configurations are set up under the following path of the NSX Policy data model:


Tier-0 gateways and edge clusters are owned by the default space, and they can be allocated to projects under the org. You cannot create tier-0 gateways and edge clusters inside a project.

Each project can optionally have its own tier-1 gateways, which must be configured in the project. In other words, the tier-1 gateways must be owned by the project. A project cannot use the tier-1 gateways that are configured in the default space.

The first figure shows the default space and two projects under the org.

  • Multi-tenancy Policy data model shows the default space, org, and two projects under the org.The next figure shows the hierarchy of objects in both projects. Under the org, projects 1 and 2 have their own hierarchy of NSX networking and security objects that are created inside the project. Hierarchy of NSX objects in projects 1 and 2 under the org.

How we can create it?

When an Enterprise Admin logs into NSX Manager, the Default view is displayed, as shown in the following screen capture.


Click on Default

Click on the Manage

Click on the ADD PROJECT, I give a name to it.

I create 3 projects.

I click on the khoshraftar-Production, You can see this project has its own Menu, You can also create a VPC in your project.

In the future, I am going to create a VPC in another post.

Finish 🙂