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: 1. 2. 3. Actual results: Expected results: 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: bb846887de7a252204152c3e6df80d39a5ea33af ef261d69ed199cc07474a36c890f63df461b35a7 ca40078cdda9167d4658ddfe24c828c7ee76be37
Full list of commits is now: bb846887de7a252204152c3e6df80d39a5ea33af ef261d69ed199cc07474a36c890f63df461b35a7 ca40078cdda9167d4658ddfe24c828c7ee76be37 ec61873d397f050fe28987f10ec919778d27818a
Verify the bug with below builds: virt-v2v-1.36.3-3.el7.x86_64 libvirt-3.2.0-2.el7.x86_64 qemu-kvm-rhev-2.8.0-6.el7.x86_64 Verify steps: 1:Ability to convert Virtual Machines via vmx is a new feature ,and we can check it in virt-v2v manpage. #man virt-v2v ------------------------ 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 storage directly. 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 # ls 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. # ls 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) (100.00/100%) [ 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. https://access.redhat.com/errata/RHBA-2017:2023