Red Hat Enterprise Virtualization 3.1 V2V Guide en US

Red Hat Enterprise Linux 6
V2V Guide
Importing Virtual Machines with virt-v2v
Edition 11
Laura Bailey
Red Hat Engineering Content Services
[email protected]
Laura Novich
[email protected]
Tim Hildred
[email protected]
David Jorm
[email protected]
Red Hat Enterprise Linux 6 V2V Guide 1
Legal Notice
Copyright 2012 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
AttributionShare Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at
http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this
document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section
4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo,
and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux is the registered trademark of Linus Torvalds in the United States and other countries.
Java is a registered trademark of Oracle and/or its affiliates.
XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
All other trademarks are the property of their respective owners.
1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
2 Legal Notice
Abstract
This book is a guide to importing virtual machines from foreign hypervisors to Red Hat Enterprise
Virtualization and KVM managed by libvirt.
Table of Contents
Preface
1. About this Guide
1.1. Documentation Suite
1.2. Audience
2. Document Conventions
2.1. Typographic Conventions
2.2. Pull-quote Conventions
2.3. Notes and Warnings
3. We Need Feedback!
1. Introducing V2V
1.1. Installing virt-v2v
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
3. Converting Virtual Machines to Run on Red Hat Enterprise Virtualization
3.1. Acceptable Converted Storage Output Formats
3.2. Attaching an Export Storage Domain
3.3.2. Converting a Virtual Machine
3.3.3. Importing and Running the Converted Virtual Machine
3.3.4. Scripting the v2v Process
3.3.5. Scripted Bulk v2v Process
4. Migrating to KVM from other hypervisors using virt-v2v
4.1. Preparing to convert a guest
4.2. Converting guests
4.2.1. virt-v2v
4.2.2. Converting a local Xen guest
4.2.3. Converting a remote Xen guest
4.2.4. Converting a VMware ESX guest
4.2.5. Converting a guest running Windows
4.3. Running converted guests
4.4. Configuration changes
4.4.1. Configuration changes for Linux guests
4.4.2. Configuration changes for Windows guests
5. Converting Physical Machines to Virtual Machines
5.1. Prerequisites
5.2. Preparing to Convert a Physical Machine
5.2.1. Install virt-v2v on Conversion Server
5.2.2. Enable Root Login over SSH
5.2.3. Define a Target Profile in virt-v2v.conf
5.2.4. Create the Bootable Media
5.3. Converting Physical Machines to Virtual Machines
5.4. Importing and Running Converted Virtual Machines on Target Hypervisors
4 Table of Contents
6. Debugging and Troubleshooting.
6.1. Debugging V2V conversions
7. References
7.1. virt-v2v Parameters
7.2. Configuration Changes
7.2.1. Configuration Changes for Linux Virtual Machines
7.2.2. Configuration Changes for Windows Virtual Machines
A. Additional Procedures
A.1. Creating Bootable Media
A.1.1. Create a P2V Client Boot CD
A.1.2. Create a Bootable P2V USB Media
A.1.3. Create a PXE Boot Image
B. Revision History
Preface
The Red Hat Enterprise Virtualization platform is a richly featured virtualization management solution
providing fully integrated management across virtual machines. It is based on the leading open source
virtualization platform and provides superior technical capabilities. The platform offers scalability in the
management of large numbers of virtual machines.
1. About this Guide
This guide describes how to import virtual machines from foreign hypervisors to Red Hat Enterprise
Virtualization and KVM managed by libvirt.
1.1. Documentation Suite
The Red Hat Enterprise Virtualization documentation suite provides information on installation,
development of applications, configuration and usage of the Red Hat Enterprise Virtualization platform
and its related products.
Red Hat Enterprise Virtualization Administration Guide describes how to setup, configure and
manage Red Hat Enterprise Virtualization. It assumes that you have successfully installed the Red
Hat Enterprise Virtualization Manager and hosts.
Red Hat Enterprise Virtualization Evaluation Guide enables prospective customers to evaluate the
features of Red Hat Enterprise Virtualization. Use this guide if you have an evaluation license.
Red Hat Enterprise Virtualization Installation Guide describes the installation prerequisites and
procedures. Read this if you need to install Red Hat Enterprise Virtualization. The installation of
hosts, Manager and storage are covered in this guide. You will need to refer to the Red Hat
Enterprise Virtualization Administration Guide to configure the system before you can start using the
platform.
Red Hat Enterprise Virtualization Manager Release Notes contain release specific information for
Red Hat Enterprise Virtualization Managers.
Red Hat Enterprise Virtualization Power User Portal Guide describes how power users can create
and manage virtual machines from the Red Hat Enterprise Virtualization User Portal.
Red Hat Enterprise Virtualization Quick Start Guide provides quick and simple instructions for first
time users to set up a basic Red Hat Enterprise Virtualization environment.
Red Hat Enterprise Virtualization REST API Guide describes how to use the REST API to set up
and manage virtualization tasks. Use this guide if you wish to develop systems which integrate with
Red Hat Enterprise Virtualization, using an open and platform independent API.
Red Hat Enterprise Virtualization Technical Reference Guide describes the technical architecture
of Red Hat Enterprise Virtualization and its interactions with existing infrastructure.
Red Hat Enterprise Virtualization User Portal Guide describes how users of the Red Hat
Enterprise Virtualization system can access and use virtual desktops from the User Portal.
Red Hat Enterprise Linux Hypervisor Deployment Guide describes how to deploy and install the
Hypervisor. Read this guide if you need advanced information about installing and deploying
Hypervisors. The basic installation of Hypervisor hosts is also described in the Red Hat Enterprise
Virtualization Installation Guide.
Red Hat Enterprise Linux V2V Guide describes importing virtual machines from KVM, Xen and
VMware ESX to Red Hat Enterprise Virtualization and KVM managed by libvirt.
1.2. Audience
This guide is intended for system administrators who manage a virtualized environment using Red Hat
Enterprise Virtualization or Red Hat Enterprise Linux. An advanced level of system administration,
preferably including familiarity with virtual machine data center operations, is assumed. This document is
6 Preface
not intended for beginners.
2. Document Conventions
This manual uses several conventions to highlight certain words and phrases and draw attention to
specific pieces of information.
In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The
Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative
but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the
Liberation Fonts set by default.
2.1. Typographic Conventions
Four typographic conventions are used to call attention to specific words and phrases. These
conventions, and the circumstances they apply to, are as follows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight
keycaps and key combinations. For example:
To see the contents of the file my_next_bestselling_novel in your current working
directory, enter the cat my_next_bestselling_novel command at the shell prompt
and press Enter to execute the command.
The above includes a file name, a shell command and a keycap, all presented in mono-spaced bold and
all distinguishable thanks to context.
Key combinations can be distinguished from keycaps by the plus sign that connects each part of a key
combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F2 to switch to a virtual terminal.
The first paragraph highlights the particular keycap to press. The second highlights two key
combinations (each a set of three keycaps with each set pressed simultaneously).
If source code is discussed, class names, methods, functions, variable names and returned values
mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
File-related classes include filesystem for file systems, file for files, and dir for
directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialog box text;
labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
Choose System Preferences Mouse from the main menu bar to launch Mouse
Preferences. In the Buttons tab, click the Left-handed mouse check box and click
Close to switch the primary mouse button from the left to the right (making the mouse
suitable for use in the left hand).
To insert a special character into a gedit file, choose Applications Accessories
Character Map from the main menu bar. Next, choose Search Find from the
Character Map menu bar, type the name of the character in the Search field and click
Next. The character you sought will be highlighted in the Character Table. Double-click
this highlighted character to place it in the Text to copy field and then click the Copy
button. Now switch back to your document and choose Edit Paste from the gedit menu
bar.
The above text includes application names; system-wide menu names and items; application-specific
menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all
distinguishable by context.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable
text. Italics denotes text you do not input literally or displayed text that changes depending on
circumstance. For example:
To connect to a remote machine using ssh, type ssh [email protected] at a shell
prompt. If the remote machine is example.com and your username on that machine is
john, type ssh [email protected].
The mount -o remount file-system command remounts the named file system. For
example, to remount the /home file system, the command is mount -o remount /home.
To see the version of a currently installed package, use the rpm -q package command. It
will return a result as follows: package-version-release.
Note the words in bold italics above username, domain.name, file-system, package, version and
release. Each word is a placeholder, either for text you enter when issuing a command or for text
displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and
important term. For example:
Publican is a DocBook publishing system.
2.2. Pull-quote Conventions
Terminal output and source code listings are set off visually from the surrounding text.
Output sent to a terminal is set in mono-spaced roman and presented thus:
books Desktop documentation drafts mss photos stuff svn
books_tests Desktop1 downloads images notes scripts svgs
Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
8 Preface
package org.jboss.book.jca.ex1;
import javax.naming.InitialContext;
public class ExClient
{
public static void main(String args[])
throws Exception
{
InitialContext iniCtx = new InitialContext();
Object ref = iniCtx.lookup("EchoBean");
EchoHome home = (EchoHome) ref;
Echo echo = home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
}
}
2.3. Notes and Warnings
Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.
Note
Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should
have no negative consequences, but you might miss out on a trick that makes your life easier.
Important
Important boxes detail things that are easily missed: configuration changes that only apply to the
current session, or services that need restarting before an update will apply. Ignoring a box
labeled 'Important' will not cause data loss but may cause irritation and frustration.
Warning
Warnings should not be ignored. Ignoring warnings will most likely cause data loss.
3. We Need Feedback!
If you find a typographical error in this manual, or if you have thought of a way to make this manual
better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/
against the product Red Hat Enterprise Linux.
When submitting a bug report, be sure to mention the manual's identifier: doc-V2V_Guide.
If you have a suggestion for improving the documentation, try to be as specific as possible when
describing it. If you have found an error, include the section number and some of the surrounding text so
we can find it easily.
Chapter 1. Introducing V2V
V2V is an acronym for virtual to virtual, referring to the process of importing virtual machines from one
virtualization platform to another. Red Hat Enterprise Virtualization and Red Hat Enterprise Linux are
capable of performing V2V operations using the virt-v2v command.
virt-v2v
The virt-v2v command converts virtual machines from a foreign hypervisor to run on KVM,
managed by Red Hat Enterprise Virtualization or libvirt. virt-v2v can currently convert Red
Hat Enterprise Linux 4, Red Hat Enterprise Linux 5, Red Hat Enterprise Linux 6, Windows XP,
Windows Vista, Windows 7, Windows Server 2003 and Windows Server 2008 virtual machines
running on Xen, KVM and VMware ESX. virt-v2v enables para-virtualized (virtio) drivers in
the converted virtual machine if possible.
The following guest operating systems are supported by virt-v2v:
Windows XP
Windows Vista
Windows 7
Windows Server 2003
Windows Server 2008
The following source hypervisors are supported by virt-v2v:
Xen
KVM
VMware ESX
1.1. Installing virt-v2v
virt-v2v is run from a Red Hat Enterprise Linux host. It must be installed on the host.
Procedure 1.1. Installing virt-v2v
1. Subscribe to RHN channel
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. Ensure the system is subscribed to the appropriate channel before
installing virt-v2v.
2. Install pre-requisites
If you are converting Windows virtual machines, you must install the libguestfs-winsupport and
virtio-win packages. 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.
The libguestfs-winsupport is available for RHEL Server 6 in the Red Hat Enterprise Linux
10 Chapter 1. Introducing V2V
Server V2V Tools for Windows (v. 6) channel, while the virtio-win package is available in
the Red Hat Enterprise Linux Server Supplementary (v. 6) channel. To install
these packages, ensure that your system has the required permissions to subscribe to both
channels and run the following command as root:
rhn-channel -a -c rhel-x86_64-server-supplementary-6 --user USERNAME --
password PASSWORD
rhn-channel -a -c rhel-x86_64-server-v2vwin-6 --user USERNAME --password
PASSWORD
yum install libguestfs-winsupport virtio-win
3. Install virt-v2v package
As root, run the command:
yum install virt-v2v
4. Run virt-v2v as the root user from a Linux shell.
Chapter 2. Converting Virtual Machines to Run on KVM
Managed by libvirt
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.
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.
Figure 2.1. Converting 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.
12 Chapter 2. Converting Virtual Machines to Run on KVM Managed by libvirt
Figure 2.2. Select host details
Select the Storage tab.
Figure 2.3. The storage tab
Click the plus sign (+) button to add a new storage pool.
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.
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:
a. Login to Red Hat Network
b. Select the Package Search tab.
c. 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
d. In the Where to search field, select In the following architectures and tick
the x86_64 checkbox. Click Search.
e. A list of packages displays. Click the package name identical to the one in the error
message.
f. You will be directed to the Details page, containing detailed descriptions of the package.
Select Download Package at the bottom of the page
g. 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
Important
virt-v2v does not support conversion of the Windows Recovery Console. If a guest 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.
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
yum install virtio-win
If you attempt to convert a virtual machine running Windows without the virtio-win package
converting a Windows virtual machine without virtio-win installed will be shown.
virtio-win installed
configuration file are required, but missing: /usr/share/virtio-
win/drivers/i386/Win2008
Note
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 7.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://[email protected] -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 7.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:
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
Important
Because each disk transfer requires a new SSH session, it is recommended that SSH keys be
set up for authentication prior to the remote VM conversion. 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://[email protected] -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
2.1.2.4. Converting a VMware ESX virtual machine
Important
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.
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
Note
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.
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 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 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. The important element for a successful VM
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 Type Storage
Format
Supported
NFS raw Yes
qcow2 No
FC/iSCSI raw Yes
qcow2 No
Table 3.2. Allocation Policy: Sparse.
Data Domain Type Storage
Format
Supported
NFS raw Yes
qcow2 Yes
FC/iSCSI raw No
qcow2 Yes
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.
Note
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.
20 Chapter 3. Converting Virtual Machines to Run on Red Hat Enterprise Virtualization
3.2. Attaching an Export Storage Domain
An export 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 domain can also be used to backup virtual machines and
templates.
Note
At a given time, an export data domain can only be attached to a single data center.
To attach an export storage domain:
1. Login 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.
Figure 3.1. Attaching an Export Domain
3. Click the Attach Export button to add the storage location where the images are stored.
4. The Attach Export Domain dialog box displays, if there are export domains available.
Figure 3.2. Attach Export Domain Dialog
5. Select the export domain from the list.
6. 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.
Figure 3.3. The Inactive Export Domain
7. Select the new export storage domain on the Storage tab of the Details pane, and click the
Activate button.
8. The export domain will be activated in a few moments and display an Active status.
Figure 3.4. Activated Export Domain
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.
Figure 3.5. 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.
Figure 3.6. Importing a virtual machine
Before a virtual machine can be converted, ensure that the following steps are completed.
1. Create an NFS export domain. virt-v2v can transfer the converted VM directly to an NFS export
storage domain. From the export storage domain, the VM 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.
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.
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.
To obtain the relevant RPMs for your environment, repeat these steps for each missing package:
a. Login to Red Hat Network
b. Select the Package Search tab.
c. 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
d. In the Where to search field, select In the following architectures and tick
the x86_64 checkbox. Click Search.
e. A list of packages displays. Click the package name identical to the one in the error
message.
f. You will be directed to the Details page, containing detailed descriptions of the package.
Select Download Package at the bottom of the page
g. 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 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.
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
yum install libguestfs-winsupport
If you attempt to convert a virtual machine using NTFS without the libguestfs-winsupport package
converting a Windows virtual machine without libguestfs-winsupport installed will be shown.
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
yum install virtio-win
If you attempt to convert a virtual machine running Windows without the virtio-win package
converting a Windows virtual machine without virtio-win installed will be shown.
virtio-win installed
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 virtual machines running on Red Hat Enterprise Virtualization. The
Manager installs drivers on the guest 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.
The Guest Tools ISO is obtained as follows:
a. From the Manager, login to Red Hat Network.
b. Click on the Download Software tab.
c. Select the Red Hat Enterprise Virtualization (x86-64) channel.
d. Select the Red Hat Enterprise Virt Manager for Desktops (v.2 x86) or Red
Hat Enterprise Virt Manager for Servers (v.2 x86) channel, as appropriate
for your subscription.
e. Download Guest Tools ISO for 2.2 and save it locally.
f. Upload the Guest Tools ISO using the ISO Uploader. See the Red Hat Enterprise
Virtualization Administration Guide for instructions.
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.
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:
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 vm-name.xml
virt-v2v -o rhev -os storage.example.com:/exportdomain --network rhevm vm-name
virt-v2v -ic esx://esx.example.com/?no_verify=1 -o rhev -os
storage.example.com:/exportdomain --network rhevm vm-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 vm-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 vm-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
vm-name
managed network 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 --bridge parameter to connect to a local network bridge,
or specify multiple mappings in /etc/virt-v2v.conf.
3.3.2.3. Converting a remote Xen Virtual Machine
Important
Xen virtual machines can be converted remotely via SSH. Ensure that the host running the virtual
machine is accessible via SSH.
virt-v2v -o rhev -ic xen+ssh://[email protected] -os
Where vmhost.example.com is the host running the virtual machine,
storage.example.com:/exportdomain is the export storage domain, rhevm is the locally
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.
3.3.2.4. Converting a local KVM Virtual Machine
virt-v2v -o rhev -os storage.example.com:/exportdomain --network rhevm vm-name
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
Important
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.
virt-v2v -ic qemu+ssh://[email protected]/system -o rhev -os
Where kvmhost.example.com is the host running the virtual machine,
storage.example.com:/exportdomain is the export storage domain, rhevm is the locally
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 Virtual Machine
Important
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.
virt-v2v -ic esx://esx.example.com/ -o rhev -os storage.example.com:/exportdomain
--network rhevm vm-name
managed network to connect the converted virtual machine's network to, and vm-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.
netrc(5). An example entry is:
Note
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:
1. In the Red Hat Enterprise Virtualization administration portal, select the export domain from the
Storage tab.
2. Open the VM Import tab, select the appropriate virtual machine and click Import.
3. The Import Virtual Machine(s) dialog will display. Select the appropriate Destination
Cluster and Destination Storage, then click OK. The import process will run in the background and
may take several minutes. While it is running, the imported virtual machine will appear in the
Virtual Machines tab with a status of Image Locked. You can monitor the status of the
import operation from the Events tab.
4. When the import completes, the status will move to Down and the VM can be manually started.
For more information on importing virtual machines, see 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.
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 Powershell API 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-Vm command performs the import
process, and must be run once per virtual machine.
Example 3.4. Importing all VMs from the export storage domain to the DataStore
storage domain on the Default Data Center
$exportdomain = Get-StorageDomain | ? {$_.Name -eq "export"}
$datadomain = Get-StorageDomain | ? {$_.Name -eq "DataStore"}
$dc = Select-DataCenter Name=Default
$cluster = Select-Cluster Name=Default
$candidates = Get-VmImportCandidates -StorageDomainId
$exportdomain.StorageDomainId -DataCenterId $dc.DataCenterId
foreach ($candidate in $candidates)
{
Import-Vm -DataCenterId $dc.DataCenterId -SourceDomainId
$exportdomain.StorageDomainId -DestDomainId $datadomain.StorageDomainId -
ClusterId $cluster.ClusterId -VmId $candidate.VmId
}
Detailed documentation for the PowerShell API is available in the Red Hat Enterprise Virtualization
PowerShell API Guide.
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.7, Scripted bulk v2v process illustrates the steps performed by the script.
Figure 3.7. Scripted bulk v2v process
The scripted bulk v2v process involves the following steps, as shown in Figure 3.7, 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 import storage domain.
To configure and run 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.5. Single host v2v script
#!/bin/sh
# Declare all VMs to import
XENDOMAINS=("rhelxen" "rhel2")
KVMDOMAINS=("rhelkvm")
VMWAREVMS=("rhel54vmware")
# Iterate through each Xen domain, performing the conversion
for domain in ${XENDOMAINS[@]}
do
virt-v2v -ic xen:///localhost -o rhev -os
storage.example.com:/exportdomain --network rhevm $domain
done
# Iterate through each KVM domain, performing the conversion
for domain in ${KVMDOMAINS[@]}
do
virt-v2v -o rhev -os storage.example.com:/exportdomain --network
rhevm $domain
done
# Iterate through each VMware VM, performing the conversion
for vm in ${VMWAREVMS[@]}
do
virt-v2v -ic esx://esx.example.com/?no_verify=1 -o rhev -os
storage.example.com:/exportdomain --network rhevm $vm
done
# Call the import VM procedure remotely on the RHEV Manager
# Set API variables
export BASE_URL='http://rhevm.example.com'
export HTTP_USER='[email protected]'
export HTTP_PASSWORD='password123'
# Get the storage domains
wget --auth-no-challenge --http-user=${HTTP_USER} --http-
password=${HTTP_PASSWORD} --header="Accept: application/xml"
${BASE_URL}/rhevm-api/storagedomains?search=name%3Dexport2 -O exportdomain
EXPORT_DOMAIN=`xpath exportdomain '/storage_domains/storage_domain/@id' |
sed -e 's/ id=//' | sed -e 's/"//g'`
# Get the datacenter
${BASE_URL}/rhevm-api/datacenters?search=name%3D23compat -O dc
DC=`xpath dc '/data_centers/data_center/@id' | sed -e 's/ id=//' | sed -e
's/"//g'`
# Get the cluster
${BASE_URL}/rhevm-api/clusters?search=name%3DDefault -O cluster
CLUSTER_ELEMENT=`grep "cluster id" cluster`
echo ${CLUSTER_ELEMENT}
# List contents of export storage domain
${BASE_URL}/rhevm-api/datacenters/${DC}/storagedomains/${EXPORT_DOMAIN}/vms
-O vms
# For each vm, export
VMS=`xpath vms '/vms/vm/actions/link[@rel="import"]/@href' | sed -e 's/
href="//' | sed -e 's/"//'`
echo
'<action><cluster><name>23compat</name></cluster><storage_domain><name>data2
</name></storage_domain></action>' > importaction
password=${HTTP_PASSWORD} --header="Accept: application/xml" --
header="Content-Type: application/xml" --post-file=importaction
${BASE_URL}$VMS
3. Run the v2v.sh script. It can take several hours to convert and import a large number of virtual
machines.
Chapter 4. Migrating to KVM from other hypervisors using virt-
v2v
The virt-v2v command converts guests from a foreign hypervisor to run on KVM, managed by libvirt.
The following guest operating systems are supported by virt-v2v:
Windows XP
Windows Vista
Windows 7
Windows Server 2003
Windows Server 2008
The virt-v2v command can currently convert guests running the listed operating systems running on
libvirt-managed Xen, KVM, and VMware ESX. 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.
New features and changes
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 guest 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 guests to libvirt targets is supported.
Refer to the virt-v2v manpage for further details on these and other features.
Installing virt-v2v
To install virt-v2v from RHN, ensure the system is subscribed to the appropriate channel, then run:
yum install virt-v2v
4.1. Preparing to convert a guest
36 Chapter 4. Migrating to KVM from other hypervisors using virt-v2v
Before a guest 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.
Figure 4.1. Select host details
Select the Storage tab.
Figure 4.2. The storage tab
Click the plus sign (+) button to add a new storage pool.
Figure 4.3. Adding a storage pool
2. Create local network interfaces.
The local machine must have an appropriate network to which the converted guest can connect.
This is likely to be a bridge interface. A bridge interface can be created using standard tools on
the host. Since version 0.8.3, virt-manager can also create and manage bridges.
use cases.
If your guest 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 guest only has a single network interface, it is simpler to use the --network or --bridge
parameters, rather than modifying virt-v2v.conf.
Preparing to convert a guest running Linux
Before a guest running Linux can be converted, ensure that the following steps are completed.
As part of the conversion process, virt-v2v may install a new kernel and drivers on the guest. 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
guest 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.
To obtain the relevant RPMs for your environment, follow these steps:
a. Log in to Red Hat Network: https://rhn.redhat.com/
b. In the Customer Portal section of RHN (https://rhn.redhat.com/rhn/software/channels/All.do),
select the Software Channels tab.
c. Select your product, version and architecture to enter the correct channel.
d. Select the Packages tab.
e. Use the Filter by Package function to locate the missing package.
f. 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
g. Select Download Packages at the bottom of the package details page.
h. 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.
Preparing to convert a guest running Windows
Before a guest 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.4.2, Configuration changes for Windows guests for
details of the process. Guests running Windows cannot be converted for output to libvirt.
1. Obtain the Guest Tools ISO
As part of the conversion process for guests running Windows, the Red Hat Enterprise
Virtualization Manager will install drivers using the Guest Tools ISO. See Section 4.4.2,
Configuration changes for Windows guests for details of the process. The Guest Tools ISO is
obtained as follows:
a. From the Red Hat Enterprise Virtualization Manager, Login to Red Hat Network
b. Click on Download Software
c. Select the Red Hat Enterprise Virtualization (x86-64) channel
d. Select the Red Hat Enterprise Virt Manager for Desktops (v.2 x86) or Red
Hat Enterprise Virt Manager for Desktops (v.2 x86) channel, as appropriate
for your subscription.
e. Download Guest Tools ISO for 2.2 and save it locally
2. Upload the Guest Tools ISO to the Red Hat Enterprise Virtualization Manager
Upload the Guest Tools ISO using the ISO Uploader. See the Red Hat Enterprise Virtualization for
Servers Administration Guide for instructions.
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 guest 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 guests. If you attempt to convert
a guest running Windows without the virtio-win package installed, the conversion will fail giving an
error message concerning missing files.
Preparing to convert a local Xen guest
The following is required when converting guests 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 guest
virt-v2v uses a libvirt domain description to determine the current configuration of the guest,
including the location of its storage. Before starting the conversion, obtain this from the host
running the guest with the following command:
4.2. Converting guests
Once you have prepared to convert the guests, use virt-v2v to perform the actual conversions. This
section provides the steps to convert the guests, and the reference table for virt-v2v. Note that
conversions are resource intensive processes, involving copying the whole disk image for a guest. In
typical environments, converting a single guest takes approximately 5-10 minutes.
4.2.1. virt-v2v
virt-v2v converts guests from a foreign hypervisor to run on KVM, managed by libvirt.
virt-v2v -i libvirtxml -op pool --bridge brname vm-name.xml
virt-v2v -op pool --network netname vm-name
virt-v2v -ic esx://esx.example.com/?no_verify=1 -op pool --bridge brname vm-name
Parameters
-i input Specifies the input method to obtain the guest for conversion. The
default is libvirt. Supported options are:
libvirt Guest argument is the name of a libvirt domain.
libvirtxml Guest argument is the path to an XML file containing
a libvirt domain.
-ic URI Specifies the connection to use when using the libvirt input method. If
omitted, this defaults to qemu:///system. virt-v2v can currently
automatically obtain guest storage from local libvirt connections, ESX
connections, and connections over SSH. Other types of connection are
not supported.
-o method Specifies the output method. If no output method is specified, the default
is libvirt. Supported output methods are:
libvirt, create a libvirt guest. See the -oc and -op options. -op
must be specified for the libvirt output method.
rhev, create a guest on a Red Hat Enterprise Virtualization Export
storage domain, which can later be imported using the manager.
The -osd or Export storage domain must be specified for the rhev
output method.
-oc URI Specifies the libvirt connection to use to create the converted guest. If
omitted, this defaults to qemu:///system. Note that virt-v2v must be able
to write directly to storage described by this libvirt connection. This
makes writing to a remote connection impractical at present.
-op pool Specifies the pool which will be used to create new storage for the
converted guest.
-osd domain Specifies the path to an existing Red Hat Enterprise Virtualization
Export storage domain.
The domain must be in the format <host > <path>; for example,
storage.example.com:/rhev/export. The nfs export must be
mountable and writable by the machine running virt-v2v.
-f file | --config
file
Load the virt-v2v configuration from file. Defaults to /etc/virt-v2v.conf if it
exists.
-n network | --
network network
Map all guest bridges or networks which don't have a mapping in the
configuration file to the specified network.
This option cannot be used in conjunction with --bridge.
-b bridge | --bridge
bridge
configuration file to the specified bridge.
This option cannot be used in conjunction with --network.
--help Display brief help.
--version Display version number and exit.
4.2.2. Converting a local Xen guest
Ensure that the guest'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 from an XML file, run:
virt-v2v -i libvirtxml -op 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 guest's network to, and vm-name.xml is the path to the guest'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.
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.2.3. Converting a remote Xen guest
Xen guests can be converted remotely via SSH. Ensure that the host running the guest is accessible via
SSH.
To convert the guest, run:
virt-v2v -ic xen+ssh://[email protected] -op pool --bridge brname vm-name
Where vmhost.example.com is the host running the guest, pool is the local storage pool to hold the
image, brname is the name of a local network bridge to connect the converted guest's network to, and
vm-name is the domain of the Xen guest. You may also use the --network parameter to connect to a
locally managed network, or specify multiple mappings in /etc/virt-v2v.conf.
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.2.4. Converting a VMware ESX guest
Ensure that the guest is stopped prior to running the v2v process.
To convert the guest, run:
virt-v2v -ic esx://esx.example.com/ -op 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 guest's network to, and vm-
name is the name of the guest. You may also use the --network parameter to connect to a locally
managed network, or specify multiple mappings in /etc/virt-v2v.conf.
the netrc(5) man page. An example entry is:
Note
4.2.5. Converting a guest 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.4.2, Configuration changes for Windows guests for
details of the process. Guests running Windows cannot be converted for output to libvirt.
This example demonstrates converting a local (libvirt-managed) Xen guest running Windows for output
to Red Hat Enterprise Virtualization. Ensure that the guest'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 from an XML file, run:
virt-v2v -i libvirtxml -o rhev -osd storage.example.com:/exportdomain --network
rhevm vm-name.xml
Where vm-name.xml is the path to the guest'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.
4.3. Running converted guests
On successful completion, virt-v2v will create a new libvirt domain for the converted guest with the
same name as the original guest. It can be started as usual using libvirt tools, for example virt-
manager.
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.
4.4. Configuration changes
As well as configuring libvirt appropriately, virt-v2v will make certain changes to a guest 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 based Linux distributions and
Windows.
4.4.1. Configuration changes for Linux guests
Table 4.1. virt-v2v changes to Linux guests
Change Description
Kernel Un-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 reconfiguration If the guest has X configured, its display driver will
be updated. See GUEST DRIVERS for which
driver will be used.
Rename block devices If changes have caused block devices to change
name, these changes will be reflected in /etc/fstab
Configure device drivers Whether virtio or non-virtio drivers are configured,
virt-v2v will ensure that the correct network and
block drivers are specified in the modprobe
configuration.
initrd virt-v2v will ensure that the initrd for the default
kernel supports booting the root device, whether
it is using virtio or not.
SELinux virt-v2v will initiate a relabel of the guest on the
next boot. This ensures that any changes it has
made are correctly labeled according to the
guest's local policy.
virt-v2v will configure the following drivers in a Linux guest:
Table 4.2. Configured drivers in a Linux Guest
Para-virtualized driver type Driver module
Display cirrus
Storage virtio_blk
Network virtio_net
In addition, initrd will preload the virtio_pci driver
Other drivers
Display cirrus
Block Virtualized IDE
Network Virtualized e1000
4.4.2. Configuration changes for Windows guests
Warning
Before converting Windows guests, 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 guest using NTFS
without the libguestfs-winsupport package installed, the conversion will fail. If you attempt to
convert a guest running Windows without the virtio-win package installed, the conversion will fail
giving an error message concerning missing files.
virt-v2v can convert guests running Windows XP, Windows Vista, Windows 7, Windows Server 2003
and Windows Server 2008. The conversion process for guests running Windows is slightly to different
to the process for guests running Linux. Windows guest images are converted as follows:
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 7 and Windows XP. When using these
operating systems, rtl8139 network drivers are used. Support for rtl8139 must be already
available in the guest.
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 guest 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 guest 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 guest. To
ensure the process is not interrupted, no user should login to the guest 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 guest, 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.
Chapter 5. Converting Physical Machines to Virtual Machines
Read this chapter for information about converting physical machines to virtual machines with the new
Red Hat Physical-to-Virtual (P2V) solution, Virt P2V.
Virt P2V is comprised of both virt-p2v-server, included in the virt-v2v package, and the P2V client,
Virt-P2V.iso, available from the Red Hat Customer Portal. Virt-P2V.iso is a bootable disk image
based on a customized Red Hat Enterprise Linux 6 image. Booting a machine from Virt-P2V.iso and
connecting to a V2V conversion server that has virt-v2v installed allows data from the physical machine
to be uploaded to the conversion server and converted for use with either Red Hat Enterprise
Virtualization, or KVM managed by libvirt.
Important
P2V is strictly a Red Hat Enterprise Linux 6 only feature, and requires virt-v2v-0.8.7-6.el6 or later.
You cannot P2V to a Red Hat Enterprise Linux 5 conversion server, or with a virt-v2v package
previous to version 0.8.7-6.el6.
5.1. Prerequisites
For a physical machine to be converted using the P2V client, it must meet basic hardware requirements
in order to successfully boot the P2V client:
Must be bootable from PXE, Optical Media(CD, DVD), or USB.
At least 512Mb of RAM.
An ethernet connection.
Console access (keyboard, video, mouse).
An operating system supported by virt-v2v:
Windows XP
Windows Vista
Windows 7
Windows Server 2003
Windows Server 2008
5.2. Preparing to Convert a Physical Machine
Before you use P2V, you must first prepare your conversion server and download and prepare the Virt-
P2V.iso boot media.
5.2.1. Install virt-v2v on Conversion Server
A conversion server is any physical server running Red Hat Enterprise Linux 6 or higher with the virt-
v2v package installed on it. To install virt-v2v follow the instructions in Section 1.1, Installing virt-
v2v.virt-v2v version 0.8.1 or higher is required.
5.2.2. Enable Root Login over SSH
Now that virt-v2v is installed, the conversion server must be prepared to accept P2V client connections.
The P2V client connects to the conversion server as root using ssh so root login over ssh must be
allowed on the conversion server.
Enable root login over ssh:
1. As root, edit the sshd_config file in /etc/ssh/sshd_config:
nano /etc/ssh/sshd_config
2. Find the Authentication section of the file, and add a line that says "PermitRootLogin yes". This
line may already exist and be commented out with a "#". In this case, remove the "#".
# Authentication:
#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
3. Save the updated /etc/ssh/sshd_config.
4. Restart the SSH server:
service ssh restart
You can now connect to the conversion server as root over ssh.
5.2.3. Define a Target Profile in virt-v2v.conf
Now that you are able to connect to the conversion server as root, it must be preconfigured with details
about what to do with the virtual machine it creates. These details are given as a target profile in the
/etc/virt-v2v.conf file on the conversion server.
Define a Target Profile in virt-v2v.conf:
1. As root, edit /etc/virt-v2v.conf:
nano /etc/virt-v2v.conf
2. Scroll to the end of the file. Before the final </virt-v2v>, add the following:
<profile name="myrhev">
<method>rhev</method>
<storage format="raw" allocation="preallocated">
nfs.share.com:/export1
</storage>
<network type="default">
<network type="network" name="rhevm"/>
</network>
</profile>
Where:
Profile Name is an arbitrary, descriptive target profile name.
Method is the destination hypervisor type (rhev or libvirt).
Storage Format is the output storage format, either raw or qcow2.
48 Chapter 5. Converting Physical Machines to Virtual Machines
Allocation is the output allocation policy, either preallocated or sparse.
Network type specifies the network to which a network interface should be connected when
imported into Red Hat Enterprise Virtualization. The first network type entry contains details
about network configuration before conversion, the second network type entry maps to an after
conversion configuration. In the given example, any detected network card is to be mapped to
the managed network called rhevm.
Important
The value associated with the <storage format> tag (in the above example
"nfs.share.com:/export1") must match the value associated with the <method> tag. In this
example, since the output method is "rhev", the value associated with storage must be an
initialized NFS share. For the libvirt method, the storage format value must be an initialized
storage domain that exists locally on the conversion server, for example "default".
You have created a target profile that defines what will happen to the virtual machine that results from
this P2V conversion.
5.2.4. Create the Bootable Media
P2V uses bootable media to create a bootable image of the hard drive of a physical machine and send it
to the conversion server for import into a hypervisor. You will need a Red Hat Network account to
download the Virt-P2V.iso.
Download the Virt-P2V.iso from the Red Hat Customer Portal:
1. Login to Red Hat Network.
2. Select the Download tab, and click Downloads.
3. In the Filter By Download Software field, enter Virt-P2V. Click Go.
4. A list of packages displays. Click the link to Virt-P2V.
5. The Details page displays, containing a description of the package. Select Virt-P2V.iso and
save it on the conversion server.
Create the appropriate bootable media:
The Virt-P2V.iso file can be used three ways: as a bootable disk, a PXE boot image, and as a bootable
USB device.
Burn the ISO to a blank CD-ROM or DVD-ROM, and insert it into the disk drive of the physical
machine that is to be converted. To boot properly from this boot media, some changes to BIOS
settings may be required to ensure that the optical disk drive is first in the boot order.
Use the ISO to create a bootable USB media. To boot properly from this boot media, some changes
to BIOS settings may be required to ensure that the USB device is first in the boot order. In addition,
some BIOSes do not support booting from USB media. The P2V client disk image is approximately 90
MB, so the USB device must be large enough to hold the disk image.
Prepare a PXE Boot image for your existing PXE server. To boot from PXE, some changes to BIOS
settings may be required to ensure that the PXE boot is first in the boot order.
More information about creating boot media can be found in Appendix A, Additional Procedures.
You have finished preparing and are now ready to move on to converting a physical machine to a virtual
machine.
5.3. Converting Physical Machines to Virtual Machines
By now you have prepared a conversion server and your chosen bootable media. Next you will boot the
P2V client, connect to your conversion server, and convert your physical machine. The conversion
process can take a long time, especially when large physical disks are being converted.
Converting a virtual machine to a physical machine:
1. Boot the P2V client boot media that you created in preparation for your conversion. Because P2V
client is built upon a Red Hat Enterprise Linux 6 live image, the Red Hat Enterprise Linux 6 splash
image is displayed while the tool is booting.
2. Configure networking. Generally the P2V client configures networking automatically using DHCP. If
it is unable to configure networking automatically, you will need to configure it manually. IP
Address, Gateway, and Prefix are required fields. Enter values that are appropriate for your
network, and click Use these network settings.
Figure 5.1. Network configuration on the P2V client
Important
If for some reason manual configuration is preferred, disconnect the physical machine from
the network entirely before booting. Then you will be able to enter a networking
configuration directly and reconnect the physical machine to the network.
3. When networking is configured, you are prompted for connection details for the conversion server.
These include Hostname (either hostname or IP address), Username (this must be root), and
Password. Enter these details and click Connect.
Figure 5.2. Connecting to the conversion server
4. After connecting to your conversion server configure the virtual hardware that will be attached to
the converted physical machine, as well as select which physical hardware should be converted.
At least one Fixed Storage device must be converted; the one containing the operating system
installation.
Figure 5.3. Configuring the virtual machine
5. Select a Destination Profile from the drop down menu. These reflect the target profiles
included in the /etc/virt-v2v.conf file on the conversion server.
6. Enter a Name for the Virtual Machine that will result from the conversion.
7. The Number of CPUs and Memory(MB) are automatically detected and completed. Change
them if more CPUs and/or Memory are desired on the outputted virtual machine.
8. When Target Properties, Fixed Storage, Removable Media, and Network
Interfaces have all been configured as desired, click Convert.
Figure 5.4. Conversion in process
9. When the conversion is complete, a Success message is displayed. You can shutdown the
physical machine.
Figure 5.5. Conversion successfully completed
You have converted your physical machine into a virtual machine. You can now import and run it on a
hypervisor.
5.4. Importing and Running Converted Virtual Machines on Target
Hypervisors
Now that you have converted your physical machine to a virtual machine, it can be run on a hypervisor.
For information on running the converted physical machine as a virtual machine on Red Hat Enterprise
Linux using virt-manager, see:
Section 2.1.3, Running Converted Virtual Machines
For information on importing and running the converted physical machine as a virtual machine in Red Hat
Enterprise Virtualization using the Red Hat Enterprise Virtualization Manager, see:
Section 3.3.3, Importing and Running the Converted Virtual Machine
Chapter 6. Debugging and Troubleshooting.
6.1. Debugging V2V conversions
Problems encountered when attempting a V2V conversion can be more easily explained to engineers or
support services if debugging messages are enabled when V2V is run.
1. Before running a V2V conversion, enter the following in the terminal:
export LIBGUESTFS_TRACE=1
export LIBGUESTFS_DEBUG=1
2. The above exports increase the verbosity of the V2V process, causing virt-v2v to print out
messages as it runs. These messages will be displayed in the terminal from which virt-v2v is run.
3. Simple redirection can be used to print virt-v2v debug messages to a file. Instead of running the
conversion normally like this:
virt-v2v can be run like this:
LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -i libvirtxml -os pool --
bridge brname vm-name.xml ... 2>&1 | tee virt-v2v.log
54 Chapter 6. Debugging and Troubleshooting.
Chapter 7. References
This chapter contains reference information for virt-v2v.
7.1. virt-v2v Parameters
The following parameters can be used with virt-v2v:
-i input Specifies the input method to obtain the guest for conversion. The
default is libvirt. Supported options are:
libvirt
Guest argument is the name of a libvirt domain.
libvirtxml
Guest argument is the path to an XML file containing a libvirt
domain.
-ic URI Specifies the connection to use when using the libvirt input method. If
omitted, this defaults to qemu:///system.
virt-v2v can currently automatically obtain guest storage from local
libvirt connections, ESX connections, and connections over SSH. Other
types of connection are not supported.
-o method Specifies the output method. If no output method is specified, the default
is libvirt. Supported output methods are:
libvirt
Create a libvirt guest. See the -oc and -os options. -os must
be specified for the libvirt output method.
rhev
Create a guest on a Red Hat Enterprise Virtualization Export
storage domain, which can later be imported using the
manager. The export storage domain must be specified using
-os for the rhev output method.
-oc URI Specifies the libvirt connection to use to create the converted guest. If
omitted, this defaults to qemu:///system. Note that virt-v2v must be able
to write directly to storage described by this libvirt connection. This
makes writing to a remote connection impractical at present.
-os storage Specifies the location where new storage will be created for the
converted guest. This is dependent on the output method, specified by
the -o parameter.
For the libvirt output method, this must be the name of a storage
pool. For the rhev output method, this specifies the NFS path to a Red
Hat Enterprise Virtualization export storage domain. Note that the
storage domain must have been previously initialized by the Red Hat
Enterprise Virtualization Manager. The domain must be in the format
<host>:<path>, for example, rhev-
storage.example.com:/rhev/export.
The NFS export must be mountable and writable by the host running
virt-v2v.
-op pool (deprecated) This parameter is still supported, but is deprecated in favor of -os.
-osd domain
(deprecated)
This parameter is still supported, but is deprecated in favor of -os.
-of format Specifies the on-disk format which will be used for the converted guest.
Currently supported options are raw and qcow2. The output format
does not need to be the same as the source format - virt-v2v can
convert from raw to qcow2 and vice versa. If not specified, the
converted guest will use the same format as the source guest.
-oa allocation Specifies whether the converted guest should use sparse or
preallocated storage. The allocation scheme does not need to be
the same as the source scheme - virt-v2v can convert from sparse to
preallocated and vice versa. If not specified, the converted guest will
use the same allocation scheme as the source.
-on outputname Renames the guest. If this option is not used, then the output name is
the same as the input name.
-f file | --config
file
Load a virt-v2v configuration from file. Multiple configuration files can be
specified; these will be searched in the order in which they are
specified. If no configuration is specified, the defaults are /etc/virt-
v2v.conf and /var/lib/virt-v2v/virt-v2v.db in that order.
Important
When overriding the default configuration details, we recommend
also specifying /var/lib/virt-v2v/virt-v2v.db, as it
contains default configuration data required for conversions.
-n network | --
network network
configuration file to the specified network.
This option cannot be used in conjunction with --bridge.
-b bridge | --bridge
bridge
configuration file to the specified bridge.
This option cannot be used in conjunction with --network.
-p profile | --
profile profile
Use the default values for output method, output storage and network
mappings from profile in the configuration file.
--root=filesystem In a multi-boot virtual machine, select the root file system to be
converted. The default value for this option is --root=ask. When this
option is selected, virt-v2v lists the possible root file systems and
asks the user which file system should be used.
Warning
In versions of Red Hat Enterprise Linux earlier than version 6.3,
the default value was --root=single, which could cause virt-
v2v to fail when a multi-boot virtual machine was detected.
Other available options include:
first
Selects the first root device if multiple devices are detected.
56 Chapter 7. References
Since this is a heuristic, the choice may not always be correct.
single
Specifies that there is only one root device available to use.
virt-v2v will fail if more than one device is detected.
<path>
Specifies a particular root device to use, for example, --
root=/dev/sda2 would specify the second partition on the
first hard drive. If the specified device does not exist or was
not detected as a root device, virt-v2v will fail.
--list-profiles Display a list of target profile names specified in the configuration file.
--help Display brief help.
--version Display version number and exit.
7.2. Configuration Changes
As well as configuring libvirt appropriately, virt-v2v will make certain changes to a guest 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 based Linux distributions and
Windows.
7.2.1. Configuration Changes for Linux Virtual Machines
Table 7.1. virt-v2v changes to Linux virtual machines
Change Description
Kernel Unbootable kernels (i.e. 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 reconfiguration If the guest has X configured, its display driver will
be updated. See Table 7.2, Configured drivers in
a Linux Guest for which driver will be used.
Rename block devices If changes have caused block devices to change
name, these changes will be reflected in
/etc/fstab
Configure device drivers Whether virtio or non-virtio drivers are configured,
virt-v2v will ensure that the correct network
and block drivers are specified in the modprobe
configuration.
initrd virt-v2v will ensure that the initrd for the
default kernel supports booting the root device,
whether it is using virtio or not.
SELinux virt-v2v will initiate a relabel of the guest on
the next boot. This ensures that any changes it
has made are correctly labeled according to the
guest's local policy.
virt-v2v will configure the following drivers in a Linux guest:
Table 7.2. Configured drivers in a Linux Guest
Para-virtualized driver type Driver module
Display cirrus
Storage virtio_blk
Network virtio_net
In addition, initrd will preload the virtio_pci driver
Other drivers
Display cirrus
Block Virtualized IDE
Network Virtualized e1000
7.2.2. Configuration Changes for Windows Virtual Machines
Warning
Before converting Windows 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. See Section 2.1.1.2,
Preparing to convert a virtual machine running Windows for details.
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 virtual machine images
are converted as follows:
1. virt-v2v installs virtio block drivers.
2. virt-v2v installs the CDUpgrader utility.
3. virt-v2v copies virtio block and network drivers to %SystemRoot%\Drivers\VirtIO. The virtio-
win package does not include network drivers for Windows 7 and Windows XP. For those
operating systems, the rtl8139 network drivers are used. rtl8139 support must be already
available in the guest.
4. virt-v2v adds %SystemRoot%\Drivers\VirtIO to DevicePath, meaning this directory is
automatically searched for drivers when a new device is detected.
5. virt-v2v makes registry changes to include the virtio block drivers in the
CriticalDeviceDatabase section of the registry, and ensure the CDUpgrader service is
started at the next boot.
At this point, virt-v2v has completed the conversion. The converted virtual machine is now fully
functional, and the conversion is complete for output to KVM managed by libvirt. If the virtual machine is
being converted for output to Red Hat Enterprise Virtualization, the Red Hat Enterprise Virtualization
Manager will perform additional steps to complete the conversion:
1. The virtual machine is imported and run on the Manager. See the Red Hat Enterprise Virtualization
Administration Guide for details.
58 Chapter 7. References
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. If the Guest Tools ISO has been uploaded to the Manager, as detailed in Section 2.1.1.2,
Preparing to convert a virtual machine running Windows, the Manager attaches the Guest Tools
CD to the virtual machine.
3. CDUpgrader detects the Guest Tools ISO and installs all the virtio drivers from it, including
additional tools that are not included in virtio-win. The virtio drivers are re-installed if the drivers in
the Guest Tools ISO are newer than the ones previously installed from virtio-win. This ensures
that the tools are kept up to date.
Additional Procedures
A.1. Creating Bootable Media
The P2V Client can be booted from PXE boot, a bootable USB device, or optical media. Scripts for
preparing boot options are included with the Virt-P2V.iso in the LiveOS directory.
A.1.1. Create a P2V Client Boot CD
The exact series of steps that produces a CD from an image file varies greatly from computer to
computer, depending on the operating system and disc burning software installed. This procedure
describes burning an ISO image to disk using Brasero which is included in RHEL6.
Make sure that your disc burning software is capable of burning discs from image files. Although this is
true of most disc burning software, exceptions exist.
1. Insert a blank, writable CD into your computer's CD or DVD burner.
2. Open the Applications menu, choose the Sound and Video sub-menu, and click Brasero
Disk Burner.
3. Click the Burn Image button.
4. Click the Click here to select a disc image button.
5. Browse to the Virt-P2V.iso and select it for burning.
6. Click Burn.
Your BIOS may need to be changed to allow booting from your DVD/CD-ROM drive.
A.1.2. Create a Bootable P2V USB Media
1. As root, mount the Virt-P2V.iso:
mkdir /mnt/p2vmount
mount -o loop Virt-P2V.iso /mnt/p2vmount
2. Attach your USB device to the computer. For the livecd-iso-to-disk script to function, the USB
filesystem must be formatted vfat, ext[234] or btrfs.
3. From a terminal as root run the livecd-iso-to-disk script:
bash /mnt/p2vmount/LiveOS/livecd-iso-to-disk /PATH/TO/Virt-P2V.iso
/dev/YOURUSBDEVICE
4. When the script finishes successfully, eject the USB device.
A.1.3. Create a PXE Boot Image
1. As root, mount the Virt-P2V.iso
mkdir /mnt/p2vmount
mount -o loop Virt-P2V.iso /mnt/p2vmount
2. From a terminal as root run the livecd-iso-to-pxeboot script:
60 Additional Procedures
bash /mnt/p2vboot/LiveOS/livecd-iso-to-pxeboot /PATH/TO/Virt-P2V.iso
When the command successfully completes, there is a tftpboot directory in the directory from
which the command was run.
3. Rename the newly created tftpboot directory to a more descriptive name:
mv tftpboot/ p2vboot/
4. Copy the p2vboot/ sub-directory to the /tftpboot directory:
cp -R p2vboot/ /tftpboot/
Set up your DHCP, TFTP and PXE server to serve /tftpboot/p2vboot/pxeboot.0 .
Note
The initrd image contains the whole CD ISO. You will notice when pxebooting that initrd can
take a long time to download. This is normal behavior.
Revision History
Revision 11-7 2012-07-18 Anthony Towns
Rebuild for Publican 3.0
Revision 11-6 Monday June 18 2012 Laura Novich
Version for 6.3 GA
Revision 11-5 Monday June 04 2012 Laura Bailey
Corrected note regarding storage pool requirement (BZ#709279).
Revision 11-4 Monday May 14 2012 Laura Bailey
Added details about Virt P2V requirements.
Revision 11-3 Monday March 26 2012 Laura Bailey
Corrected a number of minor typographical errors and improved clarity (BZ#713997).
Revision 11-2 Monday March 5 2012 Dayle Parker
Made admonition title style consistent throughout book.(BZ#732866).
Labelled figures, edited screenshot images in Section 5.3. (BZ#732865).
Revision 11-1 Friday February 24 2012 Laura Bailey
Included the V2V migration chapter (BZ#709279).
Revision 10-0 Monday January 23 2012 Laura Bailey
Corrected word usage according to style guide (BZ#733005).
Updated use of the --file parameter (BZ#749766).
Corrected channel command usage (BZ#765869).
Revision 9-0 Thursday December 08 2011 Laura Bailey
Reinstated P2V-related content previously included by Tim Hildred.
Adjusted formatting to make replaceable content more readily identifiable.
Updated parameters available for use with virt-v2v.
Added admonition about attempting to convert the Windows Recovery Console.
Revision 7-0 Friday December 02 2011 Laura Bailey
Release for GA of Red Hat Enterprise Linux 6.2.
Revision 6-0 Friday July 22 2011 Tim Hildred
Promoted and emphasised section detailing acceptable storage format/allocation policy combinations
Changed warnings to importants
Revision 5-0 Friday June 17 2011 Tim Hildred
Fixed the following bugs:
BZ#712320 -Added warnings about transferring multiple HDD images over ssh.
BZ#696050 -Can't import qcow2/preallocated guest to NFS data domain when convert a qcow2/sparse
guest with -oa preallocated parameter. .
BZ#710161 -Section detailing the installation of the pre-reqs for virt-v2v is not detailed enough.
Revision 4-0 Monday April 11 2011 Cheryn Tan
BZ#694773 - It is not required for upload Guest Tools ISO for guest to install driver
62 Revision History
BZ#694778 - It's better to add converting a remote KVM virtual machine to RHEV to guide
BZ#694775 - The virt-v2v convert command syntax "virt-v2v -os pool --network netname vm-name"
need update
Revision 3-0 Friday April 8 2011 Cheryn Tan
BZ#694437 - The time stamp of copyright should be updated
BZ#694441 - Can't obtain virt-v2v relevant software with the V2V Guide steps
BZ#694442 - The doc should update about portmap service, as portmap is replaced by rpcbind in
RHEL6
Revision 2-0 Monday November 29 2010 David Jorm
Complete draft except for example 3.3
Revision 1-0 Monday October 25 2010 David Jorm
Initial build

Red Hat Enterprise Virtualization 3.1 V2V Guide en US

Uploaded by

Copyright:

Available Formats

Red Hat Enterprise Virtualization 3.1 V2V Guide en US

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Red Hat Enterprise Virtualization 3.1 V2V Guide en US

Uploaded by

Copyright:

Available Formats

Red Hat Enterprise Linux 6

You might also like