- Previously, when the virt-v2v utility was used to convert a virtual machine (VM) from a foreign hypervisor (such as Xen or VMware) to Red Hat Enterprise Virtualization, it set the vm_snapshot_id identifier of all disks of that VM incorrectly. Consequently, various problems occurred while doing a large number of tasks on this VM from the side of Red Hat Enterprise Virtualization. With this update, a unique identifier is generated for each disk in the described scenario, thus preventing this bug.
- Previously, a converted Microsoft Windows XP guest could terminate unexpectedly on boot with a STOP error (also known as Blue Screen of Death, or BSoD). The error could be triggered if the guest was configured with a CPU or chipset driver that malfunctioned when the CPU or chipset was not present; this only occurred when converting Physical-to-Virtual, or P2V, machines. With this update, the registry keys related to certain services known to cause problems are deleted during the conversion process. The converted guest now boots as expected after the conversion process.
- When converting a Physical-to-Virtual (P2V) or a Virtual-to-Virtual (V2V) machine to run on Red Hat Enterprise Virtualization systems, virt-v2v failed with a write error when attempting to write to the target export storage domain. This happened if the target system did not use the standard UID and GID for ownership of the target Red Hat Enterprise Virtualization export storage domain. With this update, virt-v2v checks the local system for the UID of "vdsm" and the GID of "kvm". If present, the values are treated as the values required to write to the Red Hat Enterprise Virtualization export storage domain, and the conversion succeeds in the described scenario.
- When running the virt-v2v utility and the
/var/lib/virt-v2v/directory did not contain any files other than
virt-v2v.db, the conversion failed with an error message similar to:
/transfer0w34SV: umount: /sysroot/transfer0w34SV: not mounted at /usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 193. at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Config.pm line 262The underlying source code has been modified to correctly handle situations when there is no software available locally for installation into a guest during conversion, and so ensures that the conversion succeeds.
- When converting a Xen HVM guest with references to
/dev/xvdXdevices in the fstab or GRUB device map file, the
/dev/xvdXdevices in these files were not updated. With this update, the virt-v2v and virt-p2v utilities now look in the Xen HVM guest configuration files during the conversion process for devices named
/dev/xvdXas well as
/dev/hdX. Both are treated as identical and either is converted to
/dev/vdX. References to Xen paravirtualized block devices in fstab and device map of Xen HVM guest are now correctly updated during the conversion.
- Previously, the virt-v2v utility unconditionally marked all converted guests as a Server-type workload. This caused Desktop-type workload guests to be displayed incorrectly in Red Hat Enterprise Virtualization Manager. This update adds a new command-line option,
--vmtype, which forces the conversion process to mark the newly created Red Hat Enterprise Virtualization virtual machine as either
--vmtypeis omitted, virt-v2v attempts to determine the correct type.
- The new VMware Tools are split into multiple packages. Previously, when converting such a guest, the VMware Tools packages were not removed during the conversion process. This could cause warnings to be displayed in the converted guest or cause the guest to function incorrectly. The conversion process has been updated to recognize the new VMware Tools packages and remove them. The VMware Tools packages are now correctly removed during the conversion.
- When attempting to convert a guest which was accessed over an SSH connection and the target host had an SSH login banner configured, the conversion process could become unresponsive. With this update, SSH login banners are ignored and the conversion process completes as expected.
- Previously, the virt-v2v utility could be used to move a virtual machine from one environment to another, but not to move a workload from a physical server. With this update, users can move the server data over the network to a virtual environment by using the new virt-p2v tool.
- If the user used third-party kernel modules in a guest machine, and updated the kernel, the conversion could fail or the converted guest could fail to operate correctly. This was because the conversion process did not recognize third-party kernel modules. Users can now specify a "user-custom" capability for the guest operating system in the
virt-v2v.conffile. All the dependencies of "user-custom" are installed during the conversion process.