The instant clones feature leverages vSphere vmFork technology (available with vSphere 6.0 U1 and later) to quiesce a running base image, or parent virtual machine, and rapidly create and customize a pool of virtual desktops.

Not only do instant clones share the virtual disks with the parent virtual machine at the time of creation, instant clones also share the memory of the parent. Each instant clone acts like an independent desktop, with a unique host name and IP address, yet the instant clone requires significantly less storage. Instant clones reduce the required storage capacity by 50 to 90 percent. The overall memory requirement is also reduced at clone creation time. For more information on storage requirements and sizing limits, see the VMware Knowledge Base (KB) article https://kb.vmware.com/kb/2150348.

Starting with Horizon 7 version 7.8, instant clones support the vSphere TRIM and UNMAP features for vSAN datastores.

Replica and Instant Clones on the Same Datastore

When you create an instant clone desktop pool, a full clone is first made from the master 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).

Replica and Instant Clones on Different Datastores

Alternatively, you can place instant clone replicas and instant 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 instant 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 instant clones in a large pool. Tiered storage configurations can be used to cost-effectively handle intensive I/O scenarios such as simultaneous running scheduled antivirus scans.

If you use vSAN datastores, you cannot manually select different datastores for replicas and instant clones. Because vSAN automatically places objects on the appropriate type of disk and caches all I/O operations, there is no need to use replica tiering for vSAN data stores. Instant clone pools are supported on vSAN data stores.

Storing Instant Clones on Local Datastores

Instant clone virtual machines 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 Horizon 7 environments but not appropriate in others.

Note: The limitations described in this topic do not apply to vSAN datastores, which also use local storage disks but require specific hardware.

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

Consider using local datastores if your virtual machines have floating assignments, are not dedicated to individual end users, and can be deleted or refreshed at regular intervals such as on user logoff. This approach lets you control the disk usage on each local datastore without having to move or load-balance the virtual machines across datastores.

However, you must consider the restrictions that using local datastores imposes on your Horizon 7 desktop or farm deployment:

  • You cannot use VMotion to manage Virtual Volumes.
  • You cannot use VMware High Availability.
  • You cannot use the vSphere Distributed Resource Scheduler (DRS).

    If you are deploying instant clones on a single ESXi host with a local datastore, you must configure a cluster containing that single ESXi host. If you have a cluster of two or more ESXi hosts with local datastores, select the local datastore from each of the hosts in the cluster. Otherwise, instant clone creation fails. This behavior differs from the behavior of local datastores with Composer linked clones.

  • You cannot store a replica and instant clones on separate datastores.
  • If you select local spinning-disk drives, performance might not match that of a commercially available storage array. Local spinning-disk drives and a storage array might have similar capacity, but local spinning-disk drives do not have the same throughput as a storage array. Throughput increases as the number of spindles grows. If you select direct attached solid-state disks (SSDs), performance is likely to exceed that of many storage arrays.
  • If you intend to take advantage of the benefits of local storage, you must carefully consider the consequences of not having VMotion, High Availability, DRS, and other features available. If you manage local disk usage by controlling the number and disk growth of the virtual machines, if you use floating assignments and perform regular refresh and delete operations, you can successfully deploy instant clones to local datastores.
  • Local datastore support for instant clones is available for both virtual desktops and published desktops.

Differences between Instant Clones and Composer Linked Clones

Since instant clones can be created significantly faster than linked clones, the following features of linked clones are no longer needed when you provision a pool of instant clones:

  • Instant-clone pools do not support configuration of a separate, disposable virtual disk for storing the guest operating system's paging and temp files. Each time a user logs out of an instant clone desktop, Horizon 7 automatically deletes the clone and provisions and powers on another instant clone based on the latest OS image available for the pool. Any guest operating systems paging and temp files are automatically deleted during the logoff operation.
  • Instant-clone pools do not support the creation of a separate persistent virtual disk for each virtual desktop. Instead, you can store the end user's Windows profile and application data on App Volumes' user writable disks. An end user's user writable disk is attached to an instant clone desktop when the end user logs in. In addition, user writable disks can be used to persist user-installed applications.
  • Due to short-lived nature of instant-clone desktops, instant clones do not support the space-efficient disk format (SE sparse), with its wipe and shrink process.
  • Instant-clone desktop pools are compatible with Storage vMotion. Composer linked-clone desktop pools are not compatible with Storage vMotion.