4.6

Table 5-12. Storage Overcommit Levels (Continued)
Option Storage Overcommit Level
Moderate 7 times the size of the datastore.
Aggressive 15 times the size of the datastore.
Storage overcommit levels provide a high-level guide for determining storage capacity. To determine the best
level, monitor the growth of linked clones in your environment.
Set an aggressive level if your OS disks will never grow to their maximum possible size. An aggressive
overcommit level demands attention. To make sure that the linked clones do not run out of disk space, you
can periodically refresh or rebalance the desktop pool and reduce the linked clones' OS data to its original size.
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 View Composer Replicas and Linked Clones on Separate Datastores
You can place View Composer replicas and linked clones on separate datastores with different performance
characteristics. This flexible configuration can speed up intensive operations such as provisioning many linked
clones at once or running antivirus scans.
For example, you can store the replica virtual machines on a solid-state disk-backed datastore. Solid-state disks
have low storage capacity and high read performance, typically supporting 20,000 I/Os per second (IOPS).
View Composer creates only one replica for each View Composer base-image snapshot on each ESX cluster,
so replicas do not require much storage space. A solid-state disk can improve the speed at which ESX reads a
replica's OS disk when a task is performed concurrently on many linked clones.
You can store linked clones on traditional, spinning media-backed datastores. These disks provide lower
performance, typically supporting 200 IOPS. They are cheap and provide high storage capacity, which makes
them suited for storing the many linked clones in a large pool. ESX does not need to perform intensive,
simultaneous read operations on a linked clone.
Configuring replicas and linked clones in this way can reduce the impact of I/O storms that occur when many
linked clones are created at once. For example, if you deploy a floating-assignment pool with a delete-desktop-
on-logoff policy, and your users start work at the same time, View Manager must concurrently provision new
desktops for them.
IMPORTANT This feature is designed for specific storage configurations provided by vendors who offer high-
performance disk solutions. Do not store replicas on a separate datastore if your storage hardware does not
support high-read performance.
You must follow certain requirements when you store the replica and linked clones in a pool on separate
datastores:
n
You can specify only one separate replica datastore for a pool.
n
If a replica datastore is shared, it must be accessible from all ESX hosts in the cluster.
n
If the linked-clone datastores are shared, the replica datastore must be shared. Replicas can reside on a
local datastore only if you configure all linked clones on local datastores on the same ESX host.
This feature is supported in vSphere mode only. The linked clones must be deployed on hosts or clusters
running ESX 4 or later.
Chapter 5 Creating Desktop Pools
VMware, Inc. 93