Home > Blogs > VMware End-User Computing Blog

Horizon 6.0 – Introducing Virtual SAN Integration

By Narasimha Krishnakumar, Director, Product Management, End-User Computing, VMware

On behalf of everyone on the End-User Computing (EUC) team at VMware, I’m proud to bring you another exciting product announcement from EUC.

View 5.3.1 was introduced early in the first quarter of 2014 to support Virtual SAN 5.5 GA. As you may have read recently, VMware announced the release of Horizon 6 (with View). With this release, we are continuing to expand the Virtual SAN integration capabilities delivered by Horizon. The Virtual SAN integration capabilities introduced in Horizon 6 deliver the following benefits to our customers:

  • Reduces CAPEX cost of storage by up to 50% when compared to the cost of using an external shared storage array based on magnetic disks
  • A package that contains both View and Virtual SAN
  • A simple three-step setup and management workflow
  • Performance capabilities similar to that of an all flash/all SSD external storage system

Using Horizon 6 with Virtual SAN 5.5

Using Horizon 6 with Virtual SAN 5.5 is a simple three-step process:

1. Using the vSphere web client interface set up a cluster of vSphere 5.5U1 nodes (minimum of three), with at least one SSD and one hard disk in each of the nodes. It is best to use the same number of drives on each ESXi node and keep the environment homogeneous.

2. Enable Virtual SAN using the vSphere Web Client interface, as shown in Figure 1. Select the check box labeled Turn ON Virtual SAN.


Figure 1: vSphere Web Client Interface Showing Cluster Settings

3. Create a View desktop pool using the standard workflow. Select the Use VMware Virtual SAN option, as shown in Figure 2. After this option is selected, the next steps of the workflow allow the users to select the Virtual SAN datastore and continue with the rest of the pool creation process.


Figure 2: Use a Virtual SAN Datastore

Horizon 6 Integration with Virtual SAN Policies

Horizon 6 integrates deeply with Virtual SAN 5.5 by automating the association of storage policies based on the desktop pool type chosen at pool creation time. Virtual SAN uses a policy-based framework for managing storage objects. The policy consists of four elements:

  • Stripes – Number of stripes of data
  • Resiliency – Number of ESXi host failures to tolerate
  • Storage Provisioning – Thick or thin provisioning
  • Cache Reservation – Read cache reservation

Horizon 6 automates the association of policies based on the desktop pool type. For Linked Clone desktop pools the following policy is applied:

For OS disk:

  • Failure to tolerate = 1 for dedicated pool, 0 for floating pool
  • Provisioning: thin

For replica disk:

  • Failure to tolerate = 1
  • Cache reservation = 10%
  • Provisioning: thin

It is important to note that the cache reservation is set to 10% only for the replica disk to insure that highest performance levels are achieved during any read-intensive IO operations on the ESXi host.

For full-clone desktop pools the following policy is applied:

  • Failure to tolerate = 1 for persistent, 0 for nonpersistent
  • Provisioning: 100% reserved (thick)

Figure 3 shows an example of the virtual machine storage policies that are automatically created by View. All the policies can be explored by double-clicking the individual policy in the vSphere Web Client Interface.


Figure 3: vSphere Web Client Showing Horizon Auto-Created Policies

After these three steps are performed, Horizon 6 starts using the Virtual SAN datastore to store the VMDKs of the virtual desktops by associating the storage policies based on the pool type. Horizon 6 with Virtual SAN integration then delivers an ultra-low desktop TCO and great end-user experience.

5 thoughts on “Horizon 6.0 – Introducing Virtual SAN Integration

    1. Narasimha Krishnakumar

      The storage capacity is determined by a combination of factors. First the SSD capacity – It is recommended to have at least 10% of SSD capacity relative to the size of magnetic disks that you are using. For example, if you have a total of 4TB on a server, it is best to have at least 400GB of SSD. The HDD/Magnetic disk capacity is determined by the size of the VM, whether it is a full clone or a linked clone and the number of host failures you want to tolerate. With Full clones, the number of host failures to tolerate is automatically set to 1 which means that you will need storage space for another copy of the VM data. For example if you have a 100 VM pool with a size of 10GB per full clone, you will need 10*100*2 = 2TB with a single host failure resiliency characteristic. For linked clones, the number of host failures is set to 1 for the replica disk and 0 for the clone disks. Using a similar example of 100 VMs with 10GB each, you will require 100*10 + 10 = 1010GB of magnetic disk space.

      There will be detailed guidance in terms of sizing in the following weeks. Hope this has been helpful.


  1. Pool Builder Brisbane,Pool Builders Brisbane

    You really help it become seem not that hard with all your speech nevertheless i to get this trouble to become really an element that I feel I would certainly not comprehend. It sort of feels way too intricate and really huge to me. I’m having a look in advance on your own upcoming submit, Let me attempt to get the dangle than me!

  2. Pingback: The Scoop – April Edition | vmnick

Comments are closed.