Chapter 1. About the Migration Toolkit for Virtualization
The Migration Toolkit for Virtualization (MTV) enables you to migrate virtual machines from VMware vSphere to OpenShift Virtualization, an add-on to OpenShift Container Platform 4.7. With OpenShift Virtualization, you can run and manage virtual machine workloads alongside container workloads.
1.1. MTV custom resources and services
The Migration Toolkit for Virtualization (MTV) is provided as an OpenShift Container Platform Operator. It creates and manages the following custom resources (CRs) and services.
MTV custom resources
-
ProviderCR stores attributes that enable MTV to connect to and interact with the source and target providers. -
NetworkMappingCR maps the networks of the source and target providers. -
StorageMappingCR maps the storage of the source and target providers. -
ProvisionerCR stores the configuration of the storage provisioners, such as supported volume and access modes. -
PlanCR contains a list of VMs with the same migration parameters and associated network and storage mappings. MigrationCR runs a migration plan.Only one
MigrationCR per migration plan can run at a given time. You can create multipleMigrationCRs for a singlePlanCR.
MTV services
Provider Inventoryservice:- Connects to the source and target providers.
- Maintains a local inventory for mappings and plans.
- Stores VM configurations.
-
Runs the
Validationservice if a VM configuration change is detected.
-
Validationservice checks the suitability of a VM for migration by applying rules.
The Validation service is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.
User Interfaceservice:- Enables you to create and configure MTV CRs.
- Displays the status of the CRs and the progress of a migration.
Migration Controllerservice orchestrates migrations.When you create a migration plan, the Migration Controller service validates the plan and adds a status label. If the plan fails validation, the plan status is
Not readyand the plan cannot be used to perform a migration. If the plan passes validation, the plan status isReadyand it can be used to perform a migration. After a successful migration, the Migration Controller changes the plan status toCompleted.-
Virtual Machine Import Controller,Kubevirt Controller, andContainerized Data Import (CDI) Controllerservices handle most technical operations.
1.2. High-level migration workflow
The high-level workflow shows the migration process from the point of view of the user.
Figure 1.1. High-level workflow
The workflow describes the following steps:
- You create a source provider, a target provider, a network mapping, and a storage mapping.
You create a migration plan that includes the following resources:
- Source provider
- Target provider
- Network mapping
- Storage mapping
- One or more VMs
-
You run a migration plan by creating a
MigrationCR that references the migration plan. If a migration is incomplete, you can run a migration plan multiple times until all VMs are migrated. -
For each VM in the migration plan, the Migration Controller creates a
VirtualMachineImportCR and monitors its status. When all VMs have been migrated, the Migration Controller sets the status of the migration plan toCompleted. The power state of a source VM is maintained after migration.
1.3. Detailed migration workflow
You can use the detailed migration workflow to troubleshoot a failed migration.
Figure 1.2. Detailed OpenShift Virtualization migration workflow
The workflow describes the following steps:
-
When you run a migration plan, the Migration Controller creates a
VirtualMachineImportcustom resource (CR) for each source VM. -
The Virtual Machine Import Controller validates the
VirtualMachineImportCR and generates aVirtualMachineCR. The Virtual Machine Import Controller retrieves the VM configuration, including network, storage, and metadata, linked in the
VirtualMachineImportCR.For each VM disk:
-
The Virtual Machine Import Controller creates a
DataVolumeCR as a wrapper for a Persistent Volume Claim (PVC) and annotations. -
The Containerized Data Importer (CDI) Controller creates a PVC. The Persistent Volume (PV) is dynamically provisioned by the
StorageClassprovisioner. -
The CDI Controller creates an
Importerpod. The
Importerpod connects to the VM disk by using the VMware Virtual Disk Development Kit (VDDK) SDK and streams the VM disk to the PV.After the VM disks are transferred:
The Virtual Machine Import Controller creates a
Conversionpod with the PVCs attached to it.The
Conversionpod runsvirt-v2v, which installs and configures device drivers on the PVCs of the target VM.-
The Virtual Machine Import Controller creates a
VirtualMachineInstanceCR. When the target VM is powered on, the KubeVirt Controller creates a VM pod.
The VM pod runs
QEMU-KVMwith the PVCs attached as VM disks.
1.4. Storage support and default modes
The Migration Toolkit for Virtualization (MTV) supports OpenShift Virtualization storage features.
If the OpenShift Virtualization storage does not support dynamic provisioning, MTV applies the default settings, Filesystem volume mode and ReadWriteOnce access mode. Filesystem volume mode is slower than Block volume mode. ReadWriteOnce access mode does not enable live virtual machine migration.
MTV uses the following default volume and access modes.
| Provisioner | Volume mode | Access mode |
|---|---|---|
| kubernetes.io/aws-ebs | Block | ReadWriteOnce |
| kubernetes.io/azure-disk | Block | ReadWriteOnce |
| kubernetes.io/azure-file | Filesystem | ReadWriteMany |
| kubernetes.io/cinder | Block | ReadWriteOnce |
| kubernetes.io/gce-pd | Block | ReadWriteOnce |
| kubernetes.io/hostpath-provisioner | Filesystem | ReadWriteOnce |
| manila.csi.openstack.org | Filesystem | ReadWriteMany |
| openshift-storage.cephfs.csi.ceph.com | Filesystem | ReadWriteMany |
| openshift-storage.rbd.csi.ceph.com | Block | ReadWriteOnce |
| kubernetes.io/rbd | Block | ReadWriteOnce |
| kubernetes.io/vsphere-volume | Block | ReadWriteOnce |
1.5. Warm migration
The default migration type for the Migration Toolkit for Virtualization (MTV) is cold migration. During cold migration, the virtual machines (VMs) are shut down while the data is copied.
Warm migration copies most of the data during the precopy stage. Then the VMs are shut down and the remaining data is copied during the cutover stage.
Precopy stage
The VMs are not shut down during the precopy stage.
The VM disks are copied incrementally using changed block tracking (CBT) snapshots. The snapshots are created at one-hour intervals by default. You can change the snapshot interval by patching the vm-import-controller-config config map.
You must enable CBT on the source VMs and the VM disks.
A VM can support up to 28 CBT snapshots. If that limit is exceeded, a warm import retry limit reached error message is displayed. If the VM has preexisting CBT snapshots, it will reach this limit sooner.
The precopy stage runs until either the cutover stage starts or the maximum number of CBT snapshots is reached.
Cutover stage
The VMs are shut down during the cutover stage and the remaining data is migrated. Data stored in RAM is not migrated.
You can start the cutover stage manually in the MTV console.
You can schedule a cutover time from the CLI by specifying the value of the cutover parameter in the Migration CR manifest.
