Infrastructure Migration Solution Guide

Red Hat Infrastructure Migration Solution 1.2

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

Red Hat Migration Documentation Team

Abstract

This guide describes how to migrate VMware virtual machines to Red Hat Virtualization 4.3 or Red Hat OpenStack Platform 13 or 14, using Red Hat CloudForms 4.7.6 or later.

Preface

Red Hat Infrastructure Migration Solution (IMS) 1.2 enables you to migrate virtual machines from VMware 6.0 (and later) to Red Hat Virtualization or Red Hat OpenStack Platform, using Red Hat CloudForms:

Red Hat Virtualization 4.3

Red Hat Virtualization provides 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. See Red Hat Virtualization 4.3 documentation for more information.

See Part I, “Migrating from VMware to Red Hat Virtualization”.

Red Hat OpenStack Platform 13 and 14

Red Hat OpenStack Platform provides a scaleable, fault-tolerant, private or public cloud based on Red Hat Enterprise Linux. See Red Hat OpenStack Platform 13 or Red Hat OpenStack Platform 14 documentation for more information.

See Part II, “Migrating from VMware to Red Hat OpenStack Platform”.

Red Hat CloudForms 4.7.6 or later
Red Hat CloudForms is the environment in which you perform the migration. Red Hat CloudForms is a unified set of management tools for use across virtualized, private cloud, and public cloud platforms. See Red Hat CloudForms 4.7 documentation for more information.

Part I. Migrating from VMware to Red Hat Virtualization

This guide describes how to plan your migration, to prepare the VMware source and Red Hat target environments, and to migrate the virtual machines.

Chapter 1. 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".

Review the following information to plan your migration:

1.1. Understanding the migration

The following workflow describes the migration process.

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 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 (Red Hat Virtualization hosts 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 Red Hat Virtualization 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 Red Hat Virtualization virtual machine. (The virtual machine’s power state is the same as the source virtual machine’s power state.)

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

1.2. 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 VMware virtual machines that you will be migrating.
What is the maximum number of disks or virtual machines 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.

    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 am I missing?
  • Identify resource gaps, such as bandwidth, storage, licenses, or a suitable maintenance window, before you begin the migration.
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.
How long will the migration take?

There is no formula to estimate how long the actual migration will take. This is determined on a case-by-case basis.

The following example is provided as a guide:

Example 1.1. Red Hat Virtualization migration

  • Duration of migration: 1:15:53 (hh:mm:ss)
  • 10 virtual machines
  • Total data migrated: 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
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 a 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 are limited to a maximum of ten concurrent migrations, unless you change the default values.

You should 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.

Should I migrate my virtual machines with VDDK or SSH?

You can migrate your virtual machines with either the VMware Virtual Disk Development Kit (VDDK) or SSH. VDDK is the default because it is much faster than SSH and easier to configure.

VDDK is limited to 20 concurrent migrations per conversion host, because of network limitations, and 10 concurrent migrations per VMware hypervisor, unless you increase the hypervisor’s NFC service memory.

If you cannot use VDDK, SSH transformation is a fallback option.

1.3. Recommendations and best practices

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

Scheduling the migration

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

    Note

    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 the conversion hosts

  • Create a sufficient number of conversion hosts for your migration, with sufficient resources.
  • Create multiple conversion hosts for load-balancing. The virtual machines in a migration plan are automatically distributed among the conversion hosts. This decreases the load on the conversion hosts and allows you to increase the concurrent migrations beyond the limits of a single conversion host.

Controlling the migration process

  • Create multiple migration plans for finer control.
  • Perform test migrations with different maximum numbers of concurrent migrations to assess the capabilities of your environment’s infrastructure.

Chapter 2. Preparing the migration environment

You must prepare the VMware source and Red Hat Virtualization target environments for migration.

The virtual disks are converted with the VMware Virtual Disk Development Kit (VDDK). If you cannot use VDDK, SSH transformation is a fallback option.

2.1. Preparing the VMware environment

You must prepare the VMware network and virtual machines for migration.

If you are performing more than ten concurrent migrations from a single VMware hypervisor, you must configure the hypervisor.

2.1.1. Preparing the VMware network

Extend the VMware network to your Red Hat environment.

Important
  • The network configuration must not be changed in any way during the migration.
  • IP addresses, VLANs, and other network configuration must not be changed before or after migration because the conversion process preserves the source virtual machine MAC addresses.

2.1.2. Preparing the VMware virtual machines

Perform the following steps on each VMware virtual machine that you are migrating:

  1. Install VMware Tools to capture IP addresses.

    To download and install VMware Tools, see VMware Workstation 5.0: Installing VMware Tools.

  2. Unmount mounted ISO/CDROM disks.
  3. Ensure that attached disks are not encrypted.
  4. Ensure that each NIC has no more than one IPv4 and/or one IPv6 address.
  5. 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.

  6. Ensure that the virtual machine names do not duplicate names of virtual machines in the Red Hat Virtualization environment.

2.1.3. Configuring a VMware hypervisor for more than ten concurrent migrations

If you are performing more than ten concurrent migrations from a VMware hypervisor using VDDK transformation, the migration will fail because the hypervisor’s NFC service memory buffer is limited to ten parallel connections. See VMware vSphere 6.5 NFC session connection limits and Virt-v2v. VDDK: ESXi NFC service memory limits for details.

You can increase the hypervisor’s NFC service memory to enable additional connections for migrations.

Procedure

  1. Log in to a VMware hypervisor.
  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 VMware hypervisor.

2.2. Preparing the Red Hat Virtualization environment

You must install and configure Red Hat Virtualization and CloudForms and deploy the conversion hosts.

2.2.1. Prerequisites

Ensure that the following prerequisites are met in your Red Hat environment:

  1. Set the BIOS settings of physical hosts for optimal performance (rather than power-saving), according to the vendor’s recommendations.
  2. Disable C1E halt state, if applicable.
  3. Enable the following ports in the conversion host network:

    • 22 - SSH
    • 443 - CloudForms, Red Hat Virtualization Manager, and VDDK
    • 902 - CloudForms to VMware
    • 5480 - Conversion hosts to vCenter

      For details, see Configuring Firewall Ports.

  4. Ensure that the software versions are compatible:

    SoftwareVersion

    VMware

    6.0 or later

    Red Hat Virtualization

    4.3.4 (or later)

    Red Hat CloudForms

    4.7.6 (or later), with the CFME 5.10.5 (or later) virtual appliance

    The CFME 5.10.4 virtual appliance does not support migration.

    You can use CFME 5.10.4 to manage the Red Hat Virtualization environment. Only the migration functionality is affected.

2.2.2. Installing and configuring Red Hat Virtualization

You must install and configure Red Hat Virtualization.

Procedure

  1. Install Red Hat Virtualization Manager 4.3.4.
  2. Install Red Hat Virtualization Host 4.3.4 or Red Hat Enterprise Linux 7.6 on physical hosts.

    Note

    Some of these hosts will be deployed as conversion hosts. The number of conversion hosts depends on your migration size and infrastructure capabilities.

  3. Create and attach data and ISO storage domains to the data center.

    Note

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

    Although the ISO storage domain has been deprecated, it is required for migration.

  4. Upload the VirtIO and RHV Guest Tools image files to the ISO storage domain.

    The VirtIO file name must include the version number (virtio-win-version.iso). The guest tools are required for migrating Windows virtual machines.

  5. Optionally, you can create a MAC address pool that includes the MAC addresses of the VMware virtual machines to be migrated.

    Important

    If the Red Hat Virtualization MAC address pool range overlaps the VMware MAC address range, you must ensure that the MAC addresses of the migrating virtual machines do not duplicate those of existing virtual machines. Otherwise, the migration will fail.

    If you do not create a MAC address pool, the migrated virtual machines will not have MAC addresses in the same range as virtual machines created in Red Hat Virtualization.

2.2.3. Installing and configuring CloudForms

You must install and configure CloudForms.

Removing or changing a provider in CloudForms, after creating infrastructure mappings or migration plans, will cause migration errors.

Important

CFME 5.10.4 does not support migration.

2.3. Deploying the Red Hat Virtualization conversion hosts

Deploying the conversion hosts involves the following tasks:

  1. Downloading the VMware Virtual Disk Development Kit (VDDK)
  2. Configuring the conversion hosts in CloudForms
  3. Verifying the conversion hosts in a browser

2.3.1. Downloading the VMware Virtual Disk Development Kit

You must download the VMware Virtual Disk Development Kit (VDDK).

Prerequisites

  • VMware account credentials for downloading the VDDK SDK

Procedure

  1. In a browser, navigate to VMware Documentation.
  2. Click VMware SDK & API Product DocumentationVMware Virtual Disk Development Kit (VDDK).
  3. Select the latest VDDK release.
  4. Click Download SDKs to download the tar.gz VDDK archive file.
  5. Save the VDDK archive file in an HTTP-accessible location and record its path.

2.3.2. Configuring the conversion hosts for VDDK transformation

Prerequisites

  • If the Red Hat Virtualization provider has been active for a while, verify that each host has valid subscriptions and repositories by logging in using SSH and running the following commands:

    # subscription-manager list --consumed
    # yum repolist
  • If a host has an SSH private key in /var/lib/vdsm/.ssh/id_rsa, delete the key manually before configuring the host. Conversion host configuration does not overwrite existing keys.

Procedure

  1. In CloudForms, click ComputeMigrationMigration Settings.
  2. In the Conversion Hosts tab, click Configure Conversion Host. The Configure Conversion Host wizard is displayed.

    Conversion host configuration ui

  3. In the Location screen, add the provider details:

    1. Select a Provider Type.
    2. Select a Provider.
    3. Select a Cluster and click Next.
  4. In the Host(s) screen, select one or more hosts from the dropdown list and click Next.
  5. In the Authentication screen, add the conversion hosts' SSH key and the transformation method:

    1. Click Browse to browse to the SSH private key or paste it in the Conversion host SSH private key field.

      The Manager deploys a private SSH key on the conversion hosts in order to send commands and run playbooks. The default key file is /etc/pki/ovirt-engine/keys/engine_id_rsa on the Manager machine.

    2. Select VDDK as the Transformation method.
    3. Enter the path of the VDDK package in the VDDK library path field and click Validate. Wait for validation to complete.
    4. Click Configure.
  6. In the Results screen, wait for the conversion host configuration to finish and click Close.

    The configured conversion hosts and status information, including error messages, appear in the Configured Conversion Hosts list.

If an error occurs, you can download a host’s log by clicking the More Actions icon ( 7 ) and selecting Download Log.

You can click Retry if the conversion host configuration failed for reasons unconnected with your environment.

You can click Remove to remove the configuration from a configured conversion host.

2.3.3. Verifying the conversion hosts in a browser

You can verify your conversion hosts in a browser:

  1. In the address bar of a browser, enter the following:

    https://CloudForms_FQDN/api/conversion_hosts 1
    1
    Specify the FQDN of the CloudForms machine.

    A log-in screen is displayed.

  2. Enter your CloudForms Username and Password and click Sign in.

    The conversion hosts and their IDs are displayed in JSON format in the output:

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

Chapter 3. Migrating the virtual machines

Migrating the virtual machines involves the following steps:

  1. Checking for migration conditions that have prerequisites
  2. Creating an infrastructure mapping to map the resources of your source and target environments
  3. Creating and running a migration plan in CloudForms

Optionally, you can change the maximum number of concurrent migrations for conversion hosts or providers to control the migration process.

3.1. Migration prerequisites

Check your migration for the following conditions, which have prerequisites:

3.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.

Note

A CSV file is recommended for large migrations because it is faster than manually selecting individual virtual machines.

Table 3.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.

CSV file example

Name,Host,Provider
vm01,host1,vSphere3
vm02,host1,vSphere3
vm03,host1,vSphere3

3.1.2. 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
  • Preserving the IP addresses of VMware virtual machines running RHEL or other Linux operating systems

Procedure

  1. Log in to the CloudForms user interface.
  2. Enable the Embedded Ansible server role.
  3. Add an Ansible playbook repository.
  4. Add the credentials of each virtual machine that you are migrating.
  5. Add your playbook as an Ansible service catalog item.

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

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

If you are migrating virtual machines running RHEL or other Linux operating system, you can create a RHEL premigration playbook to ensure that the IP addresses are accessible after migration. The RHEL premigration playbook calls the Ansible ims.rhel_premigration role.

To install the role with Ansible Galaxy, see ims_rhel_pre_migration. This role is not included in the IMS installation.

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

  • Preserves the static IP addresses
  • Installs the Red Hat Virtualization guest agent, which reports the IP addresses and installed applications to the Manager
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, you must re-enable it in the RHEL premigration playbook.

RHEL premigration playbook example

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

3.2. Creating an infrastructure mapping

The infrastructure mapping maps the resources of your VMware source and Red Hat target environments.

Important

If you add or remove providers or provider objects from an infrastructure mapping, the mapping will have missing resource errors. You must delete the infrastructure mapping and create a new one.

Procedure

  1. Click ComputeMigrationInfrastructure Mappings.
  2. Click Create Infrastructure Mapping. The Create Infrastructure Mapping wizard is displayed.

    Creating infrastructure mapping

  3. In the General screen, add the infrastructure mapping details:

    1. Enter the infrastructure mapping Name and (optional) Description.
    2. Select the Target Provider.
    3. Click Next.
  4. In the Map Compute screen, map the source and target clusters:

    1. Select a Source Provider \ Datacenter \ Cluster and a Target Provider \ Datacenter \ Cluster.

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

    2. Click Add Mapping. You can map additional clusters.
    3. Click Next.
  5. In the Map Storage screen, map the source and target storage:

    1. Select a Source Provider \ Datacenter \ Datastore and Target Datastores.
    2. Click Add Mapping. You can map additional datastores.
    3. Click Next.
  6. In the Map Networks screen, map the source and target networks:

    1. Select a source cluster from the drop-down list.
    2. Select one or more networks from Source Provider \ Datacenter \ Network and Target Project \ Network.
    3. Click Add Mapping. You can map the networks of additional source clusters.
    4. Click Create.
  7. In the Results screen, click Close. The infrastructure mapping is saved in ComputeMigrationInfrastructure Mappings.

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

Infrastructure Mappings list

Infra mappings list

3.3. Creating and running a migration plan

Before attempting a large migration, you should perform several test migrations with different maximum numbers of concurrent migrations for your conversion hosts or providers. This will enable you to assess the capabilities of your environment’s infrastructure.

Note

A CSV file is optional, but recommended, for large migrations because it is faster than manually selecting each virtual machine.

Procedure

  1. Click ComputeMigrationMigration Plans.
  2. Click Create Migration Plan. The Create Migration Plan wizard is displayed.

    Create Migration Plan screen

  3. In the General screen, add the details of the migration plan:

    1. Select an infrastructure mapping from the drop-down list.
    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

        If the virtual machines cannot be discovered, check that the source datastores and networks in the infrastructure mapping are correct.

      • Import a CSV file with a list of VMs to be migrated.

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

    4. Click Next.
  4. In the VMs screen, select the virtual machines for migration:

    • 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 the virtual machines cannot be added to the migration plan, check the CSV file format and fields for errors.

        Note

        If the Create Migration Plan wizard freezes, refresh the web page, check the CSV file for errors (for example, virtual machines with duplicate Name fields and no other fields to distinguish them), and create a new migration plan.

      3. Click Next.
  5. In the Advanced Options screen, select the playbook service options:

    1. Select a premigration and/or postmigration playbook service from the dropdown lists.
    2. Select the virtual machines on which to run the playbook services.
    3. Click Next.
  6. In the Schedule screen, select a schedule option and click Create:

    • Save migration plan to run later

      The migration plan is saved in Migration Plans Not Started and will not run unless you schedule it 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. You can view a migration plan’s progress or cancel a migration plan in progress.

  7. In the Results screen, 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.

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

If a migration fails because of external circumstances (for example, power outage), you can retry the migration plan.

3.3.1. Scheduling a saved migration plan

To schedule a saved migration plan to run in the future:

  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.

3.3.2. Viewing a migration plan in progress

To view the progress of a migration plan:

  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.

3.3.3. Canceling a migration plan in progress

To cancel 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.

3.3.4. Retrying a failed migration plan

To retry a migration plan that failed because of external circumstances (for example, power outage):

  1. Delete all objects created by the failed migration plan:

    • Delete newly created virtual machines to avoid name conflicts with migrating VMware virtual machines.
    • Delete converted disks to free up space.
  2. Click ComputeMigrationMigration Plans.
  3. Click Migration Plans Complete.
  4. Click the Retry button beside the failed migration plan.

3.4. 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.

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

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.

Caution

For VDDK transformation, the number of concurrent migrations must not exceed 20. Otherwise, network overload will cause the migration to fail.

Changing the maximum number of concurrent migrations for all conversion hosts

  1. Log in to the CloudForms user interface.
  2. Click ComputeMigrationMigration Settings.
  3. In the Migration Throttling tab, select a value for Maximum concurrent migrations per conversion host or Maximum concurrent migrations per provider and click Apply.

    The value of Maximum concurrent migrations per conversion host is constrained so that it cannot be greater than Maximum concurrent migrations per provider.

Changing the maximum number of concurrent migrations for a specific conversion host

  1. Log in to the conversion host using SSH.
  2. Obtain the conversion_host_id:

    # curl -sk -u username:password https://CloudForms_FQDN/api/conversion_hosts/
  3. Enter the following command:

    # curl -sk -u username:_password_ https://CloudForms_FQDN/api/conversion_hosts/conversion_host_id -X POST -d {"action": "edit", "resource": {"max_concurrent_tasks": 15}} 1 2 3 4
1
Specify the CloudForms admin username and password.
2
Specify the FQDN of the CloudForms machine.
3
Specify the conversion_host_id.
4
Specify the maximum number of concurrent migrations. The default is 10.

Chapter 4. Troubleshooting

You can review the migration logs, check common issues and mistakes, and known issues to troubleshoot a migration error.

4.1. Migration logs

You can check the conversion host logs, playbook logs, and the CloudForms migration log to identify the cause of a migration error.

Important

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

4.1.1. Downloading the conversion host and playbook logs

You can download the conversion host and playbooks logs in CloudForms.

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.

Procedure

  1. Log in to the CloudForms user interface.
  2. Click ComputeMigrationMigration Plans.
  3. Click a completed migration plan to view its details.
  4. Click Download Log of a virtual machine and select a log from the dropdown list:

    • Premigration log This option only appears if a premigration playbook is used.
    • Migration log The Migration log is the virt-v2v log.
    • Virt-v2v-wrapper log
    • Postmigration log This option only appears if a postmigration playbook is used.

4.1.2. Accessing the CloudForms migration log

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

Procedure

  1. Log in to the CloudForms machine using SSH.
  2. The migration log is /var/www/miq/vmdb/log/automation.log.

4.2. Common issues and mistakes

4.2.1. Infrastructure mapping errors

  • Networks missing, Datastores missing, and Clusters missing error messages

    If you create an infrastructure mapping and then change a provider or refresh the Red Hat Virtualization hosts, the provider’s object IDs change. Delete the infrastructure mapping and create a new one.

4.2.2. Migration plan errors

  • Virtual machines are being migrated for the first time and are not discovered by the migration plan

    Check that the source datastores and networks appear in the infrastructure mapping.

  • Previously migrated virtual machines cannot be discovered by the migration plan

    Use a CSV file to add the virtual machines to the migration plan.

  • 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 hangs while importing a CSV file

    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). Correct the CSV file, refresh the web page, and create a new migration plan.

  • 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. Cancel the migration plan, create the conversion hosts, and run the migration plan again.

4.2.3. IP address errors

  • IP address of a migrated RHEL (or other Linux-based operating system) virtual machine is not accessible

    You must create a RHEL premigration playbook and add it to the migration plan.

  • Migrated virtual machine does not have an IP address

    You must install VMware Tools on the VMware virtual machine before migration.

4.2.4. Environment configuration errors

VMware

  • A VMware virtual machine cannot be migrated if it has any of the following conditions:

    • Mounted ISO/CDROM disk
    • Encrypted disk
    • Invalid name, containing spaces or special characters
  • If you are performing more than ten concurrent migrations from a single VMware hypervisor, you must increase the hypervisor’s NFC service memory.

Red Hat Virtualization

  • Name conflict

    VMware virtual machine has the same name as a Red Hat Virtualization virtual machine.

  • MAC address conflict

    VMware virtual machine has the same MAC address as a Red Hat Virtualization virtual machine in a MAC address pool.

  • Check that the conversion host does not have an existing private SSH key in /var/lib/vdsm/.ssh/id_rsa. Conversion host configuration does not overwrite old SSH keys. They must be deleted manually.
  • SSH transformation only:

    • If you are using SSSD with single sign-on, you must reinstall ipa-client without OpenSSH.
    • Check that you enabled SSH access on the VMware hypervisors and correctly configured your conversion hosts for SSH transformation.

4.3. Known Issues

The following are known issues:

Appendix A. Configuring the Red Hat Virtualization environment for SSH transformation

You can configure your environment for SSH transformation if you cannot use VDDK.

This configuration involves adding the following steps to Chapter 2, Preparing the migration environment:

Table A.1. Additional configuration for SSH transformation

SectionAdditional configuration for SSH transformation

After Preparing the VMware environment

Go to Configuring the VMware hypervisors for SSH transformation

You can collect the SSH keys from the hypervisors at this time, if your security policies allow.

The private key of the SSH key pair that is generated in this step will be used in Configuring the conversion hosts for SSH transformation.

After Installing and configuring Red Hat Virtualization

If the conversion hosts are using SSSD with single sign-on, go to Reinstalling ipa-client

Instead of Configuring the conversion hosts for VDDK transformation

Go to:

A.1. Configuring the VMware hypervisors for SSH transformation

For SSH transformation, you must enable SSH access and copy a public SSH key to each VMware hypervisor. The corresponding private key will be used to configure the conversion hosts.

Important

A single SSH key pair is recommended because this key pair is used only for virtual machine conversion and it simplifies conversion host management.

If you wish to use a dedicated SSH key pair for each conversion host, you can copy the public key of each conversion host to all the VMware hypervisors.

Procedure

  1. Enable SSH access on each VMware hypervisor. For instructions, navigate to VMware vSphere Documentation and enter Enable ESXi Shell and SSH Access with the Direct Console User Interface] in the Search field.

    You can collect the SSH public keys of the VMware hypervisors at this stage, to copy to the conversion hosts.

  2. Generate an SSH key pair without a passphrase:

    # ssh-keygen -N ''
  3. Copy the public SSH key to /etc/ssh/keys-root/authorized_keys on each VMware hypervisor.

    You will use the private SSH key to configure the conversion hosts.

A.2. Reinstalling ipa-client

If you are using SSH transformation and configuring your conversion hosts for SSSD with single sign-on, you must reinstall ipa-client without the OpenSSH client. Otherwise, SSH will fail for the vdsm user. See BZ#1544379: ipa-client-install changes system-wide SSH configuration for more information. This issue cannot be resolved by modifying the configuration file because the file is restored during upgrades.

Procedure

  1. Log in to the Manager machine using SSH.
  2. Uninstall ipa-client:

    # ipa-client-install --uninstall
  3. Reinstall ipa-client without OpenSSH:

    # ipa-client-install --no-ssh

A.3. Configuring the conversion hosts for SSH transformation

Prerequisites

  • If the Red Hat Virtualization provider has been active for a while, verify that each host has valid subscriptions and repositories by logging in using SSH and running the following commands:

    # subscription-manager list --consumed
    # yum repolist
  • If a host has an SSH private key in /var/lib/vdsm/.ssh/id_rsa, delete the key manually before configuring the host. Conversion host configuration does not overwrite existing keys.

Procedure

  1. In CloudForms, click ComputeMigrationMigration Settings.
  2. In the Conversion Hosts tab, click Configure Conversion Host. The Configure Conversion Host wizard is displayed.

    Conversion host configuration ui

  3. In the Location screen, add the provider details:

    1. Select a Provider Type.
    2. Select a Provider.
    3. Select a Cluster and click Next.
  4. In the Host(s) screen, select one or more hosts from the dropdown list and click Next.
  5. In the Authentication screen, add the conversion hosts' SSH key and the transformation method:

    1. Click Browse to browse to the SSH private key or paste it in the Conversion host SSH private key field.

      The Manager deploys a private SSH key on the conversion hosts in order to send commands and run playbooks. The default key file is /etc/pki/ovirt-engine/keys/engine_id_rsa on the Manager machine.

    2. Select SSH as the Transformation method.
    3. Click Browse to browse to the SSH private key you created for enabling SSH access on the VMware hypervisors or paste it in the VMware hypervisors SSH private key field.
    4. Click Configure.
  6. In the Results screen, wait for the conversion host configuration to finish and click Close.

    The configured conversion hosts and status information, including error messages, appear in the Configured Conversion Hosts list.

If an error occurs, you can download a host’s log by clicking the More Actions icon ( 7 ) and selecting Download Log.

You can click Retry if the conversion host configuration failed for reasons unconnected with your environment.

You can click Remove to remove the configuration from a configured conversion host.

A.4. Copying the VMware SSH keys to the conversion hosts

Copy the SSH public keys of the VMware hypervisors to the conversion hosts.

You can collect the VMware keys either when you configure the VMware hypervisors for SSH transformation or by using ssh-keyscan.

A.4.1. Copying keys collected during VMware hypervisor configuration

  1. Copy the VMware keys to /var/lib/vdsm/.ssh/known_hosts on each conversion host.
  2. Verify the SSH connection by connecting to each VMware hypervisor as vdsm:

    $ sudo -u vdsm ssh root@_esx1.example.com_ 1
    1
    Specify the host name of your VMware hypervisor.

    If the SSH connection fails, check that the VMware hypervisor has SSH access enabled and that you copied the correct keys. Otherwise, all migrations from that hypervisor using SSH transformation will fail.

A.4.2. Copying keys collected with ssh-keyscan

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

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

    $ ssh-keyscan esx1_IP > /var/lib/vdsm/.ssh/known_hosts 1
    $ ssh-keyscan esx2_IP >> /var/lib/vdsm/.ssh/known_hosts
    $ ssh-keyscan esx3_IP >> /var/lib/vdsm/.ssh/known_hosts
    1
    Specify the IP address, not the host name, of the VMware hypervisor.
  2. Change the ownership of the known_hosts file to vdsm user and kvm group:

    $ chown 36:36 /var/lib/vdsm/.ssh/known_hosts
  3. Verify the SSH connection by connecting to each VMware hypervisor as vdsm:

    $ sudo -u vdsm ssh root@_esx1.example.com_ 1
    1
    Specify the host name of the VMware hypervisor.

    If the SSH connection fails, check that the VMware hypervisor has SSH access enabled and that you copied the correct keys. Otherwise, all migrations from that hypervisor using SSH transformation will fail.

A.5. Configuring secure remote login to the VMware hypervisors

You can configure secure remote login to the VMware hypervisors by using ssh-agent and ssh-add.

Secure remote login must be verified for each VMware hypervisor. If secure remote login fails, all migrations from that hypervisor will fail.

Procedure

  1. On the Manager machine, create an ssh-agent session for the vdsm user:

    # sudo -u vdsm ssh-agent

    ssh-agent creates the SSH_AUTH_SOCK and SSH_AGENT_PID environment variables:

    SSH_AUTH_SOCK=/tmp/ssh-socket_number/agent.pid; export SSH_AUTH_SOCK;
    SSH_AGENT_PID=139150; export SSH_AGENT_PID;
    echo Agent pid 139150;
  2. Copy the SSH_AUTH_SOCK variable from the output.
  3. Run ssh-add to authorize the vdsm user’s private key for the ssh-agent session:

    # sudo -u vdsm SSH_AUTH_SOCK=SSH_AUTH_SOCK ssh-add
  4. Connect to a VMware hypervisor to verify the secure remote login:

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

Part II. Migrating from VMware to Red Hat OpenStack Platform

This guide describes how to plan your migration, to prepare the VMware source and Red Hat target environments, and to migrate the virtual machines.

Chapter 5. 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".

Review the following information to plan your migration:

5.1. Understanding the migration

The following workflow describes the migration process.

Figure 5.1. VMware to Red Hat 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 CloudForms captures the ESXi host fingerprint for authentication during the virtual machine conversion process.

25 Using the attributes defined for the Red Hat OpenStack Platform environment, CloudForms initiates communication with the conversion hosts (Red Hat OpenStack Platform instances 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 Red Hat 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.

5.2. 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 VMware virtual machines that you will be migrating.
What is the maximum number of disks or virtual machines 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.

    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 am I missing?
  • Identify resource gaps, such as bandwidth, storage, licenses, or a suitable maintenance window, before you begin the migration.
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.
How long will the migration take?

There is no formula to estimate how long the actual migration will take. This is determined on a case-by-case basis.

The following example is provided as a guide:

Example 5.1. Red Hat OpenStack Platform migration

  • Duration of migration: 2:13:00 (hh:mm:ss)
  • 20 virtual machines
  • 2 conversion hosts, maximum of 10 concurrent conversions
  • Total data migrated: 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
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 a 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 are limited to a maximum of ten concurrent migrations, unless you change the default values.

You should 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.

Should I migrate my virtual machines with VDDK or SSH?

You can migrate your virtual machines with either the VMware Virtual Disk Development Kit (VDDK) or SSH. VDDK is the default because it is much faster than SSH and easier to configure.

VDDK is limited to 20 concurrent migrations per conversion host, because of network limitations, and 10 concurrent migrations per VMware hypervisor, unless you increase the hypervisor’s NFC service memory.

If you cannot use VDDK, SSH transformation is a fallback option.

5.3. Recommendations and best practices

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

Scheduling the migration

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

    Note

    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 the conversion hosts

  • Create a sufficient number of conversion hosts for your migration, with sufficient resources.
  • Create multiple conversion hosts for load-balancing. The virtual machines in a migration plan are automatically distributed among the conversion hosts. This decreases the load on the conversion hosts and allows you to increase the concurrent migrations beyond the limits of a single conversion host.

Controlling the migration process

  • Create multiple migration plans for finer control.
  • Perform test migrations with different maximum numbers of concurrent migrations to assess the capabilities of your environment’s infrastructure.

Chapter 6. Preparing the migration environment

You must prepare the VMware source and Red Hat Virtualization target environments for migration.

The virtual disks are converted with the VMware Virtual Disk Development Kit (VDDK). If you cannot use VDDK, SSH transformation is a fallback option.

6.1. Preparing the VMware environment

You must prepare the VMware network and virtual machines for migration.

If you are performing more than ten concurrent migrations from a single VMware hypervisor, you must configure the hypervisor.

6.1.1. Preparing the VMware network

Extend the VMware network to your Red Hat environment.

Important
  • The network configuration must not be changed in any way during the migration.
  • IP addresses, VLANs, and other network configuration must not be changed before or after migration because the conversion process preserves the source virtual machine MAC addresses.

6.1.2. Preparing the VMware virtual machines

Perform the following steps on each VMware virtual machine that you are migrating:

  1. Install VMware Tools to capture IP addresses.

    To download and install VMware Tools, see VMware Workstation 5.0: Installing VMware Tools.

  2. Unmount mounted ISO/CDROM disks.
  3. Ensure that attached disks are not encrypted.
  4. Ensure that each NIC has no more than one IPv4 and/or one IPv6 address.
  5. 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.

  6. Ensure that the virtual machine names do not duplicate names of virtual machines in the Red Hat OpenStack Platform tenant.

6.1.3. Configuring a VMware hypervisor for more than ten concurrent migrations

If you are performing more than ten concurrent migrations from a VMware hypervisor using VDDK transformation, the migration will fail because the hypervisor’s NFC service memory buffer is limited to ten parallel connections. See VMware vSphere 6.5 NFC session connection limits and Virt-v2v. VDDK: ESXi NFC service memory limits for details.

You can increase the hypervisor’s NFC service memory to enable additional connections for migrations.

Procedure

  1. Log in to a VMware hypervisor.
  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 VMware hypervisor.

6.2. Preparing the Red Hat OpenStack Platform environment

You must install and configure Red Hat OpenStack Platform and CloudForms and deploy the conversion hosts.

6.2.1. Prerequisites

Ensure that the following prerequisites are met in your Red Hat environment:

  1. Set the BIOS settings of physical hosts for optimal performance (rather than power-saving), according to the vendor’s recommendations.
  2. Disable C1E halt state, if applicable.
  3. 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 (conversion hosts to vCenter).

  4. Ensure that the software versions are compatible:

    SoftwareVersion

    VMware

    6.0 or later

    Red Hat CloudForms

    4.7.6 (or later), with the CFME 5.10.5 (or later) virtual appliance

    The CFME 5.10.4 virtual appliance does not support migration.

    Red Hat OpenStack Platform

    13 or 14

    RHOSP V2V Image for Red Hat OpenStack Director

    14.0.4

6.2.2. Installing and configuring Red Hat OpenStack Platform

  1. Install Red Hat OpenStack Platform 13 or 14.
  2. Create provider networks for the target instances to preserve the IP addresses of the source virtual machines.
  3. Create a project for the conversion hosts and any target projects you require for the target instances.
  4. Ensure that the admin user has member and admin roles in the conversion host and target projects.
  5. Create a volume and set at least one volume type for the target block storage. Otherwise, CloudForms will not 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 Red Hat Ceph Storage, you will require three times the space of the source virtual machines for the migrated virtual machines. A Ceph storage cluster, by default, creates two copies of an object in a replicated storage pool, for a total of three copies.

    The migrated disks use all of the space because it is preallocated. For example, a source virtual machine with a 100 GB disk requires 300 GB of storage, regardless of how much data the disk actually contains. To save storage space, you can use the fstrim command on the migrated virtual machines as a postmigration task or playbook.

  7. 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.

6.2.3. Installing and configuring CloudForms

You must install and configure CloudForms.

Removing or changing a provider in CloudForms, after creating infrastructure mappings or migration plans, will cause migration errors.

Important

CFME 5.10.4 does not support migration.

Procedure

  1. Install Red Hat CloudForms 4.7.6 (or later) on Red Hat OpenStack Platform.
  2. Add VMware to CloudForms as an infrastructure provider.
  3. Add Red Hat OpenStack Platform to CloudForms as an infrastructure provider.

    Do not complete the fields in the RSA key pair tab. You will add the SSH private key when you configure the conversion hosts.

    If the Red Hat OpenStack Platform provider has been active for a while, you must wait for CloudForms to update its event history before attempting to use the provider. You can check the cloud provider timeline to verify that all events have been processed.

6.3. Deploying the Red Hat OpenStack Platform conversion hosts

Deploying the conversion hosts involves the following tasks:

  1. Creating the conversion hosts from the conversion appliance
  2. Downloading the VMware Virtual Disk Development Kit (VDDK)
  3. Configuring the conversion hosts in CloudForms
  4. Verifying the conversion hosts in a browser

6.3.1. Creating the Red Hat OpenStack Platform conversion hosts

You can create the Red Hat OpenStack Platform conversion hosts with the conversion appliance. The number of conversion hosts you deploy depends on your migration size and infrastructure capabilities.

Note

For optimal performance, deploy conversion hosts on compute nodes with nested virtualization enabled. Nested virtualization is a technology preview.

Procedure

  1. Navigate to Red Hat Product Downloads.
  2. In the A-Z tab, click Red Hat OpenStack Platform.
  3. Click Download Latest.
  4. Select 14.0 from the Version list.
  5. In the Product Software tab, locate the RHOSP V2V Image for Red Hat OpenStack Director 14.0.3 (x86_64) (or later), click Download Now, and save the image.
  6. Upload the image to Red Hat OpenStack Platform.
  7. Launch the image as a conversion host instance, with the following resources:

    • 4 vCPUs
    • 10 GB RAM, if you use the default maximum number of concurrent migrations per conversion host, which is 10. If you increase the number of concurrent migrations, you must add 1 GB RAM for each additional concurrent migration. If you reduce the number, you can reduce the RAM but the conversion host cannot have less than 8 GB RAM.
    • /tmp (10 GB, or 1 GB for each concurrent migration)
    • /var/tmp (10 GB, or 1 GB for each concurrent migration)
    • /var/logs (5 GB)
  8. Resize 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 physical volume in the volume group) to the required size, or you can create a new partition and add it as a physical volume to the volume group.

    Note

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

6.3.2. Downloading the VMware Virtual Disk Development Kit

You must download the VMware Virtual Disk Development Kit (VDDK).

Prerequisites

  • VMware account credentials for downloading the VDDK SDK

Procedure

  1. In a browser, navigate to VMware Documentation.
  2. Click VMware SDK & API Product DocumentationVMware Virtual Disk Development Kit (VDDK).
  3. Select the latest VDDK release.
  4. Click Download SDKs to download the tar.gz VDDK archive file.
  5. Save the VDDK archive file in an HTTP-accessible location and record its path.

6.3.3. Configuring the conversion hosts for VDDK transformation

Procedure

  1. In CloudForms, click ComputeMigrationMigration Settings.
  2. In the Conversion Hosts tab, click Configure Conversion Host. The Configure Conversion Host wizard is displayed.

    Conversion host configuration ui

  3. In the Location screen, add the provider details:

    1. Select a Provider Type.
    2. Select a Provider.
    3. Select a Project and click Next.
  4. In the Host(s) screen, select one or more hosts from the dropdown list and click Next.
  5. In the Authentication screen, add the conversion hosts' SSH key and the transformation method:

    1. Click Browse to browse to the SSH private key or paste it in the Conversion host SSH private key field.

      The Red Hat OpenStack Platform user uses a private SSH key to connect to the conversion hosts.

    2. Select VDDK as the Transformation method.
    3. Enter the path of the VDDK package in the VDDK library path field and click Validate. Wait for validation to complete.
    4. Click Configure.
  6. In the Results screen, wait for the conversion host configuration to finish and click Close.

    The configured conversion hosts and status information, including error messages, appear in the Configured Conversion Hosts list.

If an error occurs, you can download a host’s log by clicking the More Actions icon ( 7 ) and selecting Download Log.

You can click Retry if the conversion host configuration failed for reasons unconnected with your environment.

You can click Remove to remove the configuration from a configured conversion host.

6.3.4. Verifying the conversion hosts in a browser

You can verify your conversion hosts in a browser:

  1. In the address bar of a browser, enter the following:

    https://CloudForms_FQDN/api/conversion_hosts 1
    1
    Specify the FQDN of the CloudForms machine.

    A log-in screen is displayed.

  2. Enter your CloudForms Username and Password and click Sign in.

    The conversion hosts and their IDs are displayed in JSON format in the output:

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

Chapter 7. Migrating the virtual machines

Migrating the virtual machines involves the following tasks:

  1. Checking for migration conditions that have prerequisites
  2. Creating an infrastructure mapping to map the resources of your source and target environments
  3. Creating and running a migration plan in CloudForms

Optionally, you can change the maximum number of concurrent migrations for conversion hosts or providers to control the migration process.

7.1. Migration prerequisites

Check your migration for the following conditions, which have prerequisites:

7.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.

Note

A CSV file is recommended for large migrations because it is faster than manually selecting the security group and flavor of each virtual machine.

Table 7.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. The default is Default.

Flavor

Optional 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

7.1.2. 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
  • Preserving the IP addresses of VMware virtual machines running RHEL or other Linux operating systems
  • Running fstrim after migration to reduce the space required by virtual machines migrating to Red Hat OpenStack Platform with Ceph storage

Procedure

  1. Log in to the CloudForms user interface.
  2. Enable the Embedded Ansible server role.
  3. Add an Ansible playbook repository.
  4. Add the credentials of each virtual machine that you are migrating.
  5. Add your playbook as an Ansible service catalog item.

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

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

If you are migrating virtual machines running RHEL or other Linux operating system, you can create a RHEL premigration playbook to ensure that the IP addresses are accessible after migration. The RHEL premigration playbook calls the Ansible ims.rhel_premigration role.

To install the role with Ansible Galaxy, see ims_rhel_pre_migration. This role is not included in the IMS installation.

The ims.rhel_premigration role preserves the static IP addresses of the migrating VMware virtual machines.

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, you must re-enable it in the RHEL premigration playbook.

RHEL premigration playbook example

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

7.2. Creating an infrastructure mapping

The infrastructure mapping maps the resources of your VMware source and Red Hat target environments.

Important

If you add or remove providers or provider objects from an infrastructure mapping, the mapping will have missing resource errors. You must delete the infrastructure mapping and create a new one.

Procedure

  1. Click ComputeMigrationInfrastructure Mappings.
  2. Click Create Infrastructure Mapping. The Create Infrastructure Mapping wizard is displayed.

    Creating infrastructure mapping

  3. In the General screen, add the infrastructure mapping details:

    1. Enter the infrastructure mapping Name and (optional) Description.
    2. Select the Target Provider.
    3. Click Next.
  4. In the Map Compute screen, map the source and target clusters:

    1. Select a Source Provider \ Datacenter \ Cluster source cluster and a Target Provider \ Project.

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

    2. Click Add Mapping. You can map additional projects.
    3. Click Next.
  5. In the Map Storage screen, map the source and target storage:

    1. Select a Source Provider \ Datacenter \ Datastore and Target Provider \ Volume Type.

      If the volume type is missing, check that the volume type has been set. Block storage requires at least one volume type. See Create a Volume and Changing a Volume’s Type (Volume Re-typing) in the Red Hat OpenStack Platform Storage Guide.

    2. Click Add Mapping. You can map additional datastores.
    3. Click Next.
  6. In the Map Networks screen, map the source and target networks:

    1. Select a source cluster from the drop-down list.
    2. Select one or more networks from Source Provider \ Datacenter \ Network and Target Project \ Network.

      IMS supports both provider and tenant networks.

    3. Click Add Mapping. You can map the networks of additional source clusters.
    4. Click Create.
  7. In the Results screen, click Close. The infrastructure mapping is saved in ComputeMigrationInfrastructure Mappings.

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

Infrastructure Mappings list

Infra mappings list

7.3. Creating and running a migration plan

Before attempting a large migration, you should perform several test migrations with different maximum numbers of concurrent migrations for your conversion hosts or providers. This will enable you to assess the capabilities of your environment’s infrastructure.

Note

A CSV file is optional, but recommended, for large migrations because it is faster than manually selecting the security group and flavor of each virtual machine.

Procedure

  1. Click ComputeMigrationMigration Plans.
  2. Click Create Migration Plan. The Create Migration Plan wizard is displayed.

    Create Migration Plan screen

  3. In the General screen, add the details of the migration plan:

    1. Select an infrastructure mapping from the drop-down list.
    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

        If the virtual machines cannot be discovered, check that the source datastores and networks in the infrastructure mapping are correct.

      • Import a CSV file with a list of VMs to be migrated.

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

    4. Click Next.
  4. In the VMs screen, select the virtual machines for migration:

    • 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 the virtual machines cannot be added to the migration plan, check the CSV file format and fields for errors.

        Note

        If the Create Migration Plan wizard freezes, refresh the web page, check the CSV file for errors (for example, virtual machines with duplicate Name fields and no other fields to distinguish them), and create a new migration plan.

      3. Click Next.
  5. In the Instance Properties screen, select the networks and/or flavors:

    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.
  6. In the Advanced Options screen, select the playbook service options:

    1. Select a premigration and/or postmigration playbook service from the dropdown lists.
    2. Select the virtual machines on which to run the playbook services.
    3. Click Next.
  7. In the Schedule screen, select a schedule option and click Create:

    • Save migration plan to run later

      The migration plan is saved in Migration Plans Not Started and will not run unless you schedule it 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. You can view a migration plan’s progress or cancel a migration plan in progress.

  8. In the Results screen, 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.

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

If a migration fails because of external circumstances (for example, power outage), you can retry the migration plan.

7.3.1. Scheduling a saved migration plan

To schedule a saved migration plan to run in the future:

  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.

7.3.2. Viewing a migration plan in progress

To view the progress of a migration plan:

  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.

7.3.3. Canceling a migration plan in progress

To cancel 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.

7.3.4. Retrying a failed migration plan

To retry a migration plan that failed because of external circumstances (for example, power outage):

  1. Delete all objects created by the failed migration plan:

    • Delete newly created instances to avoid name conflicts with migrating VMware virtual machines.
    • Delete network ports of failed instances.
  2. Click ComputeMigrationMigration Plans.
  3. Click Migration Plans Complete.
  4. Click the Retry button beside the failed migration plan.

7.4. 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.

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

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.

Caution

Red Hat OpenStack Platform conversion hosts require an additional 1 GB RAM for each additional concurrent migration above 10.

For VDDK transformation, the number of concurrent migrations must not exceed 20. Otherwise, network overload will cause the migration to fail.

Changing the maximum number of concurrent migrations for all conversion hosts

  1. Log in to the CloudForms user interface.
  2. Click ComputeMigrationMigration Settings.
  3. In the Migration Throttling tab, select a value for Maximum concurrent migrations per conversion host or Maximum concurrent migrations per provider and click Apply.

    The value of Maximum concurrent migrations per conversion host is constrained so that it cannot be greater than Maximum concurrent migrations per provider.

Changing the maximum number of concurrent migrations for a specific conversion host

  1. Log in to the conversion host using SSH.
  2. Obtain the conversion_host_id:

    # curl -sk -u username:password https://CloudForms_FQDN/api/conversion_hosts/
  3. Enter the following command:

    # curl -sk -u username:_password_ https://CloudForms_FQDN/api/conversion_hosts/conversion_host_id -X POST -d {"action": "edit", "resource": {"max_concurrent_tasks": 15}} 1 2 3 4
1
Specify the CloudForms admin username and password.
2
Specify the FQDN of the CloudForms machine.
3
Specify the conversion_host_id.
4
Specify the maximum number of concurrent migrations. The default is 10.

Chapter 8. Troubleshooting

You can review the migration logs, check common issues and mistakes, and known issues.

8.1. Migration logs

You can check the conversion host logs, playbook logs, and the CloudForms migration log to identify the cause of a migration error.

Important

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

8.1.1. Downloading the conversion host and playbook logs

You can download the conversion host and playbooks logs in CloudForms.

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.

Procedure

  1. Log in to the CloudForms user interface.
  2. Click ComputeMigrationMigration Plans.
  3. Click a completed migration plan to view its details.
  4. Click Download Log of a virtual machine and select a log from the dropdown list:

    • Premigration log This option only appears if a premigration playbook is used.
    • Migration log The Migration log is the virt-v2v log.
    • Virt-v2v-wrapper log
    • Postmigration log This option only appears if a postmigration playbook is used.

8.1.2. Accessing the CloudForms migration log

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

Procedure

  1. Log in to the CloudForms machine using SSH.
  2. The migration log is /var/www/miq/vmdb/log/automation.log.

8.2. Common issues and mistakes

8.2.1. Infrastructure mapping errors

  • Networks missing, Datastores missing, and Clusters missing error messages

    If you create an infrastructure mapping and then change a provider, the provider’s object IDs change. Delete the infrastructure mapping and create a new one.

  • Storage volume type not detected

    Check that you have set at least one volume type.

8.2.2. Migration plan errors

  • Virtual machines are being migrated for the first time and are not discovered by the migration plan

    Check that the source datastores and networks appear in the infrastructure mapping.

  • Previously migrated virtual machines cannot be discovered by the migration plan

    Use a CSV file to add the virtual machines to the migration plan.

  • 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 hangs while importing a CSV file

    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). Correct the CSV file, refresh the web page, and create a new migration plan.

  • 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. Cancel the migration plan, create the conversion hosts, and run the migration plan again.

8.2.3. IP address errors

  • IP address of a migrated RHEL (or other Linux-based operating system) virtual machine is not accessible

    You must create a RHEL premigration playbook and add it to the migration plan.

  • Migrated virtual machine does not have an IP address

    • You must install VMware Tools on the VMware virtual machine before migration.
    • Check the VMware 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 errors

8.2.4. Environment configuration errors

VMware

  • A VMware virtual machine cannot be migrated if it has any of the following conditions:

    • Mounted ISO/CDROM disk
    • Encrypted disk
    • Invalid name, containing spaces or special characters
    • Powered off during migration
  • If you are performing more than ten concurrent migrations from a single VMware hypervisor, you must increase the hypervisor’s NFC service memory.

Red Hat OpenStack Platform

  • disallowed by policy error

    The Red Hat OpenStack Platform admin user in CloudForms does not have admin role privileges in the target project. Add the admin user as member and admin to your target project.

    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": ""}}

8.3. Known Issues

The following are known issues:

Appendix B. Configuring the Red Hat OpenStack Platform environment for SSH transformation

You can configure your environment for SSH transformation if you cannot use VDDK.

This configuration involves adding the following steps to Chapter 6, Preparing the migration environment:

Table B.1. Additional configuration for SSH transformation

SectionAdditional configuration for SSH transformation

After Preparing the VMware environment

Go to Configuring the VMware hypervisors for SSH transformation

You can collect the SSH keys from the hypervisors at this time, if your security policies allow.

The private key of the SSH key pair that is generated in this step will be used in Configuring the conversion hosts for SSH transformation.

Instead of Configuring the conversion hosts for VDDK transformation

Go to:

B.1. Configuring the VMware hypervisors for SSH transformation

For SSH transformation, you must enable SSH access and copy a public SSH key to each VMware hypervisor. The corresponding private key will be used to configure the conversion hosts.

Important

A single SSH key pair is recommended because this key pair is used only for virtual machine conversion and it simplifies conversion host management.

If you wish to use a dedicated SSH key pair for each conversion host, you can copy the public key of each conversion host to all the VMware hypervisors.

Procedure

  1. Enable SSH access on each VMware hypervisor. For instructions, navigate to VMware vSphere Documentation and enter Enable ESXi Shell and SSH Access with the Direct Console User Interface] in the Search field.

    You can collect the SSH public keys of the VMware hypervisors at this stage, to copy to the conversion hosts.

  2. Generate an SSH key pair without a passphrase:

    # ssh-keygen -N ''
  3. Copy the public SSH key to /etc/ssh/keys-root/authorized_keys on each VMware hypervisor.

    You will use the private SSH key to configure the conversion hosts.

B.2. Configuring the conversion hosts for SSH transformation

Procedure

  1. In CloudForms, click ComputeMigrationMigration Settings.
  2. In the Conversion Hosts tab, click Configure Conversion Host. The Configure Conversion Host wizard is displayed.

    Conversion host configuration ui

  3. In the Location screen, add the provider details:

    1. Select a Provider Type.
    2. Select a Provider.
    3. Select a Project and click Next.
  4. In the Host(s) screen, select one or more hosts from the dropdown list and click Next.
  5. In the Authentication screen, add the conversion hosts' SSH key and the transformation method:

    1. Click Browse to browse to the SSH private key or paste it in the Conversion host SSH private key field.

      The Red Hat OpenStack Platform user uses a private SSH key to connect to the conversion hosts.

    2. Select SSH as the Transformation method.
    3. Click Browse to browse to the SSH private key you created for enabling SSH access on the VMware hypervisors or paste it in the VMware hypervisors SSH private key field.
    4. Click Configure.
  6. In the Results screen, wait for the conversion host configuration to finish and click Close.

    The configured conversion hosts and status information, including error messages, appear in the Configured Conversion Hosts list.

If an error occurs, you can download a host’s log by clicking the More Actions icon ( 7 ) and selecting Download Log.

You can click Retry if the conversion host configuration failed for reasons unconnected with your environment.

You can click Remove to remove the configuration from a configured conversion host.

B.3. Copying the VMware SSH keys to the conversion hosts

Copy the SSH public keys of the VMware hypervisors to the conversion hosts.

You can collect the VMware keys either when you configure the VMware hypervisors for SSH transformation or by using ssh-keyscan.

B.3.1. Copying keys collected during VMware hypervisor configuration

  1. Copy the VMware keys to /root/.ssh/known_hosts on each conversion host.
  2. On each conversion host, verify the SSH connection by connecting to each VMware hypervisor as cloud-user:

    $ sudo -u cloud-user ssh root@esx1.example.com 1
    1
    Specify the host name of the VMware hypervisor.

    If the SSH connection fails, check that the VMware hypervisor has SSH access enabled and that you copied the correct keys. Otherwise, all migrations from that hypervisor using SSH transformation will fail.

B.3.2. Copying keys collected with ssh-keyscan

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

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

    $ ssh-keyscan esx1_IP > /root/.ssh/known_hosts 1
    $ ssh-keyscan esx2_IP >> /root/.ssh/known_hosts
    $ ssh-keyscan esx3_IP >> /root/.ssh/known_hosts
    1
    Specify the IP address, not the host name, of the VMware hypervisor.
  2. On each conversion host, verify the SSH connection by connecting to each VMware hypervisor as cloud-user:

    $ sudo -u cloud-user ssh root@esx1.example.com 1
    1
    Specify the host name of the VMware hypervisor.

    If the SSH connection fails, check that the VMware hypervisor has SSH access enabled and that you copied the correct keys. Otherwise, all migrations from that hypervisor using SSH transformation will fail.