This question has come up a number of times in the past. However, there have been some updates that I personally was not aware of until last week. To cut to the chase, Horizon View 7 (all clone types) is supported with vSAN stretch cluster. This is good news. However, it is very important that customers should follow the Horizon View Reference Architecture (RA) design document and test the scalability of Horizon 7 and vSAN Stretched Clusters in their environment.
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.
Last week I wrote a post on Horizon View 7 on VSAN. That was all about showing the policies that were associated with the different desktops that can be deployed. I did mention that while one could use vmFork/Instant Clones for desktops, they did not include any sort of persistence. I did add a caveat to say that you could provide persistent storage to these desktops using App Volumes. In this post, I wanted to give some details on App Volumes, and the different moving components one will need if they want to deploy View desktops with App Volumes. However,…
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…
I had a query recently from a partner who was deploying VMware Horizon View 6.1 on top of an all-flash VSAN 6.0. They had done all the due diligence with configuring the AF-VSAN appropriately, marking certain flash devices as capacity devices, and so on. The configuration looked something like this: The they went ahead and deployed Horizon View 6.1, which they had done many times before on hybrid configurations. They were able to successfully deploy full clone pools on the AF-VSAN, but hit a strange issue when deploying linked clone pools (floating/dedicated). The clone virtual machine operation would fail with…
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.