Jump to content
Welcome to our new Citrix community!
  • 0

VDI "Contact Lost" Windows 10 1903 + VDA1906.2


tylital520

Question

Hi,

our VDI Desktops are showing "Contact Lost" error in Director on a daily basis. I have to run "Force Restart" to get them to register again to the Delivery Controller. I think this started either when I updated the VDA, or after the Windows 10 upgrade to version 1903. Has anyone else experienced this issue? Here's the error message on Director:

 

Quote

The Delivery Controller lost connection with the VDA. This may likely be caused by network disruptions.

 

Windows 10 1903

VDA1906.2

ESXi 6.0 U3

VMware Tools 10.2.5 build-8068406

 

 

Link to comment

16 answers to this question

Recommended Posts

  • 0
7 hours ago, Nick Casagrande1709152718 said:

i have a ticket open for something similiar.  are you getting ddc application error in event log of 1039 or 1116?

A few yes. I did find duplicate entries from our DNS which might explain this, and I also downgraded VMware tools to version 10.0.9 build 3917699. After those changes this is not happening as often as before.

Link to comment
  • 0
7 hours ago, tylital520 said:

Hi,

are you using MCS RAM & Disk cache on your Machine Catalog? I think using this feature was the reason our VDI's lost contact.

I am not.  I turned that off a really long time ago, very buggy and actually caused worse performance on my ssd array.  Actually doing some research last night, it seems that the DDC is not issuing a shutdown command to the VDA's.  Support is looking into this still.  I can see this from VDA's that are showing as disconnected and then looking at the application event log on the ddc and not finding a shutdown command issued to it

Link to comment
  • 0

so after 3 months or so and dozens of logs and traces later, support is saying i need to open a ticket with MS as something is blocking pica from shutting down gracefully.  i'm sure they're correct as i've had L3 and developers give me a few different things to get through this.  weird part however is that it only happens like 3% of the time each day or something small like that.  i can have user1 log off gracefully 50 times with no issues and then one time his logoff gets trashed for some reason and he is still logged into the vm, the user never sees an error either but cdf logs show it, hence users come to work the next day and one of them will hit that "broken" vm and can't login.  currently scheduled tasks allow me to sleep b/c i reboot all vm's at 2am via esx powercli command so everyone gets in just fine.  just waiting for support to analyze one more log and then i pay MS $500 to figure this out i guess.  

Link to comment
  • 0

Hi NICKCASA:

Thanks for taking time to Reply.

Are you guys a VMware shop?  If so, what version of VMware Tools are running on the VDAs that have this issue?  The reason I ask is that when Director tells me "Contact Lost" -- and sure enough, Studio shows a VDA as "Registration Missing" -- I look at that VM in vCenter and it shows VMware Tools as "Not Running"... Like somehow the NIC just died or something... I don't know yet if this is an actual Clue or just a happen-stance... You're right, a Reboot of the VDA brings it back...

Link to comment
  • 0

tylital520,

Did you ever come up with a good solution for this?

 

nickcasa,

Now Citrix is sending me to Microsoft, too... I don't think MS will be able to help, though, since this does seem to be a VMware NIC issue... When I get "Contact Lost" in Director, and "Registration Missing" in Studio, the only way to recover that Machine is a hard reboot.  So *something* is randomly turning off VMware Tools (at least the NIC portion)...

 

If you all run across any clues that could help clear this up for us, that'd be great.

Thanks --

Link to comment
  • 0

We´ve gotten this problem too.

 

The worst part, Its randomly. We have just 10 VMS to Session Apps (xenapps) with MCS. Ram cache disk.

After this error, machine gets unresponsible with session named (3) logged. 

we need to restart entire vm. 

 

I agree. I suspect the problem could be our vmware, or vmtools.  I dont know how to go deep and analyse this.

 

any clues?

Link to comment
  • 0

We have this issue also.  It's random, happens regularly (usually one machine, sometimes two), especially when User activity is high on the (Citrix) Cluster (we're a VMware shop).  Happens in our European data center too.  Environment is 1912, VMware Tools 11.0.5, Windows Updates most recent.  DNS is fine.

 

We opened a Ticket with Citrix on this.  After they analyzed the Dump file we sent them, they declared that it was a Microsoft issue (RDP-related process hung, they said)... Microsoft did their own analysis of the same Dump file and declared it to be a VMware problem (Storage issue, they said)...

 

We tried turning off Power Management on the vNIC of the VDAs, and that doesn't seem to help much.

 

Does anyone have any new insights on this?

Link to comment
  • 0

After quite a lot of work, and weeks and weeks of Dump analysis by both Microsoft and Citrix, our focus now is on the idea that the Temporary Disk Cache -- part of the MCSIO configuration -- is filling up and crashing the machine.  The config is 1Gb of Temp Mem Cache and 10Gb for Temp Disk Cache...

 

Is anyone else who is having this issue using MCSIO?  What are your configuration settings for MCSIO on the Catalog(s) having the issue?

Link to comment
  • 0

I rebuilt our VM pool without MCSIO and keep having the same problem so there must be another cause. I bet that there are multiple reasons why this happens making this so hard to diagnose and fix. 

 

The temp cache was definitely an issue though as we saw the disks fill up and made them bigger which helped reduce the problem months ago while not eliminating it. 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...