VIEW session appears to freeze but actually disconnects

[btrabue]

I have several users that are telling me that their VM is freezing on them.  They tell me that the fix is to shutdown the thin client and turn it back on and everything is ok.  I look in VIEW admin at the time that they say their session is freezing and I notice that their session actually disconnected and the thin client is making it appear that it disconnected.  By turning off the thin client and back on it is appearing to them that this is the fix. 

We currently have 2 VIEW environments that this is happening on.  4.6 and 5.1.2  Not all of the users are in the same pool and not in the same building. 

The only thing that is common between these users is that they are all using a WYSE R50 device with a 11.1.052 image on it along with the 4.6 client. 

I am told that the users can be working when the client freezes.  Does anyone have any ideas what I could look at to take care of this?  We have already contacted WYSE about screens flickering and this issue but currently they do not have any ideas.  Any help will be appreciated. 

Thank you!

[LikeABrandit]

I'm going to go ahead and guess that both environments are within the same network and domain. If that's the case, outside testing another client besides your Wyse devices to help rule them out, it sounds like whatever is affecting your users is global across your environment. Try logging the traffic for a user that reliably has the problem, then check for anything interfering with the traffic. If you can get your network guys involved I imagine that would help.

Another thing I'd check into are the PCoIP logs, at the very least you should be able to get a disconnect code from your View Agents, but still check your broker and client logs too.

[btrabue]

This is what I pulled out of the PCOIP log.  Anything stick out that might be doing this?  I'm personally thinking that it is the thin client that is doing it for whatever reason. 

01/23/2013, 13:02:58.481> LVL:2 RC:   0           AGENT :MBX_CON_CLOSED

01/23/2013, 13:02:58.481> LVL:2 RC:   0           AGENT :tera_agent_disconnect: agent close code: 3, disconnect reason: 0

01/23/2013, 13:02:58.590> LVL:2 RC:   0           AGENT :tera_agent_disconnect: connection_closed 3

01/23/2013, 13:02:59.074> LVL:2 RC:   0           AGENT :monitor thread: exiting

01/23/2013, 13:04:36.402> LVL:2 RC:   0           AGENT :pcoip_agent_connect_req

01/23/2013, 13:04:36.402> LVL:2 RC:   0           AGENT :Client address is 0.0.0.0:0 (host order)

01/23/2013, 13:04:36.402> LVL:2 RC:   0           AGENT :pcoip_agent_connect_req: For Soft Host: Using Version 1 Tag

01/23/2013, 13:04:36.402> LVL:2 RC:   0             PRI :pcoip_agent_connect_req: Session ID Tag for Soft Host: IWqSW5Yw6Zag

01/23/2013, 13:04:36.402> LVL:2 RC:   0           AGENT :server_listen_on_addr is 10.34.64.251:0 (host order)

01/23/2013, 13:04:36.402> LVL:2 RC:   0           AGENT :pcoip_agent_connect_req: Session ID = 3

[LikeABrandit]

Sorry, I think the way I wrote which logs to grab led you to a different log's disconnect code than I intended. You're looking for the pcoip_server vs pcoip_agent. Inside that log, search for:

TERA_DISCONNECT_CAUSE

Check that versus this KB:

http://kb.vmware.com/kb/2012101

Hopefully that'll give some indication. At the very least it'll tell us what the dc reason was understood to be. Also, if you're pretty sure about it being the hardware, I'd definitely look into ruling that out by using other hardware if possible. Even a laptop with View Client could work.

[memaad]

Hi,

Can you get the PCOIP logs from Vmware view client. This will give you more information.

Regards

Mohammed

[btrabue]

I think that this is what was needed.  We have other clients and I think that I am going to swap a couple out.

01/23/2013, 13:02:57.483> LVL:1 RC:-504 MGMT_PCOIP_DATA :Unable to communicate with peer on PCoIP media channels (data manager ping timer expired)

01/23/2013, 13:02:57.483> LVL:2 RC: 0 MGMT_PCOIP_DATA :mgmt_pcoip_data_set_media_activation: URBoIP is not used

01/23/2013, 13:02:57.483> LVL:2 RC: 0 MGMT_SSIG :Request to reset session (PRI: 0)

01/23/2013, 13:02:57.483> LVL:2 RC: 0 MGMT_SSIG :Session closed locally (10.**.**.***, 00-0F-01-01-01-00, PRI: 0)

01/23/2013, 13:02:57.483> LVL:2 RC: 0 MGMT_SSIG :Sending to peer: BYE disconnect reason cause (0x403)

01/23/2013, 13:02:57.483> LVL:2 RC: 0 MGMT_SSIG :Session closure reason cause (device:internal: PCoIP lost)

01/23/2013, 13:02:57.483> LVL:1 RC: 0 MGMT_DDC :mgmt_ddc_fcc_callback: queuing TERA_MGMT_FCC_EVENT_RESET [pri=0]

01/23/2013, 13:02:57.483> LVL:2 RC: 0 MGMT_VCHAN :app_reset: Session has been dropped. Forcing all channels to close!

01/23/2013, 13:02:57.498> LVL:2 RC: 0 MGMT_IMG :CODEC: State change from CODEC_CFG_EXCHANGE to CODEC_DISABLED

01/23/2013, 13:02:57.498> LVL:2 RC: 0 MGMT_IMG :CODEC: State change from CODEC_DISABLED to CODEC_DISABLED

01/23/2013, 13:02:58.481> LVL:1 RC:-500 COMMON :poll_sockets failed to generate 1 callbacks!

01/23/2013, 13:02:58.481> LVL:2 RC: 0 COMMON :TERA_PCOIP: SESSION_EVENT=TERA_MGMT_SYS_SESS_EVENT_LOST, disconnect cause (0x0)

01/23/2013, 13:02:58.481> LVL:2 RC: 0 SERVER :server main: cb_notify_session_status called (mask 0x80) with tera_disconnect_cause (0x0)

01/23/2013, 13:02:58.481> LVL:2 RC: 0 SERVER :server main: TERA_MGMT_SYS_SESS_EVENT_LOST.

01/23/2013, 13:02:58.481> LVL:2 RC: 0 SERVER :connection_closed: code = 3.

01/23/2013, 13:02:58.481> LVL:1 RC: 0 VGMAC :Session stats: Average TX=0.234381 average RX=0.0113383 (Mbps) Loss=0.00%/0.48% (R/T)

01/23/2013, 13:02:58.481> LVL:2 RC: 0 MGMT_SYS :Session lost!

01/23/2013, 13:02:58.481> LVL:2 RC: 0 MGMT_SYS :********************************************************

01/23/2013, 13:02:58.481> LVL:2 RC: 0 MGMT_SYS :********************************************************

01/23/2013, 13:02:58.481> LVL:2 RC: 0 MGMT_SYS :********************************************************

01/23/2013, 13:02:58.481> LVL:2 RC: 0 MGMT_SYS :********************************************************

01/23/2013, 13:02:58.481> LVL:2 RC: 0 SERVER :server mailbox: MBX_SHUTDOWN with agent disconnect reason code (0x0)

01/23/2013, 13:02:58.481> LVL:2 RC: 0 SERVER :server mailbox: Stopping mailbox message loop

01/23/2013, 13:02:58.481> LVL:2 RC: 0 SERVER :server main: got terminate application message

01/23/2013, 13:02:58.481> LVL:2 RC: 0 SERVER :server main: exiting

01/23/2013, 13:02:58.481> LVL:2 RC: 0 SERVER :server cleanup: tearing down pcoip with agent disconnect reason code(0) and waiting

01/23/2013, 13:02:58.481> LVL:1 RC: 0 SERVER :map_agent_to_tera: DISCONNECT_GENERIC -> TERA_DISCONNECT_CAUSE_HOST_BROKER_GENERIC

01/23/2013, 13:02:58.481> LVL:0 RC: 0 MGMT_SESS :Tearing down the session

01/23/2013, 13:02:58.481> LVL:2 RC: 0 MGMT_PERF_MON :mgmt_perf_mon_timer_cback: calling UnmapViewOfFile...

01/23/2013, 13:02:58.481> LVL:1 RC: 1 MGMT_SYS :tera_mgmt_sys_exit: tera_mgmt_perf_mon_stop() failed

01/23/2013, 13:02:58.481> LVL:2 RC: 0 MGMT_VCHAN :VChanPluginExit: Closing plugin 'VMware_Server'.

01/23/2013, 13:02:58.512> LVL:2 RC: 0 MGMT_VCHAN :VChanPluginExit: Plugin 'VMware_Server' is closed.

01/23/2013, 13:02:58.512> LVL:2 RC: 0 MGMT_VCHAN :VChanPluginExit: Closing plugin 'VMwareView-RdeVchanStub'.

01/23/2013, 13:02:58.512> LVL:2 RC: 0 MGMT_VCHAN :VChanPluginExit: Plugin 'VMwareView-RdeVchanStub' is closed.

01/23/2013, 13:02:58.512> LVL:1 RC: 0 MGMT_VCHAN :=> Successfully exited all the VChan plugins

01/23/2013, 13:02:58.512> LVL:2 RC: 0 SERVER :server cleanup: detaching inputdevtap

01/23/2013, 13:02:58.512> LVL:0 RC: 0 EXTERN :input_devtap ==> Impersonating user CDS\Mitcha2.

01/23/2013, 13:02:58.512> LVL:0 RC: 0 EXTERN :input_devtap ==> InputDevTapResetKeyboardLayout: Unable to get list of requested layouts.

01/23/2013, 13:02:58.512> LVL:2 RC: 0 SERVER :server cleanup: closing mailboxes

01/23/2013, 13:02:58.512> LVL:2 RC: 0 SERVER :server cleanup: freeing argument copy

01/23/2013, 13:02:58.512> LVL:2 RC: 0 SERVER :server cleanup: cleanup complete

[LikeABrandit]

Well, you have the most fun and non-descript disconnect cause of them all, the HOST_BROKER_GENERIC, with it's description of:

"PCoIP connection not established because of cancellation. This should not occur. Contact Teradici support."

It's possible you're on the right track with the hardware considering. I didn't see anything in that log that would tip me off personally, I was hoping the disconnect code would be useful or something else would stick out. Although, maybe someone else who has more insight into the logs will know more. Either way, definitely let us know if the hardware swap has any results.

[mindli]

Hi,

Were you able to solve the disconnect problem? We have the same symptoms with a few vdi clients (exactly the same generic disconnect) and I don't know what to do but installing the clients from scratch...

Thanks and cheers

[btrabue]

mindli,

We found that it had something to do with the thin client and the image that was on it.  We changed the Linux image to a different version and it took care of the issue.  So far WYSE has not been able to find out why it was happening.

Good luck!