Bug 718463

Summary: client mouse doesn't work after migration
Product: Red Hat Enterprise Linux 6 Reporter: Yonit Halperin <yhalperi>
Component: spice-serverAssignee: Arnon Gilboa <agilboa>
Status: CLOSED DUPLICATE QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1CC: alevy, amit.shah, cmeadors, dblechte, kraxel, mkenneth, mkrcmari, quintela, tburke, tpelka, yhalperi
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 725965 (view as bug list) Environment:
Last Closed: 2011-08-03 16:19:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 725965    

Description Yonit Halperin 2011-07-03 09:27:46 UTC 
Description of problem:
Windows guest(Xp/Windows 7).
After migration, the client mouse turns to server mouse.
After restarting the agent, client mouse is back.
Comment 2 Yonit Halperin 2011-07-24 08:13:58 UTC 
After migration, qemu_chr_open_spice is not called, and the spice server is not aware of the vdagent's char device. From what I see, Virtio doesn't have special callbacks for loadvm and it doesn't calls the 'open' callbacks of the char devices upon loadvm.
Whose responsibility should it be?
Comment 5 Alon Levy 2011-08-03 16:19:09 UTC 
The bug is not in the spice-server component, closing as not a bug, the solution is on the qmeu-kvm component: RHBZ#725965 (which is now in POST, and has four acks so it should be built Any Time Now).
Comment 6 Cameron Meadors 2011-08-04 15:13:56 UTC 
It is still a bug just not in spice-server. Why not change the component to qemu-kvm and make this a duplicate of the bug #725965?
Comment 7 Alon Levy 2011-08-04 16:11:02 UTC 
Sounds fine. I don't know what the correct thing here is, both sound good, but your solution sounds better.

*** This bug has been marked as a duplicate of bug 725965 ***