VMware App Volumes – Volumes were not mounted due to an issue with your Writable Volume

Random floating desktop pools within our environment would exhibit issues where in the end-user would login to their desktop and they will be presented with a black screen with the message – Volumes were not mounted due to an issue with your Writable Volume. Please try logging in again, or contact your administrator.

When this issue would surface, neither the AppStacks nor Writable Volumes would mount to the end-user desktop and if the end-user clicked on OK the session would log-off.

Environment Details

VMware Horizon 7.11
VMware App Volumes 2.18.5
VMware Dynamic Environment Manager 9.10
Windows 10 1909 Enterprise

Process of elimination

• The App Volumes (AV) agent is able to communicate to the AV Manager on port 443 without any issues.
• There were no SSL errors or load balancing issues communicating with the Agent/Manager.
• We thought a particular Writable Volumes (WV) would be causing the issue. Deleted and re-created the WV still the issue would persist.
• The issue would happen randomly for few users again and again.

Resolution

My team managed to open a VMware GSS case handled by Sanjay SP (A very helpful support engineer), he mentioned there were quite a few cases opened on a similar pattern. Following were the assessments from our logs:

• During the first startup of Instant Clones, App Volumes Agent queries below registry key to know the customization status and updates manager with the same
  • [HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\ViewComposer\ga\AgentIntegration]
    • “CustomizationState”=dword:1
• It has a timeout of 300 seconds, and if this task times out AppVolumes manager will fail to create a unique identity for the VM in its database
• In the App Volumes Agent logs, we see the respective timeout
  • [2021-03-09 07:11:34.009 UTC] [svservice:P1564:T1976] HandleNGVC: Waiting for NGVC to complete (count 299)
  • [2021-03-09 07:11:34.009 UTC] [svservice:P1564:T1976] Timed out waiting on NGVC after 300 seconds, disabling
• The customization itself is working fine and we do see the registry entries getting updated with appropriate values. However, its not completed within 300 seconds. 

Fix

• The delay in cloneprep customization was not found with IPv6 disabled on the primary nic adapter. The recommendation was to disable IPv6 since we don’t use it within the NIC adapter properties.

I hope you will find this information useful if you encounter the issue. If you manage to tweak or improvise further on this solution, please don’t forget to keep me posted.

Thanks,
Aresh Sarkari