Description of problem:
The KVM will not respond to mouse or keyboard after lock/unlock when running and opening KVMs from virt-manager on RHEL7.5. Using remote-viewer spice://localhost:5900 there is no such issue. Customer tested with their corporate build of RHEL 7.5 and different RHEL and Windows KVMs as well as a vanilla RHEL 7.5 host with a RHEL 7.5 guest.
Version-Release number of selected component (if applicable):
RHEL 7.5 Workstation
Steps to Reproduce:
1. Start and open KVM from virt-manager
2. Wait until the desktop of the guest is ready
3. Use the menu in upper right corner of the desktop of the host to lock the screen
4. Wait until it is locked and unlock the screen again
5. The KVM will not respond to mouse or keyboard
The KVM will not respond to mouse or keyboard after lock/unlock
The KVM will respond to mouse or keyboard after lock/unlock
I'm able to reproduce reliably with both virt-manager and remote-viewer. Seems that the window being maximized is important.
(virt-manager:11648): GSpice-WARNING **: keyboard grab failed 1
Which is similar to Bug 1485968 (upstream)
A simple workaround is to switch to 'Details' tab and back to 'Graphical console' tab.
Please refer to Marc-André comment at: https://bugzilla.redhat.com/show_bug.cgi?id=1485968#c23
In spice-gtk, the problem is triggered with GTK 3.20 and up as we switched to gdk_seat_grab() and gdk_seat_ungrab() for keyboard and pointer grab/ungrab.
The value that is emitted from in "keyboard grab failed 1" is GDK_GRAB_ALREADY_GRABBED from gdk_seat_grab() and it happens about the moment we try to Lock the screen.
I guess that when we succeed in locking the screen, it will hold the keyboard but a focus-in-event will also happen in remote-viewer which then tries to grab the keyboard and fails.
We could be using the API wrong, Pavel opened a bug to get advice in the past without success: https://bugzilla.gnome.org/show_bug.cgi?id=780133
Note that I could not reproduce the problem when switching back to old API. Moving to GTK+, suggestions?
I have a possible fix submitted at
Should be fixed by: https://gitlab.gnome.org/GNOME/gtk/commit/c926b28d965dbae90b17d404d2c6d
Looks like the gtk3 -3 package somehow ended up getting dropped from the advisory. I've added it back now.
Many thanks Kalev!
Interesting, I can't reproduce the issue in 7.6 with windows 10 guest:
- gtk3-3.22.30-2.el7.x86_64 (so one rev before the fix)
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.