NSX multi-tenancy supports sharing of certain resources (objects) with specific projects or with NSX VPCs inside the projects of the organization.
Overview of Resource Share
An Enterprise Admin might want to share resources (objects) with projects so that they are available for consumption inside those projects. Resource sharing avoids the need for recreating the objects again in projects that require them, and thereby saves effort.
Resource sharing is done by creating resource shares. Each resource share is identified by a unique name. In a resource share, you can add the members (objects) that you want to share, and then choose one or more projects with whom you want to share with.
Project users can consume the shared resources in their projects to configure groups, firewall rules, and so on, to meet their networking and security requirements.
When you share a resource by creating a resource share, the child resources of that shared resource are not shared with the target project.
In NSX 4.1, you can share resources only from the default space to projects within the organization.
- Share resources from the default space to projects or NSX VPCs.
- Share resources from a project to NSX VPCs within the same project.
Sharing of resources from one project to other projects within the organization is currently not supported.
Shared resources are available in a read-only mode to the projects or NSX VPCs with which they are shared. In other words, shared resources cannot be modified by users in those projects. When you share resources with a project, the NSX VPCs in that project do not get access to the shared resources automatically. If required, you can share resources with all the NSX VPCs or specific NSX VPCs within a project.
- Groups
- Services
- Context Profiles
- Segments
- DHCP Profiles
- DAD Profiles
- ND Profiles
- DNS Zones (In NSX 4.1.1 or later)
- IDS Profiles (In NSX 4.1.1 or later)
A subset of NSX features are currently supported for consumption in NSX VPCs. If you share resources from the default space with NSX VPCs, but the resources are not supported for consumption in the VPCs, then these resources get propagated to the NSX VPCs. However, VPC users cannot consume those shared resources.
For example, assume that an Enterprise Admin has shared an overlay segment from the default space with a project and all the NSX VPCs within that project. The system propagates the overlay segment to the project and all its NSX VPCs. However, the segment can be consumed only in the project, but not in the NSX VPCs because overlay segment is not supported in NSX VPCs.
- Enterprise Admin
- Network Admin
- Security Admin
- Project Admin
- Network Admin
- Security Admin
Overview of Default Shares of Project
When you add a new project in the organization, no user-created resources exist in that project. A new project has access to only the system-defined NSX resources that are shared by default through the default share. In other words, the default share is created automatically in the default space when NSX is deployed. The resources in the default share are available to all the projects and NSX VPCs in the organization. You cannot edit the default share in the UI.
The default share is created by the system for internal use. The members of this share are system-defined resources, such as, Services, BFD Profiles, App IDs, and many more.
- Ensure that you have selected the Default view from the Project drop-down menu.
- Navigate to .
- (In NSX 4.1.1 or later): Click the Default Shares of Projects check box at the bottom of the Resource Sharing page.
In NSX 4.1, the system-created default shares are visible directly on the page. In other words, the Default Shares of Projects check box is not available on the Resource Sharing page.
- Next to Default Share, click the count in the Members column.
For example:
Observe that in addition to the default share, which is available to all the projects and NSX VPCs in the organization, the system creates a default share automatically for each project in the organization. This project-specific default share is created for internal use of the system. The naming convention of the project-specific default share is:
default-Project-name- Tier-0 Gateways (if set during project creation)
- Edge Clusters (if set during project creation)
- Site (if edge cluster is set during project creation)
- Site Enforcement Point (if edge cluster is set during project creation)
- External IPv4 address blocks allocated to the project (In NSX 4.1.1 or later)
Tier-0/VRF gateways and edge clusters are managed from the default space and cannot be edited in the project.
The following information applies to NSX 4.1.1 or later:
If NSX VPCs are added in the project, the system creates a default share automatically for each NSX VPC in the project. This default share contains the private IPv4 address blocks that are allocated to the NSX VPC. This VPC default share is created for internal use of the system.
The naming convention of the VPC default share in the project is:
_Project-name-VPC-name- Switch to the project view where the NSX VPC is added.
- Navigate to .
- Click the Default Shares of Projects check box at the bottom of the Resource Sharing page.
For example:
Use Case for Sharing Segments with Projects
When a segment is shared with a project, it does not mean that the VMs, ports, and gateway interfaces on this segment are exposed to the project. In fact, the project does not have visibility into the segment ports, interfaces, and workload VMs of the shared segment. Therefore, project users cannot configure distributed firewall policies on the workload VMs that are connected to the shared segment.
Sharing a segment with a project allows a project user to connect the segment to the service interface of a tier-1 gateway in that project.
- Assume that in the default space, there is an isolated segment named "Operations-Segment" and a tier-0 gateway named "T-0-Operations".
- On this tier-0 gateway, add a service interface and connect this interface to the "Operations-Segment".
- The Enterprise Admin adds this segment to a resource share and shares it with project-1.
- Now, switch to project-1 in NSX Manager, navigate to the Segments page, and click the Shared Objects check box at the bottom of the page.
- Observe the properties of the shared "Operations-Segment". The Ports/Interfaces column shows value as Not Available. In other words, the service interface is not exposed to project-1.
Use Case for Sharing Groups, Services, Context Profiles with Projects
Typically, project users might want to consume NSX objects such as Groups, Services, and Context Profiles that exist in the default space of the system to create firewall rules under their projects. Resource sharing avoids the need for project users to recreate these objects. The shared objects become available to the projects in a read only mode, and they cannot be edited inside projects.