Bug 1441197 - RFE: ability to convert VMware virtual machines via vmx
Summary: RFE: ability to convert VMware virtual machines via vmx
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
Jiri Herrmann
URL:
Whiteboard: V2V
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-11 12:25 UTC by Bill Helgeson
Modified: 2019-06-13 15:43 UTC (History)
10 users (show)

Fixed In Version: libguestfs-1.36.3-3.el7
Doc Type: Enhancement
Doc Text:
.`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.
Clone Of:
Environment:
Last Closed: 2017-08-01 22:13:55 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2023 normal SHIPPED_LIVE libguestfs bug fix and enhancement update 2017-08-01 19:32:01 UTC
Red Hat Bugzilla 1523767 None CLOSED RFE: Add virt-v2v VMX imports over SSH 2019-08-22 10:50:34 UTC

Internal Links: 1523767

Description Bill Helgeson 2017-04-11 12:25:15 UTC
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.

Comment 2 Richard W.M. Jones 2017-04-11 13:41:36 UTC
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.

Comment 3 Richard W.M. Jones 2017-04-11 22:35:36 UTC
Upstream in commits:

bb846887de7a252204152c3e6df80d39a5ea33af
ef261d69ed199cc07474a36c890f63df461b35a7
ca40078cdda9167d4658ddfe24c828c7ee76be37

Comment 4 Richard W.M. Jones 2017-04-12 07:47:34 UTC
Full list of commits is now:

bb846887de7a252204152c3e6df80d39a5ea33af
ef261d69ed199cc07474a36c890f63df461b35a7
ca40078cdda9167d4658ddfe24c828c7ee76be37
ec61873d397f050fe28987f10ec919778d27818a

Comment 6 kuwei@redhat.com 2017-04-20 07:36:42 UTC
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

Comment 9 errata-xmlrpc 2017-08-01 22:13:55 UTC
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


Note You need to log in before you can comment on or make changes to this bug.