Horizon View 7 on VSAN – Policies Revisited

It has been some time since I last looked at Horizon View on Virtual SAN. The last time was when we first released VSAN, back in the 5.5 days. This was with Horizon View 5.3.1, which was the first release that inter-operated with Virtual SAN. At the time, there was some funkiness with policies. View could only use the default policy at the time, and the default policy used to show up as “none” in the UI. The other issue is that you could not change the default policy via the UI, only through CLI commands. Thankfully, things have come a long way since then. In this post, I will look at how Horizon View 7 inter-operates with Virtual SAN 6.2, concentrating mostly on policies. However, Horizon View 7 also has new vmFork/Instant Clone technology and AppVolumes, and I hope to be able to do some posts on those features running on top of VSAN going forward.

Desktop Pools

Let’s start with the creation of pools. I’m not going to cover the deployment of the View building blocks, such as manager and/or connection server. There are plenty of docs and blogs out there describing those. Instead, we’ll cut straight to the creation of some Desktop pools. In my setup, I create two pools:

6. pools

Both pools have been configured to use a VSAN datastore. Both are also “Automated Desktop Pools”, but the composer-pool-01 pool has a “dedicated” user assignment and is based on View Composer Linked Clones. The instant-pool-02 has a “floating” user assignment and is based on the new Instant clones (using vmFork) technology. Both Linked clones and Instant clones share the same base image, and they use less storage space than full virtual machines. If you want to know more about why Instant clones are faster than Linked clones, this blog post has a pretty good explanation. It basically boils down to reducing the number of steps to deploy a desktop. The number of steps can be reduced for Instant Clones because vmFork uses rapid in-memory cloning of a running parent virtual machine, and copy-on-write to rapidly deploy the virtual machines. Note that instant clones do no need View Composer; they can be deployed without this component.

Linked Clone Policies

I went ahead and deployed some desktops using the composer pool (linked clones). I then examined the objects associated with this desktop on the VSAN datastore. It looked something like this:

5. linked clone

Here we can see the VM Home Namespace, and four VMDKs. This is typical for a linked clone desktop. There are 3 disks with an OS DISK policy and a single disk with a PERSISTENT DISK policy (We will look at the policies in a moment). The three OS disks are (1) the boot disk containing the Guest OS, labeled checkpoint, (2) the internal disk which holds AD and sysprep info, and (3) the system disposable disk (SDD) which holds the Windows page-file and temp files. The disk with the PERSISTENT DISK policy is the user data disk or persistent disk which holds Windows profiles so that they are not affected by View Composer operations such as refresh and recompose. Now the persistent and disposable disks are only created if you choose that option when creating the policy, as shown below:


Instant Clone Policies

I also went ahead and deployed a pool of desktops using the instant clones. This is what the layout of that VM looked like when I examined the policies associated with its objects when it was deployed on VSAN:

4. instant clone

This time there is only a single VMDK, and it has its own unique policy called OS_DISK_FLOATING (as I selected floating user assignment). Now this is the thing with instant Clones; they are not deployed using composer. So you do not see the additional VMDKs (persistent, disposable) that we see with linked clone desktops above. However there are ways to provide persistent through AppVolumes, which I will try to cover in another post.

For the moment, let’s check out these policies in more details.

View Auto Policies

At this point, there are desktops from two different pools deployed; linked clones and instant clones. Each of the objects that make up the desktop on the VSAN datastore has its own policy. These policies are automatically created by View; there is no administrative steps to create these policies. If we now look at the policies on vCenter Server, we can see all of the policies.

3. view auto-created policies

I went through all of the above policies, and each of them had a stripe width of 1 and failures to tolerate of 1. The majority also had read cache reservation set to 0, and no object space reservation. However there were two exceptions:

Persistent Disk – Object Space Reservation = 100%

The persistent disk has an object space reservation value set to 100%. All objects deployed on VSAN are thin, in other words object space reservation is set to 0%. In this case, we are reserving all of the space for the persistent disk in advance. This is what the policy looks like:

1. persistent-disk-osr=100

Replica Disk – Flash Read Cache Reservation = 10%

We did not discuss the replica disk yet. This is essentially the base image of the desktops, and is what is cloned from the virtual machine + snapshot image that you need to select when creating a pool. To provide some additional performance to the replica, it is allocated a part of the read cache (on hybrid systems only). This 10% is 10% of the size of the replica disk/VMDK. This is what the policy looks like:

2. replic - read cache=10

Now, I have not looked at full clone desktops here, and there are probably some other variations that can give rise to other policies too. The point here is that it is fully integrated, and there is no need for an administrator to do anything with these policies.

Information about All-Flash and View

As you’ve seen above, the replica disk uses a policy that has a read cache reservation of 10%. However on all-flash VSAN configurations, there is no read cache, so you may run into the issue outlined in this KB – essentially disable provisioning on the pool, set read cache reservation to 0, then enable provisioning once more. This may now be addressed, as I had no such issues with deploying View 7 on VSAN 6.2, even though the policy is still the same. [Update] This is not addressed yet – you will see an error in the health check for read cache reservations, even though this is an all-flash cluster. You will still have to implement the above KB workaround to prevent errors like this in the health check:

read cache reservation error

Information about VSAN Stretched Cluster and View

I asked one of our View gurus about this, and the statement was that Horizon 7 on VSAN Stretched cluster is supported as long as you pin the View Managers to one site with affinity rules. In other words, you cannot have the View Managers running in a redundant configuration on both sites. This means that HA will need to start-up the VMs on the other site in the event of a full site failure.

The View team are currently testing this at the moment, and hopefully there will be a reference architecture document on this in the near future.

Information about View Storage Accelerator/CBRC

There are no changes to View Storage Accelerator (aka Content Based Read Cache – CBRC). The relevant digest files (descriptor file and actual digest) continue to be stored in the VM Home Namespace. There is no object instantiated specifically for the digest. To show what I mean, here is a listing of the VM Home of a desktop based on a linked clone. I removed some of the columns, and what you can see below are size, creation date and filename. Note that there are digests associated with some disks and not others. The disk which have digest is the OS disk. You can also see the internal, checkpoint, disposable and user disk descriptions in this listing.

16781312 Apr  6 08:21 link-clon-1-checkpoint-digest-delta.vmdk
     363 Apr  6 08:21 link-clon-1-checkpoint-digest.vmdk
     421 Apr  6 08:21 link-clon-1-checkpoint.vmdk
33558528 Apr  6 08:21 link-clon-1-digest-delta.vmdk
     475 Apr  6 08:17 link-clon-1-digest.vmdk
     519 Apr  6 08:21 link-clon-1-vdm-disposable-4cadb756-944c-4aaa-adec-36f167da073c.vmdk
     519 Apr  6 08:21 link-clon-1-vdm-user-disk-D-4cadb756-944c-4aaa-adec-36f167da073c.vmdk
    8684 Apr  6 08:21 link-clon-1.nvram
     557 Apr  6 08:21 link-clon-1.vmdk
     292 Apr  6 08:21 link-clon-1.vmsd
    4996 Apr  6 08:21 link-clon-1.vmx
     515 Apr  6 08:21 link-clon-11-internal.vmdk
     560 Apr  6 08:16 sdd
  393166 Apr  6 08:21 vmware.log


I’m sure many of you are already aware, but if you have a Horizon Enterprise or Advanced, you are also entitled to VMware Virtual SAN Advanced. More details here. VSAN is an awesome platform for Horizon View, with some seamless integration through policies, as shown above.

One Reply to “Horizon View 7 on VSAN – Policies Revisited”

Comments are closed.