Also know as Just In Time (JIT) desktops, or vmFork technology. In short, it enables you to clone an existing virtual machine in just a matter of seconds — close to one clone per second actually. Its technology is based on in-memory cloning of a Master virtual machine (which also means it shares the memory of the so-called parent virtual machine) and copy-on-write for rapid deploy purposes. As you can probably imagine, this approach offers some unique desktop provisioning options when combined with, let’s say a Citrix XenDesktop Virtual Desktop Infrastructure, or VDI in short. Do note however that initially Instant Clones are/were a feature of VMware Horizon version 7 (Enterprise edition) and upwards, it was VMware’s Project Orion that introduced Instant Clones to Citrix’s XenDesktop, which is still in tech preview.
How it works
As mentioned, a Just In Time desktop is based on a Master virtual machine. When the vmFork technology is put to work the following happens, check out the image below as well.
- When you create or add-in a new ‘Instant Clone’ desktop pool you first need to select a snapshot of the master VM. The instant-clone engine will take over from there.
- Based on the selected (by you) master VM snapshot an internal template VM will be created, which will be linked to the master VM itself.
- The system performs a domain join on the internal template VM, which ensures that all the proper Windows registry keys and settings are correctly populated. This process involves a reboot. This also ensures that at a later stage, during the actual cloning process no more reboots will be needed.
- All Replica VM’s are based on, or linked to the internal template VM — these are thin provisioned full linked clones. See the image below as well.
- The system takes a snapshot of each replica VM and uses it to create one running parent VM per VMware ESXi host per datastore.
- When the cloning process starts, first the running parent VM is brought into a so-called quite state before it is Forked (according to VMware: The forking process is like creating two similar branches of development so that disk and memory can be shared).
- As part of the Forking process the running parent VM memory and disks are used to create the instant clones, but only during the creation process (read only). Once the Instant Clones are created and up and running, the running parent VM (s) can be deleted without affecting the Instant Clone machines.
- Next a pre-configurable number of Instant Clones will be created/provisioned, each receiving their own MAC address, UUID’s etc, which is referred to as VM/clone customization or a.k.a. ClonePrep. Changing the Active Directory password, joining the Active Directory domain (no reboot needed — this was already taken care of during the internal template creation process earlier, remember) and activating the Microsoft license are part of this process as well.
- Once the cloning process is finished the Instant Clones will share the disk and memory (read only) of the Replica VM. All writes will be directed to delta disks, part of the Instant Clones.
- As a result of all this the clones will be in an instant powered-on state and ready for users to login. No reconfigurations and/or reboots needed.
- When a user logs out, the desktop VM is deleted. New clones are created according to the provisioning policy, which can be on-demand/scheduled or up-front — the View administrator has full control over when the users receive the latest image. This significantly simplifies the patching and updating process when it comes to non-persistent ‘golden’ images (our master image in this case). Also, 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 operating system and application patches. When urgent patching is necessary, users can be forced to log out and log in to latest (pathed) image/Instant Clone.
- Instant Clone technology does not need a database and the Forking process creates significantly less load on vCenter as well, though there might be a higher initial peak load.
- Instant Clones support up to 2000 VM’s per desktop pool.
When it comes to Instant Clones and XenDesktop (Project Orion) things work slightly different. Next to the above steps there are one or two dependencies you need to be aware of, at least when it comes to the Project Orion Tech Preview. Have a look at this post, it’s from Marius Sandbu, on setting up Instant Clone technology for Citrix XenDesktop.
In the above image the Replica VM’s are stored/created on the same datastores as the Instant Clone machines, though this could be a separate datastore just as easy — in the case of tiered storage scenario for example (SSD’s anyone?), which is not that uncommon. In this example one Replica VM per datastore will be created. Of course, VSAN is also supported. In that case there will be just one datastore and the data tiering will be done automatically.
Main use case
Non-persistent VDI based desktops (Horizon 7 and/or XenDesktop — combined with VMware’s Project Orion). There are a couple of reasons for this. For one, the vmFork or JIT desktops technology does not work for RDSH based workloads, only single user desktops are supported today. Secondly, only ‘floating’ user are supported, meaning virtual desktops are randomly assigned and finally Instant Clone desktops cannot have a persistent disk assigned to them.
Considering the speed of Instant Clones, including the fact that they are instantly powered-on and ready for users to log in there is no need to pre-boot VM’s or to keep multiple VM’s running while they are nog being used, though configuring spare (powered-on) machines is still optional of course.
VMW fact: you can specify whether to provision all desktop VM’s (Instant Clones) when the pool is created or to provision the VMs when they are needed, at least that’s the case within Horizon 7. Besides all this, when the ‘golden’ image or parent VM has been updated/customized the process of re-provisioning and assigning these ‘new’ desktops out to your users is extremely simply and above all, time efficient.
However, do note that after the master VM snapshot has been copied over to every LUN containing Instant Clones, the Replica VM’s (could be a single Replica VM as well of course) will need to be placed/created on one or multiple datastores as well, and that snapshots are made of those Replica VM’s from where parent VM’s are cloned to each ESXi host on each datastore before they will be powered on. Depending on the type of storage you use this process will take somewhere between 10 to 20 minutes tops. After that you will have your ‘new’ Instant Clone desktop pools up and running within minutes.
Combine all this with Citrix’s App Disks, Uhmโฆ I mean Unidesk, VMware’s App Volumes (or any other form of layering) and/or End User Environment Manager or Citrix’s workspace environment management solution (former Norskale) for that matter, and non-persistent will feel persistent — the best of both worlds.
Takeaways
- Instant Clones are extremely fast to provision, easy to set up and manage.
- When it comes to Citrix, it is VMware’s Project Orion that brings Instant Clone technology to XenDesktop (VDI).
- The primary use-case is VDI non-persistent virtual machines.
- You can have up to 2000 virtual machines per desktop pool.
- Instant Clone technology, also referred to as Just In Time Desktops (or JIT in short), is an Horizon 7 (and upwards) Enterprise Edition feature.
- Copy-on-Write technology is used for both memory and disk management.
- Give the placement of your master VM, Replica VM’s etc. some thought (tiered storage/multiple datastores).
Thanks for reading.
One response to “VMwares’ Instant Clones technology with a touch of XenDesktop”
[…] Read the entire article here, VMwares’ Instant Clones technology with a touch of XenDesktop […]