Reading Time: 5 minutes

Starting with VMware Horizon 7 it’s possible to choose two different way to deliver space optimized desktop pools: using VMware Composer and Linked Clones technology (existing from several years) or use the new Instant Clones technology (introduced with vSphere 6.0).

Similar to View Composer linked clones, instant clones share a virtual disk of a parent VM and therefore consume less storage than full VMs. In addition, instant clones share the memory of a parent VM. Instant clones are created using the vmFork technology.

An Instant Clone desktop pool has the following key characteristics:

  • The provisioning of instant clones is significantly faster than View Composer linked clones.
  • Instant clones are always created in a powered-on state, ready for users to connect to. Guest customization and joining the Active Directory domain are completed as part of the initial power-on workflow.
  • When a user logs out, the desktop VM is deleted. New clones are created according to the provisioning policy, which can be on-demand or up-front.
  • With the push-image operation, you can re-create the pool from any snapshot of any parent VM. You can use a push image to roll out the operating system and application patches.
  • When clones are created, View selects a datastore to achieve the best distribution of the clones across the datastores. No manual rebalancing is necessary. View storage accelerator is automatically enabled.
  • Transparent page sharing is automatically enabled.

That means a lot of optimization for your virtual desktop and a just in time provisioning not really possible with traditionalism linked clones approach, as described in this post.

There are different steps involved in the two cloning processes: when you eliminate or shorten the steps for provisioning View Composer clones by using Instant Clone Technology, you significantly reduce the time for a desktop to be provisioned and ready.


What are some of the benefits of Instant Clone technology over View Composer Clones?

  • Simplified deployment and patching for administrators: Instant clones do not need to be refreshed, recomposed, or rebalanced. When a user logs out of the desktop, that desktop always gets deleted and recreated as a fresh image from the latest patch. This process creates a staggered approach to patching, thus eliminating “boot storms,” reducing storage IOPS, and creating less of a load on the vCenter Server. Desktop-pool image changes can also be scheduled during the day with no downtime for the users or for the availability of the desktop pool, so that the View administrator has full control over when the users receive the latest image. Horizon 7 leverages rolling refresh operations so that users can continue to use their existing logged-in desktop, even during an image-update operation. When the user logs out of their desktop session, a new clone is instantly created using the latest image, and the desktop is immediately available for login. However, if you have an urgent patch, you can “force” the user to log out and immediately log in to the latest image.
  • Clone-level CBRC (Content-Based Read Cache) is no longer needed. When a virtual machine is created, Horizon 7 indexes the contents of each virtual disk file. The indexes are stored in a virtual machine digest file. At runtime, the ESXi host reads the digest files and caches common blocks of data in memory. To keep the ESXi host cache up to date, Horizon 7 regenerates the digest files at specified intervals and also when the virtual machine is recomposed. You can modify the regeneration interval. A longer regeneration interval puts less of a load on the system, but digest files tend to be “dirtier” and therefore CBRC is less useful. In the case of Instant Clone Technology, CBRC is less useful because the clones are short-lived and deleted or reimaged when the user logs out. Master virtual machines and replicas still use CBRC, which is calculated automatically.
  • SEsparse wipe-and-shrink operations are no longer needed. Typically, VMDKs keep growing, and SEsparse wipe-and-shrink sweeps and frees up unused blocks after they are deleted. This operation is no longer needed because the virtual machines are short-lived. They are either deleted or reimaged after the user logs out.
  • Unlike View Composer, Instant Clone Technology does not need a database, which greatly simplifies the Horizon 7 architecture. This also helps to lower the overall support cost of the solution and reduces the complexity of future environment upgrades.

Instant clones have the following compatibility requirements:

  • Horizon Enterprise edition
  • vSphere 6.0 Update 1 or later.
  • Virtual machine hardware version 11 or later.
  • Horizon Agent installed with Instant clones support (that is exclusive with Composer support)

In Horizon 7.0, instant clones have some following restrictions and limitations:

  • Only single-user desktops are supported. RDS hosts are not supported.
  • Only floating user assignment is supported. Users are assigned random desktops from the pool.
  • Instant-clone desktops cannot have persistent disks. Users can use VMware App Volumes to store persistent data. For more information about App Volumes, see
  • Virtual Volumes and VAAI (vStorage APIs for Array Integration) native NFS snapshots are not supported.
  • Sysprep is not available for desktop customization.
  • Windows 7 and Windows 10 are supported but not Windows 8 or Windows 8.1.
  • PowerCLI is not supported.
  • Local datastores are not supported.
  • IPv6 is not supported.
  • Instant clones cannot reuse existing computer accounts in Active Directory.
  • Persona Management is not available.
  • 3D rendering is not available.
  • You cannot specify a minimum number of ready (provisioned) machines during instant-clone maintenance operations. This feature is not needed because the high speed of creating instant clones means that some desktops are always available even during maintenance operations.