5.2

For example, it would make sense to set an aggressive overcommit level for a floating-assignment desktop
pool in which the desktops are set to delete or refresh after logoff.
You
can vary storage overcommit levels among different types of datastores to address the different levels of
throughput in each datastore. For example, a NAS datastore can have a different setting than a SAN datastore.
Storing Linked-Clone Desktops on Local Datastores
Linked-clone desktops can be stored on local datastores, which are internal spare disks on ESXi hosts. Local
storage offers advantages such as inexpensive hardware, fast virtual-machine provisioning, high performance
power operations, and simple management. However, using local storage limits the vSphere infrastructure
configuration options that are available to you. Using local storage is beneficial in certain View environments
but not appropriate in others.
Using local datastores is most likely to work well if the View desktops in your environment are stateless. For
example, you might use local datastores if you deploy stateless kiosks or classroom and training stations.
Consider using local datastores if your desktops have floating assignments, are not dedicated to individual
end users, do not require persistent disks for user data, and can be deleted or refreshed at regular intervals
such as on user logoff. This approach lets you control the disk usage on each local datastore without having
to move or load-balance the virtual machines across datastores.
However, you must consider the restrictions that using local datastores imposes on your View desktop
deployment:
n
You cannot use VMotion to manage volumes.
n
You cannot load-balance virtual machines across a resource pool. For example, you cannot use the View
Composer rebalance operation with linked-clones that are stored on local datastores.
n
You cannot use VMware High Availability.
n
You cannot use the vSphere Distributed Resource Scheduler (DRS).
n
You cannot store a View Composer replica and linked clones on separate datastores if the replica is on a
local datastore.
When you store linked clones on local datastores, VMware strongly recommends that you store the replica
on the same volume as the linked clones. Although it is possible to store linked clones on local datastores
and the replica on a shared datastore if all ESXi hosts in the cluster can access the replica, VMware does
not recommend this configuration.
n
If you select local spinning-disk drives, performance might not match that of a commercially available
storage array. Local spinning-disk drives and a storage array might have similar capacity, but local
spinning-disk drives do not have the same throughput as a storage array. Throughput increases as the
number of spindles grows.
If you select direct attached solid-state disks (SSDs), performance is likely to exceed that of many storage arrays.
You can store linked clones on a local datastore without constraints if you configure the desktop pool on a
single ESXi host or a cluster that contains a single ESXi host. However, using a single ESXi host limits the size
of the desktop pool that you can configure.
To configure a large desktop pool, you must select a cluster that contains multiple ESXi hosts with the collective
capacity to support a large number of virtual machines.
If you intend to take advantage of the benefits of local storage, you must carefully consider the consequences
of not having VMotion, HA, DRS, and other features available. If you manage local disk usage by controlling
the number and disk growth of the virtual machines, if you use floating assignments and perform regular
refresh and delete operations, you can successfully deploy linked clones to local datastores.
VMware Horizon View Administration
112 VMware, Inc.