NSX-T Data Center REST API

Associated URIs:

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