VMware Horizon View provides the capability to provision two different desktop types: Horizon View Composer linked clones and full clones. Before we discuss the differences between the two, let's outline what about them is the same:
From the perspective of the end user, a linked clone and full clone desktop appear the same
The master image is often prepared using the same tuning techniques
Deciding on which clone type to use is not always a simple task. While linked clones have certain advantages that we will review in this recipe, we should adopt different techniques of performing desktop maintenance in order to maintain that advantage. Additionally, using linked clones might require selecting software optimized for virtual environments, such as the antivirus platform, vShield Endpoint.
In this section, we will review the characteristics of the different Horizon View desktop types and user assignment methodologies and how each of them impacts our View environment as a whole.
Full clone Horizon View desktops are created using a master image that has been converted into a vSphere template. VMware Horizon View clones this template to create a full clone desktop; from then on, this desktop is managed independently from all other desktops and the template itself. Apart from the fact that it was created from a vSphere template, the full clone desktop is very comparable to a physical desktop from a management standpoint. As a result, the full clone desktop is often managed using the same techniques used with a physical desktop.
Assuming that the infrastructure has adequate capacity to host the full clone desktops, the familiarity with their management might be enough of a reason to choose them over linked clone desktops. Additionally, with advancements in the storage technology—specifically, real-time deduplication—organizations can deploy full clone desktops that require very little physical storage when measured on a per desktop basis.
The following table shows us the results obtained when testing the actual per-desktop storage required for 2,500 Horizon View desktops when deployed on a storage array that includes the deduplication functionality. In this example, the master image was utilizing approximately 13 GB of the 24 GB virtual hard disk. To determine the physical storage required for each desktop, the amount of actual storage being used on the array was measured immediately after the desktop deployment, and then divided by the number of desktops deployed (2,500). The measurements were taken immediately after the desktops were deployed.
|
Desktop type |
Total physical storage used for 2,500 desktops |
Average per desktop storage used |
|---|---|---|
|
Linked clone desktop |
139.16 GB |
57 MB |
|
Full clone desktop |
480.96 GB |
197 MB |
While the full clone desktop still used over three times the amount of physical storage as the linked clone desktop, the amount of storage required for the full clone desktops was reduced by over 95 percent due to the deduplication capabilities of the array. To deploy this number of desktops using an array that does not have deduplication capabilities would require approximately 32 TB of storage capacity as a minimum—the minimum providing no room for any growth beyond the 13 GB of disk space currently in use. This does not even take into account the IOPS required, a factor that influences the storage design as much as if not more, than, just the amount of capacity required.
If full clone desktops are a definite requirement, technologies such as arrays capable of deduplication or storage acceleration platforms might be required in order to meet the virtual desktop capacity and performance requirements while keeping storage costs reasonable.
VMware Horizon View Composer linked clone desktops are also provisioned from a master image. While a full clone desktop is created from a vSphere template, a linked clone requires a master image that is in the standard vSphere virtual machine format.
A linked clone desktop has a number of advantages over a full clone desktop. Some of these advantages include the following:
Linked clone desktops share the same parent virtual disk; therefore, the amount of disk space they require is greatly reduced. This relationship is shown in the following image:
Linked clone desktops can be recomposed, which replaces their replica disk with a new version that has software updates or other changes applied. Rather than applying updates to individual desktops, we should update the master image, and then use a Recompose operation to update the replica disks and apply these changes to the entire desktop pool.
Linked clone desktops can be refreshed, which returns them to the same condition they were in when initially deployed. When refreshed, any changes to the desktop OS disk that were made after the desktop was deployed are discarded. If a user-persistent data disk was used, the data on that disk will be retained.
A linked clone desktop pool can be rebalanced, which redistributes the linked clone storage evenly across datastores. The individual linked clone disk utilization will vary over time, leading to an imbalance in storage utilization across all the datastores. A Rebalance operation addresses this by relocating the linked clone storage.
Due to how a linked clone desktop works, there are specific considerations when it comes to client-based utilities and desktop management. If we were to treat linked clones like traditional physical desktops, we might find that the benefits of linked clone desktops begin to disappear. Some examples of this include the following:
If we were to apply software patches to linked clones individually rather than updating the master image and then performing a Recompose operation, the linked clone virtual hard disks would grow significantly. This eliminates the storage efficiencies that are one of the primary reasons for choosing linked clones. Unless it is an emergency that requires immediate action, software patches should be applied only to the master image and rolled out to the desktops using a Recompose operation.
Traditional client-based antivirus platforms require frequent virus pattern updates that can dramatically increase the linked clone storage utilization. A refresh might not address this issue, as the desktop will be forced to update the pattern files again when the refresh completes. Products such as vShield Endpoint address this issue by scanning for viruses at the hypervisor level rather than within the virtual machine. vShield Endpoint also provides the benefit of reducing desktop resource requirements, as traditional client-based AV software is not required.
The Recompose, Refresh, and Rebalance operations all change the state of the linked clone virtual desktop, which can affect utilities such as indexing programs. If these operations lead to resource-intensive operations, such as a file index, every time they occur, it might be that they need to be disabled or their behavior altered. Tuning the master image can help alleviate this problem.
Whenever possible, we should approach managing linked clone desktops from the master image, as this helps preserve their benefits and minimize the amount of administrative effort required. Additionally, we should examine each of our client-based management tools and utilities to see whether there are versions optimized for virtual desktop use. These two recommendations can dramatically reduce the per-desktop resources required, which enables more desktops to run on the same infrastructure.
Note
Many storage vendors provide the ability to create linked clones using the native features of their array. In many cases, these desktops can be provisioned more rapidly than Horizon View linked clones, enabling organizations to quickly deploy desktops that will still leverage Horizon View as a connection broker. While these desktops can be managed using Horizon View, since it did not create them, features such as refresh or recompose will not be available.
Consult the vendor documentation for information on what maintenance operations can be performed once the virtual desktops have been deployed using their native array features.
VMware Horizon View supports two options for assigning users to desktops: floating and dedicated user assignment. This section will define each of these options and discuss the optimal scenarios for each. Some of the terms used in this section, such as persistent and nonpersistent desktops, are defined in greater detail in the Deciding between persistent and nonpersistent desktops section.
Dedicated user assignment is when a Horizon View desktop is assigned to a single user. This user is the only one with permission to use that desktop, although the Horizon View administrator can alter the assignment, if required.
Dedicated user assignments are most commonly used in environments that use persistent desktops, as these desktops maintain their state as well as the user profile data between user sessions. Despite this, Horizon View also allows us to use dedicated assignment with nonpersistent linked clone desktops, although tools such as View Persona Management would be required to preserve the user profile data.
Horizon View can assign the desktops automatically when the user first logs in, or we can manually assign them ourselves using the View Manager Admin console.
Floating user assignment desktops have no owner; with floating user assignments, any desktops not currently in use in a desktop pool are accessible to anyone who has been granted access to the pool. A floating assignment is most common in environments that use nonpersistent desktops, as these desktops do not retain any unique personalization in between user sessions unless the pool is using linked clone desktops with user-persistent data disks.
One of the primary advantages of the floating user assignment is that it allows for the possibility of deploying only enough desktops to meet our maximum number of concurrent Horizon View clients, whereas, with dedicated user assignment, we are required to deploy a desktop for every Horizon View client. For organizations that maintain staff on multiple shifts, the floating user assignment might reduce the number of desktops required, as the number of concurrent Horizon View client sessions is likely to be much less than the total number of employees. Additionally, when combined with nonpersistent desktops, each worker will receive a freshly deployed desktop every time they log in, free of any changes that impact its functionality.
VMware Horizon View provides organizations with the ability to manage desktop persistence automatically, without having to install additional software inside the base image. This section will discuss what differs between the two desktop persistence models. It is important to note that Horizon View does not refer to a desktop as persistent or nonpersistent; in using this term, we are referring to the act of refreshing a linked clone desktop or deleting and recreating a linked clone or full clone desktop after the user has ended their session.
Persistent desktops function just as the name indicates; they keep the contents of their virtual hard disks intact in between user logon sessions, reboots, or other common operations. As with full clone desktops, managing persistent desktops will be more familiar to the existing desktop administrators within an organization, as they retain their settings from one user session to the next.
For organizations that do not wish to use Horizon View Persona Management or any third-party tools to manage the user persona data, persistent desktops are the ideal selection when there is a need to maintain user files and settings between desktop sessions.
VMware Horizon View supports the following scenarios when configuring nonpersistent desktops; they are selected by navigating to the Add Pool | Pool Settings page within the Horizon View Manager Admin console. Screenshots showing the configuration options for each scenario are also shown:
The linked clone dedicated assignment desktop: Refresh upon logoff at the time indicated.
The linked clone floating assignment desktop: Delete and redeploy or refresh immediately upon logoff.
The full clone dedicated assignment desktop: Not supported as a nonpersistent desktop.
The full clone floating assignment desktop: Delete and redeploy immediately upon logoff.
Whether we are refreshing or deleting and redeploying the desktop upon logoff, the impact is the same. Any changes made to the virtual desktop, with the exception of the optional linked clone user persistent data disk, are discarded and the desktop is returned to a just-deployed state.
Note
The benefit of deleting the desktop upon logoff is that all of the space it was using is immediately freed up, whereas a refreshed desktop will not free up all of the space that was in use. If controlling the storage capacity utilization is a key requirement, deleting the desktop upon logoff might be the preferred setting.
The following is a list of items that we must consider when determining whether or not to use nonpersistent desktops:
If required, the user persona data must be retained using persistent data disks with linked clone desktops or with persona management tools such as VMware Horizon View Persona Management or AppSense Environment Manager.
If user-installed applications are required, consider virtualizing them with ThinApp and delivering them using Horizon View or VMware Horizon Workspace. Alternatively, consider streaming them using Microsoft Windows RDSH application remoting.
Application caches such as Outlook should be disabled even if we are using persona management tools, as caches will need to be rebuilt every time the user logs in. This action can require significant resources.
Programs such as client-based antivirus and file indexing will need to be updated every time the desktop is redeployed, which might require significant resources. In the case of AV, alternative solutions optimized for virtual desktops might be preferred; for indexing, either disable the feature or alter the setting to reduce its impact on the desktop.
If large numbers of users were to log off at once, the spike in IO associated with a desktop refresh or delete and redeploy operations might impact the storage array performance. The impact of this will vary from one storage array to the next, and this should be considered during the Horizon View design phase.
The frequent erasure of the desktop data might require that the
SCSI UNMAPcommand be run to free up space on the storage array. The impact of this should be considered during the Horizon View design phase.
While there are some risks to be aware of, the combination of nonpersistent desktops and the floating user assignment is one of the most efficient means of providing EUC, as it can minimize the number of desktops required while providing desktops that are always in a just-deployed state.
There are two schools of thought when it comes to optimizing Windows for our Horizon View environment. One opinion is that the fewer resources Windows requires, the more desktops we can host on a given vSphere server. Additionally, we have probably made the desktop perform better, as there are no nonessential services running. We only need to talk to our desktop support team in order to learn the different tips and tricks they perform to make Windows run faster or with fewer errors.
The second school of thought says that you shouldn't have to optimize Windows. By doing this, you are degrading the Windows experience and introducing barriers to the adoption of your Horizon View implementation. File indexing is one example where this could be true, as some users might depend on the Windows search feature. Many other examples are less important, such as the various transparency features that Windows uses to make the user interface appear more attractive. Rather than blindly disabling every lesser-used feature we find, research should be done to identify how we can tune Windows without impacting the workflows our users depend on to perform their duties.
Even if you are fortunate enough to have the best of the best when it comes to storage technology, optimizing Windows also reduces virtual desktop vCPU and RAM needs, which can reduce our server requirements. Since Horizon View projects often deal with hundreds—if not thousands—of desktops, every reduction in virtual desktop resources requirements that you make is multiplied many times over.