Cari di RHE Linux 
    RHE Linux User Manual
Daftar Isi
(Sebelumnya) 23 : V2V Guide23 : Chapter 5. Converting phy ... (Berikutnya)

V2V Guide

Chapter 3. Converting virtual machines to run on Red Hat Enterprise Virtualization

virt-v2v can convert virtual machines to run on Red Hat Enterprise Virtualization. Virtual machines can be converted from Xen, KVM and VMware ESX / ESX(i) environments. Before converting virtual machines to run on Red Hat Enterprise Virtualization, you must attach an export storage domain to the Red Hat Enterprise Virtualization data center being used. Section 3.2, "Attaching an export storage domain" explains the process of attaching an export storage domain. For more information on export storage domains, see the Red Hat Enterprise Virtualization Administration Guide.

3.1. Acceptable converted storage output formats

It is important to note that when converting a guest virtual machine to run on Red Hat Enterprise Virtualization, not all combinations of storage format and allocation policy are supported. The supported combinations differ according to whether the Red Hat Enterprise Virtualization data center the guest will be imported into uses block (FC or iSCSI) or file (NFS) for its data storage domain. Note that virt-v2v writes to an export storage domain, and this is always required to be NFS.

Note

The important element for a successful virtual machine import into Red Hat Enterprise Virtualization is the type of the data domain. virt-v2v is unable to detect the data center type, so this check must be applied manually by the user.

Table 3.1. Allocation Policy: Preallocated

Data Domain TypeStorage FormatSupported
NFSrawYes
qcow2No
FC/iSCSIrawYes
qcow2No

Table 3.2. Allocation Policy: Sparse

Data Domain TypeStorage FormatSupported
NFSrawYes
qcow2Yes
FC/iSCSIrawNo
qcow2Yes

Data format and allocation policy of the virtual machine being converted by virt-v2v will be preserved unless the output data format and allocation policy are specified using the -of and -oa parameters respectively. To import virtual machines using sparse allocation into an FC or iSCSI data center, the storage format must be converted to qcow2. This is achieved by passing the parameters -of qcow2 -oa sparse to virt-v2v. Note that converting between raw and qcow2 formats is a resource intensive operation, and roughly doubles the length of time taken for the conversion process.

Important

Preallocated qcow2 storage is never supported in Red Hat Enterprise Virtualization, although virt-v2v is able to write it. Import to Red Hat Enterprise Virtualization will fail.

3.2. Attaching an export storage domain

Before converting virtual machines to run on Red Hat Enterprise Virtualization, you must attach an export storage domain to the Red Hat Enterprise Virtualization data center being used.
An export storage domain can be attached to a data center to enable the import or export of virtual machines from one data center to another. An export storage domain can also be used to backup virtual machines and templates.

Note

At a given time, an export domain can only be attached to a single data center.

Procedure 3.1. Attaching an export storage domain

  1. Log in to the Red Hat Enterprise Virtualization administration portal. Click the Data Centers tab.
    Select the data center to which the export storage domain is to be attached.
  2. The details pane displays. Select the Storage tab.
  3. Click Attach Export to add the storage location where the images are stored.
    Attaching an Export Domain

    Figure 3.1. Attaching an Export Domain


  4. The Attach Export Domain dialog box displays if there are export domains available. Select the export domain from the list.
  5. Click the OK button. The new export storage domain displays on the Storage tab of the details pane with a status of Locked, followed by Inactive.
  6. Select the new export storage domain on the Storage tab of the details pane, and click the Activate button.
  7. The export domain will be activated in a few moments and display an Active status.

3.3. Converting a virtual machine

virt-v2v converts virtual machines from a foreign hypervisor to run on Red Hat Enterprise Virtualization. It automatically packages the virtual machine images and metadata, then uploads them to a Red Hat Enterprise Virtualization export storage domain. For more information on export storage domains, see Section 3.2, "Attaching an export storage domain". virt-v2v always makes a copy of storage before conversion.
Converting a virtual machine

Figure 3.2. Converting a virtual machine


From the export storage domain, the virtual machine images can be imported into Red Hat Enterprise Virtualization using the administration portal.
Importing a virtual machine

Figure 3.3. Importing a virtual machine


3.3.1. Preparing to convert a virtual machine

Before a virtual machine can be converted, ensure that the following steps are completed:

Procedure 3.2. Preparing to convert a virtual machine

  1. Create an NFS export domain. virt-v2v can transfer the converted virtual machine directly to an NFS export storage domain. From the export storage domain, the virtual machine can be imported into a Red Hat Enterprise Virtualization data center. The storage domain must be mountable by the machine running virt-v2v. When exporting to a Red Hat Enterprise Virtualization export domain, virt-v2v must run as root.

    Note

    The export storage domain is accessed as an NFS share. By default, Red Hat Enterprise Linux 6 uses NFSv4, which does not require further configuration. However, for NFSv2 and NFSv3 clients, the rpcbind and nfslock services must be running on the host used to run virt-v2v. The network must also be configured to allow NFS access to the storage server. For more details refer to the Red Hat Enterprise Linux Storage Administration Guide.
  2. 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 you are converting a virtual machine for output to both libvirt and Red Hat Enterprise Virtualization, separate virt-v2v.conf files should be used for each conversion. This is because the destination network bridge corresponding to the same source network bridge is usually different for libvirt and Red Hat Enterprise Virtualization output.
    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.
  3. 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.

3.3.1.1. Preparing to convert a virtual machine running Linux

The following is required when converting virtual machines which run Linux, regardless of which hypervisor they are being converted from.

Procedure 3.3. Preparing to convert a virtual machine running Linux

  • 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/. virt-v2v will display an error similar to Example 2.1, "Missing Package error" if software it depends upon for a particular conversion is not available.

    Example 3.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.rpmrhel/6/ecryptfs-utils-82-6.el6.x86_64.rpmrhel/6/ecryptfs-utils-82-6.el6.i686.rpm

    To obtain the relevant RPMs for your environment, repeat these steps for each missing package:

    Procedure 3.4. Obtaining RPMs

    1. Log in to Red Hat Network.
    2. In the Downloads menu, select Packages under Red Hat Enterprise Linux to enter the Package Search page.
    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.

3.3.1.2. Preparing to convert a virtual machine running Windows

Important

virt-v2v does not support conversion of the Windows Recovery Console. If a guest virtual machine has a recovery console installed and VirtIO was enabled during conversion, attempting to boot the recovery console will result in a stop error.
Windows XP x86 does not support the Windows Recovery Console on VirtIO systems, so there is no resolution to this. However, on Windows XP AMD64 and Windows 2003 (x86 and AMD64), the recovery console can be re-installed after conversion. The re-installation procedure is the same as the initial installation procedure. It is not necessary to remove the recovery console first. Following re-installation, the recovery console will work as intended.

Important

When converting a virtual machine running Windows with multiple drives, for output to Red Hat Enterprise Virtualization, it is possible in certain circumstances that additional drives will not be displayed by default. Red Hat Enterprise Virtualization will always add a CD-ROM device to a converted virtual machine. If the virtual machine did not have a CD-ROM device before conversion, the new CD-ROM device may be assigned a drive letter which clashes with an existing drive on the virtual machine. This will render the existing device inaccessible. The occluded disk device can still be accessed by manually assigning it a new drive letter. It is also possible to maintain previous drive letter assignment by manually changing the drive letter assigned to the new CD-ROM device, then rebooting the virtual machine.
The following is required when converting virtual machines running Windows, regardless of which hypervisor they are being converted from. The conversion procedure depends on post-processing by the Red Hat Enterprise Virtualization Manager for completion. See Section 7.2.2, "Configuration changes for Windows virtual machines" for details of the process.

Procedure 3.5. Preparing to convert a virtual machine running Windows

  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 3.2, "Error message when converting a Windows virtual machine without libguestfs-winsupport installed" will be shown:

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

  3. Upload the guest tools ISO to the Red Hat Enterprise Virtualization Manager.
    Note that the guest tools ISO is not required for the conversion process to succeed. However, it is recommended for all Windows virtual machines running on Red Hat Enterprise Virtualization. The Manager installs Red Hat's Windows drivers on the guest virtual machine using the guest tools ISO after the virtual machines have been converted. See Section 7.2.2, "Configuration changes for Windows virtual machines" for details.
    Locate and upload the guest tools ISO as follows:
    1. Locate the guest tools ISO.
      The guest tools ISO is distributed using the Red Hat Network as rhev-guest-tools-iso.rpm, an RPM file installed on the Red Hat Enterprise Virtualization Manager. After installing the Red Hat Enterprise Virtualization Manager, the guest tools ISO can be found at /usr/share/rhev-guest-tools-iso/rhev-tools-setup.iso.
    2. Upload the guest tools ISO.
      Upload the guest tools ISO to the Red Hat Enterprise Virtualization Manager using the ISO uploader.
      Refer to the Red Hat Enterprise Virtualization Administration Guide for more information on uploading ISO files, and installing guest agents and drivers.

3.3.1.3. Preparing to convert a local Xen virtual machine

The following is required when converting virtual machines on a host which used to run Xen, but has been updated to run KVM. It is not required when converting a Xen virtual machine imported directly from a running libvirt/Xen instance.

Procedure 3.6. Preparing to convert a local Xen virtual machine

  • 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 guest_name > guest_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.

3.3.2. Converting a virtual machine

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 over the network. In typical environments, converting a single virtual machine takes approximately 5-10 minutes.

3.3.2.1. virt-v2v

virt-v2v converts virtual machines from a foreign hypervisor to run on Red Hat Enterprise Virtualization. The general command syntax for converting machines to run on Red Hat Enterprise Virtualization is:
virt-v2v -i libvirtxml -o rhev -os storage.example.com:/exportdomain --network rhevm guest_name.xmlvirt-v2v -o rhev -os storage.example.com:/exportdomain --network rhevm guest_namevirt-v2v -ic esx://esx.example.com/?no_verify=1 -o rhev -os storage.example.com:/exportdomain --network rhevm guest_name
A full specification of the parameters which can be used with virt-v2v is available in Section 7.1, "virt-v2v Parameters".

3.3.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 -o rhev -os storage.example.com:/exportdomain --network rhevm guest_name.xml
Where storage.example.com:/exportdomain is the export storage domain, rhevm is the locally managed network to connect the converted virtual machine's network to, and guest_name.xml is the path to the virtual machine's exported xml. You may also use the --bridge parameter to connect to a local network bridge, or specify multiple mappings in /etc/virt-v2v.conf.
To convert the virtual machine from a running Xen hypervisor, run:
virt-v2v -ic xen:/// -o rhev -os storage.example.com:/exportdomain --network rhevm guest_name
Where storage.example.com:/exportdomain is the export storage domain, rhevm is the locally managed network to connect the converted virtual machine's network to, and guest_name is the domain of the Xen virtual machine. You may also use the --bridge parameter to connect to a local network bridge, 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.

3.3.2.3. Converting a remote Xen virtual machine

Xen virtual machines can be converted remotely using SSH. Ensure that the host running the virtual machine is accessible via SSH. Even on a guest with multiple disks, each virtual disk transfer requires a separate SSH session.

Important

It is recommended to set up SSH keys for authentication prior to the remote virtual machine conversion. Otherwise, a user will be required to manually enter SSH credentials for each guest disk being transferred. Failure to enter a password manually in the time after the transfer completes but before the SSH negotiation times out will cause virt-v2v to fail. This is especially important for large disks, as the disk transfer can take an unspecified length of time.
To convert the virtual machine, run:
virt-v2v -o rhev -ic xen+ssh://[email protected] -os storage.example.com:/exportdomain --network rhevm guest_name
Where vmhost.example.com is the host running the virtual machine, storage.example.com:/exportdomain is the export storage domain, rhevm is the locally managed network to connect the converted virtual machine's network to, and guest_name is the domain of the Xen virtual machine. You may also use the --bridge parameter to connect to a local network bridge, 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.

3.3.2.4. Converting a local KVM virtual machine

Use the following procedure to convert a local KVM virtual machine:

Procedure 3.7. Converting a local KVM virtual machine

  1. Stop the virtual machine

    1. Ensure that the virtual machine is stopped prior to running the v2v process. If the virtual machine is in a clustered Red Hat Enterprise Linux HA virtual machine environment, stop and disable the virtual machine resource in cluster node using the command:
      clusvcadm -d vm:<guest>
    2. Run virsh define <path-to-guest.xml> to place the virtual machine in a stopped state under the control of libvirt. This command allows virt-v2v to recognize the virtual machine and enable it to be converted.
  2. Convert the virtual machine

    To convert the virtual machine, run:
    virt-v2v -o rhev -os storage.example.com:/exportdomain --network rhevm guest_name
    Where storage.example.com:/exportdomain is the export storage domain, rhevm is the locally managed network to connect the converted virtual machine's network to, and guest_name is the domain of the KVM virtual machine. You may also use the --bridge parameter to connect to a local network bridge, or specify multiple mappings in /etc/virt-v2v.conf.

3.3.2.5. Converting a remote KVM virtual machine

KVM virtual machines can be converted remotely via SSH. Ensure that the host running the virtual machine is accessible via SSH, and that the virtual machine is stopped prior to running the v2v process. Even on a guest with multiple disks, each virtual disk transfer requires a separate SSH session.

Important

It is recommended to set up SSH keys for authentication prior to the remote virtual machine conversion. Otherwise, a user will be required to manually enter SSH credentials for each guest disk being transferred. Failure to enter a password manually in the time after the transfer completes but before the SSH negotiation times out will cause virt-v2v to fail. This is especially important for large disks, as the disk transfer can take an unspecified length of time.
To convert the virtual machine, run:
virt-v2v -ic qemu+ssh://[email protected]/system -o rhev -os storage.example.com:/exportdomain --network rhevm guest_name
Where kvmhost.example.com is the host running the virtual machine, storage.example.com:/exportdomain is the export storage domain, rhevm is the locally managed network to connect the converted virtual machine's network to, and guest_name is the domain of the KVM virtual machine. You may also use the --bridge parameter to connect to a local network bridge, or specify multiple mappings in /etc/virt-v2v.conf.

3.3.2.6. Converting a VMware ESX / ESX(i) virtual machine

Important

When converting a Windows virtual machine from VMware ESX / ESX(i), 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/ -o rhev -os storage.example.com:/exportdomain --network rhevm guest_name
Where storage.example.com:/exportdomain is the export storage domain, rhevm is the locally managed network to connect the converted virtual machine's network to, and guest_name is the name of the virtual machine. You may also use the --bridge parameter to connect to a local network bridge, or specify multiple mappings in /etc/virt-v2v.conf.
Authenticating to the ESX / ESX(i) server
Connecting to the ESX / ESX(i) server will require authentication. virt-v2v supports password authentication when connecting to ESX / ESX(i). It reads passwords from $HOME/.netrc. The format of this file is described in netrc(5). An example entry is:
machine esx.example.com login root password s3cr3t

Note

The .netrc file must have a permission mask of 0600 to be read correctly by virt-v2v
Connecting to an ESX / ESX(i) server with an invalid certificate
In non-production environments, the ESX / ESX(i) 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 ...

3.3.3. Importing and running the converted virtual machine

On successful completion, virt-v2v will upload the exported virtual machine to the specified export domain. To import and run the converted virtual machine:

Procedure 3.8. Importing and running the converted virtual machine

  1. In the Red Hat Enterprise Virtualization administration portal, select the export domain from the Storage tab. The export domain must have a status of Active.
  2. Select the VM Import tab in the details pane to list the available virtual machines to import.
  3. Select one or more virtual machines and click Import. The Import Virtual Machine(s) window will open.
  4. In the drop-down menus, select the select the Default Storage Domain, Cluster, and Cluster Quota in the data center.
  5. Select the Collapse All Snapshots check box to remove snapshot restore points and include templates in template-based virtual machines. Click OK to import the virtual machines.
For more information on importing virtual machines, refer to the Red Hat Enterprise Virtualization Administration Guide.
Network configuration
virt-v2v cannot currently reconfigure a virtual machine's network configuration. If the converted virtual machine is not connected to the same subnet as the source, its network configuration may have to be updated.

3.3.4. Scripting the v2v process

The entire v2v process can be scripted, enabling the automated batch processing of a large number of virtual machines. The process is broken up into two steps, which must be run on separate hosts.

Procedure 3.9. Scripting the v2v process

  1. Use virt-v2v to convert the virtual machines and copy them to the export storage domain. This step must be run on a Linux host. The process is detailed in Section 3.3.2, "Converting a virtual machine".
  2. Once the conversion is complete, use the Red Hat Enterprise Virtualization administration portal to import the virtual machines from the export storage domain. This step must be run on the Red Hat Enterprise Virtualization Manager server.
    The Import Virtual Machine(s) wizard.

    Figure 3.4. Importing a virtual machine with the Red Hat Enterprise Virtualization administration portal


    Alternately, the Python SDK or the command line can also be used to import the virtual machines from the export storage domain:
    To import the virtual machines using the SDK, use the following:

    Example 3.4. Importing virtual machines from the export storage domain using the SDK

    api = API(url="http(s)://...:.../api",  username="...",  password="...",  filter=False,  debug=True)sd = api.storagedomains.get(id="from-sd-id")import_candidate = sd.vms.get(id="vm-to-import")import_candidate.import_vm(action=params.Action(cluster=api.clusters.get(id="to-cluster-id"), storage_domain=api.storagedomains.get(id="to-sd-id")))

    Note

    When using the SDK method, entities can also be fetched and passed using name=.
    To import the virtual machines using the command line, connect to the Red Hat Enterprise Virtualization Manager shell and use the following command:

    Example 3.5. Importing virtual machines from the export storage domain using the command line

    action vm "vm-to-import" import_vm --storagedomain-identifier "from-sd-id" --cluster-id "to-cluster-id" --storage_domain-id "to-sd-id"

    Note

    When using the command line method, entities can also be fetched and passed using -name.

3.3.5. Scripted bulk v2v process

For bulk import scenarios, it is advantageous to be able to perform the scripted v2v process from a single host. Remote procedure calls to the Red Hat Enterprise Virtualization Manager can be made using the REST API. This enables a single script running on a single Linux host to perform both steps of the v2v process. Figure 3.5, "Scripted bulk v2v process" illustrates the steps performed by the script.
Scripted bulk v2v process

Figure 3.5. Scripted bulk v2v process


The scripted bulk v2v process involves the following steps, as shown in Figure 3.5, "Scripted bulk v2v process":
  1. The virtual machine image is retrieved from the source hypervisor.
  2. The virtual machine image is packaged and copied to the export storage domain.
  3. A remote procedure call is made to the Red Hat Enterprise Virtualization Manager, telling it to import the virtual machine.
  4. The Manager imports the virtual machine from the export storage domain.
To configure and run the scripted bulk v2v process:

Procedure 3.10. Configuring and running the scripted bulk v2v process

  1. Ensure the REST API is enabled on the Red Hat Enterprise Virtualization Manager, and it is accessible from the Linux host running the v2v process. For more information about the REST API, see the Red Hat Enterprise Virtualization REST API Guide.
  2. On the Linux host, create the file v2v.sh with the following contents. Ensure you edit the script to contain appropriate values for your environment.

    Example 3.6. Single host v2v script

    #!/bin/sh# Declare all VMs to importXENDOMAINS=("rhelxen" "rhel5")KVMDOMAINS=("rhelkvm")VMWAREVMS=("rhel54vmware")# Iterate through each Xen domain, performing the conversionfor domain in ${XENDOMAINS[@]}do virt-v2v -ic xen:///localhost -o rhev -os storage.example.com:/exportdomain --network rhevm $domaindone# Iterate through each KVM domain, performing the conversionfor domain in ${KVMDOMAINS[@]}do virt-v2v -o rhev -os storage.example.com:/exportdomain --network rhevm $domaindone# Iterate through each VMware VM, performing the conversionfor vm in ${VMWAREVMS[@]}do virt-v2v -ic esx://esx.example.com/?no_verify=1 -o rhev -os storage.example.com:/exportdomain --network rhevm $vmdone# Call the import VM procedure remotely on the RHEV Managerexport BASE_URL='https://[rhevm-host]'export HTTP_USER='user@internal'export HTTP_PASSWORD='password'curl -o rhevm.cer http://[rhevm-host]/ca.crt# Get the export storage domainscurl -X GET -H "Accept: application/xml" -u "${HTTP_USER}:${HTTP_PASSWORD}" --cacert rhevm.cer ${BASE_URL}/api/storagedomains?search=nfs_export -o exportdomainEXPORT_DOMAIN=`xpath exportdomain '/storage_domains/storage_domain/@id' | sed -e 's/ id=//' | sed -e 's/"//g'`# Get the datacentercurl -X GET -H "Accept: application/xml" -u "${HTTP_USER}:${HTTP_PASSWORD}" --cacert rhevm.cer ${BASE_URL}/api/datacenters?search=NFS -o dcDC=`xpath dc '/data_centers/data_center/@id' | sed -e 's/ id=//' | sed -e 's/"//g'`# Get the clustercurl -X GET -H "Accept: application/xml" -u "${HTTP_USER}:${HTTP_PASSWORD}" --cacert rhevm.cer ${BASE_URL}/api/clusters?search=NFS -o clusterCLUSTER_ELEMENT=`xpath cluster '/clusters/cluster/@id' | sed -e 's/ id=//' | sed -e 's/"//g'`# List contents of export storage domaincurl -X GET -H "Accept: application/xml" -u "${HTTP_USER}:${HTTP_PASSWORD}" --cacert rhevm.cer ${BASE_URL}/api/storagedomains/${EXPORT_DOMAIN}/vms -o vms# For each vm, exportVMS=`xpath vms '/vms/vm/actions/link[@rel="import"]/@href' | sed -e 's/ class="edunwman1" href="//g' | sed -e 's/"/ /g'`for vms in $VMSdo curl -v -u "${HTTP_USER}:${HTTP_PASSWORD}" -H "Content-type: application/xml" -d '<action><cluster><name>cluster_name</name></cluster><storage_domain><name>data_domain</name></storage_domain><overwrite>true</overwrite><discard_snapshots>true</discard_snapshots></action>' --cacert rhevm.cer ${BASE_URL}$vmsdone

    Note

    Use the POST method to export virtual machines with the REST API. For more information about using the REST API, see the Red Hat Enterprise Virtualization REST API Guide.
  3. Run the v2v.sh script. It can take several hours to convert and import a large number of virtual machines.

Chapter 4. Converting from other hypervisors using virt-v2v to KVM

4.1. Introduction

The virt-v2v command converts guest virtual machines from a foreign hypervisor to run on KVM, managed by libvirt. The following guest operating systems are supported by virt-v2v:
  • Red Hat Enterprise Linux 3.9
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Windows XP
  • Windows Vista
  • Windows 7
  • Windows Server 2003
  • Windows Server 2008
The following hypervisors are supported:
  • KVM
  • libvirt-managed Xen
  • VMware ESX / ESX(i) - Version 3.5 or higher
The virt-v2v command enables para-virtualized (virtio) drivers in the converted guest, if possible.
virt-v2v is available on Red Hat Network (RHN) in the Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64) or Red Hat Enterprise Linux Workstation (v.6 for x86_64) channel.
The virt-v2v tool requires root access to the host system.
Some of the new features for virt-v2v starting with Red Hat Enterprise Linux 6 are:
  • The -op and -osd command line options continue to be supported, but are deprecated in favour of -os. There is no deprecation warning when they are used.
  • The -of command line option allows specification of the file format to be used for target storage: raw or qcow2. This feature allows for the conversion of a virtual machine with raw storage to qcow2 and vice versa.
  • The -oa command line option allows the allocation policy of the target storage to be specified: sparse or preallocated. This can be used to convert between sparse and preallocated. Underlying this change, sparse volumes are now supported.
  • The configuration file can now contain target profiles, which specify the storage location, output format and allocation policy for a target. This allows the user to specify --profile<foo> rather than -os<a> -op<b> -oa<oc>.
  • The conversion of Windows virtual machines to libvirt targets is supported.
Refer to the virt-v2v manpage for further details on these and other features.
To install virt-v2v from RHN, ensure the system is subscribed to the appropriate channel, then run:
# yum install virt-v2v

4.2. Preparing to convert a virtual machine

Before a virtual machine can be converted, ensure that the following steps are completed.

Procedure 4.1. Preparing the virtual machine for conversion

  1. Create a local storage domain for transferred storage. virt-v2v copies the guest virtual machine 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. Refer to the Red Hat Enterprise Linux Virtualization Administration Guide for complete instructions on creating various storage pools with either virt-manager or virsh.
  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. From libvirt version 0.8.3 and onward, virt-manager can also create and manage bridges.
  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.
Before a virtual machine running Linux can be converted, ensure that the following steps are completed.

Procedure 4.2. Preparing to convert a virtual machine running Linux

  1. Obtain the software.
    As part of the conversion process, virt-v2v may install a new kernel and drivers on the guest virtual machine. If the virtual machine being converted is registered to Red Hat Network (RHN), the required packages will be automatically downloaded. For environments where RHN is not available, the virt-v2v.conf file references a list of RPMs used for this purpose. The RPMs relevant to your virtual machine must be downloaded manually from RHN and made available in the directory specified by the path-root configuration element, which by default is /var/lib/virt-v2v/software/. virt-v2v will display an error similar to Example 4.1, "Missing Package error" if software it depends upon for a particular conversion is not available.

    Example 4.1. Missing Package error

    virt-v2v: Installation failed because the following files referenced in the configuration file are required, but missing:rhel/5/kernel-2.6.18-128.el5.x86_64.rpmrhel/5/ecryptfs-utils-56-8.el5.x86_64.rpmrhel/5/ecryptfs-utils-56-8.el5.i386.rpm

  2. To obtain the relevant RPMs for your environment, follow these steps:
    1. Log in to Red Hat Network: https://rhn.redhat.com/
    2. In the Customer Portal section of RHN (https://rhn.redhat.com/rhn/software/channels/All.do), select Channels from the Downloads tab.
    3. Select your product, version and architecture to enter the correct channel.
    4. Select the Packages tab from the channel page to display and select a package.
      Select the package exactly matching the one shown in the error message. For the example shown in Example 4.1, "Missing Package error", the first package is kernel-2.6.18-128.el5.x86_64
    5. Select Download Packages at the bottom of the Packages page.
    6. Save the downloaded package to the appropriate directory in /var/lib/virt-v2v/software. For example, the Red Hat Enterprise Linux 5 directory is /var/lib/virt-v2v/software/rhel/5.
Before a guest virtual machine running Windows can be converted, ensure that the following steps are completed.

Important

Guests running Windows can only be converted for output to Red Hat Enterprise Virtualization. The conversion procedure depends on post-processing by the Red Hat Enterprise Virtualization Manager for completion. See Section 4.6, "Configuration changes for Windows virtual machines" for details of the process. Guests running Windows cannot be converted for output to libvirt.

Procedure 4.3. Preparing to convert a virtual machine running Windows

  1. Locate the guest tools ISO.
    As part of the conversion process for guest virtual machines running Windows, the Red Hat Enterprise Virtualization Manager will install drivers using the guest tools ISO.
    After installing the Red Hat Enterprise Virtualization Manager, the guest tools ISO can be found at /usr/share/rhev-guest-tools-iso/rhev-tools-setup.iso.
  2. Upload the guest tools ISO to the Red Hat Enterprise Virtualization Manage using the ISO uploader.
    Refer to the Red Hat Enterprise Virtualization Administration Guide for more information on uploading ISO files, and installing guest agents and drivers.
  3. Ensure that the libguestfs-winsupport package is installed on the host running virt-v2v.
    This package provides support for NTFS, which is used by many Windows systems. If you attempt to convert a virtual machine using NTFS without the libguestfs-winsupport package installed, the conversion will fail.
  4. Ensure that the virtio-win package is installed on the host running virt-v2v.
    This package provides para-virtualized block and network drivers for Windows virtual machines. If you attempt to convert a virtual machine running Windows without the virtio-win package installed, the conversion will fail giving an error message concerning missing files.
The following is required when converting virtual machines on a host which used to run Xen, but has been updated to run KVM. It is not required when converting a Xen virtual machine imported directly from a running libvirt/Xen instance.

Procedure 4.4. Preparing to convert a local Xen virtual machine

  • Obtain the XML for the virtual machine
    virt-v2v uses a libvirt domain description to determine the current configuration of the guest 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 guest_name > guest_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.

4.3. Converting guest 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 the reference table 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.

4.3.1. Converting local virtual machines using virt-v2v

virt-v2v converts guest virtual machines from a foreign hypervisor to run on KVM, managed by libvirt.
virt-v2v -i libvirtxml -op pool --bridge bridge_name guest_name.xmlvirt-v2v -op pool --network netname guest_namevirt-v2v -ic esx://esx.example.com/?no_verify=1 -op pool --bridge bridge_name guest_name
For a list of virt-v2v parameters, refer to Chapter 7, References.

4.3.2. Converting a remote KVM virtual machine

KVM guest 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 qemu+ssh://[email protected]/system -op pool --bridge bridge_name guest_name
Where vmhost.example.com is the host running the virtual machine, pool is the local storage pool to hold the image, bridge_name is the name of a local network bridge to connect the converted virtual machine's network to, and guest_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.
If your virtual machine is Red Hat Enterprise Linux 4 or Red Hat Enterprise Linux 5 and uses a kernel which doesn't support the KVM virtio-drivers, virt-v2v will attempt to install a new kernel during the conversion process. You can avoid this requirement by updating the kernel to a recent version of Red Hat Enterprise Linux 6 which supports virtio prior to conversion..

Note

When converting from KVM, virt-v2v requires that the image of the source virtual machine exists within a storage pool. If the image is not currently in a storage pool, you must create one.

4.3.3. Converting a local Xen virtual machine

Ensure that the guest 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 -op pool --bridge bridge_name guest_name.xml
Where pool is the local storage pool to hold the image, bridge_name is the name of a local network bridge to connect the converted virtual machine's network to, and guest_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 virtual machine 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.

Note

When converting from Xen, virt-v2v requires that the image of the source virtual machine exists in a storage pool. If the image is not currently in a storage pool, you must create one. Contact Red Hat Support for assistance creating an appropriate storage pool.

4.3.4. Converting a remote Xen virtual machine

Xen guest 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 qemu+ssh://[email protected]/system -op pool --bridge bridge_name guest_name
Where vmhost.example.com is the host running the guest virtual machine, pool is the local storage pool to hold the image, bridge_name is the name of a local network bridge to connect the converted virtual machine's network to, and guest_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.
If your virtual machine 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.

Note

When converting from Xen, virt-v2v requires that the image of the source guest exists in a storage pool. If the image is not currently in a storage pool, you must create one. Contact Red Hat Support for assistance creating an appropriate storage pool.

4.3.5. Converting a VMware ESX / ESX(i) virtual machine

Ensure that the guest virtual machine is stopped prior to running the v2v process.
To convert the virtual machine, run:
virt-v2v -ic esx://esx.example.com/ -op pool --bridge bridge_name guest_name
Where esx.example.com is the VMware ESX / ESX(i) server, pool is the local storage pool to hold the image, bridge_name is the name of a local network bridge to connect the converted virtual machine's network to, and guest_name is the name of the virtual machine. You can also use the --network parameter to connect to a locally managed network, or specify multiple mappings in /etc/virt-v2v.conf.

4.3.5.1. Authenticating to the ESX / ESX(i) server

Connecting to the ESX / ESX(i) server will require authentication. virt-v2v supports password authentication when connecting to ESX / ESX(i). 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

Note

The .netrc file must have a permission mask of 0600 to be read correctly by virt-v2v

4.3.5.2. Connecting to an ESX / ESX(i) server with an invalid certificate

In non-production environments, the ESX / ESX(i) 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 ...

4.3.6. Converting a virtual machine running Windows

Important

Guests running Windows can only be converted for output to Red Hat Enterprise Virtualization. The conversion procedure depends on post-processing by the Red Hat Enterprise Virtualization Manager for completion. See Section 4.6, "Configuration changes for Windows virtual machines" for details of the process. Guests running Windows cannot be converted for output to libvirt.
This example demonstrates converting a local (libvirt-managed) Xen virtual machine running Windows for output to Red Hat Enterprise Virtualization. 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 guest virtual machine from an XML file, run:
virt-v2v -i libvirtxml -o rhev -osd storage.example.com:/exportdomain --network rhevm guest_name.xml
Where guest_name.xml is the path to the guest virtual machine's exported xml, and storage.example.com:/exportdomain is the export storage domain. 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 virtual machine 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.

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

4.4.1. Guest network configuration

virt-v2v cannot currently reconfigure a virtual machine's network configuration. If the converted virtual machine is not connected to the same subnet as the source, its network configuration may have to be updated.

4.5. Configuration changes

As well as configuring libvirt appropriately, virt-v2v will make certain changes to a virtual machine to enable it to run on a KVM hypervisor either with or without virtio drivers. These changes are specific to the guest operating system. The details specified here pertain to supported Red Hat Linux versions and Windows.

Table 4.1. virt-v2v changes to Linux virtual machines

ChangeDescription
KernelUn-bootable, that is, Xen para-virtualized kernels will be uninstalled. No new kernel will be installed if there is a remaining kernel which supports virtio. If no remaining kernel supports virtio and the configuration file specifies a new kernel it will be installed and configured as the default.
X reconfigurationIf the virtual machine has X configured, its display driver will be updated. See Table 4.2, "Configured drivers in a Linux guest" for which driver will be used.
Rename block devicesIf reconfiguration has caused block devices to change name, these changes will be reflected in /etc/fstab.
Configure device driversWhether virtio or non-virtio drivers are configured, virt-v2v will ensure that the correct network and block drivers are specified in the modprobe configuration.
initrdvirt-v2v will ensure that the initrd for the default kernel supports booting the root device, whether it is using virtio or not.
SELinuxvirt-v2v will initiate a relabel of the virtual machine on the next boot. This ensures that any changes it has made are correctly labeled according to the virtual machine's local policy.

virt-v2v will configure the following drivers in a Linux virtual machine:

Table 4.2. Configured drivers in a Linux guest

Para-virtualized driver typeDriver module
Displaycirrus
Storagevirtio_blk
Networkvirtio_net
In addition, initrd will preload the virtio_pci driver 

Table 4.3. Other drivers

Driver TypeModule
Displaycirrus
BlockVirtualized IDE
NetworkVirtualized e1000

4.6. Configuration changes for Windows virtual machines

Warning

Before converting Windows guest virtual machines, ensure that the libguestfs-winsupport and virtio-win packages are installed on the host running virt-v2v. These packages provide support for NTFS and Windows para-virtualized block and network drivers. If you attempt to convert a virtual machine using NTFS without the libguestfs-winsupport package installed, the conversion will fail. If you attempt to convert a virtual machine running Windows without the virtio-win package installed, the conversion will fail giving an error message concerning missing files.
virt-v2v can convert virtual machines running Windows XP, Windows Vista, Windows 7, Windows Server 2003 and Windows Server 2008. The conversion process for virtual machines running Windows is slightly to different to the process for virtual machines running Linux. Windows guest virtual machine images are converted as follows:

Procedure 4.5. Converting virtual machines running Windows XP

  1. virt-v2v installs virtio block drivers.
  2. virt-v2v installs the CDUpgrader utility.
  3. virt-v2v copies the virtio block and network drivers to %SystemRoot%\Drivers\VirtIO. The virtio-win package does not include drivers for Windows XP. When using a Windows XP operating system, rtl8139 network drivers are used. Support for rtl8139 must be already available in the virtual machine.
  4. virt-v2v adds %SystemRoot%\Drivers\VirtIO to DevicePath, meaning this directory is automatically searched for drivers when a new device is connected.
  5. virt-v2v makes registry changes to include the virtio block drivers in the CriticalDeviceDatabase section of the registry, and ensures the CDUpgrader service is started at the next boot.
At this point, virt-v2v has completed the conversion. The converted virtual machine is now bootable, but does not yet have all the drivers installed necessary to function correctly. The conversion must be finished by the Red Hat Enterprise Virtualization Manager. The Manager performs the following steps:
  1. The virtual machine is imported and run on the Manager. See the Red Hat Enterprise Virtualization for Servers Administration Guide for details.

    Important

    The first boot stage can take several minutes to run, and must not be interrupted. It will run automatically without any administrator intervention other than starting the virtual machine. To ensure the process is not interrupted, no user should login to the virtual machine until it has quiesced. You can check for this in the Manager GUI.
  2. The guest tools ISO is detected and, if found, installs all the virtio drivers from it, including a re-install of the virtio block drivers.

Note

As the Windows conversion can copy drivers from virtio-win directly to the virtual machine, the guest tools ISO is not required. It is however recommended as the included tools will be kept up to date, and additional tools that are not included in virtio-win can be installed.
(Sebelumnya) 23 : V2V Guide23 : Chapter 5. Converting phy ... (Berikutnya)