Instant clones leverage vSphere vmFork technology to quiesce a running base image, or parent VM, and rapidly create and customize a pool of virtual desktops.

Instant clones share the virtual disks with the parent VM at the time of creation. 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.

Storage for Instant Clones

Instant clones support the use of all standard vSphere storage options: VMFS, NFS, vSAN, and local datastores.

You can store instant clones on spinning media-backed (HDDs) datastores or on datastores backed by solid-state drives (SSDs). HDDs provide lower performance, but are less expensive and provide higher storage capacity. SSDs have low storage capacity and high read performance, typically supporting tens of thousands of I/Os per second (IOPS).

One way to lower the storage cost is through the tiered use of HDDs and SSDs. When you create an instant-clone desktop pool, Horizon 8 creates a series of internal VMs for managing instant clones. One such internal VM is a replica, which is essentially a full clone made from the golden image. The replica and the subsequent instant clones made from it can be placed on the same datastore/LUN (logical unit number), or separate datastores with different performance characteristics. For example, you can store the replica VMs on a SSD-backed datastore. A typical environment has only a small number of replica VMs, so replicas do not require much storage. You can then store instant clones on HDDs. They are inexpensive and provide high storage capacity, which makes them suited for storing a large number of clones.

Configuring replicas and clones in this way can reduce the impact of I/O storms that occur when many clones are created at once. For example, if you deploy a floating-assignment pool with a delete-machine-on-logoff policy, and your users start work at the same time, Horizon 8 must concurrently provision new machines for them.
Important: This feature is designed for specific storage configurations provided by vendors who offer high-performance disk solutions. Do not store replicas on a separate datastore if your storage hardware does not support high-read performance.
You must follow certain requirements when you store the replica and clones in a pool on separate datastores:
  • You can specify only one separate replica datastore for a pool.
  • The replica datastore must be accessible from all ESXi hosts in the cluster.
  • This feature is not available if you use vSAN datastores. These types of datastores use Software Policy-Based Management, so that storage profiles define which components go on which types of disks.

Availability Considerations for Storing Replicas on a Separate Datastore

You can store replica VMs on a separate datastore or on the same datastores as the clones. These configurations affect the availability of the pool in different ways.

When you store replicas on the same datastores as the clones to enhance availability, a separate replica is created on each datastore. If a datastore becomes unavailable, only the clones on that datastore are affected. Clones on other datastores continue to run.

When you store replicas on a separate datastore, all clones in the pool are anchored to the replicas on that datastore. If the datastore becomes unavailable, the entire pool is unavailable.

To enhance the availability of the desktop pool, you can configure a high-availability solution for the datastore on which you store the replicas.