Strange performance issue with profile only writable

[LukaszDziwisz]

Hello Everyone,

Roughly 2 months ago we have upgraded our AppVolumes server and agents from 2.16 to 2.18.6 and since then we are seeing some very random, sporadic performance issues for some users. The symptoms are slow Outlook ( clicking on email goes through contacting Exchange server couple of times), IE launching takes forever to bring up home pages and our instant messaging client Cisco Jabber doesn't connect at all. Also, search function doesn't work at all and won't even let the user type in anything.  Other things appear to be working fine, launching Chrome brings everything much quicker, other apps appear to be working fine. We checked the VM performance and everything seems fine, CPU at 15%, Memory barely at 12%, GPU is fine, no latency in storage or networking. Logging off and back on doesn't resolve the problem. So far the only fix is either to disable writable or delete it and let it recreate. On average we are seeing it on like 3-5 users per week now. One thing to mention, is that after upgrading I have updated templates for this writable type and I have noticed that the snapvol.cfg is quite different from what 2.16 had but none of the users have that updated, meaning that they still have the old snapvol.cfg. Even after deleting user's writable, new one created doesn't have new snapvol.cfg that is included with the template. I have attempted to replace it with the new one on one of the users to test but it didn't seem to have any effect. 

Additional info: Horizon 7.13, ESXi 6.7, Windows 1809 LTSC, AppVolumes 2.18.6

Any help would be much appreciated.

[Ray_handels]

I have seen this issue before, exactly this. We found out that we needed to exclude the %TEMP% directory from the writable volume. Normally this is soemwhere within your Appdata or Appdatalocal.

Here is a link on how to exclude folders from the writable.

https://docs.vmware.com/en/VMware-App-Volumes/4/com.vmware.appvolumes.admin.doc/GUID-73986A35-F00B-4...

[LukaszDziwisz]

@Ray_handels ,

Thank you for that information. I remember that conversation about writable optimization. We have that exclusion in place some time ago but then it was identified to cause some issues with applications using that temp folder and we had to take it out. After that it's been working fine for quite some time until after the upgrade we started getting those calls from random people. 

One thing I don't understand also is why updating template after the upgrade which has new snapvol.cfg not updating existing writables with the new config 

[Ray_handels]

Because the template is exactly that, a template. It is the disk that you build a new writable (or appstack for that matter) on. You can however change the snapvol.cfg file for all existing writable volumes by going to writables and go to update writables (I don't have the 2.x manager anymore so cannot check myself) and than upload a zip files that holds a new snapvol.cfg file in it's root. Make sure to test this functionality before going to production.

We also noticed that it did create issues with modern apps and engineering did look at it. It might well be that newer 2.x versions have fixed this issue, it is worth a try to ask GSS. 

That being said. The way Appvolumes 2.x works with thw snapvol.cfg is clunky to say the least. They did fix this in version 4 as it is now stored on the GI which is a lot easier to change for every user.

[LukaszDziwisz]

Thank you Ray. That makes sense and that's what I've been doing in the past. This time around I just started looking deeper into it because of the issues I'm describing and was for some reason under impression that updating template also updates snapvol.cfg for all users. 

We might need to start looking into AppVolumes4 earlier that I was expecting