Anybody who’s ever worked with VMware Horizon must know that this solution offers three types of VM deployment designed to satisfy different user requirements by applying one of the following three cloning methods:
- A Full Clone is a complete and independent copy of the original parent VM that operates like a brand new virtual machine.
- A Linked Clone is a copy of a virtual machine created and managed with the View Composer. This software service simultaneously applies one shared replicas storage for the read-only operations and a local storage for the read/write operations (it is called delta disk / redo log). Such VMs memory is entirely independent of the parent VM that is called a replica because it is provisioned from a golden image virtual machine.
- An Instant Clone is an instant copy of a running virtual machine that uses the same memory (Shared memory) the parent VM does with the same Copy-on-write technology, but also for memory, making it more like containerized virtualization.
Now that we’ve been properly introduced, let’s dig into details:
Full Clone
Long story short, it literally can’t get any simpler than this. Performance-wise, this one is by no extent worse than a regular VM: functionality is basically the same. Of course, there’s also a speed issue. Its deployment can become quite a headache since every new user is supposed to copy all the data from the virtual disks physically.
However, even though Full clones can provide you with more robust performance levels than the Instant and Linked ones, you have to remember that there is an upside-down as well. Since a Full clone disposes of the whole OS copy, when it comes to updates, you have to update every single machine, not just a parent/replica VM (like you would’ve done with an Instant or a Linked clone).
All in all, there’s not so much to say about Full clones apart from the fact that their storage performance is exceptional and can serve as a reference sample for other cloned machines.
Linked Clone
Linked clones have a long history going back to VMware View (back then, Horizon wasn’t even announced). Their creation and management is a responsibility of the VMware View Composer that deals with virtual desktop pools deployment.
First of all, View Composer creates a replica of a fully configured golden image virtual machine (OS is all set up, and the apps are installed). This replica will act as a parent so that each deskyop can use it for read-only operations, and all changes are written to the secondary delta disks thanks to the Copy-on-write technology.
Linked clones are known to be extremely easy and simple to use. They are created swiftly (just don’t forget about the delta disks), and the replica doesn’t have to be on and active, just the storage. Moreover, you will be pleasantly surprised by how much free storage space you’ll get since the OS and apps are stored in only one sample.
Such architecture is perfect for temporary tasks. For example, call center employees can use it for a multitude of one-time tasks without spending any extra resources.
That way, according to the Linked Clone pool policy, a clone may be deleted when the user disconnects or after the Logout operation. Also, you can attach a persistent disk so that the users’ data would stay even if such a virtual desktop is off.
Unfortunately, the disadvantages are plain to see just as well as the benefits. First, this whole approach depends on the View Composer and its reliability to the full extent; second – read/write operations will probably take a lot more time than you’re used to. In the write-only operations, the additional resources are drawn to provide for the Copy-on-write technology. Read-only operations are slowed down too: the machine needs time to decide if the data will be retrieved from the replica or users’ delta disks.
It would help if you kept in mind, though, that in the VMware Horizon 8, the Linked clones are marked as Deprecated. That probably means that the next major upgrade moves from them to the Instant clones that happen to be our next subject.
Instant Clone
Instant Clone technology (VMFork back in the day) was designed and developed to create a working copy of the running virtual machine on VMware vSphere. What makes it so distinctive is that this technology doesn’t require a centralized server to work because it operates at the VMware ESXi level. It was introduced for the first time in vSphere 6.7, and it keeps on getting upgraded since then.
It works like that: with memory copy-on-write technology, you create a “just in time” clone (VMX process) that starts using the same memory parent VM does (shared memory). The interesting thing is that this subsidiary VM cannot write any changes to this shared memory. For read/write operations on its own data uses a unique memory area. It’s all the same with the delta disks, which are meant for any changes to the shared base disk:
It may seem that the Instant Clone technology behaves and functions more like containerized virtualization that enables several isolated environments to work within one shared OS, and that is so indeed. An Instant clone isn’t just created swiftly but already running and ready to go, and on top of that, you will be able to save up some disk space and memory. One less evident advantage is that this technology, unlike our previous contestant, is completely independent of the View Composer software, which means that your whole infrastructure just has gone more reliable.
Instant clones also take significantly less time for a desktop to be ready:
The disadvantages of this technology are generally similar to those of the Linked clones. Still, they are accompanied by certain limitations of the number of clones per one parent VM, the necessity to maintain a complex system of memory management (which potentially affects security and performance), and a particular lack of support for some vSphere features.
An inevitable decline in the I/O performance is actually very simple to explain. Upon creating the first cloned VM, the parent machine gets a delta disk as well so that the clone won’t write any changes to the shared disk. Eventually, every time a clone is created, the parent VM gets an additional delta disk.
Such an approach has weak spots as additional delta disks will eventually slow down the parent VM. Also, the whole structure gets so unnecessarily complicated in general that it may lead to problems.
As of now, the following functionalities are not accessible to Linked clones:
- Machine customization with Sysprep and Quickprep
- OS Windows 8 and 8.1
- Persona Management
- Virtual Volumes (VVols)
- Native snapshots via VAAI (vStorage APIs for Array Integration)
- Selecting VM names manually (it is available for the Linked clones within dedicated- or floating- pools)
- Remote machine power policy (Always Powered On, Suspend, Power Off) for the pool
- Adding persistent disks
Even though persistent disks don’t work with the Instant clones, you can fix it with such solutions as VMware Dynamic Environment Manager (DEM), Microsoft FSLogix, or VMware App Volumes Writable Volumes. Keep in mind that Instant clones support TRIM and UNMAP in vSAN storage.
Performance Matters
Luckily, VMware has provided us with the performance results from testing all three types of clones. Let’s summarize what they have got for us in this white paper.
The first one is provisioning time and performance of a clone VM while running a heavy I/O workload:
Admittedly, Full clones take much more time to get ready than the Instant, and Linked clones do. Instant clones take a little longer than the Linked ones only because they need to configure Copy-on-write operations both for base disk and shared memory.
On the other hand, we can clearly see a severe I/O performance decline under a heavy workload for Instant and Linked clones (Hammer DB also utilizes memory and resulting performance of the Instant Clones is even lower).
Another interesting testing was performed running SPECjbb workload, only this time it weren’t machines with 450 GB of storage but ones with 16 GB VMDK, and it was testing memory and CPU, not I/O workloads:
Even though Full clones are slower in terms of storage provisioning, we can see an interesting result: in terms of processed requests (CPU/Memory), all three types behave more or less the same (an acceptable statistical error is about 5%). Also, provisioning time for Full clones is less than the one for Instant Clones, because Instant Clones need time to deal with setting up memory procedures under the heavy load.
Now, let’s see how those are affecting the parent VM. It must be self-evident that Full clones function entirely separately and bear no impact at all, which is very much (in terms of I/O) not the case for the other two types:
However, this goes only for the I/O performance since all three almost don’t affect the parent VM at all in the cases with CPU and memory.
The next one highlights creating a Full clone on a remote ESXi host (Instant clones cannot do that at all, Linked clones require shared storage). This time, the provisioning time of a Full clone has drastically changed for the worse:
With the increase in number of clones, the I/O performance goes like this:
When running the SPECjbb 2105 workload, the picture is different:
From the side of the CPU it looks like all three types are working as one, but memory-wise, Instant clones will always be a little slower.
If we are to look at how the provisioning times of different types of clones change with an increase in the number of clones, we will see nothing surprising: Full clones grow lineary, the others – not so much.
To Conclude
Finally, let’s summarize all that has been covered to categorize this information serially:
| Advantages | Disadvantages | |
| Full Clone | Works well with the I/O–intensive workloads
Nothing to share with a parent VM No single point of failure for multiple desktops Possibility to create a clone on a remote host |
Takes too much time to get ready for work
Consumes too much space since every desktop has its own storage Full clone cannot be quickly created or deleted Updates are taking too much time since each desktop needs to be updated separately |
| Linked Clone | Only one copy is required for read-only operations, which saves the disk space
Swift clone creation and elimination Replica and all the other desktops are easy to update (Rebuild/Refresh) |
Performance decline due to delta disks and extra time on finding data for read/write operations
Depends on View Composer Marked Deprecated, will be absent in the following releases |
| Instant Clone | Desktop is created “just in time” and ready to go
No relation to View Composer/vCenter Fast OS update Saving disk space AND memory |
System is much more complicated because Full clones share both disk and a memory state with the parent VM
Low performance with the I/O–intensive workloads Some vSphere features are not available Cannot use persistent disks without additional software |
I hope all of this has been useful so that you can decide what cloning technology will serve you the best!
