I have set up VDI with a VDM broker for both internal & external use. All works fine apart from the fact that externally after a few hours (7 or
the broker stops servicing vm client requests. Prior to that everything is fine. The broker event log show a few errors (listed below). I have checked the VDM services on the broker and they are running OK. A reboot of the VDM server (which is virtual 2Gb menory single CPU) resolves the issue, but I don't want to keep doing that if it can be avoided. I have load balanced with 2 identical servers to try and reduce the impact but this is having no effect since the relevant services are still running on VDM server and hence there is no trigger to fail over. I know there are solutions address this but they do not really address the real issue, just mitigate against it. Any help or guidance would be appreciated.
Logs
!https://10.229.131.29/admin/images/small_events.gif!ASSERT: id == null (more ...) !https://10.229.131.29/admin/images/error16x16.gif!ERROR | 03/21/2008 03:28:39 PM | Assert | TP-Processor2 | |
!https://10.229.131.29/admin/images/small_events.gif!ASSERT: id == null (more ...) | !https://10.229.131.29/admin/images/error16x16.gif!ERROR | 03/21/2008 03:28:39 PM | Assert | TP-Processor2 |
!https://10.229.131.29/admin/images/small_events.gif!Error retireving user for SID null. (more ...) | !https://10.229.131.29/admin/images/error16x16.gif!ERROR | 03/21/2008 03:28:39 PM | Util | TP-Processor2 |
(Request143) Request failed: com.vmware.vdi.ob.tunnelservice.bk: Failed whilst returning body: java.io.IOException: Broken pipe com.vmware.vdi.ob.tunnelservice.dq.b(SourceFile:164) com.vmware.vdi.ob.tunnelservice.bk: Failed whilst returning body: java.io.IOException: Broken pipe at com.vmware.vdi.ob.tunnelservice.l.a(SourceFile:388) at com.vmware.vdi.ob.tunnelservice.l.b(SourceFile:419) at com.vmware.vdi.ob.tunnelservice.l.a(SourceFile:226) at com.vmware.vdi.ob.tunnelservice.dq.b(SourceFile:162) at com.vmware.vdi.ob.tunnelservice.d.run(SourceFile:167) at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: Broken pipe at simple.http.MonitoredOutputStream.destroy(Unknown Source) at simple.http.MonitoredOutputStream.write(Unknown Source) at simple.http.ResponseStream.write(Unknown Source) at com.vmware.vdi.ob.tunnelservice.dq.a(SourceFile:123) at com.vmware.vdi.ob.tunnelservice.l.a(SourceFile:386) ... 5 more !https://10.229.131.29/admin/images/small_events.gif!(Request143) Request failed: com.vmware.vdi.ob.tunnelservice.bk: Failed whilst returning body: java.io.IOException: Broken pipe com.vmware.vdi.ob.tunn (more ...) | !https://10.229.131.29/admin/images/error16x16.gif!ERROR | 03/21/2008 03:27:58 PM | SimpleAJPService | AJP-43 |
!https://10.229.131.29/admin/images/small_events.gif!ASSERT: id == null (more ...) | !https://10.229.131.29/admin/images/error16x16.gif!ERROR | 03/21/2008 03:23:22 PM | Assert | TP-Processor3 |
!https://10.229.131.29/admin/images/small_events.gif!ASSERT: id == null (more ...) | !https://10.229.131.29/admin/images/error16x16.gif!ERROR | 03/21/2008 03:23:22 PM | Assert | TP-Processor3 |
!https://10.229.131.29/admin/images/small_events.gif!Error retireving user for SID null. (more ...) | !https://10.229.131.29/admin/images/error16x16.gif!ERROR | 03/21/2008 03:23:22 PM |
Minor update - I'm having a conference call with VMware about this issue & their proposal to install a patch that appears to have worked at another customer site. Will post the outcome here.
Doug.
We had a similar issue where our external Security server would stop responding to request. This only happened about once a week and the only solution was to reboot the conection broker. I was told that VMware support that my problem has been fixed in this latest 3.01 release. Maybe it includes some other fixes as well.
If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points
Doug,
Having the same problem - would be very interested to hear the outcome of your con call ... are you running VDM or View?
Bucket
Same story here as well, I had this problem in 2.1 and now in View 3.0 it happens less frequent but the problem IS STILL THERE...hope Vmware can have this problem identified and fixed soon...we're also evaluating Windows 2008 R2 VDI as well...
the new Version 3.0.1 has the fix for that problem,
will try it on weekend.
Sergej
one of the tools that i use to tell me if there is a problem is this software from ks-soft.net , the software is called Advanced Host Monitor.
what i have the tool do besides check my network for problems is i have it ping my VMview connection servers, then i have it test my URL for the connection service.
if it fails i have it restart the vmware service. if that fails i can also have this program reboot that VM.
it also sends me an email, and tells me it failed and then again when it is fixed.
Stephen
All,
Running View 3 also, and we're experiencing the same unresponsive CB behaviour after ~24 hrs for internal VDI requests (using mixture of Wyse V10L & View Client) ... CB not responding to SSL-based connection attempts from the View Client nor via browser to ... and yet interestingly I was still able to telnet to port 80 and get some HTML spat back at me when the CB was in this state. This gave me an idea, so as test I've disabled SSL connectivity (global setting) + Direct Connect mode, and I've now had 48hrs of solid performance ... no lockups.
Might be worth a try ...
Bucket
For those on View 3 that have the same issue, did you upgrade to View 3 or was it a clean new install? That's something I'd want to know before I decide to go to View 3 since I'm currently having the issue with the latest version of VDM 2.1.
Hi, we're on VIEW 3.1 now but have upgraded from VDM 2.1 to 3.0 to 3.1 last weekend.
Hasn't happened yet on 3.1 but the problem have been very intermittent so not convinced it's fixed. It did happen on 3.0.
Well my connection broker failed for the first time after i upgraded to 3.0. from 2.1.1. and this was back when 3.0 first came out.
the service was still running. however i was unable to get to the url.a simple restart of the service fixed the problem.
i was going to open a case, however i thought i should first upgrade to 3.0.1 and hope for the best.
so lastnight after it failed i did a log capture, and then i upgraded us to 3.01. so i am hopeing this will fix the problem.
Stephen
Hi all,
we have done the update to View 3.0.1 build-142034on 9.Feb. Since the update, the problem is gone. We did not restart the service anymore and have no more connection problems.
Seems that the patch does work in 3.0.1
thx,
Sergej
