Download Virt v2v

Logs and custom resources You can download logs and custom resource (CR) information for troubleshooting. For more information, see the detailed migration workflow. 9.4.1. Collected logs and custom resource information You can download logs and custom resource (CR) yaml files for the following targets by using the Red Hat OpenShift web console or the command line interface (CLI): Migration plan: Web console or CLI. Virtual machine: Web console or CLI. Namespace: CLI only. The must-gather tool collects the following logs and CR files in an archive file: CRs: DataVolume CR: Represents a disk mounted on a migrated VM. VirtualMachine CR: Represents a migrated VM. Plan CR: Defines the VMs and storage and network mapping. Job CR: Optional: Represents a pre-migration hook, a post-migration hook, or both. Logs: importer pod: Disk-to-data-volume conversion log. The importer pod naming convention is importer--, for example, importer-mig-plan-ed90dfc6-9a17-4a8btnfh, where ed90dfc6-9a17-4a8 is a truncated RHV VM ID and btnfh is the generated 5-character ID. conversion pod: VM conversion log. The conversion pod runs virt-v2v, which installs and configures device drivers on the PVCs of the VM. The conversion pod naming convention is -. virt-launcher pod: VM launcher log. When a migrated VM is powered on, the virt-launcher pod runs QEMU-KVM with the PVCs attached as VM disks. forklift-controller pod: The log is filtered for the migration plan, virtual machine, or namespace specified by the must-gather command. forklift-must-gather-api pod: The log is filtered for the migration plan, virtual machine, or namespace specified by the must-gather command. hook-job pod:

CR for each source virtual machine (VM), connected to the PVCs. If the VM ran on the source environment, the Migration Controller powers on the VM, the KubeVirt Controller service creates a virt-launcher pod and a VirtualMachineInstance CR. The virt-launcher pod runs QEMU-KVM with the PVCs attached as VM disks. Cold migration from VMWare to the local OpenShift cluster: When you create a Migration custom resource (CR) to run a migration plan, the Migration Controller service creates a DataVolume CR for each source VM disk. For each VM disk: The Containerized Data Importer (CDI) Controller service creates a blank persistent volume claim (PVC) based on the parameters specified in the DataVolume CR. If the StorageClass has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by the StorageClass provisioner. For all VM disks: The Migration Controller service creates a dummy pod to bind all PVCs. The name of the pod contains pvcinit. The Migration Controller service creates a conversion pod for all PVCs. The conversion pod runs virt-v2v, which converts the VM to the KVM hypervisor and transfers the disks' data to their corresponding PVs. After the VM disks are transferred: The Migration Controller service creates a VirtualMachine CR for each source virtual machine (VM), connected to the PVCs. If the VM ran on the source environment, the Migration Controller powers on the VM, the KubeVirt Controller service creates a virt-launcher pod and a VirtualMachineInstance CR. The virt-launcher pod runs QEMU-KVM with the PVCs attached as VM disks. 9.4.

VM disks are transferred: The Migration Controller service creates a conversion pod with the PVCs attached to it when importing from VMWare. The conversion pod runs virt-v2v, which installs and configures device drivers on the PVCs of the target VM. The Migration Controller service creates a VirtualMachine CR for each source virtual machine (VM), connected to the PVCs. If the VM ran on the source environment, the Migration Controller powers on the VM, the KubeVirt Controller service creates a virt-launcher pod and a VirtualMachineInstance CR. The virt-launcher pod runs QEMU-KVM with the PVCs attached as VM disks. Cold migration from RHV or OpenStack to the local OpenShift cluster: When you create a Migration custom resource (CR) to run a migration plan, the Migration Controller service creates for each source VM disk a PersistentVolumeClaim CR, and an OvirtVolumePopulator when the source is RHV, or an OpenstackVolumePopulator CR when the source is OpenStack. For each VM disk: The Populator Controller service creates a temporarily persistent volume claim (PVC). If the StorageClass has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by the StorageClass provisioner. The Migration Controller service creates a dummy pod to bind all PVCs. The name of the pod contains pvcinit. The Populator Controller service creates a populator pod. The populator pod transfers the disk data to the PV. After the VM disks are transferred: The temporary PVC is deleted, and the initial PVC points to the PV with the data. The Migration Controller service creates a VirtualMachine

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 Migration using OpenStack source providers only supports VMs that use only Cinder volumes. 2.7. VMware prerequisites The following prerequisites apply to VMware migrations: You must use a compatible version of VMware vSphere. You must be logged in as a user with at least the minimal set of VMware privileges. You must install VMware Tools on all source virtual machines (VMs). The VM operating system must be certified and supported for use as a guest operating system with OpenShift Virtualization and for conversion to KVM with virt-v2v. If you are running a warm migration, you must enable changed block tracking (CBT) on the VMs and on the VM disks. You must create a VMware Virtual Disk Development Kit (VDDK) image. You must obtain the SHA-1 fingerprint of the vCenter host. If you are migrating more than 10 VMs from an ESXi host in the same migration plan, you must increase the NFC service memory of the host. It is strongly recommended to disable hibernation because Migration Toolkit for Virtualization (MTV) does not support migrating hibernated VMs. In the event of a power outage, data might be lost for a VM with disabled