Created attachment 1809314 [details] virt-v2v-win2019-vmware-tools-rhel9.log Description of problem Virt-v2v can't remove vmware-tools 11.0.5 successfully from win2019 and win10 guest after conversion Version-Release number of selected component (if applicable): virt-v2v-1.45.2-1.el9.x86_64 libguestfs-1.45.6-10.el9.x86_64 guestfs-tools-1.46.1-3.el9.1.x86_64 libvirt-libs-7.5.0-1.el9.x86_64 qemu-kvm-6.0.0-10.el9.x86_64 nbdkit-1.26.2-1.el9.1.x86_64 virtio-win-1.9.15-3.el9.noarch How reproducible: 100% Steps to Reproduce: 1.Prepare a win2019 guest which has installed vmware-tools 11.0.5.15389592 on Vmware environment and convert it from VMware to rhv by v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 esx7.0-win2019-x86_64 -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -ip /home/passwd -op /home/rhvpasswd -os nfs_data -b ovirtmgmt -v -x |& tee > virt-v2v-win2019-vmware-tools-rhel9.log 2.Check the guest after v2v finishing conversion, found although vmware-tools service is stop, vmware-tools isn't removed from windows programs and exit code is 1603 of uninstalling vmware script in firstboot log, please refer to screenhost"win2019-vmware-tools-after-rhel9-v2v.png" Test the other windows guests (except win2012r2 because can't install vmware-tools for win2012r2 guest on vSphere 7.0 client) which have installed vmware-tools 11.0.5.15389592 from ESXi7.0 to rhv by v2v VMware-tools uninstall win2016 Success win10 x64 Fail win2012 Success win8.1 x64 Success Actual results: As above description Expected results: Virt-v2v can remove vmware-tools successfully from all windows guest after conversion Additional info: 1.Can reproduce the bug on rhel8.5 AV: virt-v2v-1.42.0-14.module+el8.5.0+11846+77888a74.x86_64 libguestfs-1.44.0-3.module+el8.5.0+10681+17a9b157.x86_64 libvirt-libs-7.5.0-1.module+el8.5.0+11664+59f87560.x86_64 qemu-kvm-6.0.0-25.module+el8.5.0+11890+8e7c3f51.x86_64 nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64 virtio-win-1.9.17-3.el8_4.noarch 2.Can reproduce the bug on rhel8.4 AV: virt-v2v-1.42.0-9.module+el8.4.0+9561+069bb9c1.x86_64 libguestfs-1.44.0-2.module+el8.4.0+10146+75917d2f.x86_64 libvirt-libs-7.0.0-14.1.module+el8.4.0+11095+d46acebf.x86_64 qemu-kvm-5.2.0-16.module+el8.4.0+10806+b7d97207.x86_64 nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64
I'm fairly sure this must happen because the fix for bug 1917760 is incomplete. In that bug we replaced the wrong /i option with /x. I can see from the log file that we are doing that here. But somehow we're getting the 1603 error which indicates that msiexec is still trying to install VMware Tools. While researching this I found this interesting VMware KBase article about how to nuke VMware from the system. We could try this as an alternative to using msiexec since that tool seems to be broken. https://kb.vmware.com/s/article/1001354
The error from the log is: CustomAction VM_LogStart returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) It appears that VMware Tools often doesn't uninstall, see someone having the same problem here: https://superuser.com/questions/1538084/uninstall-of-vmware-tools-fails-does-nothing I think the KB based approach above may be better.
Downgrading sev/prio based on the availability of workarounds (I also fail to see a critical functional issue here). Should we make this bug a KB / documentation permanent restriction article?
> Should we make this bug a KB / documentation permanent restriction article? Not sure what that means, but this does need some development and testing work to see if the approach of modifying the registry directly (comment 3) would work better.
(In reply to Richard W.M. Jones from comment #6) > > Should we make this bug a KB / documentation permanent restriction article? > > Not sure what that means, but this does need some development and > testing work to see if the approach of modifying the registry directly > (comment 3) would work better. It would mean in practice that we won't try to solve a VMWare-tools bug from our end, but document the workaround for customers to do that themselves... If there's a reliable way we can avoid that, though, I agree we should pursue that. Just hope we don't 'invalidate' any Windows-related support / guarantees (I guess we really don't care about VMWare here, do we?) by editing the registry directly. But I take it we do that elsewhere as well..
*** Bug 1988442 has been marked as a duplicate of this bug. ***