Migrate VMware VMs to Red Hat OpenShift Virtualization by using MTV

Software compatibility

To successfully migrate, install compatible versions of Red Hat OpenShift and Red Hat OpenShift Virtualization.

For MTV 2.9, the compatible software versions include:

• Red Hat OpenShift: 4.19, 4.18, 4.17
• Red Hat OpenShift Virtualization: 4.19, 4.18, 4.17
• VMware vSphere: 6.5 or later

Network requirements

Network prerequisites apply across all migrations:

Network stability

The network connections between the source environment and the Red Hat OpenShift Virtualization cluster must be reliable and uninterrupted.

Configuration integrity

Do not change IP addresses, virtual local area networks (VLANs), or other network configuration settings during migration, as the VM's MAC addresses are preserved.

Network address uniqueness

If you are migrating workloads from IBM Cloud classic infrastructure, connect your virtual private cloud (VPC) to the classic infrastructure by using IBM Cloud Transit Gateway. When you create the VPC to host your workloads, ensure that the network address prefixes do not overlap with prefixes that are used by other VPCs connected to your IBM Cloud classic infrastructure. When you create your VPC, deselect the Create a default prefix for each zone checkbox. The default prefix remains the same across VPCs and can introduce routing conflicts. After the VPC is created, you can configure address prefixes and subnets as needed.

Destination networks

If multiple source and destination networks are mapped, create a network attachment definition for each additional destination network.

Required ports

Firewalls must permit traffic over specific ports based on the source provider:

• VMware vSphere: Transmission Control Protocol (TCP) ports 443 (for inventory and disk transfer authentication) and 902 (for disk transfer data copy) from Red Hat OpenShift nodes to VMware vCenter®/ESXi hosts.
• OVA: TCP port 2049 (for Network File System (NFS) service) and TCP or User Datagram Protocol (UDP) port 111 (for remote procedure call (RPC) portmapper, only required for NFSv4.0) from Red Hat OpenShift nodes to the server containing the OVA files.

Source VM prerequisites

Source VMs across all migrations must meet the following prerequisites:

Media status

Unmount ISO images and CD-ROMs before migration.

IP addressing

Each network interface card (NIC) must contain either an IPv4 address or an IPv6 address, and can use both.

Operating system (OS) certification

The VM operating system must be certified and supported as a guest operating system for conversion.

Boot features

Virtual machines with Secure Boot enabled might not be migrated automatically, as this prevents them from booting on the destination provider. To resolve this, disable Secure Boot on the destination.

VMware guest agents

VMware Tools or open-vm-tools are required when Preserve static IPs is enabled.

VM naming

VM names must comply with these guidelines:

• The name of a VM must not contain a period (.). MTV automatically changes any period in a VM name to a dash (-).
• The VM name must be unique within the Red Hat OpenShift Virtualization environment (that is, it must not match any other VM name).
• If a VM name fails to comply with the rules, MTV automatically generates a new name. MTV removes excluded characters, converts uppercase letters to lowercase, and changes any underscore (_) to a dash (-).

Encryption support

MTV supports migrating VMs by using the following encryption types:

• Linux® VMs: Linux Unified Key Setup (LUKS).
• Windows® VMs: BitLocker.

VMware Tools

To use a pre-migration hook to access the virtual machine, install VMware Tools or open-vm-tools on the source virtual machine.

VDDK image

Use the VMware Virtual Disk Development Kit (VDDK) when you transfer virtual disks from VMware vSphere to accelerate migrations.

• A VDDK image is optional. However, omitting it can significantly decrease migration speeds, and it is required when the VM is backed by VMware vSAN.

VMware privileges

You must be logged in with at least the minimum set of required VMware privileges. For more information, see VMware privileges.

Warm migration requirement

To run a warm migration, you must enable changed block tracking (CBT) on the virtual machine (VM) and on each individual VM disk. The incremental copying during the precopy stage relies on CBT snapshots. A single VM supports up to 28 CBT snapshots.

Disable hibernation for all VMs because MTV does not support migrating hibernated VMs, and migration fails if hibernation is not disabled.

ESXi host configuration

If a migration plan requires migrating more than 10 VMs concurrently from a single ESXi (VMware vSphere hypervisor) host, increase the Network File Copy (NFC) service memory of that host.

• The NFC service memory defaults to supporting only 10 parallel connections, which is insufficient for more than 10 concurrent VM migrations.
• Change the maxMemory value to 1000000000 (1 GB) and restart the hostd service.

Windows warm migration

For warm migrations of Microsoft Windows® VMs from VMware, the Volume Shadow Copy Service (VSS) inside the guest VM must be running. For more information, see Source virtual machine prerequisites.

Add VMware vSphere source provider

1. Go to Migration for Virtualization > Providers and click Create provider.
2. Select VMware and specify the provider resource name and endpoint type (vCenter or ESXi).
3. Provide the URL of the SDK endpoint, for example, https://vCenter-host-example.com/sdk.
4. Create a VDDK image and specify its path. Using a VDDK image accelerates migrations and is required if VMs are backed by VMware vSAN.
5. Enter vCenter or ESXi credentials.
6. Choose a CA certificate validation option: Use a custom CA certificate, Use the system CA certificate, or Skip certificate validation.
7. Click Create provider.

Creating a migration plan

1. General: Define plan name, project, source provider, and target provider/project.

   • Start the wizard from Migration for Virtualization > Migration plans by clicking Create plan.
   • Specify the Plan name, Plan project, Source provider, Target provider, and Target project.

2. Virtual machines

   • Select the virtual machines to migrate.

   A single plan cannot contain more than 500 VMs or 500 disks.

3. Define the network map

   • Choose to use an existing, ownerless network map (which creates a copy that is attached to the plan), or use a new network map (owned by the plan).
   • If you are creating a new map, define the mappings between the source network and the target network.

4. Select the migration type

   • Select Cold migration (default) (VM is shut down during data copy) or Warm migration (VM runs during the precopy stage, minimizing downtime).

5. Other settings (optional)

   • Disk decryption passphrases: Enter passphrases for LUKS-encrypted devices.
   • Transfer network: Optionally override the provider's default transfer network. If the Red Hat OpenShift transfer network maximum transmission unit (MTU) is changed, the VMware migration network MTU must also be adjusted.
   • Preserve static IPs: Select the Preserve static IPs checkbox to attempt to preserve static IP addresses, mitigating loss due to vNIC changes during migration.
   • Root device: For multi-boot VMs, manually specify the disk location for the root device, for example, /dev/sdb2.
   • Shared disks: Shared disks are enabled by default for cold migrations. Shared disks use the multi-writer option and can slow down the migration process.
   • Select the Enable hook checkbox for pre-migration (operations on source VM before migration) or post-migration (operations on migrated VM after migration).
   • You must specify the hook runner image (default is quay.io/kubev2v/hook-runner) and provide the Ansible® playbook. Only one pre-migration and one post-migration hook are allowed per plan.
   • When you use Preserve static IPs and move to a Layer 2 primary user-defined network (UDN) or cluster user-defined network (CUDN), the source VM must be powered on and running a VMware Guest Agent. Preserve static IP does not work with secondary networks.

6. Review and create

   • Review all plan details. To edit any detail, use the Edit step link.
   • Click Create plan. MTV validates the plan. If validation is successful, the Plan details page opens.

Post-creation configuration

1. Review the Plan details page, especially for settings not in the wizard.

   • The Plan details page contains important settings not visible in the wizard.
   • Review the Plan settings section for optional configurations. To edit any setting, use the Options menu.
   • Check the Conditions section; all listed conditions must be resolved before the plan can run successfully.

Running and monitoring

1. Pre-migration activities

   • Before you start a warm migration, check for VM snapshots and commit/delete snapshots to ensure the VMs have enough available CBT snapshots.
   • Grant access for the default service account of the target namespace to pull the VDDK image from the Red Hat OpenShift MTV namespace.
   • Validate the migration plan and resolve any warnings or errors.
   • Take a full backup of the source VMs if needed.

2. Start migration

   • Go to Migration > Plans for virtualization.
   • Click Start next to the migration plan and confirm.
   • Disable vMotion, svMotion, and relocation for the VMs that you are importing to prevent data corruption.

3. Warm migration cutover

   • For warm migrations, the initial data transfer (precopy stage) begins immediately.
   • To initiate the cutover stage, which shuts down the source VM and transfers the final delta, click Cutover.
   • The cutover window allows you to Set cutover (schedule time and date) or Remove cutover (cancel a scheduled time).
   • Before cutover, stop applications, middleware, and database services on source VMs to minimize data changes. MTV does not require this action. However, stopping these services reduces the risk of data inconsistency during cutover.

4. Monitoring

   • The migration Status link displays overall progress, success/failure counts, and ongoing status.
   • The Virtual Machines tab provides specific VM status, start/end times, data copied, and a progress pipeline.
   • To access logs for running or completed migrations, select a VM on the Virtual Machines tab and click the Logs link in the Pods section.

5. Post-migration restriction

   • Do not take a snapshot of a VM after the migration starts, because this can cause the migration to fail.

6. Post-migration activities

   • Configure network settings and IP changes if required.
   • Configure role-based access control (RBAC) and service accounts for VM management.
   • Update Domain Name System (DNS) records if required.
   • Validate DNS resolution and network policies.
   • Start applications and databases on target VMs if they were stopped before cutover.
   • Verify application functionality on the migrated VMs.