Dive into the latest features for VMware Instant Clones
Instant Clone technology helps admins quickly copy VMs. VMware grows Instant Clone support but removes SID needs and deprecates Linked Clones in Horizon 2006.
With the release of Horizon 2006, VMware brings new deployment features to its Instant Clone technology. IT teams can use smart provisioning and ClonePrep to create secure, efficient VMs with vCenter, plus they can use VMware's Guest Customization Engine to launch Instant Clones on Linux.
When admins clone a VM, VMware Horizon creates an exact copy, which means the clone consumes the same amount of data as the original VM. Linked Clones were the first efficiency improvements of the VM cloning process. With Linked Clones, a parent VM is the central disk that connects to child VMs, and it only recognizes and stores changes related to the parent VM.
This reduces the necessary disk space, because for each VM, only the unique disk blocks are stored. The creation process is also fast because instead of cloning the entire disk, each VM starts with an almost empty disk.
This process is efficient on disk, but the hypervisor memory still registers each VM as a full VM -- where every machine must be individually booted and customized -- which takes time and resources. Plus, for each parent VM, first a replica is created to link the VM so that admins can update the parent VM independently from any clones.
Changes in VM clone support
VMware introduced a new technology with vSphere 6.0 Update 1 that lets admins implement a cloning technology that uses a parent VM that boots and loads in the memory; any child VMs spawn off from the parent VM.
These VMs are Instant Clones and they do go through a boot cycle because the run process is based on the already booted parent VM. For each machine, only the machine's unique memory pages are placed in the hypervisor's memory. On-disk Instant Clones work similarly to Linked Clones in terms of efficiency and resource savings. The image shows the relationships between the parent and child VMs.
VMware added native support for Instant Clones in VMware Horizon version 7. When they were first introduced, they were only available for Enterprise license customers. Other IT teams still relied on Linked Clones for efficient desktop deployments.
However, VMware decided all customers must switch to Instant Clones and now this feature is available to customers starting with Horizon 2006. To give organizations time to switch, Linked Clones are still available in Horizon 2006's initial release but VMware plans to remove them in Q4 2020.
The requirement to create an Instant Clone desktop is to have a Golden VM prepared with the VMware Horizon Agent with the Instant Clone component enabled. That machine then creates a Linked Clone template. Then, a full clone replica is created on each datastore used for the pool and a parent VM is created per host, per datastore.
The following image shows the objects that the vCenter inventory can create.
Smart provision in VMware Horizon
Instant Clone implementation can cause a sprawl of replica and parent VMs, depending on the design. There is a replica per datastore, and a parent per host, per datastore in an eight-node cluster. If admins configure four data stores for a pool, there would be four replicas and 32 parent VMs.
If an admin runs only 20 virtual desktops, then the overhead outweighs the benefits. In this scenario, it would be best to use a single datastore because it limits the number of parent VMs to eight. But it is not the most efficient approach with the same 20. With Horizon 2006, parent VMs are only created if admins run more than 12 virtual desktops for an Instant Clone pool per host.
If an admin had eight hosts and 20 virtual desktops, then there would be no more machines beyond the 20 desktops themselves. The disadvantage of this is that Instant Clone deployment time takes longer. They behave like older Linked Clones because they do not share parent VM memory.
Use ClonePrep, not QuickPrep or Sysprep
Because Instant Clones that are spawned off from a parent are a clone of a running process, they don't require the Windows boot process.
It's very efficient but imposes a new problem because the computer name and domain membership must be changed, which normally requires a reboot. Because of this, VMware introduced a new utility called ClonePrep that takes care of the rename and domain join without a Windows boot process.
This function replaces QuickPrep and Sysprep. There is one important difference between these utilities and that is that only Sysprep can change the Security Identifier (SID) for a machine. It is very rare that a unique SID is necessary for all virtual desktops.
In the rare case that an application requires a unique SID, the only other option would be to use full clones.
Instant Clones without Horizon
This ClonePrep for Windows requirement, which is only available with Horizon, is the reason that it's tricky for admins to deploy their own Instant Clones on vSphere.
Any admin can launch their own Instant Clones through the vSphere API, but then the customization process for Windows is unavailable. This makes efforts to create Instant Clones outside of Horizon that are targeted toward non-Windows OSes.
It is only possible to create Instant Clones through the vSphere API, not directly in the vSphere Client. For admins who can use the SDK from a programming language, there is a set of PowerCLI extensions that contain a cmdlet to create an Instant Clone.
Creating an individual Instant Clone is only 50% of the work, the other half is to customize the OS. For Windows, this is done with Horizon's ClonePrep, but outside of Horizon there are only Linux-based tools. VMware offers a Guest Customization Engine for admins that use Linux.
Once installed, this engine configures the network in the guest VM and allows an admin to run their own required scripts for Instant Clone that support an application or need OS customizations.
There are not only options available for Linux. William Lam, a solution architect at VMware, made a solution to create Instant Clones for nested ESXi hosts. When admins use PowerCLI and shell scripts written for this workflow, it's possible to run many nested ESXi servers with a small memory footprint.