When you create or edit an instant-clone or linked-clone desktop pool, the Select Linked (or Instant) Clone Datastores page displays a table that provides storage-sizing guidelines. The table can help you to decide which datastores to select for the linked-clone disks. The guidelines calculate space needed for new linked clones.

Sizing Table for OS Disks and Persistent Disks

1 shows an example of storage-sizing recommendations that might be displayed for a pool of 10 virtual machines if the parent virtual machine has 1GB of memory and a 10GB replica. In this example, different datastores are selected for OS disks and View Composer persistent disks.


The persistent disk information is for View Composer linked clones only. Instant clones do not support persistent disks.

Table 1. Example Sizing Table for OS and Persistent Disks

Data Type

Selected Free Space (GB)

Min Recommended (GB)

50% Utilization (GB)

Max Recommended (GB)

OS disks





Persistent disks





The Selected Free Space column shows the total available space on all of the datastores that you selected for a disk type such as OS disks.

The Min Recommended column shows the minimum amount of recommended storage for a pool.

The 50% Utilization column shows the recommended storage when the disks grow to 50% of the parent virtual machine.

The Max Recommended column shows the recommended storage when the disks approach the full size of the parent virtual machine.

If you store OS disks and persistent disks on the same datastore, View calculates the storage requirements of both disk types. The Data Type is shown as Linked clones or Instant clones instead of a particular disk type.

If you store View Composer replicas on a separate datastore, the table also shows storage recommendations for the replicas and adjusts the recommendations for OS disks.

Sizing Guidelines for View Composer Linked Clones

The table provides general guidelines. Your storage calculations must account for additional factors that can affect actual storage growth in the clones.

For OS disks, your sizing estimates depend on how frequently you refresh and recompose the pool.

If you refresh your linked-clone pool between once a day and once a week, make sure that the Selected Free Space can accommodate storage use between the Min Recommended and 50% Utilization estimates.

If you rarely refresh or recompose the pool, the linked-clone disks continue to grow. Make sure that the Selected Free Space can accommodate storage use between the 50 % Utilization and Max Recommended estimates.

For persistent disks, your sizing estimates depend on the amount of Windows profile data that users generate on their desktops. Refresh and recompose operations do not affect persistent disks.

Sizing Guidelines When You Edit an Existing Desktop Pool

View estimates the storage space that is needed for new clones. When you create a desktop pool, the sizing guidelines encompass the entire pool. When you edit an existing desktop pool, the guidelines encompass only the new clones that you add to the pool.

For example, if you add 100 clones to a desktop pool and select a new datastore, View estimates space requirements for the 100 new clones.

If you select a new datastore but keep the desktop pool the same size, or reduce the number of 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 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.


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 Instant-Clone and Linked-Clone Pools.

Sizing Guidelines and Storage Overcommit for View Composer Linked Clones


Instant clones do not support 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.