Wow, that was a long title for a blog post but then again, there are many moving parts in this cutting edge mixture of technologies..

Instant Clone Technology (that is, vmFork) uses rapid in-memory cloning of a running parent virtual machine, and copy-on-write to rapidly deploy the virtual machines.

Copy-on-write, or COW, is an optimization strategy. This means that whenever a task attempts to make a change to the shared information, it should first create a separate (private) copy of that information to prevent its changes from becoming visible to all the other tasks.

A running parent virtual machine is brought to a quiescent, or quiet, state and then forked (when a piece of software or other work is split into two branches or variations of development), and the resulting clones are then customized (receiving unique MAC addresses, UUIDs, and other information) and powered on. These clones share the disk and memory of the parent for Reads and are always ready for login instantly. After the clone is created, Writes are placed in delta disks. Both memory and disk are copy-on-write, so if a new clone modifies bits of its memory or disk, a separate copy is made for that virtual machine, thus preserving security and isolation between virtual machines.

Instant clones are installed as part for the Horizon Broker. There is no option to select to install, it just installs with the Horizon 7 broker.

The instant clone engine is a Java app that runs on the Tomcat server.

API calls are made to VMFork on vSphere.

The Master Image has the Horizon Agent installed with the Instant Clone option selected. This has the code for instant clones and the instant clone customization engine.

Any broker is capable of running the NGVC engine, but only one of them should be running NGVC. We use the existing Federated Tasks to manage this. If the broker running the NGVC were to crash/shutdown, then the task would move to another broker in the cluster. In flight operations can error out in that scenario, but newer cloning operations should work fine.

Stateless because all configurations information is stored in vCenter. No multiple database scenario – Composer database / LDAP / vCenter to get out of sync. One source of truth.

Master VM

  • Golden Image”
  • Follow build Guidelines in KB 2007319 – See Hotfix for Win7 in Step 10
  • Optimizations – OS Optimization Tool
  • Horizon Agent with Instant Clones
  • Other Agents – AppVolumes, FlexEngine
  • Snapshot(s)


  • Linked clone of Master VM – Based on chosen snapshot
  • Low disk space Usage
  • Named as <cp-template-GUID> in vCenter in <ClonePrepInternalTemplateFolder>
  • Defaults to same datastore as Master VM
  • Linked to Master VM.


  • Full Clone of Template – Thin provisioned – Less total disk space than Master VM
  • Has a Digest
  • Placed on selected datasore(s) for desktops. Can be placed on a single specific datastore in case of tiered storage selection.
  • Named as <cp-replica-GUID> in vCenter in <ClonePrepReplicaVmFolder>
  • Shared read disk for desktop VMs


  • Used to fork Desktop VMs
  • Placed on selected datasore(s) for desktops. One per host per datastore
  • Named as <cp-parent-GUID> in vCenter in <ClonePrepParentVmFolder>

Desktop VMs – Instant Clones

  • Placed on selected datastore(s) for desktops.
  • Named as defined in Horizon Administrator Pool Settings
  • Very small disk space usage – Can grow over time but limited by delete on logoff

Instant Clone Components in vCenter

Here’s a deeper dive session into the concepts (and more!) detailed above

ok, so now you are familiar with Instant Clones, let’s see how do they behave on XtremIO !

Leave a Reply Cancel reply