Setting Up Desktop and Application Pools in View

Virtual SAN offers a storage policy framework so that you can control the behavior of various virtual
machine objects that reside on the Virtual SAN datastore. An example of an object in Virtual SAN is a
virtual disk (VMDK) file, and there are four characteristics of each object that are controlled through policy:
n
Stripes: Number of stripes of data. The number of disk stripes affects how many magnetic disks you
have (HDDs).
n
Resiliency: Number of failures to tolerate. The number of host failures to tolerate depends, of course,
on the number of hosts you have.
n
Storage Provisioning: Thick or Thin.
n
Cache Reservation: Read-cache reservation.
The stripes and cache reservation settings are used to control performance. The resiliency setting controls
availability. The storage provisioning setting control capacity. These settings, taken together, affect how
many vSphere hosts and magnetic disks are required.
For example, if you set the number of disk stripes per object to 2, Virtual SAN will stripe the object across at
least 2 HDDs. In conjunction with this setting, if you set the number of host failures to tolerate to 1, Virtual
SAN will create an additional copy for resiliency and therefore require 4 HDDs. Additionally, setting the
number of host failures to tolerate to 1 requires a minimum of 3 ESXi hosts, 2 for resiliency and the third to
break the tie in case of partitioning.
NOTE If you inadvertently attempt to use settings that contradict each other, when you attempt to apply the
settings, the operation will fail, and an error message will tell you, for example, that you do not have
enough hosts.
There is no requirement for any user action associated with these default policies. Policies are created for
both linked-clone desktop pools and full-clone desktop pools.
You can use either the vSphere Command-Line Interface (esxcli) or the vSphere Web Client to change the
default storage policy profiles. Each virtual machine maintains its policy regardless of its physical location
in the cluster. If the policy becomes noncompliant because of a host, disk, or network failure, or workload
changes, Virtual SAN reconfigures the data of the affected virtual machines and load-balances to meet the
policies of each virtual machine.
Using Virtual Volumes for Virtual-Machine-Centric Storage and Policy-Based
Management
With Virtual Volumes (VVols), available with vSphere 6.0 or a later release, an individual virtual machine,
not the datastore, becomes a unit of storage management. The storage hardware gains control over virtual
disk content, layout, and management.
With Virtual Volumes, abstract storage containers replace traditional storage volumes based on LUNs or
NFS shares. Virtual Volumes maps virtual disks and their derivatives, clones, snapshots, and replicas,
directly to objects, called virtual volumes, on a storage system. This mapping allows vSphere to offload
intensive storage operations such as snapshoting, cloning, and replication to the storage system. The result,
for example, is that a cloning operation that previously took an hour might now take just a few minutes
using Virtual Volumes.
IMPORTANT Although one of the key benefits of Virtual Volumes is the ability to use Software Policy-Based
Management (SPBM), for this release of View, no default granular storage policies are created by View, as
they are when you use the Virtual SAN feature. Instead, you can set a global default storage policy in
vCenter Server that will apply to all Virtual Volume datastores.
Virtual Volumes has the following benefits:
n
Virtual Volumes supports offloading a number of operations to storage hardware. These operations
include snapshotting, cloning, and Storage DRS.
Chapter 15 Reducing and Managing Storage Requirements
VMware, Inc. 201