Summary: | VDAgent fails to respond | ||
---|---|---|---|
Product: | Spice | Reporter: | John A. Sullivan III <jsullivan> |
Component: | win32 agent | Assignee: | Spice Bug List <spice-bugs> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
First set of vdagent logs
vdagent logs from last night vdagent logs from this morning |
Created attachment 48922 [details]
vdagent logs from last night
Created attachment 48923 [details]
vdagent logs from this morning
fixed in spice/win32/vd_agent patches f1bc45e5..6b225e96. binaries at: http://www.spice-space.org/download/binaries/vdagent-win32_20110801.zip Downloaded and installed. Thanks! - John |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 48921 [details] First set of vdagent logs We are often unable to connect to our SPICE guest or the session seems to die. We then connect as administrator via RDP and restart the RHEV Spice Agent and all is well again. More specifically, often, when we try to access the guest via SPICE, we simply get a black screen and then a connection timeout. We connect to the guest via RDP as admin, restart RHEV Spice Agent service and we are then able to login. Every once in a while, the SPICE client stops responding. We restart the RHEV Spice Agent service as described and we are now able to work again. There is nothing in event logs to indicate there was a problem. The guests are Windows Server 2008 and Windows 7 - both 64 bits. The host is Fedora 15 and the clients are spicec 0.8.1 running on Debian Squeeze. I thought our qemu configuration must be off or the needed options were not support in our version (0.8.8). However, that does not appear to be the case: <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </controller> [ports='16' seems to be missing - I tried adding it but it was ignored and subsequently removed] <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> When I dump the XML to native, I get: -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x9 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 The virtio-serial driver is installed. We have specifically set power save to performance and set suspend video to never. That appeared to make it better but then it happened again. I was not able to open a spice session - just a black screen followed by "Error: unhandled exception: vdagent timeout". I double checked the Power Settings while unable to login and they were indeed on high performance with suspend video and put computer to sleep set to never. I can also add that the keyboard was extremely lagged in SPICE. I was using it without disabling effects so I exited and went in via RDP and noticed no lag. I also ran background pings to see if we had problems on the connection and it was quite healthy. I then tried SPICE again disabling all effects. That's when I noticed I could not get in. I restarted RHEV Spice Agent and was now able to get in with effects disabled but it was still very lagged. It had clearly disabled effects; the difference in the font rendering was quite noticeable. I exited again and tried via RDP and there was no lag. I then tried connecting again and once again got only the black screen. It was at that point that I grabbed the attached logs (vdagentlogs.zip). I then restarted the agent again, went in via SPICE without disabling effects and the response is much better now although keyboarding is still noticeably less crisp than RDP. I'll attach two later sets of logs taken while unable to connect via SPICE. One is from yesterday and the other is from this morning. The interesting thing about the one from this morning is that it looks like vdservice.log did was not modified since I logged out last night.