Setting Up Desktop and Application Pools in View

If you select a new datastore but keep the desktop pool the same size, or reduce the number of linked clones,
the sizing guidelines show as 0. The values of 0 reflect that no new clones must be created on the selected
datastore. Space requirements for the existing clones are already accounted for.
How View Calculates the Minimum Sizing Recommendations
To arrive at a minimum recommendation for OS disks, View estimates that each clone consumes twice its
memory size when it is first created and started up. If no memory is reserved for a clone, an ESXi swap file
is created for a clone as soon as it is powered on. The size of the guest operating system's paging file also
affects the growth of a clone's OS disk.
In the minimum recommendation for OS disks, View also includes space for two replicas on each datastore.
View Composer creates one replica when a pool is created. When the pool is recomposed for the first time,
View Composer creates a second replica on the datastore, anchors the linked clones to the new replica, and
deletes the first replica if no other clones are using original snapshot. The datastore must have the capacity
to store two replicas during the recompose operation.
By default, replicas use vSphere thin provisioning, but to keep the guidelines simple, View accounts for two
replicas that use the same space as the parent virtual machine.
To arrive at a minimum recommendation for persistent disks, View calculates 20% of the disk size that you
specify on the View Composer Disks page of the Add Desktop Pool wizard.
NOTE The calculations for persistent disks are based on static threshold values, in gigabytes. For example, if
you specify a persistent disk size of any value between 1024MB and 2047MB, View calculates the persistent
disk size as 1GB. If you specify a disk size of 2048MB, View calculates the disk size as 2GB.
To arrive at a recommendation for storing replicas on a separate datastore, View allows space for two
replicas on the datastore. The same value is calculated for minimum and maximum usage.
For details, see “Sizing Formulas for Linked-Clone Pools,” on page 205.
Sizing Guidelines and Storage Overcommit
After you estimate storage requirements, select datastores, and deploy the pool, View provisions linked-
clone virtual machines on different datastores based on the free space and the existing clones on each
datastore.
Based on the storage-overcommit option that you select on the Select Linked Clone Datastores page in the
Add Desktop Pool wizard, View stops provisioning new clones and reserves free space for the existing
clones. This behavior ensures that a growth buffer exists for each machine in the datastore.
If you select an aggressive storage-overcommit level, the estimated storage requirements might exceed the
capacity shown in the Selected Free Space column. The storage-overcommit level affects how many virtual
machines that View actually creates on a datastore.
For details, see “Set the Storage Overcommit Level for Linked-Clone Virtual Machines,” on page 208.
Sizing Formulas for Linked-Clone Pools
Storage-sizing formulas can help you estimate the size of linked-clone disks relative to the free space on the
datastores that you select for OS disks, View Composer persistent disks, and replicas.
Storage Sizing Formulas
Table 15-2 shows the formulas that calculate the estimated sizes of linked-clone disks when you create a
pool and as the linked-clone machines grow over time. These formulas include the space for replica disks
that are stored with the clones on the datastore.
Chapter 15 Reducing and Managing Storage Requirements
VMware, Inc. 205