Hide Forgot
Description of problem: After installing spice vdagent on windows guest using tools from ic114 and rebooting, I connected to the guest using spice. I tried to use copy/paste fro guest to client and WAN features of spice which use vdagent. They would not work. I restarted the RHEV spice agent from Services and after that, all the features work. Version-Release number of selected component (if applicable): RHEV Spice agent from ic114. RHEL 6.1 Host: qemu-kvm-0.12.1.2-2.160.el6.x86_64 spice-client-0.8.0-2.el6.x86_64 spice-server-0.8.0-1.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install Spice Vdagent on Windows 7 64-bit guest 2. Reboot 3. Connect to guest with Spice 4. Try to use any vdagent feature like copy/paste or WAN features Actual results: Features should work. Expected results: Features don't work until RHEV Spice Agent from Services is restarted. Additional info:
Is the service set to start automatically? If it is failing the autostart is there any errors in the log/
(In reply to comment #1) > Is the service set to start automatically? If it is failing the autostart is > there any errors in the log/ By default, after installing the tools and rebooting, the service is started. I checked the RHEV Spice Agent properties and it is set to startup type automatic. It just doesn't work (features like copy-paste and WAN features don't work). I tried to restart the RHEV Spice Agent from Services in Win7 and it worked after that. I'm investigating more into this as I'm trying to debug this more & give more information on how to reproduce this.
(In reply to comment #2) > (In reply to comment #1) > > Is the service set to start automatically? If it is failing the autostart is > > there any errors in the log/ > > By default, after installing the tools and rebooting, the service is started. I > checked the RHEV Spice Agent properties and it is set to startup type > automatic. It just doesn't work (features like copy-paste and WAN features > don't work). I tried to restart the RHEV Spice Agent from Services in Win7 and > it worked after that. > > I'm investigating more into this as I'm trying to debug this more & give more > information on how to reproduce this. Is it a 7x64 specific issue? no problem with other Windows guests? Is client mouse working or you or you need to capture mouse for working (aka server mouse mode)? For agent bugs, please attach %windiir%\temp\vdservice.log & vdagent.log.
Created attachment 513819 [details] vdagent log after reboot with copy/paste,etc not working
Created attachment 513822 [details] vdservice log after reboot of guest and copy/paste not working
Attached logs from Win7 guest after reboot and where client mouse is working but copy/paste & other vdagent features are not working.
Tried to reproduce vdagent issues on WinXP. I could not reproduce. On Win7-32 and Win7-64, I see these issues. However, they are not 100% all the time. On reboot, sometimes they work and sometimes they don't.
Is the client started from rhev-m or CLI ?
WinXP guest - I tried 2 of them, one from rhev-m and one from virt-manager(with vdagent added from libvirt). Win7-32 - virt-manager(with vdagent added from libvirt)
(In reply to comment #8) > Is the client started from rhev-m or CLI ? I reproduced it on Win7x64 running the client from CLI. Still debugging it.
BZs #719140 & #722980 were caused by the same bug in the vdservice, patched by: http://cgit.freedesktop.org/spice/win32/vd_agent/commit/?id=f1bc45e5 http://cgit.freedesktop.org/spice/win32/vd_agent/commit/?id=e0a75c90 Fixed in vdagent-win-0.1-7. Problem/Solution: The ServiceMain thread [implemented in VDService::main()/execute()] is the one who normally calls all I/O operations (pipe, virtio) and waits for their completion events. The first vdagent instance launched by vdservice always works fine. In this case all the calls are performed from the ServiceMain thread. This is exactly what happens when restarting vdservice (after it stops functioning correctly...). During session changes (logon/logoff etc.), vdservice launches agent on the new session. In the buggy code, agent launching, pipe wait-for-connection (ConnectNamedPipe) & pipe async-read were all mistakenly called from the service control handler, running in a different thread than the ServiceMain thread. This implementation caused a race condition with unpredictable behavior. Ths solution was setting event in the service control handler and performing the actual operations in the ServiceMain thread. In addition, ConnectNamedPipe() was mistakenly used synchronously which "can incorrectly report that the connect operation is complete" according to msdn. This was fixed by calling the function asynchronously and waiting for its completion.
*** Bug 726702 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > *** Bug 726702 has been marked as a duplicate of this bug. *** setting severity/priority/beta1 blocker per the closed bug
Verified on vdagent-win-0.1-8.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, using the SPICE agent on Windows 7 guests could result in unexpected behavior, such as some features of the agent not working. This was caused by a bug in the VDService agent where services would be run in a different thread than the main service thread, which resulted in a race condition. The agent has been updated and services are now run in the main service thread, so the agent performs as expected.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1818.html