Having discussed full clones, we are going to talk about deploying virtual desktop machines using linked clones.

In a linked clone deployment, a delta disk is created and then used by the virtual desktop machine to store the data differences between its own operating system and the operating system of its parent virtual desktop machine. Unlike the full clone method, a linked clone is not a full copy of the virtual disk. The term linked clone refers to the fact that the linked clone will always look to its parent in order to operate, as it continues to read from the replica disk. Basically, the replica is a copy of a snapshot of the parent virtual desktop machine.

The linked clone itself could potentially grow to the same size as the replica disk if you allowed it to. However, you can set limits on how big it can grow, and should it start to get too big, then you can refresh the virtual desktops that are linked to it. This essentially starts the cloning process again from the initial snapshot.

Immediately after a linked clone virtual desktop is deployed, the difference between the parent virtual machine and the newly-created virtual desktop machine is extremely small, and therefore reduces the storage capacity requirements compared to that of a full clone. This is how linked clones are more space-efficient than their full clone brothers.

The underlying technology behind linked clones is more like a snapshot than a clone, but with one key difference—View Composer. With View Composer, you can have more than one active snapshot linked to the parent virtual machine disk. This allows you to create multiple virtual desktop images from just one parent.

Best practice would be to deploy an environment with linked clones (or instant clones) to reduce the storage requirements. However, as we previously mentioned, there are some use cases where you may need to deploy full clones.

One thing to be aware of, which still relates to the storage, is that, rather than capacity, we are now talking about performance. All linked clone virtual desktops are going to be reading from one replica and will, therefore, drive a high number of Input/Output Operations Per Second (IOPS) on the storage where the replica lives. Depending on your desktop pool design, you are likely to have more than one replica, as you would typically have more than one data store. This, in turn, depends on the number of users who will drive the design of the solution. We will cover this in greater detail in Chapter 3, Design and Deployment Considerations.

With Horizon View, you can choose the location where the replica lives. One of the recommendations is that the replica should sit in fast storage, such as a local or shared SSD.

An alternative solution would be to deploy some form of storage acceleration technology to drive the IOPS. Horizon View also has its own integrated solution, called View Storage Accelerator (VSA) or Content Based Read Cache (CBRC). This feature allows you to allocate up to 2 GB of memory from the underlying ESXi host server, which can be used as a cache for the most commonly read blocks. As we are talking about creating and booting up desktop operating systems, the same blocks are required; as these can be retrieved from memory, the process is accelerated.

Another solution is View Composer Array Integration (VCAI), which allows the process of building linked clones to be offloaded to the storage array and its native snapshot mechanism, rather than taking CPU cycles from the host server.

There are also several other third-party solutions that resolve the storage performance bottleneck, such as ThinScale's ThinIO (https://www.thinscale.com/products/thinio/) solution, which delivers software-defined storage acceleration to actively reduce disk I/O.

In the next section, we will take a deeper look at how the linked clone process works.