NSX-T Data Center REST API

Associated URIs:

API Description	API Path
Request one-time inventory summary. Request one-time inventory summary. The backup will be uploaded using the same server configuration as for an automatic backup.	POST /policy/api/v1/cluster?action=summarize_inventory_to_remote POST /api/v1/cluster?action=summarize_inventory_to_remote
Request one-time backup Request one-time backup. The backup will be uploaded using the same server configuration as for automatic backup.	POST /policy/api/v1/cluster?action=backup_to_remote POST /api/v1/cluster?action=backup_to_remote
Get ssh fingerprint of remote(backup) server Get SHA256 fingerprint of ECDSA key of remote server. The caller should independently verify that the key is trusted.	POST /policy/api/v1/cluster/backups?action=retrieve_ssh_fingerprint POST /api/v1/cluster/backups?action=retrieve_ssh_fingerprint
Get backup configuration Get a configuration of a file server and timers for automated backup. Fields that contain secrets (password, passphrase) are not returned.	GET /policy/api/v1/cluster/backups/config GET /api/v1/cluster/backups/config
Configure backup Configure file server and timers for automated backup. If secret fields are omitted (password, passphrase) then use the previously set value.	PUT /policy/api/v1/cluster/backups/config PUT /api/v1/cluster/backups/config
Get backup history Get history of previous backup operations	GET /policy/api/v1/cluster/backups/history GET /api/v1/cluster/backups/history
Get all backup related information for a site Get a configuration of a file server, timers for automated backup, latest backup status, backups list for a site. Fields that contain secrets (password, passphrase) are not returned.	GET /policy/api/v1/cluster/backups/overview GET /api/v1/cluster/backups/overview
Get backup status Get status of active backup operations	GET /policy/api/v1/cluster/backups/status GET /api/v1/cluster/backups/status
Initiate a restore operation Start the restore of an NSX cluster, from some previously backed-up configuration. This operation is only valid when a GET cluster/restore/status returns a status with value NOT_STARTED. Otherwise, a 409 response is returned.	POST /policy/api/v1/cluster/restore?action=start POST /api/v1/cluster/restore?action=start
Advance any suspended restore operation Advance any currently suspended restore operation. The operation might have been suspended because (1) the user had suspended it previously, or (2) the operation is waiting for user input, to be provided as a part of the POST request body. This operation is only valid when a GET cluster/restore/status returns a status with value SUSPENDED. Otherwise, a 409 response is returned.	POST /policy/api/v1/cluster/restore?action=advance POST /api/v1/cluster/restore?action=advance
Suspend any running restore operation Suspend any currently running restore operation. The restore operation is made up of a number of steps. When this call is issued, any currently running step is allowed to finish (successfully or with errors), and the next step (and therefore the entire restore operation) is suspended until a subsequent resume or cancel call is issued. This operation is only valid when a GET cluster/restore/status returns a status with value RUNNING. Otherwise, a 409 response is returned.	POST /policy/api/v1/cluster/restore?action=suspend POST /api/v1/cluster/restore?action=suspend
Cancel any running restore operation This operation is only valid when a restore is in suspended state. The UI user can cancel any restore operation when the restore is suspended either due to an error, or for a user input. The API user would need to monitor the progression of a restore by calling periodically "/api/v1/cluster/restore/status" API. The response object (ClusterRestoreStatus), contains a field "endpoints". The API user can cancel the restore process if 'cancel' action is shown in the endpoint field. This operation is only valid when a GET cluster/restore/status returns a status with value SUSPENDED.	POST /policy/api/v1/cluster/restore?action=cancel POST /api/v1/cluster/restore?action=cancel
Retry any failed restore operation Retry any currently in-progress, failed restore operation. Only the last step of the multi-step restore operation would have failed,and only that step is retried. This operation is only valid when a GET cluster/restore/status returns a status with value FAILED. Otherwise, a 409 response is returned.	POST /policy/api/v1/cluster/restore?action=retry POST /api/v1/cluster/restore?action=retry
Retry any failed restore operation Retry currently failed restore operation due to incorrect passphrase. User needs to call this api after passphrase is corrected in Backup config. This operation is only valid when a GET cluster/restore/status returns a status with value FAILED. Otherwise, a 409 response is returned. Calling this api without passphrase update will result in restore failure due to bad passphrase.	POST /policy/api/v1/cluster/restore/action/retry_with_updated_config POST /api/v1/cluster/restore/action/retry_with_updated_config
List timestamps of all available Cluster Backups. Returns timestamps for all backup files that are available on the SFTP server.	GET /policy/api/v1/cluster/restore/backuptimestamps GET /api/v1/cluster/restore/backuptimestamps
Get Restore configuration Get configuration information for the file server used to store backed-up files. Fields that contain secrets (password, passphrase) are not returned.	GET /policy/api/v1/cluster/restore/config (Deprecated) GET /api/v1/cluster/restore/config (Deprecated)
Deprecated. Configure Restore SFTP server credentials Configure file server where the backed-up files used for the Restore operation are available.	PUT /policy/api/v1/cluster/restore/config (Deprecated) PUT /api/v1/cluster/restore/config (Deprecated)
List resources for a given instruction, to be shown to/executed by users. For restore operations requiring user input e.g. performing an action, accepting/rejecting an action, etc. the information to be conveyed to users is provided in this call.	GET /policy/api/v1/cluster/restore/instruction-resources GET /api/v1/cluster/restore/instruction-resources
Query Restore Request Status Returns status information for the specified NSX cluster restore request.	GET /api/v1/cluster/restore/status
Set the migrate status key of ExtraConfigProfile of all Transport Nodes to IGNORE	PUT /policy/api/v1/infra/nvds-urt?action=ignore_migrate_status (Deprecated)
Clean up all nvds upgrade related configurations	PUT /policy/api/v1/infra/nvds-urt?action=cleanup (Deprecated)
Retrieve latest precheck ID of the N-VDS to VDS migration	GET /policy/api/v1/infra/nvds-urt/precheck (Deprecated)
Start precheck for N-VDS to VDS migration	PUT /policy/api/v1/infra/nvds-urt/precheck (Deprecated)
Retrieve latest precheck ID of the N-VDS to VDS migration for the cluster	GET /policy/api/v1/infra/nvds-urt/precheck-by-cluster/{cluster_id} (Deprecated)
Start precheck for N-VDS to VDS migration by cluster	PUT /policy/api/v1/infra/nvds-urt/precheck-by-cluster/{cluster_id} (Deprecated)
Start precheck for N-VDS to VDS migration by clusters	PUT /policy/api/v1/infra/nvds-urt/precheck-by-clusters (Deprecated)
Get summary of N-VDS to VDS migration	GET /policy/api/v1/infra/nvds-urt/status-summary-by-cluster/{precheck-id} (Deprecated)
Get summary of N-VDS to VDS migration	GET /policy/api/v1/infra/nvds-urt/status-summary/{precheck-id} (Deprecated)
Set VDS configuration and create it in vCenter	PUT /policy/api/v1/infra/nvds-urt/topology?action=apply (Deprecated)
Unset VDS configuration and remove it from vCenter	PUT /policy/api/v1/infra/nvds-urt/topology?action=revert (Deprecated)
Recommmended topology	GET /policy/api/v1/infra/nvds-urt/topology-by-cluster/{precheck-id} (Deprecated)
Set VDS configuration and create it in vCenter	PUT /policy/api/v1/infra/nvds-urt/topology-by-cluster/{precheck-id}?action=apply (Deprecated)
Recommmended topology	GET /policy/api/v1/infra/nvds-urt/topology/{precheck-id} (Deprecated)
Perform steps required to finalize the infra. Perform steps that are required to finalize the infra such as remove the temporary security groups, remove other objects created temporarily for the migration.	POST /api/v1/migration?action=finalize_infra
Delete the migration data file Delete the specified migration data file.	DELETE /api/v1/migration/data
Get Migration Data Info. Get information about the requested Migration Data file.	GET /api/v1/migration/data
Download migration data Download the output data file generated during migration.	GET /api/v1/migration/data/download
Upload migration data Upload the data file needed for migration. The call returns after upload is completed.	POST /api/v1/migration/data/upload
Get the list of discovered switches (DVS, VSS) Get the list of discovered switches (DVS, VSS) for the selected VC.	GET /api/v1/migration/discovered-switches
NSX-V feedback details Get feedback details of NSX-V to be migrated.	GET /api/v1/migration/feedback-requests
Accept default action for feedbacks Pick default resolution for all feedback items.	POST /api/v1/migration/feedback-response?action=accept-recommended
Migration feedback response Provide response for feedback queries needed for migration.	PUT /api/v1/migration/feedback-response
Feedback request summary Get feedback summary of NSX-V to be migrated.	GET /api/v1/migration/feedback-summary
NSX-V feedback details Get feedback details of NSX-V to be migrated, grouped by feedback type.	GET /api/v1/migration/grouped-feedback-requests
Get migration stats for logical constructs phase Get migration stats for logical constructs phase. This API can be polled for getting runtime progress of the migration from source to target.	GET /api/v1/migration/logical-constructs/stats
List migrated resources List migrated resources.This API is applicable for mp2Policy migration mode only.	GET /api/v1/migration/migrated-resources (Deprecated)
Get the list of migrated switches (DVS, VSS) Get the list of migrated switches (DVS, VSS) for the selected VC.	GET /api/v1/migration/migrated-switches
Return information of all migration unit groups Return information of all migration unit groups in the migration plan. If request parameter summary is set to true, then only count of migration units will be returned, migration units list will be empty. If request parameter component type is specified, then all migration unit groups for that component will be returned.	GET /api/v1/migration/migration-unit-groups
Create a group Create a group of migration units.	POST /api/v1/migration/migration-unit-groups
Get migration status for migration unit groups Get migration status for migration unit groups	GET /api/v1/migration/migration-unit-groups-status
Delete the migration unit group Delete the specified group. NOTE - A group can be deleted only if it is empty. If user tries to delete a group containing one or more migration units, the operation will fail and an error will be returned.	DELETE /api/v1/migration/migration-unit-groups/{group-id}
Return migration unit group information Returns information about a specific migration unit group in the migration plan. If request parameter summary is set to true, then only count of migration units will be returned, migration units list will be empty.	GET /api/v1/migration/migration-unit-groups/{group-id}
Add migration units to specified migration unit group Add migration units to specified migration unit group. The migration units will be added at the end of the migration unit list.	POST /api/v1/migration/migration-unit-groups/{group-id}?action=add_migration_units
Reorder migration unit group Reorder an migration unit group by placing it before/after the specified migration unit group.	POST /api/v1/migration/migration-unit-groups/{group-id}?action=reorder
Update the migration unit group Update the specified migration unit group. Removal of migration units from the group using this is not allowed. An error will be returned in that case.	PUT /api/v1/migration/migration-unit-groups/{group-id}
Reorder an migration unit within the migration unit group Reorder an migration unit within the migration unit group by placing it before/after the specified migration unit	POST /api/v1/migration/migration-unit-groups/{group-id}/migration-unit/{migration-unit-id}?action=reorder
Get migration status for group Get migration status for migration units in the specified group. User can specify whether to show only the migration units with errors.	GET /api/v1/migration/migration-unit-groups/{group-id}/status
Return aggregate information of all migration unit groups Return information of all migration unit groups in the migration plan. If request parameter summary is set to true, then only count of migration units will be returned, migration units list will be empty. If request parameter component type is specified, then all migration unit groups for that component will be returned.	GET /api/v1/migration/migration-unit-groups/aggregate-info
Get migration units Get migration units	GET /api/v1/migration/migration-units
Get migration units stats Get migration units stats	GET /api/v1/migration/migration-units-stats
Get a specific migration unit Get a specific migration unit	GET /api/v1/migration/migration-units/{migration-unit-id}
Get migration units aggregate-info Get migration units aggregate-info	GET /api/v1/migration/migration-units/aggregate-info
This api is used to get mp policy promotion history. The history contains details about date and time of different promotion operations like INITIATED, CANCELLED, SUCCESS. This api is used to get migration history.	GET /api/v1/migration/mp-policy-promotion/history (Deprecated)
This api is used to get mp policy promotion state. This api is used to get promotion state.	GET /api/v1/migration/mp-policy-promotion/state (Deprecated)
This will trigger the migration from mp to policy. This will trigger the migration from mp to policy	POST /api/v1/migration/mp-to-policy (Deprecated)
Cancel migration This will cancel the on-going promotion and system will be restored to original state as before promotion.	POST /api/v1/migration/mp-to-policy/cancel (Deprecated)
To get MP2Policy promotion feedback. To get MP2Policy promotion feedback. This gives all the validation errors or failures during PRECHECK / APPLY phase.	GET /api/v1/migration/mp-to-policy/feedback (Deprecated)
This api is used to get mapping of MP and Policy objects after Mp to Policy Migration. This api is used to get mapping of MP and Policy objects. resource_type is additional parameter which takes the resource_type enum and give mapping status for that type. Only one resource_type is supported per API call.	GET /api/v1/migration/mp-to-policy/migrated-resource-status (Deprecated)
To get MP2Policy promotion stats. To get MP2Policy promotion stats. This gives detailed information about promotion progess per resource type like what's the promotion status, how many resources has been promoted etc.	GET /api/v1/migration/mp-to-policy/stats (Deprecated)
Get list of nodes across all types Get list of nodes. If request parameter component type is specified, then all nodes for that component will be returned. If request parameter component version is specified, then all nodes at that version will be returned.	GET /api/v1/migration/nodes
Get summary of nodes Get summary of nodes, which includes node count for each type and component version.	GET /api/v1/migration/nodes-summary
Get vCenters Get vCenters registered with overlay adoption migration tool.	GET /api/v1/migration/overlay-adoption/vcenters
Provide vCenter details Provide vCenter details to overlay adoption migration tool. The vCenter should already be registered as a compute manager with NSX.	POST /api/v1/migration/overlay-adoption/vcenters
Add vCenter to scope of migration Add vCenter to scope of migration. Migration operations can be performed on vCenter only if it is added to scope of migration. At any given point of time, only one vCenter can be present in the migration scope list, which means migration operations can be performed only on one vCenter at a time. Invoking this API with a new valid vCenter ID will remove previous one from the migration scope and add the new one to migration scope. For a vCenter to be added to scope of migration, it has to satisfy following conditions. 1. vCenter should have been registered as a compute manager with NSX. 2. User should have provided vCenter username and password details via UI or API in the overlay adoption tool.	PUT /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/add_to_migration_scope
Get assessment units Get assessment units.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/assessment/assessment-units/search
Get assessment messages Get assessment messages.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/assessment/messages/search
Get VMs by DVPG and VnicIpSubnets. Get VMs by DVPG and VnicIpSubnets.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/inventory/dvpg/virtual-machines/search
Get DVPGs in vCenter Get DVPGs of vCenter from the config snapshot collected by overlay adoption migration tool. Since this lists DVPGs from a snapshot collected earlier, if some DVPGs got added or deleted later, those will not be reflected in the API response. Migration tool has to collect config again to get the latest vCenter inventory to reflect any changes that were done after last config collection.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/inventory/dvpgs/search
Get segment to DVPGs mapping Get information about DVPGs that the segment has been bridged to.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/inventory/segment-to-dvpgs-mapping/search
Get VMs by segment Get VMs by segment.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/inventory/segment/virtual-machines/search
Continue workflow Continue workflow.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflow/action/continue
Reset workflow Reset workflow.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflow/action/reset
Rollback workflow Rollback workflow.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflow/action/rollback
Start workflow. Start workflow.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflow/action/start
Get feedbacks Get feedbacks.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflow/feedbacks/search
Get workflow details Get workflow details.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflow/search
Get workflow spec Get workflow spec.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflow/spec/search
Get aggregate info for VMs that belong to VM group Get aggregate info list for VMs that belong to VM group	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflow/vm-group/vm-aggregate-info-list/search
Get DVPG aggregate info list Get DVPG aggregate info list.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflows/dvpg-aggregate-info-list/search
Get DVPG migration info Get DVPG migration info. Gives information about all workflows related to the DVPG migration.	GET /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflows/dvpg-migration-info
Get workflows for DVPG and segment pair Get workflows for DVPG and segment pair.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflows/dvpg-segment-pair/search
Get workflow specs for DVPG and segment pair Get workflow specs for DVPG and segment pair.	POST /api/v1/migration/overlay-adoption/vcenters/{vcenter-id}/workflows/specs/dvpg-segment-pair/search
Get vCenter workflow timestamp list Get vCenter workflow timestamp list.	GET /api/v1/migration/overlay-adoption/workflows/vc-workflow-timestamp-list
Mark completion of a migration cycle This API marks the completion of one execution of migration workflow. This API resets internal execution state and hence needs to be invoked before starting subsequent workflow run.	POST /api/v1/migration/plan?action=finish
Start migration Start the migration. Migration will start as per the migration plan.	POST /api/v1/migration/plan?action=start
Pause migration Pause the migration. Migration will be paused after migration of all the nodes currently in progress is completed either successfully or with failure. User can make changes in the migration plan when the migration is paused.	POST /api/v1/migration/plan?action=pause
Continue migration Continue the migration. Resumes the migration from the point where it was paused.	POST /api/v1/migration/plan?action=continue
Update migration-state of federation site This API updates the migration-state of host groups which are part of provided federation site/s.	POST /api/v1/migration/plan?action=update_site_migration_state
Abort migration Resets all migration steps done so far, so that migration can be restarted with new setup details.	POST /api/v1/migration/plan?action=abort
Reset migration plan to default plan Reset the migration plan to default plan. User has an option to change the default plan. But if after making changes, user wants to go back to the default plan, this is the way to do so.	POST /api/v1/migration/plan?action=reset
Rollbabck migration Roll back the migration. Changes applied to target NSX will be reverted. Use the migration status API to monitor progress of roll back.	POST /api/v1/migration/plan?action=rollback
Get migration plan settings for the component Get the migration plan settings for the component.	GET /api/v1/migration/plan/{component_type}/settings
Update migration plan settings for the component Update the migration plan settings for the component.	PUT /api/v1/migration/plan/{component_type}/settings
Get migration-state of all the federation sites. This API returns the migration-state of all the federation sites.	GET /api/v1/migration/plan/site-migration-state
NSX-V setup details Get setup details of NSX-V to be migrated.	GET /api/v1/migration/setup
Perform V2T migration steps on newly added Host Transport Node. This API is to support the add Host workflow on NSX-T once the V2T migration process has started. There are two high level cases. For each case, please refer to the detailed steps. Case - 1 : For migration mode - CONFIG_AND_EDGE_MIGRATION_WITH_BYOT, CONFIG_AND_EDGE_MIGRATION_WITH_BYOT_ON_FEDERATION 1. Verify that overall migration status is in SUCCESS state in migration co-ordinator. This means all migration stages are completed and we are at a point where we can move workloads using the pre-migrate, post-migrate API's. 2. Follow steps mentioned in product documentation to add a new host to cluster. 3. Invoke this API (Accept Host Transport Node) to perform the V2T migration steps on newly added host transport node. Once API is successful, make sure that newly added HOST can take worklods (Ex: Traffic checks, etc.,). For Case-1, this API should be invoked only when following conditions are met. - The overall migration status is in SUCCESS status. - All the migration stages are completed and we are at a point where we can move workloads. - The migration mode selected has to be among the ones designated for case-1 - The new host has been added to a cluster by following all the steps mentioned in product documentation. Case - 2 : For migration modes that perform HOST migration. 1. Verify that overall migration status is in PAUSED state in migration co-ordinator. 2. Follow steps mentioned in product documentation to add a new host to cluster. 3. Invoke the migration co-ordinator sync HOST groups API. This will result in migration co-ordinator updating its inventory and accouting for the newly added host transport node. At this point, the list host upgrade units API call to MC will also show the newly added host transport node. But do NOT resume the migration. Since this host transport node is added after the V2T migration has started, we need to perform migration steps on this host through this special API (Accept Host Transport Node) 4. Invoke this API (Accept Host Transport Node) to perform the V2T migration steps on newly added host transport node. Once the API is successful, we should be seeing that migration status has been marked as SUCCESS for the newly added host transport node. Very Importnant Note : Make sure that migration status is PAUSED in migration co-ordinator when performing steps 2 through 4. Also ensure that all the steps 2 through 4 pass without failures. For Case-2, this API should be invoked only when following conditions are met. - The overall migration status is in PAUSED status. - The migration mode selected has HOST component in it. - All the migration stages before HOST stage are completed. - The new host has been added to a cluster by following all the steps mentioned in product documentation.	POST /api/v1/migration/setup?action=migrate_newly_added_host_transport_node
Add NSX-V to NSX-T site mapping Add NSX-V to NSX-T site mapping.	PUT /api/v1/migration/setup?action=addV2tSiteMapping
Add ALB endpoint details for non cross VC migration modes. Add ALB endpoint details for non cross VC migration modes.	PUT /api/v1/migration/setup?action=addAlbInfo
NSX-V setup details Provide setup details of NSX-V to be migrated.	PUT /api/v1/migration/setup
Set the NSX-V ESG to NSX-T Router mapping option. Set the NSX-V ESG to NSX-T Router mapping option.	PUT /api/v1/migration/setup?action=setEsgToRouterMappingOption
Get migration status summary Get migration status summary	GET /api/v1/migration/status-summary
Get migration summary Get migration summary	GET /api/v1/migration/summary
Get the switch set as current scope for migration The user is returned the switch (DVS/VSS) set as current scope of migration.	GET /api/v1/migration/switch
Set the switch as current scope for migration The user specifies a DVS / VSS as the current scope of migration.	PUT /api/v1/migration/switch
Perform steps required before migrating a VM group. For each VM group, the following three high level steps are performed in sequence. 1. Call pre VM group migrate API. 2. Migrate (by vmotion,in place, etc.,) VMs in the VM group. This step will be done by user independent of MC. 3. Call post VM group migrate API with the same VM group id used in the pre VM group migrate API. This API specifically deals with pre VM group migrate API. When pre VM group migrate API is invoked for a VM group id, MC performs following actions. - Checks segmentation realization state. - Creates segment ports. - Creates temporary security groups.	POST /api/v1/migration/vmgroup?action=pre_migrate
Perform steps required after migrating a VM group. For each VM group, the following three high level steps are performed in sequence. 1. Call pre VM group migrate API. 2. Migrate (by vmotion,in place, etc.,) VMs in the VM group. This step will be done by user independent of MC. 3. Call post VM group migrate API with the same VM group id used in the pre VM group migrate API. This API specifically deals with post VM group migrate API. When post VM group migrate API is invoked for a VM group id, MC performs following actions. - Add security tags on the VMs migrated. For the VMs mentioned in the failed VM instance uuids, this operation is skipped.	POST /api/v1/migration/vmgroup?action=post_migrate
Retreives the VM Group Execution Details The result includes a "logical_switch_id_to_vm_instance_id_and_vnics_map" list and an optional "failedVmInstanceIds" list which includes the uuids of VMs that are not found in the source VC. Construct a map of vmInstanceUuid to (vnic, ls_id) from the "logical_switch_id_to_vm_instance_id_and_vnics_map", then use the map to populate the relocate spec of each VM and migrate the VM as below: The VM object can be found in source VC by the vmInstanceUuid using VC API serviceinstance.content.searchIndex.FindByUuid(uuid=vmInstanceUuid, vmSearch=True, instanceUuid=True) For each VM vNIC, if the device key "vnic" is not found in the map of vmInstanceUuid to (vnic, ls_id), then skip the vNIC. Otherwise form a VIF-id for the vNIC by vmInstanceUuid + ':' + str(vnic), e.g. "52630e5d-ce6f-fac0-424c-4aa4bdf6bd56:4001", and use it to setup the vNIC's network backing. For VDS6.x migration, opaque-network backing in NVDS will be used; setup the vNIC device as below: - vdevice.backing = vim.vm.device.VirtualEthernetCard.OpaqueNetworkBackingInfo() - vdevice.backing.opaqueNetworkId = ls_id - vdevice.backing.opaqueNetworkType = 'nsx.LogicalSwitch' - vdevice.externalId = VIF-id For VDS 7.0 and later versions, "nsx" LogicalSwitch backing in VDS will be used. Go through all VDS DVPGs in the target VC to find each DVPG whose config.backingType is "nsx" and config.logicalSwitchUuid is not blank, build a map of dvpg.config.logicalSwitchUuid to [dvpg.key, dvpg.config.distributedVirtualSwitch.uuid] once. For each vNIC device, get the dvpg value from the map by the ls_id and then set it up as below: - vdsPgConn = vim.dvs.PortConnection() - vdsPgConn.portgroupKey = dvpg.key - vdsPgConn.switchUuid = dvpg.config.distributedVirtualSwitch.uuid - vdevice.backing = vim.vm.device.VirtualEthernetCard.DistributedVirtualPortBackingInfo() - vdevice.backing.port = vdsPgConn - vdevice.externalId = VIF-id	GET /api/v1/migration/vmgroup/actions/get_vm_group_execution_details
List all non-migrated NSX Manager ids List all non-migrated NSX Manager ids.	GET /api/v1/mppolicy/migration/object-ids
Get upgrade task status Get upgrade task status for the given task of the given bundle. Both bundle_name and task_id must be provided, otherwise you will receive a 404 NOT FOUND response. This api is deprecated. Please use API GET /node/upgrade/status-summary to get upgrade status when upgrade is in progress.	GET /api/v1/cluster/{cluster-node-id}/node/upgrade (Deprecated) GET /api/v1/node/upgrade (Deprecated)
Execute upgrade task Execute upgrade task.	POST /api/v1/cluster/{cluster-node-id}/node/upgrade/performtask POST /api/v1/node/upgrade/performtask
Get upgrade progress status Get progress status of last upgrade step, if upgrade bundle is present.	GET /api/v1/cluster/{cluster-node-id}/node/upgrade/progress-status GET /api/v1/node/upgrade/progress-status
Get upgrade status summary Get status summary of node upgrade, if upgrade bundle is present.	GET /api/v1/cluster/{cluster-node-id}/node/upgrade/status-summary GET /api/v1/node/upgrade/status-summary
Triggers Repository driven Uc Upgrade Triggers repository driven uc upgrade on the node. This API expects that repository is synced across nodes before starting upgrade.	POST /api/v1/cluster/{cluster-node-id}/node/upgrade/uc POST /api/v1/node/upgrade/uc
Upgrade the upgrade coordinator. Upgrade the upgrade coordinator module itself. This call is invoked after user uploads an upgrade bundle. Once this call is invoked, upgrade coordinator stops and gets restarted and target version upgrade coordinator module comes up after restart.	POST /api/v1/upgrade?action=upgrade_uc
Abort pre-upgrade checks Aborts execution of pre-upgrade checks if already in progress. Halts the execution of checks awaiting execution at this point and makes best-effort attempts to stop checks already in execution. Returns without action if execution of pre-upgrade checks is not in progress.	POST /api/v1/upgrade?action=abort_pre_upgrade_checks
Execute pre-upgrade checks Run pre-defined checks to identify potential issues which can be encountered during an upgrade or can cause an upgrade to fail. The results of the checks are added to the respective upgrade units aggregate-info. The progress and status of operation is part of upgrade status summary of individual components. Returns HTTP status 500 with error code 30953 if execution of pre-upgrade checks is already in progress.	POST /api/v1/upgrade?action=execute_pre_upgrade_checks
Execute post-upgrade checks Run pre-defined checks to identify issues after upgrade of a component. The results of the checks are added to the respective upgrade units aggregate-info. The progress and status of post-upgrade checks is part of aggregate-info of individual upgrade unit groups. Returns HTTP status 500 with error code 30953 if execution of post-upgrade checks is already in progress.	POST /api/v1/upgrade/{component-type}?action=execute_post_upgrade_checks
Lists the supported releases , available on VMware Download site to upgrade current system. The method fetches the available releases from VMware download site to Upgrade from this current system version to any of the available releases.	GET /api/v1/upgrade/available-releases
Upload upgrade bundle Upload the upgrade bundle. The call returns after upload is initiated. User needs to check upload status periodically by retrieving upgrade bundle upload status to find out if the upload is completed. This API is deprecated, please use /upgrade/bundles?action=upload API to upload the upgrade bundle.	POST /api/v1/upgrade/bundle?action=upload (Deprecated)
Upload upgrade bundle Upload the upgrade bundle. This call returns after upload is completed. You can check bundle processing status periodically by retrieving upgrade bundle upload status to find out if the upload and processing is completed.	POST /api/v1/upgrade/bundles?action=upload
Fetch upgrade bundle from given url Fetches the upgrade bundle from url. The call returns after fetch is initiated. Check status by periodically retrieving upgrade bundle upload status using GET /upgrade/bundles/<bundle-id>/upload-status. The upload is complete when the status is SUCCESS.	POST /api/v1/upgrade/bundles
Get uploaded upgrade bundle information Get uploaded upgrade bundle information	GET /api/v1/upgrade/bundles/{bundle-id}
Cancel upgrade bundle upload Cancel upload of upgrade bundle. This API works only when bundle upload is in-progress and will not work during post-processing of upgrade bundle. If bundle upload is in-progress, then the API call returns http OK response after cancelling the upload and deleting partially uploaded bundle.	POST /api/v1/upgrade/bundles/{bundle-id}?action=cancel_upload
Get uploaded upgrade bundle status Get uploaded upgrade bundle status	GET /api/v1/upgrade/bundles/{bundle-id}/status
Get uploaded upgrade bundle upload status Get uploaded upgrade bundle upload status	GET /api/v1/upgrade/bundles/{bundle-id}/upload-status
Accept end user license agreement Accept end user license agreement	POST /api/v1/upgrade/eula/accept
Return the acceptance status of end user license agreement Return the acceptance status of end user license agreement	GET /api/v1/upgrade/eula/acceptance
Return the content of end user license agreement Return the content of end user license agreement in the specified format. By default, it's pure string without line break	GET /api/v1/upgrade/eula/content
Return aggregate information of upgrade unit groups filtered using given query. Return information of upgrade unit groups filtered by given query in the upgrade plan.	POST /api/v1/upgrade/filter/upgrade-unit-groups
Return aggregate information of upgrade-units filtered using given query. Return information of upgrade-units filtered by given query in the upgrade plan.	POST /api/v1/upgrade/filter/upgrade-units
Get upgrade unit groups based on the filter Get all the upgrade unit groups based in the filter applied. The filter can be on component type, group name, id,enabled, status, unit name, unit IP.	GET /api/v1/upgrade/filterGroups
Get upgrade unit based on the filter Get all the upgrade unit groups based in the filter applied. The filter can be on component type, group name, id,enabled, status, unit name, unit IP, status, Hypervisor.	GET /api/v1/upgrade/filterUnits
Get functional state of the upgrade coordinator Get the functional state of the upgrade coordinator.	GET /api/v1/upgrade/functional-state
Get upgrade history Get upgrade history	GET /api/v1/upgrade/history
Get list of nodes across all types Get list of nodes. If request parameter component type is specified, then all nodes for that component will be returned. If request parameter component version is specified, then all nodes at that version will be returned.	GET /api/v1/upgrade/nodes
Get summary of nodes Get summary of nodes, which includes node count for each type and component version.	GET /api/v1/upgrade/nodes-summary
Upgrade selected units Upgrades, Resumes the upgrade of a selected set of units.	POST /api/v1/upgrade/plan?action=upgrade_selected_units
Stage the upgrade bits This will stage the upgrade bits so that upgrade can be driven from outside NSX upgrade-coordinator. If component type is not provided as a request parameter then upgrade staging will be performed on all the components.	POST /api/v1/upgrade/plan?action=stage-upgrade
Start upgrade Start the upgrade. Upgrade will start as per the upgrade plan.	POST /api/v1/upgrade/plan?action=start
Pause upgrade Pause the upgrade. Upgrade will be paused after upgrade of all the nodes currently in progress is completed either successfully or with failure. User can make changes in the upgrade plan when the upgrade is paused.	POST /api/v1/upgrade/plan?action=pause
Execute the upgrade Depending on current upgrade state, start or continue the upgrade.	POST /api/v1/upgrade/plan?action=upgrade
Reset upgrade plan to default plan Reset the upgrade plan to default plan. User has an option to change the default plan. But if after making changes, user wants to go back to the default plan, this is the way to do so.	POST /api/v1/upgrade/plan?action=reset
Continue upgrade Continue the upgrade. Resumes the upgrade from the point where it was paused.	POST /api/v1/upgrade/plan?action=continue
Get upgrade plan settings for the component Get the upgrade plan settings for the component.	GET /api/v1/upgrade/plan/{component_type}/settings
Update upgrade plan settings for the component Update the upgrade plan settings for the component.	PUT /api/v1/upgrade/plan/{component_type}/settings
Returns pre-upgrade checks in csv format Returns pre-upgrade checks in csv format	GET /api/v1/upgrade/pre-upgrade-checks?format=csv
Acknowledge the pre upgrade check. Some pre-checks can be marked as ACKNOWLEDGE required. Acknowledge status will be saved across pre-upgrade check runs.	POST /api/v1/upgrade/pre-upgrade-checks/{pre-upgrade-check-id}?action=acknowledge
Auto resolve the pre upgrade check. Run auto resolve for a pre upgrade check to try and resolve the issue encountered.	POST /api/v1/upgrade/pre-upgrade-checks/{pre-upgrade-check-id}?action=resolve
Get Pre-upgrade Check Failures Get failures resulting from the last execution of pre-upgrade checks. If the execution of checks is in progress, the response has the list of failures observed so far.	GET /api/v1/upgrade/pre-upgrade-checks/failures
Execute checks before entering host into maintenance mode This API will accept the host identification information(vCenter instance uuid and host moref id). Will execute the host and edge pre-checks that ensure host is ok to enter maintenance mode. The progress and status of upgrade unit returns status OK, if check has passed. Otherwise will return the NOT_OK. if status returns WAIT, In that case system expects client to wait and poll the API after every 1 minute till checks reach terminal state OK or NOT_OK after 8 minutes.	POST /api/v1/upgrade/pre-upgrade-checks/host/planned-maintenance
Get Pre-upgrade Check Success Get success resulting from the last execution of pre-upgrade checks. If the execution of checks is in progress, the response has the list of successes observed so far.	GET /api/v1/upgrade/pre-upgrade-checks/success
Get upgrade status summary Get upgrade status summary	GET /api/v1/upgrade/status-summary
Get upgrade summary Get upgrade summary	GET /api/v1/upgrade/summary
Get Uc Bundle metadata for last uploaded bundle. Returns the Uc bundle metadata. This information belong the last bundle upload attempt.	GET /api/v1/upgrade/uc-bundle-metadata
Get Uc Upgrade metadata. Returns the Uc upgrade metadata. This information belong the last uc upgrade attempt.	GET /api/v1/upgrade/uc-upgrade-metadata
Get upgrade-coordinator upgrade status Get upgrade-coordinator upgrade status	GET /api/v1/upgrade/uc-upgrade-status
Get preferences for rendering the UI. Get hints for rendering the UI for the product. This hints are only for UI and are product specific. The keys are contract between UI and backend. They may not be same different products using the upgrade-coordinator core services. The example specified here is for NSX product.	GET /api/v1/upgrade/ui/preferences
Returns information about upgrade checks Returns information of pre-upgrade and post-upgrade checks. If request parameter component type is specified, then returns information about all pre-upgrade and post-upgrade for the component. Otherwise returns information of checks across all component types.	GET /api/v1/upgrade/upgrade-checks-info
Return information of all upgrade unit groups Return information of all upgrade unit groups in the upgrade plan. If request parameter summary is set to true, then only count of upgrade units will be returned, upgrade units list will be empty. If request parameter component type is specified, then all upgrade unit groups for that component will be returned.	GET /api/v1/upgrade/upgrade-unit-groups
Create a group Create a group of upgrade units.	POST /api/v1/upgrade/upgrade-unit-groups
Get upgrade status for upgrade unit groups Get upgrade status for upgrade unit groups	GET /api/v1/upgrade/upgrade-unit-groups-status
Delete the upgrade unit group Delete the specified group. NOTE - A group can be deleted only if it is empty. If user tries to delete a group containing one or more upgrade units, the operation will fail and an error will be returned.	DELETE /api/v1/upgrade/upgrade-unit-groups/{group-id}
Return upgrade unit group information Returns information about a specific upgrade unit group in the upgrade plan. If request parameter summary is set to true, then only count of upgrade units will be returned, upgrade units list will be empty.	GET /api/v1/upgrade/upgrade-unit-groups/{group-id}
Add upgrade units to specified upgrade unit group Add upgrade units to specified upgrade unit group. The upgrade units will be added at the end of the upgrade unit list.	POST /api/v1/upgrade/upgrade-unit-groups/{group-id}?action=add_upgrade_units
Reorder upgrade unit group Reorder an upgrade unit group by placing it before/after the specified upgrade unit group.	POST /api/v1/upgrade/upgrade-unit-groups/{group-id}?action=reorder
Update the upgrade unit group Update the specified upgrade unit group. Removal of upgrade units from the group using this is not allowed. An error will be returned in that case.	PUT /api/v1/upgrade/upgrade-unit-groups/{group-id}
Get upgrade status for group Get upgrade status for upgrade units in the specified group. User can specify whether to show only the upgrade units with errors.	GET /api/v1/upgrade/upgrade-unit-groups/{group-id}/status
Reorder an upgrade unit within the upgrade unit group Reorder an upgrade unit within the upgrade unit group by placing it before/after the specified upgrade unit	POST /api/v1/upgrade/upgrade-unit-groups/{group-id}/upgrade-unit/{upgrade-unit-id}?action=reorder
Return aggregate information of all upgrade unit groups Return information of all upgrade unit groups in the upgrade plan. If request parameter summary is set to true, then only count of upgrade units will be returned, upgrade units list will be empty. If request parameter component type is specified, then all upgrade unit groups for that component will be returned.	GET /api/v1/upgrade/upgrade-unit-groups/aggregate-info
Get upgrade units Get upgrade units	GET /api/v1/upgrade/upgrade-units
Get upgrade units stats Get upgrade units stats	GET /api/v1/upgrade/upgrade-units-stats
Get a specific upgrade unit Get a specific upgrade unit	GET /api/v1/upgrade/upgrade-units/{upgrade-unit-id}
Get upgrade units aggregate-info Get upgrade units aggregate-info	GET /api/v1/upgrade/upgrade-units/aggregate-info
Get the version whitelist Get whitelist of versions for different components	GET /policy/api/v1/upgrade/version-whitelist GET /api/v1/upgrade/version-whitelist
Get the version whitelist for the specified component Get whitelist of versions for a component. Component can include HOST, EDGE, CCP, MP	GET /policy/api/v1/upgrade/version-whitelist/{component_type} GET /api/v1/upgrade/version-whitelist/{component_type}
Update the version whitelist for the specified component type Update the version whitelist for the specified component type (HOST, EDGE, CCP, MP).	PUT /policy/api/v1/upgrade/version-whitelist/{component_type} PUT /api/v1/upgrade/version-whitelist/{component_type}