How to Use App Volumes and vSAN Storage Policies for Efficient Application Delivery and Management

Current Architecture / Operational model

App Volumes and vSAN based Storage are often used together in Virtual Desktop environments.

vSAN policies ensure proper storage provisioning and management for VMs, while App Volumes streamline application delivery and management within virtual desktop infrastructures.

vSAN implements a policy-based approach to storage management. Virtual machine storage requirements, such as performance and availability, can be defined in a Virtual Machine storage policy.

The storage policies determine how the virtual machine storage objects are provisioned and allocated within the datastore to guarantee the required level of service.

It requires that the virtual machines deployed on the vSAN datastores are assigned at least one storage policy. If you do not explicitly assign a storage policy to the virtual machine, the Datastore Default Storage Policy is assigned to the virtual machine.

When working with App Volumes packages or Writable Volumes no Storage Policy can be selected by uploading the vmdk files. So the Datastore Default Policy will be applied.

If the storage policy is changed, such as enabling Force provisioning in a case in a customer's managed service, the changes will only be applied to VMDKs attached to virtual machines. Standalone vmdks such as packages and writables won't be changed, resulting in inconsistency and availability risks.

Example for a change of a vSAN VM Storage Policy

 In the worst case, this could result in packages not being attached to virtual desktops if multiple hosts fail, or if force provisioning is enabled, only vmdks would be attached.

What to do in case of a desired Storage Policy change
Therefore, if you change the storage policy relevant to the packages or writables, attach these vmdks to VMs, change the storage policy to a different one and revert back to the original one. Otherwise the changed values won't be applied. This is a nasty problem because the vCenter UI always shows Datastore Default for App Volumes packages, but in reality the applied storage is in an old Datastore Default state.

 All in all there is a potential for improvement when handling with standalone vmdk based objects in vSAN environments when changing Storage Policies.