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.
Note
Determining the resource requirements of a View environment is a complicated task. Companies such as Liquidware Labs (http://www.liquidwarelabs.com) have created tools that can assist you in determining virtual desktop resource needs, while other companies such as Login VSI (http://www.loginvsi.com/) 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.
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.
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:
Expand the
Data Collector Setsfolder in the left column of the Performance Monitor window, right-click on theUser Definedfolder, and select New | Data Collector Set.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.
On the next screen select the Create data logs radio button, the check box next to Performance counter, and click on Next.
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
Accept the default sample interval of 15 seconds and select Next.
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.
Accept the default Run as: settings or provide different service credentials if required. Select the Save and close radio button and then Finish.
In the left column of the Performance Monitor window, within the
User Definedfolder, 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 namedDataCollector01.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.
Note
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.
Note
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.