Chapter 2. Prerequisites

Review the following prerequisites to ensure that your environment is prepared for migration.

2.1. Software requirements

You must install compatible versions of OpenShift Container Platform and OpenShift Virtualization.

2.2. Storage support and default modes

MTV uses the following default volume and access modes for supported storage.

Note

If the OpenShift Virtualization storage does not support dynamic provisioning, you must apply the following settings:

  • Filesystem volume mode

    Filesystem volume mode is slower than Block volume mode.

  • ReadWriteOnce access mode

    ReadWriteOnce access mode does not support live virtual machine migration.

See Enabling a statically-provisioned storage class for details on editing the storage profile.

Note

If your migration uses block storage and persistent volumes created with an EXT4 file system, increase the file system overhead in CDI to be more than 10%. The default overhead that is assumed by CDI does not completely include the reserved place for the root partition. If you do not increase the file system overhead in CDI by this amount, your migration might fail.

Table 2.1. Default volume and access modes

ProvisionerVolume modeAccess 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

2.3. Network prerequisites

The following prerequisites apply to all migrations:

  • IP addresses, VLANs, and other network configuration settings must not be changed before or during migration. The MAC addresses of the virtual machines are preserved during migration.
  • The network connections between the source environment, the OpenShift Virtualization cluster, and the replication repository must be reliable and uninterrupted.
  • If you are mapping more than one source and destination network, you must create a network attachment definition for each additional destination network.

2.3.1. Ports

The firewalls must enable traffic over the following ports:

Table 2.2. Network ports required for migrating from VMware vSphere

PortProtocolSourceDestinationPurpose

443

TCP

OpenShift nodes

VMware vCenter

VMware provider inventory

Disk transfer authentication

443

TCP

OpenShift nodes

VMware ESXi hosts

Disk transfer authentication

902

TCP

OpenShift nodes

VMware ESXi hosts

Disk transfer data copy

Table 2.3. Network ports required for migrating from Red Hat Virtualization

PortProtocolSourceDestinationPurpose

443

TCP

OpenShift nodes

RHV Engine

RHV provider inventory

Disk transfer authentication

443

TCP

OpenShift nodes

RHV hosts

Disk transfer authentication

54322

TCP

OpenShift nodes

RHV hosts

Disk transfer data copy

2.4. Source virtual machine prerequisites

The following prerequisites apply to all migrations:

  • ISO/CDROM disks must be unmounted.
  • Each NIC must contain one IPv4 and/or one IPv6 address.
  • 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.
  • VM names must contain only lowercase letters (a-z), numbers (0-9), or hyphens (-), up to a maximum of 253 characters. The first and last characters must be alphanumeric. The name must not contain uppercase letters, spaces, periods (.), or special characters.

  • VM names must not duplicate the name of a VM in the OpenShift Virtualization environment.

    Note

    Migration Toolkit for Virtualization automatically assigns a new name to a VM that does not comply with the rules.

    Migration Toolkit for Virtualization makes the following changes when it automatically generates a new VM name:

    • Excluded characters are removed.
    • Uppercase letters are switched to lowercase letters.
    • Any underscore (_) is changed to a dash (-).

    This feature allows a migration to proceed smoothly even if someone entered a VM name that does not follow the rules.

2.5. Red Hat Virtualization prerequisites

The following prerequisites apply to Red Hat Virtualization migrations:

  • You must use a compatible version of Red Hat Virtualization.

  • You must have the CA certificate of the Manager.

    You can obtain the CA certificate by navigating to https://<engine_host>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA in a browser. If the Manager Apache CA certificate was replaced with a third-party CA certificate, you must have both the Manager Apache CA certificate and Manager CA certificate.

2.6. 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).
  • 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.
Note

Neither Migration Toolkit for Virtualization (MTV) nor OpenShift Virtualization support conversion of Btrfs for migrating VMs from VMWare.

VMware privileges

The following minimal set of VMware privileges is required to migrate virtual machines to OpenShift Virtualization with the Migration Toolkit for Virtualization (MTV).

Table 2.4. VMware privileges

PrivilegeDescription

Virtual machine.Interaction privileges:

Virtual machine.Interaction.Power Off

Allows powering off a powered-on virtual machine. This operation powers down the guest operating system.

Virtual machine.Interaction.Power On

Allows powering on a powered-off virtual machine and resuming a suspended virtual machine.

Virtual machine.Provisioning privileges:

Note

All Virtual machine.Provisioning privileges are required.

Virtual machine.Provisioning.Allow disk access

Allows opening a disk on a virtual machine for random read and write access. Used mostly for remote disk mounting.

Virtual machine.Provisioning.Allow file access

Allows operations on files associated with a virtual machine, including VMX, disks, logs, and NVRAM.

Virtual machine.Provisioning.Allow read-only disk access

Allows opening a disk on a virtual machine for random read access. Used mostly for remote disk mounting.

Virtual machine.Provisioning.Allow virtual machine download

Allows read operations on files associated with a virtual machine, including VMX, disks, logs, and NVRAM.

Virtual machine.Provisioning.Allow virtual machine files upload

Allows write operations on files associated with a virtual machine, including VMX, disks, logs, and NVRAM.

Virtual machine.Provisioning.Clone template

Allows cloning of a template.

Virtual machine.Provisioning.Clone virtual machine

Allows cloning of an existing virtual machine and allocation of resources.

Virtual machine.Provisioning.Create template from virtual machine

Allows creation of a new template from a virtual machine.

Virtual machine.Provisioning.Customize guest

Allows customization of a virtual machine’s guest operating system without moving the virtual machine.

Virtual machine.Provisioning.Deploy template

Allows deployment of a virtual machine from a template.

Virtual machine.Provisioning.Mark as template

Allows marking an existing powered-off virtual machine as a template.

Virtual machine.Provisioning.Mark as virtual machine

Allows marking an existing template as a virtual machine.

Virtual machine.Provisioning.Modify customization specification

Allows creation, modification, or deletion of customization specifications.

Virtual machine.Provisioning.Promote disks

Allows promote operations on a virtual machine’s disks.

Virtual machine.Provisioning.Read customization specifications

Allows reading a customization specification.

Virtual machine.Snapshot management privileges:

Virtual machine.Snapshot management.Create snapshot

Allows creation of a snapshot from the virtual machine’s current state.

Virtual machine.Snapshot management.Remove Snapshot

Allows removal of a snapshot from the snapshot history.

2.6.1. Creating a VDDK image

The Migration Toolkit for Virtualization (MTV) uses the VMware Virtual Disk Development Kit (VDDK) SDK to transfer virtual disks from VMware vSphere.

You must download the VMware Virtual Disk Development Kit (VDDK), build a VDDK image, and push the VDDK image to your image registry. You need the VDDK init image path in order to add a VMware source provider.

Note

Storing the VDDK image in a public registry might violate the VMware license terms.

Prerequisites

Procedure

  1. Create and navigate to a temporary directory: 

    $ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>
  2. In a browser, navigate to the VMware VDDK version 7 download page.
  3. Select version 7.0.3.2 and click Download.
  4. Save the VDDK archive file in the temporary directory.

  5. Extract the VDDK archive: 

    $ tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz

  6. Create a Dockerfile: 

    $ cat > Dockerfile <<EOF
FROM registry.access.redhat.com/ubi8/ubi-minimal
USER 1001
COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib
RUN mkdir -p /opt
ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"]
EOF

  7. Build the VDDK image: 

    $ podman build . -t <registry_route_or_server_path>/vddk:<tag>

  8. Push the VDDK image to the registry: 

    $ podman push <registry_route_or_server_path>/vddk:<tag>
  9. Ensure that the image is accessible to your OpenShift Virtualization environment.

2.6.2. Obtaining the SHA-1 fingerprint of a vCenter host

You must obtain the SHA-1 fingerprint of a vCenter host in order to create a Secret CR.

Procedure

  • Run the following command: 

    $ openssl s_client \
    -connect <vcenter_host>:443 \ 1
    < /dev/null 2>/dev/null \
    | openssl x509 -fingerprint -noout -in /dev/stdin \
    | cut -d '=' -f 2
    1
    Specify the IP address or FQDN of the vCenter host.

    Example output

    01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67

2.6.3. Increasing the NFC service memory of an ESXi 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. Otherwise,the migration will fail because the NFC service memory is limited to 10 parallel connections.

Procedure

  1. Log in to the ESXi host as root.

  2. Change the value of maxMemory to 1000000000 in /etc/vmware/hostd/config.xml: 

    ...
      <nfcsvc>
         <path>libnfcsvc.so</path>
         <enabled>true</enabled>
         <maxMemory>1000000000</maxMemory>
         <maxStreamMemory>10485760</maxStreamMemory>
      </nfcsvc>
...

  3. Restart hostd: 

    # /etc/init.d/hostd restart

    You do not need to reboot the host.

2.7. Software compatibility guidelines

You must install compatible software versions.

Table 2.5. Compatible software versions

Migration Toolkit for VirtualizationOpenShift Container PlatformOpenShift VirtualizationVMware vSphereRed Hat Virtualization

2.3.3

4.10 or later

4.10 or later

6.5 or later

4.4.9 or later