.`virt-v2v` can now use vmx configuration files to convert VMware guests
The `virt-v2v` utility now includes the `vmx` input mode, which enables the user to convert a guest virtual machine from a VMware vmx configuration file. Note that to do this, you also need access to the corresponding VMware storage, for example by mounting the storage using NFS. It is also possible to access the storage using SSH, by adding the `-it ssh` parameter.
Description of problem: Having access to the VMware folders where the vmx live I would like the ability to use the vmx file as a source. Getting around the need for the export to OVA would be a great time saver to the entire migration/conversion process.
Version-Release number of selected component (if applicable): any version but 7.3 forward.
How reproducible: currently this would be a feature request.
Steps to Reproduce:
Additional info: Currently this would be used at Intermountain and Amex accounts.
Dev-acking this for RHEL 7.4.
We may not actually ship it for RHEL 7.4 (except for the customer
involved in this case).
I have a half-working implementation at the moment.
Upstream in commits:
Full list of commits is now:
Verify the bug with below builds:
1:Ability to convert Virtual Machines via vmx is a new feature ,and we can check it in virt-v2v manpage.
INPUT FROM VMWARE VMX
Virt-v2v is able to import guests from VMware’s vmx files. This is useful where VMware
virtual machines are stored on a separate NFS server and you are able to mount the NFS
If you find a folder of files called guest.vmx, guest.vmxf, guest.nvram and one or more
.vmdk disk images, then you can use this method.
VMX: REMOVE VMWARE TOOLS FROM WINDOWS GUESTS
For Windows guests, you should remove VMware tools before conversion. Although this is
not strictly necessary, and the guest will still be able to run, if you don't do this
then the converted guest will complain on every boot. The tools cannot be removed after
conversion because the uninstaller checks if it is running on VMware and refuses to
start (which is also the reason that virt-v2v cannot remove them).
This is not necessary for Linux guests, as virt-v2v is able to remove VMware tools.
VMX: GUEST MUST BE SHUT DOWN
The guest must be shut down before conversion starts. If you don't shut it down, you
will end up with a corrupted VM disk on the target. With other methods, virt-v2v tries
to prevent concurrent access, but because the -i vmx method works directly against the
storage, checking for concurrent access is not possible.
VMX: MOUNT THE NFS STORAGE ON THE CONVERSION SERVER
Virt-v2v must be able to access the .vmx file and any local .vmdk disks. Normally this
means you must mount the NFS storage containing these files.
VMX: IMPORTING A GUEST
To import a vmx file, do:
$ virt-v2v -i vmx guest.vmx -o local -os /var/tmp
Virt-v2v processes the vmx file and uses it to find the location of any vmdk disks.
2:From the manpage content ,if we want convert Virtual Machines via vmx,we should be able to access to the NFS storage directly(VMware virtual machines are stored on the NFS storage).
So mount the NFS storage to testing PC local as below:
#mount 10.73.197.27:/vol/s3/v2v/esx5.5 /mnt
3:Then we can list all the VMware virtual machines in the NFS server
1161333-WPLCLDWA170_no_mcafee.ova esx5.5-rhel7.2-x86_64 esx5.5-win2012R2-x86_64 esx5.5-win8-i386
1164853-LPLCLDWA273_reboot.ova esx5.5-win10-i386 esx5.5-win2012-x86_64 esx5.5-win8-x86_64
esx5.5-rhel5.11-i386 esx5.5-win10-x86_64 esx5.5-win7-i386_1 kean_multiple_linux
esx5.5-rhel5.11-x86_64 esx5.5-win2008-i386 esx5.5-win7-x86_64 rhel7-juzhou-standard-cdrom-multidisks
esx5.5-rhel6.7-i386 esx5.5-win2008r2-x86_64 esx5.5-win8.1-i386
esx5.5-rhel6.7-x86_64 esx5.5-win2008-x86_64 esx5.5-win8.1-x86_64
4:If convert rhel7.2 guest,then locate in esx5.5-rhel7.2-x86_64 directory.
esx5.5-rhel7.2-x86_64-flat.vmdk esx5.5-rhel7.2-x86_64.vmsd vmware-2.log vmware-5.log vmware.log
esx5.5-rhel7.2-x86_64.nvram esx5.5-rhel7.2-x86_64.vmx vmware-3.log vmware-6.log
esx5.5-rhel7.2-x86_64.vmdk esx5.5-rhel7.2-x86_64.vmxf vmware-4.log vmware-7.log
5:Then import the vmx file to KVM by virt-v2v
# virt-v2v -i vmx esx5.5-rhel7.2-x86_64.vmx -of qcow2
[ 0.0] Opening the source -i vmx esx5.5-rhel7.2-x86_64.vmx
[ 0.0] Creating an overlay to protect the source from being modified
[ 0.1] Initializing the target -o libvirt -os default
[ 0.1] Opening the overlay
[ 5.0] Inspecting the overlay
[ 34.3] Checking for sufficient free disk space in the guest
[ 34.3] Estimating space required on target for each disk
[ 34.3] Converting Red Hat Enterprise Linux Server 7.2 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 281.1] Mapping filesystem data to avoid copying unused and blank areas
[ 281.4] Closing the overlay
[ 281.6] Checking if the guest needs BIOS or UEFI to boot
[ 281.6] Assigning disks to buses
[ 281.6] Copying disk 1/1 to /var/lib/libvirt/images/esx5.5-rhel7.2-x86_64-sda (qcow2)
[ 408.3] Creating output metadata
Pool default refreshed
Domain esx5.5-rhel7.2-x86_64 defined from /tmp/v2vlibvirt9a7b07.xml
[ 409.2] Finishing off
6:Conversion is successfully and all checkpoints passed.
Additions:Convert rhel6.7 windows10,windows7 via vmx all successful.
So, move the bug to VERIFIED
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.