Last week, I was rolling out Horizon View v7.1 on my new vSAN 6.6.1 all-flash configuration in the lab. Now, one of the pet peeves a few of us have had with this configuration was that a warning was always reported around read cache reservations on all-flash vSAN. Of course, read cache is irrelevant to all-flash (AF) configurations as it does not use a read cache; this is only applicable to hybrid vSAN configurations. This is why it was such as annoyance.
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…
While running through a bunch of interoperability tests for VSAN, one of the products I deployed was VMware View 5.3.1. This required a bunch of virtual machines to be rolled out; one VM for my SQL Server database to support View Composer, another for View Composer itself and then finally another VM for View Connection Server (also known as the connection broker). It was during the install of View Connection server that I hit this issue: Error 1720: There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact…
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.