Workload Considerations for Virtual Desktop Reference Architecture


As interest in virtual desktop infrastructure continues to accelerate, so do the needs for improved assessment, planning, and deployment methodologies and tools. The historical methodology for determining deployment parameters, (that is the impact of VDI on network, storage, and compute resources) typically failed to truly assess the impact of the workload that would eventually end up being generated by the desktop virtual machine once it went into production. The reason for this gap was simple: There were few, if any, workloads that accurately represented what a user actually did during their workday, that is, the applications they used, the frequency of use, and the “intensity” of use. So professional services organizations typically estimated network and storage impacts based on their experience, and then architected or modified an environment based on those estimates. The problem, of course, is that such qualitative assessments can underestimate the impact of a deployment and result in storage contention or network bottlenecks, or overestimate the impact and result in excess costs.

The purpose of this paper is to introduce a desktop workload tool that generates a realistic, adjustable
workload with various applications in the desktop virtual machine. The results gathered (regarding CPU usage, memory utilization, storage, and network) can then be analyzed to identify appropriateness / readiness of a given environment to run virtual desktops. This tool, called the Desktop Reference Architecture Workload Code (RAWC), has been used in numerous studies to simulate application workloads for various user types. It can be configured to simulate light, medium, or heavy user characteristics, including the types of applications used in a typical Windows desktop environment.

RAWC can be used to evaluate server and storage performance, validate configurations, and perform scalability studies and proof of concepts.


The RAWC workload runs on a Windows 7 or XP guest operating system and is executed on each desktop virtual machine on one or more ESX hosts. The RAWC workload has a set of functions that performs operations on common desktop applications including Microsoft Office, Adobe Reader, McAfee Virus Scan, Windows Media Player, Java, and 7-Zip. The applications are called randomly and perform operations that mimic those of a typical desktop user, including open, save, close, minimize and maximize windows, view an html page, insert text, insert random words and numbers, conduct a slideshow, view a video, run a virus scan, send and receive email, and compress files.

The RAWC workload uses a configuration file that is created via the RAWC GUI and writes application open/close times and any errors to log files in a shared network folder. Various test variables can be configured via the RAWC GUI, including a start delay for creating ‘boot storms,’ and density (delay between application operations) resulting in applications under test to be run together faster, number of emails created and sent, and typing speed.

The combination of applications and test variables that are configured can either increase or decrease the
workload on virtual machines and VMware ESX server(s). The goal of doing this is to evaluate how many virtual machines per solution can be run.

In addition to running native applications, RAWC can also run VMware® ThinApp™ applications hosted on either a local or remote site.

RAWC supports the use of Active Directory Groups. Large-scale deployment evaluations will find this feature extremely valuable. Based on the virtual machine’s Active Directory Group membership, a workload can be configured specifically for that Group via the RAWC GUI. This allows virtual machines to run varying workloads to simulate a more realistic large-scale work environment.


The RAWC Architecture was designed with the following in mind:

  • Simplicity – Minimal number of components and software packages to install.
  • Ease of use – GUI used to configure workloads, create log folders and launch and cleanup configuration files.
  • Scalability – Unlimited number of virtual machines under test.
  • Active Directory aware – Able to determine Group membership and locate the correct configuration file for the test.
  • Policy based workload – Configure realistic workloads based on Group membership for large scale enterprise testing.

The components of the RAWC Architecture include the following:

  • Session Launcher Virtual Machine(s): One or more session launcher virtual machines must be set up to support the launching of desktop sessions. Each session launcher virtual machine can support up to 20 sessions.
  • Target Desktop Virtual Machines – Workload: The RAWC code resides on each of the desktop virtual machines.
  • Email Server Virtual Machine: The email server is required only if you are running Microsoft Outlook. You may use the email server that is provided or supply your own.
  • RAWC Controller Virtual Machine: The RAWC Controller hosts the RAWC GUI and the shared network folder for the configuration and log files. The RAWC Controller can be a physical or virtual machine.
Figure 1.- RAWC Architecture

Figure 1: RAWC Architecture


As the desktop virtualization world evolves, so will the desktop workload tools. Know your environment (network, servers, storage and desktops), and your users (applications, light/heavy use), before determining which workload tool to use. Research the various tools and even conduct an assessment to determine if virtualization is right for your company. Make sure the tool is easy to install and use and that it simulates the applications you run most. Be sure to allow enough time for a proper assessment, testing and interpretation of the results, as this will aid in the proper planning and deployment of your virtual desktop infrastructure.


Download out the full Workload Considerations for Virtual Desktop Reference Architecture guide.

Rating: 5/5

Comments are closed.