Horizon View Composer and linked clones

The next component and feature that we are going to discuss is View Composer and what linked clones mean in a desktop environment. We will spend a bit more time concentrating on this subject, as it's a key part of delivering a successful and cost-effective VDI solution. It's also one of those things that often gets confused, so we need to give this subject the justice it deserves.

Let's start with why this is important. An all-too-often reason why a VDI project fails or doesn't even get started comes down to the perceived storage requirements, both from a capacity as well as cost perspective in deploying a storage platform that delivers the performance required for VDI. The reason we see this typically comes down to the fact that the VDI project is being approached in the same way as a physical desktop project would be.

This would mean that each user will get their own dedicated virtual desktop and the hard disk that comes with it, albeit now a virtual disk, but potentially of the same capacity as the desktop PC. It's just like picking the desktop PC up and creating an exact virtualized copy of it in the data center. When you start to scale this to hundreds or maybe even thousands of users, it just doesn't stack up.

We need a new approach to deploy storage in a virtual desktop environment, and that's where the linked clone technology comes into its own.

Linked clones are not only designed to reduce the amount of disk storage space required, but to also make the management and deployment of images to multiple virtual machines a centralized and much easier process.

Introducing the clone technology in Horizon View

Let's start off by defining what we mean by the term clone. A clone is an exact copy of an existing virtual desktop machine.

When you create your new clone, it becomes a separate, new virtual desktop machine in its own right, complete with its own unique identity. The cloning process is not a feature of Horizon View; it's actually a function of vSphere and vCenter and works in the same way as cloning server virtual machines. However, with a Horizon View deployment, there is another component to the solution, which is View Composer. View Composer is used to manage the desktop images and the cloning process for the virtual desktop machines. One of the key tasks it performs is the ability to maintain multiple clones.

In our environment, this virtual desktop machine or clone will act as the gold image and will be used as the template from which we can create any new virtual desktop machines.

There are two different types of clone. The first is a full clone and the second is a linked clone, and we will explain the two types in the following sections.

Full clones

A full clone, as the name suggests, is an exact, full-sized copy of your master image. When you create your clone, the result is a virtual desktop machine that is unique, has its own identity, and has no link to the original master image virtual machine from which it was cloned. It operates as a fully independent virtual desktop machine.

However, one thing to bear in mind is that as it is a full-sized copy, it will consume the same amount of storage as the original parent virtual machine and, therefore, will require greater storage capacity. As we discussed earlier on in this chapter, this might introduce cost implications for deploying VDI due to higher infrastructure costs.

However, before you completely write off the idea of using a full clone, there are actually some use cases that need this model in order to operate. One example is when using VMware Mirage to deliver base layers or application layers. This only works today with a full clone and dedicated virtual desktop machines.

Linked clones

The next method to deploy virtual desktop machines is using the linked clone technology. The idea behind linked clones is that they are based on snapshots and, as a result, will consume far less storage than a full clone.

As this is a key and very important feature of Horizon View, in this section, we will dive deeper into how linked clones work.

The first thing that happens when deploying a linked-clone virtual desktop machine is the creation of a delta disk. This is used by the virtual desktop machine to store the data differences between the newly created virtual desktop machine's own operating system and the operating system of the original gold image or parent virtual desktop machine.

Unlike creating a full-clone disk, the linked-clone disk is not a full copy of the parent image, and this is what defines it as a linked clone. The term linked clone refers to the fact that the linked-clone virtual desktop machine will always refer back to its parent in order to operate. It continues to read from a component called the replica disk. The replica disk is basically a copy of a snapshot of the original parent virtual desktop machine. The original parent virtual desktop machine is then powered off.

The linked clone disk has the potential to grow to the same size as the replica disk if allowed; however, you can set a limit on the size to which it can grow. Should it start to get close to that limit, 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 machine is created, the differences between the parent virtual machine and the newly created virtual desktop machine are extremely small, which means that you don't need the same amount of storage capacity that you would require for a full clone. This is how linked clones are far more space-efficient than their full clone cousins.

If we examine the underlying technology behind linked clones, they are more like snapshots than they are clones, but with one key difference; this is where View Composer comes in. View Composer allows you to have more than one active snapshot linked to the parent virtual machine disk, ideal for a desktop environment, as you will be creating multiple virtual desktop machines.

The best practice would be to deploy an environment with linked clones so as 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 we need to highlight while on the subject of storage is that rather than capacity, we are now talking about the storage performance of your entire VDI environment.

If we start with linked clones, all of your linked-clone virtual desktop machines are going to be reading from only one replica, and therefore, it's important to host the replica on a fast storage that can deliver the number of IOPS required. Depending on your desktop pool design, you will probably have more than one replica and typically more than one datastore. We will cover storage sizing in more detail in Chapter 3, Designing and Building a Horizon View 6.0 Infrastructure, apart from best practices on where to host the replica and the types of disk to use.

When it comes to storage acceleration technologies, it's useful to remember that Horizon View has its own integrated solution called the View Storage Accelerator (VSA) or Content Based Read Cache (CBRC). This feature allows you to allocate up to 2 GB of memory from the ESXi host server that is hosting your virtual desktop machines to be used as a cache that contains the most commonly read blocks.

In a VDI environment, we are talking about booting up a desktop operating system and, therefore, there will be a lot of duplication of required blocks. These can now be retrieved from the memory in order to accelerate the process.

In addition to the VMware integrated options, there are also a number of other third-party solutions that deliver storage acceleration and optimization technologies, such as Atlantis Computing and their ILIO products—Nutanix, Nimble, and Tintri, to name a few.

One thing that needs to be mentioned before you start looking at any of these technologies for VDI is to first look at your physical desktop assessment data and understand your current desktop storage performance and requirements. We will cover this in Chapter 3, Designing and Building a Horizon View 6.0 Infrastructure. You might find that you don't actually require additional storage solutions.

An alternative solution can be to use the View Composer Array Integration (VCAI), which allows the process of building linked clones to be offloaded to the storage array rather than taking CPU cycles from your ESXi host server.

Having now described the different types of clones you can create, the next section will take an in-depth look into how linked clones work.

How do linked clones work?

Before you start any form of cloning, the first thing you need to do is to create your virtual desktop machine that will be used as the parent virtual machine or gold master image. This should contain the operating system, core applications, and other settings. You will also need to install the Horizon View Agent components.

We will cover the desktop image-building process in more detail in Chapter 7, Configuring Horizon View to Deliver Virtual Desktops.

Now that we have built our image, we will use it to create any new subsequent virtual desktop machines.

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

Once you have created your Gold Image (1) or—as it's referred to in VMware terms—the Parent Image, you take a snapshot (2). When you create your desktop pool, this snapshot is selected and becomes the Replica (3) and will be set to be read-only. Each virtual desktop machine will be linked back to this replica, and hence the term linked clone.

Tip

Try not to create too many snapshots for your Parent VM. Just have one or no more than a handful, otherwise this could impact the performance of your desktops and make management a bit harder, determining the snapshots.

What does View Composer build?

During the virtual desktop machine build process and once the replica disk has been created, View Composer creates a number of other virtual disks as well as the linked clone (OS disk) itself. We will explain these different disks in the following sections.

The linked-clone disk

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

As we have already discussed, 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 machines operating system. These block changes are stored in the linked-clone disk, and this is why this disk is sometimes referred to as the delta disk or differential disk. This is due to the fact that it stores all the delta changes that the desktop operating system requests from the replica disk. The linked-clone disk can only grow to the maximum size of its parent; however, you should never let that happen. Typically, it will only grow to a couple of hundred MBs. We will cover this in the The linked-clone process 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 will be using a single read-only VMDK file as their base image.

The 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 separate from the operating system. This allows any user data to be preserved when you update or make changes to the operating system disk, as we will see when we cover some of the other linked clones features.

This disk is also used to store the user profiles. You need to size this disk accordingly in order to ensure that it is large enough to store the user profiles, especially when using roaming profiles. This is another reason why it's a good idea to run a desktop assessment so that you can build a picture of your desktop user environment, in order to understand what users are doing and what they require.

The disposable disk

The disposable disk option, as the name suggests, allows Horizon View to create a temporary disk that is deleted when the user powers off their virtual desktop machine.

If you think about how the Windows operating system works and the files that it creates, there are several files that are only required on a temporary basis—files such as temporary Internet files or the Windows pagefile, for example. As these are only temporary files, why would you want to keep them and take up storage space unnecessarily?

Horizon View provides the option to have a disposable disk for each virtual desktop that can be used to store these temporary files, which will be deleted on power off.

One thing to point out here is that 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 are preserved. Having said that, you might want to delete the temporary user data, in which case, you can redirect the temporary user files to the disposable disk.

The 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 required to join the virtual desktop machine to the domain if you performed a refresh operation. It is also used to store Sysprep and QuickPrep configuration details. We will cover what QuickPrep is in Chapter 7, Configuring Horizon View to Deliver Virtual Desktops.

In terms of disk space, the internal disk is relatively small at only 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:

The linked-clone process

So, now that we have covered what View Composer does, let's look at how the process for building a linked clone virtual desktop machine works and what goes on under the hood.

When a user logs into Horizon View and requests a virtual desktop machine, which is View Manager, in conjunction with the vCenter Server and View Composer, will start the process to create the virtual desktop machine. There are three key stages to this process:

• Create
• Build
• Customize

This process is detailed in the following diagram:

Now that we have covered the build process for linked clones, there are a number of tasks that we can perform in order to manage and update the linked clone and the virtual desktop image.

The linked-clone features and functions

There are a number of functions that you can perform on linked clones in order to deliver the ongoing management of the virtual desktop machines.

The recompose operation

Recomposing a linked-clone virtual desktop machine allows you to perform updates to the operating system disk, such as updating the image with the latest patches or software updates.

Note

You can only update the same version of an operating system. You cannot use the recompose feature to migrate from one operating system to another, for example, migrating from Windows XP to Windows 7.

As we covered in the previous section of this chapter, we have separate disks for things such as user data. These disks are not affected during a recompose operation, which means that 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, so a new operating system disk is created, which then gets customized, and a snapshot is taken, as we previously described.

Note

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

Before you start the recompose process, the first thing you need to do is update your parent master image (1) with the patch updates or new applications that you want to deploy.

The next step is to take a snapshot (2) in order to create the new replica (3). The existing operating system disk is destroyed. The user data disk (4) is maintained during the recompose process.

This is shown in the following diagram with the old version on the left-hand side and the newly recomposed linked clone shown on the right-hand side of the diagram:

The refresh operation

By initiating a refresh of the linked-clone virtual desktop machine, you are effectively carrying out a factory restore, reverting it back to how it was on day one, and its original snapshot that was taken after it had completed the customization phase.

This refresh operation only applies to the operating system disk, and none of the other disks are affected.

So, why would you need to refresh the linked-clone virtual desktop machine? One of the main reasons why you would perform this operation is because the operating system disk starts to become full. We have already discussed the fact that the operating system disk can grow to be the full size of its parent image.

This is also good for VDI environments that are in public areas so that nothing gets left behind on the virtual desktop machine when the user logs out. The next user gets a completely fresh machine.

This means that it would be taking up more disk space than is really necessary, which kind of defeats the objective of having linked clones in the first place. By performing a refresh operation and essentially resetting the linked clone back to the original snapshot, it will revert to having only a small delta between itself and its parent image, and therefore, takes up less storage space.

The following diagram shows you a representation of the refresh operation:

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

The rebalance operation

The rebalance operation is used to evenly distribute the linked-clone virtual desktop machines across the multiple datastores you might have in your Horizon View environment. You would perform a rebalance if one of your datastores was nearing capacity and others had ample free space.

This 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, running a rebalance operation would potentially even this out, leaving you with six virtual desktop machines per datastore. The following diagram describes the rebalance operation:

Note

You must use the View Administrator management console to initiate the rebalance operation in View Composer. We will cover the View Administrator in more detail in Chapter 5, A Guided Tour of the Horizon View Administrator Console. If you simply try to vMotion any of your virtual desktop machines, View Composer will not be able to keep track of them.

On the other hand, if you had six virtual desktop machines on one datastore and seven on another, it is highly likely that initiating a rebalance operation will have no effect and no virtual desktop machines will be moved.

A virtual desktop machine will only be moved to another datastore if the target datastore has significantly more spare capacity than the source.

Now we have covered linked clones in some detail. In the next section, we are going to cover some of the other core components and features of Horizon View.