Red Hat Bugzilla – Bug 1508847
Corrupted guest icons on client display, but not corrupted in guest screen capture
Last modified: 2018-04-10 09:23:06 EDT
Customer installed a RHEL 7.4 client with the latest version of virt-viewer we supply, virt-viewer.x86_64 version 5.0-7.el7 and is seeing the issue originally reported upstream.They did not have this issue with older versions of virt-viewer.
Created attachment 1346979 [details] virt-viewer taskbar disruption
Created attachment 1346980 [details] Disruption with Themes service started
Created attachment 1346981 [details] Disruption with Themes service stopped
With the windows versions from the portal(s) RHV 3.6 (version 2.0-129) and RHV 4.1 (version 2.0-176) there are no problems.
(In reply to Frank DeLorey from comment #2) > Customer installed a RHEL 7.4 client with the latest version of virt-viewer > we supply, virt-viewer.x86_64 version 5.0-7.el7 and is seeing the issue > originally reported upstream.They did not have this issue with older > versions of virt-viewer. Any idea what "older versions of virt-viewer" correspond to exactly? I assume the guest is Windows 7? Which driver/version is it running, and which graphics adapter is the VM configured with? What are the spice-server/qemu versions? Is this being run on RHEV Is there a step by step reproducer which can be used here? I tried it quickly in a win7 VM I have, stopped the themes.exe service, opened the details of some services in the service list, moved the windows around, but did not notice any corruption. So I'm missing something.. (In reply to Frank DeLorey from comment #6) > With the windows versions from the portal(s) RHV 3.6 (version 2.0-129) and > RHV 4.1 (version 2.0-176) there are no problems. But virt-viewer 6.0 64bit on a Windows 7 client is apparently having the issue too?
Any idea what "older versions of virt-viewer" correspond to exactly? A1) The version that came with RHEL 7.3 - virt-viewer-2.0-12.el7.x86_64 I assume the guest is Windows 7? Which driver/version is it running, and which graphics adapter is the VM configured with? A2) I will check to verify this info What are the spice-server/qemu versions? Is this being run on RHEV A3) I will grab a sosreport from their host. This is RHEV: rhev-guest-tools-iso-3.6-7.el6ev.noarch rhev-hypervisor7-7.3-20170118.0.el6ev.noarch rhev-hypervisor7-7.3-20170424.0.el6ev.noarch rhev-hypervisor7-7.3-20170425.0.el6ev.noarch rhev-hypervisor7-7.3-20170615.0.el6ev.noarch rhevm-3.6.12-0.1.el6.noarch Is there a step by step reproducer which can be used here? I tried it quickly in a win7 VM I have, stopped the themes.exe service, opened the details of some services in the service list, moved the windows around, but did not notice any corruption. So I'm missing something.. I think in their case stopping themes solves the problem having it enabled causes the problem.
A2) Windows 7 32bit VDI with RHEV-toolsSetup_4.1_7 (QXL driver version 6.1.0.10024 and spice-agent 4.41.5) on a RHEV 4.1 environment. The same problem I have with a Dutch and a English Windows, on a RHEV 3.6 and a RHEV 4.1 environment.
But virt-viewer 6.0 64bit on a Windows 7 client is apparently having the issue too? A4) Yes anything but the versions from the RHEV UI downloads. They tried upstream versions as they first noticed the issue with an IGEL thin client update that brought in the newer version of virt-viewer. They tested with a Windows client using various newer upstream versions 5,6 and 7 and they all show the same issue, whereas the versions from RHEV 3.6 and RHEV 4.1 do not have the problem. They then created a new RHEL 7.4 client and usinf the version of virt-viewer we package with RHEL 7.4 see the same issue.
Created attachment 1347060 [details] Disruption with Themes service started
A3) qemu-kvm-common-rhev-2.9.0-16.el7_4.5.x86_64 spice-server-0.12.8-2.el7.1.x86_64 Note they are seeing this problem in both a 3.6 and 4.1 RHEV environment.
I made a clone of my Windows 7 VDI and (re)installed RHEV tools 3.6.7 with exact the same result.
Is there any progression/news?
It may require a RHEV environment as we have not tested it using non-RHEV based VMs. Frank
They are not exactly random corruption. If you try to align the image with the darker line you'll manage to read back something. I think the black line at the beginning is the bytes between a line and the other. Something is not considering the correct stride. Looking at the line look like that the stride difference is exactly 7 pixels. It's weird that that line is greyed too. I remember there was some issues with 16 bit images with odd width. Note that Windows memory layout start from bottom to top so that line at that position is "expected" in such stride misalignment problems. I think would be worth trying a new client (like a master version or Fedora 27) and know the guest resolution (including depth). This behaviour would make perfectly sense if the Windows rendering engine would capture an image and grey it but this way the screen capture would be corrupted too which is not the case here. Question: If you disconnect and connect again are you getting the text right?
Customer states that disconnecting/reconnecting makes no difference. Franl
Got a local reproduction. Should not be hard to fix. Is a wrong stride adjustment.
"Should not be hard to fix." This is very good news. I will appreciate leaving this nuisance behind.
Send patch upstream at https://lists.freedesktop.org/archives/spice-devel/2017-December/041228.html.
Private build at https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14834390.
(In reply to Frediano Ziglio from comment #29) > Send patch upstream at > https://lists.freedesktop.org/archives/spice-devel/2017-December/041228.html. I am delighted to report that this fixes my system. I will supply a Tested-By to the development list.
Created attachment 1374448 [details] Patch for RHPKG spice-gtk This is patch for 7.5. Note that package does not compile for a missing spice-protocol package (not related to this patch). See https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14848118. No much idea about timing. Is there an Errata available? I'm currently on holiday.
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/RHBA-2018:0672