Bug 1377491 - Mouse movement fails in VM after the host OS has been running for some time
Summary: Mouse movement fails in VM after the host OS has been running for some time
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: spice
Version: 24
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Christophe Fergeau
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-19 21:27 UTC by Jared Wallace
Modified: 2017-03-23 13:59 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-23 13:59:15 UTC
Type: Bug


Attachments (Terms of Use)
spice debug, bad behavior (30.54 KB, text/plain)
2016-09-19 21:27 UTC, Jared Wallace
no flags Details
spice debug, good behavior (157.61 KB, text/plain)
2016-09-19 21:27 UTC, Jared Wallace
no flags Details
VM xml dump (4.85 KB, text/plain)
2016-09-19 21:29 UTC, Jared Wallace
no flags Details
spice vdagent log from guest (8.97 KB, text/plain)
2016-09-20 12:38 UTC, Jared Wallace
no flags Details
host side logs corresponding to guest logs with debug enabled (87.93 KB, text/plain)
2016-09-20 12:54 UTC, Jared Wallace
no flags Details
guest spice logs with debug enabled (13.18 KB, text/plain)
2016-09-20 12:54 UTC, Jared Wallace
no flags Details

Description Jared Wallace 2016-09-19 21:27:11 UTC
Created attachment 1202631 [details]
spice debug, bad behavior

Description of problem:
When I first boot up the host OS (Fedora 24) I can launch virt-manager, start my VM (IBM OpenClient RHEL 6.8) and use my mouse in the VM as normal. I can then close the VM window, shut down virt-manager, reopen virt-manager, and reopen the VM, and the mouse still works. If I then close the VM windows, and wait some unknown amount of time (haven't been able to clock it), upon opening the VM window again, the mouse fails to to move - (I can see my pointer moving, but the VM thinks it is holding still). I can still click the mouse buttons, however.

This behavior can always be fixed by a reboot, but it always returns fairly quickly.

I rebooted, enabled spice debug, and captured debug traces from both a good and a bad session. I see that the good session had "mouse mode = 1", and the bad session had "mouse mode = 2". I also see an extra warning in the bad session about 'no element "avdec_h264"'

I suspect this is a Spice problem, but then I wonder why virt-manager is setting the mouse mode differently when no changes were made to the VM in between captures. I do see similar behavior with my ovirt web interface launched consoles, so again that argues for an underlying issue of some kind.

Version-Release number of selected component (if applicable):
qemu: qemu-kvm-2.6.1-1.fc24.x86_64
virt-manager: virt-manager-1.4.0-3.fc24.noarch
spice: spice-server-0.12.8-1.fc24.x86_64, spice-vdagent-0.16.0-3.fc24.x86_64

How reproducible:


Steps to Reproduce:
1. Wait 30 min to an hour after booting, and try to use a VM through virt-manager
2.
3.

Actual results:
mouse movement is not captured by the VM

Expected results:
mouse movement captured by VM

Additional info:

This is a pretty recent install. The only thing out of the ordinary that I did was install Bumblebee drivers (non-free) following this guide: https://fedoraproject.org/wiki/Bumblebee

I did revert those changes, just to see if it helped, and it did not.

Comment 1 Jared Wallace 2016-09-19 21:27:46 UTC
Created attachment 1202632 [details]
spice debug, good behavior

Comment 2 Jared Wallace 2016-09-19 21:29:25 UTC
Created attachment 1202633 [details]
VM xml dump

Comment 3 Jared Wallace 2016-09-19 21:33:15 UTC
Host machine is a Thinkpad w540, Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz, Quadro K1100M

Comment 4 Victor Toso 2016-09-20 12:27:31 UTC
Hi, thanks for taking time to report this bug.

(In reply to Jared Wallace from comment #0)
> I rebooted, enabled spice debug, and captured debug traces from both a good
> and a bad session. I see that the good session had "mouse mode = 1", and the
> bad session had "mouse mode = 2".

mouse mode 1 is server mode while mode 2 is client mode.
 
> I suspect this is a Spice problem, but then I wonder why virt-manager is
> setting the mouse mode differently when no changes were made to the VM in
> between captures.

It's not virt-manager. server mode is default mode without guest agent installed.

For some reason, the agent does not seem connected and then you fail to grab they mouse pointer on server mode.

It would be good to see the logs from the spice vdagent (from your VM) and also check if the mouse pointer might be fixed since [0]. Sadly, this fix is upstream and not yet released yet. If i provide a scratch-build, would you be able to test it (in your fedora24 [client] machine)

[0] https://lists.freedesktop.org/archives/spice-devel/2016-August/031150.html

Comment 5 Jared Wallace 2016-09-20 12:38:39 UTC
Created attachment 1202879 [details]
spice vdagent log from guest

Comment 6 Jared Wallace 2016-09-20 12:40:07 UTC
Not sure that log I uploaded has anything useful, considering no debug traces were set. I'll recapture here in a bit, after getting my daughter off to school.

I can absolutely test a different build.

Comment 7 Jared Wallace 2016-09-20 12:54:32 UTC
Created attachment 1202883 [details]
host side logs corresponding to guest logs with debug enabled

Comment 8 Jared Wallace 2016-09-20 12:54:58 UTC
Created attachment 1202884 [details]
guest spice logs with debug enabled

Comment 9 Jared Wallace 2016-09-20 12:55:56 UTC
Guest spice debug enabled. Captured host and guest both, time of reproduction of the issue was 07:52 CST

Comment 10 Cole Robinson 2017-03-12 18:04:38 UTC
jared, sorry this bug went dormant. are you still seeing this with latest packages?

moving to spice since it sounds like this isn't virt-manager specific

Comment 11 Jared Wallace 2017-03-23 12:56:21 UTC
I have since updated to Fedora 25, and the issue appears to have disappeared. Thanks for following up though :)

Comment 12 Cole Robinson 2017-03-23 13:59:15 UTC
Thanks Jared, closing. Please reopen if anyone is still hitting this


Note You need to log in before you can comment on or make changes to this bug.