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 |
We've been having this issue among others with VDM 2.0. The problem now is that VDM 2.1 has been released, and any issue you raise is going to result in them asking you to upgrade as 'this version contains many fixes for known problems' etc etc etc etc.
So, guess what - I'm planning upgrades to VDM 2.1!!!
Doug.
Hello,
we have updated to VDM 2.1 and the issue is still there. We have to restart the service twice a day or more.
I have a task that restarts the service, but this is not applicable for a production environment.
We have been tracking this problem but cannot reproduce it. In order to help with this could you provide some information about your environment and the exact nature of the problem. The following would help:
Describe your environment: the number of Connection Servers and Security Servers, use of load balancers, running on physical or virtual machines, what OS (including patch level) are you using, how is the OS customized (vanilla build or in-house hardeneded/modified builds)
Level of use of the environment: numbers of users, typical number of sessions per day
Network topology: If you have Security Servers, are they in a DMZ. Do clients access VDM directly over a LAN, from the Internet, over a VPN connection
Type of use: predominantly using web access or the native client
The problem: how exactly does it manifest itself (client refuses to connect, or disconnects after authentication)
Frequency of the problem: does it happen to all Connection/Security Servers or just a subset, does it happen after a number of session connections or after a period of time.
Finally, if you are running on VMs, would it be possible to take a copy of a VM with a snapshot of the VM when its in a failed state. If the problem happens on Security Servers, these would be easiest to take as they contain no sensitive data.
I know this is a lot of questions, but using the information you supply we may be able to narrow this problem down. We can take this offline if you would like.
Many thanks,
Frank.
Hello,
here our environment:
we have one Connection Server running on Virtaul Machine, OS is Windows 2003 Standard Edition SP2 (with all latest patches from Windows Update) no special configurations
Virtual Machine has 1xCPU, 1GB RAM (430MB free), 10GB HDD
*at the moment we have 10 VDIs and 14 Users, number of Sessions are 5-6 per day
access to VDM is directly, no DMZ, no VPN...
We use Wyse ThinClients S10 and web Access to acces the VDM
the problem is that the clients loses the connection and cannot connect again. The Admin Site of VDM is not Responding, but the Services are running. We have to restart them and then it works again
*it happen after a period of time 6-8 hours maybe
i will try to take a snapshot when it happens again and i am in the office
with kind regards
Sergej
Hello,
here our environment:
we have one Connection Server running on Virtaul Machine, OS is Windows 2003 Standard Edition SP2 (with all latest patches from Windows Update) no special configurations
Virtual Machine has 1xCPU, 1GB RAM (430MB free), 10GB HDD
*at the moment we have 10 VDIs and 14 Users, number of Sessions are 5-6 per day
access to VDM is directly, no DMZ, no VPN...
We use Wyse ThinClients S10 and web Access to acces the VDM
the problem is that the clients loses the connection and cannot connect again. The Admin Site of VDM is not Responding, but the Services are running. We have to restart them and then it works again
*it happen after a period of time 6-8 hours maybe
i will try to take a snapshot when it happens again and i am in the office
with kind regards
Sergej
Many thanks for the swift update.
can you tell me the s/w version that your S10 clients are running?
Thanks,
Frank.
Hi,
Firmware is 5.3.0_09
Thanks
Sergej,
FYI, we also have a VDM Connection Server running as a VM and had exactly the same issue. Increasing the amount of RAM allocated to the VM has helped considerably - we pushed ours up from 1.6GB to 4GB and have had very few instances of this happening since. Our VDM Connection Server is running anything between 30-50 concurrent connections.
Rgds,
Doug.
Come to think of it, we had the same similar problems. The admin console would not respond or be VERY VERY slow in responding (like waiting up to 1-2 minutes for the login screen). We also had problems with users logging in, but I never heard any details other than I'ts not letting me log in. I don't know the specifics.. We are using DMZ though. In any case, I've reinstalled my entire VDI environment with 2.1 and increased the RAM from 1.5 gig to 3 gig on the VDM broker server, and these issues seem to have gone away..
Perry
Ok i will increase the RAM of VDM Machine and look what happen.
will post the result
Hello,
i set the Mem to 2 GIG with no success. The same problem after several hours cannot connect. The memory usage at that moment is 600MB of 2Gig. The ws_TomcatService.exe hhas a consumtion of 160MB.After ServiceRestart is works again.
that drives me crazy
Hi, did you manage snapshot a VM in the failed state? Would it be possible to have a copy so we can analyse the problem?
Thanks,
Frank.
Hello,
seems that i found the failure.
We have McAfee VirusScan on the VDM host installed. I disabled the scanner to scan the VDM and ADAM folders.
Now the Service works for a week without problem.
Will look for couple of weeks if the service is running well.
thx,
Sergej
Sergej,
that's good news.
Please can you tell us a bit more about your McAfee configuration. Does it include a firewall component? Did it log any problems whilst it was enabled?
Thanks,
Frank.
Hi Frank,
the config of McAfee VirusEnterprise 8.5.0.i is following:
AccessProtection is OFF:Firewall component is disabled
Only Accessscanner is ON and with the rule not to scan the VDM and ADAM folders.
kind regards
Sergej
Thanks for the swift reply. We'll see if we can reproduce the problem using this virus scanner.
Can anyone else who has seen this problem comment on their use of virus scanners?
Thanks,
Frank.
I also use McAfee VirusEnterprise 8.5.0.i however i never quite had this problem.
i did what you said so if there is the problem I wil not get it.
We have tried to reproduce the problem with the same virus scanner installed but have not been able to get it to fail.
If anyone has this problem on a VM, could they send us a copy of the VM with a running snapshot of when the problem is manifested (contact via the forum to arrange). Without the ability to reproduce this problem it will be very hard to fix.
Many thanks,
Frank.
Hello,
the problem is still there.
The last weeks, when i think the problem is gone, one operator from other location did restart the service in the morning. ggrr
I have a snapshot of the VM at the state of no connect to VDi and logfiles at the same time.
How can i upload the snapshot to you? Which files do you need?
kind regards
Sergej
Sergej,
I'm sorry to hear that you still have the problem. However this is helpful for us as we can now investigate the problem.
I'll contact you with details on how to upload the VM.
Thanks,
Frank.
