It should come as no surprise but VMware Horizon View is also supported on VSAN. VMware released Horizon View version 5.3.1 to coincide with the vSphere 5.5.U1 and VSAN release. This release allows desktops to be successfully deployed on a VSAN datastore, using default policies for the desktop storage objects. Let’s go through the steps to get this configured and running, and then we can talk about the default policy settings afterwards.
Deployment is pretty much identical to previous versions of VMware View. There are no significant differences. You create your desktop pools just like before. You still select a virtual machine and snapshot combination which would form the ‘replica’ that becomes the basis for your linked clone desktops. However, per the View on VSAN guidelines, this virtual machine and snapshot should use the default VM Storage Policy (in other words, no policy should be selected when the VM is created on a VSAN datastore). Therefore when you examine the replica object’s VM Storage Policy, it should look like the following:
The only other different step that’s required is to select the VSAN datastore as your destination (this is during the creation of a persistent linked clone pool):
And if we take a closer look at these hard disks, we will also see that they are all using the default VM Storage Policy which includes a Number of Failures To Tolerate set to 1:
Now, there is a way to change the default policy of VSAN if you so wish. This is only achievable through the esxcli command line however. VMware KB article 2073795 talks about how to do that. Remember though that this changes the default for every VM deployed on VSAN, not just Horizon View replicas and desktops, so caution should be exercised. It will also apply to every VM storage object and disk. To elaborate, if you decide to add 10% of flash read cache to the default policy, every single object rolled out onto the VSAN datastore will get a 10% cache reservation. This include disk objects which would get no benefit from read cache, such as the internal disk. You also risk consuming all of your read cache. The recommendation from VMware is to stick with the default policy, and allow all storage objects to share the read cache equally; those who need it will consume it, those who don’t need will not.
Just to close, there are a few things to keep in mind regarding View and VSAN:
- View Storage Accelerator/CBRC works just fine with VSAN.
- There is no longer a need for replica tiering with VSAN. This was a feature which placed replicas on a separate datastore backed by flash devices or SSD drives. This means that read I/O operations are directly served from the flash/SSD layer. VSAN negates the need for such a configuration since all I/O (if the system is properly sized) is serviced by the flash layer.
- There is no support in this initial release for SE Sparse Disks. Linked clone pools use the original vmfsSparse format.
- Full clones are supported as well as linked clones (although I don’t specifically call it out in the post)