Cari di RHE Linux 
    RHE Linux User Manual
Daftar Isi
(Sebelumnya) 23 : Chapter 3. Converting vir ...24 : Virtualization Administra ... (Berikutnya)

V2V Guide

Chapter 5. Converting physical machines to virtual machines

Read this chapter for information about converting physical machines to virtual machines with the 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, available from the Red Hat Customer Portal as rhel-6.x-p2v.iso. rhel-6.x-p2v.iso is a bootable disk image based on a customized Red Hat Enterprise Linux 6 image. Booting a machine from rhel-6.x-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.
Note that the host must be running Red Hat Enterprise Linux 6. Other host configurations will not work.

Important

Adhere to the following rules. Failure to do so may cause the loss of data and disk malfunction:
  • The Physical to Virtual (P2V) feature requires a Red Hat Enterprise Linux 6 virtualization host with virt-v2v-0.8.7 or later. You can check your version of virt-v2v by running $ rpm -q virt-v2v.
  • Note that you cannot convert to a Red Hat Enterprise Linux 5 conversion server, or with a virt-v2v package previous to version 0.8.7-6.el6.
  • A number of operating systems can be converted from physical machines to virtual machines, but be aware that there are known issues converting physical machines using software RAID. Red Hat Enterprise Linux 6 machines with a filesystem root on a software RAID md device may be converted to guest virtual machines. Red Hat Enterprise Linux 4 and Red Hat Enterprise Linux 5 guest virtual machines with their filesystem root on a software RAID md device cannot be converted to virtual machines. There is currently no workaround available.

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 512 MB of RAM.
  • An ethernet connection.
  • Console access (keyboard, video, mouse).
  • An operating system supported by virt-v2v:
    • Red Hat Enterprise Linux 4
    • Red Hat Enterprise Linux 5
    • Red Hat Enterprise Linux 6
    • Windows XP
    • Windows Vista
    • Windows 7
    • Windows Server 2003
    • Windows Server 2008

5.2. Preparing to convert a physical machine

Before you use P2V, you must first prepare your conversion server and download and prepare the rhel-6.x-p2v.iso boot media. For full instructions see the Red Hat Enterprise Linux Installation Guide. Note that there is one ISO image for both i386 and x86_64 architectures.

5.2.1. Install virt-v2v on a 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.7-6 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 2mPermitRootLogin yes#StrictModes yes#MaxAuthTries 6#MaxSessions 10
  3. Save the updated /etc/ssh/sshd_config.
  4. Restart the SSH server:
    service sshd 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.
    • 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 rhel-6.x-p2v.iso ISO. Follow the instructions on preparing bootable media from the Red Hat Enterprise Linux Installation Guide. Note that there is only one ISO image for both i386 and x86_64 architectures.
The latest release of rhel-6.x-p2v.iso can be found at https://rhn.redhat.com/rhn/software/channel/downloads/Download.do?cid=10358
Create the appropriate bootable media:
The rhel-6.x-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 100 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 physical machine to a virtual 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.
    Configure Networking.

    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.
    Connect to conversion server.

    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, and select which physical hardware should be converted. At least one Fixed Storage device must be converted, including the device containing the operating system installation.
    Enter the details for the outputted virtual machine.

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

    Figure 5.4. Conversion in process


  9. When the conversion is complete, a success message is displayed. You can shut down the physical machine.
    The screen reads "A guest has been successfully created on the target server. Remove the temporary boot device from this machine and press 'Power Off' to continue." A Power Off button appears below the text in this window.

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

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.
Exporting the debugging messages increases 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.
Simple redirection can be used to print virt-v2v debug messages to a file. The conversion runs normally like this:
virt-v2v -i libvirtxml -os pool --bridge bridge_name guest_name.xml
Instead, edit this command to export the debug messages to the virt-v2v.log file. To do this, prefix the above command with the environment variables LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1, and redirect the output to the virt-v2v.log file by adding ... 2>&1 | tee virt-v2v.log to the end of the command.
LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -i libvirtxml -os pool --bridge bridge_name guest_name.xml ... 2>&1 | tee virt-v2v.log

6.2. Known issue with iscsi/mpath/scsi storage volumes

It is not possible at the moment with virt-v2v to convert a guest with a storage volume in a pool of any of the following types:
  • iscsi
  • mpath
  • scsi
Converting such a guest results in a failed conversion. There is no workaround for this issue.

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 with the libvirt input method. If omitted, this defaults to qemu:///system. Note, this only works when virt-v2v is run as root.
virt-v2v can currently automatically obtain guest storage from local libvirt connections, ESX / ESX(i) 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 if virt-v2v is run as root. 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
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.
-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. 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 virtual machine to enable it to run on a KVM hypervisor either with or without virtio drivers. These changes are specific to the guest operating system. The details specified here apply to supported Red Hat Enterprise Linux distributions and Windows.

7.2.1. Configuration changes for Linux virtual machines

Table 7.1. virt-v2v changes to Linux virtual machines

ChangeDescription
KernelUnbootable 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 reconfigurationIf 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 devicesIf reconfiguration has caused block devices to change name, these changes will be reflected in /etc/fstab.
Configure device driversWhether virtio or non-virtio drivers are configured, virt-v2v will ensure that the correct network and block drivers are specified in the modprobe configuration.
initrdvirt-v2v will ensure that the initrd for the default kernel supports booting the root device, whether it is using virtio or not.
SELinuxvirt-v2v will initiate a relabel of the 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 typeDriver module
Displaycirrus
Storagevirtio_blk
Networkvirtio_net
In addition, initrd will preload the virtio_pci driver 
Other drivers
Displaycirrus
BlockVirtualized IDE
NetworkVirtualized 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.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 virtual machine.
  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.

    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 log in 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.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 rhel-6.x-p2v.iso 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 rhel-6.x-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 rhel-6.x-p2v.iso:
    mkdir /mnt/p2vmount
    mount -o loop rhel-6.x-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/rhel-6.x-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 rhel-6.x-p2v.iso
    mkdir /mnt/p2vmount
    mount -o loop rhel-6.x-p2v.iso /mnt/p2vmount
  2. From a terminal as root run the livecd-iso-to-pxeboot script:
    bash /mnt/p2vboot/LiveOS/livecd-iso-to-pxeboot /PATH/TO/rhel-6.x-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 History
Revision 11-44Tue Feb 19 2013Dayle Parker
Version for 6.4 GA release.
Revision 11-42Tues Feb 5 2013Dayle Parker
Minor corrections throughout book.
Revision 11-41Thurs Jan 31 2013Dayle Parker
Updated procedures relating to the guest tools ISO in Chapter 3 and 4 for BZ#881469.
Updated "Importing and running the converted virtual machine" in Chapter 3 for BZ#881469.
Revision 11-39Thurs Jan 24 2013Dayle Parker
Changed subsection title 2.1. Converting a virtual machine to 2.1. Preparing to convert a virtual machine; minor reorganization of section.
Minor grammatical edits throughout book.
Revision 11-38Wed Jan 16 2013Dayle Parker
Made corrections for QE review in BZ#881469.
Revision 11-37Thurs Dec 20 2012Dayle Parker
Made corrections for QE review in BZ#881469.
Revision 11-36Thurs Dec 13 2012Dayle Parker
Corrected ISO filenames for BZ#713997.
Revision 11-35Wed Nov 28 2012Dayle Parker
Applied QE feedback to Chapter 3 - new RHEV screenshots and typo fixes.
Revision 11-34Tue Nov 27 2012Dayle Parker
Applied QE feedback to 'Scripting the v2v Process' section for BZ#754884.
Revision 11-33Thu Nov 22 2012Laura Novich
fixed script in the Single host v2v script section for https://bugzilla.redhat.com/show_bug.cgi?id=832361
Revision 11-32Thurs Nov 22 2012Dayle Parker
Applied SME feedback to 'Scripting the v2v Process' section for BZ#754884.
Revision 11-31Wed Nov 21 2012Dayle Parker
Edited and republished 'Scripting the v2v Process' section for BZ#754884.
Revision 11-30Fri Nov 16 2012Dayle Parker
Clarified Guest Tools ISO paragraph for BZ#754887.
Revision 11-29Mon Nov 12 2012Dayle Parker
Added note about REST API in 3.3.5. Scripted bulk v2v process for BZ#832361.
Revision 11-28Thurs Nov 8 2012Dayle Parker
Corrected typos for BZ#713997.
Revision 11-27Wed Nov 7 2012Dayle Parker
Edited minor typos in topics.
Revision 11-26Wed Nov 7 2012Dayle Parker
Updated script in 3.3.5. Scripted bulk v2v process for BZ#832361.
Revision 11-24Mon Nov 5 2012Dayle Parker
Updated ISO filename and link for BZ#713997 in 5.2.4. Create the bootable media and A.1. Creating bootable media.
Revision 11-23Fri Nov 2 2012Dayle Parker
Corrections for BZ#832019 in Chapter 4 and 5.
Revision 11-22Thu Nov 1 2012Laura Novich
added section to troubleshooting BZ841542
Revision 11-21Thurs Nov 1 2012Dayle Parker
Corrections for BZ#754888 in Chapter 6 and 7.
Revision 11-20Thurs Nov 1 2012Dayle Parker
Additions for BZ#754886 in Chapter 2.
Corrections for BZ#754887 in Chapter 3.
Revision 11-19Wed Oct 31 2012Laura Novich
added .iso download information
Revision 11-18Wed Oct 31 2012Dayle Parker
Fixes for BZ#754886 in Chapter 2.
Revision 11-18Wed Oct 31 2012Laura Novich
added .iso download information
Revision 11-17Wed Oct 31 2012Laura Novich
changed revision history page and chapter 1 BZ754885
Revision 11-16Tue Oct 30 2012Laura Novich
fixed typo in chapter 3
Revision 11-15Mon Oct 29 2012Laura Novich
fixed typo in chapter 3
Revision 11-14Mon Oct 29 2012Dayle Parker
Made virtualization terms consistent throughout book for BZ#825894
Revision 11-13Thu Oct 25 2012Laura Novich
finished v2v migration chapter - added ESX(i) as supported
Revision 11-12Wed Oct 24 2012Laura Novich
finished v2v migration chapter
Revision 11-11Wed Oct 24 2012Laura Novich
fixed P2V chapter and reference libvirt chapter - https://bugzilla.redhat.com/show_bug.cgi?id=816930
Revision 11-10Wed Oct 24 2012Laura Novich
fixed P2V chapter - https://bugzilla.redhat.com/show_bug.cgi?id=816930
Revision 11-9Mon Oct 15 2012Laura Novich
fixed BZ754885 - changed Revision History and changed Front Matter.
Revision 11-8Sun Oct 14 2012Laura Novich
fixed ch5
Revision 11-7Sun Oct 14 2012Laura Novich
fixed ch5
Revision 11-6Monday June 18 2012Laura Novich
Preparing for GA
Revision 11-5Monday June 04 2012Laura Bailey
Corrected note regarding storage pool requirement (BZ#709279).
Revision 11-4Monday May 14 2012Laura Bailey
Added details about Virt P2V requirements.
Revision 11-3Monday March 26 2012Laura Bailey
Corrected a number of minor typographical errors and improved clarity (BZ#713997).
Revision 11-2Monday March 5 2012Dayle Parker
Made admonition title style consistent throughout book.(BZ#732866).
Labelled figures, edited screenshot images in Section 5.3. (BZ#732865).
Revision 11-1Friday February 24 2012Laura Bailey
Included the V2V migration chapter (BZ#709279).
Revision 10-0Monday January 23 2012Laura 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-0Thursday December 08 2011Laura 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-0Friday December 02 2011Laura Bailey
Release for GA of Red Hat Enterprise Linux 6.2.
Revision 6-0Friday July 22 2011Tim Hildred
Promoted and emphasised section detailing acceptable storage format/allocation policy combinations
Changed warnings to importants
Revision 5-0Friday June 17 2011Tim Hildred
Fixed the following bugs:
BZ#712320 - Added warnings about transferring multiple HDD images over ssh.
BZ#696050 - Cannot 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-0Monday April 11 2011Cheryn Tan
Fixed the following bugs:
BZ#694773 - It is not required for upload Guest Tools ISO for guest to install driver
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-0Friday April 8 2011Cheryn Tan
Fixed the following bugs:
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-0Monday November 29 2010David Jorm
Complete draft except for example 3.3
Revision 1-0Monday October 25 2010David Jorm
Initial build
(Sebelumnya) 23 : Chapter 3. Converting vir ...24 : Virtualization Administra ... (Berikutnya)