CloudConcepts
Contributor
Contributor

View 4.5 - All clients disconnect and lot of java errors in Application log

Hi,

I have deployed a new View 4.5 environment on top of ESXi 4.1 and vCenter. This all runs on 2 HP DL385G6 (dual hexacore opteron with 64GB each), connected over iSCSI to a SAN. In total, about 40 Windows 7 Clients are in the pool (linked clones). All the applications are Thinapp'd. The end-users are connecting with HP Thin Clients with View Client 4.5.

Everything works great, but sometimes the customer notices that all clients disconnect at the same time. Afterwards they can reconnect and continue. At that time, there is no network disconnection on the servers, I'm monitoring the switches, vCenter server, my ESX hosts and none of them report network error. So I guess it's somehow View-related.

The VMWare view server is a VM on the cluster with 1vCPU and 4GB RAM, running Windows 2008R2, same goes for the vCenter server. I have 4 gigabit NICs for the uplink to the physical switch per host. In the VMware View server's application log I notice a lot of errors:

{!BD01015CFF5C92BC4CE757554D3D1D5) Failure during resend of data: java.net.SocketException: Connection reset by peer: socket write error com.vmware.vdi.ob.tunnelservice.u.c(SourceFile:1062)

(Request628) Tunnel reconnected when we didn't know it had disconnected (this one I get a lot of times).

I have looked on the communities and the internet, but don't seem to find much information about this. Frankly, I don't know where to look as the errors are very unclear about the source of the problems.

Any help would be appreciated.

Tags (3)
0 Kudos
6 Replies
mittim12
Immortal
Immortal

Are all of these users connecting from within the network?  If so you could try setting the server to direct mode so that clients only utilize the broker for allocation of machine and not tunneling.  If you didn't want to do everyone you could easily setup a replica connection broker and point a few specific users to that.  

0 Kudos
NelsonPSU
Contributor
Contributor

Also, you should consider the Hardware vs Software based Teradici PCoIP connection. We saw this in our environment (even with the bypass checked) when the Connection Server

1) Network dropped on Connection Server

2) When we did scheduled backups on the Connection Server  (vRanger Pro drops the connections during a backup)

3) Rebooted the Connection Server.

We found that the software based teradici directly connects to the virtual desktop for display resolution but still keeps a TCP connection channeled through the Connection Server for Keyboard and Mouse connectivity. The hardware based Teradici chip in the WYSE P20 did not drop the connection as it is able to channel the Keyboard Video and Mouse through to the virtual desktop independent of the Connection Server. Windows XP uses sofware based and the WYSE P20 has a hardware based Teradici chip. Easy test is to reboot your Connection Server and watch the PCoIP clients. RDP clients will drop everytime as they depend on the Connection Server.

0 Kudos
CloudConcepts
Contributor
Contributor

Not all the clients connect from the internal network. There are about 50% of the users connected over WAN connection, that is why we had RDP as default protocol implemented. If I need to switch it to PCoIP, it will be a serious performance-penalty. So that is no option. I can't seem to find where to set the option to direct connect in the security server settings.

Also, changing to other thin clients is also no solution, as the customer has bought brand new HP Thin Clients 🙂

0 Kudos
mittim12
Immortal
Immortal

Security server doesn't have an option to change to direct connect.  If you want to make that change it would need to be done on the connection server that is paired with the security server.  I wouldn't recommend that in a security server scenario as you would need to expose the clients in a unsecure manner to make it work.  I would only use direct connect for clients connecting inside of the network.

0 Kudos
KSUITPRO
Contributor
Contributor

I am having the same errors and issues as the OP.  Has anyone had any resolution or tips?  I can guarentee you its not our network.  VMware View 4.01 worked just fine until we switched 3 weeks ago.  VMware has produced a shotty product and they are even baffled by what they are seeing in my logs.  "Top tier support engineers" have been reviewing my case for a week now and they have no answers.

0 Kudos
npeter
Expert
Expert

I don't think your connection server configuration is well enough to run 40 tunneled connections.same for vcenter.

can you try incresing the config based on recomended values in respective installation manuals. I have experienced similar problems if the connection server is starving for resources. It could be a resourse crunch at VM level or host level.

-nObLe
0 Kudos