Edition 1
1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
Mono-spaced Bold
To see the contents of the filemy_next_bestselling_novel
in your current working directory, enter thecat my_next_bestselling_novel
command at the shell prompt and press Enter to execute the command.
Press Enter to execute the command.Press Ctrl+Alt+F2 to switch to the first virtual terminal. Press Ctrl+Alt+F1 to return to your X-Windows session.
mono-spaced bold
. For example:
File-related classes includefilesystem
for file systems,file
for files, anddir
for directories. Each class has its own associated set of permissions.
Choose Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).→ → from the main menu bar to launchTo insert a special character into a gedit file, choose → → from the main menu bar. Next, choose → from the Character Map menu bar, type the name of the character in the Search field and click . 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 button. Now switch back to your document and choose → from the gedit menu bar.
Mono-spaced Bold Italic
or Proportional Bold Italic
To connect to a remote machine using ssh, typessh
at a shell prompt. If the remote machine isusername
@domain.name
example.com
and your username on that machine is john, typessh john@example.com
.Themount -o remount
command remounts the named file system. For example, to remount thefile-system
/home
file system, the command ismount -o remount /home
.To see the version of a currently installed package, use therpm -q
command. It will return a result as follows:package
.
package-version-release
Publican is a DocBook publishing system.
mono-spaced roman
and presented thus:
books Desktop documentation drafts mss photos stuff svn books_tests Desktop1 downloads images notes scripts svgs
mono-spaced roman
but add syntax highlighting as follows:
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")); } }
virt-v2v
command.
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.
virt-v2v
:
virt-v2v
:
virt-v2v
is run from a Red Hat Enterprise Linux host. It must be installed on the host.
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
.
Install pre-requisites
rhn-channel -a rhel-x86_64-server-supplementary-6 --user USERNAME --password PASSWORD
rhn-channel -a rhel-x86_64-server-v2vwin-6 --user USERNAME --password PASSWORD
yum install libguestfs-winsupport virtio-win
Install virt-v2v package
yum install virt-v2v
virt-v2v
as the root user from a Linux shell.
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.
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.
virt-manager
can also create and manage bridges. For more information on bridged networking with libvirt, see the Red Hat Enterprise Linux Virtualization Guide.
virt-v2v.conf
. This step is optional, and is not required for most use cases.
/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.
--network
or --bridge
parameters, rather than modifying virt-v2v.conf
.
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.
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.
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
/var/lib/virt-v2v/software
. For Red Hat Enterprise Linux 6, the directory is /var/lib/virt-v2v/software/rhel/6
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
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.
virt-v2v
. This package provides para-virtualized block and network drivers for Windows guests. The virtio-win package is provided by the RHEL Server Supplementary (v. 6 64-bit x86_64) channel. Ensure your system is subscribed to this channel, then run the following command as root:
yum install virtio-win
virt-v2v: Installation failed because the following files referenced in the configuration file are required, but missing: /usr/share/virtio-win/drivers/i386/Win2008
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.xmlThis 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.
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.
virt-v2v
converts guests from a foreign hypervisor to run on KVM, managed by libvirt. The general command syntax for converting machines to run on KVM managed by libvirt is:
virt-v2v -i libvirtxml -os pool --bridge brname vm-name.xml virt-v2v -ic xen+ssh://root@vmhost.example.com -os pool --bridge brname vm-name virt-v2v -ic esx://esx.example.com/?no_verify=1 -os pool --bridge brname vm-name
virt-v2v
is available in Section 5.1, “virt-v2v Parameters”.
virt-v2v -i libvirtxml -os pool --bridge brname vm-name.xml
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
.
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.
virt-v2v -ic xen+ssh://root@vmhost.example.com -os pool --bridge brname vm-name
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
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.
virt-v2v -ic esx://esx.example.com/ -os pool --bridge brname vm-name
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.
virt-v2v
supports password authentication when connecting to ESX. It reads passwords from $HOME/.netrc. The format of this file is described in the netrc(5) man page. An example entry is:
machine esx.example.com login root password s3cr3t
.netrc
file must have a permission mask of 0600 to be read correctly by virt-v2v
... -ic esx://esx.example.com/?no_verify=1 ...
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
.
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.
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.
Data Domain Type | Storage Format | Supported |
---|---|---|
NFS | raw | Yes |
qcow2 | No | |
FC/iSCSI | raw | Yes |
qcow2 | No |
Data Domain Type | Storage Format | Supported |
---|---|---|
NFS | raw | Yes |
qcow2 | Yes | |
FC/iSCSI | raw | No |
qcow2 | Yes |
-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.
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.
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.
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.
virt-v2v.conf
. This step is optional, and is not required for most use cases.
/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.
--network
or --bridge
parameters, rather than modifying virt-v2v.conf
.
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.
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.
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
/var/lib/virt-v2v/software
. For Red Hat Enterprise Linux 6, the directory is /var/lib/virt-v2v/software/rhel/6
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
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.
virt-v2v
. This package provides para-virtualized block and network drivers for Windows guests. The virtio-win package is provided by the RHEL Server Supplementary (v. 6 64-bit x86_64) channel. Ensure your system is subscribed to this channel, then run the following command as root:
yum install virtio-win
virt-v2v: Installation failed because the following files referenced in the configuration file are required, but missing: /usr/share/virtio-win/drivers/i386/Win2008
virsh dumpxml vm-name > vm-name.xmlThis 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.
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.
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
virt-v2v
is available in Section 5.1, “virt-v2v Parameters”.
virt-v2v -i libvirtxml -o rhev -os storage.example.com:/exportdomain --network rhevm vm-name.xml
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
.
virt-v2v -ic xen:/// -o rhev -os storage.example.com:/exportdomain --network rhevm vm-name
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
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
.
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.
virt-v2v -o rhev -ic xen+ssh://root@vmhost.example.com -os storage.example.com:/exportdomain --network rhevm vm-name
vmhost.example.com
is the host running the virtual machine, storage.example.com:/exportdomain
is the export storage domain, rhevm
is the locally managed network to connect the converted virtual machine's network to, and 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
.
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.
virt-v2v -o rhev -os storage.example.com:/exportdomain --network rhevm vm-name
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
is the domain of the KVM virtual machine. You may also use the --bridge
parameter to connect to a local network bridge, or specify multiple mappings in /etc/virt-v2v.conf
.
virt-v2v -ic qemu+ssh://root@kvmhost.example.com/system -o rhev -os storage.example.com:/exportdomain --network rhevm vm-name
kvmhost.example.com
is the host running the virtual machine, storage.example.com:/exportdomain
is the export storage domain, rhevm
is the locally managed network to connect the converted virtual machine's network to, and vm-name
is the domain of the KVM virtual machine. You may also use the --bridge
parameter to connect to a local network bridge, or specify multiple mappings in /etc/virt-v2v.conf
.
virt-v2v -ic esx://esx.example.com/ -o rhev -os storage.example.com:/exportdomain --network rhevm vm-name
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
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
.
virt-v2v
supports password authentication when connecting to ESX. It reads passwords from $HOME/.netrc. The format of this file is described in netrc(5). An example entry is:
machine esx.example.com login root password s3cr3t
.netrc
file must have a permission mask of 0600 to be read correctly by virt-v2v
... -ic esx://esx.example.com/?no_verify=1 ...
virt-v2v
will upload the exported virtual machine to the specified export domain. To import and run the converted virtual machine:
Image Locked
. You can monitor the status of the import operation from the Events tab.
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”.
Import-Vm
command performs the import process, and must be run once per virtual machine.
$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 }
v2v.sh
with the following contents. Ensure you edit the script to contain appropriate values for your environment.
#!/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='rhevadmin@domain.example.com' 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 wget --auth-no-challenge --http-user=${HTTP_USER} --http-password=${HTTP_PASSWORD} --header="Accept: application/xml" ${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 wget --auth-no-challenge --http-user=${HTTP_USER} --http-password=${HTTP_PASSWORD} --header="Accept: application/xml" ${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 wget --auth-no-challenge --http-user=${HTTP_USER} --http-password=${HTTP_PASSWORD} --header="Accept: application/xml" ${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 wget --auth-no-challenge --http-user=${HTTP_USER} --http-password=${HTTP_PASSWORD} --header="Accept: application/xml" --header="Content-Type: application/xml" --post-file=importaction ${BASE_URL}$VMS
v2v.sh
script. It can take several hours to convert and import a large number of virtual machines.
export LIBGUESTFS_TRACE=1 export LIBGUESTFS_DEBUG=1
virt-v2v -i libvirtxml -os pool --bridge brname vm-name.xml
LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -i libvirtxml -os pool --bridge brname vm-name.xml ... 2>&1 | tee virt-v2v.log
virt-v2v
.
virt-v2v
:
-i input
|
Specifies the input method to obtain the guest for conversion. The default is libvirt. Supported options are:
|
-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:
|
-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 Use
-os instead. This parameter is still supported, but is deprecated in favor of -os .
|
-osd domain
|
DEPRECATED Use
-os instead. 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.
|
-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
|
Map all guest bridges or networks which don't have a mapping in the 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. |
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.
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 5.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:
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 |
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 different to the process for virtual machines running Linux. Windows virtual machine images are converted as follows:
%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.
%SystemRoot%\Drivers\VirtIO
to DevicePath
, meaning this directory is automatically searched for drivers when a new device is detected.
CriticalDeviceDatabase
section of the registry, and ensure the CDUpgrader service is started at the next boot.
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:
Revision History | ||||||
---|---|---|---|---|---|---|
Revision 7-0 | Friday December 02 2011 | |||||
| ||||||
Revision 6-0 | Friday July 22 2011 | |||||
| ||||||
Revision 5-0 | Friday June 17 2011 | |||||
| ||||||
Revision 4-0 | Monday April 11 2011 | |||||
| ||||||
Revision 3-0 | Friday April 8 2011 | |||||
| ||||||
Revision 2-0 | Monday November 29 2010 | |||||
| ||||||
Revision 1-0 | Monday October 25 2010 | |||||
|