Description of problem: In RHV manager, virt-v2v failed to convert VMware ESXi VM with the snapshot. Version-Release number of selected component (if applicable): virt-v2v-1.36.10-6.9.rhvpreview.el7ev.x86_64 vdsm-4.20.27.2-1.el7ev.x86_64 How reproducible: Based on the Bugzilla #1172425 [https://bugzilla.redhat.com/show_bug.cgi?id=1172425], the RHEL VM with snapshot import should be successful but seems regression. found ERROR in vdsm logs as "vm 'vmimport1' has snapshots and therefore cannot be imported since snapshot conversion is not supported for VMware." So the workaround is to delete the snapshots in VMWare for this vm and then try to import VM. engine.log --- 2018-08-28 16:40:30,642+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsNamesFromExternalProviderVDSCommand] (default task-41) [0123a456-d0c1-47f2-b379-5d9769af4f6b] FINISH, GetVmsNamesFromExternalProviderVDSCommand, return: [VM [MailSvr], VM [VM0], VM [VM1], VM [VM2], VM [VM3], VM [VM4], VM [VM5], VM [VM6], VM [VM7], VM [VM8], VM [VM9], VM [vmimport1]], log id: 9908c2b 2018-08-28 16:40:45,779+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFullInfoFromExternalProviderVDSCommand] (default task-28) [jkljkljkl-aea9-4d75-bfb4-852daa304e10] START, GetVmsFullInfoFromExternalProviderVDSCommand(HostName = Hypervisor1, GetVmsFromExternalProviderParameters:{runAsync='true', hostId='abcdefgh-aabf-4ca8-a41c-1c0fa7d4a57b', url='vpx://user@sec-vcenter/Datacenter/Cluster/Hypervisor2.domain.internal?no_verify=1', username='user', originType='VMWARE', namesOfVms='[vmimport1]'}), log id: 3cb1dc9e 2018-08-28 16:41:13,906+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFullInfoFromExternalProviderVDSCommand] (default task-3) [01010101-ffa5-409a-91e1-1e18ea4b1d33] START, GetVmsFullInfoFromExternalProviderVDSCommand(HostName = Hypervisor1, GetVmsFromExternalProviderParameters:{runAsync='true', hostId='abcdefgh-aabf-4ca8-a41c-1c0fa7d4a57b', url='vpx://user@sec-vcenter/Datacenter/Cluster/Hypervisor2.domain.internal?no_verify=1', username='user', originType='VMWARE', namesOfVms='[vmimport1]'}), log id: 390542dd --- vdsm.log --- 2018-08-28 16:40:30,020+0800 INFO (jsonrpc/2) [api.host] START getExternalVMNames(uri=u'vpx://user@sec-vcenter/Datacenter/Cluster/Hypervisor2.domain.internal?no_verify=1', username=u'user', password='********') from=::ffff:192.168.1.15,59040, flow_id=0123a456-d0c1-47f2-b379-5d9769af4f6b (api:46) 2018-08-28 16:40:30,633+0800 INFO (jsonrpc/2) [api.host] FINISH getExternalVMNames return={'status': {'message': 'Done', 'code': 0}, 'vmNames': ['MailSvr', 'VM0', 'VM1', 'VM2', 'VM3', 'VM4', 'VM5', 'VM6', 'VM7', 'VM8', 'VM9', 'vmimport1']} from=::ffff:192.168.1.15,59040, flow_id=0123a456-d0c1-47f2-b379-5d9769af4f6b (api:52) 2018-08-28 16:40:45,784+0800 INFO (jsonrpc/3) [api.host] START getExternalVMs(uri=u'vpx://user@sec-vcenter/Datacenter/Cluster/Hypervisor2.domain.internal?no_verify=1', username=u'user', password='********', vm_names=[u'vmimport1']) from=::ffff:192.168.1.15,59040, flow_id=jkljkljkl-aea9-4d75-bfb4-852daa304e10 (api:46) 2018-08-28 16:40:46,722+0800 ERROR (jsonrpc/3) [user] vm 'vmimport1' has snapshots and therefore can not be imported since snapshot conversion is not supported for VMware (v2v:186) <---- ERROR --- Actual results: VM import has failed with ERROR "vm 'vmimport1' has snapshots and therefore cannot be imported since snapshot conversion is not supported for VMware." Expected results: VM import should have been succeeded.
Bug 1172425 is indeed the correct one. But please note this fix *only* applies to the "old" vCenter-over-HTTPS import method that is used by RHV GUI. It does not apply to IMS/VDDK/SSH/etc.
we have a pending bug 1565955 to allow that already.
Setting severity to high, because it is IMS. Also, shouldn't we consider it for 4.2.z as well, Michal?
(In reply to Marina from comment #4) > Setting severity to high, because it is IMS. > Also, shouldn't we consider it for 4.2.z as well, Michal? No, it’s not IMS. The bug talks about integrated v2v in RHV. What’s the other ticket about specifically?
WA is to ask to collapse snapshots on VMware side first, then convert
Right as Michal says, this is for the vCenter over HTTPS method. IMS is using either SSH or VDDK and the code paths there are both completely different. For interest only (and outside the scope of the current bug): For VDDK we would have to specify the snapshot moref (https://github.com/libguestfs/nbdkit/blob/master/plugins/vddk/nbdkit-vddk-plugin.pod#parameters). I have absolutely no idea how we'd get this. It probably involves calling obscure VMware APIs. For SSH this would require investigation. I've no idea how it would be done without examining a VMware ESXi server that is using snapshots.
*** Bug 1565955 has been marked as a duplicate of this bug. ***
Notes from preliminary testing: Removing the following lines does allow for vmware vm importing support: https://github.com/oVirt/vdsm/blob/master/lib/vdsm/v2v.py#L184-L188 Some preliminary testing did succeed in importing the vms. However the snap shots are not displayed within the Virtual Machines -> Details -> Snapshots window which will require more investigation.
As explained before it will simply never be possible to convert a VM while preserving all snapshots. virt-v2v will convert the top snapshot only.
Yes, the comment is with respect to the engine and whether the engine can actually display the single snap shot as it does when a snap shot is created by the engine UI.
nope, still POST: http://gerrit.ovirt.org/95868 needs to be reverted, see https://gerrit.ovirt.org/#/c/95878/
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ] For more info please contact: rhv-devops: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ] For more info please contact: rhv-devops
Reassigned: Import of VMware Linux VM with snapshots succeeds, but importing of Windows VM with snapshots failed and it's not related to Windows hibernation or fast restart. Windows verification scenario: 1. Run VMware Windows VM and create 3 snapshots. 2. Disable hibernate and fast restart. 3. shutdown VMware VM. 4. Import VM Import failed. please see attached log: import-with-snapshots.log 5. From vSphere client, keep this VM powered off and remove all snapshots. 6. Import VM. Import succeeds, please see attached log: import-without-snapshots.log Verification version: ovirt-engine-4.3.0-0.8.master.20190122121624.git9a8a519.el7 virt-v2v-1.38.2-12.el7_6.1.x86_64 vdsm-4.30.8-9.gitf28e377.el7.x86_64 qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64 libvirt-client-4.5.0-10.el7_6.4.x86_64 VMware: Version 6.5.0.13000 Build 7801515
Created attachment 1527158 [details] import-without-snapshots.log
Created attachment 1527159 [details] import-with-snapshots.log
The failure is: The NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting), or mount the volume read-only with the 'ro' mount option. indicating that fast restart wasn't disabled. However note this is converting the 4th snapshot, which is presumably some older version than the top snapshot, and so perhaps that snapshot was of a live system and virt-v2v could not ever convert that because the NTFS library we are using isn't capable of it. Anyhow converting VMs with snapshots isn't possible and isn't ever going to be possible (no matter how much we want it), so I think we should just tell users not to do this.
(In reply to Richard W.M. Jones from comment #20) I just tried it with 4 snapshot while the latest one is not of a live system and virt-v2v conversion succeeds. Verifying this bug: ovirt-engine-4.3.0.5-0.0.master.20190205084851.gitaaebfc9.el7 virt-v2v-1.38.2-12.el7_6.1.x86_64 vdsm-4.30.8-36.git8b043e4.el7.x86_64 qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64 libvirt-client-4.5.0-10.el7_6.4.x86_64
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/RHEA-2019:1085