| API Description | API Path |
|---|---|
List Transport NodesReturns information about all transport nodes along with underlying host or edge details. A transport node is a host or edge that contains hostswitches. A hostswitch can have virtual machines connected to them. Because each transport node has hostswitches, transport nodes can also have virtual tunnel endpoints, which means that they can be part of the overlay. |
GET /api/v1/transport-nodes
|
Create a Transport NodeTransport nodes are hypervisor hosts and NSX Edges that will participate in an NSX-T overlay. For a hypervisor host, this means that it hosts VMs that will communicate over NSX-T logical switches. For NSX Edges, this means that it will have logical router uplinks and downlinks. This API creates transport node for a host node (hypervisor) or edge node (router) in the transport network. When you run this command for a host, NSX Manager attempts to install the NSX kernel modules, which are packaged as VIB, RPM, or DEB files. For the installation to succeed, you must provide the host login credentials and the host thumbprint. To get the ESXi host thumbprint, SSH to the host and run the openssl x509 -in /etc/vmware/ssl/rui.crt -fingerprint -sha256 -noout command. To generate host key thumbprint using SHA-256 algorithm please follow the steps below. Log into the host, making sure that the connection is not vulnerable to a man in the middle attack. Check whether a public key already exists. Host public key is generally located at '/etc/ssh/ssh_host_rsa_key.pub'. If the key is not present then generate a new key by running the following command and follow the instructions. ssh-keygen -t rsa Now generate a SHA256 hash of the key using the following command. Please make sure to pass the appropriate file name if the public key is stored with a different file name other than the default 'id_rsa.pub'. awk '{print $2}' id_rsa.pub | base64 -d | sha256sum -b | sed 's/ .*$//' | xxd -r -p | base64 This api is deprecated as part of FN+TN unification. Please use Transport Node API to install NSX components on a node. Additional documentation on creating a transport node can be found in the NSX-T Installation Guide. In order for the transport node to forward packets, the host_switch_spec property must be specified. Host switches (called bridges in OVS on KVM hypervisors) are the individual switches within the host virtual switch. Virtual machines are connected to the host switches. When creating a transport node, you need to specify if the host switches are already manually preconfigured on the node, or if NSX should create and manage the host switches. You specify this choice by the type of host switches you pass in the host_switch_spec property of the TransportNode request payload. For a KVM host, you can preconfigure the host switch, or you can have NSX Manager perform the configuration. For an ESXi host or NSX Edge node, NSX Manager always configures the host switch. To preconfigure the host switches on a KVM host, pass an array of PreconfiguredHostSwitchSpec objects that describes those host switches. In the current NSX-T release, only one prefonfigured host switch can be specified. See the PreconfiguredHostSwitchSpec schema definition for documentation on the properties that must be provided. Preconfigured host switches are only supported on KVM hosts, not on ESXi hosts or NSX Edge nodes. To allow NSX to manage the host switch configuration on KVM hosts, ESXi hosts, or NSX Edge nodes, pass an array of StandardHostSwitchSpec objects in the host_switch_spec property, and NSX will automatically create host switches with the properties you provide. In the current NSX-T release, up to 16 host switches can be automatically managed. See the StandardHostSwitchSpec schema definition for documentation on the properties that must be provided. Note: Previous versions of NSX-T also used a property named transport_zone_endpoints at TransportNode level. This property is deprecated which creates some combinations of new client along with old client payloads. Examples [1] & [2] show old/existing client request and response by populating transport_zone_endpoints property at TransportNode level. Example [3] shows TransportNode creation request/response by populating transport_zone_endpoints property at StandardHostSwitch level and other new properties. The request should either provide node_deployement_info or node_id. If the host node (hypervisor) or edge node (router) is already added in system then it can be converted to transport node by providing node_id in request. If host node (hypervisor) or edge node (router) is not already present in system then information should be provided under node_deployment_info. |
POST /api/v1/transport-nodes
|
Get the module details of a transport node |
GET /api/v1/transport-nodes/<node-id>/modules
|
Invoke DELETE request on target transport node |
DELETE /api/v1/transport-nodes/<target-node-id>/<target-uri>
|
Invoke GET request on target transport node |
GET /api/v1/transport-nodes/<target-node-id>/<target-uri>
|
Invoke POST request on target transport node |
POST /api/v1/transport-nodes/<target-node-id>/<target-uri>
|
Invoke PUT request on target transport node |
PUT /api/v1/transport-nodes/<target-node-id>/<target-uri>
|
Delete a Transport NodeDeletes the specified transport node. Query param force can be used to force delete the host nodes. Force deletion of edge and public cloud gateway nodes is not supported. It also removes the specified node (host or edge) from system. If unprepare_host option is set to false, then host will be deleted without uninstalling the NSX components from the host. |
DELETE /api/v1/transport-nodes/<transport-node-id>
|
Get a Transport NodeReturns information about a specified transport node. |
GET /api/v1/transport-nodes/<transport-node-id>
|
Apply cluster level Transport Node Profile on overridden hostA host can be overridden to have different configuration than Transport Node Profile(TNP) on cluster. This action will restore such overridden host back to cluster level TNP. This API can be used in other case. When TNP is applied to a cluster, if any validation fails (e.g. VMs running on host) then existing transport node (TN) is not updated. In that case after the issue is resolved manually (e.g. VMs powered off), you can call this API to update TN as per cluster level TNP. |
POST /api/v1/transport-nodes/<transport-node-id>?action=restore_cluster_config
|
Refresh the node configuration for the Edge node.The API is applicable for Edge transport nodes. If you update the VM configuration and find a discrepancy in VM configuration at NSX Manager, then use this API to refresh configuration at NSX Manager. It refreshes the VM configuration from sources external to MP. Sources include vSphere Server and the edge node. After this action, the API GET api/v1/transport-nodes will show refreshed data. |
POST /api/v1/transport-nodes/<transport-node-id>?action=refresh_node_configuration&resource_type=EdgeNode
|
Restart the inventory sync for the node if it is paused currently.Restart the inventory sync for the node if it is currently internally paused. After this action the next inventory sync coming from the node is processed. |
POST /api/v1/transport-nodes/<transport-node-id>?action=restart_inventory_sync
|
Enable flow cache for an edge transport nodeEnable flow cache for edge transport node. Caution: This involves restart of the edge dataplane and hence may lead to network disruption. |
POST /api/v1/transport-nodes/<transport-node-id>?action=enable_flow_cache
|
Disable flow cache for an edge transport nodeDisable flow cache for edge transport node. Caution: This involves restart of the edge dataplane and hence may lead to network disruption. |
POST /api/v1/transport-nodes/<transport-node-id>?action=disable_flow_cache
|
Update a Transport NodeModifies the transport node information. The host_switch_name field must match the host_switch_name value specified in the transport zone (API: transport-zones). You must create the associated uplink profile (API: host-switch-profiles) before you can specify an uplink_name here. If the host is an ESX and has only one physical NIC being used by a vSphere standard switch, TransportNodeUpdateParameters should be used to migrate the management interface and the physical NIC into a logical switch that is in a transport zone this transport node will join or has already joined. If the migration is already done, TransportNodeUpdateParameters can also be used to migrate the management interface and the physical NIC back to a vSphere standard switch. In other cases, the TransportNodeUpdateParameters should NOT be used. When updating transport node you should follow pattern where you should fetch the existing transport node and then only modify the required properties keeping other properties as is. It also modifies attributes of node (host or edge). Note: Previous versions of NSX-T also used a property named transport_zone_endpoints at TransportNode level. This property is deprecated which creates some combinations of new client along with old client payloads. Examples [1] shows old/existing client request and response by populating transport_zone_endpoints property at TransportNode level. Example [2] shows TransportNode updating TransportNode from exmaple [1] request/response by adding a new StandardHostSwitch by populating transport_zone_endpoints at StandardHostSwitch level. TransportNode level transport_zone_endpoints will ONLY have TransportZoneEndpoints that were originally specified here during create/update operation and does not include TransportZoneEndpoints that were directly specified at StandardHostSwitch level. |
PUT /api/v1/transport-nodes/<transport-node-id>
|
Return the list of capabilities of transport nodeReturns information about capabilities of transport host node. Edge nodes do not have capabilities. |
GET /api/v1/transport-nodes/<transport-node-id>/capabilities
|
Get a Transport Node's StateReturns information about the current state of the transport node configuration and information about the associated hostswitch. |
GET /api/v1/transport-nodes/<transport-node-id>/state
|
Resync a Transport NodeResync the TransportNode configuration on a host. It is similar to updating the TransportNode with existing configuration, but force synce these configurations to the host (no backend optimizations). |
POST /api/v1/transport-nodes/<transportnode-id>?action=resync_host_config
|
Update transport node maintenance modePut transport node into maintenance mode or exit from maintenance mode. |
POST /api/v1/transport-nodes/<transportnode-id>
|
List transport nodes by realized stateReturns a list of transport node states that have realized state as provided as query parameter |
GET /api/v1/transport-nodes/state
|