Description of problem: I have a guest on a remote RHEL 6.1 machine which uses spice. I access the guest from my F16 workstation using virt-manager over ssh. Frequently (many times per day), X (on the F16 host) will become unresponsive to certain input. When I click on the guest window's close button I eventually get a message that virt-manager is unresponsive. Forcing the closure of virt-manager restores X to normal behaviour. The problem only happens when accessing a guest using spice. X unresponsiveness always includes keyboard input: it is not possible to type anything into any window, even if the window can be selected with the mouse. It sometimes involves not being able to move windows. I haven't nailed down a specific trigger, but it happens on my system a lot. I think it tends to trigger on a focus transition in or out, but I wouldn't swear to that. I use focus follows mouse and make heavy use of multiple workspaces. I'm happy to run with debugging enabled if you let me know what you need. I suspect this is spice-gtk rather than virt-manager, but I'll let you move it. Version-Release number of selected component (if applicable): spice-gtk-0.7.39-1.fc16.x86_64 virt-manager-0.9.0-7.fc16.noarch
Yeah I'm not really sure how to go about debugging this. Reassigning to spice-gtk for input from them.
Is it still happening? I would say this is not spice-gtk or virt-manager specific, but rather x11/gnome-shell issue. For instance, I used to found myself having to switch to terminal to kill the spice-client. Typically when I hit a breakpoint under gdb, while the client has all the grabs. Nowadays, I make sure I use SPICE_NOGRAB=1 to workaround that gdb problem. But there might be other cases where an application using spice-gtk might freeze while holding all the grabs... and this is not specific to spice-gtk.
No response for a while, closing as INSUFFICIENT_DATA. Please reopen if you're still seeing this issue.