Description of problem: While migrating VM's from VMware 6.7 to Red Hat Virtualization 4.4.3 `VMware tools` were not uninstalled post-migration. Version-Release number of selected component (if applicable): virt-v2v-1.42.0-6.module+el8.3.0+7898+13f907d5.x86_64 v2v-import.log ~~~ libguestfs: trace: v2v: write "/Program Files/Guestfs/Firstboot/scripts/0003-uninstall-VMware-Tools.bat" "@echo off\x0d\x0a\x0d\x0aecho uninstalling VMware Tools\x0d\x0aMsiExec.exe /I{25932044-BBC8-444F-ACF4-7E508054FA12} /quiet /norestart /l*v+ "%~dpn0.log" REBOOT=ReallySuppress REMOVE=ALL\x0d\x0aif errorlevel 3010 exit /b 0\x0d\x0a" libguestfs: trace: v2v: internal_write "/Program Files/Guestfs/Firstboot/scripts/0003-uninstall-VMware-Tools.bat" "@echo off\x0d\x0a\x0d\x0aecho uninstalling VMware Tools\x0d\x0aMsiExec.exe /I{25932044-BBC8-444F-ACF4-7E508054FA12} /quiet /norestart /l*v+ "%~dpn0.log" REBOOT=ReallySuppress REMOVE=ALL\x0d\x0aif errorlevel 3010 exit /b 0\x0d\x0a" ~~~ Actual results: VMware tools are not uninstalled post importing Windows guests from Vmware to RHV. Expected results: msiexec command we are trying to run should uninstall the VMware tools. Additional info:
The msiexec command we are trying to run is wrong. We run this: MsiExec.exe /I{25932044-BBC8-444F-ACF4-7E508054FA12} /quiet /norestart /l*v+ "%~dpn0.log" REBOOT=ReallySuppress REMOVE=ALL The first part of this command (MsiExec.exe /I{...}) comes from the UninstallString from the registry entry for VMware Tools. The rest (/quiet ...) is added by virt-v2v to make the uninstallation automatic. https://github.com/libguestfs/virt-v2v/blob/96a5d7d058aeb107f785f52e166f42c2a1e797a1/v2v/convert_windows.ml#L171 As usual the MSFT documentation is contradictory but it seems as if /I is asking for installation. (In other words, the UninstallString command added by VMware Tools to the registry is wrong - it's actually the install command). We should rewrite /i to /x in this case.
msiexec documentation: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec
Upstream commits: https://github.com/libguestfs/virt-v2v/commit/3515c9f617271bec89962ba8a2b8c690e6df4c99 https://github.com/libguestfs/virt-v2v/commit/d48530209a79725f26d6e25101bed6f228f45e8d https://github.com/libguestfs/virt-v2v/commit/f7496b0a7e76a06bda8d7ec1aba36741f8cb295c The first two are refactoring/clean up commits. The last one changes the msiexec command to use /x instead of /i. After this the command that we run is: MsiExec.exe /x{45147181-CF69-4C8C-81CB-0FC96F170758} /quiet /norestart /l*v+ "%~dpn0.log" REBOOT=ReallySuppress REMOVE=ALL
Reproduce the bug with below builds: virt-v2v-1.42.0-7.module+el8.4.0+9398+f376ac33.x86_64 libguestfs-1.44.0-1.module+el8.4.0+9398+f376ac33.x86_64 libvirt-libs-7.0.0-2.module+el8.4.0+9520+ef609c5f.x86_64 qemu-kvm-5.2.0-4.module+el8.4.0+9676+589043b9.x86_64 nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64 virtio-win-1.9.15-0.el8.noarch Steps to reproduce: 1.Convert a windows guest which has installed vmware tools from VMware to rhv4.4 by v2v #virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -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 -n ovirtmgmt esx7.0-win2016-x86_64-vmware-tool -oo rhv-direct=true -v -x |& tee > virt-v2v-1.42.0-7-windows-vmware-tool.log 2. Check msiexec command in v2v debug log, can find /I option is used in msiexec command # cat virt-v2v-1.42.0-7-windows-vmware-tool.log |grep MsiExec.exe libguestfs: trace: v2v: hivex_value_string = "MsiExec.exe /I{25932044-BBC8-444F-ACF4-7E508054FA12}" libguestfs: trace: v2v: write "/Program Files/Guestfs/Firstboot/scripts/0003-uninstall-VMware-Tools.bat" "@echo off\x0d\x0a\x0d\x0aecho uninstalling VMware Tools\x0d\x0aMsiExec.exe /I{25932044-BBC8-444F-ACF4-7E508054FA12} /quiet /norestart /l*v+ "%~dpn0.log" REBOOT=ReallySuppress REMOVE=ALL\x0d\x0aif errorlevel 3010 exit /b 0\x0d\x0a" libguestfs: trace: v2v: internal_write "/Program Files/Guestfs/Firstboot/scripts/0003-uninstall-VMware-Tools.bat" "@echo off\x0d\x0a\x0d\x0aecho uninstalling VMware Tools\x0d\x0aMsiExec.exe /I{25932044-BBC8-444F-ACF4-7E508054FA12} /quiet /norestart /l*v+ "%~dpn0.log" REBOOT=ReallySuppress REMOVE=ALL\x0d\x0aif errorlevel 3010 exit /b 0\x0d\x0a" 3.Check guest on rhv4.4, VMware tools can be removed from windows guest successfully, but find “Property(S): ACTION = INSTALL” in 0003-uninstall-VMware-Tools.log Verify the bug with below builds: virt-v2v-1.42.0-9.module+el8.4.0+9561+069bb9c1.x86_64 libguestfs-1.44.0-1.module+el8.4.0+9398+f376ac33.x86_64 libvirt-libs-7.0.0-2.module+el8.4.0+9520+ef609c5f.x86_64 qemu-kvm-5.2.0-4.module+el8.4.0+9676+589043b9.x86_64 nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64 virtio-win-1.9.15-0.el8.noarch Steps: 1.Convert a windows guest which has installed vmware tools from VMware to rhv4.4 by v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -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 -n ovirtmgmt esx7.0-win2016-x86_64-vmware-tool -oo rhv-direct=true -v -x |& tee > virt-v2v-1.42.0-9-windows-vmware-tool.log 2. Check msiexec command in v2v debug log, can find the first msiexec command is still using /I option, the other msiexec commands already use /x instead of /I # cat virt-v2v-1.42.0-9-windows-vmware-tool.log |grep MsiExec.exe libguestfs: trace: v2v: hivex_value_string = "MsiExec.exe /I{25932044-BBC8-444F-ACF4-7E508054FA12}" libguestfs: trace: v2v: write "/Program Files/Guestfs/Firstboot/scripts/0003-uninstall-VMware-Tools.bat" "@echo off\x0d\x0a\x0d\x0aecho uninstalling VMware Tools\x0d\x0aMsiExec.exe /x{25932044-BBC8-444F-ACF4-7E508054FA12} /quiet /norestart /l*v+ "%~dpn0.log" REBOOT=ReallySuppress REMOVE=ALL \x0d\x0aif errorlevel 3010 exit /b 0\x0d\x0a" libguestfs: trace: v2v: internal_write "/Program Files/Guestfs/Firstboot/scripts/0003-uninstall-VMware-Tools.bat" "@echo off\x0d\x0a\x0d\x0aecho uninstalling VMware Tools\x0d\x0aMsiExec.exe /x{25932044-BBC8-444F-ACF4-7E508054FA12} /quiet /norestart /l*v+ "%~dpn0.log" REBOOT=ReallySuppress REMOVE=ALL \x0d\x0aif errorlevel 3010 exit /b 0\x0d\x0a" 3.Check guest on rhv4.4, VMware tools can be removed from windows guest successfully, but find “Property(S): ACTION = INSTALL” in 0003-uninstall-VMware-Tools.log Hi Richard, Please help to check verification step2 and step3, seems miss fixing one /I option in msiexec command during v2v conversion, besides, still can find info "ACTION = INSTALL” in 0003-uninstall-VMware-Tools.log after v2v conversion, is it expected?
Created attachment 1751569 [details] virt-v2v-1.42.0-9-windows-vmware-tool.log
Created attachment 1751570 [details] unintall-vmware-tools-log-1.42.0-9.png
Yes I noticed that. I don't understand why it still puts "ACTION = INSTALL" into the log. What matters is only that VMware Tools gets uninstalled after conversion. The customer reported (and showed a log) showing that in the first case VMware Tools was not being uninstalled. So you didn't reproduce the customer's bug. However I also could not reproduce the customer's bug, they may be using some weird version of VMware Tools.
Confirmed with Richard on IRC, the message "libguestfs: trace: v2v: hivex_value_string = "MsiExec.exe /I{25932044-BBC8-444F-ACF4-7E508054FA12}" is reading the command from the windows registry, so it is not v2v problem. Besides, the purpose of bug is to confirm VMware tools get uninstalled after v2v conversion, according to comment9, VMware tools can be uninstalled from windows guest successfully after v2v conversion, so move the bug from ON_QA to VERIFIED.
Created attachment 1780611 [details] vmware-tools-11.2.5-mxie.png
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 (virt:av bug fix and enhancement update), 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-2021:2098