Chapter 7. Migrating from AWS EC2

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 snapshot 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. To view your migration’s logs, either as it is running or after it is completed:

   1. Click the Virtual machines tab.
   2. Click the arrow (>) before the name of the virtual machine whose migration progress you want to check.

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

      The Logs tab opens.

      Note

      Logs might not be available for the following common reasons:

      • The migration is from OpenShift Virtualization to OpenShift Virtualization. In this case, the virt-v2v utility 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>
   type: Opaque
   stringData:
     region: <aws_region>
     accessKeyId: <aws_access_key_id>
     secretAccessKey: <aws_secret_access_key>
     # targetAccessKeyId: <target_aws_access_key_id>
     # targetSecretAccessKey: <target_aws_secret_access_key>
   EOF

   where:

   <secret>

   Specifies the name of the Secret CR.

   <namespace>

   Specifies the namespace for the resource. Use openshift-mtv for the MTV namespace, or specify a custom namespace if you have configured providers in a different project.

   <aws_region>

   Specifies the region where your EC2 instances are located, for example, us-east-1 or us-east-2.

   <aws_access_key_id>

   Specifies the access key ID for the source account.

   <aws_secret_access_key>

   Specifies the secret access key for the source account.

   <target_aws_access_key_id>

   Specifies the access key ID for the target account. Required only for cross-account migrations.

   <target_aws_secret_access_key>

   Specifies the secret access key for the target account. Required only for cross-account migrations.

   Note

   For same-account migrations, use the OpenShift cluster’s credentials to ensure the Elastic Block Store (EBS) Container Storage Interface (CSI) driver can access the migrated volumes.

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: ec2
     secret:
       name: <secret>
       namespace: <namespace>
     settings:
       target-az: <target_availability_zone>
   EOF

   where:

   <namespace>

   Specifies the namespace for the resource. Use openshift-mtv for the MTV namespace, or specify a custom namespace if you have configured providers in a different project.

   <source_provider>

   Specifies the name of the source provider.

   <secret>

   Specifies the name of the provider Secret CR.

   <target_availability_zone>

   Specifies the target availability zone where MTV creates EBS volumes, for example, us-east-1a. This must match an availability zone where OpenShift worker nodes run.

   Important

   EBS volumes are availability zone-specific. If the target-az setting does not match an availability zone where OpenShift worker nodes run, the EBS CSI driver cannot attach the volumes to worker nodes, causing the migration to fail.

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_subnet_id>
       - destination:
           name: <network_attachment_definition>
           namespace: <network_attachment_definition_namespace>
           type: multus
         source:
           id: <source_subnet_id>
     provider:
       source:
         name: <source_provider>
         namespace: <namespace>
       destination:
         name: <destination_provider>
         namespace: <namespace>
   EOF

   where:

   <network_map>

   Specifies the name of the network map.

   <namespace>

   Specifies the namespace for the resource. Use openshift-mtv for the MTV namespace, or specify a custom namespace if you have configured providers in a different project.

   <source_subnet_id>

   Specifies the subnet ID (for example, subnet-abc123def456).

   type

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

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

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

   where:

   <storage_map>

   Specifies the name of the storage map.

   <storage_class>

   Specifies the storage class that uses the EBS CSI driver. The storage class must be configured for the same availability zone as the target-az setting in the Provider resource.

   <source_volume_type>

   Specifies the EBS volume type (for example, gp2, gp3, io1).

5. 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:

   <namespace>

   Specifies the namespace for the resource. Use openshift-mtv for the MTV namespace, or specify a custom namespace if you have configured providers in a different project.

   <plan>

   Specifies the name of the Plan CR.

   map

   Specifies the network map and storage map used by the plan.

   network

   Specifies a network mapping, even if the migration does not assign the virtual machines (VMs) 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 migration does not assign disk images to the VMs. The mapping can be empty in this case.

   <storage_map>

   Specifies the name of the StorageMap CR.

   <target_namespace>

   Specifies the target namespace in OpenShift Virtualization where MTV creates the migrated VMs.

   vms

   Specifies the source VMs. Accepts either the id or the name parameter to specify the source VMs.

   <source_vm1>

   Specifies the EC2 instance ID.

   hooks

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

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

6. 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>
   EOF

   where:

   <name_of_migration_cr>

   Specifies the name of the Migration CR.

   <name_of_plan_cr>

   Specifies the name of the Plan CR to execute.

7. Monitor the migration progress:

   $ oc get migration/<name_of_migration_cr> -n <namespace> -o yaml

   This shows the migration status and progress.

8. View detailed migration information:

   $ oc get vmimports -n <namespace>

   This shows the detailed phases of the VM import process.