Product SiteDocumentation Site

Chapter 2. Converting Virtual Machines to Run on KVM Managed by libvirt

2.1. Converting a Virtual Machine
2.1.1. Preparing to Convert a Virtual Machine
2.1.2. Converting Virtual Machines
2.1.3. Running Converted Virtual Machines
virt-v2v can convert virtual machines to run on Red Hat Enterprise Linux, using KVM managed by libvirt. Virtual machines can be converted from Xen, KVM and VMware ESX environments.

2.1. Converting a Virtual Machine

virt-v2v converts virtual machines from a foreign hypervisor to run on Red Hat Enterprise Linux, using KVM managed by libvirt. It automatically creates a libvirt domain for the converted virtual machines.
Converting a virtual machine
Figure 2.1. Converting a virtual machine

2.1.1. Preparing to Convert a Virtual Machine

Before a virtual machine can be converted, ensure that the following steps are completed.
  1. Create a local storage domain for transferred storage
    virt-v2v copies the guest storage to a locally defined libvirt storage pool during import. This pool can be defined using any libvirt tool, and can be of any type. The simplest way to create a new pool is with virt-manager. Select your host, right click and select details.
    Select host details
    Figure 2.2. Select host details

    Select the Storage tab.
    The storage tab
    Figure 2.3. The storage tab

    Click the plus sign (+) button to add a new storage pool.
    Adding a storage pool - step 1
    Figure 2.4. Adding a storage pool - step 1

    Enter the name for the new storage pool, and select the type of storage target to use.
    Adding a storage pool - step 2
    Figure 2.5. Adding a storage pool - step 2

    Specify the path to the storage target, along with any type-specific details.
  2. Create local network interfaces.
    The local machine must have an appropriate network to which the converted virtual machine can connect. This is likely to be a bridge interface. A bridge interface can be created using standard tools on the host. virt-manager can also create and manage bridges. For more information on bridged networking with libvirt, see the Red Hat Enterprise Linux Virtualization Guide.
  3. Specify network mappings in virt-v2v.conf. This step is optional, and is not required for most use cases.
    If your virtual machine has multiple network interfaces, /etc/virt-v2v.conf must be edited to specify the network mapping for all interfaces. You can specify an alternative virt-v2v.conf file with the -f parameter.
    If your virtual machine only has a single network interface, it is simpler to use the --network or --bridge parameters, rather than modifying virt-v2v.conf.
  4. Create a profile for the conversion in virt-v2v.conf. This step is optional. Profiles specify a conversion method, storage location, output format and allocation policy. When a profile is defined, it can be called using --profile rather than individually providing the -o, -os, -of and -oa parameters. See virt-v2v.conf(5) for details.

2.1.1.1. Preparing to convert a virtual machine running Linux

Before a virtual machine running Linux can be converted, ensure that the following steps are completed.
  1. Obtain the software
    As part of the conversion process, virt-v2v may install a new kernel and drivers on the virtual machine. If the virtual machine being converted is registered to Red Hat Network (RHN), the required packages will be automatically downloaded. If the virtual machine is not registered to RHN, the virt-v2v.db file ships with a list of RPMs used for this purpose. The RPMs relevant to your virtual machine must be downloaded manually from RHN and made available on the host running virt-v2v. The RPMs should be saved in the directory specified by the path-root configuration element, which by default is /var/lib/virt-v2v/software/. An error similar to Example 2.1, “Missing Package error” will be displayed by virt-v2v if software it depends upon for a particular conversion is not available.
    Example 2.1. Missing Package error
    virt-v2v: Installation failed because the following files referenced in the configuration file are required, but missing:
    rhel/6/kernel-2.6.32-128.el6.x86_64.rpm
    rhel/6/ecryptfs-utils-82-6.el6.x86_64.rpm
    rhel/6/ecryptfs-utils-82-6.el6.i686.rpm
    

    To obtain the relevant RPMs for your environment, repeat these steps for each missing package:
    1. Login to Red Hat Network
    2. Select the Package Search tab.
    3. In the Search For field, type the package name exactly matching the one shown in the error message. For the example shown in Example 2.1, “Missing Package error”, the first package is kernel-2.6.32-128.el6.x86_64
    4. In the Where to search field, select In the following architectures and tick the x86_64 checkbox. Click Search.
    5. A list of packages displays. Click the package name identical to the one in the error message.
    6. You will be directed to the Details page, containing detailed descriptions of the package. Select Download Package at the bottom of the page
    7. Save the downloaded package to the appropriate directory in /var/lib/virt-v2v/software. For Red Hat Enterprise Linux 6, the directory is /var/lib/virt-v2v/software/rhel/6

2.1.1.2. Preparing to convert a virtual machine running Windows

Before a virtual machine running Windows can be converted, ensure that the following steps are completed.
  1. Install the libguestfs-winsupport package on the host running virt-v2v. This package provides support for NTFS, which is used by many Windows systems. The libguestfs-winsupport package is provided by the RHEL V2VWIN (v. 6 for 64-bit x86_64) channel. Ensure your system is subscribed to this channel, then run the following command as root:
    yum install libguestfs-winsupport
    If you attempt to convert a virtual machine using NTFS without the libguestfs-winsupport package installed, the conversion will fail. An error message similar to Example 2.2, “Error message when converting a Windows virtual machine without libguestfs-winsupport installed” will be shown.
    Example 2.2. Error message when converting a Windows virtual machine without libguestfs-winsupport installed
    No operating system could be detected inside this disk image.
    
    This may be because the file is not a disk image, or is not a virtual machine
    image, or because the OS type is not understood by virt-inspector.
    
    If you feel this is an error, please file a bug report including as much
    information about the disk image as possible.

  2. Install the virtio-win package on the host running virt-v2v. This package provides para-virtualized block and network drivers for Windows guests. The virtio-win package is provided by the RHEL Server Supplementary (v. 6 64-bit x86_64) channel. Ensure your system is subscribed to this channel, then run the following command as root:
    yum install virtio-win
    If you attempt to convert a virtual machine running Windows without the virtio-win package installed, the conversion will fail. An error message similar to Example 2.3, “Error message when converting a Windows virtual machine without virtio-win installed” will be shown.
    Example 2.3. Error message when converting a Windows virtual machine without virtio-win installed
    virt-v2v: Installation failed because the following files referenced in the configuration file are required, but missing: /usr/share/virtio-win/drivers/i386/Win2008

Post-processing for Windows virtual machines

When virtual machines running Windows are converted for output to Red Hat Enterprise Virtualization, post-processing of the virtual machine image will be performed by the Red Hat Enterprise Virtualization Manager to install updated drivers. See Section 5.2.2, “Configuration Changes for Windows Virtual Machines” for details of the process. This step will be omitted when virtual machines running Windows are converted for output to libvirt.

2.1.1.3. Preparing to convert a local Xen virtual machine

The following is required when converting virtual machine on a host which used to run Xen, but has been updated to run KVM. It is not required when converting a Xen guest imported directly from a running libvirt/Xen instance.
  1. Obtain the XML for the virtual machine
    virt-v2v uses a libvirt domain description to determine the current configuration of the virtual machine, including the location of its storage. Before starting the conversion, obtain this from the host running the virtual machine with the following command:
    virsh dumpxml vm-name > vm-name.xml
    This will require booting into a Xen kernel to obtain the XML, as libvirt needs to connect to a running Xen hypervisor to obtain its metadata. The conversion process is optimized for KVM, so obtaining domain data while running a Xen kernel, then performing the conversion using a KVM kernel will be more efficient than running the conversion on a Xen kernel.

2.1.2. Converting Virtual Machines

Once you have prepared to convert the virtual machines, use virt-v2v to perform the actual conversions. This section provides the steps to convert the virtual machines, and command syntax for virt-v2v. Note that conversions are resource intensive processes, involving copying the whole disk image for a virtual machine. In typical environments, converting a single virtual machine takes approximately 5-10 minutes.

2.1.2.1. virt-v2v

virt-v2v converts guests from a foreign hypervisor to run on KVM, managed by libvirt. The general command syntax for converting machines to run on KVM managed by libvirt is:
virt-v2v -i libvirtxml -os pool --bridge brname vm-name.xml
virt-v2v -ic xen+ssh://root@vmhost.example.com -os pool --bridge brname vm-name
virt-v2v -ic esx://esx.example.com/?no_verify=1 -os pool --bridge brname vm-name
A full specification of the parameters which can be used with virt-v2v is available in Section 5.1, “virt-v2v Parameters”.

2.1.2.2. Converting a local Xen virtual machine

Ensure that the virtual machine's XML is available locally, and that the storage referred to in the XML is available locally at the same paths.
To convert the virtual machine from an XML file, run:
virt-v2v -i libvirtxml -os pool --bridge brname vm-name.xml
Where pool is the local storage pool to hold the image, brname is the name of a local network bridge to connect the converted virtual machine's network to, and vm-name.xml is the path to the virtual machine's exported XML. You may also use the --network parameter to connect to a locally managed network, or specify multiple mappings in /etc/virt-v2v.conf.
If your guest uses a Xen para-virtualized kernel (it would be called something like kernel-xen or kernel-xenU), virt-v2v will attempt to install a new kernel during the conversion process. You can avoid this requirement by installing a regular kernel, which won't reference a hypervisor in its name, alongside the Xen kernel prior to conversion. You should not make this newly installed kernel your default kernel, because Xen will not boot it. virt-v2v will make it the default during conversion.

2.1.2.3. Converting a remote Xen virtual machine

Setup SSH Keys Prior to Converting a Remote VM with Multiple Disks

Because each disk transfer requires a new SSH session, it is recommended that SSH keys be set up prior to the conversion for authentication. This is especially important for large disks. Otherwise, a user will be required to manually enter SSH credentials for each disk being transferred. Failure to do so before the SSH negotiation times out will cause virt-v2v to fail.
Xen virtual machines can be converted remotely via SSH. Ensure that the host running the virtual machine is accessible via SSH.
To convert the virtual machine, run:
virt-v2v -ic xen+ssh://root@vmhost.example.com -os pool --bridge brname vm-name
Where vmhost.example.com is the host running the virtual machine, pool is the local storage pool to hold the image, brname is the name of a local network bridge to connect the converted virtual machine's network to, and vm-name is the domain of the Xen virtual machine. You may also use the --network parameter to connect to a locally managed network, or specify multiple mappings in /etc/virt-v2v.conf. You will be prompted to enter the password for the user specified in the connection string, which is root in the example above
If your guest uses a Xen para-virtualized kernel (it would be called something like kernel-xen or kernel-xenU), virt-v2v will attempt to install a new kernel during the conversion process. You can avoid this requirement by installing a regular kernel, which won't reference a hypervisor in its name, alongside the Xen kernel prior to conversion. You should not make this newly installed kernel your default kernel, because Xen will not boot it. virt-v2v will make it the default during conversion.

2.1.2.4. Converting a VMware ESX virtual machine

Uninstall VMware Tools prior to conversion

When converting a Windows virtual machine from VMware ESX, ensure that VMware Tools is not installed on the virtual machine. The VMware Tools must be uninstalled prior to the conversion process. If a virtual machine is converted with the VMware Tools installed, it will not function correctly.
Ensure that the virtual machine is stopped prior to running the v2v process.
To convert the virtual machine, run:
virt-v2v -ic esx://esx.example.com/ -os pool --bridge brname vm-name
Where esx.example.com is the VMware ESX server, pool is the local storage pool to hold the image, brname is the name of a local network bridge to connect the converted virtual machine's network to, and vm-name is the name of the virtual machine. You may also use the --network parameter to connect to a locally managed network, or specify multiple mappings in /etc/virt-v2v.conf. The progress of the conversion process will be displayed in percent as it runs.
Authenticating to the ESX server
Connecting to the ESX server will require authentication. virt-v2v supports password authentication when connecting to ESX. It reads passwords from $HOME/.netrc. The format of this file is described in the netrc(5) man page. An example entry is:
machine esx.example.com login root password s3cr3t

.netrc permissions

The .netrc file must have a permission mask of 0600 to be read correctly by virt-v2v
Connecting to an ESX server with an invalid certificate
In non-production environments, the ESX server may have a non-valid certificate, for example a self-signed certificate. In this case, certificate checking can be explicitly disabled by adding '?no_verify=1' to the connection URI as shown below:
... -ic esx://esx.example.com/?no_verify=1 ...

2.1.3. Running Converted Virtual Machines

On successful completion, virt-v2v will create a new libvirt domain for the converted virtual machine with the same name as the original virtual machine. It can be started as usual using libvirt tools, for example virt-manager.
Guest network configuration
virt-v2v cannot currently reconfigure a guest's network configuration. If the converted guest is not connected to the same subnet as the source, its network configuration may have to be updated.