VMware Horizon 7.0: Instant Clones
With the release of Horizon 7, VMware has introduced Instant Clones (previously code-named Project Fargo) into the wild. Instant Clones utilize the vmFork technology within vSphere to fork a virtual desktop from a running virtual machine. Below are highlights about Instant Clones:
- This is a completely separate technology from Linked Clones, and it also does not rely on View Composer at all. View Composer does not even need to be installed, and no Composer database is required.
- Instant Clones are only available in Horizon Enterprise edition.
- In the initial 7.0 release, only virtual desktops and not RDSH servers are supported.
- vSphere 6.0 Update 1 or later and Virtual Machine version 11 or later is required.
- Windows 7 and 10 are supported. Windows 8.x are not supported.
- Local ESXi datastores are not supported.
- 3D rendering is not supported.
- The customization process does not use QuickPrep, but instead a new process called ClonePrep. No reboots are required after the virtual desktop is forked from the ClonePrep ParentVM like is required with the traditional QuickPrep process.
- All Instant Clones are non-persistent. Resetting a virtual desktop is a delete and re-fork process.
- Persistence is available through AppVolumes and UEM.
- VMware estimates the following time differences between View Composer and Instant Clones for 1,000 desktops:
- Pool Creation: 25 minutes (Instant Clones) vs 170 minutes (Composer)
- Creating 1 Desktop: 1.5 seconds (Instant Clones) vs 10.2 seconds (Composer)
- The forking/cloning process is incredibly quick, with it only taking an average of one second per desktop. When initially creating the pool or updating the image, it can still take a few minutes of time, as there are a few intermediate steps to preparing the ClonePrep Parent VMs to be forked.
- The Master VM snapshot is cloned to a ClonePrepInternalTemplate folder, which is then cloned to a ClonePrepReplicaVmFolder, the virtual disk digest is created, the ClonePrep Replica VM is then cloned to a ClonePrep Parent VM for each host in the cluster and forking is enabled on them, and then the virtual desktops are forked from the ClonePrep Parent VMs.
- If updating, the old ClonePrep Parent VMs, Replica VMs, and Template are deleted.
- A ClonePrep ParentVM has to be created for every host in the cluster and is always running, so this must be calculated into design considerations. This is the virtual machine that all virtual desktops on the host are forked from.
- ClonePrep Parent VMs per host appear to be set to a static memory usage percentage. In my lab, all parent VMs were locked to 92% Guest Memory usage.
- The internal Instant Clone folders are: ClonePrepInternalTemplateFolder, ClonePrepParentVmFolder, ClonePrepReplicaVmFolder, and ClonePrepResyncVmFolder.
- The virtual machines within these folders are locked from being modified manually. Trying to click ‘Edit Settings’, perform power operations, or other activities are grayed out within the vSphere Client. These can be unprotected by using the IcUnprotect.cmd script on the View Connection servers.
- In the initial release, Instant Clones will prevent ESXi hosts from properly entering maintenance mode if simply placing the host into maintenance mode. Instead, the IcMaint.cmd script must be ran from the View Connection Servers to put the host into maintenance mode.
- AppVolumes 2.10 and prior are not supported for usage with Instant Clones.
- Instant Clones place significantly less load on vCenter compared to View Composer. Comparatively, there is 1 vCenter tasks to create a desktop with Instant Clones vs 7 with Composer.
- Boot storms no longer occur as forked desktops do not boot but instead are forked in a running state.
- The View Agent cannot be installed to support Composer and Instant Clones at the same time. When installing the View Agent, one or the other must be chosen.