When an organization decides to investigate a new hypervisor platform, such as Red Hat OpenShift Virtualization, the first question is usually how to migrate virtual machines from your existing infrastructure into OpenShift Virtualization. This is where Red Hat Migration Toolkit for Virtualization comes in. MTV is an OpenShift operator that adds migration functionality at scale and allows your organization to more quickly and easily migrate virtual machine workloads from vSphere, Red Hat Virtualization (RHV), Red Hat OpenStack Services on OpenShift, or other OpenShift Virtualization clusters.

Once your virtual machines are migrated to OpenShift Virtualization, your organization can reclaim the old hypervisor infrastructure and begin the process of containerizing the workloads that run in the virtual machines without ever needing to leave the OpenShift platform.

In this article, I'll walk through the steps to install the migration toolkit for virtualization, configure it for virtual machine migration from VMware vSphere, and then demonstrate the migration process. By the end of this article, you will have all of the information you need to successfully migrate your Linux and Windows workloads from vSphere to OpenShift Virtualization.

Install the migration toolkit for virtualization operator

The first step is to install the migration toolkit for virtualization on the cluster where you have already installed OpenShift Virtualization. You install the MTV operator from the Operator Hub, just like you would any other operator.

Search for MTV, and then click the corresponding operator tile. Click Install to proceed.

The MTV operator is installed in the openshift-mtv namespace, which is where you'll create all of your migration configurations later.

Once the operator is installed, you're prompted to create a Forklift Controller. This is the service responsible for running all of the migrations. Click the blue Create ForkliftController button, and then the Create button.

After some time, you see the ForkliftController status change to Condition: Running with a green check box.

After refreshing the Console, you see a new Migration tab in the left panel of the OpenShift Console.

Configure a Provider

Before you can migrate anything, you must create a Provider. A Provider is a hypervisor (such as vSphere) where the virtual machines are running, and that you want to migrate into OpenShift Virtualization. From the Migration navigation tab, click Providers for virtualization. A Provider called host already exists. This represents the OpenShift Virtualization cluster on which the MTV Operator is running, and it was created automatically when the Forklift Controller was created.

Click the blue Create Provider button to create a Provider for the vSphere cluster.

Although the Migration Toolkit for Virtualization is capable of migrating from Other OpenShift Virtualization clusters, Red Hat OpenStack, or Red Hat Virtualization clusters, I'm focusing on migration from vSphere, so select vSphere from the presented options.

At this point, you need some information about the vSphere cluster in order to configure the Provider.

• Provider resource name: This is a string of text for you to use so you know which vSphere cluster this configuration is for. In this example, there's only one vSphere cluster, so call it vsphere.
• Endpoint type: The configuration and migration process is the same whether you select vCenter or ESXi. However, selecting vCenter allows you to see all virtual machines in the cluster, whereas selecting ESXi only shows the virtual machines running on that ESXi server. The ESXi option might be useful if your intention is to migrate an entire host in order to reuse it as an OpenShift Virtualization compute node.
• URL: This is the DNS name or IP address of the vCenter server followed by /sdk and represents the endpoint for SDK access to the vCenter server.
• VDDK init image: The VMware Virtual Disk Development Kit (VDDK) init image is optional, but highly recommended, because it can greatly increase the speed of migration. This image is used by the MTV operator to inject VirtIO drivers into the guest operating system during migration. Because the creation of the VDDK image requires proprietary licenses from VMware, I'm omitting instructions for creating it, but Red Hat’s documentation for creating the VDDK image is very easy to follow.
• Username: This is a vCenter username that has access to all or a subset of virtual machines in the vSphere cluster. In this example, I'm using the vSphere Administrator account.
• Password: The password for the username above.
• Skip certificate validation: Enable this option for a vCenter server using self-signed certificates.
• CA certificate: Copy and paste the CA certificate in this field, or just press the Fetch certificate from URL button, and then accept the CA from the window that appears.
   

After clicking the Create provider button, the configuration is created and validated. After a few seconds, the Provider appears as Ready in the Console.

Creating a migration plan

Virtual machine migrations are performed in MTV with a migration plan, which is a configuration that includes a list of virtual machines to migrate, as well as mappings of networks and storage. The mappings are required because the MTV operator is not necessarily able to determine which vSphere networks and datastores should map to OpenShift Virtualization networks and StorageClasses.

After clicking the Create Plan button, you're presented with a window asking which source provider to use. Please note that although the local host cluster appears in this list, it's not possible to migrate a virtual machine from OpenShift Virtualization to vSphere using the MTV operator. In this example, I have only one valid source provider configured.

After selecting vSphere from the list, you're presented with a list of virtual machines that exist on that provider. It is possible to select multiple virtual machines at once, but for this example, I'm only selecting the virtual machine called rhel9-vm-01.

In the next window, give the migration plan a name, select the target namespace, and configure the network and storage mappings. The default Target namespace is set to openshift-mtv, which is almost surely not where you want the virtual machines to run after migration, so make sure to change this field to the appropriate namespace for your environment.

This simple example environment only has one vSphere network called VM Network, and it's going to get mapped to an external Multus network in the OpenShift Virtualization cluster. In this case, I've followed my previous article describing how to configure your OpenShift cluster to enable virtual machines to communicate directly on the external network. The selected vSphere network and the selected OpenShift Virtualization network are in the same VLAN in this case, so they share the same IP address space.

Similarly, this example environment only has one datastore, and that's going to map to an appropriate StorageClass in the OpenShift Virtualization environment.

Now that the migration plan has been created, some verification checks are run, and then the migration plan shows a status of Ready and a blue Start button.

Migrating virtual machines

Virtual machine migrations using the MTV operator always require some downtime of the virtual machine that is being migrated. The length of that outage depends on several factors, including:

• Change Block Tracking (CBT): If CBT is enabled in vSphere, then MTV can do a warm migration. The virtual machine data is copied while the guest OS is still running. Then the virtual machine is shutdown in vSphere and immediately started in OpenShift Virtualization. Without CBT, only cold migration is possible, which requires the virtual machine to be down during the entire migration process.
• VDDK image is available: If the VDDK image is available, then MTV is able to modify the target virtual machine image more efficiently.
• Network and disk speed: The speed of the underlying network and disks can also affect the migration speed, which affects the length of time a virtual machine is down during migration.

There are changes that happen inside the virtual machine that are a result of the move from one hypervisor to another. In addition to the installation of device drivers, the names of the network interfaces in the guest OS are likely to change. If no intervention is taken prior to migration, then the migrated virtual machine won't not be able to connect to the network. In this article, I provide options for mitigating this issue and ensuring a smooth migration of the guest OS network parameters.

Once you're ready to start the migration, click the Start button for the migration plan. If the virtual machines in the migration plan are still running in vSphere, they're shutdown automatically at this time. Once the virtual machines are migrated, OpenShift Virtualization only starts a migrated virtual machine that was running in vSphere. In other words, the running state of a migrated virtual machine is duplicated after migration is complete, so a virtual machine that's shut down in vSphere when the migration begins is still shut down in OpenShift Virtualization until it's manually started after the migration.

You can monitor the details of a migration by clicking the blue hyperlinked text in the Status column labeled Running. This provides you with a variety of statuses, such as the PersistentVolumeClaims in use for migration, and the pod responsible for the actual migration of the virtual machine data. In the image below, note the blue link labeled Logs, which displays the logs of the pod running the migration:

It's also possible to monitor the migration resources from the command-line interface. This example shows the status of the Pods, the DataVolume, and the PersistentVolumeClaim:

$ oc get pods,dv,pvc
NAME                                                READY   STATUS      RESTARTS   AGE
pod/migrate-rhel9-vm-01-vm-1001-nb95n               1/1     Running     0          17s
pod/vddk-validator-migrate-rhel9-vm-014wnpf-6sr5r   0/1     Completed   0          4m47s

NAME                                                           PHASE       PROGRESS   RESTARTS   AGE
datavolume.cdi.kubevirt.io/migrate-rhel9-vm-01-vm-1001-tbwhg   Succeeded   100.0%                40s

NAME                                                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                                   AGE
persistentvolumeclaim/migrate-rhel9-vm-01-vm-1001-tbwhg   Bound    pvc-2834ec68-489a-4a77-a5e4-960a6f48d7cf   16Gi       RWX            ocs-external-storagecluster-ceph-rbd           40s

After some time, the migration plan completes. The migration pod remains in a Completed state so  you can examine the logs after the migration has finished. The pod is deleted when the migration plan is archived.

Examining the migrated virtual machine

After the migration has completed, you can view the virtual machine in the target namespace you selected when you created the migration plan. In this case, that namespace was called vmtest.

When you log in to the migrated virtual machine, you can see that the network adapter is configured correctly, and that the virtual machine is able to communicate with the external network. The migration is complete!

For virtual machines running Windows, the process is identical. The Migration Toolkit for Virtualization takes care of adding the required VirtIO drivers to the WIndows disk image during migration so that the virtual machine boots correctly on the first try.

Post migration tasks

The MTV operator does not delete migrated virtual machines from vSphere. The migrated virtual machines exist in both hypervisors, so it's important that the old virtual machine in vSphere is not started at the same time as the new virtual machine in OpenShift Virtualization. Once the migrated virtual machine is released for use, you should delete the old virtual machine in vSphere.

In the event that the migration process fails, restart the virtual machine in vSphere, troubleshoot, and try the migration again. Unless you specify an Ansible Playbook to run prior to the migration, the MTV operator doesn't make any changes to the virtual machine in vSphere, so that virtual machine can be used as a backup in the event of an unsuccessful migration.

A toolkit for success

Migrating away from a hypervisor that may have been embedded in your environment for decades  to a new, innovative platform is a formidable task that should not be taken lightly. As this article has demonstrated, tools like Red Hat Migration Toolkit for Virtualization can make this complex challenge simpler and easier to automate.

For more information about OpenShift Virtualization, you can check out another blog post of mine about the topic,  have a look at the product on our website, and you can find more information about the Migration Toolkit for Virtualization on our website.