Because View Composer creates desktop images that share virtual disks with a base image, you can reduce the required storage capacity by 50 to 90 percent.

View Composer uses a base image, or parent virtual machine, and creates a pool of up to 2,000 linked-clone virtual machines. Each linked clone acts like an independent desktop, with a unique host name and IP address, yet the linked clone requires significantly less storage.

Replica and Linked Clones on the Same Datastore

When you create a linked-clone desktop pool, a full clone is first made from the parent virtual machine. The full clone, or replica, and the clones linked to it can be placed on the same data store, or LUN (logical unit number). If necessary, you can use the rebalance feature to move the replica and linked clones from one LUN to another or to move linked clones to a Virtual SAN datastore or from a Virtual SAN datastore to a LUN.

Replica and Linked Clones on Different Datastores

Alternatively, you can place View Composer replicas and linked clones on separate datastores with different performance characteristics. For example, you can store the replica virtual machines on a solid-state drive (SSD). Solid-state drives have low storage capacity and high read performance, typically supporting tens of thousands of I/Os per second (IOPS). You can store linked clones on traditional, spinning media-backed datastores. These disks provide lower performance, but are less expensive and provide higher storage capacity, which makes them suited for storing the many linked clones in a large pool. Tiered storage configurations can be used to cost-effectively handle intensive I/O scenarios such as simultaneous rebooting of many virtual machines or running scheduled antivirus scans.

For more information, see the best-practices guide called Storage Considerations for VMware  View.

If you use Virtual SAN datastores, you cannot manually select different datastores for replicas and linked clones. Because Virtual SAN automatically places objects on the appropriate type of disk and caches of all I/O operations, there is no need to use replica tiering for Virtual SAN datastores.

Disposable Disks for Paging and Temp Files

When you create a linked-clone pool, you can also optionally configure a separate, disposable virtual disk to store the guest operating system's paging and temp files that are generated during user sessions. When the virtual machine is powered off, the disposable disk is deleted. Using disposable disks can save storage space by slowing the growth of linked clones and reducing the space used by powered off virtual machines.

Persistent Disks for Dedicated Desktops

When you create dedicated-assignment desktop pools, View Composer can also optionally create a separate persistent virtual disk for each virtual desktop. The end user's Windows profile and application data are saved on the persistent disk. When a linked clone is refreshed, recomposed, or rebalanced, the contents of the persistent virtual disk are preserved. VMware recommends that you keep View Composer persistent disks on a separate datastore. You can then back up the whole LUN that holds persistent disks.

Virtual SAN Datastores That Aggregate Local Storage Disks from a vSphere Cluster

Virtual SAN virtualizes the local physical storage disks available on ESXi hosts into a single datastore shared by all hosts in a vSphere cluster. A Virtual SAN datastore consists of solid-state drive (SSD) disks and hard disk drives (HDDs), also called data disks. SSD disks are used for read caching and write buffering. Data disks are used for persistent storage. This strategy provides high-performance storage with automatic caching, so that you specify only one datastore when creating a desktop pool, and the various components, such as virtual machine files, replicas, user data, and operating system files, are placed on the appropriate SSD or data disks.


The Virtual SAN feature requires vSphere 5.5 Update 1 or a later release, and requires the appropriate hardware. See the VMware Compatibility Guide.

When you use Virtual SAN, View defines virtual machine storage requirements, such as capacity, performance, and availability, in the form of default storage policy profiles, which you can modify. Virtual SAN lays out the virtual disk across the logical datastore to meet the specified requirements. Virtual SAN also monitors and reports on the policy compliance during the life cycle of the virtual machine. If the policy becomes noncompliant because of a host, disk, or network failure, or workload changes, Virtual SAN reconfigures the data of the affected virtual machines and optimizes the use of resources across the cluster.


When you create a linked-clone desktop pool, a full clone is first made from the parent virtual machine. From this full clone, or replica, linked clones are created. If you use a Virtual SAN datastore, by default an extra copy of the replica and linked clones are created according to the availability policy.

Local Datastores for Floating, Stateless Desktops

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 environments but not appropriate in others.


The limitations described in this section do not apply to Virtual SAN datastores, which also use local storage disks but require specific hardware, as described in the preceding section about Virtual SAN.

Using local datastores is most likely to work well if the remote desktops in your environment are stateless. For example, you might use local datastores if you deploy stateless kiosks or classroom and training stations.

If you intend to take advantage of the benefits of local storage, you must carefully consider the following limitations:

  • You cannot use VMotion, VMware High Availability (HA), or vSphere Distributed Resource Scheduler (DRS).

  • You cannot use the View Composer rebalance operation to load-balance virtual machines across a resource pool.

  • You cannot store a View Composer replica and linked clones on separate datastores, and, in fact, VMware recommends storing them on the same volume.

If you manage local disk usage by controlling the number of virtual machines and their disk growth, and if you use floating assignments and perform regular refresh and delete operations, you can successfully deploy linked clones to local datastores.

For more information, see the chapter about creating desktop pools in the ViewAdministration document.