Bug 1845368
Summary: | [virtio-win-msi] The repair function doesn't work well | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | xiagao | ||||||
Component: | virtio-win | Assignee: | Vadim Rozenfeld <vrozenfe> | ||||||
virtio-win sub component: | virtio-win-prewhql | QA Contact: | xiagao | ||||||
Status: | CLOSED ERRATA | Docs Contact: | |||||||
Severity: | medium | ||||||||
Priority: | unspecified | CC: | ailan, demeng, leidwang, lijin, mdean, menli, phou, qizhu, vrozenfe | ||||||
Version: | 9.0 | Keywords: | CustomerScenariosInitiative, MigratedToJIRA, Reopened, Triaged | ||||||
Target Milestone: | rc | ||||||||
Target Release: | 9.0 | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | |||||||||
: | 1934486 (view as bug list) | Environment: | |||||||
Last Closed: | 2023-11-07 08:29:32 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1897024, 1934486 | ||||||||
Attachments: |
|
Can yo please upload the SetupAPI.dev.log from this VM? https://docs.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries Thanks, Vadim. Created attachment 1697326 [details]
SetupAPI Device Installation Log
Hit same issue on REHL8.3.1, repair function also can not install pvpanic/vioscsi driver. And also found a interesting thing for netkvm and viostor, it will repair to previous installed driver version, but after uninstalled driver again, repair function cannot install the driver. steps: 1. Both netkvm and viostor installed virtio-win-1.9.14-4 and then upgraded to virtio-win-1.9.15-0 with virtio-win-guest-tools.exe. 2. For netkvm, uninstalled 191 build, tried to repair, installed 189 build, then uninstalled netkvm 189 driver, tried to repair, cannot install netkvm driver as well. 3. For viostor, uninstalled 191 build, tried to repair, installed 184 build, then uninstalled viostor 184 driver, tried to repair, cannot install viostor driver as well. Used versions: Guest os: Windows 2016 kernel-4.18.0-240.10.1.el8_3.x86_64 qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64 seabios-bin-1.14.0-1.module+el8.3.0+7638+07cf13d2.noarch virtio-win-1.9.15-0.el8 Best Regards~ Peixiu (In reply to Peixiu Hou from comment #4) > Hit same issue on REHL8.3.1, repair function also can not install > pvpanic/vioscsi driver. > And also found a interesting thing for netkvm and viostor, it will repair to > previous installed driver version, but after uninstalled driver again, > repair function cannot install the driver. what's you guest os? if it's win10+, please make sure windows update is disabled, else guest will get drivers from windows update automatically. (In reply to lijin from comment #5) > (In reply to Peixiu Hou from comment #4) > > Hit same issue on REHL8.3.1, repair function also can not install > > pvpanic/vioscsi driver. > > And also found a interesting thing for netkvm and viostor, it will repair to > > previous installed driver version, but after uninstalled driver again, > > repair function cannot install the driver. > > what's you guest os? if it's win10+, please make sure windows update is > disabled, else guest will get drivers from windows update automatically. I used Win2016, I updated on used versions part and yes, I checked the windows update, the service is disabled. (In reply to Peixiu Hou from comment #6) > (In reply to lijin from comment #5) > > (In reply to Peixiu Hou from comment #4) > > > Hit same issue on REHL8.3.1, repair function also can not install > > > pvpanic/vioscsi driver. > > > And also found a interesting thing for netkvm and viostor, it will repair to > > > previous installed driver version, but after uninstalled driver again, > > > repair function cannot install the driver. > > > > what's you guest os? if it's win10+, please make sure windows update is > > disabled, else guest will get drivers from windows update automatically. > > I used Win2016, I updated on used versions part and yes, I checked the > windows update, the service is disabled. Then it sounds like step1 upgrade does not uninstall previous driver, it keep both. So when you do step2, it install previous one. Hit same issue with virtio-net/virtio-blk/pvpanic ... all the virtio device. Version: Guest:win10-32/win10-64 virtio-win-1.9.14-4.el8.iso virtio-win-1.9.15-0.el8.iso kernel-4.18.0-240.10.1.el8_3.x86_64 qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64 seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64 Thanks Yu Wang Hit same issue with all the virtio device. Version: Guest:win8.1/win2019 virtio-win-1.9.15-0.el8.iso kernel-4.18.0-240.10.1.el8_3.x86_64 qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64 seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64 Hit same issue with all the virtio device. Version: Guest:win2012/win2012r2 virtio-win-1.9.15-0.el8.iso kernel-4.18.0-240.10.1.el8_3.x86_64 qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64 seabios-1.14.0-1.module+el8.3.0+7638+07cf13d2.x86_64 After evaluation this issue, it looks as the problem can not be solved with existing WiX/WixDifxAppExtension.dll toolchain because they are not support Repair/Modification scenario. Interesting thing is that Windows Installed by itself knows how to handles this situation. Right-click -> Repair on virtio-win MSI with the following system reboot can solve the problem in most of the cases. Moving this problem to 8.5 Vadim. Hit the same issue with virtio-win-1.9.16-2.el8.iso, tested with all the virtio devices on RHLE8.4.0 host. Used versions: guest os: Win10-32/64, Win2012, Win2012-r2 kernel-4.18.0-298.el8.x86_64 qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch virtio-win-1.9.16-2.el8.iso Thanks~ Peixiu (In reply to Peixiu Hou from comment #21) > Hit the same issue with virtio-win-1.9.16-2.el8.iso, tested with all the > virtio devices on RHLE8.4.0 host. > > Used versions: > guest os: Win10-32/64, Win2012, Win2012-r2 > kernel-4.18.0-298.el8.x86_64 > qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 > seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch > virtio-win-1.9.16-2.el8.iso > > Thanks~ > Peixiu The same with win2019 and win8.1-32/64 guest. (In reply to Peixiu Hou from comment #21) > Hit the same issue with virtio-win-1.9.16-2.el8.iso, tested with all the > virtio devices on RHLE8.4.0 host. > > Used versions: > guest os: Win10-32/64, Win2012, Win2012-r2 > kernel-4.18.0-298.el8.x86_64 > qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 > seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch > virtio-win-1.9.16-2.el8.iso > > Thanks~ > Peixiu The same with win8.1-64/win2016-64 guests. (In reply to dehanmeng from comment #23) > (In reply to Peixiu Hou from comment #21) > > Hit the same issue with virtio-win-1.9.16-2.el8.iso, tested with all the > > virtio devices on RHLE8.4.0 host. > > > > Used versions: > > guest os: Win10-32/64, Win2012, Win2012-r2 > > kernel-4.18.0-298.el8.x86_64 > > qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 > > seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch > > virtio-win-1.9.16-2.el8.iso > > > > Thanks~ > > Peixiu > > The same with win2016-64/win8-32/64 guests hit the same issue when run virtio-win-1.9.17-1.el8_4 acceptance test. version: qemu-kvm-5.2.0-16.module+el8.4.0+11536+725e25d9.2.x86_64 kernel-4.18.0-305.el8.x86_64 seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch virtio-win-1.9.17-1.el8_4.iso Hit the same issue when run virtio-win-1.9.17-2.el8_4 acceptance test. Version: kernel-4.18.0-305.el8.x86_64 qemu-kvm-5.2.0-16.module+el8.4.0+11721+c8bbc1be.3.x86_64 seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch virtio-win-1.9.17-2.el8_4.iso Hit the same issue when run virtio-win-1.9.17-3.el8_4 acceptance test. Version: kernel-4.18.0-305.el8.x86_64 qemu-kvm-5.2.0-16.module+el8.4.0+11721+c8bbc1be.3.x86_64 seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch virtio-win-1.9.17-3.el8_4.iso Hi the same issue when run virtio-win-1.9.17-4.el8_4 acceptance test. Version: qemu-kvm-5.2.0-16.module+el8.4.0+11923+e8b883e4.4.x86_64 kernel-modules-4.18.0-305.el8.x86_64 seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch virtio-win-1.9.17-4.el8_4 1. 140.140-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win2012.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35 2. 145-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win2016.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35 3. 209-Host_RHEL.m8.u4.product_av.qcow2.virtio_scsi.up.virtio_net.Guest.Win2019.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35 4. 214-Host_RHEL.m8.u4.product_av.qcow2.virtio_scsi.up.virtio_net.Guest.Win8.i386.1.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35 5. 219-Host_RHEL.m8.u4.product_av.qcow2.virtio_scsi.up.virtio_net.Guest.Win8.x86_64.1.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35 6. 209-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win10.i386.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35 7. 214-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win10.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35 8. 219-Host_RHEL.m8.u4.product_av.qcow2.virtio_blk.up.virtio_net.Guest.Win2012.x86_64.r2.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair.q35 hit the same issue when run virtio-win-1.9.15-4.el9 acceptance testing. version: kernel-5.14.0-0.rc4.35.el9.x86_64 qemu-kvm-6.0.0-10.el9.x86_64 virtio-win-1.9.15-4.el9 seabios-bin-1.14.0-6.el9.noarch hit the same issue when run virtio-win-1.9.18-2.el8 acceptance testing version: kernel-4.18.0-338.el8.x86_64 qemu-kvm-6.0.0-29.module+el8.5.0+12386+43574bac.x86_64 seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch virtio-win-1.9.18-2.el8 hit the same issue when run virtio-win-1.9.19-1.el8 acceptance testing version: kernel-4.18.0-339.el8.x86_64 qemu-kvm-6.0.0-29.module+el8.5.0+12386+43574bac.x86_64 seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch virtio-win-1.9.19-1.el8 hit the same issue when run virtio-win-1.9.19-4.el9 acceptance test version: kernel-5.14.0-5.el9.x86_64 qemu-kvm-6.0.0-13.el9_b.5.x86_64 seabios-bin-1.14.0-6.el9.noarch virtio-win-1.9.19-4.el9 1.Win2012.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair 2.Win2016.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair 3.Win2019.x86_64.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair 4.Win8.i386.1.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair 5.Win8.x86_64.1.io-github-autotest-qemu.win_virtio_driver_install_by_installer.driver_repair hit the same issue when run virtio-win-1.9.19-5.el9 acceptance testing version: kernel-5.14.0-6.el9.x86_64 qemu-kvm-6.0.0-13.el9_b.5.x86_64 seabios-bin-1.14.0-6.el9.noarch virtio-win-1.9.19-5.el9 Hi Vadim, As the ITR is set, could you set DTM, so qe can set ITM accordingly. Thanks. Xiaoling (In reply to xiagao from comment #38) > Hi Vadim, > As the ITR is set, could you set DTM, so qe can set ITM accordingly. > > Thanks. > Xiaoling Moved to 25. Best, Vadim. (In reply to Vadim Rozenfeld from comment #39) > (In reply to xiagao from comment #38) > > Hi Vadim, > > As the ITR is set, could you set DTM, so qe can set ITM accordingly. > > > > Thanks. > > Xiaoling > > Moved to 25. > Best, > Vadim. Hello Vadim, On RHEL8.6.0 Code freeze time is 2022-02-28 which DTM is 26, and you set DTM to 25, it's risky for QE to verify within 1 week. So could you move the date a little bit forward,such as 23. Thanks, Xiaoling hit the same issue when run virtio-win-1.9.20-1.el8_4 acceptance testing kernel-4.18.0-305.el8.x86_64 qemu-kvm-5.2.0-16.module+el8.4.0+13460+2e130eec.13.x86_64 seabios-bin-1.14.0-1.module+el8.4.0+8855+a9e237a9.noarch virtio-win-1.9.20-1.el8_4 After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. hello Vadim, the DTM expired, could you pls re-set them? Thanks. (In reply to xiagao from comment #58) > hello Vadim, the DTM expired, could you pls re-set them? Thanks. updated. All the best, Vadim. Hi Vadim, could you help reset the 'Current Deadline:'? Thank you. Hi Vadim, Would you prefer to defer this repair bug to RHEL.9.3.z? (In reply to xiagao from comment #64) > Hi Vadim, Would you prefer to defer this repair bug to RHEL.9.3.z? We can postpone it to 9.3.z in general since repair from the bundle doesn't work. But if msi repair repair works I would like to release this feature in 9.3.0 and fix the bundle in 9.3.z Best, Vadim. (In reply to Vadim Rozenfeld from comment #65) > (In reply to xiagao from comment #64) > > Hi Vadim, Would you prefer to defer this repair bug to RHEL.9.3.z? > > We can postpone it to 9.3.z in general since repair from the bundle doesn't > work. > But if msi repair repair works I would like to release this feature in 9.3.0 > and > fix the bundle in 9.3.z > > Best, > Vadim. Thanks Vadim. Then I will set this bug to verified. And open another one in Jira to track the bundle doesn't work issue. 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 (virtio-win 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-2023:6388 |
Created attachment 1696224 [details] guest tool repair log Description of problem: Virtio-win-guest-tools' repair function couldn't install the uninstalled driver. Steps to Reproduce: 1.boot up win2019 guest with virtio device. 2.install drivers via Virtio-win-guest-tools.exe 3.uninstall rng and balloon driver right click "My computers"-->"properties"--->"device manager"---->choose "Virtio Balloon Driver"---> right-click "Uninstall" ---->choose "Delete the driver software for this device"--->Uninstall the driver. 4.open Virtio-win-guest-tools.exe and click repair button 5.reboot guest 6.check if rng and baloon driver is installed Actual results: repair function can not install rng/balloon driver all logs are in attachment. Expected results: repair function can install the uninstalled driver. Additional info: 1.qemu command line /usr/libexec/qemu-kvm -name $1 -enable-kvm -m 6G -smp 8,maxcpus=12,cores=4,threads=1,sockets=3 -rtc base=localtime,driftfix=none -boot order=cd,menu=on -monitor stdio -qmp tcp:0:1235,server,nowait -M q35 \ -cpu 'EPYC',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv-tlbflush,+kvm_pv_unhalt \ -cdrom /home/kvm_autotest_root/iso/windows/virtio-win.iso.el8 \ -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x3 \ -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \ -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \ -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \ -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \ -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \ -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \ -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \ -device pcie-root-port,port=0x18,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x4 \ -drive file=$1,if=none,id=drive_system_disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop \ -device ide-drive,bus=ide.0,unit=0,drive=drive_system_disk,id=ide0-0-0 \ -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/data-disk2.qcow2,node-name=system_file \ -blockdev driver=qcow2,node-name=drive_blk_disk,file=system_file \ -object iothread,id=thread0 -device virtio-blk-pci,iothread=thread0,drive=drive_blk_disk,id=virtio-disk0,serial=GAGENT_TEST,bus=pci.1 \ -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0,vhost=on,queues=4 \ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:52:11:36:4d:0d,bus=pci.2,mq=on,vectors=10 \ -device virtio-serial-pci,id=virtio-serial1,max_ports=31,bus=pci.3 \ -chardev socket,id=channel1,host=127.0.0.1,port=2222,server,nowait -device virtserialport,bus=virtio-serial1.0,chardev=channel1,name=com.redhat.rhevm.vdsm1,id=port1 \ -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,bus=virtio-serial1.0,chardev=channel2,name=org.qemu.guest_agent.0,id=port2 \ -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/data-disk1.qcow2,node-name=data_file \ -blockdev driver=qcow2,node-name=drive_data_disk,file=data_file \ -device virtio-scsi-pci,id=scsi0,num_queues=4,bus=pci.4 -device scsi-hd,bus=scsi0.0,drive=drive_data_disk,id=scsi-disk0 \ -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,bus=pci.5 \ -device virtio-balloon-pci,id=balloon0,bus=pci.6 \ -device pvpanic,id=pvpanic0,ioport=0x0505 \ -device virtio-keyboard-pci,id=kbd0,serial=virtio-keyboard,bus=pci.7 -device virtio-mouse-pci,id=mouse0,serial=virtio-mouse,bus=pci.8 -device virtio-tablet-pci,id=tablet0,serial=virtio-tablet,bus=pci.9 \ -spice id=on,disable-ticketing,port=5912 -vga qxl \\