Number of Initialization events in vworkspace log

Hi Richard,

Computer Initialization is something that should only happen once. There are several triggers that make computer initialization happen of which provisioning or importing a computer into a group is the most common one.

If computer initialization succeeds initially but is reran later it means that the connection broker has 'lost touch' with it so it tries to re-initalize it. Network outages or firewalls are common culprits.

Let's start with the beginning: are your computers initialized successfully intially?

Hi Michel,

Yes, they do successfully initialize. 99% of the time or will eventually.

"If computer initialization succeeds initially but is reran later it means that the connection broker has 'lost touch' with it so it tries to re-initalize it. Network outages or firewalls are common culprits."

Your comment above definitely rings true to what is happening looking at the broker logs. I have attached a screen shot of the log from a vdi i was using yesterday with a wyse terminal.

I was logged on for alll of the day, but during that time there would have been periods of time when the client was locked. At no point during hte day did i have any issues with connectivity from the wyse terminal to the vdi client, nor were there any vcenter service restarts.

Does this help?

Hi Richard,

It is not normal to see so many initialization events in such a short period of time.

How many VM's have you that are showing these symptoms?

Are your connection brokers on the same network as the VM's or over a WAN link?

Are you seeing any reported connection errors in the console or just multiple VM initialization's?

Do you see any errors or warnings in the Windows event log of the VM which may be relevant?

Regards

David

Thanks David,

The connection brokers are on the same network, though my test machine is hosted in another data center. This is in the same location as 90% of machines on the 7.2MR2 environment. The storage is in the same location as the host esx box so no failover type things going on.

I will try to get some numbers for you from the log windows though may take me a little while.

No errors showing from the vcenter side, though from the vm side through the console i am seeing missing heartbeat messages.

Nothing within windows event viewer that would point to something like a faulty software component either through the security side or with the pntools agent.

One thing i have noticed though which may or may not be relevant.

running a netstat -an on my vm shows the following

machine name :1395     broker name : 8080 CLOSE_WAIT

Is this normal behaviour? Cancelling the outstanding initialize task, then drops the above connection.

Hi Richard,

Thank you for the update.

If you are seeing missed heartbeat messages, especially in succession, then this could suggest some connectivity issues. If the broker misses 3 or more heartbeat messages from a VM it will consider that machine unavailable and mark it as offline. The broker will continue to poll the offline VM with heartbeat messages, but at reduced intervals, while offline the VM will not be available to any user.

I know that your environment is 7.2 MR1 but can you check the PNtools version on the VM’s is also the same.

It would be interesting to see if there are multiple VM’s on the same subnet that have missed heartbeats at similar times or whether this more sporadic and perhaps more an issue on the broker side.

The screenshot you posted showed the initialization attempts during yesterday, is this still going on today or has it settled?

Had you sorted the columns to show all messages of the same type, were there any other status messages in between those initializations?

How many connection brokers have you in this environment?

PNtools installed is 7.2.1.461, the same happens on another vdi built using the same template using 7.1.358

Looking at the log for the one particular machine, then the missing heartbeat and initialize messages tie up with one another.

I cancelled the initialize task, and then the missing heartbeat messages ceased, these have not re-occured since. I am currently working from home today through VPN and have had a few disconnections on the VPN but none have caused any heartbeat drops in the log. Though today i am connecting via the AppPortal client (v7.2.303.461)

There are two connection brokers hosted on different esx servers, which run well under 30% utilised. VM vwBrokers have 4Gb of ram assigned and 1cpu per server, there are a total of 149 vdi machines on the brokers.

The same messages are appearing across both individual data centers. (on different IP ranges, though looking at the same set of brokers)

I'll ask someone in networks to monitor on port 8080 to see if there is anything obvious happening to the packets.

Hi Richard,

If you have any VM's with the 7.1.358 PNtools then I would suggest you look to upgrade those to 7.1 MR1 (7.1.369) or later. There was an issue in the .358 version where by it could cause the connection broker service to stop in some circumstances. This was detailed as defect 2276 in the 7.1 MR1 Release Notes. Whilst this will not be causing your current problem it could add to it.

From what you are describing there would seem to be some reliability problems for the VM's communicating with the brokers, the missed heartbeats will likely show why there are so many initialization attempts. You may want to try setting up a simple ping test or similar from the VM's to the broker to see if the connection is 100% reliable.

It would be helpful to see the connection broker logs and also the data collector log from one of the problem VM's to help diagnose this further, I would suggest opening a support case for this rather than posting large log files onto the community, is this okay with you?

Regards

David

Thanks David,

have replied via email to the CaseID generated yesterday.

Many thanks for your assistance so far.

Richard

The issue of multiple VM initialization requests has now been identified and resolved. The cause of the issue was the connection brokers being registered in the vWorkspace Console using their FQDN name, e.g. broker1.vworkspace.co.uk, this is not supported format.

The connection brokers should be identified using the NetBIOS or short name, so broker1 instead of broker1.vworkspace.co.uk.

We are still investigating the cause of the missed heartbeat messages.