Description of problem: Exclamation mark on VM with message" New guest tools available" even when latest guest tools are installed. Version-Release number of selected component (if applicable): virtio-win-1.9.15.el8.noarch How reproducible: On RHV 4.4, upgrade the virtio-win* package, current latest version is: virtio-win-1.9.15.el8 Note: Tested this on customers environment. Steps to Reproduce: 1. Attached CD to the VM 2. installed virtio-win-guest-tools from it Actual results: The statistics shows correct in the rhv-manager portal and spice console works fine as well but the exclamation mark still appears with message below: ~~~ Up New guest tools available ~~~ Expected results: The 'New guest tools available' message should not be shown when latest available tools are installed Additional info: The steps in the documentation are not clear on which all files to install exactly: Reference: 3.3.2. Installing the guest agents, tools, and drivers on Windows https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/virtual_machine_management_guide/installing_guest_agents_and_drivers_windows#Installing_the_Guest_Agents_and_Drivers_on_Windows And when we select the installation with virtio-win-gt-x64.msi, you need to install manually the spice agents, etc. Also virtio-win-gt-x64.msi custom setup does not show RHEV Agent option while the virtio-win-guest-tools shows the option for "Install ovirt guest agent" and after installing this (tested on a VM), an exclamation mark appears with New guest tools available. This shows correct statistics though but with an exclamation mark with message.
Hi, Did you fully followed the documentations? Please note in 3.2.2 section[1], the guest-agent step: Double-click virtio-win-gt-x64.msi or virtio-win-gt-x86.msi. Click Next at the welcome screen. Follow the prompts in the installation wizard. Ensure all check boxes in the list of components are selected, including the RHEV Agent, which is disabled by default. When installation is complete, select Yes, I want to restart my computer now and click Finish to apply the changes. After the virtual machine reboots, open the CD-ROM and go to the guest-agent directory and double-click qemu-ga-x86_64.msi or qemu-ga-i386.msi, to install qemu-ga, the Qemu guest agent. As you can see, you have 2 MSIs, one for the drivers and the other for the qemu-guest-agent. The mark is shown if the guest agent is not updated comparing the available one installed in the RPM on the engine. You can check the version available in the engine by (should be 101.2.0-1 for the given RPM): # cat /usr/share/virtio-win/agents.json To the VM you can see it under the VM itself, under the applications. Or, using the DB to check it: # select app_list from vm_dynamic where vm_guid=<vm_guid>; Can you tell what are the reported versions from the engine and from the guest? Did you install the qemu-ga MSI? [1] - https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/virtual_machine_management_guide/installing_guest_agents_and_drivers_windows#Installing_the_Guest_Agents_and_Drivers_on_Windows
(In reply to Liran Rotenberg from comment #2) > Hi, > Did you fully followed the documentations? > Please note in 3.2.2 section[1], the guest-agent step: > Double-click virtio-win-gt-x64.msi or virtio-win-gt-x86.msi. > Click Next at the welcome screen. > Follow the prompts in the installation wizard. Ensure all check boxes in the > list of components are selected, including the RHEV Agent, which is disabled > by default. - This was performed, but the RHEV Agent check box is not seen with it. > When installation is complete, select Yes, I want to restart my computer now > and click Finish to apply the changes. - It does not ask to restart the machine as well, we did it manually. > After the virtual machine reboots, open the CD-ROM and go to the guest-agent > directory and double-click qemu-ga-x86_64.msi or qemu-ga-i386.msi, to > install qemu-ga, the Qemu guest agent. > - Yes we did this too. - The steps does not go like what documentation talks here exactly. - virtio-win-gt-x64.msi custom setup does not show RHEV Agent option , its only shown with the virtio-win-guest-tools - it shows the option for "Install ovirt guest agent" - All the check boxes were checked- we did this testing back and forth in customer environment we have remote session recording in the case for review. > As you can see, you have 2 MSIs, one for the drivers and the other for the > qemu-guest-agent. > The mark is shown if the guest agent is not updated comparing the available > one installed in the RPM on the engine. > You can check the version available in the engine by (should be 101.2.0-1 > for the given RPM): > # cat /usr/share/virtio-win/agents.json I will ask customer to update on this. > > To the VM you can see it under the VM itself, under the applications. Or, > using the DB to check it: > # select app_list from vm_dynamic where vm_guid=<vm_guid>; This shows: ~~~ [root@rhvm-02844659-0 ~]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select app_list from vm_dynamic where vm_guid='eafc37a4-8a73-479e-bc2c-cfd9d071d8a2';" app_list --------------------------------------------------------------------------------------------------------------------- QEMU guest agent,Virtio-win-driver-installer,oVirt guest agent,Red Hat QXL controller,Spice Agent 0.10.0-5 (64-bit) (1 row) ~~~ > > Can you tell what are the reported versions from the engine and from the > guest? Did you install the qemu-ga MSI? > > - virtio-win-1.9.15-0.el8.noarch - rhvm-4.4.4.7-0.2.el8ev.noarch - I will confirm on - Did you install the qemu-ga MSI > [1] - > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/ > html/virtual_machine_management_guide/ > installing_guest_agents_and_drivers_windows#Installing_the_Guest_Agents_and_D > rivers_on_Windows
customer confirmed: 1) Check the version available in the engine by (should be 101.2.0-1 for the given RPM): *Yes it is * [root@LAB-RHVM ~]# cat /usr/share/virtio-win/agents.json { "agents": [ { "arch": "x86", "agent_version": "101.2.0-1", "name": "Red Hat QEMU guest agent" }, { "arch": "amd64", "agent_version": "101.2.0-1", "name": "Red Hat QEMU guest agent" }, { "arch": "x86", "agent_version": "0.10.0-5", "name": "Red Hat SPICE VDA agent" }, { "arch": "amd64", "agent_version": "0.10.0-5", "name": "Red Hat SPICE VDA agent" } ] } 2) Referring to the documentation: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/virtual_machine_management_guide/installing_guest_agents_and_drivers_windows#Installing_the_Guest_Agents_and_Drivers_on_Windows Yes we did reboots, I even tested rebooting several times as below, virtio-win-gt-x64 Reboot QxlWddmDod_x64 Reboot spice-vdagent-x64 Reboot qemu-ga-x86_64 Reboot at this point no exclamation mark is present ovirt-guest-agent-x64 - asap i install the overt-guest agent exclamation mark is present Note: Without the Ovirt Guest agent, i don't see Installed applications CPU usage RAM utilization Network utilization
Targeting and assigning under the assumption this can be fixed by changing the application list that is reported by the host when the guest is installed with ovirt-guest-agent to also include the version of qemu-guest-agent
Technically this is fixed, however in reality this just caused opposite problem, the mark is now never displayed. I installed WGT 4.3-13 on my windows 10 VM and mark that GT should be installed disappeared, however there is nothing telling me that this GT is old and should be upgraded. Same goes for when I install virtio-win GT 1.9.12, no mark that new GT are available.
forgot version info: vdsm-4.40.60.5-1.el8ev on ovirt-engine-4.4.6.5-0.17.el8ev.noarch
Hi Petr, Can you provide us more details? The applist of the VM on each stage. The virtio-win ISO available on the engine, including the output of the agents.json. The ISOs available on the ISO/Data domain.
apps list with WGT 4.3-13: "appsList": [ "Microsoft Update Health Tools", "RHEV-Tools 4.3.13", "Windows 10 Update Assistant", "Microsoft Edge Update", "Microsoft Edge", "RHEV-Block64 4.3.1", "Qemufwcfg64 4.3.1", "RHEV-Spice-WDDM-DOD64 4.3.2", "RHEV-SCSI64 4.3.1", "RHEV-Balloon64 4.3.1", "RHEV-Network64 4.3.1", "RHEV-Serial64 4.3.1", "RHEV-RNG64 4.3.1", "RHEV-Spice-Agent64 4.3.3", "RHEV-SSO64 4.3.1", "RHEV-Agent64 4.3.3" ], after removing WGT and installing virtio-win 1.9.12: "appsList": [ "qemu-guest-agent-101.1.0" ], after upgrading to actually current virtio-win 1.9.16: "appsList": [ "qemu-guest-agent-5.2.0" ], [root@engine ~]# cat /usr/share/virtio-win/agents.json { "agents": [ { "arch": "x86", "agent_version": "102.0.0-2", "name": "Red Hat QEMU guest agent" }, { "arch": "amd64", "agent_version": "102.0.0-2", "name": "Red Hat QEMU guest agent" }, { "arch": "x86", "agent_version": "0.10.0-5", "name": "Red Hat SPICE VDA agent" }, { "arch": "amd64", "agent_version": "0.10.0-5", "name": "Red Hat SPICE VDA agent" } ] } [root@engine ~]# yum info virtio-win Last metadata expiration check: 2:48:20 ago on Wed 28 Apr 2021 01:48:57 PM IDT. Installed Packages Name : virtio-win Version : 1.9.16 Release : 2.el8 Architecture : noarch Size : 756 M Source : virtio-win-1.9.16-2.el8.src.rpm Repository : @System From repo : rhel-8.4-nightly-appstream Summary : VirtIO para-virtualized drivers for Windows(R) URL : http://www.redhat.com/ License : Red Hat Proprietary and BSD-3-Clause and Apache and GPLv2 Description : VirtIO para-virtualized Windows(R) drivers for 32-bit and 64-bit : Windows(R) guests. [root@host ~]# ls /rhev/data-center/mnt/iso_domain/d31037e5-0d45-4306-975b-73eea845ae86/images/11111111-1111-1111-1111-111111111111/ 1.iso bpelled_initramfs.img 1.vfd bpelled_vmlinuz AWS-Storage-Gateway.ova cirunner.iso CentOS-7-x86_64-NetInstall-1611.iso coreos_production_iso_image.iso CentOS-Atomic-Host-7-Installer.iso en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso Fedora-Live-Workstation-x86_64-23-10.iso en_windows_10_enterprise_x64_dvd_6851151.iso Fedora-Server-DVD-x86_64-23.iso en_windows_7_enterprise_x64_dvd_x15-70749.iso Fedora-Server-dvd-x86_64-26-1.5.iso en_windows_7_enterprise_x86_dvd_x15-70745.iso Fedora-Workstation-Live-x86_64-25-1.3.iso en_windows_8.1_enterprise_with_update_x86_dvd_4065185.iso Fedora-Workstation-Live-x86_64-31-1.9.iso en_windows_8_enterprise_x64_dvd_917522.iso RHEL-7.5-20180322.0-Server-x86_64-dvd1.iso en_windows_8_enterprise_x86_dvd_917587.iso RHEL-7.8-20200225.1-Server-ppc64le-dvd1.iso en_windows_server_2012_r2_with_update_x64_dvd_6052708.iso RHEL-8.2.0-20200404.0-ppc64le-dvd1.iso en_windows_server_2012_r2_x64_dvd_2707946.iso RHEL-8.2.0-20200404.0-x86_64-dvd1.iso en_windows_server_2012_x64_dvd_915478.iso RHEV-toolsSetup_3.6.iso en_windows_server_2016_x64_dvd_9327751.iso RHEV-toolsSetup_4.0_6.iso en_windows_server_2016_x64_dvd_9327751.iso.txt RHEV-toolsSetup_4.0_7.iso en_windows_server_2019_x64_dvd_4cb967d8.iso RHEV-toolsSetup_4.1_5.iso fedora-netinstaller.iso RHEV-toolsSetup_4.1_7.iso initramfs-4.18.0-147.5.1.el8_1.x86_64.img RHEV-toolsSetup_4.2_1.iso initramfs.img RHEV-toolsSetup_4.2_5.iso initrd.img RHV-toolsSetup_4.2_1.iso oVirt-toolsSetup-4.1-5.fc24.iso RHV-toolsSetup_4.2_2.iso oVirt-toolsSetup-4.2-1.el7.centos.iso RHV-toolsSetup_4.2_3.iso oVirt-toolsSetup-4.2-3.el7.iso RHV-toolsSetup_4.2_4.iso rhcos-44.81.202001240222.0-installer.x86_64.iso RHV-toolsSetup_4.2_5.iso rhcos-44.81.202003062006-0-installer.x86_64.iso RHV-toolsSetup_4.2_6.iso rhel-server-7.4-x86_64-dvd.iso RHV-toolsSetup_4.2_7.iso rhel74_kickstart.iso RHV-toolsSetup_4.2_8.iso rhel75_server_rhv_cfme_testing.iso RHV-toolsSetup_4.2_9.iso rhv-tools-setup.iso RHV-toolsSetup_4.3_1.iso thursday.iso RHV-toolsSetup_4.3_10.iso ubuntu-18.04.5-live-server-amd64.iso RHV-toolsSetup_4.3_11.iso virtio-win-0.1.173.iso RHV-toolsSetup_4.3_12.iso virtio-win-1.9.11.iso RHV-toolsSetup_4.3_13.iso virtio-win-1.9.12.iso RHV-toolsSetup_4.3_2.iso virtio-win-1.9.16.iso RHV-toolsSetup_4.3_3.iso virtio-win-1.9.4.iso RHV-toolsSetup_4.3_6.iso virtio-win-1.9.8.iso RHV-toolsSetup_4.3_7.iso virtio-win-1.9.8_amd64.vfd RHV-toolsSetup_4.3_8.iso virtio-win-1.9.8_servers_amd64.vfd RHV-toolsSetup_4.3_9.iso virtio-win-1.9.8_servers_x86.vfd VMware-VMvisor-Installer-201912001-15160138.x86_64.iso virtio-win-1.9.8_x86.vfd Win10_1607_Hebrew_x64.iso virtio-win.iso Win10_1909_EnglishInternational_x32.iso virtio-win_amd64.vfd alpine-standard-3.10.2-x86_64.iso virtio-win_servers_amd64.vfd automation_initramfs virtio-win_servers_x86.vfd automation_initramfs.img virtio-win_x86.vfd automation_vmlinuz vmlinuz automation_vmlinuz.img vmlinuz-0-rescue-ba03afd38c8c4ac6b261483207401a9f automation_vmlinuz_test_tamir
Actually now I see the new GT are available mark (with 1.9.16 installed), so even more of a reason for failing this. Also if this requires virtio-win installed (obviously yes) on the engine then it should be part of requirements of engine-setup, because I didn't have that installed before.
Thanks Petr. You do need virtio-win installed. It was decided not to be a requirement as part of the ovirt-engine. Was virtio-win RPM installed on the WGT to virtio-win phase? For the last part it does makes sense you have the mark on: You have on the applist: qemu-guest-agent-5.2.0 In the RPM(ISO) you have: qemu-guest-agent-102.0.0-2 And 102.0.0-2 > 5.2.0 The 1.9.12 versioning (what I remember being on the ISO and what you had installed) looks correct. It looks like the virtio-win-1.9.16.iso you have available isn't containing what it suppose to.
As it is not a requirement then it will cause these problems. It was available always, although I installed it only before trying this again for the apps list, so it was installed for upgrade WGT - virtio-win 1.9.12.
(In reply to Petr Matyáš from comment #24) > As it is not a requirement then it will cause these problems. right, it makes the setup a bit more complex. that's the downside of not requiring it. and back to this bug, something doesn't seem right - you took two artifacts of virtio-win 1.9.16 (RPM and ISO) and they provided you with different versions of qemu-guest-agent as Liran wrote above, something is fishy with the ISO that provided qemu-guest-agent 5.2.0 please make sure to use a valid ISO and check with other versions if it reproduces or this issue is specific to 1.9.16 I see no reason to fail this bug at this point - moving back to ON_QA
Please provide me with virtio-win ISO that you think is correct. Because what I have is from RHEL repos.
Also as the main point of this feature is to show a user that old WGT should be updated, which it now doesn't show in direct response to patches in this bug, this is a FailedQA.
yes, but you need to install qemu-guest-agent for this - did you?
(In reply to Petr Matyáš from comment #26) > Please provide me with virtio-win ISO that you think is correct. Because > what I have is from RHEL repos. I trust you to find the right ISO with your peers, I don't have it at hand
(In reply to Arik from comment #28) > yes, but you need to install qemu-guest-agent for this - did you? Yes
(In reply to Arik from comment #29) > (In reply to Petr Matyáš from comment #26) > > Please provide me with virtio-win ISO that you think is correct. Because > > what I have is from RHEL repos. > > I trust you to find the right ISO with your peers, I don't have it at hand If that is the case, I have the right ISO and problem is at your end.
Liran, can you please install WGT properly and compare it with the output provided in comment 21 [1] - I believe QEMU guest agent should have been reported [1] apps list with WGT 4.3-13: "appsList": [ "Microsoft Update Health Tools", "RHEV-Tools 4.3.13", "Windows 10 Update Assistant", "Microsoft Edge Update", "Microsoft Edge", "RHEV-Block64 4.3.1", "Qemufwcfg64 4.3.1", "RHEV-Spice-WDDM-DOD64 4.3.2", "RHEV-SCSI64 4.3.1", "RHEV-Balloon64 4.3.1", "RHEV-Network64 4.3.1", "RHEV-Serial64 4.3.1", "RHEV-RNG64 4.3.1", "RHEV-Spice-Agent64 4.3.3", "RHEV-SSO64 4.3.1", "RHEV-Agent64 4.3.3" ],
After testing the results: WGT 4.3.13 - new guest tools available mark app_list | qemu-guest-agent-7.6.2,Microsoft Update Health Tools,RHEV-Tools 4.3.13,Microsoft Edge Update,Microsoft Edge,RHEV-Block64 4.3.1,Qemufwcfg64 4.3.1,RHEV-Spice-WDDM-DOD64 4.3.2,RHEV-SCSI64 4.3.1,RHEV-Balloon64 4.3.1,RHEV-Network64 4.3.1,RHEV-Serial64 4.3.1,RHEV-RNG64 4.3.1,RHEV-Spice-Agent64 4.3.3,RHEV-SSO64 4.3.1,RHEV-Agent64 4.3.3 Virtio-WIN older (101 GA) - new guest tools available mark app_list | qemu-guest-agent-101.1.0,Microsoft Update Health Tools,Microsoft Edge Update,Virtio-win-driver-installer,Microsoft Edge,oVirt guest agent Virtio-win new (102 GA) - new guest tools available mark app_list | qemu-guest-agent-5.2.0,Microsoft Edge Update,Microsoft Update Health Tools,Microsoft Edge,oVirt guest agent,Virtio-win-driver-installer For latest virtio-win (1.9.16) we do have a problem. In the provided JSON we have: "agent_version": "102.0.0-2", but actually we got 5.2.0. 2021-05-03 19:33:22,250+0300 INFO (qgapoller/2) [vds] New QEMU-GA capabilities for vm_id=1b0cb163-a5e2-4161-a05f-9e6d4d0d2a66, qemu-ga=5.2.0, commands={'guest-file-flush', 'guest-file-open' , 'guest-file-write', 'guest-fsfreeze-freeze-list', 'guest-get-osinfo', 'guest-get-time', 'guest-get-disks', 'guest-set-user-password', 'guest-fsfreeze-status', 'guest-get-timezone', 'guest- suspend-ram', 'guest-get-host-name', 'guest-fstrim', 'guest-get-users', 'guest-sync-delimited', 'guest-suspend-disk', 'guest-info', 'guest-fsfreeze-thaw', 'guest-get-devices', 'guest-ping', 'guest-get-fsinfo', 'guest-file-seek', 'guest-fsfreeze-freeze', 'guest-exec-status', 'guest-exec', 'guest-sync', 'guest-get-vcpus', 'guest-file-close', 'guest-file-read', 'guest-set-time', ' guest-network-get-interfaces', 'guest-shutdown'} (qemuguestagent:233) Self added DEBUG logs where OGA shows info['appsList'] and QGA shows qga['appsList']. Before moving to 1.9.16: 2021-05-03 19:20:25,991+0300 DEBUG (jsonrpc/1) [virt.vm] (vmId='1b0cb163-a5e2-4161-a05f-9e6d4d0d2a66') OGA: ('QEMU guest agent', 'Microsoft Edge Update', 'Microsoft Update Health Tools', 'Mi crosoft Edge', 'oVirt guest agent', 'Virtio-win-driver-installer') (guestagent:494) 2021-05-03 19:20:25,991+0300 DEBUG (jsonrpc/1) [virt.vm] (vmId='1b0cb163-a5e2-4161-a05f-9e6d4d0d2a66') QGA: ('qemu-guest-agent-101.1.0',) (guestagent:495) After moving to 1.9.16: 2021-05-03 19:25:18,017+0300 DEBUG (jsonrpc/1) [virt.vm] (vmId='1b0cb163-a5e2-4161-a05f-9e6d4d0d2a66') OGA: ('QEMU guest agent', 'Microsoft Edge Update', 'Microsoft Update Health Tools', 'Microsoft Edge', 'oVirt guest agent', 'Virtio-win-driver-installer') (guestagent:494) 2021-05-03 19:25:18,017+0300 DEBUG (jsonrpc/1) [virt.vm] (vmId='1b0cb163-a5e2-4161-a05f-9e6d4d0d2a66') QGA: ('qemu-guest-agent-5.2.0',) (guestagent:495) We need to check with virtio-win if the JSON is wrong or the report of the version is wrong.
agents.json seems to be fine { "arch": "x86", "agent_version": "102.0.0-2", "name": "Red Hat QEMU guest agent" }, { "arch": "amd64", "agent_version": "102.0.0-2", "name": "Red Hat QEMU guest agent" }, which is corresponding with sources SHA512 (mingw-qemu-ga-win-102.0.0-2.el8.src.rpm) = 2620a9cb1ce648fbdaf0d0bad5ddf4f073551e6c0e17c1aae3648a3e46b5f06740a695e251b10e96bd0e05eff445ba4a665fc86cbf911be3e2325d8f18d85495 SHA512 (qemu-ga-win-102.0.0-2.el8.noarch.rpm) = 01ba30eb8b49015eda55de34e5ad5c892dccdbed531e37bdbff7ce8f09da046506d51c11ccc16c4fd6f2e287f3ee920e7ddc12d326b414e9d7c82ec506f2d33f and virtio-win.spec %global qemu_ga_win_build qemu-ga-win-102.0.0-2.el8 it is always "102.0.0-2" which is also matching mingw-qemu-ga-win-102.0.0-2.el8 changelog https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1531558 "5.2.0" looks as qemu version to which mingw-qemu-ga-win has been rebased recently https://bugzilla.redhat.com/show_bug.cgi?id=1915198
(In reply to Vadim Rozenfeld from comment #34) > it is always "102.0.0-2" which is also matching > mingw-qemu-ga-win-102.0.0-2.el8 > changelog > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1531558 > > "5.2.0" looks as qemu version to which mingw-qemu-ga-win > has been rebased recently > https://bugzilla.redhat.com/show_bug.cgi?id=1915198 So if I understand it correct this is a problem with the Windows build. Or is that intentional that qemu-ga itself now reports version 5.2.0 instead of 102.0.0?
(In reply to Tomáš Golembiovský from comment #35) > (In reply to Vadim Rozenfeld from comment #34) > > > it is always "102.0.0-2" which is also matching > > mingw-qemu-ga-win-102.0.0-2.el8 > > changelog > > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1531558 > > > > "5.2.0" looks as qemu version to which mingw-qemu-ga-win > > has been rebased recently > > https://bugzilla.redhat.com/show_bug.cgi?id=1915198 > > So if I understand it correct this is a problem with the Windows build. Or > is that intentional that qemu-ga itself now reports version 5.2.0 instead of > 102.0.0? Looks like a bug. Downstream qemu-ga should report the build number and not QEMU version. We had a downstream patch changing the version.
Ack, thanks, filed bz 1957377 on this then.
Having the qemu-ga fixed is nice, however I will need new build of virtio-win to verify this and I don't see any new one.
(In reply to Petr Matyáš from comment #46) > Having the qemu-ga fixed is nice, however I will need new build of > virtio-win to verify this and I don't see any new one. What happens with the latest one? I would expect that in the json you'll see 102.0.0 and the guest agent would report 102.0.1 (https://bugzilla.redhat.com/show_bug.cgi?id=1974317#c1), which is a nice test case - we should not tell the user that there's a newer version available
The latest build of virtio-win is from march, it's the same one I already tried and which does not report correct data (according to you). I don't think the fix was brought back in time and implemented into the build from march, which you are apparently suggesting happened.
Sure, but Vadim and Yan provided more information since then (in comment 34 and comment 36) saying that this version was correct and the problem was with the version reported by the guest agent The latter is supposed to be fixed in mingw-qemu-ga-win-102.0.1-2.el8_4
Sure, which we are getting as part of virtio-win only.
(In reply to Petr Matyáš from comment #50) > Sure, which we are getting as part of virtio-win only. Can't you check it with a RHEL guest?
I am, it's not part of any RHV repos nor any regular RHEL (baseos and appstream) repos, unlike virtio-win. And it shouldn't be, as I said it's shipped as part of virtio-win.
OK, my question about RHEL guest was incorrect - this is really an issue with the version for Windows Petr, it would be great if you could get the version that was tested in bz 1974317 (@demeng, can you please point us to where you took the package from?) but as long as it's tested in 4.4.7, that's ok
Once more reiterating here, even if I would download the package from brew and test it, no customer would ever do that, we as in RHV are testing virtio-win iso which should contain the latest qemu-ga. This means that without the iso I can test the package, but agents.json will be in a different location than ovirt-engine expects and it wouldn't be a real life usage. So without rebuild of virtio-win we shouldn't verify this BZ, which probably means it is not making it into 4.4.7.
If you'll be able to test it quickly with the package that was verified in bz 1974317, it will increase the chances everything would work and delivered in 4.4.7 If you insist on waiting for the package to be delivered in the channels you use, it might be that you'll find some issue when you test it and it will get pushed out again to 4.4.8 - that's not very likely to happen though so it should be part of 4.4.7
(In reply to Arik from comment #55) > If you'll be able to test it quickly with the package that was verified in > bz 1974317, it will increase the chances everything would work and delivered > in 4.4.7 > If you insist on waiting for the package to be delivered in the channels you > use, it might be that you'll find some issue when you test it and it will > get pushed out again to 4.4.8 - that's not very likely to happen though so > it should be part of 4.4.7 But don't worry about it, worst case we'll set it as exception for 4.4.7
(In reply to Arik from comment #53) > OK, my question about RHEL guest was incorrect - this is really an issue > with the version for Windows > Petr, it would be great if you could get the version that was tested in bz > 1974317 (@demeng, can you please point us to where you took the package > from?) but as long as it's tested in 4.4.7, that's ok If I don't misunderstand you, you might be taking about where to get mingw-qemu-ga package right? if so, please visit this link https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1641120, feel free to needinfo me if I provide the wrong info.
FYI, I see that virtio-win-1.9.17-1.el8_4.noarch.rpm is now available
Using virtio-win-1.9.17-3.el8_4.noarch and vdsm-4.40.70.6-1.el8ev.x86_64 this now finally reports correct qemu version "appsList": ["qemu-guest-agent-102.0.2"] and [root@engine ~]# cat /usr/share/virtio-win/agents.json { "agents": [ { "arch": "x86", "agent_version": "102.0.2-0", "name": "Red Hat QEMU guest agent" }, { "arch": "amd64", "agent_version": "102.0.2-0", "name": "Red Hat QEMU guest agent" }, { "arch": "x86", "agent_version": "0.10.0-5", "name": "Red Hat SPICE VDA agent" }, { "arch": "amd64", "agent_version": "0.10.0-5", "name": "Red Hat SPICE VDA agent" } ] } However this still shows exclamation mark on the VM and reports 'New guest tools are available'
Did you wait enough time to let the engine pick it up? One way to trigger it in my opinion is just by clicking edit on the VM (and then cancel).
Wow, what a weird process, I waited only like an hour and restarted engine service which was not enough. However after clicking edit and closing the warning is gone. This process with edit and cancel should be added to documentation.
(In reply to Petr Matyáš from comment #82) > Wow, what a weird process, I waited only like an hour and restarted engine > service which was not enough. However after clicking edit and closing the > warning is gone. Eh, this does not sound good. Liran, could you elaborate on how and when does engine refresh the flag?
(In reply to Tomáš Golembiovský from comment #83) > (In reply to Petr Matyáš from comment #82) > > Wow, what a weird process, I waited only like an hour and restarted engine > > service which was not enough. However after clicking edit and closing the > > warning is gone. > > Eh, this does not sound good. Liran, could you elaborate on how and when > does engine refresh the flag? We talked on the standup on this - we are not going to invest in it for now. Anyway, there are two options to trigger it (VmHandler::refreshVmsToolsVersion). If there is no active ISO domain it will have an interval of 180 seconds by default, it can be configured by engine-config. If there is an active ISO domain it will act as it always did, triggered when IsoDomainListSynchronizer will initiate it, when refreshing the ISO list. This happen when the engine thinks the cached isn't relevant anymore (by time, pretty long one), or once triggered, for example by editing a VM. A possible easy solution would be to let the no active ISO domain to be triggered regardless the ISO domain.
bz 1983401 was filed for improving the presentation of the mark after the VM is upgraded
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 (RHV RHEL Host (ovirt-host) [ovirt-4.4.7]), 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:2864
Hi All, After acceptance testing for this new build https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1684993, this new build runs well on QE side. Thanks for your effort and time. BRs Dehan Meng
Due to QE capacity, we are not going to cover this issue in our automation