The vCloud Director API for NSX acts as a proxy, allowing vCloud API clients to send requests to the NSX API. Use this document as an extension to the official NSX vSphere API Guide (for NSX version 6.2 or later).
This guide outlines the subset of NSX API requests that vCloud Director supports and explains the key differences in how you must use them through the vCloud Director proxy interface.
Connecting to the NSX API
The vCloud Director API for NSX supports a subset of the operations and objects defined in the NSX vSphere API Guide for versions 6.2 and 6.3. You can use the queries and examples from the NSX guide with some modifications and additional restrictions detailed in this document.
Multi-Tenant Support
While the standard NSX API manages tasks across a global vCenter datacenter, the vCloud Director NSX Proxy API is designed for operations within a specific tenant organization.
A key difference is how objects are identified:
-
The standard NSX API uses internal identifiers (like
edge-1). -
The vCloud Director API for NSX uses a unique UUID (as defined by RFC 4122) that vCloud Director assigns to the object, such as an Edge Gateway.
This UUID ensures that access is restricted to members of the organization that owns the object, governed by their assigned roles and rights. The proxy API uses this UUID to discover the edge, identify its managing NSX Manager, and retrieve the internal NSX ID needed for subsequent operations.
Similarly, operations on other NSX objects (like certificates or security groups) typically require vCloud Director organization UUIDs to enforce tenant isolation.
Note: vCloud Director system administrators retain the ability to view and update all edges in the system.
Security
All HTTP communication between the client and the vCloud API server is secured with SSL. Additionally, clients must first complete a login request to obtain an authorization token, which must be included in every subsequent API call.
Request Headers
Include the following HTTP headers in your requests:
|
|
All requests must include the HTTP Accept header, which specifies the vCloud Director API for the version of NSX that the client is using. |
|
Accept-Encoding |
By default, the system returns the response content as uncompressed XML. Compressing the response can improve performance, especially if the response is large and network bandwidth is an issue. (Requests cannot be compressed.) To request a response that is returned as compressed XML, include the following header: Accept-Encoding: gzip |
|
Accept-Language |
Message strings in ErrorType responses are localised. Use the Accept-Language request header to specify the required language in responses. To request a response with message strings localised to French, use the following header: |
|
Authorization |
All requests to create a vCloud API session must include the header of the authorisation form required by your organisation's identity provider. See the vCloud API Programmer's Guide for Service Providers. |
|
Content-Type |
|
|
x-vcloud-authorization |
This header, which is returned with the session response after a successful login, must be included in all subsequent requests from clients authenticating to the Integrated Identity Provider or SAML Identity Provider. See the vCloud API Programmer's Guide for Service Providers. |
|
X-VMWARE-VCLOUD-CLIENT-REQUEST-ID |
|
Supported NSX Services
The vCloud Director API for NSX enables you to manage the following services for an NSX Edge Gateway, which provides network security and gateway services for your isolated virtual networks.
Requesting or upgrading the Edge Gateway
Edge interfaces, Logging, Statistics and Remote Access Properties/
NSX Distributed Firewall Services
The distributed NSX firewall provides micro-segmentation by applying firewall functionality directly to the vNIC of a virtual machine. This allows for the inspection of East-West traffic at high processing speeds.
- https://code.vmware.com/doc/preview?id=5705#/doc/GUID-442E3FDF-47AC-44F2-906B-B37666795970.html
Have you tried Cloud4U services? Not yet?
