Description of problem: Unable to copy/paste when accessing RHEL 6 VM's from a Windows client using virt-viewer. We have ensured that rhevm-guest-agent-common ( ovirt-guest-agent-common-1.0.13-5.el6.noarch ) is enabled and started on the VM's, that the Spice copy and paste is enabled in the VM (from within RHV, right click, advanced settings, console). --Some users can copy to the VM and not to the client or vice versa. Version-Release number of selected component (if applicable): rhevm-4.1.6.2-0.1.el7 spice-client-msi-x64-4.1-6 virt-viewer both version 2.0 and 6.0 from the RHEV UI console downloads page. How reproducible: Randomly happening Steps to Reproduce: 1. Install the latest virt-viewer from the RHEV Console Downloads page on a Windows 7 client 2. Try copy and paste function while accessing a RHEL 6 VM from the Windows 7 client Actual results: Copy and Paste does not work consistently Expected results: Copy and Paste should work every time. Additional info: From a live debug session on the client: (remote-viewer.exe:13412): GSpice-DEBUG: ../../src/decode-glz.c:374 decode_header: 90x21, id 1387, ref 1274 (remote-viewer.exe:13412): Gdk-WARNING **: ../../../gdk/win32/gdkselection-win32.c:424: OpenClipboard failed: Access is denied. (remote-viewer.exe:13412): Gdk-WARNING **: ../../../gdk/win32/gdkselection-win32.c:424: OpenClipboard failed: Access is denied. (remote-viewer.exe:13412): Gdk-WARNING **: ../../../gdk/win32/gdkselection-win32.c:424: OpenClipboard failed: Access is denied. (remote-viewer.exe:13412): GSpice-DEBUG: ../../src/decode-glz.c:374 decode_header: 171x24, id 1388, ref 1274 (remote-viewer.exe:13412): Gdk-WARNING **: ../../../gdk/win32/gdkselection-win32.c:424: OpenClipboard failed: Access is denied. (remote-viewer.exe:13412): Gdk-WARNING **: ../../../gdk/win32/gdkselection-win32.c:424: OpenClipboard failed: Access is denied. (remote-viewer.exe:13412): Gdk-WARNING **: ../../../gdk/win32/gdkselection-win32.c:424: OpenClipboard failed: Access is denied.
This is a failure related to the OpenClipboard() Windows's API [0] that was not well handled in gdk and spice-gtk. The upstream bug [1] points that this might be handled (not fixed) by commit 6c29e8105 [2] [0] https://msdn.microsoft.com/en-us/library/windows/desktop/ms649048(v=vs.85).aspx [1] https://bugzilla.gnome.org/show_bug.cgi?id=706610 [2] https://git.gnome.org/browse/gtk+/commit/?id=6c29e81051bd622b22fbf0 I'll try to make a reproducer and see if we can fix this in spice-gtk.
*** Bug 1327658 has been marked as a duplicate of this bug. ***
Additional information, from the same case: .\remote-viewer.exe --spice-debug C:\Users\<your username>\AppData\Local\Temp\console.vv "He receives a modal dialog saying “Authentication required” – it has 2 fields for Username and Password, but the Username field is disabled and does not allow entry" "this only happens when console has been invoked via the command line in windows."
(In reply to amashah from comment #4) > Additional information, from the same case: > > .\remote-viewer.exe --spice-debug C:\Users\<your > username>\AppData\Local\Temp\console.vv > > "He receives a modal dialog saying “Authentication required” – it has 2 > fields for Username and Password, but the Username field is disabled and > does not allow entry" > > "this only happens when console has been invoked via the command line in > windows." Seems like a different bug?
(In reply to Victor Toso from comment #1) > I'll try to make a reproducer and see if we can fix this in spice-gtk. The problem is that this failure is internal in gtk3 and the application doesn't know the failure. We can't easily workaround this in spice-gtk nor in virt-viewer. We have built the client from RHV with mingw-gtk3-3.14.12-5.el7ev. The 3.22 branch of gtk3 has the patch [0] which workarounds the OpenClipboard() failure. As we already use gtk3 3.22 in RHEL-7, we can rebase the mingw-gtk3 to that version and backport [0] [0] https://gitlab.gnome.org/GNOME/gtk/commit/8caba9536cdccb6657b315c3af85
The plan is to do the gtk rebase and necessary fixes in RHV 4.3 and backport the new client (msi installer) to older versions of RHV
Should this have a z stream milestone?
(In reply to Yaniv Lavi from comment #12) > Should this have a z stream milestone? As mentioned in comment #8, yes. The flag to request 4.2.z is set, what else is needed? Thanks!
(In reply to Victor Toso from comment #13) > (In reply to Yaniv Lavi from comment #12) > > Should this have a z stream milestone? > > As mentioned in comment #8, yes. The flag to request 4.2.z is set, what else > is needed? Thanks! Please set the milestone for the release you plan to fix this to.
(In reply to Yaniv Lavi from comment #14) > (In reply to Victor Toso from comment #13) > > (In reply to Yaniv Lavi from comment #12) > > > Should this have a z stream milestone? > > > > As mentioned in comment #8, yes. The flag to request 4.2.z is set, what else > > is needed? Thanks! > > Please set the milestone for the release you plan to fix this to. As mentioned in comment #8, I plan to fix this in 4.3 and backport the msi installer with the fix to 4.2.z so 4.3 milestone seems reasonable to me while having the z-stream flag set. Please let me know if this is not correct.
(In reply to Victor Toso from comment #15) > (In reply to Yaniv Lavi from comment #14) > > (In reply to Victor Toso from comment #13) > > > (In reply to Yaniv Lavi from comment #12) > > > > Should this have a z stream milestone? > > > > > > As mentioned in comment #8, yes. The flag to request 4.2.z is set, what else > > > is needed? Thanks! > > > > Please set the milestone for the release you plan to fix this to. > > As mentioned in comment #8, I plan to fix this in 4.3 and backport the msi > installer with the fix to 4.2.z so 4.3 milestone seems reasonable to me > while having the z-stream flag set. Please let me know if this is not > correct. You should set the milestone to the release you are planning to fix this on.
Should be fixed by rebase on Bug 1615874 I'll move to POST, this should be included in an errata to have the fix documented for customers.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
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/RHEA-2019:1084
sync2jira