Installing and using the Migration Toolkit for Virtualization

Procedure

1. In the Red Hat OpenShift web console, click Operators → OperatorHub.
2. Use the Filter by keyword field to search for mtv-operator.
3. Click Migration Toolkit for Virtualization Operator and then click Install.
4. Click Create ForkliftController when the button becomes active.

5. Click Create.

   Your ForkliftController appears in the list that is displayed.

6. Click Workloads → Pods to verify that the MTV pods are running.

7. Click Operators → Installed Operators to verify that Migration Toolkit for Virtualization Operator appears in the openshift-mtv project with the status Succeeded.

   When the plugin is ready you will be prompted to reload the page. The Migration menu item is automatically added to the navigation bar, displayed on the left of the Red Hat OpenShift web console.

Procedure

1. Create the openshift-mtv project:

   $ cat << EOF | oc apply -f -
   apiVersion: project.openshift.io/v1
   kind: Project
   metadata:
     name: openshift-mtv
   EOF

   Copy to Clipboard Toggle word wrap

2. Create an OperatorGroup CR called migration:

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: migration
     namespace: openshift-mtv
   spec:
     targetNamespaces:
       - openshift-mtv
   EOF

   Copy to Clipboard Toggle word wrap

3. Create a Subscription CR for the Operator:

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: mtv-operator
     namespace: openshift-mtv
   spec:
     channel: release-v2.7
     installPlanApproval: Automatic
     name: mtv-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: "mtv-operator.v2.7.12"
   EOF

   Copy to Clipboard Toggle word wrap

4. Create a ForkliftController CR:

   $ cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: ForkliftController
   metadata:
     name: forklift-controller
     namespace: openshift-mtv
   spec:
     olm_managed: true
   EOF

   Copy to Clipboard Toggle word wrap

5. Verify that the MTV pods are running:

   $ oc get pods -n openshift-mtv

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                                                    READY   STATUS    RESTARTS   AGE
   forklift-api-bb45b8db4-cpzlg                            1/1     Running   0          6m34s
   forklift-controller-7649db6845-zd25p                    2/2     Running   0          6m38s
   forklift-must-gather-api-78fb4bcdf6-h2r4m               1/1     Running   0          6m28s
   forklift-operator-59c87cfbdc-pmkfc                      1/1     Running   0          28m
   forklift-ui-plugin-5c5564f6d6-zpd85                     1/1     Running   0          6m24s
   forklift-validation-7d84c74c6f-fj9xg                    1/1     Running   0          6m30s
   forklift-volume-populator-controller-85d5cb64b6-mrlmc   1/1     Running   0          6m36s

   Copy to Clipboard Toggle word wrap

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click vSphere.

4. Specify the following fields:

   Provider details

   • Provider resource name: Name of the source provider.
   • Endpoint type: Select the vSphere provider endpoint type. Options: vCenter or ESXi. You can migrate virtual machines from vCenter, an ESX/ESXi server that is not managed by vCenter, or from an ESX/ESXi server that is managed by vCenter but does not go through vCenter.
   • URL: URL of the SDK endpoint of the vCenter on which the source VM is mounted. Ensure that the URL includes the sdk path, usually /sdk. For example, https://vCenter-host-example.com/sdk. If a certificate for FQDN is specified, the value of this field needs to match the FQDN in the certificate.
   • VDDK init image: VDDKInitImage path. It is strongly recommended to create a VDDK init image to accelerate migrations. For more information, see Creating a VDDK image.

   Provider credentials

   • Username: vCenter user or ESXi user. For example, user@vsphere.local.
   • Password: vCenter user password or ESXi user password.

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

   Note

   It might take a few minutes for the provider to have the status Ready.

8. Optional: Add access to the UI of the provider:

   1. On the Providers page, click the provider.

      The Provider details page opens.

   2. Click the Edit icon under External UI web link.

   3. Enter the link and click Save.

      Note

      If you do not enter a link, MTV attempts to calculate the correct link.

      • If MTV succeeds, the hyperlink of the field points to the calculated link.
      • If MTV does not succeed, the field remains empty.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click the host number in the Hosts column beside a provider to view a list of hosts.
3. Select one or more hosts and click Select migration network.

4. Specify the following fields:

   • Network: Network name
   • ESXi host admin username: For example, root
   • ESXi host admin password: Password
5. Click Save.

6. Verify that the status of each host is Ready.

   If a host status is not Ready, the host might be unreachable on the migration network or the credentials might be incorrect. You can modify the host configuration and save the changes.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click OpenShift Virtualization.

4. Specify the following fields:

   • Provider resource name: Name of the source provider
   • URL: URL of the endpoint of the API server

   • Service account bearer token: Token for a service account with cluster-admin privileges

     If both URL and Service account bearer token are left blank, the local OpenShift cluster is used.

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

Procedure

1. In the Red Hat OpenShift web console, click Migration > Providers for virtualization.

2. Click the OpenShift Virtualization provider whose migration network you want to change.

   When the Providers detail page opens:

3. Click the Networks tab.
4. Click Set default transfer network.
5. Select a default transfer network from the list and click Save.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization and then click Create Plan.

   The Create migration plan wizard opens to the Select source provider interface.

2. Select the source provider of the VMs you want to migrate.

   The Select virtual machines interface opens.

3. Select the VMs you want to migrate and click Next.

   The Create migration plan pane opens. It displays the source provider’s name and suggestions for a target provider and namespace, a network map, and a storage map.

4. Enter the Plan name.
5. To change the Target provider, the Target namespace, or elements of the Network map or the Storage map, select an item from the relevant list.
6. To add either a Network map or a Storage map, click the + sign anf add a mapping.

7. Click Create migration plan.

   MTV validates the migration plan, and the Plan details page opens, indicating whether the plan is ready for use or contains an error.

   The details of the plan are listed, and you can edit the items you filled in on the previous page. If you make any changes, MTV validates the plan again.

8. Check the following items in the Settings section of the page:

   • Warm migration: By default, all migrations are cold migrations. For a warm migration, click the Edit icon and select Warm migration.

   • Transfer Network: The network used to transfer the VMs to OpenShift Virtualization, by default, this is the default transfer network of the provider. Verify that the transfer network is in the selected target namespace.To edit the transfer network, click the Edit icon, choose a different transfer network from the list in the window that opens, and click Save.

     You can configure an OpenShift network in the OpenShift web console by clicking Networking > NetworkAttachmentDefinitions.

     To learn more about the different types of networks OpenShift supports, see Additional Networks in OpenShift Container Platform.

     If you want to adjust the maximum transmission unit (MTU) of the OpenShift transfer network, you must also change the MTU of the VMware migration network. For more information see Selecting a migration network for a VMware source provider.

   • Target namespace: Destination namespace to be used by all the migrated VMs, by default, this is the current or active namespace. To edit the namespace, click the Edit icon, choose a different target namespace from the list in the window that opens, and click Save.

   • Preserve static IPs: By default, virtual network interface controllers (vNICs) change during the migration process. As a result, vNICs that are configured with a static IP linked to the interface name in the guest VM lose their IP. To avoid this, click the Edit icon next to Preserve static IPs and toggle the Whether to preserve the static IPs switch in the window that opens. Then click Save.

     MTV then issues a warning message about any VMs for which vNIC properties are missing. To retrieve any missing vNIC properties, run those VMs in vSphere in order for the vNIC properties to be reported to MTV.

   • Disk decryption passphrases: For disks encrypted using Linux Unified Key Setup (LUKS). To enter a list of decryption passphrases for LUKS-encrypted devices, in the Settings section, click the Edit icon next to Disk decryption passphrases, enter the passphrases, and then click Save. You do not need to enter the passphrases in a specific order. For each LUKS-encrypted device, MTV tries each passphrase until one unlocks the device.

   • Root device: Applies to multi-boot VM migrations only. By default, MTV uses the first bootable device detected as the root device.

     To specify a different root device, in the Settings section, click the Edit icon next to Root device and choose a device from the list of commonly-used options, or enter a device in the text box.

     MTV uses the following format for disk location: /dev/sd<disk_identifier><disk_partition>. For example, if the second disk is the root device and the operating system is on the disk’s second partition, the format would be: /dev/sdb2. After you enter the boot device, click Save.

     If the conversion fails because the boot device provided is incorrect, it is possible to get the correct information by checking the conversion pod logs.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Plans for virtualization.

   The Plans list displays the source and target providers, the number of virtual machines (VMs) being migrated, the status, the date that the migration started, and the description of each plan.

2. Click Start beside a migration plan to start the migration.

3. Click Start in the confirmation window that opens.

   The plan’s Status changes to Running, and the migration’s progress is displayed.

   Warm migration only:

   • The precopy stage starts.
   • Click Cutover to complete the migration.

4. Optional: Click the links in the migration’s Status to see its overall status and the status of each VM:

   • The link on the left indicates whether the migration failed, succeeded, or is ongoing. It also reports the number of VMs whose migration succeeded, failed, or was canceled.

   • The link on the right opens the Virtual Machines tab of the Plan Details page. For each VM, the tab displays the following data:

     • The name of the VM
     • The start and end times of the migration
     • The amount of data copied

     • A progress pipeline for the VM’s migration

       Warning

       vMotion, including svMotion, and relocation must be disabled for VMs that are being imported to avoid data corruption.

5. Optional: To view your migration’s logs, either as it is running or after it is completed, perform the following actions:

   1. Click the Virtual Machines tab.

   2. Click the arrow (>) to the left of the virtual machine whose migration progress you want to check.

      The VM’s details are displayed.

   3. In the Pods section, in the Pod links column, click the Logs link.

      The Logs tab opens.

      Note

      Logs are not always available. The following are common reasons for logs not being available:

      • The migration is from OpenShift Virtualization to OpenShift Virtualization. In this case, virt-v2v is not involved, so no pod is required.
      • No pod was created.
      • The pod was deleted.
      • The migration failed before running the pod.
   4. To see the raw logs, click the Raw link.
   5. To download the logs, click the Download link.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization.
2. Click the name of a running migration plan to view the migration details.
3. Select one or more VMs and click Cancel.

4. Click Yes, cancel to confirm the cancellation.

   In the Migration details by VM list, the status of the canceled VMs is Canceled. The unmigrated and the migrated virtual machines are not affected.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click Red Hat Virtualization

4. Specify the following fields:

   • Provider resource name: Name of the source provider.
   • URL: URL of the API endpoint of the Red Hat Virtualization Manager (RHVM) on which the source VM is mounted. Ensure that the URL includes the path leading to the RHVM API server, usually /ovirt-engine/api. For example, https://rhv-host-example.com/ovirt-engine/api.
   • Username: Username.
   • Password: Password.

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

8. Optional: Add access to the UI of the provider:

   1. On the Providers page, click the provider.

      The Provider details page opens.

   2. Click the Edit icon under External UI web link.

   3. Enter the link and click Save.

      Note

      If you do not enter a link, MTV attempts to calculate the correct link.

      • If MTV succeeds, the hyperlink of the field points to the calculated link.
      • If MTV does not succeed, the field remains empty.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click OpenShift Virtualization.

4. Specify the following fields:

   • Provider resource name: Name of the source provider
   • URL: URL of the endpoint of the API server

   • Service account bearer token: Token for a service account with cluster-admin privileges

     If both URL and Service account bearer token are left blank, the local OpenShift cluster is used.

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

Procedure

1. In the Red Hat OpenShift web console, click Migration > Providers for virtualization.

2. Click the OpenShift Virtualization provider whose migration network you want to change.

   When the Providers detail page opens:

3. Click the Networks tab.
4. Click Set default transfer network.
5. Select a default transfer network from the list and click Save.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization and then click Create Plan.

   The Create migration plan wizard opens to the Select source provider interface.

2. Select the source provider of the VMs you want to migrate.

   The Select virtual machines interface opens.

3. Select the VMs you want to migrate and click Next.

   The Create migration plan pane opens. It displays the source provider’s name and suggestions for a target provider and namespace, a network map, and a storage map.

4. Enter the Plan name.
5. To change the Target provider, the Target namespace, or elements of the Network map or the Storage map, select an item from the relevant list.
6. To add either a Network map or a Storage map, click the + sign anf add a mapping.

7. Click Create migration plan.

   MTV validates the migration plan, and the Plan details page opens, indicating whether the plan is ready for use or contains an error.

   The details of the plan are listed, and you can edit the items you filled in on the previous page. If you make any changes, MTV validates the plan again.

8. Check the following items in the Settings section of the page:

   • Warm migration By default, all migrations are cold migrations. For a warm migration, click the Edit icon, and select Warm migration.

   • Transfer Network: The network used to transfer the VMs to OpenShift Virtualization, by default, this is the default transfer network of the provider. Verify that the transfer network is in the selected target namespace.To edit the transfer network, click the Edit icon, choose a different transfer network from the list in the window that opens, and click Save.

     You can configure an OpenShift network in the OpenShift web console by clicking Networking > NetworkAttachmentDefinitions.

     To learn more about the different types of networks OpenShift supports, see Additional Networks in OpenShift Container Platform.

     If you want to adjust the maximum transmission unit (MTU) of the OpenShift transfer network, you must also change the MTU of the VMware migration network. For more information see Selecting a migration network for a VMware source provider.

   • Target namespace: Destination namespace to be used by all the migrated VMs, by default, this is the current or active namespace. To edit the namespace, click the Edit icon, choose a different target namespace from the list in the window that opens, and click Save.

   • Preserving the CPU model of VMs that are migrated from RHV: Generally, the CPU model (type) for RHV VMs is set at the cluster level, but it can be set at the VM level, which is called a custom CPU model. By default, MTV sets the CPU model on the destination cluster as follows:

     • MTV preserves custom CPU settings for VMs that have them.

     • For VMs without custom CPU settings, MTV does not set the CPU model. Instead, the CPU model is later set by OpenShift Virtualization.

       To preserve the cluster-level CPU model of your RHV VMs, in the Settings section, click the Edit icon next to Preserve CPU model. Toggle the Whether to preserve the CPU model switch, and then click Save.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Plans for virtualization.

   The Plans list displays the source and target providers, the number of virtual machines (VMs) being migrated, the status, the date that the migration started, and the description of each plan.

2. Click Start beside a migration plan to start the migration.

3. Click Start in the confirmation window that opens.

   The plan’s Status changes to Running, and the migration’s progress is displayed.

   Warm migration only:

   • The precopy stage starts.
   • Click Cutover to complete the migration.

4. Optional: Click the links in the migration’s Status to see its overall status and the status of each VM:

   • The link on the left indicates whether the migration failed, succeeded, or is ongoing. It also reports the number of VMs whose migration succeeded, failed, or was canceled.

   • The link on the right opens the Virtual Machines tab of the Plan Details page. For each VM, the tab displays the following data:

     • The name of the VM
     • The start and end times of the migration
     • The amount of data copied

     • A progress pipeline for the VM’s migration

       Warning

       vMotion, including svMotion, and relocation must be disabled for VMs that are being imported to avoid data corruption.

5. Optional: To view your migration’s logs, either as it is running or after it is completed, perform the following actions:

   1. Click the Virtual Machines tab.

   2. Click the arrow (>) to the left of the virtual machine whose migration progress you want to check.

      The VM’s details are displayed.

   3. In the Pods section, in the Pod links column, click the Logs link.

      The Logs tab opens.

      Note

      Logs are not always available. The following are common reasons for logs not being available:

      • The migration is from OpenShift Virtualization to OpenShift Virtualization. In this case, virt-v2v is not involved, so no pod is required.
      • No pod was created.
      • The pod was deleted.
      • The migration failed before running the pod.
   4. To see the raw logs, click the Raw link.
   5. To download the logs, click the Download link.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization.
2. Click the name of a running migration plan to view the migration details.
3. Select one or more VMs and click Cancel.

4. Click Yes, cancel to confirm the cancellation.

   In the Migration details by VM list, the status of the canceled VMs is Canceled. The unmigrated and the migrated virtual machines are not affected.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click OpenStack.

4. Specify the following fields:

   • Provider resource name: Name of the source provider.
   • URL: URL of the OpenStack Identity (Keystone) endpoint. For example, http://controller:5000/v3.

   • Authentication type: Choose one of the following methods of authentication and supply the information related to your choice. For example, if you choose Application credential ID as the authentication type, the Application credential ID and the Application credential secret fields become active, and you need to supply the ID and the secret.

     • Application credential ID

       • Application credential ID: OpenStack application credential ID
       • Application credential secret: OpenStack application credential Secret

     • Application credential name

       • Application credential name: OpenStack application credential name
       • Application credential secret: OpenStack application credential Secret
       • Username: OpenStack username
       • Domain: OpenStack domain name

     • Token with user ID

       • Token: OpenStack token
       • User ID: OpenStack user ID
       • Project ID: OpenStack project ID

     • Token with user Name

       • Token: OpenStack token
       • Username: OpenStack username
       • Project: OpenStack project
       • Domain name: OpenStack domain name

     • Password

       • Username: OpenStack username
       • Password: OpenStack password
       • Project: OpenStack project
       • Domain: OpenStack domain name

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

8. Optional: Add access to the UI of the provider:

   1. On the Providers page, click the provider.

      The Provider details page opens.

   2. Click the Edit icon under External UI web link.

   3. Enter the link and click Save.

      Note

      If you do not enter a link, MTV attempts to calculate the correct link.

      • If MTV succeeds, the hyperlink of the field points to the calculated link.
      • If MTV does not succeed, the field remains empty.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click OpenShift Virtualization.

4. Specify the following fields:

   • Provider resource name: Name of the source provider
   • URL: URL of the endpoint of the API server

   • Service account bearer token: Token for a service account with cluster-admin privileges

     If both URL and Service account bearer token are left blank, the local OpenShift cluster is used.

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

Procedure

1. In the Red Hat OpenShift web console, click Migration > Providers for virtualization.

2. Click the OpenShift Virtualization provider whose migration network you want to change.

   When the Providers detail page opens:

3. Click the Networks tab.
4. Click Set default transfer network.
5. Select a default transfer network from the list and click Save.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization and then click Create Plan.

   The Create migration plan wizard opens to the Select source provider interface.

2. Select the source provider of the VMs you want to migrate.

   The Select virtual machines interface opens.

3. Select the VMs you want to migrate and click Next.

   The Create migration plan pane opens. It displays the source provider’s name and suggestions for a target provider and namespace, a network map, and a storage map.

4. Enter the Plan name.
5. To change the Target provider, the Target namespace, or elements of the Network map or the Storage map, select an item from the relevant list.
6. To add either a Network map or a Storage map, click the + sign anf add a mapping.

7. Click Create migration plan.

   MTV validates the migration plan, and the Plan details page opens, indicating whether the plan is ready for use or contains an error.

   The details of the plan are listed, and you can edit the items you filled in on the previous page. If you make any changes, MTV validates the plan again.

8. Check the following items in the Settings section of the page:

   • Transfer Network: The network used to transfer the VMs to OpenShift Virtualization, by default, this is the default transfer network of the provider. Verify that the transfer network is in the selected target namespace.To edit the transfer network, click the Edit icon, choose a different transfer network from the list in the window that opens, and click Save.

     You can configure an OpenShift network in the OpenShift web console by clicking Networking > NetworkAttachmentDefinitions.

     To learn more about the different types of networks OpenShift supports, see Additional Networks in OpenShift Container Platform.

     If you want to adjust the maximum transmission unit (MTU) of the OpenShift transfer network, you must also change the MTU of the VMware migration network. For more information see Selecting a migration network for a VMware source provider.

   • Target namespace: Destination namespace to be used by all the migrated VMs, by default, this is the current or active namespace. To edit the namespace, click the Edit icon, choose a different target namespace from the list in the window that opens, and click Save.

9. If your plan is valid, you can do one of the following:

   1. Run the plan now by clicking Start migration.
   2. Run the plan later by selecting it on the Plans for virtualization page and following the procedure in Running a migration plan.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Plans for virtualization.

   The Plans list displays the source and target providers, the number of virtual machines (VMs) being migrated, the status, the date that the migration started, and the description of each plan.

2. Click Start beside a migration plan to start the migration.

3. Click Start in the confirmation window that opens.

   The plan’s Status changes to Running, and the migration’s progress is displayed.

   Warm migration only:

   • The precopy stage starts.
   • Click Cutover to complete the migration.

4. Optional: Click the links in the migration’s Status to see its overall status and the status of each VM:

   • The link on the left indicates whether the migration failed, succeeded, or is ongoing. It also reports the number of VMs whose migration succeeded, failed, or was canceled.

   • The link on the right opens the Virtual Machines tab of the Plan Details page. For each VM, the tab displays the following data:

     • The name of the VM
     • The start and end times of the migration
     • The amount of data copied

     • A progress pipeline for the VM’s migration

       Warning

       vMotion, including svMotion, and relocation must be disabled for VMs that are being imported to avoid data corruption.

5. Optional: To view your migration’s logs, either as it is running or after it is completed, perform the following actions:

   1. Click the Virtual Machines tab.

   2. Click the arrow (>) to the left of the virtual machine whose migration progress you want to check.

      The VM’s details are displayed.

   3. In the Pods section, in the Pod links column, click the Logs link.

      The Logs tab opens.

      Note

      Logs are not always available. The following are common reasons for logs not being available:

      • The migration is from OpenShift Virtualization to OpenShift Virtualization. In this case, virt-v2v is not involved, so no pod is required.
      • No pod was created.
      • The pod was deleted.
      • The migration failed before running the pod.
   4. To see the raw logs, click the Raw link.
   5. To download the logs, click the Download link.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization.
2. Click the name of a running migration plan to view the migration details.
3. Select one or more VMs and click Cancel.

4. Click Yes, cancel to confirm the cancellation.

   In the Migration details by VM list, the status of the canceled VMs is Canceled. The unmigrated and the migrated virtual machines are not affected.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click Open Virtual Appliance (OVA).

4. Specify the following fields:

   • Provider resource name: Name of the source provider
   • URL: URL of the NFS file share that serves the OVA

5. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

   Note

   An error message might appear that states that an error has occurred. You can ignore this message.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click OpenShift Virtualization.

4. Specify the following fields:

   • Provider resource name: Name of the source provider
   • URL: URL of the endpoint of the API server

   • Service account bearer token: Token for a service account with cluster-admin privileges

     If both URL and Service account bearer token are left blank, the local OpenShift cluster is used.

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

Procedure

1. In the Red Hat OpenShift web console, click Migration > Providers for virtualization.

2. Click the OpenShift Virtualization provider whose migration network you want to change.

   When the Providers detail page opens:

3. Click the Networks tab.
4. Click Set default transfer network.
5. Select a default transfer network from the list and click Save.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization and then click Create Plan.

   The Create migration plan wizard opens to the Select source provider interface.

2. Select the source provider of the VMs you want to migrate.

   The Select virtual machines interface opens.

3. Select the VMs you want to migrate and click Next.

   The Create migration plan pane opens. It displays the source provider’s name and suggestions for a target provider and namespace, a network map, and a storage map.

4. Enter the Plan name.
5. To change the Target provider, the Target namespace, or elements of the Network map or the Storage map, select an item from the relevant list.
6. To add either a Network map or a Storage map, click the + sign anf add a mapping.

7. Click Create migration plan.

   MTV validates the migration plan, and the Plan details page opens, indicating whether the plan is ready for use or contains an error.

   The details of the plan are listed, and you can edit the items you filled in on the previous page. If you make any changes, MTV validates the plan again.

8. Check the following items in the Settings section of the page:

   • Transfer Network: The network used to transfer the VMs to OpenShift Virtualization, by default, this is the default transfer network of the provider. Verify that the transfer network is in the selected target namespace.To edit the transfer network, click the Edit icon, choose a different transfer network from the list in the window that opens, and click Save.

     You can configure an OpenShift network in the OpenShift web console by clicking Networking > NetworkAttachmentDefinitions.

     To learn more about the different types of networks OpenShift supports, see Additional Networks in OpenShift Container Platform.

     If you want to adjust the maximum transmission unit (MTU) of the OpenShift transfer network, you must also change the MTU of the VMware migration network. For more information see Selecting a migration network for a VMware source provider.

   • Target namespace: Destination namespace to be used by all the migrated VMs, by default, this is the current or active namespace. To edit the namespace, click the Edit icon, choose a different target namespace from the list in the window that opens, and click Save.

9. If your plan is valid, you can do one of the following:

   1. Run the plan now by clicking Start migration.
   2. Run the plan later by selecting it on the Plans for virtualization page and following the procedure in Running a migration plan.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Plans for virtualization.

   The Plans list displays the source and target providers, the number of virtual machines (VMs) being migrated, the status, the date that the migration started, and the description of each plan.

2. Click Start beside a migration plan to start the migration.

3. Click Start in the confirmation window that opens.

   The plan’s Status changes to Running, and the migration’s progress is displayed.

   Warm migration only:

   • The precopy stage starts.
   • Click Cutover to complete the migration.

4. Optional: Click the links in the migration’s Status to see its overall status and the status of each VM:

   • The link on the left indicates whether the migration failed, succeeded, or is ongoing. It also reports the number of VMs whose migration succeeded, failed, or was canceled.

   • The link on the right opens the Virtual Machines tab of the Plan Details page. For each VM, the tab displays the following data:

     • The name of the VM
     • The start and end times of the migration
     • The amount of data copied

     • A progress pipeline for the VM’s migration

       Warning

       vMotion, including svMotion, and relocation must be disabled for VMs that are being imported to avoid data corruption.

5. Optional: To view your migration’s logs, either as it is running or after it is completed, perform the following actions:

   1. Click the Virtual Machines tab.

   2. Click the arrow (>) to the left of the virtual machine whose migration progress you want to check.

      The VM’s details are displayed.

   3. In the Pods section, in the Pod links column, click the Logs link.

      The Logs tab opens.

      Note

      Logs are not always available. The following are common reasons for logs not being available:

      • The migration is from OpenShift Virtualization to OpenShift Virtualization. In this case, virt-v2v is not involved, so no pod is required.
      • No pod was created.
      • The pod was deleted.
      • The migration failed before running the pod.
   4. To see the raw logs, click the Raw link.
   5. To download the logs, click the Download link.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization.
2. Click the name of a running migration plan to view the migration details.
3. Select one or more VMs and click Cancel.

4. Click Yes, cancel to confirm the cancellation.

   In the Migration details by VM list, the status of the canceled VMs is Canceled. The unmigrated and the migrated virtual machines are not affected.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click OpenShift Virtualization.

4. Specify the following fields:

   • Provider resource name: Name of the source provider
   • URL: URL of the endpoint of the API server

   • Service account bearer token: Token for a service account with cluster-admin privileges

     If both URL and Service account bearer token are left blank, the local OpenShift cluster is used.

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

8. Optional: Add access to the UI of the provider:

   1. On the Providers page, click the provider.

      The Provider details page opens.

   2. Click the Edit icon under External UI web link.

   3. Enter the link and click Save.

      Note

      If you do not enter a link, MTV attempts to calculate the correct link.

      • If MTV succeeds, the hyperlink of the field points to the calculated link.
      • If MTV does not succeed, the field remains empty.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Providers for virtualization.
2. Click Create Provider.
3. Click OpenShift Virtualization.

4. Specify the following fields:

   • Provider resource name: Name of the source provider
   • URL: URL of the endpoint of the API server

   • Service account bearer token: Token for a service account with cluster-admin privileges

     If both URL and Service account bearer token are left blank, the local OpenShift cluster is used.

5. Choose one of the following options for validating CA certificates:

   • Use a custom CA certificate: Migrate after validating a custom CA certificate.
   • Use the system CA certificate: Migrate after validating the system CA certificate.

   • Skip certificate validation : Migrate without validating a CA certificate.

     1. To use a custom CA certificate, leave the Skip certificate validation switch toggled to left, and either drag the CA certificate to the text box or browse for it and click Select.
     2. To use the system CA certificate, leave the Skip certificate validation switch toggled to the left, and leave the CA certificate text box empty.
     3. To skip certificate validation, toggle the Skip certificate validation switch to the right.

6. Optional: Ask MTV to fetch a custom CA certificate from the provider’s API endpoint URL.

   1. Click Fetch certificate from URL. The Verify certificate window opens.

   2. If the details are correct, select the I trust the authenticity of this certificate checkbox, and then, click Confirm. If not, click Cancel, and then, enter the correct certificate information manually.

      Once confirmed, the CA certificate will be used to validate subsequent communication with the API endpoint.

7. Click Create provider to add and save the provider.

   The provider appears in the list of providers.

Procedure

1. In the Red Hat OpenShift web console, click Migration > Providers for virtualization.

2. Click the OpenShift Virtualization provider whose migration network you want to change.

   When the Providers detail page opens:

3. Click the Networks tab.
4. Click Set default transfer network.
5. Select a default transfer network from the list and click Save.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization and then click Create Plan.

   The Create migration plan wizard opens to the Select source provider interface.

2. Select the source provider of the VMs you want to migrate.

   The Select virtual machines interface opens.

3. Select the VMs you want to migrate and click Next.

   The Create migration plan pane opens. It displays the source provider’s name and suggestions for a target provider and namespace, a network map, and a storage map.

4. Enter the Plan name.
5. To change the Target provider, the Target namespace, or elements of the Network map or the Storage map, select an item from the relevant list.
6. To add either a Network map or a Storage map, click the + sign anf add a mapping.

7. Click Create migration plan.

   MTV validates the migration plan, and the Plan details page opens, indicating whether the plan is ready for use or contains an error.

   The details of the plan are listed, and you can edit the items you filled in on the previous page. If you make any changes, MTV validates the plan again.

8. Check the following items in the Settings section of the page:

   • Transfer Network: The network used to transfer the VMs to OpenShift Virtualization, by default, this is the default transfer network of the provider. Verify that the transfer network is in the selected target namespace.To edit the transfer network, click the Edit icon, choose a different transfer network from the list in the window that opens, and click Save.

     You can configure an OpenShift network in the OpenShift web console by clicking Networking > NetworkAttachmentDefinitions.

     To learn more about the different types of networks OpenShift supports, see Additional Networks in OpenShift Container Platform.

     If you want to adjust the maximum transmission unit (MTU) of the OpenShift transfer network, you must also change the MTU of the VMware migration network. For more information see Selecting a migration network for a VMware source provider.

   • Target namespace: Destination namespace to be used by all the migrated VMs, by default, this is the current or active namespace. To edit the namespace, click the Edit icon, choose a different target namespace from the list in the window that opens, and click Save.

9. If your plan is valid, you can do one of the following:

   1. Run the plan now by clicking Start migration.
   2. Run the plan later by selecting it on the Plans for virtualization page and following the procedure in Running a migration plan.

Procedure

1. In the Red Hat OpenShift web console, click Migration → Plans for virtualization.

   The Plans list displays the source and target providers, the number of virtual machines (VMs) being migrated, the status, the date that the migration started, and the description of each plan.

2. Click Start beside a migration plan to start the migration.

3. Click Start in the confirmation window that opens.

   The plan’s Status changes to Running, and the migration’s progress is displayed.

   Warm migration only:

   • The precopy stage starts.
   • Click Cutover to complete the migration.

4. Optional: Click the links in the migration’s Status to see its overall status and the status of each VM:

   • The link on the left indicates whether the migration failed, succeeded, or is ongoing. It also reports the number of VMs whose migration succeeded, failed, or was canceled.

   • The link on the right opens the Virtual Machines tab of the Plan Details page. For each VM, the tab displays the following data:

     • The name of the VM
     • The start and end times of the migration
     • The amount of data copied

     • A progress pipeline for the VM’s migration

       Warning

       vMotion, including svMotion, and relocation must be disabled for VMs that are being imported to avoid data corruption.

5. Optional: To view your migration’s logs, either as it is running or after it is completed, perform the following actions:

   1. Click the Virtual Machines tab.

   2. Click the arrow (>) to the left of the virtual machine whose migration progress you want to check.

      The VM’s details are displayed.

   3. In the Pods section, in the Pod links column, click the Logs link.

      The Logs tab opens.

      Note

      Logs are not always available. The following are common reasons for logs not being available:

      • The migration is from OpenShift Virtualization to OpenShift Virtualization. In this case, virt-v2v is not involved, so no pod is required.
      • No pod was created.
      • The pod was deleted.
      • The migration failed before running the pod.
   4. To see the raw logs, click the Raw link.
   5. To download the logs, click the Download link.

Procedure

1. In the Red Hat OpenShift web console, click Plans for virtualization.
2. Click the name of a running migration plan to view the migration details.
3. Select one or more VMs and click Cancel.

4. Click Yes, cancel to confirm the cancellation.

   In the Migration details by VM list, the status of the canceled VMs is Canceled. The unmigrated and the migrated virtual machines are not affected.

Procedure

1. Create a Secret manifest for the source provider credentials:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: <secret>
     namespace: <namespace>
     ownerReferences: 

   1

   
       - apiVersion: forklift.konveyor.io/v1beta1
         kind: Provider
         name: <provider_name>
         uid: <provider_uid>
     labels:
       createdForProviderType: vsphere
       createdForResourceType: providers
   type: Opaque
   stringData:
     user: <user> 

   2

   
     password: <password> 

   3

   
     insecureSkipVerify: <"true"/"false"> 

   4

   
     cacert: | 

   5

   
       <ca_certificate>
     url: <api_end_point> 

   6

   
   EOF

   Copy to Clipboard Toggle word wrap

   1

   The ownerReferences section is optional.

   2

   Specify the vCenter user or the ESX/ESXi user.

   3

   Specify the password of the vCenter user or the ESX/ESXi user.

   4

   Specify "true" to skip certificate verification, and specify "false" to verify the certificate. Defaults to "false" if not specified. Skipping certificate verification proceeds with an insecure migration and then the certificate is not required. Insecure migration means that the transferred data is sent over an insecure connection and potentially sensitive data could be exposed.

   5

   When this field is not set and skip certificate verification is disabled, MTV attempts to use the system CA.

   6

   Specify the API endpoint URL of the vCenter or the ESX/ESXi, for example, https://<vCenter_host>/sdk.

2. Create a Provider manifest for the source provider:

   $ cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: Provider
   metadata:
     name: <source_provider>
     namespace: <namespace>
   spec:
     type: vsphere
     url: <api_end_point> 

   1

   
     settings:
       vddkInitImage: <VDDK_image> 

   2

   
       sdkEndpoint: vcenter 

   3

   
     secret:
       name: <secret> 

   4

   
       namespace: <namespace>
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Specify the URL of the API endpoint, for example, https://<vCenter_host>/sdk.

   2

   Optional, but it is strongly recommended to create a VDDK image to accelerate migrations. Follow OpenShift documentation to specify the VDDK image you created.

   3

   Options: vcenter or esxi.

   4

   Specify the name of the provider Secret CR.

3. Create a Host manifest:

   $ cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: Host
   metadata:
     name: <vmware_host>
     namespace: <namespace>
   spec:
     provider:
       namespace: <namespace>
       name: <source_provider> 

   1

   
     id: <source_host_mor> 

   2

   
     ipAddress: <source_network_ip> 

   3

   
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Specify the name of the VMware vSphere Provider CR.

   2

   Specify the Managed Object Reference (moRef) of the VMware vSphere host. To retrieve the moRef, see Retrieving a VMware vSphere moRef.

   3

   Specify the IP address of the VMware vSphere migration network.

4. Create a NetworkMap manifest to map the source and destination networks:

   $  cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: NetworkMap
   metadata:
     name: <network_map>
     namespace: <namespace>
   spec:
     map:
       - destination:
           name: <network_name>
           type: pod 

   1

   
         source: 

   2

   
           id: <source_network_id>
           name: <source_network_name>
       - destination:
           name: <network_attachment_definition> 

   3

   
           namespace: <network_attachment_definition_namespace> 

   4

   
           type: multus
         source:
           id: <source_network_id>
           name: <source_network_name>
     provider:
       source:
         name: <source_provider>
         namespace: <namespace>
       destination:
         name: <destination_provider>
         namespace: <namespace>
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Allowed values are pod and multus.

   2

   You can use either the id or the name parameter to specify the source network. For id, specify the VMware vSphere network Managed Object Reference (moRef). To retrieve the moRef, see Retrieving a VMware vSphere moRef.

   3

   Specify a network attachment definition for each additional OpenShift Virtualization network.

   4

   Required only when type is multus. Specify the namespace of the OpenShift Virtualization network attachment definition.

5. Create a StorageMap manifest to map source and destination storage:

   $ cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: StorageMap
   metadata:
     name: <storage_map>
     namespace: <namespace>
   spec:
     map:
       - destination:
           storageClass: <storage_class>
           accessMode: <access_mode> 

   1

   
         source:
           id: <source_datastore> 

   2

   
     provider:
       source:
         name: <source_provider>
         namespace: <namespace>
       destination:
         name: <destination_provider>
         namespace: <namespace>
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Allowed values are ReadWriteOnce and ReadWriteMany.

   2

   Specify the VMware vSphere datastore moRef. For example, f2737930-b567-451a-9ceb-2887f6207009. To retrieve the moRef, see Retrieving a VMware vSphere moRef.

6. Optional: Create a Hook manifest to run custom code on a VM during the phase specified in the Plan CR:

   $  cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: Hook
   metadata:
     name: <hook>
     namespace: <namespace>
   spec:
     image: quay.io/konveyor/hook-runner
     serviceAccount:<service account> 

   1

   
     playbook: |
       LS0tCi0gbm... 

   2

   
   EOF

   Copy to Clipboard Toggle word wrap

   1

   (Optional) Red Hat OpenShift service account. The serviceAccount must be provided if you want to manipulate any resources of the cluster.

   2

   Base64-encoded Ansible Playbook. If you specify a playbook, the image must include an ansible-runner.

   Note

   You can use the default hook-runner image or specify a custom image. If you specify a custom image, you do not have to specify a playbook.

7. Create a Plan manifest for the migration:

   $ cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: Plan
   metadata:
     name: <plan> 

   1

   
     namespace: <namespace>
   spec:
     warm: false 

   2

   
     provider:
       source:
         name: <source_provider>
         namespace: <namespace>
       destination:
         name: <destination_provider>
         namespace: <namespace>
     map: 

   3

   
       network: 

   4

   
         name: <network_map> 

   5

   
         namespace: <namespace>
       storage: 

   6

   
         name: <storage_map> 

   7

   
         namespace: <namespace>
     preserveStaticIPs: 

   8

   
     targetNamespace: <target_namespace>
     vms: 

   9

   
       - id: <source_vm> 

   10

   
       - name: <source_vm>
         hooks: 

   11

   
           - hook:
               namespace: <namespace>
               name: <hook> 

   12

   
             step: <step> 

   13

   
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Specify the name of the Plan CR.

   2

   Specify whether the migration is warm - true - or cold - false. If you specify a warm migration without specifying a value for the cutover parameter in the Migration manifest, only the precopy stage will run.

   3

   Specify only one network map and one storage map per plan.

   4

   Specify a network mapping even if the VMs to be migrated are not assigned to a network. The mapping can be empty in this case.

   5

   Specify the name of the NetworkMap CR.

   6

   Specify a storage mapping even if the VMs to be migrated are not assigned with disk images. The mapping can be empty in this case.

   7

   Specify the name of the StorageMap CR.

   8

   By default, virtual network interface controllers (vNICs) change during the migration process. As a result, vNICs that are configured with a static IP linked to the interface name in the guest VM lose their IP. To avoid this, set preserveStaticIPs to true. MTV issues a warning message about any VMs for which vNIC properties are missing. To retrieve any missing vNIC properties, run those VMs in vSphere in order for the vNIC properties to be reported to MTV.

   9

   You can use either the id or the name parameter to specify the source VMs.

   10

   Specify the VMware vSphere VM moRef. To retrieve the moRef, see Retrieving a VMware vSphere moRef.

   11

   Optional: You can specify up to two hooks for a VM. Each hook must run during a separate migration step.

   12

   Specify the name of the Hook CR.

   13

   Allowed values are PreHook, before the migration plan starts, or PostHook, after the migration is complete.

   Important

   When you migrate a VMware 7 VM to an OpenShift 4.13+ platform that uses CentOS 7.9, the name of the network interfaces changes and the static IP configuration for the VM no longer works.

8. Create a Migration manifest to run the Plan CR:

   $ cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: Migration
   metadata:
     name: <name_of_migration_cr>
     namespace: <namespace>
   spec:
     plan:
       name: <name_of_plan_cr>
       namespace: <namespace>
     cutover: <optional_cutover_time>
   EOF

   Copy to Clipboard Toggle word wrap
   Note

   If you specify a cutover time, use the ISO 8601 format with the UTC time offset, for example, 2024-04-04T01:23:45.678+09:00.