NSX-T Data Center REST API

Associated URIs:

API Description	API Path
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