Horizon View Composer and Linked Clones

One of the main reasons a virtual desktop project fails to deliver, or doesn't even get out of the starting blocks, is down to the heavy infrastructure and storage requirements. The storage requirements in particular are often seen as a huge cost burden, which can be attributed to the fact that people are approaching a VDI project in the same way they would approach a physical desktop environment's requirements. This would mean that each user gets their own dedicated virtual desktop and the hard disk space that comes with it, albeit a virtual disk; this then gets scaled out for the entire user population, so each user is allocated a virtual desktop with some storage.

Let's take an example. If you had 1,000 users and allocated 250 GB per user's desktop, you would need 1,000 * 250 GB = 250 TB for the virtual desktop environment. That's a lot of storage just for desktops and could result in significant infrastructure costs, which could possibly mean that the cost to deploy this amount of storage in the data center would render the project cost-ineffective compared to physical desktop deployments.

A new approach to deploying storage for a virtual desktop environment is needed, and this is where linked clone technology comes into play. In a nutshell, Linked Clones are designed to reduce the amount of disk space required, and to simplify the deployment and management of images to multiple virtual desktop machines, making it a centralized, and much easier, process.

Linked Clone technology

Starting at a high level, a clone is a copy of an existing or parent virtual machine. This parent virtual machine (VM) is typically your gold build, from which you want to create new virtual desktop machines. When a clone is created, it becomes a separate, new virtual desktop machine with its own unique identity. This process is not unique to Horizon View; it's actually a function of vSphere and vCenter, and in the case of Horizon View, we add in another component, View Composer, to manage the desktop images. There are two types of clone that we can deploy, a full clone or a linked clone. We will explain the difference in the next sections.

Full Clones

As the name implies, a full clone disk is an exact, full-sized copy of the parent machine. Once the clone has been created, the virtual desktop machine is unique, with its own identity, and has no links back to the parent virtual machine from which it was cloned. It can operate as a fully independent virtual desktop in its own right and is not reliant on its parent virtual machine.

However, as it is a full-sized copy, be aware that it will take up the same amount of storage as its parent virtual machine, which leads back to our discussion earlier in this chapter about storage capacity requirements. Using a full clone will require larger amounts of storage capacity and will possibly lead to higher infrastructure costs.

Before you completely dismiss the idea of using full clone virtual desktop machines, there are some use cases that rely on this model. For example, if you use VMware Mirage to deliver the operating system as a base layer, it only works today with Full Clones and dedicated Horizon View virtual desktop machines.

If you have software developers, then they probably need to install specialist tools and a trust code onto a desktop, and therefore, need to own their desktop. Or, perhaps, the applications that you run in your environment need a dedicated desktop due to the way the applications are licensed.

Linked Clones

Having now discussed Full Clones, we are going to talk about deploying virtual desktop machines with 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, the 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 allow 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 in order to reduce the storage requirements. However, as we previously mentioned, there are some use cases where you will need to use 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 fairly 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 detail in Chapter 3, Design and Deployment Considerations.

In Horizon View, you are able to choose the location where the replica lives. One of the recommendations is that the replica should sit in fast storage, such as a local SSD.

Alternative solutions 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 booting up desktop operating systems, the same blocks are required; as these can be retrieved from memory, the process is accelerated.

Note

View Storage Accelerator is enabled by default when using Instant Clones and cannot be configured.

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 a number of other third-party solutions that resolve the storage performance bottleneck, such as Atlantis Computing and their ILIO product, or using an all-flash array such as Tintri.

In the next section, we will take a deeper look at how Linked Clones work.

How do Linked Clones work?

The first step is to create your master virtual desktop machine image, which should contain not only the operating system, core applications, and settings, but also the Horizon View Agent components. This virtual desktop machine will become your parent VM, or your gold image. We will cover the build process in Chapter 6, Building and Optimizing the Virtual Desktop OS.

This image can now be used as a template to create any new subsequent virtual desktop machines.

Note

The gold image or parent image cannot be a VM template.

An overview of the linked clone creation process is shown in the following diagram:

Once you have created the parent virtual desktop or Gold Image (1), you then take a Snapshot (2). When you create your desktop pool, this snapshot is selected and will become the Replica (3) and will be set to be read-only. Each virtual desktop is linked back to this replica; hence the term Linked Clone. When you start creating your virtual desktops, you create Linked Clones that are unique copies for each user.

Tip

Try not to create too many snapshots for your parent VM. I would recommend having just a handful, otherwise this could impact the performance of your desktops and make it a little harder to know which snapshot is which.

What does View Composer build?

During the image building process, and once the replica disk has been created, View Composer creates a number of other virtual disks, including the linked clone (operating system disk) itself. These are described in the following sections.

Linked Clone disk

Not wanting to state the obvious, the main disk that gets created is the Linked Clone disk itself. This Linked Clone disk is basically an empty virtual disk container that is attached to the virtual desktop machine as the user logs in and the desktop starts up.

This disk will start off small in size, but will grow over time depending on the block changes that are requested from the replica disk by the virtual desktop machine's operating system. These block changes are stored in the linked clone disk, and this disk is sometimes referred to as the delta disk, or differential disk, due to the fact that it stores all the delta changes that the desktop operating system requests from the parent VM. As mentioned before, the linked clone disk can grow to the maximum size, equal to the parent VM but, following best practice, you would never let this happen. Typically, you can expect the linked clone disk to only increase to a few hundred MBs. We will cover this in the Linked Clone processes section later.

The replica disk is set as read-only and is used as the primary disk. Any writes and/or block changes that are requested by the virtual desktop are written/read directly from the linked clone disk.

Tip

It is a recommended best practice to allocate tier-1 storage, such as local SSD drives, to host the replica, as all virtual desktops in the cluster will be referencing this single read-only VMDK file as their base image. Keeping it high in the stack improves performance, by reducing the overall storage IOPS required in a VDI workload. As we mentioned at the start of this section, storage costs are seen as being expensive for VDI. Linked Clones reduce the burden of storage capacity, but they do drive the requirement to derive a huge amount of IOPS from a single LUN.

Persistent disk or user data disk

The persistent disk feature of View Composer allows you to configure a separate disk that contains just the user data and user settings, and not the operating system. This allows any user data to be preserved when you update or make changes to the operating system disk, such as a recompose action.

Note

It's worth noting that the persistent disk is referenced by the VM name and not username, so bear this in mind if you want to attach the disk to another VM.

This disk is also used to store the user's profile. With this in mind, you need to size it accordingly, ensuring that it is large enough to store any user profile type data such as Virtual Desktop Assessments. This is another reason why it's a good idea to run a desktop assessment, as we will cover in Chapter 3, Design and Deployment Considerations, so that you can build up a picture of what your user desktop profiles and user data requirements look like.

Disposable disk

With the disposable disk option, Horizon View creates what is effectively a temporary disk that gets deleted every time the user powers off their virtual desktop machine.

If you think about how the Windows desktop operating system operates and the files it creates, there are several files that are used on a temporary basis. Files such as temporary Internet files or the Windows page file are two such examples. As these are only temporary files, why would you want to keep them? With Horizon View, these type of files are redirected to the disposable disk and then deleted when the VM is powered off.

Horizon View provides the option to have a disposable disk for each virtual desktop. This disposable disk is used to contain temporary files that will get deleted when the virtual desktop is powered off. These are files that you don't want to store on the main operating system disk as they would consume unnecessary disk space. For example, files on the disposable disk are things such as the pagefile, Windows system temporary files, and VMware log files.

Note that here, we are talking about temporary system files and not user files. A user's temporary files are still stored on the user data disk so that they can be preserved. Many applications use the Windows temp folder to store installation CAB files, which can be referenced post-installation. Having said that, you might want to delete the temporary user data to reduce the desktop image size, in which case you could ensure that the user's temporary files are directed to the disposable disk.

Internal disk

Finally, we have the internal disk. The internal disk is used to store important configuration information, such as the computer account password, which would be needed to join the virtual desktop machine back to the domain if you refreshed the Linked Clones. It is also used to store Sysprep and Quickprep configuration details. We will cover Quickprep in Chapter 6, Building and Optimizing the Desktop Operating System.

In terms of disk space, the internal disk is relatively small, averaging around 20 MB. By default, the user will not see this disk from their Windows Explorer, as it contains important configuration information that you wouldn't want them to delete.

The following diagram shows you an outline of the different disk types created:

Understanding how the linked clone process works

There are several complex steps performed by View Composer and View Manager and that occur when a user launches a virtual desktop session. So, what's the process to build a linked clone desktop, and what goes on behind the scenes? When a user logs into Horizon View and requests a desktop, View Manager, using vCenter and View Composer, will create a virtual desktop machine. This process is described in the following sections.

Creating and provisioning a new desktop

first step in the process is to create and provision the virtual desktop machine following the steps described here:

The first step in the process is to create and provision the virtual desktop machine following the steps described here: An entry for the virtual desktop machine is created in the Active Directory Application Mode (ADAM) database before it is put into provisioning mode.

1. The linked clone virtual desktop machine is created by View Composer.
2. A machine account is created in AD with a randomly generated password.
3. View Composer checks for a replica disk and creates one if one does not already exist.
4. A linked clone is created by the vCenter Server API call from View Composer.
5. An internal disk is created to store the configuration information and machine account password.

The virtual desktop machine has now been created and the next step is to customize it.

Customizing the desktop

Now that you have a newly created, linked clone virtual desktop machine, the next phase is to customize it.

The customization steps are as follows:

1. The virtual desktop machine is switched to customization mode.
2. The virtual desktop machine is customized by vCenter Server using the customizeVM_Task command and is joined to the domain with the information you entered in the View Manager console.
3. The linked clone virtual desktop is powered on.
4. The View Composer Agent on the linked clone virtual desktop machine starts up for the first time and joins the machine to the domain, using the NetJoinDomain command and the machine account password that was created on the internal disk.
5. The linked clone virtual desktop machine is now Sysprep'd. Once complete, View Composer tells View Agent that customization has finished, and View Agent tells View Manager that the customization process has finished.
6. The linked clone virtual desktop machine is powered off and a snapshot is taken.
7. The linked clone virtual desktop machine is marked as provisioned and is now available for use.

When a linked clone virtual desktop machine is powered on with the View Composer agent running, the agent tracks any changes that are made to the machine account password. Any changes will be updated and stored on the internal disk.

In many AD environments, the machine account password is changed periodically. If the View Composer Agent detects a password change, it updates the machine account password on the internal disk that was created with the linked clone.

This is important, as the linked clone virtual desktop machine is reverted to the snapshot taken after the customization during a refresh operation. For example, the agent will be able to reset the machine account password to the latest one.

The linked clone process is depicted in the following diagram:

Additional features and functions of Linked Clones

There are a number of other management functions that you can perform on a linked clone disk from View Composer; these are outlined in this section and are needed in order to deliver the ongoing management of the virtual desktop machines.

Recomposing a linked clone

Recomposing a linked clone virtual desktop machine or desktop pool allows you to perform updates to the operating system disk, such as updating the image with the latest patches, or software updates. You can only perform updates on the same version of an operating system, so you cannot use the recompose feature to migrate from one operating system to another, such as going from Windows 8.1 to Windows 10.

As we've covered in the What does View Composer Build? section, we have separate disks for items such as a user's data. These disks are not affected during a recompose operation, so all user-specific data on them is preserved.

When you initiate the recompose operation, View Composer essentially starts the linked clone building process over again; thus, a new operating system disk is created, which then gets customized, and a snapshot, such as the ones shown in the preceding sections, is taken.

Note

During the recompose operation, the MAC addresses of the network interface and the Windows SID are not preserved. There are some management tools and security-type solutions that might not work due to this change. However, the UUID will remain the same.

The recompose process is described in the following steps:

1. View Manager puts the linked clone into maintenance mode.
2. View Manager calls the View Composer resync API for the Linked Clones being recomposed, directing View Composer to use the new base image and the snapshot.
3. If there isn't a replica for the base image and snapshot yet, in the target datastore for the linked clone, View Composer creates the replica in the target datastore (unless a separate datastore is being used for replicas, in which case, a replica is created in the replica datastore).
4. View Composer destroys the current OS disk for the linked clone and creates a new OS disk linked to the new replica.
5. The rest of the recompose cycle is identical to the customization phase of the provisioning and customization cycles.

The following diagram shows a graphical representation of the recompose process. Before the process begins, the first thing you need to do is update your Gold Image (1) with the patch updates or new applications you want to deploy as the virtual desktops.

As described in the preceding steps, the snapshot is then taken (2) to create the new replica, Replica V2 (3). The existing OS disk is destroyed, but the User Data disk (4) is maintained during the recompose process:

Refreshing a linked clone

By carrying out a refresh of the linked clone virtual desktop, you are effectively reverting it to its initial state, when its original snapshot was taken after it had completed the customization phase. This process only applies to the operating system disk and no other disks are affected.

An example use case for refresh operations would be recomposing a non-persistent desktop two hours after logoff, to return it to its original state and make it available for the next user.

The refresh process performs the following tasks:

1. The linked clone virtual desktop is switched into maintenance mode.
2. View Manager reverts the linked clone virtual desktop to the snapshot taken after customization was completed: - vdm-initial-checkpoint.
3. The linked clone virtual desktop starts up, and View Composer Agent detects weather the machine account password needs to be updated. If not, and the password on the internal disk is newer than the one in the registry, the agent will update the machine account password using the one on the internal disk.

One of the reasons why you would perform a refresh operation is if the linked clone OS disk starts to become bloated. As we previously discussed, the OS-linked clone disk could grow to the full size of its parent image. This means it would be taking up more disk space than is really necessary, which kind of defeats the objective of Linked Clones. The refresh operation effectively resets the linked clone to a small delta between it and its parent image.

The following diagram shows a representation of the refresh operation:

The linked clone on the left-hand side of the diagram (1) has started to grow in size. Refreshing reverts it back to the snapshot as if it were a new virtual desktop, as shown on the right-hand side of the diagram (2).

Rebalancing operations with View Composer

The rebalance operation in View Composer is used to evenly distribute the linked clone virtual desktop machines across multiple datastores in your environment. You would perform this task in the event that one of your datastores was becoming full while others have ample free space. It might also help with the performance of that particular datastore. For example, if you had 10 virtual desktop machines in one datastore and only two in another, then running a rebalance operation would potentially even this out and leave you with six virtual desktop machines per datastore.

Note

You must use the View Administrator console to initiate the rebalance operation in View Composer. If you simply try to vMotion any of your virtual desktop machines, then View Composer will not be able to keep track of them.

On the other hand, if you have six virtual desktop machines on one datastore and seven on another, then it is highly likely that initiating a rebalance operation will have no effect, and no virtual desktop machines will be moved, as doing so has no benefit. A virtual desktop machine will only be moved to another datastore if the target datastore has significantly more spare capacity than the source.

The rebalance process is described in the following steps:

1. The linked clone is switched to maintenance mode.
2. Virtual machines to be moved are identified based on the free space in the available datastores.
3. The operating system disk and persistent disk are disconnected from the virtual desktop machine.
4. The detached operating system disk and persistent disk are moved to the target datastore.
5. The virtual desktop machine is moved to the target datastore.
6. The operating system disk and persistent disk are reconnected to the linked clone virtual desktop machine.
7. View Composer resynchronizes the linked clone virtual desktop machines.
8. View Composer checks for the replica disk in the datastore and creates one if one does not already exist, as per the provisioning steps covered earlier in this chapter.
9. As per the recompose operation, the operating system disk for the linked clone gets deleted and a new one is created and then customized.

The following diagram shows the rebalance operation:

In the next section, we are going to look at the method for creating virtual desktop machines with the Instant Clone feature.