Description of problem: I use virt-manager. I switched my guests from VNC to spice, and am mostly very happy. However, 4 or 5 times per day, something triggers a 150 second timeout. During that time, all guests are unresponsive. Also, I can't do anything on the host, because the guest that triggers the timeout still has the keyboard focus. I have tried to pay attention to general system load, but that seems unrelated to the problem. Yesterday afternoon I had two guest VMs running and a compile going on the host, and did not trigger the problem. This morning I only have 1 guest VM running and both it and the host are mostly idle, yet the timeout has already triggered 3 times. I *have* noticed that it appears to be related to redisplay. The timeout almost always occurs when I do something that triggers a repaint of an entire window. (XEmacs does this a lot. I'm an XEmacs developer. Therefore, I edit files in my guests with XEmacs...) Also, once the 150 second timeout period passes, the guest window does not redraw itself properly. I have to close it and open a new one. Sadly, opening a new window causes a full repaint of the entire guest desktop, which sometimes triggers the timeout again instantly. Version-Release number of selected component (if applicable): spice-server-0.9.1-1.fc16.x86_64 How reproducible: Frequently Steps to Reproduce: 1. Run a guest VM with spice 2. Run a program in the guest that frequently repaints its entire window 3. Wait Actual results: The guest window becomes unresponsive for a 150 second time period, and the window has to be closed and reopened afterward. Expected results: No timeouts. Additional info: I see two 150 second timeout values defined in the spice sources, both in server/red_worker.c: DETACH_TIMEOUT and DISPLAY_CLIENT_TIMEOUT.
I haven't had this happen once since spice-server-0.10.0-1.fc16.x86_64 came through, so I'm going to close this bug. Thank you! It's quite a relief to not have that happen anymore.