Migrate from ONTAP tools for VMware vSphere 9.x to 10.2
When migrating storage data, storage backends are onboarded manually using REST APIs. When migrating VASA provider data, data is exported from existing Derby database and imported into the MongoDB database.
It is recommended to migrate ONTAP tools for VMware vSphere 9.x setup only if the setup is servicing the VASA provider feature alone. |
After migrating from ONTAP tools for VMware vSphere 9.x to 10.2, vVols datastores with NVMe/FC protocol do not work because ONTAP tools 10.2 only supports NVMe-oF with VMFS datastores. |
About this task
Migration is supported from ONTAP tools for VMware vSphere 9.10D2, 9.11D4, 9.12D1, and 9.13D2 releases to 10.2 release.
If you are using ONTAP tools for VMware vSphere 9.13P1 version, you should upgrade to 9.13D2 before the migration to 10.2 version. |
As an existing user, you need to take the OVA backup from your current release before upgrading to the patch releases. |
Common migration steps
-
Deploy OVA for ONTAP tools for VMware vSphere 10.2 release.
-
Add the vCenter Server instance that you want to migrate to ONTAP tools for VMware vSphere 10.2 release. See Add vCenter Server instances
-
Onboard storage backend locally from the ONTAP tools for VMware vSphere plug-in vCenter server APIs. Add storage as a locally scoped storage for migration.
-
The NFS and VMFS datastores migrated from ONTAP tools for VMware vSphere 9.xx is visible in ONTAP tools for VMware vSphere 10.2 only after the datastore discovery job is triggered, which might take up to 30 minutes to trigger. Verify if the datastores are visible in the Overview page of the ONTAP tools for VMware vSphere Plugin UI page.
SRA migration steps
Before you begin
Before migrating, ensure that one of the sites is in a protected state and the other is in recovery state.
Do not migrate if the failover just completed and re-protect is pending. Complete the re-protect and then perform the migration. Same applies to testing the recovery plan. Once the testing of recovery plan is complete, cleanup the test recovery and then start the migration. |
-
Perform the following steps to delete ONTAP tools for VMware vSphere 9.xx release SRA adapter in VMware Live Site Recovery UI:
-
Go to VMware Live Site Recovery Configuration management page
-
Go to Storage Replication Adapter section
-
Click on Kebab menu, and click on Reset configuration
-
Click on Kebab menu and select Delete
Perform these steps on both protection and recovery sites.
-
-
Install ONTAP tools for VMware vSphere 10.2 SRA adapter on both protection and recovery sites using the steps in Configure SRA on VMware Live Site Recovery appliance
-
In the VMware Live Site Recovery UI page, perform Discover Arrays and Discover Devices operations and verify that the devices are showing up as it was before the migration.
VASA provider migration steps
-
Enable Derby PORT 1527 on the existing ONTAP tools for VMware vSphere. To enable the port, log in to CLI with root user and run the following command:
iptables -I INPUT 1 -p tcp --dport 1527 -j ACCEPT
-
Deploy OVA for ONTAP tools for VMware vSphere 10.2 release.
-
Add the vCenter Server instance that you want to migrate to ONTAP tools for VMware vSphere 10.2 release. See Add a vCenter Server instance.
-
Onboard storage backend locally from the remote plug-in vCenter server APIs. Add storage as local scoped for migration.
-
Issue the following API call to migrate:
HTTP method and endpoint
This REST API call uses the following method and endpoint.
HTTP method
Path
POST
/api/v1
Processing type
Asynchronous
Curl example
/api/v1/vcenters/{vcguid}/migration-jobs
JSON input example Request body for migrating from 9.12 and 9.13:
{ "otv_ip": "10.12.13.45", "vasa_provider_credentials": { "username": "vasauser", "password": "" } "database_password": "" }
Request body for other release migration:
{ "otv_ip": "10.12.13.45", "vasa_provider_credentials": { "username": "vasauser", "password": "*" } }
JSON output example
A job object is returned. You should save the job identifier to use it in the next step.
{ "id": 123, "migration_id": "d50073ce-35b4-4c51-9d2e-4ce66f802c35", "status": "running" }
-
Use the following URI to check the status:
https://xx.xx.xx.xxx:8443/virtualization/api/jobmanager/v2/jobs/<JobID>?includeSubJobsAndTasks=true
Once the job is completed, validate the migration report. You can see the report from the job-response as part of the jobData.
-
Add ONTAP tools for VMware vSphere storage provider to the vCenter Server and Register VASA Provider to vCenter Server.
-
Stop ONTAP tools for VMware vSphere storage provider 9.10/9.11/9.12/9.13 VASA Provider service from maintenance console.
Do not delete the VASA provider.
Once the old VASA provider is stopped, vCenter Server fails over to ONTAP tools for VMware vSphere. All the datastores and VMs become accessible and are served from ONTAP tools for VMware vSphere.
-
Perform the patch migrate using the following API:
HTTP method and endpoint
This REST API call uses the following method and endpoint.
HTTP method
Path
PATCH
/api/v1
Processing type
Asynchronous
Curl example
PATCH "/api/v1/vcenters/56d373bd-4163-44f9-a872-9adabb008ca9/migration-jobs/84dr73bd-9173-65r7-w345-8ufdbb887d43
JSON input example
{ "id": 123, "migration_id": "d50073ce-35b4-4c51-9d2e-4ce66f802c35", "status": "running" }
JSON output example
A job object is returned. You should save the job identifier to use it in the next step.
{ "id": 123, "migration_id": "d50073ce-35b4-4c51-9d2e-4ce66f802c35", "status": "running" }
Request body is empty for patch operation.
uuid is the migration uuid returned in the response of post migrate API. Once the patch migrate API is successful, all the VMs will be compliant with the storage policy.
-
The delete API for migration is:
HTTP method
Path
DELETE
/api/v1
Processing type
Asynchronous
Curl example
/api/v1/vcenters/{vcguid}/migration-jobs/{migration_id}
This API deletes migration by Migration Id and deletes migration on the given vCenter Server.
After successful migration and after you register ONTAP tools 10.2 to the vCenter Server, do the following:
-
Refresh the certificate on all the hosts.
-
Wait for some time before performing Datastore (DS) and Virtual Machine (VM) operations. The waiting time depends on the number of hosts, DS, and VMs that are present in the setup. When you don't wait, the operations may fail intermittently.