Plan for migration performance

Your migration performance is dependent on your environment and your application of the best practice guidelines.

Migration best practices

The following are some migration best practices, when you migrate a large workload from VMware to Red Hat OpenStack Services on OpenShift (RHOSO) with Ansible Automation Platform (AAP) using a conversion host:

  • Ensure that you size your destination RHOSO environment appropriately to accommodate large numbers of instances, ports, volumes, floating IPs, API requests, and other RHOSO resources.
  • Divide your workload among multiple conversion hosts and threads for faster migration.
  • A conversion host typically contains the following configuration:
    • 6 vCPU.
    • 8GB RAM.
    • 20GB disk.
    • Red Hat Enterprise Linux 9.5 or later.

Known issues

  • If a single conversion host performs many 1,000s of migrations in a short time, there might be issues with the device mount mechanism in the operating system. You can remedy this by rebooting the conversion host to clean the /dev/ directory.
  • If you encounter the message snapshot hierarchy is too deep, you can clean the guest snapshots hierarchy and re-run the migration.

Migration performance benchmarks

The following tables contain example performance measurements for migrating from VMware to Red Hat OpenStack Services on OpenShift (RHOSO) with Ansible Automation Platform (AAP).

Table 1. Migration with 1 conversion host
VMs Threads Time

1

1

2 minutes

20

1

31 minutes

20

2

15 minutes

30

10

8 minutes

100

10

20 minutes

Table 2. Migration of RHEL VMs with large disks filled with random data
Disk size CBT enabled Time Cutover time Expected downtime

100 GB

yes

8 minutes

2 minutes

2 minutes

100 GB

no

7 minutes

-

7 minutes

200 GB

yes

10 minutes 30 seconds

2 minutes

2 minutes

200 GB

no

9 minutes 30 seconds

-

9 minutes 30 seconds

300 GB

yes

17 minutes

2 minutes

2 minutes

300 GB

no

15 minutes

-

15 minutes

1 TB

yes

39 minutes

2 minutes

2 minutes

1 TB

no

35 minutes

-

35 minutes

Note
Enabling Change Block Tracking (CBT) takes more time overall to migrate but with less downtime because of the smaller data cutover time.
Table 3. Migration of 55 VMs with 200GB disks filled with random data
Threads CBT enabled Time Sync time

1

yes

115 minutes

5

no

105 minutes

5

no

22 minutes

110 minutes

Note
Parallelizing the migration on a single conversion host with 5 threads and enabling CBT to pre-migrate the volume data reduces the downtime.
Table 4. Migration of 1500 VMs with 20GB disks filled with random data
VMs Conversion hosts Threads Time

250

2

6

60 minutes

1000

2

6

5 hours

1500

2

6

> 5 hours

Note
The conversion host flavor has 12 GB of RAM and 6 vCPUs, and can run 6 migrations in parallel.

Post-migration script hooks

After you migrate virtual machines from VMware to Red Hat OpenStack Services on OpenShift (RHOSO), the VMs can fail to start or lose network connectivity due to hypervisor-specific configurations. You can incorporate scripting to assist in the following areas:

Network Interface Drift
VMware and RHOSO can have different interface names. You can use a script to remap MAC addresses to preserve connectivity.
Different Driver Configurations
VMware Tools, drivers, and configurations are incompatible with RHOSO. You can use a script to reconfigure the guest operating system.
Zero-Touch Automation
Manual post-migration fixes do not scale. You can use script hooks to automate migrations.
Reduced Downtime
You should fix issues before or during migration, not after. You can use a script to ensure that VMs are properly configured before they start in RHOSO.

There are two levels of migration hook:

  • Migration playbooks at the Ansible Automation level that run before and after migration.
  • Hooks on the guest operating system.
Table 5. Overview of script hooks
Level of hook Type of hook When the hook runs Use case

Ansible / AAP.

Pre-migration playbook.

Before migration.

Preparing environment, validation, approvals.

Ansible / AAP.

Post-migration playbook.

After migration.

Verification, DNS updates, notifications.

Guest operating system.

Runscript.

During v2v conversion.

Network configuration, driver removal.

Guest operating system.

Boot script.

First start in RHOSO.

Agent installation, registration.

Guest filesystem.

Run script only for Linux guest VMs.

Before the VM starts in RHOSO.

Extend default network config logic.

Create a first-boot script for post-migration tasks

You can create a script that runs when the VM starts for the first time after migration. Include logic in your script to load Red Hat OpenStack Services on OpenShift (RHOSO) drivers, remove VMware tools, install monitoring agents, and complete other important post-migration tasks.

Procedure

  1. Create your boot script:
    #!/bin/bash
    # post-migration-firstboot.sh
    
    LOG="/var/log/migration-firstboot.log"
    exec > >(tee -a "$LOG") 2>&1
    echo "=== First Boot: $(date) ==="
    
    # Your custom logic here...
    
    touch /var/log/migration-complete
  2. Set the variable in your vars file or playbook by using the Ansible variable boot_script_path:
    # In your vars file or playbook
    boot_script_path: "/opt/scripts/post-migration-firstboot.sh"
  3. Add logic to your migration playbook so that the script is copied in the conversion host:
    - name: Migrate with Custom Bootscript
      hosts: conversion_host
      vars:
        boot_script_path: "/opt/scripts/post-migration-firstboot.sh"
        vms_list:
          - # Add the names of your VMs here
    
      pre_tasks:
        - name: Copy bootscript to conversion host
          ansible.builtin.copy:
            src: files/post-migration-firstboot.sh
            dest: "{{ boot_script_path }}"
            mode: '0755'
    
      tasks:
        - name: Run migration with bootscript
          ansible.builtin.include_role:
            name: os_migrate.vmware_migration_kit.import_workloads
          loop: "{{ vms_list }}"
          loop_control:
            loop_var: vm
          vars:
            vm_name: "{{ vm }}"