On F18 with an F18 guest: - Open virt-manager, start the VM, log in. - Run pm-suspend - Watch the guest pause and stop, but leave the spice window open. - Close the spice window - The guest resumes Doesn't seem like a good thing to me, since it basically means you can't leave virt-manager without unsuspending your guest.
Using spice + qxl FWIW
I can still reproduce with rawhide qemu and remote-viewer, using this command line: ./x86_64-softmmu/qemu-system-x86_64 -m 4096 -enable-kvm -cpu host -cdrom /mnt/data/devel/media/Fedora-18-x86_64-Live-Desktop.iso -vga qxl -spice port=5901,disable-ticketing However it doesn't seem to reproduce using cirrus and vnc. So not sure if this is remote-viewer, spice-gtk, spice, or qemu which is causing this. Reassigning to spice-gtk
I can reproduce easily, though I don't think spice-gtk is reponsible, since killing it just resume the guest as well, it's probably some server behaviour, but I haven't found the root cause yet.
There seems to be the cause. Working on a fix. #0 runstate_set (new_state=RUN_STATE_RUNNING) at vl.c:606 #1 0x00007f926f0bdb18 in qemu_system_wakeup_request (reason=reason@entry=QEMU_WAKEUP_REASON_OTHER) at vl.c:1882 #2 0x00007f926f007b82 in ps2_put_keycode (opaque=0x7f9271e96c20, keycode=56) at hw/ps2.c:158 #3 0x00007f9268e471bf in inputs_channel_handle_parsed () from /lib64/libspice-server.so.1 #4 0x00007f9268e4e4be in red_channel_client_receive () from /lib64/libspice-server.so.1 #5 0x00007f9268e5055c in red_channel_client_event () from /lib64/libspice-server.so.1 #6 0x00007f926f04fca7 in qemu_iohandler_poll (readfds=readfds@entry=0x7f926f9e14c0 <rfds>, writefds=writefds@entry=0x7f926f9e1440 <wfds>, xfds=xfds@entry=0x7f926f9e13c0 <xfds>, ret=ret@entry=1) at iohandler.c:159 #7 0x00007f926f05554e in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:417 #8 0x00007f926ef2f9e5 in main_loop () at vl.c:2001 #9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4326 Breakpoint 3, inputs_channel_on_disconnect (rcc=0x7f9271ef6840) at inputs_channel.c:482 482 inputs_relase_keys(); (gdb) bt #0 inputs_channel_on_disconnect (rcc=0x7f9271ef6840) at inputs_channel.c:482 #1 0x00007f9268e4e6b1 in red_peer_handle_incoming (handler=0x7f9271efa950, stream=0x7f9271e9e290) at red_channel.c:300 #2 red_channel_client_receive (rcc=rcc@entry=0x7f9271ef6840) at red_channel.c:309 #3 0x00007f9268e5055c in red_channel_client_event (fd=<optimized out>, event=1, data=0x7f9271ef6840) at red_channel.c:1436 #4 0x00007f926f04fca7 in qemu_iohandler_poll (readfds=readfds@entry=0x7f926f9e14c0 <rfds>, writefds=writefds@entry=0x7f926f9e1440 <wfds>, xfds=xfds@entry=0x7f926f9e13c0 <xfds>, ret=ret@entry=1) at iohandler.c:159 #5 0x00007f926f05554e in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:417 #6 0x00007f926ef2f9e5 in main_loop () at vl.c:2001 #7 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4326
So it is not so obvious what should be the solution. Otoh, qemu wakes up on keyboard events, which sounds reasonable. Otoh, spice-server make sure to release modifiers keys. Perhaps the server should track modifier state and only release when necessary?
Doing testing, I noted that win7 will go to sleep even when keyboard is pressed, and a key release event will wakeup the VM, but win7 doesn't process that event. So it will remain as if the key was pressed... I wonder if a bare-metal win7 behaves similarly.
proposed solution: http://lists.freedesktop.org/archives/spice-devel/2013-October/014741.html
Upstream as: commit 2d28da3c17f115fb1be4e5045e4a7a67fd1158b9 Author: Marc-André Lureau <marcandre.lureau> Date: Fri Oct 4 18:48:41 2013 +0200 server: release all pressed keys on client disconnect
Resetting all spice bugs to their default assignee, as I'm no longer in the Spice team.
(In reply to Hans de Goede from comment #9) > Resetting all spice bugs to their default assignee, as I'm no longer in the > Spice team. Ok that does not work, as it seems I'm still the owner lets fix that first.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Pretty sure this is long since in f20+, so closing