Implementing VMware Horizon View 5.2

5 (1 reviews total)
By Jason Ventresco
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Designing a VMware Horizon View Infrastructure

About this book

VMware Horizon View helps you simplify desktop and application management while increasing security and control. This book will introduce you to all of the components of the VMware Horizon View suite, walk you through their deployment, and show how they are used. We will also discuss how to assess your virtual desktop resource requirements, and build an optimized virtual desktop.

"Implementing VMware Horizon View 5.2" will provide you the information needed to deploy and administer your own end-user computing infrastructure. This includes not only the View components themselves, but key topics such as assessing virtual desktop resource needs, and how to optimize your virtual desktop master image.

You will learn how to design and deploy a performant, flexible and powerful desktop virtualization solution using VMware Horizon View. You will implement important components and features, such as VMware View Connection Server, VMware View Composer, VMware View Transfer Server, and VMware View Security Server.

"Implementing VMware Horizon View 5.2" will take you through application virtualization with VMware ThinApp, the implementation of Persona Management, and creation of Desktop Pools. We then cover View Client options, Desktop maintenance, and Virtual Desktop Master Image. Finally we discuss View SSL certificates management, Group Policies, PowerCLI, and VMware View Design and Maintenance to help you get the most out of VMware View.

If you want to learn how to design, implement and administrate a complex, optimized desktop virtualization solution with VMware View, then this book is for you.

Publication date:
May 2013


Chapter 1. Designing a VMware Horizon View Infrastructure

One task that is critical to the success of any VMware Horizon View implementation is the initial research that will shape the design of the View infrastructure. Performing this research requires not only an understanding of the individual components of View, but also an in-depth understanding of what is required to move our end user computing resources from the desk into the datacenter.

This chapter will discuss a number of topics that play a critical role in our View design. We will discuss the different components of a View installation, examine the different license levels of View, and outline the core requirements of a View infrastructure. We will also discuss how to measure the resource requirements of a desktop, and how those requirements impact all layers of our infrastructure including the storage design, network design, and virtual desktop VMware vSphere host configuration.

In this chapter we will learn:

  • The individual components of a VMware Horizon View installation

  • The role of different components of VMware Horizon View

  • VMware Horizon View license options

  • Core infrastructure requirements for VMware Horizon View

  • Desktop operating system (OS) design considerations

  • How to measure desktop resource requirements

  • How to calculate the size of our virtual desktop vSphere hosts

  • View client network bandwidth requirements

  • The basics of running a VMware Horizon View pilot


VMware Horizon View components

A VMware Horizon View installation is comprised of a number of different components. The following section will provide a high-level overview of the function of the various components of View, not all of which may be required in your environment.

The following figure shows where each of the components of a typical View installation resides within the IT infrastructure. The only component not shown is the View Transfer server, which resides within the private network and is described in greater detail in Chapter 4, Implementing VMware Horizon View Transfer Server.

VMware Horizon View Connection Server

VMware Horizon View Connection Server is a software service that serves as the broker for View client connections. In this role, it authenticates user connection requests, verifies the desktops or Microsoft Windows Terminal Servers the user is entitled to access, and then directs the connection to the appropriate resource. View Connection Server is installed on a dedicated server that is required to be a member of an Active Directory (AD) domain that is trusted by all View clients.

View Connection Server also hosts the View Administrator console, an Adobe Flex-based web application that is used to manage the View environment and perform tasks, such as:

  • Deploying virtual desktops

  • Creating desktop pools

  • Controlling access to desktop pools

  • Examining View system events

The View Connection Server is one component that is required in every View environment due to the role it plays as the connection broker and management console.

Chapter 2, Implementing VMware Horizon View Connection Server, provides the information needed to install and configure a VMware Horizon View Connection Server.

VMware vSphere

VMware vSphere, also referred to as ESXi or even ESX for earlier versions, is a Type 1 hypervisor that is the virtualization platform used for the vSphere suite of products. Type 1 hypervisors are designed to run directly on the host hardware, whereas Type 2 hypervisors run within a conventional operating system environment.

vSphere is the only hypervisor that is fully supported for hosting View virtual desktops, as it fully integrates with View for full desktop lifecycle management. All of the primary desktop provisioning and maintenance tasks are performed using the View Manager Admin console; the vSphere Client is not used. View supports multiple versions of vSphere, but vSphere 5.0 and newer are required to leverage many of the latest features of the platform. Refer to the vCenter Server requirements section for examples of some View features that require a specific version of both vSphere and vCenter Server.

VMware vCenter Server

VMware vCenter Server is a software service that provides a central administration point for VMware vSphere hosts as well as other components of the vSphere suite. vCenter Server performs the actual creation and management of virtual desktops, based on instructions received from the View Connection Server and the View Composer Server.

VMware Horizon View Composer

VMware Horizon View Composer is a software service that works alongside the VMware vCenter and View Connection Servers to deploy and manage linked-clone desktops. View Composer can be installed directly on the vCenter Server, or on a dedicated server.

View Composer is only required if linked-clone desktops will be deployed. Chapter 3, Implementing VMware Horizon View Composer, provides the information needed to install and configure View Composer.

VMware Horizon View Transfer Server

VMware Horizon View Transfer Server is a software service that controls data transfers for virtual desktops that are checked out for use directly on the View Client with Local Mode. The View Client with Local Mode is used in scenarios where access to a virtual desktop is required during times where no network access is available. View Transfer Server is installed on a dedicated server.

Local Mode desktops require a full Windows XP, Vista, Windows 7, or Windows 8 based-client, and run on a Type 2 hypervisor that is installed with the View Client with Local Mode installation package.

VMware Horizon View Agent

VMware Horizon View Agent is a software service that is installed on the systems that will be managed by View. This includes not only a virtual desktop image that will be deployed using View, but any physical desktops or Microsoft Terminal Servers as well.

The View agent provides services including, but not limited to, support for connecting the virtual desktop to View’s client-attached USB devices, client connection monitoring, Virtual Printing, single sign-on, and View Persona Management.

VMware Horizon View Client

VMware Horizon View Client is a software application that is used to communicate with a View Connection Server, and initiate connections to desktops and Microsoft Windows Terminal Servers.

The View Client is available for multiple software platforms, including Microsoft Windows, Apple OS X, Android, iOS, and Ubuntu Linux. In addition, there are a number of Thin and Zero clients that come preloaded with View-compatible clients.

The VMware Horizon View Client with Local Mode, described previously in this chapter, can also be used to connect to desktops and laptops remotely. Chapter 9, VMware Horizon View Client Options, provides more information about the various View Client options.

VMware Horizon View Persona Management

VMware Horizon View Persona Management is an optional component of the View Agent that enables an alternative means of managing end user Windows profile data and application settings.

View Persona Management can be used in place of traditional Microsoft Windows roaming profiles, while also providing additional benefits such as:

  • User profile data is loaded only as required, speeding up the user desktop login process

  • User profile updates can be synced back to the remote persona management repository at predefined internals, enabling quicker logoff times compared to traditional Windows roaming profiles

  • View Persona Management settings are controlled through Microsoft Active Directory (AD) Group Policies rather than through individual Active Directory user objects

Chapter 7, Implementing View Persona Management, provides information about how to implement and administer View Persona Management.

VMware ThinApp

VMware ThinApp is an application virtualization platform that integrates with View to provide users with rapid access to new or upgraded applications without having to perform any changes to the virtual desktops.

Applications that have been packaged with ThinApp are delivered as a single executable file that runs completely isolated from both other ThinApp packaged applications as well as applications that are installed on the desktop itself. If required, ThinApp packages can be configured to communicate with one another using a feature known as ThinApp AppLink.

ThinApp provides View customers with a number of powerful capabilities. The following list details three popular scenarios where ThinApp can benefit an organization:

  • Reduce the number of applications that need to be installed on the master virtual desktop image, which reduces the need to deploy and maintain a large number of images for different user bases

  • Eliminate application conflicts that can occur when specific programs are installed together within the desktop image

  • Virtualize legacy applications to ensure that they will continue to function regardless of the underlying Windows OS

Chapter 6, Using VMware ThinApp, provides information about how to use VMware ThinApp to virtualize applications and deliver them using View.


VMware Horizon View licensing

VMware Horizon View offers three different license levels: Bundle, Add-on, and Add-on to Bundle Upgrade. The license levels are differentiated by whether or not they include licenses for vCenter Server and the vSphere hosts. The licenses are sold in 10 and 100 packs.

  • The Bundle license includes all the features of VMware Horizon View, including the licenses needed for the vSphere desktop hosts and vCenter Server. The version of vSphere included with this license is known as vSphere Desktop.

  • The Add-on license includes all the features of VMware Horizon View, but you must provide your own licenses for the vSphere desktop hosts and vCenter.

  • The Add-on to Bundle Upgrade license is for customers who already have Add-on licenses, but wish to upgrade them to the Bundle license level.

The advantage of using vSphere Desktop is that it is licensed on a per-desktop basis, while a traditional vSphere license is licensed on a per-socket basis. This provides View customers with maximum flexibility when considering what servers they will use when deploying their View infrastructure, as it removes the per-socket licensing costs as a deciding factor in server selection.

Visit the VMware Horizon View website ( for the most recent information concerning licensing options and their costs.


VMware Horizon View core infrastructure requirements

There are a number of requirements to consider even before the infrastructure needs of the virtual desktops themselves are considered. These include, but are not limited to:

  • Operating system requirements for both vSphere and View components

  • Database requirements for vCenter Server, View Composer, and View Connection Server

  • Required Microsoft infrastructure services and components


The online VMware Compatibility Guide ( and Product Interoperability Matrixes ( maintain an up-to-date listing of supported operating systems, hardware platforms, and product compatibility for all VMware products.

Microsoft infrastructure requirements

VMware Horizon View requires Microsoft Active Directory to support the virtual desktop infrastructure. VMware Horizon View supports both Windows 2003 and Windows 2008 Active Directory.

View also requires Domain Name System (DNS) servers that can resolve requests for the standard Microsoft Active Directory Service Record (SRV) and Resource Record (RR) DNS entries. Microsoft domain-integrated DNS servers typically store these DNS entries by default. Incomplete or inaccurate DNS entries can lead to issues with tasks, such as virtual desktop deployment and user authentication.

Dynamic Host Configuration Protocol (DHCP) servers are required in the View environment to provide Internet Protocol (IP) addresses to the virtual desktops. In situations where the virtual desktops cannot self-register the IP addresses they have been assigned, the DHCP server should be configured to register the entries with a DNS server that is accessible by the View Connection server.

Operating system requirements

The following table shows which Microsoft Windows Server Operating Systems (OSs) are supported for the each of the different software packages that comprise a View infrastructure. Unless otherwise noted, the software packages support the Standard, Enterprise, and Datacenter versions of the Microsoft Server version listed.

Operating System

vCenter Server 5.1

Horizon View Connection Server, Security Server, Transfer Server, and Composer

Windows Server 2003 SP2 64-bit


Not supported

Windows Server 2003 R2 64-bit (any service pack)


Not supported

Windows Server 2008 64-bit (both SP1 and SP2)


Not supported

Windows Server 2008 R2 (No SP or SP1 installed)


Supported for Standard and Enterprise versions only

As View Composer supports only Windows Server 2008 R2, any View installation that plans on deploying linked-clone desktops and installing Composer directly on the vCenter Server will need to choose that specific version of Windows.

Visit the VMware Horizon View Installation guide ( for updated information about which OSs are supported.

Database requirements

The following table shows which database types are supported for the components of a View infrastructure. Unless otherwise noted, both 32-bit and 64-bit versions of the specified database platform are supported. In addition, unless otherwise noted the ONE, Standard, and Enterprise versions of the Oracle database platforms are supported.

Database Platform

vCenter (all databases)

View Composer

View Event Log

IBM DB2 10 Enterprise


Not supported

Not supported

IBM DB2 Enterprise 9.7.2


Not supported

Not supported

Microsoft SQL Server 2005 Standard, Enterprise, and Datacenter editions (SP4)




Microsoft SQL Server 2008 Standard and Enterprise editions (SP2, SP3)




Microsoft SQL Server 2008 Datacenter edition (SP2)




Microsoft SQL Server 2008 R2 Express (64-bit only), Standard, and Enterprise editions (SP1)


Supported; Express supported only for vCenter 5.0 U1 and newer

Supported; Express supported only for vCenter 5.0 U1 and newer

Oracle 10g (Release 2)




Oracle 11g (Release 1 and 2)


Supported (Release 2 with Patch 5 only)

Supported (Release 2 with Patch 5 only)

Visit the VMware Horizon View Installation guide for updated information on which databases are supported.

vCenter Server requirements

VMware Horizon View supports multiple versions of vSphere and vCenter Servers. The purchase of Bundle or Add-on to Bundle Upgrade licenses entitles users to use the latest supported version of both vSphere and vCenter Servers.

The following versions of vSphere are supported by VMware Horizon View:

  • vSphere 5.1

  • vSphere 5.0, 5.0 U1, and 5.0 U2

  • vSphere (ESX/ESXi) 4.1 , 4.1 U1, 4.1 U2, and 4.1 U3

  • vSphere (ESX/ESXi) 4.0 U3 and 4.0 U4

The following versions of vCenter Server are supported by VMware Horizon View:

  • VMware vCenter Server 5.1

  • VMware vCenter Server 5.0, 5.0 U1, and 5.0 U2

  • VMware vCenter Server 4.1 U1, 4.1 U2, and 4.1 U3

  • VMware vCenter Server 4.0 U3 and 4.0 U4

Visit the VMware Product Interoperability Matrixes for an updated listed of the supported versions of vSphere and vCenter Servers.

Supporting earlier versions of vSphere and vCenter Servers is important for customers who are already running earlier versions of either software platform, and cannot or will not upgrade for some reason. Even with this support, it is recommended to use dedicated vSphere hosts and vCenter Servers for your View environment to ensure that all the latest View features are supported.

There are multiple View features that are supported only if certain other prerequisites are met. Some examples of these requirements are:

  • View Composer requires Windows Server 2008 R2 as the host operating system, which became available after vSphere 4.0 was launched. Customers running vSphere 4.0 may need to upgrade their Windows OS to gain support for View Composer.

  • View Storage Accelerator requires vSphere 5.0 or newer. Customers who wish to leverage this feature will need to upgrade their vSphere desktop hosts.

  • Space Reclamation requires Space-Efficient (SE) Sparse format virtual hard disks, which is only available in vSphere 5.1 or newer.

  • vSphere 5.0 or newer is required to enable View support for vSphere clusters with up to 32 hosts.

A complete list of View features that require specific versions of vSphere or vCenter Server can reviewed in either the official VMware Horizon View Installation guide or the View Release Notes that accompany each release of the View platform.


VMware Horizon View Agent supported operating systems

The VMware Horizon View Agent supports multiple versions of the Microsoft Windows desktop operating system and Microsoft Windows Terminal Server. The following table outlines which version of Windows is supported, based on what type of View-brokered service we wish to provide.

Windows Version

View Desktop or Terminal Service session

View Local Mode Desktop

Windows XP Professional 32-bit (SP3)



Windows Vista Business and Enterprise 32-bit (SP1 or SP2)


Not supported

Windows 7 Enterprise or Professional, 64-bit and 32-bit (No SP or SP1)



Windows 8 Enterprise or Professional, 64-bit and 32-bit



Windows 2008 Terminal Server 64-bit (SP2)


Not applicable

Windows 2008 R2 Terminal Server 64-bit (SP1)


Not applicable

To obtain current information about which desktop operating systems and Microsoft Terminal Services servers are supported, please refer to the online VMware Product Interoperability Matrixes.


Windows 7 virtual machines require vSphere 4.0 U4 (ESX or ESXi) or later, 4.1 U2 (ESX or ESXi) or later, 5.0 U1 or later, or 5.1 or later. Windows 8 virtual machines require vSphere 5.1 or later.


Measuring Virtual Desktop resource requirements

One of the most important aspects of any View design is ensuring that an infrastructure has adequate compute, storage, and network resources to host the required number of virtual desktops. Were it not for troublesome things such as budgets, we could simply purchase an excess of all three of those resources and rest easy at night. For this exercise, our goal is to build an infrastructure that is robust enough to support our average user workload, with some capacity in reserve for growth or maintenance purposes.


Determining the resource requirements of a View environment is a complicated task. Companies such as Liquidware Labs ( have created tools that can assist you in determining virtual desktop resource needs, while other companies such as Login VSI ( have created tools that can be used to test the performance of your View infrastructure. This section will focus on how to use the tools that you already have available with you, but you may wish to research the Liquidware Labs and Login VSI tools further to determine if they are something you would want to use when designing and testing your View infrastructure.

Using Performance Monitor to gather Windows counters

One of the most accurate means of measuring desktop resource usage is to gather performance data during a typical user session. The Microsoft Performance Monitor tool is built into every Windows operating system, and can be used to gather the required performance data.

Configuring Performance Monitor

The examples provided for this section will use the Windows 7 performance monitoring tool, which can be initiated from the Windows Start menu by running the command perfmon. The tool can also be found in the Windows Start menu under All Programs | Administrative Tools | Performance Monitor. The following screenshot shows the default view of the Performance Monitor window:

To determine the average core resource requirements of the virtual desktop, we will be gathering the following counters:

  • Network Adapter Bytes Total/sec: This counter represents the total network throughput of the desktop. The average of this value will help us calculate the network requirements of each virtual desktop vSphere host.

  • PhysicalDisk: This counter gives you read and write bytes per second. The disk read and write bytes of a desktop provide the basis for sizing the storage network connection that will connect the vSphere host to the storage infrastructure.

  • PhysicalDisk: This counter gives you read and write operations per second. The number of disk reads and writes of a desktop provide the basis 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 by the ratio of reads to writes.

  • % Processor Time: This counter measures the percentage of time the processor was busy during the interval. The average of this value will influence the number of virtual desktop processors we can host per vSphere server CPU core.

  • Memory Committed Bytes: 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 determine 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.

To gather the performance data for analysis, we need to create a user-defined Data Collector Set. To create the Data Collector set complete the following steps:

  1. Expand the Data Collector Sets folder in the left column of the Performance Monitor window, right-click on the User Defined folder, and select New | Data Collector Set.

  2. When prompted, provide a name for the Data Collector Set, select the option to Create manually (Advanced), and select Next. This will create a blank Data Collector Set that we will populate with the performance metrics required to perform this analysis.

  3. On the next screen select the Create data logs radio button, the check box next to Performance counter, and click on Next.

  4. Add the following counters to the Data Collector Set by selecting Add to open the Available counters window. Highlight the indicated counter from the following list and selecting Add >> to add it to the Added counters list. Repeat this process for the remaining counters, and select OK when all have been added.

    • Memory – Committed Bytes

    • Network Adapter – Bytes Total/sec – Network Adapter

    • PhysicalDisk – Disk Read Bytes/sec – 0 C:

    • PhysicalDisk – Disk Reads/sec – 0 C:

    • PhysicalDisk – Disk Write Bytes/sec – 0 C:

    • PhysicalDisk – Disk Writes/sec – 0 C:

    • Processor - % Processor Time - _Total


    The counters for the Network Adapter and PhysicalDisk objects are specific to each system. Please select all applicable network adapters and local system drives, using the Ctrl key if it is necessary to gather counters for multiple objects.

  5. Accept the default sample interval of 15 seconds and select Next.

  6. Select a destination directory for the counter data that is not being monitored by Performance Monitor, such as a network drive. This ensures that the disk activity associated with the Performance Monitor data-gathering process is not counted among the rest of the disk statistics. Select Next when finished with this step.

  7. Accept the default Run as: settings or provide different service credentials if required. Select the Save and close radio button and then Finish.

  8. In the left column of the Performance Monitor window, within the User Defined folder, highlight the Data Collector Set that has been created. In the right column, right-click on the Data Collector and select Properties. This Data Collector should be named DataCollector01.

  9. In the Log format: drop-down menu, select Comma Separated and then OK. This will save the data in a format that can be imported into a spreadsheet program for more advanced analysis.

Performance Monitor is now configured to gather the required counters. To start gathering data, right-click on the Data Collector Set in the left column of the Performance Monitor application and select Start. To stop the data collection process, right-click on the same Data Collector Set and select Stop, or simply restart or power down the computer.


A default installation of a Microsoft Windows desktop operating system runs a number of processes and scheduled tasks that are typically not required in a virtual desktop environment. Performing desktop counter gathering or performance analysis without considering the impact of these services or tasks may lead to an overestimation of virtual desktop resource requirements. Chapter 11, Creating a Master Virtual Desktop Image, provides information about what changes should be made to a virtual desktop master image, and information that can also be applied to the sample desktop during data collection to understand the impact of the proposed changes on desktop performance.

The value of the Performance Monitor data gathered from a single desktop is dependent on a number of factors. It is very likely that in order to determine the resource requirements of our View infrastructure, we will need to monitor and analyze multiple types of users. A common way of classifying user types is to break them down into three distinct groups:

  • Task Workers: They run a limited set of applications that typically have lower resource requirements. Examples include factory-floor computers and web-based data entry.

  • Knowledge Workers: They run multiple, often concurrent, standalone Office applications, web-based tools, and other similar applications that have medium resource requirements. Examples include many types of office workers or other individuals who use a computer for most if not all aspects of their job.

  • Power Users: They run resource-intensive applications that are more likely to require the advanced features of a desktop, including multiple vCPUs. Examples include workers that use programs such as SAP or Oracle clients, AutoCAD, or that require 64-bit desktop operating systems.


These classifications of user types are just one example. You will need to research the types of users you have within your own organization to determine if there is a more suitable way of classifying user resource requirements.

To accurately gauge the resource needs of our View infrastructure, we should gather desktop performance data from multiple users that fall within each user classification. The more sources of sample data we have, the less likely it is that any analysis will be influenced by anomalies from any one sample.


Using Performance Monitor to properly size the infrastructure

Once we have gathered desktop Performance Monitor data, we need to perform some data analysis to determine how to size our View infrastructure. This section will outline the processes used to take raw Performance Monitor data, and use it to determine our View infrastructure requirements.

Basics of sizing a View infrastructure

One of the most accurate ways to determine our infrastructure requirements is to take an average of each of the Performance Monitor counter values we have gathered, which should provide us with a per-desktop figure for the amount of resources that a given desktop type requires.

The first thing that must be taken into consideration is whether or not we plan on separating our virtual desktops based on any sort of metric or other user classification. In the previous section, we broke down users into one of three different groups: Task Workers, Knowledge Workers, and Power Users. Each group has different desktop performance expectations, and as their expected performance requirements increase, their tolerance for events that impact that performance decreases. Each user base is different, of course, but when designing our View infrastructure we should consider whether or not we should provide unique storage, network, or compute resources for each of our own user classes. The following provides an example of how that might be accomplished:

  • Task Workers:

    • Higher desktop consolidation ratios per vSphere host

    • Lower tier storage

  • Knowledge Workers:

    • Average desktop consolidation rations per vSphere host

    • Medium tier storage

  • Power Users:

    • Low desktop consolidation ratios per vSphere host

    • High performing storage

    • Network QOS to guarantee desktop bandwidth availability

The analysis done in this section assumes that we are sizing a View infrastructure for one classification of user, and not multiple user classifications that may have different performance requirements. As we discussed earlier, our final design may allocate unique resources to each user classification in order to provide the expected level of performance.

Interpreting Performance Monitor data

The following screenshot shows a portion of the Performance Monitor data collected from a sample Windows desktop. This data was imported from the CSV file created by the Performance Monitor application.

Column A displays a time reference showing that the data was gathered in 15-second intervals, as configured in the previous section. Row 1 displays the counter names, which are arranged by default in alphabetical order.

The following table shows the average value of each of the Performance Monitor counters from our sample desktop. To make the results easier to read, the data recorded in Bytes was converted to Megabytes.

Performance Monitor Counter

Average Value

Memory Committed Megabytes per second

2,443.4 Megabytes

Network Total Megabytes per second

0.75 Megabytes

Disk Reads per second

7.25 Reads

Disk Read Megabytes per second

0.109 Megabytes

Disk Writes per second

10.09 Writes

Disk Write Megabytes per second

0.120 Megabytes

% Processor Time

13.80 percent Processor Time

This data provides the starting point for determining the amount of resources we need to provide for each virtual desktop, and by extension how many desktops we can run on each vSphere host.


Storage for our virtual desktops can be provided using a number of different solutions that include both server-based (local) storage, and shared storage arrays. The Performance Monitor data we have collected includes counters for the number of Disk Reads and Disk Writes per second, which is the basis for properly sizing whichever storage solution we plan to use.

Regardless of which storage protocol your vSphere hosts uses, 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. The sample calculations in this chapter involving Disk Reads, Disk Writes, Disk Read Megabytes per second, and Disk Write Megabytes per second assume that you have already added the 15 percent overhead.

Server processor configurations are a good starting point for determining how many desktops we can run per vSphere server. While most server types can accommodate a number of different memory configurations, they support a fixed number of processors, and each of those processors comes with a specific number of CPU cores. For the purpose of this exercise, we will assume that we have existing servers that we want to use for our View infrastructure.

Server Resource


Physical Processor Count


Cores Per Processor



144 GB

Network Interfaces

10 GB—2 interfaces

Fiber Channel Interface

4 GB (800 MB)—2 interfaces

Using these specifications, we can determine exactly how many View desktops we should be able to host on this server. The goal is to determine which resource is the limiting factor, based on the average values obtained during our Performance Monitor data collection. To determine the number of desktops supported, we divide the aggregate quantity of server resources by the average usage of that resource as determined by our analysis of the performance monitor data. View supports up to 16 virtual desktop CPUs per physical processor core, but your own environment may support less based on the average desktop CPU utilization.

With regard to virtual desktop memory, it is important to remember that the amount of memory we assign to the desktop should be at least 25 percent higher than the average value obtained from our Performance Monitor Memory Committed Megabytes counter data. The reason for this is that we want to prevent the desktop from having to utilize the Windows paging file during spikes in memory utilization, which would increase the amount of I/O that the storage infrastructure must service, and potentially impact virtual desktop performance.


Storage technologies such as all-flash storage arrays and flash storage installed directly within the vSphere hosts can lessen the performance impact of virtual desktop memory swapping. Just be sure to assign the virtual desktops the minimum memory required by the OS vendor to ensure that your configuration will be supported.

The previous table shows our four core resources: server processor power measured in number of cores, server memory, server network bandwidth, and storage network bandwidth. To calculate the number of desktops supported,we use the following calculations:

  • Processor: (Number of server cores * 100) / % Processor Time of reference desktop:

    • (16 * 100) / 13.8 = 115.94 desktops

  • Memory: Total server memory in MB / (Memory Committed MB per second of reference desktop * 1.25):

    • 1,47,456 / (2,443.4 * 1.25) = 48.28 desktops


    The value obtained when you multiply the desktop Memory Committed MB per second times 1.25 (2,443.4 * 1.25 = 3,054.25 MB) indicates that each desktop requires 3 GB of memory, which should provide sufficient free memory, and in turn reduce likelihood of having to use the Windows paging file.

  • Network: Total server network bandwidth in MB / Network Total MB per second of reference desktop:

    • 2,560 / 0.75 = 3,413 desktops.


    Remember to convert the network adapter line speeds from megabit to megabyte to match the output format of the Performance Monitor data. The following formula is used to perform the conversion:

    Value in megabits / 8 = Value in megabytes

  • Storage Network: Total server storage network bandwidth in MB / (Disk Read MB per second + Disk Write MB per second) of the reference desktop:

    • 1,600 / (0.109 + 0.120) = 6,987 desktops.

These calculations assume that we are using a dedicated storage network to connect our vSphere servers to a storage array, in this case Fibre Channel. In the event that our storage network will utilize the same network connections as our virtual machine traffic, we will need to combine both the values observed for Network Total MB per second, Disk Read MB per second, and Disk Write MB per second when determining how many desktops our vSphere host can accommodate.

Using the numbers from the previous example, we will calculate the maximum number of desktops the server could host, assuming the server has only the two 10 GB connections for all network traffic, and no Fibre Channel storage network exists:

  • Network: Total server network bandwidth in MB / (Network Total MB per second of reference desktop + Disk Read MB per second + Disk Write MB per second) of the reference desktop:

    • 2,560 / (0.75 + 0.109 + 0.120) = 2,614 desktops

To determine the minimum specifications for the storage solution we will use to host our virtual desktops, we need to take the average number of Disk Reads and Writes per second from our Performance Monitor data and multiply that number by the number of desktops we wish to host. The following calculation shows an example of how we would calculate the required I/O per second, also known as IOPS, that our storage solution is required to service:

  • Data used for calculations:

    • Performance Monitor Disk Reads per second: 7.25

    • Performance Monitor Disk Writes per second: 10.09

    • Number of desktops to size the storage solution for: 500

    • Average IOPS for one 15K RPM SAS disk drive: 175 IOPS

  • (Disk Reads per second + Disk Writes per second) * Total number of desktops = Total IOPS required by the virtual desktop storage solution.

    • (7.25 + 10.09) * 500 = 8,670 IOPS

  • Our calculations tell us that our storage array will need to service at least 8,670 IOPS, which would require at least fifty 175 IOPS, 15K RPM SAS disk drives. Our calculations are based on the raw IOPS capabilities of the disk drives, and do not take into account the overhead required to implement a redundant array of inexpensive disks (RAID) using a large quantity of disks. The actual number of disks required to service 8,670 IOPS will be more than fifty; how much more is dependent on the architecture of our storage array.

The following table summarizes the number of desktops that the server could host, based on the current hardware configuration. The server referenced in this table has distinct networks for storage and virtual machine networking.

Server Total Resources

Desktop Average Utilization

Number of View Desktops Supported

16 processor cores

13.80 percent (of one core)


144 GB memory

2,443.4 MB


20 GB network bandwidth

0.75 MB


8 GB storage network bandwidth

0.23 MB


Based on the data that was gathered from the Performance Monitor session and the specifications of the servers, we can host a maximum of 60 desktops on these servers as they are currently configured. As the table indicates, our limiting resource is server memory. If the server supported it, and we wanted to maximize the number of virtual desktops the server could host, we could increase the amount of memory in the server and host up to 115 desktops, which is the maximum supported based on the processor configuration. To determine how much memory would be required, we would apply the calculation used earlier, in reverse:

  • Memory Committed MB per second of reference desktop * 1.25 * Number of desktops we want to host = Amount of memory required in MB:

    • 2,443.4 MB * 1.25 * 115 = 351,239 MB = 343 GB

In this example, if we were to increase the memory in our server to at least 343 GB, we could host 115 desktops.

In both the examples, the number of desktops that the servers could support, based on network bandwidth, may seem rather high. One of the reasons for this is that we are basing our calculated maximum on the combined capacity of our two 10 GB connections, which not every server may have. The second, and more common reason, is that our Performance Monitor data did not generate a significant amount of disk or network traffic. This is why it is critical that we gather Performance Monitor data from as many desktops as is feasible, across multiple job or user types within our organization.

The resources required by the virtual desktops are the most important part of determining vSphere capacity, but not the only factor we must take into consideration. The next section will discuss how virtual machine overhead and planning for vSphere failure or maintenance affects our sizing calculations.

Virtual Desktop overhead and vSphere reserve capacity

When determining the absolute maximum number of desktops we can host on a given vSphere host, we must take into account topics such as virtual machine overhead, accommodating vSphere host failures or maintenance, and other similar factors.

Calculating virtual machine overhead

vSphere requires a certain amount of memory and a small amount of CPU resources to manage the hosted virtual machines, including the ability to power them on. The amount of resources required for overhead is typically minimal compared to the resources required by the virtual machines themselves, but it is important not to determine capacity solely by using the calculations from the previous section.

The vSphere console can provide an estimate of the expected amount of memory overhead required for a given virtual machine. The following screenshot shows where the memory overhead is displayed in the Summary tab of the virtual machine properties:

The following table shows the expected amount of memory required to support a virtual machine of several different memory and processor configurations. This information is useful for determining how much memory should be available on a given host in order to properly manage the guest virtual machines.

Virtual Machine Memory

1 vCPU

2 vCPUs

1024 MB

101.06 MB

123.54 MB

2048 MB

121.21 MB

146.71 MB

3096 MB

141.35 MB

169.88 MB

4096 MB

161.50 MB

193.04 MB

The overhead associated with an individual virtual machine is subject to change during the operation of the virtual machine. There is no definitive way to calculate what this overhead will be, but these figures are considered a reasonable estimation.


The figures listed in the previous table represent not only the per virtual machine memory overhead, but also the amount of memory that must be available in order to power on the virtual machine. If our vSphere host refuses to power on a virtual machine, lack of available memory is the likely cause.

The calculations we performed in the previous section revealed that we should assign 3 GB of memory to each of our sample Virtual Desktops. For the purpose of this calculation, we will assume that these Virtual Desktops require only one virtual CPU (vCPU), which is common for all but the heaviest of Power User desktops. Based on the vCPU and memory configuration, each Virtual Desktop would require an additional 141.35 MB of memory to be available for vSphere overhead, which would require another 16 GB be added to our previous server configuration, bringing the total to 359 GB of memory required to host 115 desktops.


These examples assume that we intend to operate our vSphere hosts at 100 percent capacity at all times. In many cases, including the one we will discuss next, this will not necessarily be the case. Just remember that operating any individual component of our View infrastructure at 100 percent capacity can lead to problems if our initial design does not take into account all possible contingencies, including spikes in usage, hardware failure, and other similar events.

The need for vSphere reserve capacity

A second reason to not fully populate a vSphere host is to be able to accommodate all the desktops in the event of a vSphere host failure or host maintenance operation. Consider a vSphere cluster with eight vSphere servers hosting 128 desktops each (1024 total desktops):

  • Desktop requirements:


    Desktop requirements will vary from one environment to the next; these figures are just an example.

    • Each single vCPU desktop requires 10 percent of one vSphere server CPU core (average % Processor Time)

    • Each desktop requires 2,048 MB of memory (average Memory Committed Megabytes)

  • Eight vSphere hosts, each running 12.5 percent of the total number of Virtual Desktops:

    • 1024 desktops / 8 vSphere hosts = 128 desktops per host

  • To continue to run all the desktops in the event one vSphere host were to become unavailable, we would need to be able to accommodate 18.29 desktops on each of the remaining seven hosts.

    • 128 desktops / 7 remaining vSphere hosts = 18.29 desktops per each vSphere host

  • To continue to run all desktops without any degradation in the quality of service, each server needs to have an excess of capacity that is sufficient to host 18-19 desktops. This is:

    • 19 desktops * 10% of a CPU core = 1.9 available CPU cores required

    • 19 desktops * 2,048 MB of memory = 38,912 MB or 38 GB of available memory required

    • 19 desktops * 121.21 MB of memory for virtual machine overhead = 2303 MB or 2.3 GB of additional available memory required

    • 19 desktops * 0.75 MB network bandwidth = 14.25 MB of available network bandwidth required

    • 19 desktops * 0.23 MB storage network bandwidth = 4.37 MB of available storage network bandwidth required

These calculations assume that we want to protect the ability to provide resources for 100 percent of our desktops at all times, which is a very conservative yet valid approach to building a View infrastructure.

The final configuration of the vSphere servers should take into account not only what percentage of desktops are actually in use at a given time, but also the cost of purchasing the additional capacity needed to support vSphere host failures or other events that require downtime.


Always take into consideration the growth of our View environment. Purchasing equipment that has limited ability to scale may save money today, but could cost you dearly when we need to expand. If a piece of equipment you plan to buy for your View infrastructure just barely meets your needs, look into the next larger model or even a competing product, if necessary.


View Client network bandwidth requirements

One of the easiest things to overlook when designing our View infrastructure is how much network bandwidth is required to support the View Client connections. The preferred protocol for VMware Horizon View is PC-over-IP, commonly known as PCoIP. View also supports the use of Microsoft Remote Desktop Protocol (RDP).

PCoIP is a display protocol provided by VMware for use in the View product suite. The PCoIP protocol has multiple features that make it ideal for connecting to View desktops:

  • Capable of adapting to varying levels of connection latency and bandwidth

  • Has multiple built-in techniques for optimizing and accelerating connections over a wide area network (WAN)

  • Able to achieve compression ratios of up to 100:1 for images and audio

  • Uses multiple codecs that enable more efficient encoding and decoding of content between the Virtual Desktop and the remote Client

  • Based on User Datagram Protocol (UDP), which eliminates the need for latency-inducing handshakes used in Transmission Control Protocol (TCP)-based display protocols

Microsoft RDP is a TCP-based display protocol that does not have many of the WAN optimization and acceleration techniques that are found in PCoIP. In addition, VMware Horizon View includes Microsoft GPO templates that enable a very granular control over PCoIP connection characteristics. Chapter 13, Implementing VMware Horizon View Group Policies, provides information about how to use the View GPO templates to control the settings of the PCoIP connections.

Client bandwidth estimates

The VMware Horizon View Architecture Planning guide ( provides estimates for PCoIP bandwidth utilization based on the application workload of the client. The following table is built upon that information:

User type

Workload characteristics

Bandwidth in Kbps

Task Worker

2D display and single monitor. Web and limited Office applications.

50-100 Kbps

Knowledge Worker (2D)

2D display and single monitor. Office Applications.

100-150 Kbps

Knowledge Worker (3D)

3D display (Windows Aero) and multiple monitors. Office Applications.

400-600 Kbps

Knowledge Worker (3D)—High Use

3D display (Windows Aero) and multiple monitors. Office Applications. Frequent display changes.

500 Kbps-1 Mbps

Power User

3D display (Windows Aero) and multiple monitors. 480P video and images frequent screen changes.

2 Mbps

Bandwidth utilization is heavily dependent on a number of factors, many of which can be controlled with the View PCoIP GPO settings or even Windows Virtual Desktop settings. Actual bandwidth utilization will vary based on usage and PCoIP settings.


The PCoIP protocol was invented by a company called Teradici. For additional information about how the protocol works, visit the Teradici PCoIP technology page (

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 who has a need to use an application with a large amount of screen changes, such as viewing images in succession or watching a video, may cause a brief bandwidth spike of between 500 Kbps and 1 Mbps or more. Preparing for these spikes in bandwidth utilization is important in order to preserve the quality of service for all of the View Client connections.

Refer to Chapter 11, Creating a Master Virtual Desktop Image for information about optimal settings for a Windows desktop, and Chapter 13, Implementing VMware Horizon View Group Policies for information about how to configure PCoIP settings to reduce bandwidth needs. The information contained in both of these chapters is critical to optimizing View Client connections and Virtual Desktop performance in general.


The importance of a VMware Horizon View pilot

Up until now, this chapter has been about introducing us to a variety of different concepts that form the basis of architecting our View infrastructure. If we learn anything from this chapter, it is that our goal is to obtain the resources we need to provide an acceptable end user computing experience.

Classifying our end users and measuring their resource requirements is a valuable exercise that will help us understand what will be required to transition our end user computing resources from the desktop to the datacenter. That being said, no amount of planning can possibly replace a properly run pilot that validates not only the configuration of our master Virtual Desktop image, but also the performance of the View infrastructure and the quality of the experience from an end user perspective.

Our View pilot should involve the same types of users as our user analysis did, but not necessarily the same users within each group. The following list includes a number of goals that our View pilot should attempt to achieve:

  • Include multiple users from each user classification: Task Worker, Knowledge Worker, and Power User

  • Include fully remote users as well as WAN-connected users at other company sites

  • Perform additional performance analysis at all layers of the View infrastructure including:

    • Storage

    • Network

    • vSphere host

    • Guest operating system

  • Measure the impact of common View scenarios, such as:

    • User logon storms: Large numbers of users logging on within a short time frame.

    • Steady state user load: Measure View infrastructure performance during a period of steady desktop usage by a significant number of users.

    • Antivirus platform performance: Measure the impact of common antivirus platform tasks, such as on demand scans and pattern file updates.

    • View refresh or recompose: Measure the impact of these common View linked clone desktop maintenance operations, described in detail in Chapter 10, Performing View Desktop Maintenance.

    • A fully populated vSphere host: Measure host performance with higher than normal workloads, such as simulating an outage or an other period of higher than usual utilization.

Performance deficiencies at any layer of the View infrastructure can lead to a poor end user experience, usually in the form of longer than anticipated application response times. This is why it is critical to involve a large cross-section of our users in the pilot process, and to seek their opinion throughout the program.

The performance data that we collect during the pilot program can be used to measure the average of the actual resource utilization, which can then be compared to the estimated average resource utilization from the initial physical desktop analysis. Ideally, the numbers would be rather close to one another, but if they are not we will want to work to identify the cause. Now that we can measure performance at all layers of the View infrastructure, it should be easy to determine where the higher than expected utilization originates from. Some potential issues to look for include:

  • The earlier analysis of the users did not include a sufficient number or a wide enough cross-section of users.

  • The Virtual Desktop master image was not properly optimized. Refer to Chapter 11, Creating a Master Virtual Desktop Image for details on how to optimize the master desktop image.

  • A component of the View infrastructure was improperly configured. This problem can affect any number of components of the infrastructure.

  • The pilot program is occurring during a period of higher than normal user workload, for example a recurring event unique to the organization such as financial reporting.

In summary, the View pilot is your best time to learn about how View will perform within your 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 needed in order to minimize the risk of failure as the project moves forward.



In this chapter, we have been introduced to the different components that comprise a VMware Horizon View infrastructure, including the licensing and core infrastructure requirements. Later chapters will discuss how to install and configure each of these components.

We have also been introduced to the basics of what level of research is required even before the first virtual desktop is deployed, including assessing our existing physical desktops, calculating bandwidth requirements for remote users, and adjusting our design to accommodate vSphere host maintenance or failure.

We concluded this chapter by learning the basics of running a View pilot, which is critical as it will either validate or invalidate all of the research that we did in the early phases of our View design.

In the next chapter, we will begin the installation of our VMware Horizon View infrastructure, beginning with the View Connection Server.

About the Author

  • Jason Ventresco

    Jason Ventresco is a 19-year veteran of the IT field, currently working for Cohesity as a Senior Implementation Practice Lead. In that role, he both develops and delivers Cohesity product training and creates professional services offerings. Jason previously worked as a Professional Services Offerings Manager for McAfee, an EUC Consultant Solutions Engineer for Dell EMC, a member of the Global Infrastructure team for FHI 360, and an IT consultant for WorkSmart and Xerox Global Services. Jason previously authored the books Implementing VMware Horizon 5.2, VMware Horizon 5.3 Design Patterns and Best Practices, VMware Horizon 6.0 Desktop Virtualization Cookbook, and Implementing VMware Horizon 7.

    Browse publications by this author

Latest Reviews

(1 reviews total)
I was able to purchase and download the book immediately. I enjoy the send to kindle feature. It would be nice if I could connect to my Dropbox.
Book Title
Access this book and the full library for FREE
Access now