Bug 871240

Summary: Guest is unsuspended (S3) if remote-viewer window is closed
Product: [Fedora] Fedora Reporter: Cole Robinson <crobinso>
Component: spiceAssignee: Christophe Fergeau <cfergeau>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: alexl, amit.shah, berrange, cfergeau, dblechte, dwmw2, hdegoede, itamar, jforbes, kem, knoel, kraxel, marcandre.lureau, pbonzini, ricardo.arguello, rjones, scottt.tw, uril, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-27 08:39:41 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Cole Robinson 2012-10-29 22:44:49 EDT
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.
Comment 1 Cole Robinson 2012-10-29 22:45:27 EDT
Using spice + qxl FWIW
Comment 2 Cole Robinson 2013-09-09 10:16:59 EDT
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
Comment 3 Marc-Andre Lureau 2013-09-09 11:43:32 EDT
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.
Comment 4 Marc-Andre Lureau 2013-10-03 10:46:26 EDT
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
Comment 5 Marc-Andre Lureau 2013-10-03 10:52:23 EDT
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?
Comment 6 Marc-Andre Lureau 2013-10-04 10:15:05 EDT
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.
Comment 7 Marc-Andre Lureau 2013-10-04 12:52:08 EDT
proposed solution:
http://lists.freedesktop.org/archives/spice-devel/2013-October/014741.html
Comment 8 Cole Robinson 2013-12-17 15:44:07 EST
Upstream as:

commit 2d28da3c17f115fb1be4e5045e4a7a67fd1158b9
Author: Marc-André Lureau <marcandre.lureau@gmail.com>
Date:   Fri Oct 4 18:48:41 2013 +0200

    server: release all pressed keys on client disconnect
Comment 9 Hans de Goede 2014-03-17 05:03:18 EDT
Resetting all spice bugs to their default assignee, as I'm no longer in the Spice team.
Comment 10 Hans de Goede 2014-03-17 05:09:42 EDT
(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.
Comment 11 Fedora Admin XMLRPC Client 2014-03-17 05:25:35 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Cole Robinson 2015-03-27 08:39:27 EDT
Pretty sure this is long since in f20+, so closing