Chapter 4. Migrating from OpenStack

Procedure

1. In the Red Hat OpenShift web console, click Migration for Virtualization > Migration plans.

   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.

   Warning

   Do not take a snapshot of a VM after you start a migration. Taking a snaphot after a migration starts might cause the migration to fail.

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

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. Create a Secret manifest for the source provider credentials:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: <secret>
     namespace: <namespace>
     ownerReferences:
       - apiVersion: forklift.konveyor.io/v1beta1
         kind: Provider
         name: <provider_name>
         uid: <provider_uid>
     labels:
       createdForProviderType: openstack
       createdForResourceType: providers
   type: Opaque
   stringData:
     user: <user>
     password: <password>
     insecureSkipVerify: <"true"/"false">
     domainName: <domain_name>
     projectName: <project_name>
     regionName: <region_name>
     cacert: |
       <ca_certificate>
     url: <api_end_point>
   EOF

   where:

   ownerReferences

   Is an optional section in which you can specify a provider’s name and uid.

   <user>

   Specifies the OpenStack user.

   <password>

   Specifies the user OpenStack password.

   <"true"/"false">

   Specifies "true" to skip certificate verification, and specifies "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.

   cacert

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

   <api_end_point>

   Specifies the API endpoint URL, for example, https://<identity_service>/v3.

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: openstack
     url: <api_end_point>
     secret:
       name: <secret>
       namespace: <namespace>
   EOF

   where:

   <api_end_point>

   Specifies the URL of the API endpoint.

   <secret>

   Specifies the name of the provider Secret CR.

3. 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
         source:
           id: <source_network_id>
           name: <source_network_name>
       - destination:
           name: <network_attachment_definition>
           namespace: <network_attachment_definition_namespace>
           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

   where:

   type

   Specifies the network type. Allowed values are pod and multus.

   source

   Specifies the source network. You can use either the id or the name parameter to specify the source network. For id, specify the OpenStack network UUID.

   <network_attachment_definition>

   Specifies a network attachment definition (NAD) for each additional OpenShift Virtualization network.

   <network_attachment_definition_namespace>

   Specifies the namespace of the OpenShift Virtualization NAD. Required only when type is multus.

   namespace

   Specifies the namespace. If you are using a user-defined network (UDN), its namespace is defined in OpenShift Virtualization.

4. 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>
         source:
           id: <source_volume_type>
     provider:
       source:
         name: <source_provider>
         namespace: <namespace>
       destination:
         name: <destination_provider>
         namespace: <namespace>
   EOF

   where:

   <access_mode>

   Specifies the access mode. Allowed values are ReadWriteOnce and ReadWriteMany.

   <source_volume_type>

   Specifies the OpenStack volume_type UUID. For example, f2737930-b567-451a-9ceb-2887f6207009.

5. 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/kubev2v/hook-runner
     serviceAccount:<service account>
     playbook: |
       LS0tCi0gbm...
   EOF

   where:

   <service account>

   Specifies the Red Hat OpenShift service account. This is an optional label. Use the serviceAccount parameter to modify any cluster resources.

   playbook

   Specifies the 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.

6. Enter the following command to create the network attachment definition (NAD) of the transfer network used for MTV migrations.

   You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically.

   Configuring the IP address enables the interface to reach the configured gateway.

   $ oc edit NetworkAttachmentDefinitions <name_of_the_NAD_to_edit>
   apiVersion: k8s.cni.cncf.io/v1
   kind: NetworkAttachmentDefinition
   metadata:
     name: <name_of_transfer_network>
     namespace: <namespace>
     annotations:
       forklift.konveyor.io/route: <IP_address>

7. Create a Plan manifest for the migration:

   $ cat << EOF | oc apply -f -
   apiVersion: forklift.konveyor.io/v1beta1
   kind: Plan
   metadata:
     name: <plan>
     namespace: <namespace>
   spec:
     provider:
       source:
         name: <source_provider>
         namespace: <namespace>
       destination:
         name: <destination_provider>
         namespace: <namespace>
     map:
       network:
         name: <network_map>
         namespace: <namespace>
       storage:
         name: <storage_map>
         namespace: <namespace>
     targetNamespace: <target_namespace>
     vms:
       - id: <source_vm1>
       - name: <source_vm2>
         hooks:
           - hook:
               namespace: <namespace>
               name: <hook>
             step: <step>
   EOF

   where:

   <plan>

   Specifies the name of the Plan CR.

   map

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

   network

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

   <network_map>

   Specifies the name of the NetworkMap CR.

   storage

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

   <storage_map>

   Specifies the name of the StorageMap CR.

   vms

   Specifies the source VMs. Accepts either the id or the name parameter to specify the source VMs. If you are using a UDN, verify that the IP address of the provider is outside the subnet of the UDN. If the IP address is within the subnet of the UDN, the migration fails.

   <source_vm1>

   Specifies the OpenStack VM UUID.

   hooks

   Specifies up to two hooks for a VM. Each hook must run during a separate migration step. This is an optional label.

   <hook>

   Specifies the name of the Hook CR.

   <step>

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

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

   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.