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
orESXi
. However, selectingvCenter
allows you to see all virtual machines in the cluster, whereas selectingESXi
only shows the virtual machines running on thatESXi
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.
Sull'autore
Matthew Secaur is a Red Hat Senior Technical Account Manager (TAM) for Canada and the Northeast United States. He has expertise in Red Hat OpenShift Platform, Red Hat OpenStack Platform, and Red Hat Ceph Storage.
Altri risultati simili a questo
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit