VMware Horizon Community
Kris_vL
Enthusiast
Enthusiast

Appstacks not attached

We set up a Horizon 6.2 environment with linked clones and appvolumes 2.9. We are using vCenter 6.0

We have an issue that a user doesn't get his assigned appstacks attached some times. In the console of app volumes we see that the user is logged in to app volumes, when we select the user we see that the user is assigned to certain appstacks, but there are no attachements. If the user logs out and logs in again it works without any other intervention. As this is quite annoying for the users, I have tried a lot of things:

1) change FQDN in app volumes agent to ip-address

2) Work with different app volumes managers (load balancing)

3) Different pools

4) Different administrator accounts in appvolumes.

It happened with different users on different machines on different pools.

Any suggestions are welcome.

Thanks!

26 Replies
Kris_vL
Enthusiast
Enthusiast

I have been trying a lot of things and finally I found a solution that seems to have resolved the issue. 

I have now a situation that the issue is gone. When I replaced the FQDN of the managers in the registry of the virtual desktop  the issue is solved. I have to use 2 managers. When I use just 1 manager, I still have the issue. It is not a DNS issue, but in the activity log of appvolume I noticed that an affected user was always connected to app volumes (so the machine found the manager at the moment of the issue).

Of course this is not a real solution. I hope that things will be better in the next version.

clay7494
Contributor
Contributor

I'm glad you were able to find a solution.  I have just started to work with app volumes and the issue you were having is pretty much identical to what I am experiencing too.  Let me ask...so are you using 2 app volume servers?  Since you said 2 managers, I am assuming you have multiple app volume servers.  Also you mentioned you replaced the FQDN of the managers in the registry.  Where you using an IP address at first?

Or are you using two managers, that point to the same server?  Maybe one with IP and one FQDN.  I am just trying to fully understand the solution you used.

Thanks again.

Reply
0 Kudos
Kris_vL
Enthusiast
Enthusiast

Yes I have 2 different App Volume servers (WIndows 2008R2)

I replaced the FQDN in the registry by the ip addresses. It is in hklm\system\CCS\Services\svservice\parameters Manager1->10.11.7.14:80  and Mnager2->10.11.7.15:80

WIth the FQDN I had issues

Kris_vL
Enthusiast
Enthusiast

Last week I got a patch version from VMware. "Version 2.9.1". I installed this version in 2 different data centers on Friday evening. The agent still is the same version, only the manager has changed. I didn't change the ip-address in a FQDN yet (in the registry of the agent/client). I will first check if this version does not give me other unwanted issues.

Reply
0 Kudos
Jason_Marshall
VMware Employee
VMware Employee

2.9.1 should resolve this. It is from bad communication responses form vCenter and the hosts. Hard to troubleshoot in logs because there would not be an actual error seen. Basically AV gets a bad response or no response and that causes some confusion with the refresher job causing some volumes to detach randomly or not detach.

Reply
0 Kudos
hockeyguyin714
VMware Employee
VMware Employee

Just to clarify App Volumes 2.9.1 will help ease the pain of environments having this issue.  The problem is that there is something going on in the infrastructure causing this issue in the first place.  vCenter SSO failing to connect due to bad configuration or bad Active Directory Servers, Network issues or latency, vCenter SQL database issues to name a few, Active Directory replication issues.  These items need to be addressed along with the hotfix to avoid it from happening in the future.

Reply
0 Kudos
Kris_vL
Enthusiast
Enthusiast

If there is something wrong with 1 domain controller, AV should take another domain controller. If there's something wrong with a DNS server another can be used. For the moment AV takes a random DC, not based on the sites and services defined in AD. I could see this behaviour multiple times.

Reply
0 Kudos