Description of problem:
Since upgrading to Fedora 26 I have noticed the following ...
I open my Windows 8.1 guest. While I am working in it all is fine, but if I don't do anything in it for a while (e.g. I am on a Skype call just chatting, or I use other windows in Fedora, ignoring the Guest, then when I click back to the Guest window, the mouse moves over it, but nothing updates on the screen. (At some rare times it might be black aka screensaver.) The audio is still working as my Skype chats are still ongoing. The only thing I can do is close the guest GUI and then immediately re-open it in Virt-Manager. Then everything is working 100% again.
I upgraded to the Win 8.1 drivers for VIRTIO 141, but this didn't help either.
Version-Release number of selected component (if applicable):
.... amongst others
As described, and it does it regularly. I'm just not sure of the time window involved.
Steps to Reproduce:
1. Boot guest. Working in it, maybe start a call.
2. Do nothing in the Guest for a time.
3. When accessing the Guest, the screen is frozen (although audio is still working), and you have to close and reopen the Guest.
It should not freeze. It didn't freeze on Fedora 25.
Thanks for the report. Please provide the VM XML: sudo virsh dumpxml VM-NAME
Can you also try reproducing by launching 'virt-manager --debug' from a terminal, and when you get the freeze, grab all the output from the terminal and attach it to this bug, I'm curious if there's any spice errors. Also provide /var/log/libvirt/qemu/VM-NAME.log after you hit an error, there might be qemu/spice errors in there
Created attachment 1323190 [details]
Created attachment 1323202 [details]
virsh dumpxml Win8.1
Created attachment 1323203 [details]
EVENTUALLY it seems to have done it again. This time though, I noticed that the time was still moving forward. I am not 100% sure if that was the case previously. The mouse and keyboard were not grabbed -- the mouse pointer was black, and pressing the Windows Key or ALT-F2 had Gnome responding. Also, the end of the debug output of virt-manager showed that they keyboard was not grabbed.
I will keep running it in this fashion to see if it does it again.
Thanks for the info. That message:
(virt-manager:11648): GSpice-WARNING **: keyboard grab failed 1
The 1 there is GDK_GRAB_ALREADY_GRABBED meaning some other client already has focus. Not sure what that specifically means here.
Are you using gnome-shell or some other desktop environment?
Yes, I run Gnome Shell. But I have the NVIDIA drivers from Negativo17.org installed, which in my limited understanding means that I don't think I run Wayland.
I do have weird problems with Gnome, where it just doesn't respond. The mouse moves all over the screen, but nothing responds. I usually then switch to another text console, log in as root, and run killall -3 gnome-shell which most times sorts it out. I have been experiencing THAT for many years now - always hoping that the next release of Fedora would fix it. I have a feeling that it's tied to Evolution because most of the times that it freezes is when I have done something in Evolution.
Standard applications I have open are:
- gnome terminal running SABnzbd and SickBeard.
- occasionally LibreOffice Calc
Let me know how else I can be more informative.
How often do you get the gnome problems? IMO it would be interesting to try non-nvidia drivers and see if either issue persists, nvidia drivers cause all sorts of weird issues. I realize that's probably not a suitable solution for you but it could identify the culprit
Hi Cole. Sorry for being silent so long. I've not changed back to the nouveau drivers because the unresponsive Gnome thing has been happening on my laptop for years too, and it runs an Intel graphics driver. If you insist on it though, I will make a plan to test it out (and not play any Steam games) LOL.
However, I can report back on what I have noticed. EVERY time it happens, the debug log shows:
(virt-manager:20140): GSpice-WARNING **: keyboard grab failed 1
I can go days without it happening. It happens much more often when I am on a "Skype for Business" voice call. But not always. But the one time I notice it happening almost consisitently is once the "screensaver" has kicked in. The screen begins to fade to black, and often (but not always) this message appears in the debug output.
My guess is then that it's most likely to do with the screen lock.
I have just noticed on:
that vdagent 0.9.0 is out. I have been running 0.7.3 until now. I will report back if that makes any difference.
Nope. Didn't help. I was text chatting on Skype for Business. Had to leave for about an hour. When I came back and unlocked Gnome, the Windows screen was there but the moment I moved the mouse onto the screen it went black, and the mouse was not working in Windows (i.e. it had the black Gnome pointer, not the white Windows pointer. The GSpice message came up again too.
I have exactly the same issue on Win10 guest (on debian, with gnome wayland and gnome-shell)
(virt-manager:5481): GSpice-WARNING **: keyboard grab failed 1
As Louis says, it seems related to the screensaver. I am 100% sure but it seems only to happen when both host and VM start the screensaver
I have changed my login screen to "Gnome" instead of "Gnome Xorg". That still has not helped.
In the freeze that just happened now (and it doesn't ALWAYS happen), I had Seamonkey open on an animated web page, and I had Skype for Business open. I left the room for 20 minutes, so the Gnome screensaver kicked in. I unlocked Gnome, and saw the VM screen.
- the background of the constantly playing movie clip would update once every 20 or 30 seconds.
- the mouse pointer stayed BLACK (meaning it was working on Gnome, and not on Windows, when it is white).
- pressing the windows key had Gnome respond, not Windows.
- the DEBUG log again had showed
(virt-manager:9683): GSpice-WARNING **: keyboard grab failed 1
- although I wasn't playing sound this time, at other times when it freezes, the audio continues working without a hitch
When I closed the VM's screen and immediately re-opened it, the video on the web page played smoothly, and I could again have the mouse be active inside the VM.
Okay I can reproduce. Used a win10 VM, set VM display to turn off after 1 minute, set host f27 gnome-shell display to turn off after 2 minutes, give mouse/keyboard focus to the VM, wait until host display turns off, unlock host, and the VM display is unresponsive.
verified with both virt-manager and virt-viewer. Also verified that virt-viewer+vnc doesn't have this issue, so I'm guessing spice is the culprit
VM going to sleep doesn't matter, just seems to depend on the host locking the display while the VM has mouse/keyboard focus
Met the same issue with recent updates. Never met this issue before.
I have two monitors and the remote-viewer use one of it.
Leaving/entering full screen will get the keyboard/mouse functioning again.
Switching to VM details tab and back to console tab will also get the keyboard/mouse functioning again.
Never an issue if first focus on the non-spice part of virt-manager window, like window title, menu bar, then focus onto the spice area.
(In reply to Cole Robinson from comment #14)
> Okay I can reproduce. Used a win10 VM, set VM display to turn off after 1
> minute, set host f27 gnome-shell display to turn off after 2 minutes, give
> mouse/keyboard focus to the VM, wait until host display turns off, unlock
> host, and the VM display is unresponsive.
> verified with both virt-manager and virt-viewer. Also verified that
> virt-viewer+vnc doesn't have this issue, so I'm guessing spice is the culprit
Is this 100% reproducible for you? I managed to reproduce once, but was not successful to hit this a 2nd time.
(In reply to Christophe Fergeau from comment #20)
> Is this 100% reproducible for you? I managed to reproduce once, but was not
> successful to hit this a 2nd time.
I just reproduced it 3/3 times with virt-manager and 1/1 times with virt-viewer. This is with the comment #14 method. Comment #15 didn't work the one time I tried it so that may be wrong
*** Bug 1560726 has been marked as a duplicate of this bug. ***
After the grab failed (when screen dims after timeout and starts to lock itself), spice-gtk widget never receives the enter-notify event again, and thus will no longer attempt to take the grab.
This seems like a gtk+ or gnome-shell/mutter bug (something changed as I remember the screen didn't lock itself when the grab was taken before), reassigning.
A possible solution for me was change the field 'grab-keyboard' to false into gsettings. I didn't discovered what are the consequences yet (I read the virt-manager code, but it is possible related to Spice anyway) but, at least, I can lock my screen without the GSpice warning or weird Spice behaviours.
One can try the scratch-build at  which includes the proposed patch 
This is likely to be fixed by next 3.22 release by
The condition is still occurring. Not sure why Fedora 28 which is ACTIVE is not going to have gtk 3.22 updated if I read the comments on
Thanks for bringing this up again Louis.
Can some from Gtk3 backport this fix to Fedora at least?
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 28 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.