Infrastructure Migration Solution Guide

Red Hat Infrastructure Migration Solution 1.1

Migrating from VMware to Red Hat Virtualization or Red Hat OpenStack Platform

Red Hat IMS Documentation Team

Abstract

This guide describes how to plan, perform, and troubleshoot an infrastructure migration from VMware to Red Hat Virtualization or Red Hat OpenStack Platform. The migration is performed with Red Hat CloudForms.

Chapter 1. Infrastructure Migration Solution overview

The Red Hat Infrastructure Migration Solution (IMS) enables you to migrate virtual machines from VMware 5.5 (and later) to the following target environments:

  • Red Hat Virtualization 4.2

    Red Hat Virtualization (RHV) is a virtualization platform built on Red Hat Enterprise Linux. You can manage your virtual infrastructure, including hosts, virtual machines, networks, storage, and users, from a centralized graphical user interface or with a REST API (for more information, see the Red Hat Virtualization documentation).

  • Red Hat OpenStack Platform 13 or 14

    Red Hat OpenStack Platform enables you to create a scaleable, fault-tolerant, private or public cloud based on Red Hat Enterprise Linux (for more information, see the Red Hat OpenStack Platform documentation).

The migration process is performed with CloudForms 4.7, a user interface for managing the infrastructure (for more information, see the Red Hat CloudForms documentation).

The migration process has the following key steps:

1.1. Red Hat Virtualization migration workflow

This diagram describes the workflow of a migration to Red Hat Virtualization.

Figure 1.1. VMware to Red Hat Virtualization migration workflow

vmware to rhv migration workflow

25 You create and run a migration plan in CloudForms.

25 CloudForms uses the migration plan to locate the source virtual machines.

25 If you are using VDDK transformation, CloudForms captures the ESXi host fingerprint for authentication during the virtual machine conversion process.

25 Using the attributes defined for the Red Hat Virtualization environment, CloudForms initiates communication with the conversion hosts (RHV host with virt-v2v and virt-v2v-wrapper installed)

25 virt-v2v-wrapper connects to the source datastore through the ESXi host. virt-v2v streams the source disks to the target data domain and converts the source disks.

25 virt-v2v-wrapper creates a target RHV virtual machine, using the source virtual machine’s metadata in order to maintain its attributes (tags, power state, MAC address, CPU count, memory, disks, and virtual machine name) after migration.

25 virt-v2v attaches the converted disks to the RHV virtual machine. (The RHV virtual machine’s power state is identical to the source virtual machine’s premigration state.)

The migration process is complete and the migration plan’s status is displayed in CloudForms.

1.2. Red Hat OpenStack Platform migration workflow

This diagram describes the workflow of a migration to OpenStack Platform.

Figure 1.2. VMware to OpenStack Platform migration workflow

vmware to osp migration workflow

25 You create and run a migration plan in CloudForms.

25 CloudForms uses the migration plan to locate the source virtual machines.

25 If you are using VDDK transformation, CloudForms captures the ESXi host fingerprint for authentication during the virtual machine conversion process.

25 Using the attributes defined for the OpenStack Platform environment, CloudForms initiates communication with the conversion hosts (OpenStack Platform instance created from a conversion host appliance, with virt-v2v and virt-v2v-wrapper installed)

25 virt-v2v-wrapper connects to the source datastore through the ESXi host. virt-v2v streams the source disks to the target data domain and converts the source disks.

25 After the source disks are converted, virt-v2v detaches the volumes from the conversion host, migrates the volumes to the destination project, and creates the network ports defined in the infrastructure mapping.

25 virt-v2v-wrapper creates the target OpenStack Platform instance with the flavor and security group defined in the migration plan. virt-v2v attaches the newly created network ports and the disks mapped in the block storage to the instance and the instance is powered on.

The migration process is complete and the migration plan’s status is displayed in CloudForms.

Chapter 2. Planning the migration

During the planning phase, you will formulate a specific migration goal, for example, "I want to migrate 2000 virtual machines, with 200 TB of data, in less than 6 months".

The following information can help you plan your migration:

2.1. Questions to ask before migration

The following questions can help you to estimate the resources and time required for migration:

What am I migrating?
  • Identify the hosts and virtual machines to be migrated.
What is the maximum number of disks, virtual machines, or NICs that I can migrate?
  • There is no maximum number of disks or virtual machines that you can migrate. However, you may not want to migrate all your virtual machines at the same time, in order to minimize the impact on your users.
  • You can migrate a maximum of four NICs with each virtual machine.

    Important

    If you exceed the capabilities of your environment, the migrations will fail. This situation could affect existing applications running on virtual machines attached to the network and storage.

What operating systems can I migrate?
What resources does my target environment require?
  • Your target environment must be large enough to run the migrated virtual machines in addition to the source virtual machines. The source virtual machines are not affected by the migration process.
What am I missing?
  • Identify resource gaps, such as bandwidth, storage, licenses, or a suitable maintenance window.
What impact will the migration have on my users?
  • Assess the effects the migration may have on a production environment.

    It may be possible to migrate your applications in phases, without downtime at the application layer, if the applications are distributed in a high-availability architecture.

  • Check whether users will lose access to critical applications.

2.1.1. How long will the migration take?

There are no specific rules to determine how long the actual migration will take. This is determined on a case-by-case basis.

The following migration examples are provided as a guide.

Example 2.1. Red Hat Virtualization migration

  • Duration of migration: 1:15:53 (hh:mm:ss)
  • 10 virtual machines
  • Total data migrated, using VDDK: 1000 GB
  • Hardware:

    • Strong host (40 cores, 500 GB RAM)
    • Fast SSD XtremIO storage
    • Fibre Channel 8 interface for host-to-storage connection
    • 10 GbE network interface cards for all other connections

Example 2.2. OpenStack Platform migration

2.1.2. How many conversion hosts do I need?

The number of conversion hosts you create depends on the size of your migration. All the virtual machines in the migration plan are migrated at the same time, in parallel. The number of virtual machines that you can migrate simultaneously depends on your infrastructure capabilities. Each migration requires a certain amount of network bandwidth, I/O throughput, and processing power for the conversion process.

Multiple conversion hosts provide load-balancing and better performance, even for small migrations.

Conversion hosts and providers are limited to ten concurrent migrations, unless you change the default maximum number of concurrent migrations (see Section 4.3, “Changing the maximum number of concurrent migrations”).

Test your environment thoroughly before the migration to determine how many migrations it can support without negative effects, for example, five conversion hosts, each running ten concurrent migrations.

2.1.3. Which transformation method, VDDK or SSH?

You will configure the conversion hosts to use either the VMware Virtual Disk Development kit (VDDK) or SSH as the transformation method for converting the virtual machines. The choice is determined by the number of virtual machines you are migrating and the capabilities of your infrastructure.

The following table compares the options.

Table 2.1. VDDK and SSH comparison

 ProsCons

VDDK

  • Recommended because it is approximately twice as fast as SSH
  • Compiled with nbdkit, which provides direct connectivity to the virtual machine disks
  • Requires VDDK package download
  • Requires VDDK library location for configuring the conversion hosts

SSH

  • Better suited for large-scale migrations than VDDK
  • Does not require additional downloads, packages, tools, or compilation
  • Slower than VDDK
  • Requires the VMware hypervisors to have SSH access enabled
  • Requires shared SSH keys for the source and target environments

2.2. Recommendations for migration

The following recommendations will minimize the impact of the migration on your environment.

Checking your resources

  • Ensure that you have sufficient space for the migration. The migration process does not delete the original virtual machines.
  • Plan for redundancy.

Scheduling the migration

  • Schedule your migration carefully, to minimize the impact on your users.
  • Prepare your users for downtime.

    Important

    Currently, IMS supports only cold migration. Virtual machines are powered off gracefully as part of the migration process.

  • Stagger the migration schedules.
  • Move critical applications during maintenance windows.

Distributing the migration workload

  • Create migration groups, so that you are not migrating all of your virtual machines at the same time, keeping in mind the following considerations:

    • How are the virtual machines grouped now?
    • Which virtual machines should be migrated together?
    • Which workloads or linked applications should be migrated together?
    • What applications must remain available?
  • Consider which parts of the workload to migrate first:

    • Databases
    • Applications
    • Web servers
    • Load balancers

Deploying conversion hosts

Controlling the migration process

Chapter 3. Preparing the environment for migration

Preparing the environment for migration involves the following key steps:

  1. Preparing the source environment, by extending the network and checking the virtual machines
  2. Preparing the target environment, by configuring the storage and networks, installing software, and configuring CloudForms:

  3. Configuring the conversion hosts for VDDK or SSH

    Optionally, you can change the maximum number of concurrent migrations for better performance and control of the migration process.

3.1. Preparing the source environment

To prepare the source environment:

  1. Extend the VMware network to the target environment.

    Important
    • The network configuration must not be changed in any way during the migration.
    • IP addresses, VLANs, and other network configurations should not be changed before or after migration because the conversion process preserves the source virtual machine MAC addresses.
  2. Prepare the source virtual machines.
  3. If you are using SSH transformation, configure the VMware hypervisors.

Preparing the source virtual machines

Prepare each source virtual machine for migration:

  • Install VMware Tools to capture IP addresses. For download and installation instructions, navigate to https://www.vmware.com/support/ws5/doc/new_guest_tools_ws.html.
  • Unmount mounted ISO/CDROM disks.
  • Ensure that attached disks are not encrypted.
  • Ensure that each NIC has no more than one IPv4 and/or one IPv6 address.
  • Ensure that the virtual machine names contain only upper- or lower-case letters, numbers, underscores (_), hyphens (-), or periods (.).

    Note

    International characters and spaces are not permitted.

  • Red Hat Virtualization only: Ensure that source virtual machine names do not duplicate the names of existing RHV virtual machines.

Configuring the VMware hypervisors for SSH transformation

SSH transformation requires passwordless access to the VMware hypervisors. Passwordless access involves enabling SSH access on the VMware hypervisors, generating an SSH key pair, and copying the public key to the VMware hypervisors. You will use the private key of the SSH key pair in Section 3.3, “Configuring the conversion hosts for VDDK or SSH”.

Using a single SSH key pair for all conversion hosts is recommended because the key pair is used only for virtual machine conversion and simplifies conversion host management. If you wish to use a dedicated SSH key pair for each conversion host, you can create multiple key pairs and copy all the public keys to all the VMware hypervisors.

Configure the VMware hypervisors:

  1. Enable SSH access on each VMware hypervisor. For instructions, navigate to https://docs.vmware.com/en/VMware-vSphere/index.html. In the navigation pane, click vSphere versionESXi and vCenter ServerVMware ESXi Installation and SetupInstalling and Setting Up ESXiSetting Up ESXiEnable ESXi Shell and SSH Access with the Direct Console User Interface.

    Note

    If your security processes allow you to collect the VMware hypervisors' public keys, save them for Section 3.3, “Configuring the conversion hosts for VDDK or SSH”.

  2. Generate an SSH key pair.
  3. Copy the public key to all the VMware hypervisors in /etc/ssh/keys-root/authorized_keys.

You are ready to prepare the target environment.

3.2. Preparing the target environment

Prepare your target environment for migration:

3.2.1. Preparing the Red Hat Virtualization environment

Prerequisites

The following prerequisites apply:

  • Compatible software versions

    Table 3.1. Software compatibility matrix

    SoftwareIMS 1.0IMS 1.1

    VMware

    5.5 or later

    5.5 or later

    Red Hat Virtualization

    4.2.7

    4.2.8

    CloudForms

    4.6

    4.7

    OpenStack Platform

    N/A

    13 or later

  • BIOS settings of physical hosts adjusted for optimal performance (rather than power-saving), according to the vendor’s recommendations
  • C1E halt state disabled, if applicable

Installing and configuring Red Hat Virtualization

  1. Install Red Hat Virtualization Manager 4.2 on the Manager machine (see Installing the Red Hat Virtualization Manager in the Red Hat Virtualization Installation Guide).
  2. Install Red Hat Virtualization Host 4.2 or Red Hat Enterprise Linux 7.6 on physical machines (see Installing Red Hat Virtualization Host or Installing Red Hat Enterprise Linux Hosts in the Red Hat Virtualization Installation Guide).

    Note

    Some of these hosts will be deployed as conversion hosts. The number of conversion hosts depends on your migration size and infrastructure capabilities. See Section 2.1.2, “How many conversion hosts do I need?” for details.

  3. Enable the following ports in the conversion host network (see https://access.redhat.com/articles/417343):

    • 22 - SSH
    • 443 - CloudForms, Red Hat Virtualization Manager, and VDDK
    • 902 - CloudForms to VMware
    • 5480 - virt-v2v to vCenter
  4. Create and attach data and ISO storage domains to the data center, ensuring that the data domain has sufficient space for the migrated virtual machines (see Storage in the Red Hat Virtualization Administration Guide).

    Note

    IMS only supports shared storage, such as NFS, iSCSI, or FCP. Local storage is not supported.

  5. Upload the VirtIO and Guest Tool image files to the ISO storage domain (see Uploading the VirtIO and Guest Tool Image Files to an ISO Storage Domain in the Red Hat Virtualization Administration Guide).

    The VirtIO file name must include the version number: virtio-win-version.iso. The Guest Tool is required for migrating Windows virtual machines.

  6. If you are using SSSD with single sign-on, reinstall ipa-client without configuring the OpenSSH client:

    # ipa-client-install --uninstall
    # ipa-client-install --no-ssh

    Otherwise, SSH will fail for the vdsm user (see https://bugzilla.redhat.com/show_bug.cgi?id=1544379). This issue cannot be resolved by modifying the configuration file because the file is restored during upgrades.

Installing and configuring CloudForms

  1. Install Red Hat CloudForms 4.7 on the Manager machine (see Installing Red Hat CloudForms on Red Hat Virtualization).
  2. Add VMware and Red Hat Virtualization as providers (see Adding a VMware vCenter Provider and Adding a Red Hat Virtualization Provider in Red Hat CloudForms: Managing Providers) .

    Note

    Removing or changing a provider, including refreshing hosts, before, during, or after the migration will cause errors in the infrastructure mappings and migration plans.

    You are ready to configure the conversion hosts for VDDK or SSH.

3.2.2. Preparing the OpenStack Platform environment

Prerequisites

The following prerequisites apply:

  • Compatible software versions

    Table 3.2. Software compatibility matrix

    SoftwareIMS 1.0IMS 1.1

    VMware

    5.5 or later

    5.5 or later

    Red Hat Virtualization

    4.2.7

    4.2.8

    CloudForms

    4.6

    4.7

    OpenStack Platform

    N/A

    13 or later

  • BIOS settings of physical hosts adjusted for optimal performance (rather than power-saving), according to the vendor’s recommendations
  • C1E halt state disabled, if applicable

Installing and configuring OpenStack Platform

  1. Install Red Hat OpenStack Platform 13 or 14 (see Red Hat OpenStack Platform Director Installation and Usage).
  2. Create provider networks for the target instances to preserve the IP addresses of the source virtual machines (see Create a network in the Red Hat OpenStack Platform Networking Guide).
  3. Create a project for the conversion hosts and whatever destination projects you require for the target instances (see Create a Project in the Red Hat OpenStack Platform Users and Identity Management Guide).
  4. Ensure that the admin user has member and admin roles in the conversion and destination projects (see Edit a Project in the Red Hat OpenStack Platform Users and Identity Management Guide).
  5. Set at least one volume type for the target block storage (see Create a Volume and Changing a Volume’s Type (Volume Re-typing) in the Red Hat OpenStack Platform Storage Guide). Otherwise, CloudForms cannot detect the storage when you create the infrastructure mapping.
  6. Ensure that the storage backends have sufficient space for the migrated virtual machines.

    Important

    If you are using Ceph storage, you will require three times the space of the source virtual machines for the migrated virtual machines. Ceph, by default, creates two replicas of an object, for a total of three copies (see Get the Number of Object Replicas in the Red Hat Ceph Storage: Storage Strategies Guide).

    The migrated virtual machines use all of the space because it is preallocated. For example, if you migrate a virtual machine with a 100 GB disk, you will require 300 GB of Ceph storage, regardless of how much data is on the disk.

    You can use the ftrim command on the migrated virtual machines to reduce the space required, as a postmigration task or playbook.

  7. Configure security groups with the following ports enabled:

    • For the conversion hosts and CloudForms: port 22 (SSH)
    • For CloudForms: port 443 (HTTPS)

      Note

      Outbound traffic is enabled by default. If you have changed this setting, enable ports 902 (CloudForms to VMware) and 5480 (virt-v2v to vCenter).

  8. Create flavors for the source virtual machines. If you do not create custom flavors, CloudForms will try to map each source virtual machine to an existing flavor.

Installing and configuring CloudForms

  1. Install Red Hat CloudForms 4.7 (see Installing Red Hat CloudForms on Red Hat OpenStack Platform).
  2. Add VMware and OpenStack Platform as providers (see Adding a VMware vCenter Provider and Adding an OpenStack Infrastructure Provider in Red Hat CloudForms: Managing Providers).

    Note

    Removing or changing a provider before, during, or after the migration will cause errors in the infrastructure mappings and migration plans.

Deploying OpenStack Platform conversion hosts

You download the conversion host appliance and use it to deploy the conversion host instances. The number of conversion hosts you deploy depends on your migration size and infrastructure capabilities. See Section 2.1.2, “How many conversion hosts do I need?” for details.

  1. Navigate to https://access.redhat.com/downloads/.
  2. In the A-Z tab, click Red Hat OpenStack Platform.
  3. Click the green Download Latest button to go to the OpenStack Platform download page.
  4. Click the Product Software tab and download the RHOSP V2V Image for Red Hat OpenStack Director (x86_64).

    Important

    Always download the latest version of the OpenStack Platform conversion appliance because it contains patches and fixes. The OpenStack Platform 14 conversion appliance can be used with both OpenStack Platform 13 and 14.

  5. Upload the appliance to Glance storage.
  6. Deploy the appliance as a conversion host instance, with the following resources:

    • 4 vCPUs
    • 1 GB RAM for each concurrent migration, starting at 10 GB RAM (the default maximum number of concurrent migrations per conversion host is 10). If you raise the number of concurrent migrations, you should increase the RAM accordingly. If you lower the number of concurrent conversions, you should not go below 8 GB RAM.
    • /tmp (1 GB for each concurrent migration)
    • /var/tmp (1 GB for each concurrent migration)
    • /var/logs (5 GB)

      Note

      For optimal performance:

  7. Increase the disk space of the instance to accommodate its file system.

    The instance is created from an image, but the disk space defined in the image will not be sufficient. You can either extend the partition, and subsequently extend the PV in the VG, to the required size, or you can create a new partition and add it as a PV to the VG.

    Note

    You must resize lv_root to use all available disk space because the image will not use it by default.

You are ready to configure the conversion hosts for VDDK or SSH.

3.3. Configuring the conversion hosts for VDDK or SSH

Configure the conversion hosts for VDDK or SSH transformation:

3.3.1. Configuring the Red Hat Virtualization conversion hosts

Configuring the Red Hat Virtualization conversion hosts for VDDK or SSH transformation involves the following steps:

  1. VDDK only: Downloading the VMware Virtual Disk Development kit
  2. Configuring the conversion hosts:

    1. Installing the ovirt-ansible-v2v-conversion-host package
    2. Creating the extra_vars.yml and secure_vars.yml files
    3. Configuring the conversion host with the conversion_host_enable playbook
    4. Verifying the configuration with the conversion_host_check playbook
    5. SSH only: Copying the VMware keys to the conversion hosts
    6. SSH only: Configuring secure remote login to the VMware hypervisors
  3. Authenticating the conversion hosts in CloudForms
  4. (Optional) Verifying the name and number of conversion hosts in a browser
Important

If you upgrade the target environment, you should upgrade the conversion hosts so that you have the latest software and critical updates:

  1. Log in to the Manager machine using SSH.
  2. Run the following command:

    # yum update

Prerequisite

  • VDDK only: Download the VMware Virtual Disk Development kit:

    1. Navigate to https://www.vmware.com/support/pubs/.
    2. Click VMware SDK & API Product Documentation to expand.
    3. Click VMware Virtual Disk Development Kit (VDDK).
    4. Click Latest Releases and select the latest VDDK release.
    5. Download and save the VDDK package (VMware-vix-disklib-version.x86_64.tar.gz), recording its URL.

Procedure

Perform the following procedure on the Manager machine:

  1. Install the ovirt-ansible-v2v-conversion-host package:

    # yum install ovirt-ansible-v2v-conversion-host
  2. Create an extra_vars.yml file and update its parameters:

    ---
    v2v_host_type: rhevm
    
    # Transport methods to configure on the conversion host. Valid values: `vddk`, `ssh`
    v2v_transport_methods:
      - vddk
    
    # Maximum number of concurrent conversions per host. Default is `10`.
    v2v_max_concurrent_conversions: 10
    
    # File name of VDDK package
    v2v_vddk_package_name: "VMware-vix-disklib-version.x86_64.tar.gz"
    
    # URL of VDDK package
    v2v_vddk_package_url: "http://path_to_vddk_package/{{ v2v_vddk_package_name }}"
    
    # Name of the CloudForms provider to which the conversion host belongs
    manageiq_provider_name: RHV
    
    # Base URL of CloudForms machine
    manageiq_url: "https://CloudForms_FQDN"
    
    # Whether to validate certificate of CloudForms server. Default is `true`.
    manageiq_validate_certs: false
    
    # To obtain the CloudForms zone ID, run this API call on the CloudForms machine:
    # curl -sk -u admin http://CloudForms_FQDN/api/zones/?filter\[\]=name=RHV&expand=resources&attributes=zone
    manageiq_zone_id: "42000000000001"
    
    # List of infrastructure providers
    # Each provider is a dictionary with 3 attributes: `name`, `hostname`, and `connection_configurations`
    manageiq_providers:
      - name: "RHV"
        hostname: Manager_FQDN_or_IP_address
        connection_configurations: 1
          - endpoint:
              role: "default"
              certificate_authority: | 2
                -----BEGIN CERTIFICATE-----
                MIIDoDCCAoigAwIBAgIBATANBgkqhkiG9w0BAQsFADA9MRswGQYDVQ....
                -----END CERTIFICATE-----
    1
    connection_configurations has a single endpoint, whose role is default.
    2
    The CA certificate is stored as /etc/pki/ovirt-engine/apache-ca.pem on the Manager machine.
  3. Create an encrypted secure_vars.yml file:

    # ansible-vault create secure_vars.yml
  4. Add the following variables to secure_vars.yml and save the file:

    ---
    # CloudForms `admin` user, for connecting to CloudForms
    manageiq_username: "username"
    
    # CloudForms `admin` password:
    manageiq_password: "password"
    
    # SSH private key to connect to VMware hypervisors. Required for both VDDK and SSH. 1
    v2v_ssh_private_key: |
      -----BEGIN RSA PRIVATE KEY-----
      b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAlwAAAAdzc2gtcn....
      -----END RSA PRIVATE KEY-----
    1
    This is the private key of the SSH key pair that you created in Configuring the VMware hypervisors for SSH transformation.
  5. Run the conversion_host_enable playbook:

    # ansible-playbook -i conversion_host_FQDN_or_IP, -b \
        -e "ansible_ssh_private_key_file=/etc/pki/ovirt-engine/keys/engine_id_rsa" \
        -e @extra_vars.yml -e @secure_vars.yml --ask-vault-pass \
        /usr/share/ovirt-ansible-v2v-conversion-host/playbooks/conversion_host_enable.yml
    Warning

    Running the conversion_host_enable playbook more than once on the same host creates multiple entries in the CloudForms database for that host.

    If you need to run the conversion_host_enable playbook again, you should remove the existing database entry by running the conversion_host_disable playbook on the host:

    # ansible-playbook /usr/share/ovirt-ansible-v2v-conversion-host/playbooks/conversion_host_disable.yml
  6. Run the conversion_host_check playbook to verify the conversion host configuration:

    # ansible-playbook --ask-vault-pass -i conversion_host_FQDN_or_IP, conversion_host_check.yml

Copying the VMware keys for Red Hat Virtualization

To prevent man-in-the-middle attacks, the conversion hosts do not accept the VMware keys by default for SSH transformation. Instead, the known_hosts file of each conversion host must be populated with the public keys of the VMware hypervisors.

Depending on the security processes of your VMware environment, you can either obtain a list of public keys from the VMware system administrators, if they collected the keys when they enabled SSH access on the hypervisors, or you can use ssh-keyscan.

Warning

You must run ssh-keyscan multiple times, once for each VMware hypervisor. Otherwise your conversion hosts will not have all the VMware keys and the migration will fail.

Perform the following procedure on the Manager machine:

  1. Run ssh-keyscan for each VMware hypervisor and output the public key to known_hosts, as in the following example:

    # ssh-keyscan esx1.example.com > /var/lib/vdsm/.ssh/known_hosts
    # ssh-keyscan esx2.example.com >> /var/lib/vdsm/.ssh/known_hosts
    # ssh-keyscan esx3.example.com >> /var/lib/vdsm/.ssh/known_hosts
  2. Change the ownership of the known_hosts file to user vdsm and group kvm:

    # chown 36:36 /var/lib/vdsm/.ssh/known_hosts

Configuring secure remote login to the VMware hypervisors for SSH transformation

Perform the following procedure on the Manager machine:

  1. Enter the following command:

    # sudo -u vdsm ssh-agent

    The command returns this output:

    SSH_AUTH_SOCK=socket_domain; export SSH_AUTH_SOCK; 1
    SSH_AGENT_PID=139150; export SSH_AGENT_PID;
    echo Agent pid 139150;
    1
    The socket_domain format is /tmp/ssh-socket_number/agent.pid.
  2. Enter the following commands, copying the socket_domain from the output, to validate the SSH configuration for each VMware hypervisor:

    # sudo -u vdsm SSH_AUTH_SOCK=socket_domain ssh-add
    # sudo -u vdsm \
        SSH_AUTH_SOCK=socket_domain ssh root@esx1.example.com
    Important

    These commands must be run for each VMware hypervisor.

    If the last command fails, all migrations from this VMware hypervisor using SSH transformation will fail. Check the following procedures:

    If the SSH connection is successful, you can authenticate the conversion hosts in CloudForms. See Authenticating the Red Hat Virtualization conversion hosts in CloudForms.

Authenticating the Red Hat Virtualization conversion hosts in CloudForms

Perform the following procedure for each Red Hat Virtualization conversion host:

  1. Click ComputeInfrastructureHosts and select a Red Hat Virtualization conversion host.
  2. Click the Configuration drop-down button and select Edit Selected items.
  3. In the Default tab of the Endpoints section, enter the Username and the Password for root.
  4. Click Validate and wait for validation to complete.
  5. Click Save.

You can create an infrastructure mapping. See Section 4.1, “Creating an infrastructure mapping”.

Optionally, you can verify the conversion hosts in a browser. See Section 3.3.3, “(Optional) Verifying the conversion hosts in a browser”.

3.3.2. Configuring the OpenStack Platform conversion hosts

Configuring the OpenStack Platform conversion hosts for VDDK or SSH transformation involves the following steps:

  1. VDDK only: Downloading the VMware Virtual Disk Development kit
  2. Configuring the conversion hosts:

    1. Creating the extra_vars.yml and secure_vars.yml files
    2. Configuring the conversion host with the conversion_host_enable playbook
    3. Verifying the configuration with the conversion_host_check playbook
    4. SSH only: Copying the VMware keys to the conversion hosts
  3. (Optional) Verifying the name and number of conversion hosts in a browser
Important

If you upgrade the target environment, you should upgrade the conversion hosts so that you have the latest software and critical updates:

  1. Download the latest conversion host appliance.
  2. Redeploy the conversion hosts. See Deploying the OpenStack Platform conversion hosts.

Prerequisite

  • VDDK only: Download the VMware Virtual Disk Development kit:

    1. Navigate to https://www.vmware.com/support/pubs/.
    2. Click VMware SDK & API Product Documentation to expand.
    3. Click VMware Virtual Disk Development Kit (VDDK).
    4. Click Latest Releases and select the latest VDDK release.
    5. Download and save the VDDK package (VMware-vix-disklib-version.x86_64.tar.gz), recording its URL.

Procedure

Perform the following procedure on each conversion host:

  1. Go to /usr/share/ovirt-ansible-v2v-conversion-host/playbooks.
  2. Create an extra_vars.yml file and update its parameters:

    ---
    v2v_host_type: openstack
    
    # Transport methods to configure on the conversion host. Valid values: `vddk`, `ssh`
    v2v_transport_methods:
      - vddk
    
    # Maximum number of concurrent conversions per host. Default is `10`.
    v2v_max_concurrent_conversions: 10
    
    # File name of VDDK package
    v2v_vddk_package_name: "VMware-vix-disklib-version.x86_64.tar.gz"
    
    # URL of VDDK package
    v2v_vddk_package_url: "http://path/to/downloaded_vddk_package/{{ v2v_vddk_package_name }}"
    
    manageiq_provider_name: OpenStack
    
    # Base URL of CloudForms machine
    manageiq_url: "https://CloudForms_FQDN"
    
    # Whether to validate certificate of CloudForms server. Default is `true`.
    manageiq_validate_certs: false
    manageiq_zone_id: "42000000000001"
    
    # List of cloud providers
    # Each provider is a dictionary with 3 attributes: `name`, `hostname`, and `connection_configurations`
    manageiq_providers:
      - name: "OpenStack"
        hostname: controller_node_FQDN_or_IP_address
        connection_configurations: 1
          - endpoint:
              role: "default"
              security_protocol: "ssl" 2
              certificate_authority: | 3
                -----BEGIN TRUSTED CERTIFICATE-----
                MIIDNzCCAh8CAQEwDQYJKoZIhvcNAQELBQAwYjELMAkGA1UEBhMCVV....
                -----END TRUSTED CERTIFICATE-----
                -----BEGIN TRUSTED CERTIFICATE-----
                MIIDlzCCAn+gAwIBAgIJAOP7AaT7dsLYMA0GCSqGSIb3DQEBCwUAMG....
                -----END TRUSTED CERTIFICATE-----
    1
    connection_configurations has a single endpoint, whose role is default.
    2
    You can specify the connection security: non-ssl, ssl-without-validation, or ssl. If you choose ssl, add the CA chain (certificate_authority)
    3
    The CA chain (certificate_authority) is a concatenation of two CA files:
    • /etc/pki/ca-trust/source/anchors/undercloud-cacert.pem on the undercloud server
    • /etc/pki/ca-trust/anchors/overcloud-cacert.pem on one of the overcloud controllers

      If you deploy your own CA chain, use the chain that signs the OpenStack Platform API certificates (see SSL/TLS Certificate Configuration in Red Hat OpenStack Platform Director Installation and Usage).

  3. Create an encrypted secure_vars.yml file:

    # ansible-vault create secure_vars.yml
  4. Add the following variables to secure_vars.yml and save the file:

    ---
    # CloudForms `admin` user, for connecting to CloudForms
    manageiq_username: "username"
    
    # CloudForms `admin` password:
    manageiq_password: "password"
    
    # SSH private key to connect to VMware hypervisors. Required for both VDDK and SSH. 1
    v2v_ssh_private_key: |
      -----BEGIN RSA PRIVATE KEY-----
      b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAlwAAAAdzc2gtcn....
      -----END RSA PRIVATE KEY-----
    1
    This is the private key of the SSH key pair that you created in Configuring the VMware hypervisors for SSH transformation.
  5. Run the conversion_host_enable playbook:

    # ansible-playbook -i conversion_host_FQDN_or_IP, -c local -b \
        -e @extra_vars.yml -e @secure_vars.yml --ask-vault-pass \
        /usr/share/ovirt-ansible-v2v-conversion-host/playbooks/conversion_host_enable.yml
    Warning

    Running the conversion_host_enable playbook more than once on the same host creates multiple entries in the CloudForms database for that host.

    If you need to run the conversion_host_enable playbook again, you should remove the existing database entry by running the conversion_host_disable playbook on the host:

    # ansible-playbook /usr/share/ovirt-ansible-v2v-conversion-host/playbooks/conversion_host_disable.yml
  6. Run the conversion_host_check playbook to verify the conversion host configuration:

    # ansible-playbook --ask-vault-pass -i conversion_host_FQDN_or_IP, conversion_host_check.yml

Copying the VMware keys for OpenStack Platform

To prevent man-in-the-middle attacks, the conversion hosts do not accept the VMware keys by default for SSH transformation. Instead, the known_hosts file of each conversion host must be populated with the public keys of the VMware hypervisors.

Depending on the security processes of your VMware environment, you can either obtain a list of public keys from the VMware system administrators, if they collected the keys when they enabled SSH access on the hypervisors, or you can use ssh-keyscan.

Warning

You must run ssh-keyscan multiple times, once for each VMware hypervisor. Otherwise your conversion hosts will not have all the VMware keys and the migration will fail.

Perform the following procedure on a conversion host:

  1. Run ssh-keyscan for each VMware hypervisor and output the public key to known_hosts, as in the following example:

    # ssh-keyscan esx1.example.com > /root/.ssh/known_hosts
    # ssh-keyscan esx2.example.com >> /root/.ssh/known_hosts
    # ssh-keyscan esx3.example.com >> /root/.ssh/known_hosts
  2. Repeat the procedure on each conversion host, to ensure that all the conversion hosts have all the VMware keys.
  3. Connect to each VMware hypervisor from each conversion host as cloud-user to verify the SSH connection.

    Important

    If the SSH connection to a VMware hypervisor fails, check Configuring the VMware hypervisors for SSH transformation.

    If the connection is successful, you can create an infrastructure mapping. See Section 4.1, “Creating an infrastructure mapping”.

3.3.3. (Optional) Verifying the conversion hosts in a browser

This procedure displays the names and number of your conversion hosts. It does not check SSH or VDDK transformation, which is done by the conversion_host_check playbook.

To verify your conversion hosts:

  1. Enter the following URL in your browser:

    https://CloudForms_FQDN/api/conversion_hosts
  2. In the Sign in window, enter the Username and Password and click Sign in.

    The conversion hosts are displayed in JSON format:

    {"name":"conversion_hosts","count":3,"subcount":3,"pages":1,"resources":[{"href":"https://CloudForms_FQDN/api/conversion_hosts/10000000000001"},{"href":"https://CloudForms_FQDN/api/conversion_hosts/10000000000002"},{"href":"https://CloudForms_FQDN/api/conversion_hosts/10000000000003"}],"actions":[{"name":"create","method":"post","href":"https://CloudForms_FQDN/api/conversion_hosts"},{"name":"edit","method":"post","href":"https://CloudForms_FQDN/api/conversion_hosts"},{"name":"delete","method":"post","href":"https://CloudForms_FQDN/api/conversion_hosts"}],"links":{"self":"https://CloudForms_FQDN/api/conversion_hosts?offset=0","first":"https://CloudForms_FQDN/api/conversion_hosts?offset=0","last":"https://CloudForms_FQDN/api/conversion_hosts?offset=0"}}

Chapter 4. Migrating the infrastructure

Note

Performing test migrations with different maximum numbers of concurrent migrations is highly recommended, to assess the capabilities of your environment’s infrastructure. See Section 4.3, “Changing the maximum number of concurrent migrations”.

Migrating the infrastructure involves the following key tasks:

  1. Section 4.1, “Creating an infrastructure mapping”, to map the resources of your source environment to your target environment
  2. Section 4.2, “Creating and running a migration plan”

4.1. Creating an infrastructure mapping

The infrastructure mapping maps your source infrastructure to your target environment.

Important

If you add or remove providers or provider objects from an infrastructure mapping, the mapping will have missing resource errors (see Section 5.2, “Infrastructure mapping errors”). You must delete the infrastructure mapping and create a new one.

Procedure

  1. Click ComputeMigrationInfrastructure Mappings.
  2. Click Create Infrastructure Mapping.
  3. Perform the following procedures in the Create Infrastructure Mapping wizard:

Creating infrastructure mapping

ScreenProcedure

General

  1. Enter the infrastructure mapping Name and (optional) Description.
  2. Select the Target Provider.
  3. Click Next.

Map Compute

  1. Select a Source Provider \ Datacenter \ Cluster source cluster and a (RHV) Target Provider \ Datacenter \ Cluster or (OpenStack Platform) Target Provider \ Project.

    If the target cluster or project does not contain a conversion host, a warning icon ( warning ) appears. You can create and save an infrastructure mapping, but you must configure conversion hosts before you can run a migration plan.

  2. Click Add Mapping. You can map additional clusters.
  3. Click Next.

Map Storage

  1. Select a source cluster whose datastores you want to map.
  2. Select a Source Provider \ Datacenter \ Datastore and (RHV) Target Datastores or (OpenStack Platform) Target Provider \ Volume Type. (If the OpenStack Platform volume type is missing, check that the volume type has been set. See Section 5.2, “Infrastructure mapping errors”.)
  3. Click Add Mapping. You can map additional datastores.
  4. Click Next.

Map Networks

  1. Select a source cluster from the drop-down list.
  2. Select one or more from Source Provider \ Datacenter \ Network and a Target Project \ Network. (IMS supports both provider and tenant networks in OpenStack Platform.)
  3. Click Add Mapping. You can map the networks of additional source clusters.
  4. Click Create.

Results

Click Close. Your infrastructure mapping is saved in ComputeMigrationInfrastructure Mappings.

You can click an infrastructure mapping element to view its details:

Infrastructure Mappings list

Infra mappings list

After you have created an infrastructure mapping, you can create and run a migration plan.

4.2. Creating and running a migration plan

Prerequisites

Certain prerequisites may apply.

Check your migration for the following conditions:

If these conditions do not apply, you are ready to create a migration plan.

Creating and running a migration plan

Creating and running a migration plan involves the following key steps:

  1. Creating a migration plan with the Create Migration Plan wizard in CloudForms (see Section 4.2.2, “Creating a migration plan”)
  2. Running the migration plan (the last step of the Create Migration Plan wizard) with one of the following options:

Optionally, you can do the following:

4.2.1. Migration plan prerequisites

The migration plan prerequisites apply to the following conditions:

If these conditions do not apply, you can create a migration plan. See Section 4.2.2, “Creating a migration plan”.

4.2.1.1. Creating a CSV file to add virtual machines to the migration plan

If you are migrating virtual machines that were migrated in the past, you should create a CSV file to add the virtual machines to the migration plan, because the migration plan cannot discover them automatically.

Using a CSV file for large migrations (recommended)

If you are migrating a large number of virtual machines, using a CSV file to add the virtual machines is faster than selecting them manually.

For large OpenStack Platform migrations, you can use a CSV file to set the security groups and flavors, instead of setting them individually in CloudForms.

Table 4.1. CSV file fields

FieldComments

Name

Virtual machine name. Required

Host

Optional. Only required if virtual machines have identical Name fields.

Provider

Optional. Only required if virtual machines have identical Name and Host fields.

Security Group

Optional, for OpenStack Platform only. The default is Default.

Flavor

Optional, for OpenStack Platform only. If you do not create flavors for the migration or if you leave this field blank, CloudForms tries to map the source virtual machines to existing flavors.

CSV file example

Name,Host,Provider,Security Group,Flavor
vm01,host1,vSphere3,webservers,x1.medium
vm02,host1,vSphere3,webservers,x1.medium
vm03,host1,vSphere3,webservers,x1.medium

You are ready to create a migration plan. See Section 4.2.2, “Creating a migration plan”.

4.2.1.2. Creating a RHEL premigration playbook for RHEL/Linux source virtual machines

If you are migrating virtual machines running RHEL or other Linux operating system, a RHEL premigration playbook ensures that their IP addresses are accessible after migration. The RHEL premigration playbook calls the Ansible ims.rhel_premigration role (see https://galaxy.ansible.com/fdupont_redhat/ims_rhel_pre_migration for documentation).

The ims.rhel_premigration role performs the following tasks on the source virtual machines:

  • Preserves the static IP address configuration by creating udev rules to associate the virtual machine’s MAC address with its interface name
  • (Red Hat Virtualization only) Installs the Red Hat Virtualization guest agent, which enables Red Hat Virtualization to report the IP address of the new virtual machine and to integrate it into the new environment
Note

The ims.rhel_premigration role assumes that either the rhel-6-server-rpms or the rhel-7-server-rpms repository is enabled in the source virtual machine when it installs qemu-guest-agent. If you have disabled the repository, re-enable it in the RHEL premigration playbook.

RHEL premigration playbook example

---
- hosts: all
  roles:
    - role: ims.rhel_pre_migration

You will select this playbook as a premigration playbook service in the Advanced options screen when you create the migration plan.

You are ready to create a migration plan. See Section 4.2.2, “Creating a migration plan”.

4.2.1.3. Adding Ansible playbooks to CloudForms for premigration and postmigration tasks

You can add Ansible playbooks to CloudForms to perform automated premigration and postmigration tasks on specific virtual machines, for example:

  • Removing webservers from a load-balancing pool before migration and returning them to the pool after migration
  • Running postmigration cleanup tasks, such as ftrim, to reduce the space required by virtual machines migrating to OpenStack Platform with Ceph storage (see Installing and configuring OpenStack Platform)

CloudForms requires a minimum of one Ansible playbook repository, one playbook, and one set of credentials.

Procedure

  1. Enable the Embedded Ansible server role (see Enabling the Embedded Ansible Server Role in Red Hat CloudForms: Managing Providers).
  2. Add an Ansible playbook repository (see Adding a Playbook Repository in Red Hat CloudForms: Managing Providers).
  3. Add the Ansible credentials for your virtual machines (see Credentials in Red Hat CloudForms: Managing Providers).
  4. Add a playbook as an Ansible service catalog item (see Creating an Ansible Playbook Service Catalog Item in Red Hat CloudForms: Provisioning Virtual Machines and Instances).

You will select the playbooks and the virtual machines on which they run in the Advanced Options screen when you create the migration plan.

You are ready to create a migration plan. See Section 4.2.2, “Creating a migration plan”.

4.2.2. Creating a migration plan

Large migrations

A CSV file is optional, but recommended, for large migrations because it is faster than manually selecting virtual machines or setting an OpenStack Platform security group and flavor for each virtual machine. See Section 4.2.1.1, “Creating a CSV file to add virtual machines to the migration plan”.

  1. Click ComputeMigrationMigration Plans.
  2. Click Create Migration Plan.
  3. Perform the following procedures in the Create Migration Plan wizard:

Create Migration Plan screen

ScreenProcedure

General

  1. Select an infrastructure mapping from the drop-down list.

    If you select an OpenStack Platform mapping, an Instance Properties screen appears after the VMs screen.

  2. Enter the migration plan Name and (optional) Description.
  3. Select a virtual machine discovery method:

    • Choose from a list of VMs discovered in the selected infrastructure mapping
    • Import a CSV file with a list of VMs to be migrated.

      A CSV file is required for previously migrated source virtual machines and highly recommended for large migrations.

  4. Click Next.

VMs

  1. If you selected Choose from a list of VMs discovered in the selected infrastructure mapping, select the virtual machines for migration. You can search for virtual machines by VM Name, Data Center, Cluster, and Folder.

    If you selected Import a CSV file with a list of VMs to be migrated:

    1. Click Import.
    2. Browse to the CSV file and click Open.

      If you try to import an invalid CVS file (for example, virtual machines with a duplicate Name field and no Host/Provider field to distinguish them, or with a duplicate Name field and duplicate Host/Provider fields), the Create Migration Plan wizard will freeze. This is a known issue and will be addressed in a future release.

  2. Click Next.

If the Create Migration Plan wizard cannot discover or import the source virtual machines, see Section 5.3, “Migration plan errors” for possible causes.

Instance Properties

(OpenStack Platform only)

  1. Click the pencil icon to edit the network or flavor of each selected virtual machine.

    Flavors that are too small for the virtual machine are marked with an asterisk (*). If you have not created flavors for the migration, CloudForms tries to map the source virtual machines to existing flavors.

  2. Click Next.

Advanced Options

  1. Select a premigration and/or postmigration playbook service from the dropdown lists (see Section 4.2.1.3, “Adding Ansible playbooks to CloudForms for premigration and postmigration tasks” for details).
  2. Select the virtual machines on which to run the playbook services.
  3. Click Next.

Schedule

  1. Select a schedule option:

    • Save migration plan to run later

      The migration plan is saved in Migration Plans Not Started and will not run unless you schedule it (see Scheduling a saved migration plan) or click Migrate to run the scheduled migration plan immediately.

    • Start migration immediately

      The migration plan may take some time to complete. Progress bars indicate the amount of transferred data, the number of migrated virtual machines, and the elapsed time. See Viewing a migration plan in progress for details.

      Optionally, you can cancel a migration plan in progress.

  2. Click Create.

Results

Click Close.

When the migration plan has finished, click Migration Plans Complete to view the status of the migration plan. The completed migration plan shows the status of the migrated virtual machines. If there are errors, see Chapter 5, Troubleshooting.

In the migration plans list, you can click the More Actions icon ( 7 ) to archive, edit, or delete a migration plan.

Scheduling a saved migration plan

  1. Click Migration Plans Not Started.
  2. Click the Schedule button of a migration plan.
  3. In the Schedule Migration Plan window, select a date and time and click Schedule. The plan’s status is Migration Scheduled with the date and time.

Viewing a migration plan in progress

  1. Click Migration Plans in Progress.
  2. Click a migration plan name to view its details, including the status of the migrating virtual machines.
Note

The counter in ComputeMigrationMigration Plans may be a few seconds ahead of the counter in the migration plan details view. This is because the Migration Plans counter displays the total time for running the migration plan, while the details counter displays the time for migrating the virtual machines.

Canceling a migration plan in progress

  1. Click Migration Plans in Progress.
  2. Select a migration plan and click Cancel Migration.
  3. Click Cancel Migrations to confirm the cancellation. The canceled migration appears in Migration Plans Complete with a red x indicating that the plan did not complete successfully.

Retrying a migration plan

  1. Delete newly created target virtual machines or instances, if any, to avoid name conflicts with the migrating VMware virtual machines.
  2. Delete newly created disks in the target datastore to free up space.
  3. OpenStack Platform only: Delete newly created network ports of failed instances.
  4. Click ComputeMigrationMigration Plans.
  5. Click Migration Plans Complete.
  6. Click the Retry button beside the failed migration plan.

4.3. Changing the maximum number of concurrent migrations

You can change the maximum number of concurrent migrations for conversion hosts or providers to control the impact of the migration process on your infrastructure.

Warning

For VDDK, the maximum concurrent migrations per conversion host should not be greater than 20. Otherwise, network overload will cause the migration to fail.

The provider setting has priority over the conversion host setting. For example, if the maximum number of concurrent migrations for a provider is 20 and for five conversion hosts, 3, the maximum number of concurrent migrations is 20, not 15 (5 conversion hosts x 3 concurrent migrations).

An increase in the maximum number of concurrent migrations affects all migration plans immediately. Virtual machines that are queued to migrate will migrate in greater numbers.

A decrease maximum number of concurrent migrations affects only future migration plans. Migration plans that are in progress will use the limit that was set when the plan was created.

Changing the maximum number of concurrent migrations for all conversion hosts
In CloudForms, click ComputeMigrationMigration Settings and select the new limit.
Note

The following commands are performed on the command line of the CloudForms machine.

Changing the maximum number of concurrent migrations for a single conversion host
# vmdb
# rails console
irb(main):001:0> $evm = MiqAeMethodService::MiqAeService.new(MiqAeEngine::MiqAeWorkspaceRuntime.new)
irb(main):002:0> $evm.vmdb(:host).find_by(:name => "host1.example.com").custom_set("Max Transformation Runners", 20)
Changing the maximum number of concurrent migrations for a provider
# vmdb
# rails console
irb(main):001:0> $evm = MiqAeMethodService::MiqAeService.new(MiqAeEngine::MiqAeWorkspaceRuntime.new)
irb(main):002:0> $evm.vmdb(:ext_management_system).find_by(:name => "RHV").custom_set("Max Transformation Runners", 30)
Getting the maximum number of concurrent migrations for a provider
# vmdb
# rails console
irb(main):001:0> $evm = MiqAeMethodService::MiqAeService.new(MiqAeEngine::MiqAeWorkspaceRuntime.new)
irb(main):002:0> $evm.vmdb(:ext_management_system).find_by(:name => "OpenStack").custom_get("Max Transformation Runners")

Chapter 5. Troubleshooting

To identify errors, check the migration logs (Section 5.1, “Migration logs”).

You can check these common issues and mistakes:

Section 5.5, “Known Issues” provides information about issues that will be addressed in a future release.

5.1. Migration logs

The conversion host logs and the CloudForms migration log can help with troubleshooting.

Conversion host logs

When disk migration starts, two logs are created in the conversion host:

  • virt-v2v: Debug output from virt-v2v itself. This log tracks the core of the virtual machine migration process, including libguestfs traces and disk migration details.
  • virt-v2v-wrapper: Log of the daemonizing wrapper for virt-v2v. This log traces the orchestration of the virtual machine conversion on the conversion host, including disk migration percentages and virt-v2v error reporting.

For more information about the functions of virt-v2v and virt-v2v-wrapper, see the migration workflows:

Important

If you need to open a Red Hat Support call, you will be required to submit both the migration (virt-v2v) log and virt-v2v-wrapper log for analysis.

Accessing the virt-v2v and virt-v2v-wrapper logs on the conversion host
  1. Log in to the conversion host using SSH. If you have multiple conversion hosts, you can view the name of a virtual machine’s conversion host by clicking the information icon ( 20 ) of the virtual machine in the migration plan’s details view.
  2. Go to /var/log/vdsm/import/ to access the logs for each migration:

    • virt-v2v log: v2v-import-date-log_number.log
    • virt-v2v-wrapper log: v2v-import-date-log_number-wrapper.log
Downloading the virt-v2v log in CloudForms
  1. Click ComputeMigrationMigration Plans.
  2. Click a completed migration plan to view its details.
  3. Click Download LogMigration Log.

CloudForms migration log

This log traces the orchestration of the virtual machine migration in CloudForms.

Accessing the CloudForms migration log
  1. Log in to the CloudForms machine using SSH.
  2. View the migration log, /var/www/miq/vmdb/log/automation.log.

5.2. Infrastructure mapping errors

  • Networks missing, Datastores missing, and Clusters missing error messages: If you create an infrastructure mapping and change a provider or refresh the RHV hosts, the provider’s object IDs change. Delete the infrastructure mapping and create a new one.
  • OpenStack Platform volume type not detected: Check that you have set at least one volume type. See Group Volume Settings with Volume Types in the Red Hat OpenStack Platform Storage Guide for the storage.

5.3. Migration plan errors

  • If the virtual machines are being migrated for the first time and are not discovered by the migration plan, check the source datastores and networks in the infrastructure mapping.
  • If the virtual machines have been migrated in the past, they cannot be discovered by the migration plan. Use a CSV file to add the virtual machines to the migration plan.
  • If the virtual machines cannot be added to the migration plan with a CSV file, check the CSV file format and fields. Create a new migration plan with the updated CSV file.
  • Create Migration Plan wizard hang while importing CSV file. This error is caused by an invalid CVS file (for example, virtual machines with a duplicate Name field and no Host/Provider field to distinguish them, or with a duplicate Name field and duplicate Host/Provider fields). You must reload the web page. This is a known issue and will be addressed in a future release.
  • Denied State error (IMS 1.1). If a migration plan fails immediately and the migration plan displays a Denied State error message, check that you have created and configured the conversion hosts correctly. Cancel the migration plan and retry it.
  • If you have not configured conversion hosts, the following error appears after running the migration plan (IMS 1.2): Unable to migrate VMs because no conversion host was configured at the time of the attempted migration. See the product documentation for information on configuring conversion hosts. You can create and save a migration plan whose infrastructure mapping does not contain conversion hosts, but you cannot run the migration plan without conversion hosts.

5.4. Virtual machine migration errors

5.4.1. Postmigration virtual machine IP address errors

  • If a migrated virtual machine does not have an IP address:

    • Check that VMware Tools is installed on the source virtual machine.
    • OpenStack Platform: Check the source virtual machine for an interface configuration file mapped to a non-existent interface (for example, /etc/sysconfig/network-scripts/ifcfg-eth1 exists, but eth1 interface does not). Log example:

      CalledProcessError: Command '['openstack', u'--os-username=admin', u'--os-identity-api-version=3', u'--os-user-domain-name=default', u'--os-auth-url=http://osp.example.com:5000/v3', u'--os-project-name=admin', u'--os-password=******, u--os-project-id=0123456789abcdef0123456789abcdef', 'port', 'create', '--format', 'json', '--network', u'01234567-89ab-cdef-0123-456789abcdef', '--mac-address', u'00:50:56:01:23:45', '--enable', u'port_0', '--fixed-ip', 'ip-address=None'"]' returned non-zero exit status 1
      date time:ERROR: Command output:
      BadRequestException: Unknown error

5.4.2. VMware environment errors

A source virtual machine cannot migrate if it has any of the following conditions:

  • Mounted ISO/CDROM disk
  • Encrypted disk
  • Invalid name (containing spaces or special characters)

If you are using SSH transformation, see Configuring the VMware hypervisors for SSH transformation.

5.4.3. Target environment errors

Red Hat Virtualization

OpenStack Platform

  • disallowed by policy error: The OpenStack Platform admin user in CloudForms does not have admin role privileges within the target project. Add the admin user as member and admin to your target project (see Edit a Project in the Red Hat OpenStack Platform Users and Identity Management Guide). Log example:

    ERROR: Command exited with non-zero return code 1, output: HttpException: 403: Client Error for url: https://FQDN:13696/v2.0/ports, {"NeutronError": {"message": "((rule:create_port and rule:create_port:mac_address) and rule:create_port:fixed_ips) is disallowed by policy", "type": "PolicyNotAuthorized", "detail": ""}}

5.5. Known Issues

Note

To obtain critical updates for the conversion hosts:

The following issues will be addressed in a future release: