daleallenc
Contributor
Contributor

View Secure server flaky

I've had to reboot my View Secure gateway a couple of times now because the View Portal was inaccessible. I'm a Windows IIS guy, not an Apache guy, so I'm not even sure what to look for to prevent a reoccurence of whatever's happening. The server's in the DMZ and works normally most of the time. Because we're early in our View deployment, we've got less than a dozen users remotely accessing virtual desktops.

Any ideas?

0 Kudos
33 Replies
BDogg
Contributor
Contributor

I was searching the forums for an answer to this as well. I have the exact same experience. Sometimes the login to our VDI environment from the outside can take up to 2 minutes. Sometimes it's really fast. It almost seems like the Security Server has to "wake up"?

Is there anything we can do to speed up the login to our security server from the internet?

Brian

0 Kudos
lbourque
VMware Employee
VMware Employee

A few ideas to look into:

1. traceroute packets done from external to security (from multiple providers) and then from security to connection server

2. ensure you have FULL reverse and forward lookup enabled for your DNS

3. check the security servers logs to see if there are any errors showing up there (perhaps it's timing out somewhere?)

4. Are either of you using a VPN?

I connect into my test environment in Palo Alto from NYC without problem (takes less than a second).

0 Kudos
daleallenc
Contributor
Contributor

It's possible that I didn't explain this properly.

External requests intermittantly do not access to the View Portal web page at all. The only thing that seems to fix this access problem is re-booting the Secure serve. I've tried restarting the View Security Server service, but that does not restore access.

Nevertheless, in answer to your questions:

Traceroutes from the external sources only hit the external (public) interface and IP address (which doesn't tell me if the web server is working or not).

Traceroute from the Secure server to the Connection server is only a single hop, and it's good.

We have full reverse and forward lookup enabled in DNS.

No VPN access is involved.

I am getting Warnings in the logs. Unfortunately, they look like Java errors, and I have no idea what they mean:

(A5B4DA1780DA517357562985A7D6C7E1) Exception while forwarding data to tunnel: java.io.IOException: Stream closed com.vmware.vdi.ice.server.c.a(SourceFile:208)

java.io.IOException: Stream closed

at simple.http.MonitoredOutputStream.ensureOpen(MonitoredOutputStream.java:145)

at simple.http.MonitoredOutputStream.write(MonitoredOutputStream.java:106)

at simple.http.ResponseStream.write(ResponseStream.java:141)

at java.io.BufferedOutputStream.flushBuffer(Unknown Source)

at java.io.BufferedOutputStream.write(Unknown Source)

at java.io.FilterOutputStream.write(Unknown Source)

at com.vmware.vdi.ice.server.az.a(SourceFile:105)

at com.vmware.vdi.ob.tunnelservice.ch.c(SourceFile:1140)

at com.vmware.vdi.ob.tunnelservice.t.a(SourceFile:1082)

at com.vmware.vdi.ob.tunnelservice.t.a(SourceFile:1021)

at com.vmware.vdi.ob.tunnelservice.az.a(SourceFile:560)

at com.vmware.vdi.ice.server.c.a(SourceFile:206)

at com.vmware.vdi.ice.server.au.run(SourceFile:152)

at java.lang.Thread.run(Unknown Source)

and this:

(A5B4DA1780DA517357562985A7D6C7E1) Exception while forwarding data to tunnel: java.io.IOException: Broken pipe com.vmware.vdi.ice.server.c.a(SourceFile:208)

java.io.IOException: Broken pipe

at simple.http.MonitoredOutputStream.destroy(MonitoredOutputStream.java:159)

at simple.http.MonitoredOutputStream.write(MonitoredOutputStream.java:111)

at simple.http.ResponseStream.write(ResponseStream.java:141)

at java.io.BufferedOutputStream.write(Unknown Source)

at java.io.FilterOutputStream.write(Unknown Source)

at com.vmware.vdi.ice.server.az.a(SourceFile:105)

at com.vmware.vdi.ob.tunnelservice.ch.c(SourceFile:1140)

at com.vmware.vdi.ob.tunnelservice.t.a(SourceFile:1082)

at com.vmware.vdi.ob.tunnelservice.t.a(SourceFile:1021)

at com.vmware.vdi.ob.tunnelservice.az.a(SourceFile:560)

at com.vmware.vdi.ice.server.c.a(SourceFile:206)

at com.vmware.vdi.ice.server.au.run(SourceFile:152)

at java.lang.Thread.run(Unknown Source)

and this:

(Request488) Request failed: com.vmware.vdi.ob.tunnelservice.cx: Failed whilst returning body: java.net.SocketException: Connection reset by peer: socket write error com.vmware.vdi.front.e.b(SourceFile:178)

com.vmware.vdi.ob.tunnelservice.cx: Failed whilst returning body: java.net.SocketException: Connection reset by peer: socket write error

at com.vmware.vdi.ob.tunnelservice.cg.a(SourceFile:390)

at com.vmware.vdi.ob.tunnelservice.cg.c(SourceFile:421)

at com.vmware.vdi.ob.tunnelservice.cg.a(SourceFile:228)

at com.vmware.vdi.front.e.b(SourceFile:176)

at com.vmware.vdi.front.g.run(SourceFile:190)

at java.lang.Thread.run(Unknown Source)

Caused by: java.net.SocketException: Connection reset by peer: socket write error

at java.net.SocketOutputStream.socketWrite0(Native Method)

at java.net.SocketOutputStream.socketWrite(Unknown Source)

at java.net.SocketOutputStream.write(Unknown Source)

at com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(Unknown Source)

at com.sun.net.ssl.internal.ssl.OutputRecord.write(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)

at java.io.OutputStream.write(Unknown Source)

at simple.http.MonitoredResponse.commit(MonitoredResponse.java:566)

at simple.http.MonitoredResponse.ensureCommit(MonitoredResponse.java:167)

at simple.http.MonitoredResponse.getOutputChannel(MonitoredResponse.java:617)

at simple.http.ResponseStream.getOutputStream(ResponseStream.java:272)

at simple.http.ResponseStream.flushBuffer(ResponseStream.java:206)

at simple.http.ResponseStream.write(ResponseStream.java:138)

at com.vmware.vdi.front.e.a(SourceFile:137)

at com.vmware.vdi.ob.tunnelservice.cg.a(SourceFile:388)

... 5 more

0 Kudos
lbourque
VMware Employee
VMware Employee

Go to services.msc and see restart the View Security server service. It'll take care of the rest.

What version of Windows 2003 is this? Is anything else installed on this system?

0 Kudos
daleallenc
Contributor
Contributor

Microsoft Windows Server 2003 R2 Service Pack 2.

From Add or Remove Programs:

McAfee VirusScan Enterprise

Microsoft .NET Framework 2.0 Service Pack 1

VMware Tools

VMware View Connection Server

And all Microsoft updates through March 6th.

That's it. Pretty basic.

0 Kudos
BDogg
Contributor
Contributor

I enabled DNS and reverse DNS to the Security Server, and that did seem to help - this is the sympton that it seemed to be having. I got similar warnings in the Application Log as well, and I opened up Ports 80 and 443 outbound to hopefully help this:

(Request105) Request failed: com.vmware.vdi.ob.tunnelservice.dd: Failed whilst returning body: java.net.SocketException: Connection reset by peer: socket write error com.vmware.vdi.front.e.b(SourceFile:178)

com.vmware.vdi.ob.tunnelservice.dd: Failed whilst returning body: java.net.SocketException: Connection reset by peer: socket write error

at com.vmware.vdi.ob.tunnelservice.cm.a(SourceFile:390)

at com.vmware.vdi.ob.tunnelservice.cm.c(SourceFile:421)

at com.vmware.vdi.ob.tunnelservice.cm.a(SourceFile:228)

at com.vmware.vdi.front.e.b(SourceFile:176)

at com.vmware.vdi.front.g.run(SourceFile:190)

at java.lang.Thread.run(Unknown Source)

Caused by: java.net.SocketException: Connection reset by peer: socket write error

at java.net.SocketOutputStream.socketWrite0(Native Method)

at java.net.SocketOutputStream.socketWrite(Unknown Source)

at java.net.SocketOutputStream.write(Unknown Source)

at com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(Unknown Source)

at com.sun.net.ssl.internal.ssl.OutputRecord.write(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)

at java.io.OutputStream.write(Unknown Source)

at simple.http.MonitoredResponse.commit(MonitoredResponse.java:566)

at simple.http.MonitoredResponse.ensureCommit(MonitoredResponse.java:167)

at simple.http.MonitoredResponse.getOutputChannel(MonitoredResponse.java:617)

at simple.http.ResponseStream.getOutputStream(ResponseStream.java:272)

at simple.http.ResponseStream.flushBuffer(ResponseStream.java:206)

at simple.http.ResponseStream.write(ResponseStream.java:138)

at com.vmware.vdi.front.e.a(SourceFile:137)

at com.vmware.vdi.ob.tunnelservice.cm.a(SourceFile:388)

(Request102) Request failed: com.vmware.vdi.ob.tunnelservice.dd: Failed whilst returning body: java.net.SocketException: Connection reset by peer: socket write error com.vmware.vdi.front.e.b(SourceFile:178)

com.vmware.vdi.ob.tunnelservice.dd: Failed whilst returning body: java.net.SocketException: Connection reset by peer: socket write error

at com.vmware.vdi.ob.tunnelservice.cm.a(SourceFile:390)

at com.vmware.vdi.ob.tunnelservice.cm.c(SourceFile:421)

at com.vmware.vdi.ob.tunnelservice.cm.a(SourceFile:228)

at com.vmware.vdi.front.e.b(SourceFile:176)

at com.vmware.vdi.front.g.run(SourceFile:190)

at java.lang.Thread.run(Unknown Source)

Caused by: java.net.SocketException: Connection reset by peer: socket write error

at java.net.SocketOutputStream.socketWrite0(Native Method)

at java.net.SocketOutputStream.socketWrite(Unknown Source)

at java.net.SocketOutputStream.write(Unknown Source)

at com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(Unknown Source)

at com.sun.net.ssl.internal.ssl.OutputRecord.write(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)

at java.io.OutputStream.write(Unknown Source)

at simple.http.MonitoredResponse.commit(MonitoredResponse.java:566)

at simple.http.MonitoredResponse.ensureCommit(MonitoredResponse.java:167)

at simple.http.MonitoredResponse.getOutputChannel(MonitoredResponse.java:617)

at simple.http.ResponseStream.getOutputStream(ResponseStream.java:272)

at simple.http.ResponseStream.flushBuffer(ResponseStream.java:206)

at simple.http.ResponseStream.write(ResponseStream.java:138)

at com.vmware.vdi.front.e.a(SourceFile:137)

at com.vmware.vdi.ob.tunnelservice.cm.a(SourceFile:388)

Problem setting up HTTP connection: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake - Repeated 4 times

0 Kudos
jflisher
Contributor
Contributor

I am getting very similiar warning/errors. We mostly connect using the View client, installed on thin clients and other machines on our LAN.

Here is what happens.

1. Connection broker (view manager) seems to hang up. Anybody trying to establish a new connection gets denied. Those that are already connected do not get booted off. Make sure Direct Connect is on. See attached.

2. Stop and Stop these two services. "VMware View Connection Server" , "VMWareVDMDS"

3. Problem Fixed.

This of course is not a solution.

Here is the warning.

at com.vmware.vdi.ob.tunnelservice.cg.a(SourceFile:390)

at com.vmware.vdi.ob.tunnelservice.cg.c(SourceFile:421)

at com.vmware.vdi.ob.tunnelservice.cg.a(SourceFile:228)

at com.vmware.vdi.front.e.b(SourceFile:176)

at com.vmware.vdi.front.g.run(SourceFile:190)

at java.lang.Thread.run(Unknown Source)

Caused by: java.net.SocketException: Connection reset by peer: socket write error

at java.net.SocketOutputStream.socketWrite0(Native Method)

at java.net.SocketOutputStream.socketWrite(Unknown Source)

at java.net.SocketOutputStream.write(Unknown Source)

at com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(Unknown Source)

at com.sun.net.ssl.internal.ssl.OutputRecord.write(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)

at java.io.OutputStream.write(Unknown Source)

at simple.http.MonitoredResponse.commit(MonitoredResponse.java:566)

at simple.http.MonitoredResponse.ensureCommit(MonitoredResponse.java:167)

at simple.http.MonitoredResponse.getOutputChannel(MonitoredResponse.java:617)

at simple.http.ResponseStream.getOutputStream(ResponseStream.java:272)

at simple.http.ResponseStream.flushBuffer(ResponseStream.java:206)

at simple.http.ResponseStream.write(ResponseStream.java:138)

at com.vmware.vdi.front.e.a(SourceFile:137)

at com.vmware.vdi.ob.tunnelservice.cg.a(SourceFile:388)

Has anybody else had similar problems, and have they been able to fiox this???????????????/

0 Kudos
lbourque
VMware Employee
VMware Employee

Are all of you using 3.0.0 or 3.0.1?

If there is a bunch of you having an issue, it may be worthwhile to file a support ticket to perhaps see if this is a more of a bug than a setup/design issue.

0 Kudos
daleallenc
Contributor
Contributor

I was getting ready to ask the same question.

We're using 3.0.1.

We had been using 3.0.0 and had not seen this problem with it.

Could be a coincidence or a bug introduced with 3.0.1?

0 Kudos
jflisher
Contributor
Contributor

3.01

We have a support ticket open right now. It's been on going for awhile. I am trying to explore other avenues to hopfully resolve the issue.

0 Kudos
lbourque
VMware Employee
VMware Employee

If you have a support ticket, point them to this thread. It may be something new introduced into 3.0.1 accidentally or from some other component upgraded. Support won't know of things unless there is a cluster of tickets. This will probably help.

0 Kudos
BDogg
Contributor
Contributor

Have you heard anything back from support?

0 Kudos
jflisher
Contributor
Contributor

We have been in contact with support and made a few configuration changes. Most notably bumped up the memory on the view managers to 3 GB. So far today we have not had any calls in regards to people unable to connect. Keep your fingers crossed. We have this deployed to about 40 users.

0 Kudos
CWedge
Enthusiast
Enthusiast

We have been in contact with support and made a few configuration changes. Most notably bumped up the memory on the view managers to 3 GB. So far today we have not had any calls in regards to people unable to connect. Keep your fingers crossed. We have this deployed to about 40 users.

How do you do that?

0 Kudos
jflisher
Contributor
Contributor

I am assuming your asking about the memory increase. I should have stated that both of our view managers are virtual machines. So bumping the memory up on them was just a quick config change for both in VC.

0 Kudos
daleallenc
Contributor
Contributor

My workaround: I've scheduled our Secure server to re-boot now every night at oh-dark-thirty. That seems to have helped. As near as I can tell, nobody has lost access to the View Portal since I started re-booting it at the beginning of the week.

Specifics: I created "reboot.bat" and it only has one line in it: shutdown -r -t 0. I then set Task Scheduler to run reboot.bat Daily at 04:30 am.

0 Kudos
jflisher
Contributor
Contributor

That was going to be my next step. We've had two days without issues since we bumped up the memory.

daleallenc - How many virtual desktops do you have in production? How many view managers are you using?

0 Kudos
daleallenc
Contributor
Contributor

I'm running 11 full persistent clones, along with the Connection server, and Secure server running on a single host.

0 Kudos
daleallenc
Contributor
Contributor

jflisher, I was wondering if you'd gotten anything back from support or had any other movement on this?

I talked with our systems engineer on this and he also recommended a bump in RAM to 3GB -- said that the View service will utilize all of that, but that VMware's testing shows no benefit in going with more than 3GB. So I bumped up both the Connection and the Secure servers.

Then we got another failure 4 days later.

At this point, I'd just like an email warning that something is amiss - and not one from one of my users.

0 Kudos