4.5

Storage Overcommit for Linked-Clone Desktops
With
the storage overcommit feature, you can reduce storage costs by placing more linked-clone desktops on
a datastore than is possible with full virtual-machine desktops. The linked clones can use a logical storage
space several times greater than the physical capacity of the datastore.
This feature helps you choose a storage level that lets you overcommit the datastore's capacity and sets a limit
on the number of linked clones that View Manager creates. You can avoid either wasting storage by
provisioning too conservatively or risking that the linked clones will run out of disk space and cause their
desktop applications to fail.
For example, you can create at most ten full virtual machines on a 100GB datastore, if each virtual machine is
10GB. When you create linked clones from a 10GB parent virtual machine, each clone is a fraction of that size.
If you set a conservative overcommit level, View Manager allows the clones to use four times the physical size
of the datastore, measuring each clone as if it were the size of the parent virtual machine. On a 100GB datastore,
with a 10GB parent, View Manager provisions approximately 40 linked clones. View Manager does not
provision more clones, even if the datastore has free space. This limit keeps a growth buffer for the existing
clones.
Table 5-12 shows the storage overcommit levels you can set.
Table 5-12. Storage Overcommit Levels
Option
Storage Overcommit Level
None Storage is not overcommitted.
Conservative 4 times the size of the datastore. This is the default 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.
VMware View Administrator's Guide
90 VMware, Inc.