In this chapter, we will cover the following recipes:
Identifying why we need VMware Horizon with View
Understanding the risks of end user computing
Understanding how our desktop configuration impacts our design
Determining our Horizon View desktop infrastructure requirements
Analyzing our Horizon with View environment
The foundation of any VMware Horizon with View implementation lies in a solid understanding of the goals that the project seeks to achieve. These goals are important, as they provide with us a metric for determining whether or not the project is delivering the capabilities we require. Additionally, many of these goals can influence the project design process as well as the resources required, which is why it is important to identify them early on in the project when it is easier to make changes.
This chapter discusses a number of key considerations that will influence the design, implementation, and assessment of a VMware Horizon with View infrastructure.
This recipe will outline a number of different reasons why organizations might opt to implement a virtual desktop solution using VMware Horizon with View.
VMware Horizon with View can provide us with a number of different capabilities that can complement, extend, or replace our existing end user computing (EUC) platforms. Identifying which of these apply in our organization is important, as they can influence all phases of our project, starting with the design and ending with the rollout itself.
Migrating to a newer version of Microsoft Windows is a difficult project for reasons that include:
Hardware compatibility or capability issues that might require hardware upgrade or replacement
Application compatibility testing
Application support for a newer operating system (OS)
User training for the new OS
User downtime
User data and desktop configuration migration
Labor costs
What makes things even more difficult is if we are running an unsupported OS such as Windows XP and require official support from Microsoft. In some cases, we are paying at least $200 per desktop for this service (http://software.dell.com/products/changebase/calculate.aspx).
While VMware Horizon with View and its VMware ThinApp (http://www.vmware.com/products/thinapp/) application virtualization platform cannot by themselves solve issues related to the support of legacy applications or operating systems, they can provide organizations with a way to improve their end user computing environment with little or no changes to their existing legacy desktops. Horizon View provides users with a more relaxed desktop migration than is typically possible with a traditional reimage or replacement of an existing physical computer, where rolling back the migration is difficult or, sometimes, impossible. When migrating the users to Horizon View virtual desktops, any existing physical desktops need not be immediately removed or changed, usually enabling a less disruptive upgrade with the potential to move back to the physical desktop, if required.
Providing a more relaxed OS migration to the end users is not the only benefit of using Horizon View; the information technology (IT) staff will also benefit. While tools such as VMware Horizon Mirage (http://www.vmware.com/products/horizon-mirage) and Microsoft System Center Configuration Manager (http://www.microsoft.com/en-us/server-cloud/products/system-center-2012-r2-configuration-manager) can assist organizations with OS and software upgrades on their existing physical machines, if those machines lack the resources required, the hardware itself will still need replacement. Additionally, tools such as these often carry additional costs that must be factored into the cost of the migration.
Note
Implementing Horizon View will not necessarily eliminate the need for tools to assist with our desktop migration. If we determine that these tools will provide some benefit, we must research whether the costs and resource requirements outweigh whatever that benefit that might be.
While many organizations might select to replace their existing physical computers with a thin or zero client tailored for use specifically with Horizon View or to rebuild the existing computer with just an OS and the Horizon View client software, there is no immediate need to do either of these unless we wish to prevent the user from continuing to use any existing applications on their physical desktop.
VMware Horizon View 6 introduced the capability to stream individual applications directly to the Horizon View client, a feature that is also known as application remoting. Using a Microsoft Windows Remote Desktop Session Host (RDSH) server, Horizon View can now deliver access to individual applications in addition to traditional virtual desktops.
VMware Horizon View 6 also offers the capability to directly deliver other applications, including those packaged with VMware ThinApp, streamed using Citrix XenApp (http://www.citrix.com/products/xenapp/overview.html) and even Web or SaaS applications using the included Horizon Workspace Portal (http://www.vmware.com/products/workspace-portal).
Application remoting enables organizations to distill the end user computing experience down to the smallest unit possible: individual applications. One scenario where application remoting can provide the most benefit is when a user uses only one or two applications; rather than providing them with their own virtual desktop, it might be more efficient to have them stream just these applications from a shared RDSH server.
Additionally, VMware created its own protocol provider for the RDSH servers so that application remoting clients can leverage the same PC over Internet Protocol (PCoIP) protocol used with virtual desktops; this is one of the key differentiating features of the Horizon View platform, offering high levels of performance using the minimum bandwidth required.
Chapter 11, Implementing Application Streaming Using Windows Remote Desktop Services, provides us with an overview on how to use VMware Horizon View and Microsoft Windows RDSH servers to enable the Microsoft Windows RDSH application remoting and streamed ThinApp applications.
VMware Horizon View supports the VMware Virtual SAN (VSAN) hypervisor-converged storage platform. VMware Virtual SAN provides organizations that do not wish to invest in a traditional shared storage array for their Horizon View desktops with an additional option that can meet the capacity and performance needs that the desktops require.
With VMware VSAN, organizations need to only deploy vSphere servers that include additional dedicated local storage. This storage can be all flash disks or a combination of flash and spinning disks. The combination of flash and spinning disks, along with the automated data-tiering capabilities or VSAN, allows it to meet both the performance and capacity needs of almost any Horizon View environment. VMware VSAN can also be used to provide the storage required for the Horizon View infrastructure servers, if desired.
One advantage of using VMware VSAN is that it reduces the complexity of a VMware Horizon View deployment by reducing the overall number of infrastructure components required while also simplifying the management, as VSAN is managed using the VMware vSphere Web Client.
Chapter 10, Implementing VMware Virtual SAN for Horizon View, provides us with an overview on how to use VMware VSAN to provide storage for Horizon View.
For many organizations, desktop mobility means providing users with a laptop and a virtual private network (VPN) connection that they can use to access company resources remotely. While this method of office mobility has worked, and continues to work, for many, managing these remote clients and their data can be challenging if organizations lack tools that are specifically designed to manage clients who are infrequently connected to an organization's private network. Organizations that cannot address these challenges might find themselves exposed to significant risks when it comes to the security of these remote physical endpoints, whether keeping them up-to-date with critical security patches or protecting and backing their data.
VMware Horizon View provides organizations with a number of different ways to rethink how they provide users with a mobile office:
A VMware Horizon View Connection Server deployed as a specialized gateway, commonly referred to as a View Security Server, can be deployed in a perimeter network, also known as the demilitarized zone (DMZ), in order to provide secure access to Horizon View without needing to deploy a VPN. To further secure the user authentication process, Horizon View supports multifactor authentication platforms, such as RSA SecurID and others, that are supported by RADIUS, which is a network protocol that is most commonly used for authentication.
When paired with VMware Horizon Workspace and VMware AirWatch Secure Content Locker (http://www.air-watch.com/solutions/mobile-content-management), Horizon View clients gain access to a single portal that they can use to access desktops, streamed applications, applications packaged using ThinApp, and user data stored in AirWatch Secure Content Locker. AirWatch Secure Content Locker is a separate VMware product that integrates with the VMware Horizon Workspace portal and mobile devices in order to provide access to secure file storage.
Using Blast Adaptive UX, a HTML5-compliant web browser is all that is required for Horizon View clients to access their desktops and applications. The software-based Horizon View client is also available for remote users, enabling greater flexibility.
For organizations that wish to leverage VMware Horizon View in order to manage desktop images deployed to traditional physical desktops—beginning with Horizon View 6—you can manage images used by physical machines running VMware Horizon Mirage or as virtual machines running on VMware Fusion Professional (http://www.vmware.com/products/fusion-professional) or VMware Player Plus (http://www.vmware.com/products/player). Chapter 9, Using VMware Mirage with Horizon View, provides us with an overview on how to use VMware Horizon Mirage with Horizon View full clone desktops.
In summary, VMware Horizon View enables organizations to offer new virtual desktop mobility offerings without the need to provide additional mobile devices for remote access; train users on how to properly protect their mobile devices and their data; or explain to users how their experience differs when they are logging in remotely.
Virtual desktops offer many potential benefits for enhancing end user computing security; however, but similar to traditional desktops, organizations must commit to the changes required for them to be effective. With the exception of remote desktops managed by VMware Horizon Mirage, Horizon View desktops are hosted in a data center where it is assumed that they will be more secure than traditional physical computers. In reality, with virtual desktops, there is no longer any physical hardware to steal, but securing the desktop OS and its applications is the same regardless of where it is located. The fact that a desktop is virtual does not automatically prevent the flow of data from that desktop to elsewhere, unless an organization takes steps to prevent it from using methods such as Active Directory (AD) group policies or various software tools.
Note
Simply migrating desktops to VMware Horizon View or managing them using VMware Horizon Mirage does not mean that we do not need data loss prevention (DLP) platforms or organizational policies that are designed to protect our data. Horizon View and Horizon Mirage merely provide us with a tool that we can use to enhance or extend our data-protection goals.
VMware Horizon View supports a variety of options for controlling how USB devices access virtual desktops. The devices can be controlled based on a specific device (such as a USB Ethernet adapter), the type of device (such as the storage device), or even on the vendor product model. This feature is controlled using AD group policies and enables advanced control over how the desktop can be accessed.
The most common benefit of using Horizon View to provide virtual desktops is that their data remains in the data center, where we can protect it using whatever data center capabilities or protections are at our disposal. This includes tools such as vSphere-based backups of virtual desktop data, common storage array features such as snapshots and Redundant Array of Inexpensive Disk (RAID) protection, and even VMware vShield Endpoint, which provides antivirus (AV) protection at the hypervisor level rather than within each individual desktop.
Note
VMware vShield also requires third-party scanning plugins to provide antivirus scanning capabilities. These plugins are currently offered by a number of different vendors including Trend Micro (http://www.trendmicro.com/us/enterprise/cloud-solutions/deep-security/) and McAfee (http://www.mcafee.com/us/products/move-anti-virus.aspx).
Each of these capabilities provides a more efficient means of protecting virtual desktops and their content than is possible with physical desktops. If physical desktops are still required, VMware Horizon Mirage can be used to provide similar levels of protection, namely the desktop contents and configuration.
Note
VMware Horizon Mirage is discussed in greater detail in Chapter 9, Using VMware Mirage with Horizon View, but primarily, within the context of using it with Horizon View full clone virtual desktops. Consult the VMware Mirage website (http://www.vmware.com/products/horizon-mirage) for information on how Mirage can be used with physical desktops.
One benefit of using virtual desktops is that they can dramatically change how an organization provides support to its end users. In scenarios where we are replacing our existing physical desktops with dedicated devices whose only purpose is to act as a client for Horizon View, with the exception of hardware failure, there is less of a need to provide support in person. The following is a list of key features and characteristics of VMware Horizon View:
Horizon View application remoting using Microsoft Windows RDSH servers enables organizations to provide access to critical applications directly rather than deploying a physical or virtual desktop. Since the RDSH servers support multiple concurrent users, while a virtual desktop can only support one, fewer infrastructure resources might be needed.
The VMware ThinApp application virtualization platform enables us to package and distribute applications independent of the desktop operating system. Horizon View and Horizon Workspace can also be used to provide access to ThinApp applications without the need to install them on each desktop.
VMware Horizon View Persona Management enables us to centrally manage and protect the user profile data while delivering a personalized desktop experience regardless of where our users log in.
Linked clone Horizon View desktops require far less storage capacity than physical or full clone desktops and can also be rapidly refreshed, thus discarding any changes that were made since the desktop was deployed or last recomposed.
These features are just a partial list of what Horizon View can offer, yet they alone offer us the opportunity to rethink how support is provided. With Horizon View, we don't have to expend resources that support individual desktops, as everything that makes these desktops unique can be abstracted or stored elsewhere. If everything that makes a desktop unique can be maintained in another location, such as custom applications and user persona data, our IT support staff can simply discard the problematic machine and provide the user with a fresh desktop free of any underlying issues.
With Horizon View, we can greatly reduce the support our desktops require and focus more on supporting the users. With linked clone desktops, when desktops need to be changed, these changes are applied to the desktop master image and rolled out to all users at our convenience.
Note
In this section, we referred to linked clone desktops that share a common master disk and write any changes to a dedicated delta disk. If we choose to use full clone desktops, we cannot use features such as a Horizon View desktop Refresh or Recompose. Due to this, full clone desktops are often managed using the same techniques as physical desktops; this also includes VMware Horizon Mirage.
The concept of having users use their own devices to access company resources is becoming more common as organizations move towards new ways of providing users access to their applications and data. With Horizon View, users can use their own endpoint as a client to access desktops, applications, or data hosted by Horizon View or other components of the VMware Horizon Suite.
Bring Your Own Device (BYOD) does not necessarily mean that users are spending their own money to purchase these devices. In some organizations, users are provided with a stipend to purchase whatever device they wish, preferably with some guidance from their IT department in terms of required client features or specifications. In some cases, by providing users with access to a wider variety of devices, they are more likely to end up with a device they are comfortable with, which might help make them more productive.
The concept of BYOD is most commonly seen with smartphones where employees use their own mobile device to access e-mail and other company resources, in many cases without being required to or without reimbursement.
This recipe will discuss key topics that are important to keep in mind throughout our virtual desktop design and implementation. Each section represents a potential risk that can influence the perceived or realized success of our Horizon View project.
Each of the topics discussed in this section has the potential to influence our design by extending the success or failure of our Horizon View environment. Due to the varying end user computing requirements from one organization to the next, this list represents just a starting point to assess what our organization must keep in mind when implementing virtual desktops.
In many cases, the act of deploying virtual desktops will not be an organization's monetary concern. Additionally, if we continue to manage and support virtual desktops just like physical desktops, our virtual desktops might well end up costing us more. The following is a partial list of potential expenses that must be considered when determining whether cost savings are possible with virtual desktops:
The cost of support, electricity, and maintenance of using existing physical desktops as Horizon View clients rather than implementing purpose-built clients that have a much smaller management footprint
The cost required to upgrade our data center's local area network (LAN) and our company's wide area network (WAN) to provide sufficient bandwidth for Horizon View clients
The additional amount of server random access memory (RAM) required to host virtual desktops that use traditional client-based firewalls and antivirus platforms rather than deploying platforms optimized for virtual desktop computing
The cost of virtualizing desktops that require greater than average amounts of central processing unit (CPU) or RAM resources
For organizations that do not regularly refresh or recompose their linked-clone-based virtual desktops, how that can impact the storage utilization over time
For organizations that lack storage platforms that include deduplication capabilities, what storage resources are required to use full clone Horizon View desktops
The labor costs when IT support personnel continue to spend time troubleshooting a linked clone desktop, rather than refreshing it to a just-deployed state and a known configuration
The cost of deploying one virtual desktop for every user, rather than determining the actual maximum number of concurrent desktops needed overall
In most of these cases, ignoring these items will not make our virtual desktop environment a failure; however, the more we ignore them, the more difficult it will be for us to lower per-desktop support costs. Depending on what it costs to implement virtual desktops in our own organization, it might be that, even if we address all of these points, we still won't save money. This is why reducing costs should not be the first priority, as it cannot be guaranteed in all environments.
When designing our virtual desktop environment, we must consider everything involved with providing, managing, and supporting the desktops we have today. As mentioned earlier, if we operate and support our virtual desktops as we do for our physical desktops, we will make it very difficult to realize any cost savings. The topics we covered in this section are just an example of the types of things we must be conscious of if our goal is to attempt to reduce our costs associated with providing end user computing resources.
A lack of understanding as to how our users interact with their desktops can have a significant impact on the success of our Horizon View deployment. It is about more than failing to appropriately size our virtual desktop infrastructure; it has to do with understanding what our users need in order to perform their duties. The following are just some examples we must consider when deciding who among our users is a suitable candidate for conversion to Horizon View virtual desktops.
There will always be users whose workstations are not ideal candidates for conversion to a virtual desktop. This can include—but is not restricted to—workloads that require a significant amount of CPU or RAM resources; have a large number of peripherals; use applications unsuitable for virtualization or streaming that are also not common to other desktop users; use a multimonitor configuration that requires an unacceptable amount of Horizon View Client bandwidth; run graphics-intense applications such as Computer Aided Design (CAD) platforms; or have unique or resource-intensive storage requirements.
While CPU and RAM requirements will not prevent a desktop from being virtualized in all cases, when they are combined with any one of the other factors mentioned, it might be that the desktop is unsuitable to be deployed as a virtual desktop.
Note
Beginning with Version 6, VMware Horizon View supports Virtual Shared Graphics Acceleration (vSGA), which allows the virtual desktops to share a dedicated discrete card installed in each vSphere host (http://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-graphics-acceleration-deployment.pdf). Support for vSGA might enable Horizon View to deliver the graphics performance that certain desktops require.
Does all of our infrastructure support Horizon View? This includes telephone systems, video conferencing platforms, uncommon peripherals, and so on. It is crucial that organizations consult their vendors in order to ensure that their solutions are compatible with the proposed Horizon View environment.
If we ask people to trade in laptops that never leave the office for a stationary Horizon View client without first researching how these laptops are used, we might not realize that they move around within the office itself. In a BYOD environment, this might not be an issue, as users will select whatever device best accommodates their workflow; if, however, our users have to use the devices provided to them, then there is a potential for problems. Depending on the needs of our users, it might be possible to solve this problem with tablets or other devices that are less costly than laptops but can still provide mobility within the office.
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.
Determining the resources required to host the Horizon View infrastructure is straightforward for the Horizon View and vCenter Servers but far more involved for vSphere servers that will host the virtual desktops. This recipe will focus primarily on determining virtual desktop resource requirements.
The infrastructure resource requirements for VMware Horizon View can be broken down into two primary sections:
Resources required by the virtual desktop itself, including compute, networking, and storage. This can vary based on the user workload, applications being used, and any other factors that distinguish one user from the next.
The network bandwidth required for each Horizon View client connection; this will vary based on the workload profile of each client.
In this recipe, we review methods for measuring or determining what infrastructure resources we need for each of these items.
One of the preferred methods to determine virtual desktop resource requirements is to use a commercial tool such as Liquidware Labs Stratusphere FIT (http://www.liquidwarelabs.com/products/stratusphere-fit). Stratusphere FIT can generate detailed reports concerning the compute resources required by each of the virtual desktops in our organization. This information can be used to determine the desktop resource requirements with a very high degree of precision.
For organizations that cannot justify the expense of Stratusphere FIT, and feel that a simpler approach to desktop resource utilization is sufficient, the Windows Performance Monitor tool can be used to measure the resource utilization of their virtual desktops.
Note
While the Performance Monitor tool provides a useful insight into resource utilization, it cannot compare with commercial tools such as Stratusphere FIT. Given how important it is to accurately determine our Horizon View infrastructure requirements, we should consider using the best tools at our disposal in order to gather current desktop resource requirements.
When using Performance Monitor, the desktop should be measured during a period of normal use, and the data being measured should be saved into the comma-separated format in order to make it easier to analyze. This section will detail each of the counters that should be monitored using the Performance Monitor tool.
Note
Due to differences in hardware and software configurations, Windows resource names will vary slightly from one system to the next. The performance monitor counter names provided in this section are just examples; when using the performance monitor, select the appropriate counter based on the target resource you wish to monitor. Ensure that you are monitoring the active resources, as a system might have some unused devices, such as hard disks or network adapters.
This Windows counter represents the total network throughput of the specified desktop network adapter. The average of this value will help us calculate the network requirements of each virtual desktop on the vSphere Server. For Windows 7 and newer OSes, this counter is displayed as Network Adapter\Bytes Total/sec–Network Adapter in Windows Performance Monitor.
To determine the number of desktops a vSphere Server can host based on the information gathered, we use the following calculation:
Network: The total server network bandwidth in MB/network total MB per second of reference desktop
Read/write bytes per second—the disk read and writes bytes of a desktop provide us with a starting point for sizing the storage network connection that will connect the vSphere hosts to the storage infrastructure. These counters are displayed as PhysicalDisk\Disk Read Bytes/sec – 0 C: and PhysicalDisk\Disk Write Bytes/sec – 0 C: in Windows Performance Monitor.
To determine the number of desktops a vSphere server can host based on the information gathered, we can use the following calculation:
Storage network: The total server storage network bandwidth in MB (disk read MB per second + disk write MB per second) of the reference desktop
Reads/writes per second—the number of disk reads and writes on a desktop provide us a with starting point for sizing the virtual desktop storage platform. The storage design is impacted not only by the total amount of disk input/output (I/O), but also by the ratio of reads to writes. These counters are displayed as PhysicalDisk\Disk Reads/sec – 0 C: and PhysicalDisk\Disk Writes/sec – 0 C: in Windows Performance Monitor. These values can also be referred to as either read or write I/O Operations per Second (IOPS).
To determine the number of desktops a vSphere Server can host based on the information gathered, we use the following calculation:
(Disk Reads per second + Disk Writes per second) * Total number of desktops = Total IOPS required by the virtual desktop storage solution
Note
Regardless of which storage protocol our vSphere hosts will use, there will be some overhead involved. After you have measured your baseline disk bandwidth (disk read or write megabytes per second) or IO (disk reads or writes per second) from your reference desktop, add 15 percent to the value recorded prior to calculating your overall resource requirements.
This counter measures the percentage of time for which the processor was busy. The average of this value will impact the number of virtual desktop processors we can host per vSphere Server CPU core. This counter is displayed as Processor\% Processor Time - _Total in Windows Performance Monitor.
To determine the number of desktops a vSphere Server can host based on the information gathered, we can use the following calculation:
This counter represents the total number of bytes allocated by Windows processes, including any that were paged to physical disk. The average of this value will help us calculate how much memory should be allocated to the virtual desktop master image and, by extension, how much memory will be required in each virtual desktop vSphere host. This counter is displayed as Memory\Committed Bytes in Windows Performance Monitor.
To determine the number of desktops a vSphere server can host based on the information gathered, we can use the following calculation:
Memory: Total server memory in MB / (memory committed MB per second of reference desktop * 1.25)
Note
The
1.25multiplier is used in this calculation to grant the desktop additional memory and reduce the likelihood that the Windows swap file will be utilized. In most cases, when a desktop is forced to use the swap file, a decrease in performance will occur as well as an increase in the amount of IO it generates, which is why the additional memory is important.
One of the easiest things to overlook when designing our Horizon View infrastructure is how much network bandwidth is required in order to support the client connections. The preferred protocol for Horizon View is PCoIP, although it also supports VMware HTML Access as well as Microsoft Remote Desktop Protocol (RDP).
PCoIP is a display protocol provided by VMware for use in the Horizon View product suite. The PCoIP protocol has multiple features that make it ideal for connecting to Horizon View desktops or streamed applications:
It's capable of adapting to varying levels of connection latency and bandwidth
It has multiple built-in techniques for optimizing and accelerating connections over a WAN
It is able to achieve compression ratios of up to 100:1 for images and audio
It uses multiple codecs that enable more efficient encoding and decoding of content between the virtual desktop and the remote client
It is based on User Datagram Protocol (UDP), which eliminates the need for latency-inducing handshakes used in display protocols based on Transmission Control Protocol (TCP)
Microsoft RDP is a TCP-based display protocol that lacks many of the WAN optimization and acceleration techniques that are found in PCoIP. In addition, VMware Horizon View includes Microsoft Group Policy Object (GPO) templates that enable a very granular control over PCoIP connection characteristics. The Horizon View document Setting up Desktop and Application Pools in View (https://pubs.vmware.com/horizon-view-60/index.jsp#com.vmware.horizon-view.desktops.doc/GUID-D90CC716-6CDA-4210-8AF2-9E75C729D847.html) provides us with details on how to use the PCoIP GPO templates.
The VMware Horizon View Architecture Planning guide (https://pubs.vmware.com/horizon-view-60/index.jsp#com.vmware.horizon-view.planning.doc/GUID-5CC0B95F-7B92-4C60-A2F2-B932FB425F0C.html) provides us with estimates for the PCoIP bandwidth utilization based on the application workload of the client. The following table is built upon this information:
|
User type |
Workload characteristics |
Bandwidth in Kbps |
|---|---|---|
|
Task Worker |
2D display and single monitor. Web and limited Office applications. Horizon View desktop and PCoIP settings optimized. |
50–100 Kbps |
|
Task Worker |
2D display and single monitor. Web and limited Office applications. Horizon View desktop and PCoIP settings not optimized. |
100–150 Kbps |
|
Knowledge Worker (3D) |
3D display (Windows Aero) and multiple monitors. Office applications. |
400–600 Kbps |
|
Knowledge worker (3D): heavy video |
3D display (Windows Aero) and multiple monitors. Office applications. Frequent bursts of large display changes and other imaging traffic. |
500 Kbps–1 Mbps |
|
Power user |
3D display (Windows Aero) and multiple monitors. 480P video and images with frequent screen changes. |
2 Mbps |
Bandwidth utilization is heavily dependent on a number of factors, many of which can be controlled with the Horizon View PCoIP GPO settings or even Windows virtual desktops settings.
Even with a careful analysis of user desktop usage patterns, it is important to remember that there will be spikes in usage from time to time. A knowledge or task worker that has a need to use an application with a large amount of screen changes, such as viewing images in succession or watching a video, might cause a brief bandwidth spike between 500 Kbps and 1 Mbps or more, referenced as a Heavy Video user in the table. Preparing for these spikes in bandwidth utilization is important in order to preserve the quality of service for all of the Horizon View client connections.
Measuring the resource requirements of our physical desktops and their users is a valuable exercise that will help us understand what will be required to transition them from the local desktop to the data center. While this is a valuable exercise, no amount of initial planning or analysis can ever replace a properly run pilot that validates the configuration of our master virtual desktop image, the performance of the Horizon View infrastructure, and the perceived end user experience.
Ideally, our pilot should involve the same types of users on whom we performed our initial usage analysis but not necessarily the same users within each group. The following list includes a sample of the goals that our Horizon View pilot should attempt to achieve:
Include multiple users from each user classification such as the task worker, knowledge worker, and power user
Include fully remote users, including WAN-connected users at other company sites
Run the pilot for the full duration of a business cycle so that recurring operations such as quarterly reporting or accounting functions can be observed
Review the performance data from all layers of the Horizon View infrastructure including:
Storage
Network
vSphere host
Guest operating system
Measure the impact of common scenarios such as:
User logon storms: These are large numbers of Horizon View clients logging on within a short time frame
Steady state user load: This measures the Horizon View infrastructure's performance during a period of steady desktop usage by a significant number of users
Antivirus platform performance: This measures the impact of common antivirus software tasks such as on-demand scans and pattern file updates
Horizon View Refresh or Recompose: This measures the impact of these common Horizon View maintenance operations
A fully populated vSphere host: This measures the host performance with higher than normal workloads, such as when a vSphere server fails, and the remaining vSphere servers must host its desktops in addition to their own
Performance issues at any layer of the Horizon View infrastructure will often result in a poor end user experience, usually in the form of longer-than-anticipated response times. This is one of the reasons why it is important to involve a large cross-section of our users in the pilot and seek their opinion throughout.
The performance data that we collect during the pilot can be used to determine our actual resource utilization, which can then be compared to the estimated resource utilization, as determined from our initial analysis of existing physical desktops. If the numbers differ by a significant amount, we will want to work to identify the cause and determine what would happen if any changes need to be made. Some potential issues that need to be looked out for include the following:
The initial analysis of our users did not include a sufficient number or wide enough cross-section of users.
The virtual desktop's master image was not properly optimized to reduce or stabilize the resource utilization. The VMware Optimization Guide for Windows 7 and Windows 8 Virtual Desktops in Horizon with View (http://www.vmware.com/resources/techresources/10157) technical paper provides common Windows desktop optimization techniques.
A component of the Horizon View infrastructure was improperly configured.
The pilot program is occurring during a period of higher than normal user workload, such as a recurring events unique to the organization, including quarterly or monthly reporting.
In summary, a pilot is our best time to learn about how virtual desktops will perform within our environment, both from a performance perspective and in terms of user acceptance. Use the pilot program to identity any potential barriers to a successful rollout, and make any changes that are required in order to minimize the risk of failure as the project moves forward into production.
