maxel
Enthusiast
Enthusiast

5 Minutes Connection Timeout to Win7 View Desktops

Hi,

we have a weird 5 minute connection timeout problem in our new View 7.03 Environment (one connection server, one security server)

in the Pool we are using the Win7 View Desktops will be powered off if no one is connected (Remote Machine Power Policy is set to power off )

If the user connect to his view desktop ( through the  view security server), the message "preparing the desktop" is shown, and then is takes  exactly 5 minutes till the desktop will show to the user. That's not normal, because in view administrator the view agent of this desktop is available after approx. 1 minute .

if we change the Remote Machine Power Policy to "stay powered on" or "suspend"..we did't have that problem..so it is only a problem with the Win7 Desktops after booting..

We have checked our firewall rules for drops but we didnt find some.

Someone an idea what we should check or change?

Used software: Horizon View Client 4.02 ; View Agent 7.0.2

7 Replies
Matthews
Contributor
Contributor

We are getting the same issue (often) with VMware View 7.0.3, View Agent 7.0.3 and various versions of View Client (Zero, Windows and Linux) and with Windows 8 Desktops.
I think that the issue only occurs with the PCoIP Protocol

We have 3 View Connetion Servers (2 x Intern and 1 x via VMware Access Point) which all show the following related error in the debug logs.

2017-06-21T12:30:03.362+02:00 DEBUG (05B4-1E48) <PendingOperation-vm-618-Starting> [MachineInformation] Agent has reported it is enabled. Waiting for status update indicating it is accepting connections.
2017-06-21T12:30:03.362+02:00 DEBUG (05B4-1E48) <PendingOperation-vm-618-Starting> [MachineInformation] Agent has reported it is accepting connections. Now collecting IP:port information for port testing.
2017-06-21T12:30:03.363+02:00 ERROR (05B4-1E48) <PendingOperation-vm-618-Starting> [PendingOperation] Pending operation failed unexpectedly with: java.lang.NullPointerException com.vmware.vdi.desktopcontroller.PendingOperation.run(SourceFile:2037)
java.lang.NullPointerException
at com.vmware.vdi.desktoptracker.MachineInformation.waitPortStatus(SourceFile:822)
at com.vmware.vdi.desktopcontroller.PendingOperation.startVm(SourceFile:6522)
at com.vmware.vdi.pendingoperations.StartVmPO.runTheOp(SourceFile:72)
at com.vmware.vdi.desktopcontroller.PendingOperation.run(SourceFile:2023)
at java.lang.Thread.run(Thread.java:745)

I would also be interested if anyone has had this fixed

0 Kudos
TechMassey
Hot Shot
Hot Shot

I have tested this in various versions of Horizon View and have always had issues. Sometimes it works, other times it does not.

My recommendation is to have enough capacity in available desktops to meet demand but the rest can be configured to be powered off. For instance, configure pool to have 2 available desktops at all times. When you have no available desktops and View powers on a desktop for an incoming connection request, there is typically always a time delay. If you want to not use this work around, then I recommend getting in contact with VMware support as it will take a lot of digging.


Please help out! If you find this post helpful and/or the correct answer. Mark it! It helps recgonize contributions to the VMTN community and well me too 🙂
0 Kudos
Bleiweiss
Contributor
Contributor

I can also confirm that this issue is still happening in the VMware View Version 7.2

I've opened a case with VMware Support (I'll let you know if I get a resolution, see you in 6 months)

Matthews
Contributor
Contributor

Reply from VMware Support...
Based on the description provided and the logs to corroborate I can say that this is a known issue with 7.x version of View. We already have a case open with our Engineering team who are currently working on this.

Current update on the Engineering ticket is that they are testing the fix provided for a connection broker in one of our labs. The update was posted this week so no results have been provided as yet.

Until testing is complete no fix/patch will be provided to customers for obvious reasons.

Aside from not using "power off" policy no other workaround has been mentioned.

snix85
Contributor
Contributor

Hi Matthews,

have you any news from the Support?

We have the same issue after upgrading ours infrastructure from 6.2.2 to 7.0.3

0 Kudos
Matthews
Contributor
Contributor

The latest news back from Support.

A hot fix for 7.2 is available (I've still not tested it yet)

0 Kudos
thmo
Contributor
Contributor

Do you happen to know if this is fixed in 7.3?

0 Kudos