Planning and deploying a Virtual Desktop

Infrastructure on HP hardware
Creating a 150 user VDI proof-of-concept implementation

Introduction ......................................................................................................................................... 3
Assumptions................................................................................................................................. 3
Acronyms, terms and conventions used in this document ................................................................... 3
Preinstall activities ................................................................................................................................ 4
HP VDI solutions .................................................................................................................................. 5
Basic VDI ........................................................................................................................................ 5
Standard VDI ................................................................................................................................... 6
Enterprise VDI .................................................................................................................................. 6
Brokered (dynamic) and non-brokered (static) architectures ................................................................... 6
Understanding VDI ........................................................................................................................... 7
Desktop VMs versus server VMs ..................................................................................................... 7
Desktops versus desktop VMs ....................................................................................................... 10
Planning steps ................................................................................................................................... 11
Collecting and evaluating performance measurements for planning ..................................................... 11
End user activity levels ................................................................................................................ 11
Collecting data with perfmon ....................................................................................................... 11
Examining devices for redirection .................................................................................................... 16
Planning for network bandwidth ...................................................................................................... 16
Sizing and configuring servers and infrastructure ................................................................................... 17
A building block based approach to VDI architecture ......................................................................... 17
Server sizing ................................................................................................................................. 17
Sockets and cores ...................................................................................................................... 18
Memory sizing ........................................................................................................................... 19
Networking ............................................................................................................................... 20
Moving swap files to other filesystems ........................................................................................... 20
Sizing storage ............................................................................................................................... 20
Basic VDI .................................................................................................................................. 21
Standard VDI ............................................................................................................................. 21
Enterprise VDI ............................................................................................................................ 21
EVA .......................................................................................................................................... 22
MSA ......................................................................................................................................... 22
Datastore size ............................................................................................................................ 22
Deployment steps ............................................................................................................................... 22
Infrastructure configuration .............................................................................................................. 22
Network Time Protocol servers ..................................................................................................... 22
Network deployment ...................................................................................................................... 23
Physical networking .................................................................................................................... 23
Building the management tools ........................................................................................................ 24
Active Directory policies .............................................................................................................. 24
 VMware VirtualCenter ................................................................................................................ 24
VMware Virtual Desktop Manager ............................................................................................... 24
Installing the server......................................................................................................................... 24
Configuration............................................................................................................................. 24
Firmware ................................................................................................................................... 24
iLO 2 configuration .................................................................................................................... 25
RBSU settings ............................................................................................................................. 25
Installing ESX Server ................................................................................................................... 26
Post deployment configuration ......................................................................................................... 26
Adding hosts to VirtualCenter ...................................................................................................... 27
Configuring network adapters manually ........................................................................................ 27
SAN configuration ......................................................................................................................... 29
Network Attached Storage for end user data ..................................................................................... 30
NAS for Virtual Machines............................................................................................................ 31
Direct Attached Storage configuration .............................................................................................. 32
Creating the virtual machine storage ................................................................................................ 32
Sizing and creating the template ...................................................................................................... 39
Help – I made my C drive too small .............................................................................................. 39
VM configuration steps ................................................................................................................... 41
Redirecting devices ........................................................................................................................ 42
OS customization ........................................................................................................................... 42
Replicating user virtual machines ..................................................................................................... 43
Templating ................................................................................................................................ 43
Storage reductions and snapshotting ............................................................................................ 51
Powering on and finalizing VMs .................................................................................................. 65
Extra space................................................................................................................................ 66
Proof of concept evaluation ................................................................................................................. 66
Collecting and evaluating performance measurements post deployment ............................................... 66
Configuring ESXTOP ................................................................................................................... 66
Configuring perfmon to analyze ESXTOP data ............................................................................... 69
Identifying performance issues ......................................................................................................... 72
Server based bottlenecks ............................................................................................................. 72
Virtual machine configuration issues ............................................................................................. 74
Summary .......................................................................................................................................... 75
Appendix A – Desktop inventory categories .......................................................................................... 76
Appendix B – Understanding virus scans in a VDI environment ............................................................... 77
Virus scans and end users ........................................................................................................... 77
The effects of scans on SAN scaling ............................................................................................. 79
Block sizing based on thresholds .................................................................................................. 81
NAS based solutions .................................................................................................................. 81
DAS solutions ............................................................................................................................. 82
The effects of VM size on scans .................................................................................................... 83
Other approaches ...................................................................................................................... 83
Emerging alternatives.................................................................................................................. 84
Appendix C – Performance testing ....................................................................................................... 85
For more information .......................................................................................................................... 86
Virtualization information from HP ................................................................................................ 86
Virtualization information from VMware ........................................................................................ 86
Third party software .................................................................................................................... 86
Introduction
HP Virtual Desktop Infrastructure (VDI) seeks to replace end-user desktops with HP Thin Clients
connected to virtual desktops running on HP ProLiant servers in the datacenter. This document
describes the processes involved in implementing a VDI proof-of-concept (POC) and attempts to fill in
gaps with existing documents. Planning, design, architecture, and troubleshooting as well as
environmental considerations are discussed.

Target audience: This document is intended for IT decision makers, planners, architects, service
professionals and installers that are evaluating VDI. A moderate level of technical expertise and
familiarity with VMware, Microsoft Windows Server and Desktop Operating Systems as well as HP
ProLiant and StorageWorks hardware is considered essential.

Assumptions
This document assumes the following.
A POC or limited pilot implementation of between 20 and 150 users is being undertaken to evaluate
HP VDI as a desktop replacement strategy.
Microsoft® Active Directory is in use and is the current version used within the customer‟s production
environment.
The installer is familiar with installation practices for VMware Infrastructure 3, Microsoft Windows®
XP and desktop applications or has access to subject matter experts.
The installer understands Storage Area Networks or has access to subject matter experts.
The installer understands networking concepts as they relate to the POC environment or has access to
subject matter experts.
The POC is being implemented in a lab environment or a limited production environment.
The POC environment described in this document is based on VMware Infrastructure 3 (VI3) with
Virtual Desktop Manager 2.1 (VDM), Microsoft Windows XP Professional with Service Pack 3 and
Microsoft Remote Desktop Protocol v5/6. Storage may be direct attached (DAS), network attached
(NAS) or a storage area network (SAN).

The installer will review vendor specific documentation. This document does not discuss certain pieces
of the architecture such as application delivery/streaming, backup strategies and broker configuration
and options that should be reviewed.

This white paper is based on testing performed in the second and third calendar quarters of 2008.

Acronyms, terms and conventions used in this document

This document uses acronyms that may not be defined in the body of the text. The following acronyms
should be taken to refer to the items referenced below.
 MS RDP – Microsoft Remote Desktop Protocol
 RDP – HP Rapid Deployment Pack

This document uses specific terms which should be defined.

A proof-of-concept (POC) implementation is a limited scale installation that will deliver IT resources for
functionality and scalability testing and end user evaluation. This is generally done in a lab
environment, but may be extended into limited production to enhance testing.
This document also uses specific conventions for entering command line parameters.

3
The symbol “%>” represents the prompt at the shell in the VMware ESX Server 3 console and should
not be typed. It is assumed that the installer will press the Enter key after each command line unless
otherwise noted.
LUN/Vdisk/datastore may be used interchangeably in this document to refer to the same entity in
sections that refer to work performed on HP StorageWorks Enterprise Virtual Array (EVA) products.

Preinstall activities
Table 1 is a pre-installation checklist that is designed to help guide you through the POC
implementation process. It is not an exhaustive list of considerations for a full scale implementation but
rather a set of suggestions as to where you may wish to give extra thought to considerations.

Table 1. Project outline steps and locations of reference information where available

Step Description

Read Read this document, documents it references and any

VMware VDI specific documents. A broad understanding of
the solution as a whole is critical.

Decide on the architecture Will the implementation be as Basic, Standard, Enterprise or

a Hybrid implementation? Decide and use this guide to
define.

Define static or dynamic architecture Determine whether or not a connection broker will be used in
and core components the environment. In most environments the answer is yes.

Gather a list of existing programs on Create a detailed list of all programs AND SERVICES running
desktops on the local desktops that are distributed and supported by
local IT. Use this document to determine whether these
applications are good candidates for VDI when combined
with a specific type of user.

Determine requirements for local Inventory existing devices such as printers that will need to be
device support redirected in a VDI environment. This should become a list of
devices to discuss REMOVING from the environment. If
devices can not be removed, their functionality will need to
be verified and validated onsite.

Determine current print layout A solid understanding of the current print environment is
critical. Mapping location, permissions and access methods
for all printers and maintaining a record of these devices
should be completed prior to implementing a design.

Define server and storage Inventory and define all available VDI hosts and their
environment connections to storage (both NAS and SAN). Include uplink
ports used for connectivity.

Determine networking requirements Be sure to include remote network requirements and

connectivity between locations. Define connectivity in terms
of bandwidth and latency. Define datacenter networks based
on servers and storage.

Define virtual machine size and Decide what is expected in terms of performance, availability
performance requirements and space. Insure that the virtual machines follow best
practices for creation and that they have enough CPU,
memory and disk resources dedicated to them.

4
Install Follow the installation steps in this document to create a POC
VDI implementation.

Test Test local device redirection, end user acceptance, system

performance and sizing, printing and overall usability.

HP VDI solutions
HP‟s end to end capabilities with VDI allow HP to structure VDI as more than just a piece-meal
solution. Our offerings are distinct, supported and save you time and money with regards to
implementation and long term management. Each of HP‟s offerings, Basic, Standard and Enterprise,
are differentiated by their functionality. Figure 1 shows an overview of the three HP VDI solutions.
Sizing ranges are relative to end user type and ability to follow best practices during implementation.

Figure 1. VDI solutions from HP

Basic VDI
Basic VDI is a broker optional implementation that allows end users to connect to a virtual machine
(VM) resource located on direct attached storage. This is a low cost alternative that offers many of the
major advantages of VDI while trading off some enterprise features and large scale manageability. A
broker can be added to enhance the manageability of the solution.
While capable of supporting both a large number and variety of end users, Basic VDI would normally
be targeted at the following groups:

5
 Small workgroups with specific job functions and little data stored locally
 Business-to-business connectivity such as allowing partners access to specific resources on the
corporate network
 Kiosk type implementations such as information consoles, e-mail stations for trade shows and
corporate lobbies
 Smaller scale, cost-conscious environments where disaster recovery is not a major concern

Standard VDI
A Standard VDI implementation adds shared storage in the form of NAS, iSCSI or HP StorageWorks
Modular Smart Array (MSA) SAN-based storage solutions, such as HP StorageWorks All-in-One (AiO)
or MSA2000 storage products. These products may reduce the overall cost of the solution while
enabling desirable, enterprise-level features from VMware such as VMotion, Distributed Resource
Scheduler (DRS), High Availability (HA) as well as improving availability and data protection.
Standard VDI by default uses a connection broker and is thus a dynamic implementation. HP
recommends VMware Virtual Desktop Manager (VDM).
Standard VDI implementations are capable of scaling into the thousands of users with lower hardware
costs than a more advanced implementation. However, as a rule, these implementations are
optimized for less than 1,500 users as the cost of managing multiple NAS/iSCSI devices may
become prohibitive in some organizations.

Enterprise VDI
Enterprise VDI brings an array of enterprise capabilities to the desktop. By utilizing fibre-channel
based SAN and implementing SAN connected fileshares for user data as a core feature rather than
an option, Enterprise VDI offers the ability to architect complex disaster recovery scenarios, increase
scalability and optimize the environment for security.
The emphasis of Enterprise VDI is the highest levels of availability and data integrity for end user
computing resources. Enterprise VDI is flexible enough to be implemented for anywhere between 200
and 10,000 or more users.

Brokered (dynamic) and non-brokered (static) architectures

It is possible to deploy a multi-thousand user VDI implementation without a connection broker. In this
type of static environment, the end user is generally tied to their own VM much like they would be a
physical desktop and the VM is configured for only that user to access. There are issues that present
themselves in this non-brokered (static) environment.
The first issue with a static VDI implementation comes from tying users to a system. Managing a small
group of known VMs and users is feasible, but tying users and VMs may result in large scale
headaches as time moves on. When user domain\jdoe is user 11 of 50 in the initial POC, the local
admin may know he is on a VM named ks14567jd. When the POC is done and domain\jdoe is user
11 of 7,000, the scenario is not as easy. Part of the VDI benefits story is the ability to reduce support
costs. As such, you should consider naming the virtual machine for the user and adding an
appropriate suffix. In this case, the VM could be named jdoe-vm. When the user requires support, he
will need to know nothing more than his user name to receive it.
Of equal concern is locating the virtual machines themselves within a cluster. VMware clusters do
have limitations based on storage bandwidth and practical management limitations. When a VDI
environment grows into the thousands of users, clusters may grow into the dozens and locating a user
and VM within the mass of clusters is difficult. The answer again comes in the naming scheme for the
virtual machines. In this case, let‟s assume that domain\jdoe works in the finance department for
sales. From a support standpoint, naming the cluster finance to represent the business organization

6
may be an answer. The VM then becomes jdoe-fin-vm or a similar name. It is still searchable using the
user‟s login name, but now support can pinpoint the cluster it resides in as well.
There is more than just user tracking involved in VDI and thus there are other things to consider.
Tracking and maintaining the users‟ files are also an issue. Data redirection should always be used
regardless of whether or not a broker is in the environment. This allows for the centralization of user
data that can be backed up, scanned for viruses and secured in a more efficient manner.
Finally, in a brokerless environment, it should be understood that not using a broker will guarantee a
user is without a resource if something goes wrong with their individual virtual machine. This presents
a situation where availability is essentially the same as during a desktop failure. If you still want to
forgo a broker, steps should be taken to reduce downtime. The best way to insure there are options is
to use data redirection and keep “spare VMs” set aside for use. A separate naming convention for
spares and restrictive policy settings to avoid local data accumulation should be used. In addition,
VMware HA should be used in the environment. While it can not be used to eliminate downtime, it
can drastically reduce downtime from system failures. It is also recommended that HP Systems Insight
Manager (HP SIM) be used for hardware monitoring. While HP SIM can not detect all failures, it is an
excellent way to proactively monitor systems and fix problems before downtime occurs.
Dynamic environments introduce layers of functionality that begin to fill in solution gaps and simplify
management. These features are enabled by connection brokers. As a rule, core features of
connection brokers include the following functions:
 Ability to dynamically allocate an end user to a VM
 Ability to create groups of VMs for the purpose of applying policies, organizing functions or setting
access permissions
 Provide a central access point to the infrastructure that can be made highly available
 Provide an added layer of security to the login functions and/or display protocols

It should be noted that with many brokers it is possible to use a reserved model. In this model a user
has a virtual machine dedicated and reserved for as long as an administrator chooses, but the broker
is still the central point for control and provisioning of each VM.

Other functions are broker specific. HP recommends VMware Virtual Desktop Manager (VDM) for
VDI.

Understanding VDI
This section provides a planning approach for the installer to take rather than a set of hard and fast
rules. As with all virtualization implementations, interactions can only be predicted to a certain extent
outside of the actual production environment. Stated another way, you can not tell how many VMs
you will have on a host in your environment by simply asking your neighbor how many he has on his.
The level of variability is too great. Thus, this section focuses more on the “what effects” overall
utilization with virtual desktops rather than how each potential combination of resources may interact.
Two subsections emerge to help the installer understand some of the major issues of VDI environments.
The first section will deal with the comparison of a desktop virtual machine versus a server virtual
machine. The purpose is to assist those who are familiar with server virtualization better understand
the differences they need to plan and adjust for. The second section is a discussion of the desktop
versus a desktop VM.

Desktop VMs versus server VMs

If you consider the general function of a desktop versus the function of a server there are general
behaviors and characteristics that can be assumed with a reasonable degree of certainty. Table 2
presents an overview of some of these general characteristics.

7
Table 2. Server and desktop characteristics

Characteristic Desktop Server

CPU scheduling and utilization Function of user type, applications in Generally heavier with even “light”
use and frequency of work being services scheduling CPU time on a
done. Tends to be variable for most nearly continuous basis. For most
users with peak periods occurring server applications processor
during the day, week, month and scheduling is continuous within a set
potentially the year. May be at or time range. Fluctuations and peaks
below 5% for the vast majority of a can and do appear, but tend to be
shift with only momentary spikes as more predictable.
applications start or non-user initiated
processes occur.

Memory usage Applications at start and during Services tend to grab memory at start
operation may reserve large blocks and may not release it until reboot or
of memory. Applications can utilize service shutdown. The amount of
the memory heavily, but generally memory and the absolute utilization
release it when the user closes the vary based on service, but are almost
program. always more consistent than a
desktop.

Disk IO Generally intense only during file Numerous applications rely on disk
copies and patch deployment/virus IO for performance. Frequently a
scan. May vary with application, but limiting factor in overall system
typical IO and graphics intensive performance.
applications may not be ideally
suited for VDI at this time and thus
would be rarely used.

Network utilization Generally peaks during file copies, May be extremely heavy based on
media work, network logons and application. Light usage is outside of
client/server application work. the norm. Constant utilization is
common even if it is fairly low
overall.

Placing these characteristics into the context of comparing desktop and server VMs requires a brief
review of what is actually happening within VMware ESX Server 3 when the various resources are
used. This section is not an exhaustive discussion, but rather seeks to highlight in a common sense
way how these characteristics will alter sizing.

CPU
Within VMware, each virtual machine must schedule time on a CPU core (or multiple cores if the VM
is assigned more than one virtual CPU (vCPU)). If we were to size our environments with one VM (1
vCPU) per core, we would see excellent performance and little resource contention aside from the
requirements of the Service Console. However, there may not be a business case to be made for 4-16
desktop VMs per host due to higher per VM hardware costs. Luckily, one of the major advantages of
VMware is its management of the scheduling of threads from the virtual machines to the physical
processors. VMware provides the ability for more than one virtual machine to efficiently utilize the
same physical CPU core. While there is contention, for the most part a thread is not usually waiting
long to be processed provided the number of virtual machines per core is reasonable and the
workload is balanced.
If we refer back to Table 2, we can start to make some broad generalizations about sizing. In a
server environment where we virtualize a series of web servers and application servers, the CPU
utilization, while not necessarily intense, may be viewed as relatively constant. There is never a large
period of time when the VM is idle. In the context of the previous paragraph it becomes easy to

8
imagine that 3-4 of these VMs scheduled on a single core may quickly begin to experience conflicts
for processor time.
From a desktop perspective, this behavior is certainly more variable, but in many cases it is less
severe. If we “look around” us during the course of the day at what others are doing at their desktop,
we may find that two people are typing away at e-mails, one is browsing a web page, another has a
Microsoft Office Word document open for review, two more are on the phone and casually reading
e-mail and two more are away from their desk in a meeting, having coffee or just plain absent for the
day. Of those 8 representative users, perhaps 3-4 are contending for the same resource at any given
point in time. Were this our user profile at any given moment in time, these 8 users and their
associated VMs on a single core is a reasonable proposition. 8 cumulative VMs per core in this case
is actually 4-5 highly active VMs per core in practice.
These are of course blanket generalizations. Exceptions do exist. A tertiary DNS server that is largely
inactive in physical form would likely sit in an idle loop and not contend for CPU resources against
other server virtual machines. Similarly, a call center user may punch data into a desktop VM for 90%
of an 8 hour shift and constantly contend for CPU resources with other, nearly identical users. We will
move beyond the generalizations later in this document, but it is useful to take away this high level
understanding from this section.

Memory usage
In a server environment, the services provided by the server are generally continuously using or at
least reserving memory. In a consolidation environment, the variety of services can be quite large and
thus VMware‟s ability to both share and overcommit memory resources is lessened. With HP VDI, the
opposite tends to be true. Through proper design, the same OS and programs within a VDI instance
are generally running on a given host. This means that even if programs stay open and memory is
being used, the capacity for VMware to share and overcommit is far greater. Memory overcommit
levels of 200% in a VDI environment are in fact feasible (though highly variable based on
environment).
From the previous paragraph it may be tempting to believe that memory would rarely be a limiting
factor. When examined from a utilization standpoint this is at least partially true. From an absolute
capacity standpoint though it can have a tremendous effect and thus proper server memory sizing is
critical.
Disk IO
Disk IO in a server environment is generally consistent for a given application and timeframe. Disk IO
in a VDI environment may vary considerably based on user and application types associated with a
given VM. While user data is generally redirected to NAS, local disk IO from programs is still a
potential issue to contend with. Knowledge of end user disk IO patterns is extremely helpful prior to
implementing HP VDI and should be monitored as part of a pre-deployment environment check. The
biggest factors that will likely effect the overall amount of disk IO in a VDI environment is from virus
scans or patch application (see Appendix B for hints on planning for this IO).
As in all server based computing environments, host systems will experience a login phenomena
commonly called a login or boot storm. This phenomena is noted by a stressed disk subsystem caused
as many users log on to shared storage resources over a short period of time. This creates a need to
balance login disk IO with continuous utilization IO. Using NAS or SAN to redirect user data can
partially alleviate this phenomena and is recommended.

Network utilization
At a high level, end user network traffic is generally not intense with the exception of certain times
such as during logins, file copies and large print sessions. However, the network itself can have a
profound effect on user experience, especially in remote locations. When comparing the network

9
characteristics of a desktop to a server, the profile is very different. A server tends to have sustained
periods of network activity, frequently with small amounts of data per transmission. A desktop tends to
experience bursts of activity, frequently with large amounts of data being transmitted and received.
It is important to note that any attempt at sizing networking using physical desktops can not reflect the
deployment as it will exist in a virtual environment. When monitoring a standard desktop there are
characteristics that change when moving to VDI that can not be easily accounted for. These may
include:
 Redirected printers that once communicated directly via USB or parallel cables but now have their
queues pushed across a network
 Redirected file devices such as disk-on-keys which now must have data migrated across the network
when moving files
 The connection protocol itself is not measured when collecting data on a standard desktop

The most server-like of these network points is the connection protocol itself as screen display is fairly
consistent with users working in a specific application. There will be exceptions to this rule which will
be discussed later in the document.

Desktops versus desktop VMs

The desktop is generally the most commonly implemented computing device in the enterprise.
Surprisingly the behaviors of the desktop are not well understood. The next section will deal with
capturing data to understand the function of the desktop in your environment. This section suggests
that the lack of understanding may simply be the result of the desktop being a device that is rarely
utilized to its full extent.
When comparing a virtual machine to a physical desktop, certain themes emerge. First and foremost
is the difference in current resource capabilities. Put simply, a desktop will rarely have contention over
resources when being operated by a user that is a good fit for VDI. With multi-core processors and
high speed, large memory installed, a desktop simply has more power than the average user will
need. This is of course one of the drivers for VDI adoption. From a design standpoint this begs certain
changes be implemented in the design of the image. These are covered more in depth later in the
paper, but the idea is that when a discreet resource such as a desktop becomes a shared resource
such as a VDI VM it is an opportunity for the installer to evaluate the effects that extra programs and
services will have at design time and not after the VMs have been brought online. Minimizing or
eliminating applications and services that would have a big effect on overall system performance is a
positive.
Another theme that emerges in the comparison is that behaviors will change at the network level. In a
desktop environment, a printer and USB key connected directly to the device will have no effect on
the network. With VDI, these devices, while directly connected, must be redirected across the display
protocol in order for the virtual machine to make use of them. This means data formerly carried across
USB paths is now carried over the network and the network needs to be planned accordingly. This
also has an effect at the hypervisor level as the hypervisor manages and touches network packets.
Finally, the desktop has a dedicated graphics card that generally offers capabilities to display high
resolution images and other media types with little effort. Virtual desktops do not have a physical
graphics card and must rely on CPU cycles and physical memory to render graphics information that
would normally be offloaded on a physical desktop. This creates higher levels of utilization on shared
systems and has the potential to effect the performance of other users on the system. It should also be
noted that graphics capabilities are limited to begin with due to the lack of a VM controlled graphics
card and limitations of some display protocols. Some protocols such as HP‟s Remote Graphics
Software – PC Edition offer a codec independent method of improving the end user graphics
experience for all types of media.

10
Planning steps
Collecting and evaluating performance measurements for planning
HP recommends that during an initial evaluation the installer pay close attention to a number of
performance metrics at the desktop. By utilizing performance measurements and characterizations
from real desktops, the identification of end users to include in the proof of concept and the overall
design of the virtual machines will be made easier.

End user activity levels

It has become commonplace to categorize end users as some variation of power user, office worker,
knowledge worker, etc. The user type is generally loosely defined and tends to be focused on
imaginary application loads. While certain applications may require excessive resources (and thus
may not be a good choice for a VDI implementation), the frequency of end user activity including
keyboard entry actions are generally as important as application type in determining what “category”
of user a specific worker or user group belongs to. End user actions equate to CPU activity within the
virtual machine and intense actions with a frequent level of occurrence mean a heavier user even
when the application is lightweight. PC activity monitoring software may be used or you may simply
wish to record general perfmon data remotely in order to decipher times of peak activity and overall
activity effect for a variety of user types.
By approaching end user categorization from an activity level as well as an application level you are
far more likely to maximize the number of users on a host as you can distribute the heaviest and
lightest users based on application load and frequency of use across the same hosts and achieve a
better balance than simply using loosely estimated categorizations or business function groupings to
place end users.
It should be noted that regardless of activity level, certain applications have a large footprint on a
desktop and will have a large footprint in a VM. If these applications are utilized on a frequent basis
or are accessed concurrently by a large number of users it may be best to exclude users that are
dependent on those applications from a proof of concept or even a production deployment. The
following sections of this document should assist the installer in determining ways to potentially
evaluate and isolate those applications.

Collecting data with perfmon

The primary purposes for collecting perfmon data from physical user desktops are threefold:
 Making determinations of what type of users are suitable for VDI
 Defining application and service loads for virtual machine groups
 Determining what loads will be eliminated from VDI consideration

Given the categories above, it is logical to infer that perfmon data should be collected across a
variety of user types. Once you have defined potential groups for a POC or proof of concept you
should choose a sample of users from each group to monitor for an extended period of time. It is up
to the discretion of the installer and management as to whether or not the end user should be aware
they are being monitored. The installer should seek to identify and resolve aggregated services issues,
seek out applications and end users that would be too resource intensive and remove them from the
pool and seek to identify and work around time based usage patterns.

Perfmon and aggregated services issues

Aggregated services issues typically show up when you have a scheduled service or services that
contend for resources at the same time on a large scale. This can be a complex issue, especially in IT
environments where resources are segmented into groups that handle LAN, SAN, server and desktop.

11
Because the desktop group may require an image or build of a certain spec, the server administrators
may build the HP VDI VMs to meet that spec. The issue with this is that the desktop itself is a fairly
limitless pool of resources. A VDI instance is only as strong at its peak as the currently available
resources on the host. With 40 virtual machines running and end users active, the free resources may
be limited for scheduled services to work.
An obvious example of the aggregated services issue is virus scanning. While it is recommended in
an HP VDI environment that real-time virus scanning be left on at the VM, an actual full system scan
should not be carried out. Take an example of 40 virtual machines on a single platform, all of which
launch a full system scan at the same time. It is doubtful these scans could be carried out across all
VMs in a reasonable time frame. It is even more unlikely that any one VM would be useable by an
end user while the simultaneous scans occur. If the VMs reside on shared storage it is unlikely that a
user on any host accessing that storage would be capable of producing work.
While this is a drastic example of the issue, the same problem can occur in far more subtle ways.
Application inventory scans are another example. While these are generally low overhead processes
on a desktop, the aggregate effect of running 40 small processes simultaneously in a VDI environment
can be pronounced. The effect can also be exacerbated by limiting resources through resource pools
or memory/processor limits.
When a shared services issue exists in a VDI instance it generally will show the following
characteristics:
 User complaints of performance issues at specific times of day or week
 Repeated and extended ESX host spikes (on one or more subsystems) to 100% for periods of time
greater than 30 seconds but generally less than 30 minutes
 Unexpected sustained IO activity from more than one source

Troubleshooting these issues post-install may require tools such as HP Operations Manager and the
Veeam (nworks) Smart Plug-in (SPI) for VMware. These tools can monitor the desktops of similar end
users along with the virtual machines of HP VDI users. At the desktop, the goal is to search for intense
bursts of patterned and or scheduled activity. At the VM, the goal is merely to look at patterns of spike
behaviors on any of the subsystems. The real key is that these monitoring tools can dig down to the
process and application level and, with the Veeam SPI, report back reasonably accurate information
that is not completely skewed by timekeeping issues in the VM.
Preventing these problems before they occur is of course the best solution. Using perfmon to sample
user behaviors prior to their occurring in virtual machines is highly recommended. It is generally
easier to isolate patterned behaviors by the end user before their environment becomes virtualized.
Utilizing perfmon to monitor common characteristics while the end user works is an excellent way to
capture shared services patterns. There is no universal rule for defining what scheduled services will
be an issue. The installer must know what to look for when analyzing data from the desktops and
exercise their judgment on what they believe may present an issue. This is a matter of experience on
the part of the installer.
Figure 2 shows a mild example of time based patterning. In this case there is a “shark tooth” pattern
to the CPU usage on the desktop. This may or may not be indicative of a scheduled service. On closer
examination of individual processes, evidence suggested that this minor pattern was a result of
background activities occurring between Microsoft Office Outlook and Microsoft Exchange Server.
While it would likely be possible to alter these interactions, the relatively small spikes are merely
noted and will only be tuned if they become problematic post-POC install.

12
Figure 2. Perfmon graph suggesting mild CPU patterning for further examination.

Resolution to scheduled services issues varies, but a good general rule is to distribute the scheduled
service to either off-hours times or across VM groups to insure that a minimal number of instances of
the service are running at any given point in time.

Perfmon and utilization data

The second purpose for monitoring physical desktops is to determine the source of high utilization
rates for applications and end users and to categorize them as being suitable or unsuitable for VDI.
These categorizations are at the discretion of the architect and should also account for the business
function of the user and their relative importance over other users. For instance, if a small group of
end users exhibit heavy peak utilization or if a limited number of instances of a particularly heavy
application are in use at the same time, this may not disqualify the users or apps from inclusion in
VDI. If those users are performing a business critical function that must have the highest priority of
access to resources, then exclusion should be considered.
Figure 3 shows the patterning of a rich media application running on a desktop. While there is still
enough disk and CPU resources available on this physical system, running this application
concurrently with a number of other virtual machines on a single host may present issues for other
users. Monitoring over extended periods of time to determine the frequency of application usage and
the amount of time it is utilizing resources this heavily is recommended.

13
Figure 3. Intensive application patterning

It should be noted that the installer will be seeking patterns such as those in Figure 3 during data
analysis. The installer will have to determine the causes of spikes such as these and then make
determinations whether or not the end user or application should be included in a VDI POC. It should
also be noted that if this application shows up for only one monitored end user it may be perfectly
acceptable to include it and the user in a VDI deployment. The concern is the application or activity
occurring with numerous instances at once.

Perfmon and time based usage patterning

The third purpose for utilizing perfmon in the physical environment is to determine usage patterns of
end users on a time basis. This is different than seeking scheduled services issues in that the source of
the scheduling issues is a user rather than a process. Questions that need to be asked of the data
include:
 Are there times of day that always show greater usage?
 Are there specific user groups that show consistent offline periods based on time of day?
 Are there users that show a consistent enough utilization across time to be precluded from a VDI
implementation?
 Are there extended enough periods of underutilization that could allow for the repurposing and
redeployment of host systems?
 Can loads be transferred to fewer systems at certain times of day to allow for some systems to be
powered down?

The goal of all of the above is to insure optimal utilization at all times of day and night. That
optimization can come (from a time perspective) in 3 ways.

14
1. Preventing certain users from migrating to VDI
2. End user concurrency
3. Optimizing power utilization for greener IT and lower solution costs

The first optimization is straightforward but deserves a moment of mention. It is theoretically true that
all users can be placed in a VDI environment. The issue is not whether or not this is possible, it is
whether it is cost effective. A VDI server with users that show sustained and heavy utilization over time
or at discrete times will host fewer users than a server with lighter users or those who are not as
frequent of users. This in turn raises the per user cost of the solution to a level that may justify looking
into other dedicated resource technologies such as HP Consolidated Client Infrastructure, Blade
Workstations or even leaving the user on a traditional desktop.
End user concurrency is a concept that states that all users do not need their computing resource at all
times. Because of this, you can have fewer resources (VDI sessions) than end users and still maintain
overall productivity. It is critical that this concept is tested thoroughly prior to implementing in a
production environment.
Power optimization is an area of interest for most customers and can be enabled in a variety of ways.
The four most commonly mentioned methods of achieving some level of power optimization are HP
Integrated Lights-Out (iLO) power control, HP Power Regulator for ProLiant, VMware Distributed Power
Management (experimental in VMware Infrastructure 3.5) and application stacking. The first three
approaches may be made passive in that settings can be configured or scripted to insure that systems
that are not loaded are not utilizing excess and unneeded resources. Application stacking is a rather
different approach and is also a riskier venture. With time based stacking, a server may be used as a
VDI server between the hours of 7 am and 7 pm. Rather than being taken offline at 7 pm, a different
set of virtual machines is started on the server. These VMs would serve a different business purpose
that could be achieved between 7 pm and 7 am. It is theoretically possible to reprovision the entire
server as well, but there are advantages in speed to deployment and flexibility when the system is run
as a virtual host. Read Appendix B of this document prior to considering multi-purpose servers and
application stacking.
Determining what time based performance data is a result of end users may be more complicated
than determining scheduled services, but only because it is likely not as fine grained of a pattern. As
a rule, end user caused time patterns will not be as exact as scheduled service based patterns
because humans do not respond to a clock at an exact and discrete point in time. There are
exceptions (think of usage that is tied to the stock market opening which would occur within seconds
daily). It is also worth noting that end user time patterning is generally difficult or impossible to
change as the causes tend to be business function specific.
Once time based user patterns are identified the installer should determine the expected cumulative
effect of those end users. As an example, if the time based patterning appears to be tied to a group
of users rather than a discrete user, the number of users can be multiplied by the individual statistic
(CPU, disk, memory) to gather an estimate of cumulative resource usage. The end users can then be
spread across multiple systems or removed from the pool of users completely.

Closing notes
One of the central themes of all of the issues discussed in the previous sections is the different
behaviors brought about by running standard desktop builds inside of virtual machines. The following
are simple general rules to follow when testing desktop environments and planning virtual machine
environments.
1. Limit anything in the VM image that can cause contention when multiplied by the number of VMs
on a single host or when factoring in the IO available from shared storage resources.
2. Never move a physical desktop to a virtual environment via a physical to virtual (P2V) process.
This almost guarantees issues moving forward.

15
3. Mix VM builds across clusters in environments where there are known scheduled services issues
within certain groups and not within others. This will balance contention across multiple systems
rather than concentrating in one area.

Examining devices for redirection

Not all devices will successfully redirect across all display protocols. HP suggests that during the
planning phase end user devices are evaluated for whether they will redirect across the protocols
selected for implementation. These tests should be used to determine the viability of certain user types
and also the continued need for peripheral devices. This is an opportunity for the IT department to
reevaluate the costs and benefits of allowing certain device types at the end user support point. Fewer
devices at this point will translate into lower support costs.

Planning for network bandwidth

The primary planning consideration for network in a VDI environment is the connection protocol itself.
VM specific traffic that never leaves the datacenter is not generally seen as an issue in a VDI
environment. Rather, the connection protocol itself must be considered as it is the source for all end
user productivity. There are not currently hard and fast rules for planning, but the recommendations
below should serve as a starting point. In addition, measure network behavior during initial data
collection to identify major areas of contention prior to implementing.
 Latency is nearly always more critical than bandwidth with regards to end user experience. A
bandwidth limited user may have an acceptable user experience simply by tailoring the protocol to
relay less information. When latency becomes an issue, the end user experience becomes
undesirable very quickly. 100ms or less of latency is regarded as optimal. Depending on the
protocol, latencies as high as 150ms may be acceptable for everyday use. Values above these
numbers would require a customized protocol with very low screen change rates to be useable as
an everyday computing device. Levels of 200ms and more have been reported for special purpose
VMs.
 Base protocols (MS RDP, HP Remote Graphics Software – PC Edition (RGS-PC)) will generally
perform acceptably with less than 100Kb of bandwidth per VM with infrequent screen refreshes.
However, in practice this is not an adequate number as print traffic and redirected devices carry
data across this protocol. HP suggests starting with a minimum of 150Kbps per user for a VDI
implementation. Increase bandwidth for any other applications/devices that may increase screen
refresh rates or push data across the protocol network.
 Print traffic is the largest variable in the connection protocol network. Print traffic is best handled
when compressed and managed. HP recommends the HP Universal Print Driver in environments that
utilize only HP printers. HP recommends ThinPrint as a print management platform for all mixed
printer VDI environments. ThinPrint helps with issues of bandwidth and location awareness and
offers a central point of management for VDI print implementations.
 Minimizing device redirection or eliminating it completely can insure that the per user bandwidth
stays low and is more consistent. Evaluate each device prior to implementation and determine
whether or not it is critical to the implementation. It may be possible to implement the functionality
of the device in a different way such as moving a printer to the network and restricting access
permissions to a specific user or group.
 Keep local printers to a minimum. Local printers receive print queues over the connection protocol
network and may require that a driver be loaded in all VMs to make them work right. A well
organized set of networked printers is generally the better solution to providing end users with a
local, physical printer to access.

16
Sizing and configuring servers and infrastructure
Sizing the server goes beyond “the box” and includes insuring that best practices are met at all points
in the VDI environment. The following discussions are meant to provide guidance on common
practices and relative figures on appropriate sizing numbers by device. There is no substitute for
testing within an environment to insure accurate sizing.

A building block based approach to VDI architecture

HP recommends that VDI deployments be broken up into building block units (blocks) for simplicity of
support, deployment and for reliability in sizing and configuration. The concept of a block suggests
that all of the pieces of the VDI solution are broken into logical groups based on the lowest common
performance denominator (LCPD) in the deployment. As an example, in a SAN based deployment,
the SAN itself is a logical LCPD. At some point the SAN will become saturated and no amount of
additional servers, clients or management infrastructure will improve that number of users. Once the
performance threshold of the LCPD has been reached, a block has been defined. For instance, if the
SAN reaches capacity at 500 users, the block may look as follows in Table 3. For every 500
subsequent users, an identical block is ordered and deployed.

Table 3. VDI block definition based on SAN as the lowest common performance denominator.

Component Quantity Capacity per unit

SAN 1 500 users

Servers 16 32 VMs

Blade enclosures 1 16 servers

Thin clients 500 1 client per user

Hypervisor licenses 5 100 VDI instances per license

This is of course a very simple block. Management software, power distribution, racks and
infrastructure, and backup facilities are all potential additions. However, since many of these pieces
of the solution have a fractional value for each block it is at the discretion of the installer or decision
maker to include them in their own block definitions.

Server sizing
Accurately predicting proper sizing for a virtualized environment is always a process in estimation to
some extent. There are few hard and fast rules in a virtualized world for you to take anything other
than real world experience and strong knowledge of VMware and make an accurate guess for sizing.
It is HP‟s experience that on 2-socket systems with 4GB of memory per processing core that 4-6 highly
active users per core are observed in nearly all cases when the following configuration norms are
true:
 Virtual machines run Microsoft Windows XP Professional
 Virtual machines are assigned a single processing core and 1GB of memory or less
 Microsoft Remote Desktop Protocol is used as the connection protocol

17
In a 150 user POC implementation such as this, 4-5 servers are utilized with between 32 and 38
users per server (150 VMs plus spares). The installer may then size up or down based on observed
data and suggestions contained in this guide.

Per core ranges

We call out the ability of the installer to adjust sizing up or down based on
observed data as field implementations suggest that the range of users per
core is increasing as technology improves.

There are some general discussions to be had around optimizing the server and environment that will
always lead to a greater number of virtual machines on a given host. Some of these optimizations are
covered in this document.

HP Sizer for VMware

The HP Sizer for VMware is not designed to address the proper sizing of
virtual desktops. Please do not use this sizer for your VDI deployment.

System Recommendations
The following are system recommendations for servers in a VDI environment.
Minimum
 8 processing cores
 32GB of memory
 2 network ports for Console and VMotion networks
 2 network ports for virtual machine traffic
 2 network ports for iSCSI traffic (Standard VDI only)
 2 fibre channel ports (4Gb) (Enterprise VDI only)
 2 72GB SFF SAS 10,000 RPM HDD in a RAID 1+0 configuration (15,000 RPM drives and
maximized number of spindles if hosting VMs locally)

Recommended
 8 processing cores
 32GB RAM
 2 network ports for Console network
 2 network ports for VMotion network
 2 network ports for virtual machine traffic
 2 network ports for iSCSI traffic (Standard VDI only)
 2 fibre channel ports (4Gb) (Enterprise VDI only)
 3 72GB SFF SAS 10,000 RPM HDD in a RAID 5 configuration (15,000 RPM drives and maximized
number of spindles if hosting VMs locally)

Sockets and cores

Table 4 below seeks to highlight the pros and cons of 2- versus 4-socket systems in a VDI
environment. Not all of these pros and cons are applicable in standard consolidation environments.
As more cores become available on different system types the advantages and disadvantages may
shift.

18
Table 4. Pros and cons of 2- and 4-socket systems in a VDI implementation.

2 Socket Systems

Pros Cons

Lower risk with fewer VMs per host Can mean more costly memory required for
large memory footprints

Greater number of systems to handle HA failover Full-height blades require a greater quantity of
scenarios infrastructure components such as enclosures and
switches if using greater than 8 hosts throughout
the solution. This will not necessarily be evident
with a small pilot or proof of concept.

Lower power draw per system Fewer cores to schedule on

Excellent scalability Rack systems tend to have fewer expansion slots

for NICs and HBAs

Can reduce per host licensing

Half-height blades require less infrastructure once

you use more than 8 hosts

Lower per VM power draw

4 Socket Systems

Pros Cons

Fewer systems to manage overall Lower scalability can mean more expensive per
VM hardware costs

More cores to schedule on Greater per host power draw

Better memory scalability for large memory VMs Higher per VM power draw

Rack systems tend to have more expansion slots Higher risk with more VMs per host
for NICs and HBAs.

Tend to lead the way with more cores per Fewer systems to handle HA failover scenarios
physical processor which improves scalability

Can mean increased per host licensing

Memory sizing
Ideally, each ESX host will have 4GB of memory per core as a starting point. Undersizing memory
has an effect on levels of memory overcommitment and thus an effect on overall system performance.
When sizing a server, keep the 4GB per core ratio in mind to avoid memory performance issues. For
VMs that have 768MB to 1GB of memory assigned, 4GB per core is likely adequate. As memory per
VM increases, levels of overcommit will likely increase with load. To avoid swapping and potential
performance issues, the amount of memory per core should increase as the amount of virtual machine
memory increases.
Increasing the amount of memory per core or the number of cores will generally increase the number
of users on a system, but scalability is reduced. Four-socket systems will generally not scale as well as
two-socket systems in this environment. 2-socket systems with additional memory per core (while still
following the norms listed above) will begin to exchange memory contention for CPU scheduling
contention.
Similarly, shrinking the resources available to each VM may increase the number of virtual machines
on a host provided that the application suite within the VM functions properly. If a particular suite of

19
applications needs 1GB of memory to function properly it is not conducive to overall performance to
limit those VMs to 768MB.
Increasing the size of the virtual machines from a memory footprint will have the effect of reducing the
number of virtual machines on the host. For VMs with footprints of greater than 1GB of memory you
should configure the server with between 6 and 8GB of memory per processing core. This may alter
the point of contention on a single system from memory to CPU.

Networking
HP recommends that each server be configured with six (6) network interface cards (NICs) where
possible. This maximizes redundancy and optimizes performance. Each NIC should be at least a 1Gb
adapter. For configuration recommendations, see VMware‟s Virtual Networking Concepts document
(http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf). For blade specific configurations,
consult HP‟s configuration white papers at http://www.hp.com/go/vmware/. See also the Network
deployment section of this document.

Moving swap files to other filesystems

Within VMware ESX it is possible to locate per VM swap files on a filesystem other than the one that
is housing the virtual machine itself. This could be done when you are seeking a reduction in space
requirements on Tier 1 or Tier 2 storage and are willing to sacrifice some speed and functionality to
achieve a slightly reduced cost.
There are consequences to placing a swap file on a local filesystem that is different than that of the
virtual machine itself. First and foremost, even though VMotion works, if there are differences between
the locations of the swapfile on the local filesystems of the source and destination hosts, the swapfile
will need to be copied to the new location. This may greatly slow down the migration. If using DRS
this may present an unacceptable tradeoff in functionality.
If for some reason the swapfile location of the migration destination can not be reached, the swapfile
will be copied to the same location as the virtual machine. This would of course begin to negate any
realized space savings. It is best to insure all swapfile locations are accessible and recognizable to
hosts in the POC environment prior to moving to production.
It should also be noted that you must be running VMware ESX Server that is version 3.5 or greater to
configure the storage of swapfiles on local datastores rather than with the virtual machines
themselves.
If the installer decides local swapfiles are acceptable, they may use VirtualCenter to configure the files
to reside locally rather than with the virtual machine configuration files. Thoroughly test the effects of
this move prior to moving the environment into production.

Sizing storage
Storage can be the most perplexing variable in designing VDI. Application patterns, data redirection
and especially virtual machine size all play critical roles in determining the total IO required in a VDI
implementation. In certain circumstances such as a Basic VDI implementation the calculations are
simplified because memory or CPU will become a bottleneck before normal use IO. In that case the
only planning is how to distribute patches and run virus scans in a fashion that will have the lowest
cumulative effect to online users (see Appendix B of this document).
In environments where storage is shared across a large number of users, sizing becomes much more
difficult. Peak user IO will generally be within reasonable boundaries for a given storage system, but
the installer may find that it is impossible to complete virus scans or large patch applications within a
reasonable time period. In these cases, storage sizing is determined by a peak IO rather than a user
IO activity. This is likely in shared storage scenarios.

20
In terms of overall sizing, there are general rules.
 Leave room for swap files on storage.
 Do not sacrifice spindle count for space savings. It is better to have leftover space than inadequate
performance.
 Use the fastest drives available for your storage system. This includes both rotational speed and
drive architecture.

The following sections note specific maxims for different storage types.

Basic VDI
Sizing storage in a basic VDI POC implementation is straightforward. Maximize the number of
spindles per server, use the highest rotational speed SAS drives per server, leave adequate space for
all VMs, swap files and any accessory files and do not use a server with less than an 8 drive capacity
(2 socket. Consider 12 or more drives for 4 socket.) For optimal disk performance, consider adding
on an HP StorageWorks MSA50. Fewer end users per spindle will result in better performance.
Use battery-backed write cache for HP Smart Array Controllers. Maximize available cache for all
controllers. It is okay to share local disks and any expansion disks on a single array controller in a
VDI environment.
Use of RAID10 may help with storage performance, but will hinder space efficiency. RAID 5 is
acceptable in many environments as a compromise. As with other implementations, the goal is to be
able to handle peak IO in a reasonable fashion. As this is direct attached storage, the IO will never
affect a user on another server.
A secondary storage system should be used to redirect user data for this proof of concept. HP offers
numerous options for shared user storage.

Standard VDI
For a 150 user proof of concept, it may be the case that a single AiO storage unit is insufficient to
handle all users and peak IO activity. To optimize the unit for the largest possible IO, insure you
configure the following.
 Use a dedicated pair of NICs on the ESX host server for all iSCSI traffic
 Add an external disk enclosure such as a StorageWorks MSA60 to the AiO in order to maximize
the number of disks
 Add extra NICs to the AiO and team them for optimal performance
 Use a second storage system to redirect user data. This may be another AiO.

Enterprise VDI
Enterprise VDI focuses on utilizing Tier-1 or Tier-2 SAN infrastructure to host the virtual machines and
potentially to host the end user data as well. This will always move the overall solution bottleneck to
the shared storage. For a 150 user POC it may be the case that the bottleneck never appears outside
of peak IO. The data gathered during the POC will still be useful in determining the overall number of
users that the shared storage can support in the installers environment.
There are two aspects to sizing a SAN. The first is the total space required to house the planned
number of virtual machines and their accessory files. The second aspect is to insure there is an
adequate amount of bandwidth available at the port, controller and spindle level to support a given
number of users. The approach within a VDI POC should be to maximize the number of spindles.
Configuration specifics will be listed below for HP StorageWorks EVA and MSA SAN products.

21
EVA
HP StorageWorks Enterprise Virtual Array SANs should be considered with the following minimums
for a 150 user POC. Many of the configuration details below can be expanded on as the
implementation grows. Consider maximizing the SAN prior to POC implementation as it will improve
your ability to predict peak sizing for the installer‟s production environment.
 Redundant controllers in all situations
 Use fastest available disks (rotational speed and type)
 Minimum of 48 spindles (maximize if possible)
 Leave capacity for the cumulative space occupied by all virtual machines, accessory files and
swapfiles
 License HP StorageWorks Command View, Business Copy and Data Protector in all scenarios to
allow for rapid deployment and failure recovery
 Use all controller ports
 Divide IO between external switches

MSA
The HP StorageWorks MSA2000fc provides a cost effective fibre-channel based shared storage
solution for VDI. It is recommended for a 150 user POC that all options for the MSA2000fc are
ordered and configured. This includes maximizing controllers, cabinets and disks along with choosing
the fastest available hard disks and licensing all capabilities. As with EVA based SAN, divide IO
between switches and use all controller ports.

Datastore size
For all storage platforms, it is critical that you size your datastores optimally. The following serves as a
useable formula.
((disk space size for OS and apps x number of virtual machines) + (100-150MB (.1-.15 GB) x
number of VMs for log growth) + (size of memory per VM (in GB) x number of VMs)) + percent
freespace = datastore size.
As an example, if we house 20 VMs using 1GB of memory and 12GB of disk space and wish 10%
free space we would get the following:
((12 x 20) + (.150 x 20) + (1 x 20)) * 1.10 = datastore size
(240 + 3 + 20) * 1.10 = datastore size
263 + 27 = 290 GB

HP suggests that no more than 30 VMs are housed within any given datastore. 20-25 VMs are
generally viewed as optimal.

Deployment steps
Infrastructure configuration
Network Time Protocol servers
Network Time Protocol (NTP) servers should be configured and used in a VDI environment. All ESX
hosts should be pointed to the NTP servers for time synchronization.

22
Network deployment
A best practices configuration for HP BladeSystem c-Class and VMware Infrastructure 3 remains the
same regardless of whether you are implementing VMware for server consolidation, business
continuity or HP VDI. Figure 4 shows the mappings that would create a hardware and software
redundant configuration for a half-height c-Class blade server.

Figure 4. Per server redundant configuration for half-height blades.

Networking within a VDI environment involves both a physical and virtual layer. Each of these layers
must be configured with full awareness of the configuration of the other. This section describes the
best practices for the physical layer. The virtual configuration is described later in this document.

Physical networking
At a high level, there are few hard and fast rules for physical network configuration. The known
imperatives include:
 Network links should autonegotiate to maximum speed and full duplex. If a link does not get set to
these parameters, investigate the switches for potential problems.
 Network latencies for a successful deployment will optimally be below 100ms and should always
be below 150ms. Some customers have run VDI in higher latency environments, but these are for
remote developers where experience is secondary to data integrity. The protocol has an effect on
this. The reference here is to Microsoft Remote Desktop Protocol. WAN accelerators can help with
remote desktop connections. They do not help with voice over IP (VOIP) implementations.
 Datacenter connections should always be a minimum of 1 gigabit.

23
 Desktop connections may be 100Mb or gigabit. Latency and reliability are more important than
bandwidth.
 There should ALWAYS be at least 2 physical adapters per host server tied to the virtual machine
network and teamed for redundancy.

Building the management tools

This section applies to Basic, Standard and Enterprise VDI implementations. Small customizations may
be required for each of these environments and are noted as needed.

Active Directory policies

Implementing Active Directory policies can greatly simplify the configuration of HP VDI virtual
machines. Policy dictates what end users are allowed to do within the environment and in turn how
the environment is presented. There are two primary considerations to take into account when
designing policies. First and foremost is the interaction of policy with the connection broker. Insure
that any and all policies recommended by the connection broker vendor are followed. The second
design consideration is simply the amount of policy applied. Each set of additional policies assigned
to a group carries with it additional overhead at login time. There is a balancing act that you as an
architect need to perform to insure that performance and functionality goals are achieved. AppSense,
an HP partner, offers capabilities in this space that the installer may wish to evaluate.

VMware VirtualCenter
The backbone of a VMware virtualized environment, VirtualCenter allows for fine grained control
over VM creation, performance monitoring, access permissions, license compliance of virtual hosts
and much more. Refer to VMware‟s documentation for proper installation and configuration of
VirtualCenter at http://www.vmware.com/support/pubs/vi_pages/vi_pubs_35.html.

VMware Virtual Desktop Manager

For instructions and considerations about setting up VMware Virtual Desktop Manager (VDM), see the
documents
“Introduction to Virtual Desktop Manager” at http://www.vmware.com/pdf/vdm20_intro.pdf and
VDM ”Installation and Administration Guide” at http://www.vmware.com/pdf/vdm20_manual.pdf.
It is further recommended that the installer familiarize themselves with all of the VMware brokering
documents at http://www.vmware.com/support/pubs/vdi_pubs.html.
HP recommends VMware VDM as the broker when using Microsoft RDP as the display protocol.

Installing the server

Configuration
Configuring the servers and infrastructure is a critical step in the overall success of any VDI
implementation. Adhering to the guidelines laid out in this section and following best practices laid
out by VMware for installing ESX Server will help insure proper operation of all components.

Firmware
Prior to beginning the installation or configuration of any server or HP BladeSystem c-Class
components you should insure that the firmware listed in Table 5 is updated to the latest available and
tested versions (see the firmware compatibility matrix at
http://h18004.www1.hp.com/products/blades/components/c-class-compmatrix.html ). To insure
optimal performance this step should be completed prior to any software installation. The first three
items in Table 5 pertain only to c-Class blade implementations.

24
Table 5. Firmware checklist

Completed Firmware

Onboard Administrator(s)

Virtual Connect Ethernet modules (or network switch)

Virtual Connect Fibre modules (or fibre channel switch)

iLO 2 (Per server)

Array controller (Per server)

Fibre channel host bus adapters (Per server)

Hard disks (Per server)

System ROM (Per server)

Network interface cards (Per server)

iLO 2 configuration
It is recommended that at a minimum, the following settings be configured for the iLOs of each VDI
host server.
 Change the Administrator password
 Add a secondary administrative account
 License any additional features
 Fill in the server name under access options
 Create and authorize required SSH keys
 Generate an SSL certificate and have it signed by an appropriate authority
 Configure directory integration to simplify user access management
 Assign a common name to the iLO under network settings and insure it is in DNS
 Enter the Insight Manager Web Agent URL
 Configure SNMP
 Configure Remote Console settings including any needed shortcut keys

RBSU settings
There is flexibility with some server settings in VDI, but the following should be configured. Access the
ROM Based Setup Utility (RBSU) by selecting F9 when prompted during boot.
 Insure the date and time on the server are correctly configured against an NTP server or another
extremely accurate time source. If at all possible, use an NTP server in the environment.
Timekeeping in virtual machines is a well understood issue. Many timekeeping problems can be
minimized by using NTP servers in the environment.
 Enable hardware based virtualization assistance on platforms.

25
Installing ESX Server
The installer should follow VMware‟s best practices for installing ESX Server
(http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_installation_guide.pdf).
Configuration of the various parameters may occur post-installation or during the kickstart installation
process. Many of these parameters are discussed in the following sections and are exampled using
VMware VirtualCenter.
The installer may wish to experiment with and configure various advanced parameters during or after
the installation. This may be done using VMware VirtualCenter, at the command line or the
commands may be scripted in the kickstart configuration file.
Advanced parameters are changed at the command line using the esxcfg-advcfg command. An
example of the syntax of the command is shown below.
esxcfg-advcfg <action> <value> <parameter location>
The actions may be any of the following:
-g or -get
-s or -set
-d or -default
The value refers to the value of the current setting. This will vary based on the parameter being
changed.
The location will reflect a directory and value name underneath the directory /proc/vmware. When
entering the command manually the /proc/vmware directory is omitted. As an example, to read the
runtime CPU Quantum of the current ESX host, you would issue the following command at the
command line:
%> esxcfg-advcfg -get /config/Cpu/Quantum
This command prints the current parameter value to standard output.
To set the parameter using the kickstart file, you could add the following line:
--esxcfg-advcfg --set 10 /proc/vmware/config/Cpu/Quantum

Post deployment configuration

Following the initial deployment of the server there are a few steps that need to be configured. While
these are optional, they are highly recommended.
 Configure NTP on the host server. NTP is highly recommended in a VDI environment.
 Install any and all patches required on the ESX hosts.
 Install antivirus protection into the service console if desired.
 Insure FTP and Telnet are disabled on the ESX hosts.
 DO NOT ENABLE ROOT LEVEL SSH ACCESS. This is explicitly disabled by default and should be
left alone. Follow VMware best practices for access permissions.
 Configure user access and security for the console and remote logins.
 Configure Active Directory authentication for ESX hosts (http://www.rtfm-
ed.co.uk/docs/vmwdocs/ESX3.x-VC2.x-ServiceConsole-Guide.pdf is one reference source)
 Restrict SUDO (superuser) usage to administrative group members only.
 Set password aging and complexity for the ESX hosts.
 Shut down any unused services utilizing the following command or VirtualCenter
– service <service name> stop

26
 Insure services do not restart if the system is rebooted.
– chkconfig –level 2345 <service name> off

 Increase the console memory from 272MB to 512MB or more based on number of services in the
console and the number of VMs on the host.
 Create a GRUB password.
 Configure the ESXTOP configuration file (see section on Configuring ESXTOP).

Adding hosts to VirtualCenter

Within VirtualCenter you should create a Datacenter and Cluster to house hosts that will be used for
the POC. As this is a small implementation, all hosts may be housed in a single Datacenter and
Cluster as in Figure 5.

Figure 5. Sample cluster VDI Test.

Configuring network adapters manually

If you are not comfortable configuring the network adapters using a kickstart file it is easy to configure
these using VirtualCenter. In our example below, we are configuring three virtual switches with a pair
of redundant ports for each. These adapters are housed in an HP ProLiant DL380 G5 server. Follow
the example below for all hosts in your cluster.

27
Highlight a host in the left pane of VirtualCenter and then select the Configuration tab from the right
pane. Within the right pane, select Networking as in Figure 6. This host has 6 network adapters so
we will follow the practice of 2 adapters per virtual switch to maximize redundancy on all virtual
networks. If you have fewer than 6 adapters, please consult the VMware documentation for best
practices.

Figure 6. The overall network configuration screen.

Click on Properties and you will be presented with a screen as in Figure 7.

28
Click on the Network Adapters tab as we will be adding a network adapter to the Virtual Switch for
the service console network.

Figure 7. Network adapters screen.

Click on the Add button as in Figure 7. At the Add Adapter screen choose a second network port
(preferably on a separate physical card) to complete the virtual switch.
Click on Add Networking from the main screen (Figure 6). You will repeat the previous process to
add a VMkernel network (if needed) for VMotion or iSCSI based traffic and then to add a virtual
machine network. Follow the prompts presented during install and insure you select two adapters per
virtual network.

SAN configuration
This section primarily addresses an Enterprise VDI deployment. If you are deploying Basic or
Standard VDI some pieces of information will not apply.

Note
This section uses an HP StorageWorks EVA4400 as the SAN. Your
configuration steps will be different based on the SAN you utilize.

29
With StorageWorks EVA products, such as the EVA4400, EVA6100 and EVA8100, there are a few
general rules to follow. These are generally restatements of practices from the planning section of this
document.
 Maximize the number of spindles on the controller pair.
 Insure that you are not sending all data through one controller port. Insure you are load balanced
across as many ports and controllers as are available.
 Use vRaid1 or vRaid5 on EVA controllers for all VDI implementations when possible.
 Use 15,000 RPM drives with Fibre Channel drives preferred.
 Pay close attention to your per VM size requirements and do not automatically go for the largest
disk size. If your controllers or the disks themselves become a bottleneck, extra capacity will be
wasted.
 Use one large disk group for all disks.
 Divide the disk group into Vdisks formatted as VMFS (Virtual Machine File System) volumes based
on the following guidelines:
– Use smaller Vdisks with fewer VMs to avoid SCSI reservation issues
– Make each Vdisk visible to all hosts post deployment
– Place 30 VMs or less in each Vdisk

The installer may wish to utilize writeable snapshots during the deployment process. See the
Replicating user virtual machines section in this document.
In practical terms, Vdisks created using the rules above will be between 200 and 500GB.

Network Attached Storage for end user data

The most cost effective option for user data redirection is network attached storage. With NAS, a
CIFS share is created and Active Directory is used to move the users‟ core data folders (My
Documents, Desktop, Application Data and Start Menu). The filesystem behind these shares is
Microsoft‟s NTFS.
Sizing the NAS is a function of:
 RAID level selected
 Number of disks available
 Number of end users per share
 Amount of storage per user
 Number, size and type of IOs per second

In extremely large environments, a solution such as HP‟s Clustered Gateway product offers enhanced
performance, availability and scalability, generally at a reduced cost compared to common NAS
filers. A solution such as this can be scaled using an HP StorageWorks EVA SAN mapped to a group
of servers.
Virus scanning software should be configured on the NAS and scheduled full-system scans should be
completed on the NAS on a regular basis based on your existing policies. Try not to configure full
system scans within VMs.
Roaming profiles are highly recommended in a VDI environment and may be required for some
functionality to work.
If you will be redirecting user data to NAS you should consider adding adapters to the VDI host
servers. Adding adapters will not by itself enhance performance. Rather, segmenting traffic as per
Figure 8 can improve performance by segregating data paths. Placing too many adapters into a host

30
server may become counterproductive. At this time, do not use more than 3 virtual switches for user
data traffic.

Figure 8. Breaking out virtual networks for enhanced performance.

HP recommends customers consider AppSense Environment Manager for Policy and Personalization
management in a VDI environment. AppSense technology enables VDI users to experience a
consistent and personalized working environment regardless of where and how they access their
virtual desktop. Since AppSense dynamically personalizes virtual desktops on access, virtual desktop
image standardization is possible, significantly reducing back-end management and storage costs.
AppSense Environment Manager combines company policy and user‟s personal settings to deliver an
optimum virtual desktop without cumbersome scripting and high maintenance of traditional profiling
methods. Capabilities such as profile migration, personalization streaming, self-healing and registry
hiving combine to provide an enterprise-scalable solution managing all aspects of the user in a VDI
environment.
For more information on best practice user environment management in VDI, please visit
http://www.appsense.com/solutions/virtualdesktops.aspx.

NAS for Virtual Machines

In environments where advanced features such as HA and VMotion are desired but the cost of large
scale SAN deployments can not be justified, Standard VDI is an excellent option. When configured
utilizing affordable HP All-in-One or ProLiant Storage Server storage with expansion drive enclosures,
the cost of achieving higher levels of availability and redundancy are greatly reduced.
Configuring HP All-in-One products for use with VMware is outlined in the document “Using HP
StorageWorks All-in-One Storage System with VMware ESX Server Solution – overview and
configuration guide” at http://h71028.www7.hp.com/ERC/downloads/4AA1-5829ENW.pdf.
A single AiO1200 or ProLiant DL380 Storage Server with 2 MSA60s attached can yield over 4TB of
RAID 10 direct attached storage. Some configurations can be made dual domain capable which
adds an extra level of redundancy.

31
Note
If you utilize a ProLiant Storage Server, you should order the optional
Microsoft iSCSI Software Target.

Direct Attached Storage configuration

Basic VDI utilizing direct attached storage (DAS) is a cost effect way to provide a remotely managed,
secure and consolidated desktop to end users. Sizing environments that utilize DAS is generally
straightforward and consists of the following recommendations.
 Use controllers with battery-backed write cache and as much onboard cache as is feasible. A
controller such as the HP Smart Array P800 controller with 512MB of battery-backed write cache is
an excellent starting point for connecting direct attached disks to a system.
 Use more than one controller for maximum users per storage system. If you will be connecting a
pair of smaller arrays such as MSA50s you may increase system performance and lower risk by
sending IO out separate controllers. Similarly, when using large arrays with multiple connections
you can split IO amongst more than one controller.
 Use the fastest spindles possible. 15,000 RPM drives perform better in VDI environments than
10,000 RPM drives.
 Use RAID1 for VMs if possible.
 Distribute VMs across multiple logical drives. This allows you to better accommodate IO intensive
activities without disturbing all users as you can distribute IO to smaller groups of disks.
 On a RAID 1 logical disk, try to keep a ratio of no more than 7 users per spindle. For example, an
SB40c with 6 drives in a RAID1 configuration may support up to 42 users following this rule. Fewer
users per spindle is better.

HP offers a broad array of servers that feature storage expansion capabilities internally and through
the addition of controllers and external drive enclosures.

Creating the virtual machine storage

The intent of this section is not to inform the installer how to install Microsoft Windows XP, but rather
to discuss how to configure the initial VM, install the OS and patches at a high level and then deploy
the VMs en masse.
This document recommends the MANUAL creation of the first Virtual Machine. This does not
necessarily mean connecting a virtual CD-ROM to the VM and performing a step by step install.
Rather, this means carefully selecting and installing/scripting each software component into the virtual
machine including operating systems and applications. The reason for this is straightforward. A
desktop is a very powerful computing device. As such, most IT shops do not stop and consider
performance for each desktop image. The assumption is that the resources will be there when needed.
For the most part, this is true of all recently released individual desktops.
With HP VDI, numerous “desktops” are competing for access to and utilization of the same physical
resources on the host. As such, scheduled services and scans such as full-system virus scans and
application inventory scans may create bottlenecks on the system even if utilization on the host system
appears low. To avoid conflicts, careful planning of scheduled services and consideration of how
applications will be used should be undertaken and results used to create the initial virtual machine
template.
The remainder of this section assumes an HP StorageWorks EVA SAN for deployment. It starts by
creating a 500GB virtual disk (your size may vary based on sizing procedures within this document).

32
Under Virtual Disks in Command View, create a folder to store the LUNs and snapshots that will be
used for deployment. Highlight the folder and then click on Create Vdisk as shown in Figure 9.

Figure 9. Create a new Virtual Disk in Command View EVA.

33
The assumption is this will be vRaid1 storage for performance. Do not present the Vdisk to any hosts
during the creation process. Once the Vdisk is created, highlight it in the left frame and then click on
the Presentation tab in the right frame. The result should look like Figure 10. Next, click on Present.

Figure 10. Presentation screen in Command View EVA.

Choose a single host as in Figure 11 and then click on Present Vdisk.

Figure 11. Presenting to a single host.

34
If you have not logged into VirtualCenter, do so now. Highlight the server you just presented the LUN
to and then click on the Configuration tab and then Storage Adapters as in Figure 12.

Figure 12. Storage Adapters screen in VirtualCenter.

Click on Rescan in the upper right corner. You may need to do this more than once to see the LUN.
Be patient and wait for the hourglass to disappear before proceeding.
Once the raw storage is visible click on the Storage link. This screen will allow you to present the raw
storage to the host and format it using VMware‟s VMFS filesystem.

35
Click on Add Storage and you will be presented with a new screen as in Figure 13.

Figure 13. Add Storage screen in VirtualCenter.

Be sure that Disk/LUN is selected and click on the Next button.

36
The next screen should present you with the raw LUN as in Figure 14.

Figure 14. Raw disk shown in the Add Storage wizard.

Click on the Next button twice and you will be presented with an option to name the datastore.

37
Choose a name that makes sense. For the purposes of this example we will name the LUN
Master_Disk to match what is recorded in Command View EVA.

Figure 15. Applying a name to the LUN.

You can accept the defaults and click Next through the remaining screens to accept the default file
size and create the VMFS datastore.

38
At this point, VirtualCenter should reflect the fact that there is a volume to store virtual machines on as
in Figure 16. We will use this volume to create our master template in the next steps.

Figure 16. The completed datastore as viewed in VirtualCenter.

Sizing and creating the template

There is no single formula for determining the size of your virtual machines. Best practices for VDI
dictate that user data be redirected to shares for optimal sizing and performance, but some space still
needs to be left for profile information on the local disk. HP suggests the following minimum formula to
determine the overall size of the C drive in an environment where user data is redirected. The user
should be prevented via policy from saving files on the desktop in these configurations.
VM size = ((5GB + App size) * 1.10)) * 1.15
1.10 represents a nominal 10% space to allow for the copying of profile data to and from the end
user‟s environment.
In an environment where user data is left local on the C drive (deployments without a load balancer
and with limited redundancy and availability) the sizing process is simpler.
VM size = (5GB + App size + User Space Allocated) * 1.15
In both cases 1.15 represents a nominal 15% space overhead to account for patches, service packs
and OS refreshes over time along with extra space for swap files. If you will create VMs with larger
memory footprints or plan on going extended periods of time between recreating virtual machines you
may wish to leave more space on a per VM basis.

Help – I made my C drive too small

Note
It is a best practice to keep the VM as small as is feasible. The larger the
VM, the longer it will take to scan and patch. The ability to scan 500
12GB virtual machines in a week during off peak hours may be feasible,
but it may become impossible if those VMs are increased in size to 25GB.

39
A common issue seen in VDI deployments is virtual machines running out of space on their C drive.
While it is possible to recreate virtual machines in an environment where all user data is pushed off
remotely, it is not always advisable and in fact may result in domain issues or other serious problems.
The chief purpose of a POC or pilot implementation is to locate and target issues when they can be
easily remedied. Assuming you are in POC and have realized your VMs may not contain enough
space you can use the following steps to resize the C drive of both the template and individual virtual
machines. Follow these steps for each VM.
1. In VirtualCenter, shutdown the VM in question. Right click and select Properties. Click on the virtual
hard disk that represents the C drive and change the size to the desired size. Boot the VM. Watch
the task area in VirtualCenter to insure it completes.
2. Shutdown the virtual machine once the resize task is complete. It will remain shut down and
inaccessible throughout the remaining portion of the process.
3. Backup the VMDK (virtual hard disk) file in the virtual machine‟s directory on the VMFS filesystem.
There are numerous ways to accomplish this including simply making a copy on the same
filesystem, backing up to tape or even copying the files to lower tier storage.
4. Create a new VM running Windows XP with the same service pack as your existing virtual
machines.
5. Prior to booting the new VM, add a hard disk to its configuration under properties. Instead of
creating a new hard disk, choose to mount the C drive of the VM you wish to expand. You may
choose to mount multiple hard disks but this has not been tested.
6. Boot the new VM and log in as an administrator.
7. Launch a CMD prompt and type in „diskpart‟ at the command line. This will launch the diskpart
program.
8. From within diskpart, type „list volume‟. Locate the volume number of the C drive(s) from the
original VM(s). Record the volume number(s) below.
C Drive 1 Volume: __________________ C Drive 2 Volume: __________________
C Drive 3 Volume: __________________ C Drive 4 Volume: __________________
C Drive 5 Volume: __________________ C Drive 6 Volume: __________________
9. Type „select volume #‟ (Where # is the volume number from step 8)
10. Type „extend‟.
11. Shut down the new VM and detach the resized C drive(s).
12. Boot the original VM and login as an administrator. You should see the sizing change reflected in
the VM.

40
VM configuration steps
After the virtual machine has been created but prior to installing the operating system you will need to
disable the virtual serial ports. From the virtual machine console, press F2 during initial boot. This will
bring up the VMBIOS screen. Use the arrows to navigate to the Advanced tab and select I/O Device
Configuration as shown in Figure 17.

Figure 17. VMBIOS screen Advanced tab with I/O Device Configuration highlighted.

41
Press enter and select Serial port A. Use the + and – keys to change the setting from Automatic to
Disabled as shown in Figure 18. Repeat this step for Serial port B.

Figure 18. Disable Serial ports in the VMBIOS.

Once disabled, press F10 to exit and save settings. The virtual machine will reboot and PXE Boot to
the RDP server, virtual CD-ROM or physical media.

Redirecting devices
If you will allow the redirection of devices such as printers and USB keys from the end user access
device it is important to insure the virtual machines are configured to address those devices. Remote
Desktop Protocol will see storage devices as simple containers and these generally do not require
customization of the VM image. Printers however may require that the manufacturer supplied driver or
a universal print driver be installed to address a locally attached and redirected device. The time to
ascertain these requirements is during the creation of the initial golden master VM and not after. The
master VM should contain any and all required device drivers.

OS customization
A standard deployment of Windows XP Professional is not a good place to start a VDI implementation
from. Extra resources that are unneeded and generally create little or no overhead on a physical
desktop may quickly reduce the number of VMs per host in a VDI implementation. It is recommended
that the following settings be changed within the Windows XP Professional based VDI VMs as shown
in Table 6.

42
Table 6. Recommended VM tuning parameters.

VM Tuning (Recommended) Turn off pagefiles and system restore.

Disable any unnecessary services. Common recommendations for services to disable
include the Windows Fax/Telephony service and Windows XP themes.
Insure VMware Tools is up to date and matches the version of the host server.
Set VMware Tools to Sync time to the host and disable Windows time update.
Change screen savers to blank screens or disable them altogether (may cause a
security concern in some environments).
Disable the logon screen screensaver in the registry.
Disable any theme enhancements within the registry.
Insure that there are no virtual CDs or floppies connected to the virtual machines post-
install.
In the Advanced performance section of the system properties on the VM, insure
“Adjust for best performance” is selected.
Set “Launch desktop as a separate process” in the registry to a DWORD value of
00000001.
Disable system restore in dynamic environments.
Do not enable indexing on the virtual hard drives.
HKEY_CURRENT_USER\Software\VMware, Inc.\VMware Tools and set ShowTray
equal to 0
In the local computer policies set Terminal Services color depth to 24-bit.

VM Tuning (Optional) Use an NTP server for the VMware host that is time synched as closely as possible with
the Windows domain the VMs will be a part of.
VMware recommends disabling CTRL+ALT+DEL at the logon screen. This is not viewed
as critical.
Remove drivers and disable services for unneeded devices such as wireless adapters
and modems.
Create single vCPU VMs unless software or display protocols call for more.
Disable wallpapers if you are not allowing desktop personalization.

AppSense may provide ways to simplify some of these steps. Consult the AppSense documentation if
you have decided to implement it within your VDI environment.
Insure that you have defragmented the C drive of the template before it is permanently converted to a
template.

Replicating user virtual machines

Do not begin replicating virtual machines until you are positive you have the base image optimized
and all registry settings configured. Once you have done this and created a master template that has
been sysprep‟d you may proceed with mass deployment. This section discusses two approaches to
mass deployment but recommends that storage snapshots be used. You should understand the steps
and requirements in the templating section even if you will use snapshot deployment as some
templating is required to complete snapshots.

Templating
The use of templates for the deployment of virtual machines is a time tested methodology that is highly
functional in many environments. Because VDI tends to be deployed very quickly, with a large number
of VMs per host and on a dedicated set of storage resources, templating may actually be a detriment
to deployment.

43
VMware limits the number of concurrent template based deployments to 8 per VirtualCenter server.
Depending on the resources used in deployment and the size of the virtual machines, this could take
30 minutes or more to deploy 8 virtual machines. For a VDI deployment of 1500 users it becomes
obvious very quickly why this is not a practical approach to mass deployment. Templating should be
used when there is no SAN.
To configure the initial template for VDI mass deployment you will need to run and configure the
Windows Sysprep tool included on the Windows XP tools. Insure that you have Deploy.cab from the
Windows XP Professional CD expanded to the local template hard drive. In our example it has been
expanded to c:\sysprep. To begin, use VirtualCenter to convert your template to a virtual machine.
Once converted, log in as administrator and click on Start -> Run. In the Run dialog type in
c:\sysprep\setupmgr.exe. This will launch the Setup Manager tool as in Figure 19. You can use this
tool to create an answer file for unattended setup of Windows XP VMs.

Figure 19. Introduction screen to Setup Manager.

Click on Next and then choose Create New at the next screen. Click on Next to proceed to the Type
of Setup screen. You will choose Sysprep Setup at this screen. Choose the following options in the
remaining screens.

44
Product Windows XP Professional

License Agreement Yes, fully automate the installation

Name and Organization Enter a name and use a 3-5 digit extension that reflects the purpose
of this template for the organization. This will cause the automatically
generated hostname to begin with the extension and will make the
virtual machines easy to categorize within the broker.

Display Settings Accept the defaults

Time Zone Enter your specific information

Product Key Enter your specific information

Computer Name Automatically generate computer name

Administrator Password Enter your specific information

Networking Components Enter your specific information

Workgroup or Domain It is recommended that you stay in a workgroup for now if you plan
on changing the names of the virtual machines via script after
deployment. Place the machines in the domain if you are okay with
the automatically generated hostname.

Choose your specific settings for the remaining screens.

When done, choose a location to save the .inf file that is generated.
Press Cancel once the file has been created.
Click on Start -> Run and type in c:\sysprep\sysprep.exe. Click on Ok to bypass warnings. At the
main sysprep screen, under Options, click on Use Mini-setup and then click on the Reseal button.
Sysprep will run and the system will shutdown.
Once the system is powered off, convert it back to a template.
Open VirtualCenter and switch to the Virtual Machines and Templates view as in Figure 20.

45
Figure 20. Master template in the Virtual Machines and Templates view in VirtualCenter.

Right click the template and choose to Deploy Virtual Machine from this template.

46
At the resulting screen assign a name to the VM to be created and place it in the main Datacenter as
in Figure 21. Click Next when done.

Figure 21. Template creation process step 1. Naming and assigning a Datacenter locale to the VM.

47
Next, place the virtual machine in the appropriate cluster as in Figure 22. Click Next when done.

Figure 22. Cluster selection in VirtualCenter.

48
Choose the master host as in Figure 23 and then select Next to continue.

Figure 23. Host selection screen.

49
Next you should choose to place the virtual machine on the main Datastore that is presented to the
host as in Figure 24. Select Next to continue.

Figure 24. Datastore selection screen.

50
Next, you will be prompted to choose how to customize the VM. Choose Do Not Customize at the
customization screen. The virtual machines created from this template will run Mini-setup and
automatically name themselves and create a new SID.

Figure 25. Main customization screen.

Accept the defaults on the remaining screen insuring that you do not choose to power on the virtual
machine after creation. Click on Finish.
If you are deploying to local storage, repeat the template deployment process until the main Vdisk is
filled. If this is a shared storage environment, proceed to the next section on storage reductions and
snapshotting.

Storage reductions and snapshotting

Storage replication as a method of deployment is extremely efficient but frequently misunderstood.
The first benefit that comes to mind for many is a reduction in capacity and storage required. It should
be noted again that this storage reduction does not generally refer to a drastic reduction in the
number of spindles required. Spindles are still necessary to handle peak load IO operations such as
inventory scans, virus scans (in environments that can not get around them), large scale patch updates
and other forms of heavy IO. The overall cost thus remains the same or is only minimally reduced by
using space efficient snapshots. Secondly, the white space left by spindles is not available to be
presented to other entities. It can and will fill up over time as users write data and commit individual
changes over time. This effect can be reduced by redirecting user data off to secondary or tertiary
storage technologies, but it can not be eliminated entirely. A properly sized VDI implementation will

51
maximize the storage and thus leave no IO for other applications. In other words, peak IO in a VDI
environment will produce a bottleneck at either the port or spindle level.
The following example of snapshot based deployment uses an HP StorageWorks EVA4400 with 48
drives. Every step of this deployment is described and carried out in a manual fashion. The vast
majority of this installation can be scripted. The manual process is described to provide the installer
with a complete understanding of the steps required and the order in which they need to be
completed. VMware Virtual Desktop Manager is used as the connection broker for this example.
Figure 26 is taken from HP StorageWorks Command View software and depicts our EVA with one
default disk group that includes all spindles. This is the recommended base configuration when using
snapshot based deployment of VDI virtual machines. The screen also shows that we have added our
host servers and created a folder for our VDI virtual disks as described earlier in this document. We
will use the 500GB LUN that contains our template VM and the presentation host that the volume is
mounted to.

Figure 26. Command View EVA showing the starting storage layout for our deployment.

52
Switch to VirtualCenter on your screen. Click on your presentation host in VirtualCenter and click the
Configuration tab. A new window appears. Highlight LVM as in Figure 27 and set the value for
LVM.EnableResignature to 0.

Figure 27. Enabling LUN resignaturing on the master host.

Note
Do not turn resignaturing on or present the volume to any host other than
the presentation host.

53
Filling the first Vdisk with VMs
Figure 28 shows the Vdisk that will be used for mass deployment. At present the only things that
reside on this LUN are the template (or templates) that has been sysprep‟d for mass deployment and
the associated configuration files for that template.

Figure 28. Master Vdisk housing the template.

To prepare for mass deployment we will actually return to the prior section around Templating. Follow
the steps in that section to fill the master Vdisk with sysprep‟d VMs. As a reminder – DO NOT
POWER ON THE VMs ONCE THEY ARE CREATED. Once you have filled the Vdisk return to this
section and proceed with the next steps.
At this point you have a master Vdisk that is filled with sysprep‟d virtual machines. HP StorageWorks
EVA with Business Copy gives you the ability to make writeable snapshots of each of these LUNs.
Each Vdisk may have up to 16 snapshots. Because of the capacity of our system and our limited
number of hosts we are planning on approximately 152 virtual machines on our SAN. Our VMs are
25.2 GB each and our main LUN is 500GB. We have deployed 19 templates into our master Vdisk.
To achieve 152 virtual machines this means we will need 152/19 500GB datastores or 8 total
datastores. Including our original datastore this means we will need 7 snapshots. If your sizing works
out to more than 16 snapshots, you should make a second and potentially even third master disk.

Note
If you are hosting multiple types of VMs (different application loads) you
should create a master Vdisk for each type.

54
Note
The sizing used for this section is for illustrative purposes and should not be
taken to represent a real world deployment.

While we have not exceeded the maximum number of snapshots allowed for our individual Vdisk, we
will create a second Vdisk to snapshot as an example. It should be evident at this point that creating a
new Vdisk and creating another 19 templates manually is a time consuming process that you likely
will not want to repeat. We will use Mirrorclones instead to replicate our original Vdisk (this could be
done numerous times depending on the number of master Vdisks you need).
To begin, highlight the Folder in Command View that houses your master Vdisk and select Create
Container as in Figure 30.

Figure 30. Create Container under the main VDI folder in Command View.

Set the name of the container to something easily recognizable.

55
Then set the size and vRaid level to match the original LUN as in Figure 31.

Figure 31. Name and size the container appropriately.

Once done, click on Create Container.

56
Highlight the original master disk in Command View and choose to Create Mirrorclone. Figure 32
shows the resulting screen. At this screen, choose a name for the clone and select the container you
created in the previous step. It will take some time for the original master disk to clone. Be patient.
You may highlight the mirrorclone in Command View and monitor the resync progress to determine
when to proceed.

Figure 32. Associating the container to a source LUN during Vdisk Mirrorclone.

57
Once complete, the mirrorclone is an exact replica of your initial Vdisk housing the same 19
sysprep‟d virtual machines. Figure 33 shows the screen after the mirrorclone completes. Select
Fracture within Command View. A warning will appear. Click on Ok to disregard the warning.
When the fracture executes you should see the Write Cache Actual change from Write-back to Write-
through. Requested will still read Write-back. This is expected behavior.

Figure 33. The completed mirrorclone.

58
Click on Detach and dismiss the warning. Figure 34 reflects what has now become 2 identical Vdisks
within Command View. Select the Vdisk that was created from the mirrorclone and click the
Presentation tab. Present this Vdisk to the master host.

Figure 34. The mirrorclone is now an independent Vdisk.

Once the cache has been flushed you should see the Actual state change to Write-back.
In VirtualCenter, rescan the master host to detect the new Vdisk (return to the Hosts and Clusters view).

59
Figure 35 reflects the new LUN which is presented as a resignatured snapshot to the main host. It is
recommended that you change the name of the snapshot to match the Vdisk name in Command View.
To do this, simply right click in the VirtualCenter storage configuration screen and select rename.

Figure 35. The mirrorclone shown as a presented snapshot. Change the name to reflect the Vdisk name.

We now have all of the files needed to present 38 virtual machines to our primary host. Our goal
however is to have at least 152 virtual machines. To rapidly produce a large number of virtual
machines we will create snapshots using Command View with Business Copy.

60
Within Command View, highlight the original Vdisk (Master_Disk in this example). Click on Create
Snapshot and provide an easy to associate name as in Figure 36. Do not choose to present the
snapshot to any other hosts at this time.

Figure 36. Snapshot parameters screen in Command View.

The snapshot is created in a matter of seconds. You will notice that the snapshot shows as occupying
no space on the EVA. This will be true until the file is powered on and a change is made to the file.
The file will slowly grow over time until the maximum VM size is allocated. This is normal and
expected.

61
Choose to present this LUN to the master host and then perform another storage adapter rescan. The
snapshot will show up as a volume named “snap-*” just as the mirrorclone did. It is once again
recommended that you right click and rename the snap to reflect the naming in Command View.
Figure 37 reflects the snapshot in its final state within VirtualCenter.

Figure 37. The first snapshot renamed and presented to the master host.

62
Repeat this process on each Vdisk until you have a sufficient number of snapshots that contain enough
files to equal your total number of VMs. In our example we created 3 snapshots on our original Vdisk
and 3 on our mirrorclone as reflected in Figure 38. This gives us 8 total datastores with 19 virtual
machine files for a total of 152 VMs.
Since all datastores are the same size and contain the same file names it is recommended that you
rescan each time you create a snapshot to insure that you can easily rename and keep track of the
subsequent datastores.

Figure 38. The final view in Command View with 2 Vdisks and 6 snapshots.

63
Figure 39 reflects the final view in VirtualCenter with all 6 snapshots and 2 Vdisks presented to the
master host and renamed within VirtualCenter.

Figure 39. The final view in VirtualCenter with all 8 datastores presented and renamed.

In the Advanced Settings for the master VM, set LVM.EnableResignature to 0. This will turn off
resignaturing. Do this only after you have successfully presented and renamed all mirrorclones and
snapshots on the master host.
In Command View, insure that each Vdisk and snapshot is presented to each host in the cluster. Once
you have presented all Vdisks and snapshots to all hosts, rescan the adapters of each host to detect
the new datastores. You may need to rescan more than once before the volumes appear.
We now have 8 datastores with 19 registered VMs from our original master disk. During the template
process we made sure our VMs generated their hostnames. This means when we register and start the
VMs they will have their own hostnames at startup that begin with their broker group extension.
If we were to register the VMs at this point we would have a serious management issue. Each of the
sub-directories on our snapshots and Vdisks is identical as are the files within these directories. By
registering the VMs now we would have multiple VMs with the same display name in VirtualCenter.
From a tracking and management standpoint this is extremely difficult to work with. You will need to
make some simple changes to insure that the virtual machines are displayed separately and can be
traced back to their source.
To avoid display issues with repetitive VM names we need edit the VMX file for each virtual machine.
The VMX files are located in the directory /vmfs/volumes/id/vmname where id is the unique
identifier of the virtual machine datastore and vmname is the name of the original virtual machine.
Run the following commands to view your datastores.
%> cd /vmfs/volumes/
%> ls

64
The results should resemble the following.
473b2f06-7bbd4b00-1d62-001a4bcd5dea Master_Disk
489b4dd4-d33bc120-87e6-001635c5afda Master_Disk_Cl
48a0b99c-98f01d20-b36e-001635c5afda Master_Disk_Cl_SS01
48a0c433-96f86908-4624-001635c5afda Master_Disk_Cl_SS02
48a0c724-e838a588-414d-001635c5afda Master_Disk_Cl_SS03
48a0c8a1-830aea88-901f-001635c5afda Master_Disk_SS01
48a0cb3d-4c46f5f0-6e5d-001635c5afda Master_Disk_SS02
48a0cc4f-c54ca4a8-d598-001635c5afda Master_Disk_SS03
48a0cd65-78c16580-21a4-001635c5afda storage1 (1)
We will need to change into each directory. You may use a single host to access and rename all files.
%> cd /vmfs/volumes/48a0b99c-98f01d20-b36e-001635c5afda /
Within this directory you will find a series of sub-directories that match the names of your virtual
machines. These subdirectories will be identical within each datastore because of the replication
techniques used. Change into each virtual machine directory and open the *.vmx file for the virtual
machine using vi or another editor. Within the file, locate the following line (the name within quotes
will reflect the parent directory name).
displayName = "vm-xp-003"
Change the name within quotes to the name that appears in VirtualCenter. It is recommended for now
that you change the name to reflect the datastore the VM resides on. This VM is on our SS01
snapshot so we will change the line to read
displayName = "vm-xp-003-ss01"
You can do this via sed with a command similar to the following.
%> sed -i "/displayName/s/vm-xp-001/vm-xp-001-ss05/g"
"/vmfs/volumes/Master_Disk_SS05/vm-xp-001/vm-xp-001.vmx"
This in turn can be placed into a script to touch all of the files.

VM registration
Once all display names have been renamed you will need to register each VM to a host. You can use
VirtualCenter to perform this action or simply script the following command for each VM.
vmware-cmd –s register
/vmfs/volumes/volumename/vmfoldername/vmfoldername.vmx
Be sure to use the exact name of the vmx file to register the vm.
As a best practice, you should not run this command for all VMs on all datastores on a single host as
the VMs will then become registered to that host. However, for the sake of simplicity you may wish to
register all VMs for a single datastore to a single host. In our example there are 8 datastores and 4
hosts so we may choose to register VMs for a pair of datastores to a single host and then move to the
next host for the next pair of datastores. Remember that it is easy to migrate VMs between hosts once
they are registered so it is not necessary to be concerned about any patterning effects at this time.

Powering on and finalizing VMs

Once done with registration you should show 152 virtual machines spread across your hosts within
VirtualCenter. You may use the VMware VI Toolkit for Windows or simply use VirtualCenter itself to
power up all of the VMs. You should expect this process to take some time. Each VM must run sysprep

65
which is IO intensive and each must go through an individual boot process. You may wish to stagger
VM boot up into groups of 15 virtual machines.
If you have decided to change the names of the VMs via script or using a program such as HP Rapid
Deployment Pack you should do that now. If you are allowing the automated naming with fixed
broker prefix as in the example you will find all of your VMs need to be joined to Active Directory to
be made ready for final tuning via policy. Proceed once the VMs are in Active Directory.
Note that VMs based on the same files are indeed different. They have different identifiers and
individual MAC addresses.

Extra space
As noted earlier, in many cases you will note a considerable amount of unused space on your SAN
post deployment. This is expected. In the example in this paper, we have 152 25GB virtual machines.
After startup and sysprep they occupy less than a terabyte of storage. In raw form they would occupy
nearly 3.8TB of storage. It is important to note that sizing is according to spindles and not raw disk
space. You need spindles for performance so space savings does not equate to extra useable space.
The amount of extra space can be defined in two ways. The first is to simply monitor how much is left
after mirrorclones and snapshots have been brought online. This ignores the fact that much of the
space you have allocated will fill in over time. The proper way to determine remaining space is to
subtract the amount of space that can be used based on the VM size multiplied by the number of
VMs. This will reflect the maximum used capacity at some future point in time. This is generally a
much smaller amount of free space.
Just because there is extra space does not mean it should be used. At this point, prior to activating
and monitoring the POC it absolutely should not be used. Non-VDI applications that make use of
these spindles will have unintended consequences. Adding applications during the POC will insure
that you are never able to grow beyond the 150 users involved in the POC without purchasing a new
SAN. Over time, with proper monitoring and as the POC expands into production you may find that
there are times of day or week when there is extra capacity available on the EVA. It may be possible
at that time, with careful planning, to utilize that capacity for other applications.

Proof of concept evaluation

Collecting and evaluating performance measurements post deployment
HP recommends that during an initial evaluation the administrator pay close attention to a number of
performance metrics at the SAN, server and hypervisor layers of the solution. This section outlines the
configuration of ESXTOP for performance metric gathering and discusses common bottlenecks and
how to identify them. Once in a virtual machine, standard performance analysis tools are of very
limited use for problem identification and resolution. See the planning section of this document for
steps to avoid difficult to trace performance issues.

Configuring ESXTOP
In order to configure ESXTOP, you will need to log in to the console as a user with permissions
sufficient to run the tool. To create the necessary configuration, launch esxtop from a command line as
follows.
%>esxtop
Figure 40 shows the main ESXTOP screen.

66
Figure 40. ESXTOP main screen.

Once you have started ESXTOP you may change screens by typing c (CPU or the default screen), n
(network), m (memory) or d (disk). Each screen gives you real time monitoring capabilities. If real time
monitoring is what you are after then VirtualCenter lends itself to visual data analysis and should be
used. What we are after is the ability to do long term, time based comparisons of data sets.
Within each screen (CPU, memory, storage adapters, storage devices, vm storage and network, or c,
m, d, u, v, n), you may type in “f” in order to see a list of optional fields that may be collected. Figure
41 shows these fields for the network screen.

Figure 41. ESXTOP fields for the network screen.

To activate a particular field, simply type in the letter of the field. When active the “Current Field
order” at the top of the field selection screen will show the field as a capital letter. When inactive it is
lower case. HP‟s recommendations for initial data capture will be discussed elsewhere in this section.

67
Besides individual fields, you will also need to set a data collection interval or the interval in seconds
at which ESXTOP reads samples. To do this, type in “s” from the main screen and enter a number in
seconds. Data collection files can become quite large, especially with the initial recommendations set.
Increasing the number of seconds between collections can reduce the file size, but it may be
detrimental when trying to ascertain the effects of VM booting and user logins without the use of a
fibre channel analyzer or network sniffer. 5 seconds is a good initial interval.
When you have selected the fields you wish to capture and set the interval for samples, you may type
“W” to write the configuration to a file called “.esxtop350rc” (based on version of ESX). Note that
the W is capitalized.
Type “q” to exit ESXTOP. You may view your .esxtop350rc file by typing
%>cat .esxtop350rc
HP‟s initial .esxtop350rc file looks as follows.
ABCDEfgh
aBCDefGHijklMno
ABCDEfgHIjklm
ABCdeFGhijk
ABCDEfgHIjk
ABcDEFGHIJKLm
5n
Each row corresponds to performance counters or fields that can be collected as outlined earlier in
this section.
To launch ESXTOP in batch mode using the configuration file you saved, type the following.
%> esxtop –b > file_to_save_data_to.csv
The CSV file is as named, a file that you will write the collected data to for further analysis.
A major benefit to using ESXTOP for data collection is that it is configured to produce output that is
readable in perfmon. This makes data analysis and visualization simpler for Windows administrators.

68
Configuring perfmon to analyze ESXTOP data
To launch perfmon on any Microsoft Windows system, simply click on Start -> Run and type in
perfmon. Click on Ok. Figure 42 shows the initial perfmon screen.

Figure 42. Windows performance monitor default screen.

By default, perfmon collects and displays real time data for the system it is running on. To load
perfmon data, right click in the graph window and select Properties. The resulting window appears as
in Figure 43.

69
Figure 43. Perfmon properties window.

70
Click on the Source tab. Click on the Log files radio button and then select Add. This will allow you to
browse for your ESXTOP data. Figure 44 shows the screen after selecting a file.

Figure 44. Perfmon source window.

Notice that the time range slider is still available as it would be with standard data collection.
If you select the Data tab, you can now choose to add data points from the ESXTOP data set to
graph. It is beyond the scope of this document to explain each data set and what the values mean.
Other sections in this document discuss commonly used statistics. VMware offers extensive
documentation on tuning and monitoring ESX and this documentation should be consulted regularly.

71
Figure 45 is a sample graph showing %Ready vCPU values for a single virtual machine.

Figure 45. Perfmon graphing ESXTOP data

Identifying performance issues

If we exclude shared storage, performance issues generally fall into one (or more) of two categories.
Server based bottlenecks and virtual machine configuration issues. This section discusses approaches
for identifying and working with both types. It is assumed that other issues were removed during the
planning phase.

Server based bottlenecks

As with any server based solution, there are 4 systems that should be monitored for bottlenecks. Not
all of the subsystems (CPU, memory, network and disk) are as susceptible to overflow in VDI as they
are in a standard application environment.
The most likely sources of bottlenecks within VDI are CPU and memory. When memory per core ratios
drop below 4:1 the chance of a memory bottleneck increases. Assuming adequate amounts of
memory (4+ GB per core) at the host and properly planned per VM memory allocation the most likely
culprit for a bottleneck shifts to the CPU.

72
CPU bottlenecks may not be readily viewable with traditional absolute utilization based counters such
as CPU percentages. Figure 46 shows the CPU performance of a single host during normal periods of
utilization. The peak utilization stands at 45 percent with a very reasonable average of 34%. This
average for many applications would not be cause for concern, especially given that host memory
utilization on this system is very much within reasonable boundaries.

Figure 46. Overall CPU utilization rates for a single host system.

73
Figure 47 contrasts the view of acceptable CPU utilization rates with the percent ready values of
selected VMs on the same host at the same time. While the average percent ready value of 4 will
likely be acceptable, it is possible and potentially even likely that the extended periods of values over
10 could become noticeable to end users as momentary episodes of sub-standard performance. In
essence, this system is approaching saturation at 34% average CPU utilization (these are users with
high activity levels on simple applications). If it were used in a cluster with VMware HA active it might
need to be capped at or below this level to insure resource availability in the event of a host failure.
This suggests heavily that using absolute CPU utilization as a planning factor is not always the best
approach to sizing servers and determining when thresholds have been reached. The better statistics
to look at are those that will tell you when lower level scheduling issues are occurring or may soon
begin to occur.

Figure 47. Potentially excessive percent ready values over the same timeframe as the CPU values presented in figure 46

Once the POC is in place it is generally possible to identify and potentially redistribute the heaviest
users contributing to a CPU oversubscription scenario.
If you are detecting values that are of great concern reduce the number of users per core on the
individual hosts.

Virtual machine configuration issues

The end user experience is generally seen as the proof of how well the solution is performing.
Unfortunately when that experience is not acceptable, the instant reaction is to assume that the issue is
in the virtual machine configuration. Generally speaking if you follow the tuning suggestions in the
install guide you likely will not see performance issues that are attributable to VM configuration. There
are tools available to gather per VM statistics such as Veeam‟s nWorks Connectors for HP Operations
Manager and Microsoft System Center Operations Manager and MOM 2005.
Prior to delving into a per VM analysis, if you believe there are issues with your VM configuration you
may wish to attempt the following.

74
1. Check to insure all best practices were followed in creation including inspecting production VMs to
insure settings created during the template process remain configured as intended. Pay particular
attention to screen savers and services that are running.
2. Use ESXTOP data on a per VM basis to look at cumulative counters. Compare these counters to
your original desktop data captures to look for anomalies. If the VM performance patterns (not
absolute numbers) look similar to the desktop performance over similar timeframes and activities
the VM configuration may not be the issue. If there are substantial differences investing in tools
that run within the virtual machines may very well be worthwhile.

Summary
This document describes many of the steps and caveats in designing, deploying and optimizing VDI
for a 150 user pilot or POC implementation. It seeks, along with other documents from HP and
VMware, to assist the installer with completing the implementation in an optimized fashion that
balances performance and computing needs. The approach to meeting these goals is to point out
caveats the installer may miss, recommend steps that should improve overall performance and make
suggestions on approaching issues that may arise during implementation. The installer should seek the
latest versions of all documents prior to beginning the install. Improvements arise quickly with
emerging technologies and should be considered for inclusion.

75
Appendix A – Desktop inventory categories

Hardware Notes

End user Record who the unit currently is used by, their group and job function

Processor speed Record the desktop CPU speed and model

Memory Record the amount of memory within the PC

Hard Disk Size Record the actual size of the hard drive

Hard Disk Used Record the percent of the disk used

Record the number of monitors. More than 1 monitor should trigger the need for justification
Number of monitors
of resource use

Monitor Description Add a description for each monitor

Make note of whether or not a local printer, scanner or other device is present. This again
Local devices present
should trigger the need for justification of resource use

Device description Make complete descriptions of any devices attached to the desktop

CD Burner Does the user have a CD or DVD burner and is it regularly utilized for corporate purposes?

Record applications installed on the system including Windows applications such as

Applications
HyperTerminal that would not normally be installed during a corporate desktop install

Leave a space for any user comments. Are there performance issues with the current system?
Comments
Are they receiving warnings?

76
Appendix B – Understanding virus scans in a VDI
environment
As mentioned elsewhere in this document, traditional full system virus scanning creates a number of
potential performance issues in VDI environments as they exist today. Best practices for virus scanning
in a VDI VM would be the following:
1. Virus scanning software should be installed in the VM.
2. The local VM should not be fully scanned.
3. Users should be forbidden from kicking off a local system scan.
4. Real time virus scanning should be turned on.
5. User data is redirected to a NAS/scalable fileshare which runs virus scanning software. The NAS
should be scanned using a full-system scan on a regular basis.
6. Where possible, utilize technologies that address VDI such as on access scanning from McAfee.

If you are following these best practices, it is likely that peak IO will be introduced into your
environment from a different source such as patch application. If however you must scan then it is
important to understand what this does to your overall environment. In either case, this section is
useful for understanding the effects from various IO sources.
This section offers methods for incorporating scans and other peak IO activities into your overall
sizing plan. You may wish to incorporate other methodologies and considerations into your planning.

Virus scans and end users

The end goal of VDI is to provide a manageable, cost effective desktop experience to end users. As
long as this experience mirrors or improves upon the experience of their traditional desktops, end
users should remain satisfied. Minimal virus scans during work hours would have little to no negative
effect on the majority of end users if storage is not shared on a large scale. Once this shared element
is introduced into the environment, off peak hour scanning needs to be considered to insure any
negative effects are minimized while maximizing security measures.

77
As a rule, end users will not notice a pronounced effect from the scans from a CPU standpoint until all
CPU cores have scheduled virus scans occurring on them. This effect may in fact be very limited.
Figure 48 shows the effect of 5 concurrent scans on a system with 8 CPU cores. There are no
elevated percent ready values and overall CPU utilization (not shown) is reasonable. During off peak
hours a minimal number of users could utilize this system from a CPU standpoint.

Figure 48. CPU %Ready values for 5 concurrent virus scans

78
Once a single host moves beyond concurrently scanning a number of VMs equal to its number of
cores the end user experience may become unpredictable as demonstrated by Figure 49. The system
depicted in Figure 49 is saturated and unusable from an end user standpoint.

Figure 49. CPU %Ready values for 10 concurrent virus scans across 8 processing cores.

For a full discussion of percent ready values, see VMware‟s document “Ready Time Observations” at
http://www.vmware.com/pdf/esx3_ready_time.pdf.
Aside from large scale testing used in the creation of this document, small scale testing has indicated
that percent ready values that appear sustained above 20% for even short time periods in a VDI
environment begin to have an unfavorable impact on end user experience from a CPU standpoint.
This discussion only accounts for CPU. In a basic VDI architecture using direct attached storage it
should be feasible to apply these rules on a per system basis so scans will not interfere with end users
or will present only a minor inconvenience. Once shared storage is introduced, CPU issues as a
central contention point are unlikely. Scans begin to have a much larger effect on the scaling of SAN
resources and a more pronounced effect on users across different servers regardless of the CPU
utilization of the servers.

The effects of scans on SAN scaling

This Appendix begins with the assertion that full system scans should not be undertaken in a VDI
environment. This is not an option in some IT departments and as such, the remainder of this section
will focus on optimizing the environment for scanning. Even if you will only perform real time scans,
this section is valuable as it could be made to relate to other discrete peak IO operations such as
scheduled patch applications.

79
Virus scans have a very direct effect on scaling in a VDI environment. Since planning storage requires
planning for peak IO periods and scanning tends to be the absolute peak IO source, it is critical that
the scan be considered as at least one piece of the scalability equation. In order to use the scans as a
source, it is important to know how they function in your environment. Prior to going live, it is
imperative that you run a series of tests to record and evaluate virus scan times and effects. You
should also estimate how much downtime exists to complete all scans without creating an IO
bottleneck for end users. These two data points will factor into the peak number of VMs you can
support on one SAN.
Table 7 shows the results of calculating how much time will be required to scan VMs based on a
desired number of end users. The calculations are based on a 25GB virtual machine with 4GB of free
space. All extra VMs are shut down when not being scanned. The VMs are hosted on an HP
StorageWorks EVA4400 with 48, 300GB, 15,000 RPM fibre channel drives. The EVA4400 will
support up to 96 drives and as mentioned previously in the paper, a greater number of spindles will
improve overall scan times and peak IO performance as long as the disks remain a bottleneck.

Table 7. Concurrent scans

Total VMs 270 270 270

Concurrent Scans 24 16 8

Number of Scan Groups 11 17 34

Time Per Scan Group 35 30 21

Total Scan Time (Minutes) 385 510 714

Total Scan Time (Hours) 6:25 8:30 11:54

The number of concurrent scans is a testable metric. It should be noted that these times are for the lab
configuration used for this document. If you produce a 25GB VM the scan times will vary as the
makeup of files will vary considerably.

Reminder
The size of the virtual machines hosted in VDI will have a large effect on the
overall number of scans that can be completed both during peak and off
peak hours. Optimize virtual machines for size per VMware and HP
directions. See the section in this appendix about The effects of VM size on
scans.

It is suggested that testing begin with 8 VMs and progress to 16, 24 and potentially 32 or more
concurrent scans. The goal is to record the completion time of the longest scan and also the peak IO
of all concurrent scans in the group.
Once you have measured concurrent scan times you can plug in your desired number of VMs. Divide
the total VMs by the number of concurrent scans to get the number of scan groups. A scan group is
used to determine the number of times you will have to initiate a mass scan. In other words, only one
scan group per SAN can be scanned at one point in time. Thus, a scan group is a discrete entity with
a known time value associated with it. Multiply the number of scan groups by the time it takes each
group to finish a scan and you will have the time required to complete all scans in an off hours
scenario.
Desired VMs/concurrent scans = scan groups
Number of scan groups x scan group time = total scan time

80
Notice that there are diminishing returns as more concurrent scans are added. By the information in
the table it may be tempting to conclude that one should simply load up as many VMs as possible
until there are no improvements in per VM scan time. This will happen when the ports or the
controllers for the SAN have become saturated. Proceeding until or even beyond the saturation point
insures that no other work may be accomplished on the SAN and thus no work besides virus scanning
must be done during off hours. This is generally not practical as even during off hours end users may
be accessing the systems in limited numbers and will require excess IO to complete their work.

Note
You may wish to complete testing for greater than 24 concurrent scans. The
examples in this paper do not saturate the SAN or any particular server. It
is possible in your environment that the number of acceptable concurrent
scans will be greater than 24 with a similar SAN configuration.

Your overall sizing using this methodology, and assuming that scans are your peak IO source, will
generally be one of the following.
1. The maximum number of VMs you can scan during off hours without impeding end users.
2. The number of concurrent scans that results in scan times that will take as long or longer to
complete than if you ran fewer concurrent scans. As an example, if you find it takes 400 minutes
to scan 40 VMs and 300 minutes to scan 30 you have reached a point where there is no time
advantage to scanning more than 30.
3. You are seeing behaviors and reading metrics that show you are saturated at a controller or port
level. This is not desirable in most circumstances, but if you can insure no off peak hour end user
access this may be the optimal way to maximize the number of users on a system.

Block sizing based on thresholds

Once you have reached a threshold, a new VDI block delineated by the SAN size should be put in
place for the next set of users.
To put this into an example, we use the following illustration (Table 8) to define a block size. Assume
that we have discovered that 250 VMs is our peak user number for our SAN based on our available
hours for scanning. We have also discovered that we can house 36 VMs per server. We can thus
define a block based on the SAN as 250 users. Quantity for each additional block piece is simply
total number of users (250) desired divided by the capacity per unit.

Table 8. Determining sizing based on known storage size.

Component Quantity Capacity per unit

SAN 1 250 end users

Servers 7 36 VMs per unit

Blade enclosures 1 Up to 16 servers

Thin clients 250 1 client per user

Hypervisor licenses 3 100 VDI instances per license (May order 2 plus
5 10 packs)

NAS based solutions

Another option, sized just like SAN, is to use iSCSI based NAS such as HP All-in-One or ProLiant
Storage Server based systems enhanced with MSA direct attached storage cabinets. These solutions

81
allow for enterprise availability and manageability features, potentially offer a degree of site-to-site
failover capabilities (depending on model and configuration) and familiar Windows based
management at what may be a smaller cost overall than SAN. In this environment, smaller clusters of
servers are created and tied to a single storage server. Let‟s assume we have used our SAN sizing
methodologies and determined that our storage server may host 140 VMs. If we look at our formula
again we see the improvement in times versus SAN.

Table 9. NAS based calculations using the SAN formula.

Total VMs 140 140 140

Concurrent Scans 12 8 4

Number of Scan Groups 12 18 35

Time Per Scan Group 24 19 15

Total Scan Time (Min) 288 342 525

Total Scan Time (Hrs) 4:48 5:42 8:45

For this example, the times appear lower than SAN in all instances. The tradeoffs now become
balancing the costs of managing extra devices, the loss of redundant storage controllers and the loss
of the highest levels of performance and availability with the reduction in expense.

DAS solutions
Understanding why DAS helps with virus scans and other peak IO time constraints is simple. In a
SAN or NAS based solution with 270 VMs, all 270 VMs share a set of spindles and more
importantly, a set of controllers and ports. It is not feasible to do concurrent patch applications or
scans for all 270 VMs as the SAN will become a contention point that can not be mitigated.
In a DAS based environment, let‟s assume each host may have 45 VMs on its spindles. Scanning VMs
on that host will never effect the IOs available to end users on another server. Thus our total number
of VMs to be scanned based on contention point and block is now 45 instead of 270. It is far easier
to complete 45 total scans over the course of a period of time than it is to complete 270. As an
example let‟s assume we can scan 4 VMs in 11 minutes with a DAS solution. Using the same formula
from the SAN section we get the following values in Table 10.

Table 10. DAS based calculations using the SAN formula.

Total VMs 270

Concurrent Scans 4

Number of Scan Groups 68

Time Per Scan Group 13

Total Scan Time (Min) 884

Total Scan Time (Hrs) 14:44

This table suggests that this is not efficient. The difference is that we do not have shared spindles as
the limitation anymore. Our limitation is now per server. In this case we have 12 servers for 270
users. This means that we can change our concurrent scans to 4 times the number of servers in our
implementation. Once we figure this into the equation the end result looks far more favorable as
shown in Table 11.

82
Table 11. DAS based calculations using the SAN formula with allowances made for concurrent scans on different servers.

Total VMs 270

Concurrent Scans 48

Number of Scan Groups 6

Time Per Scan Group 13

Total Scan Time (Min) 78

Total Scan Time (Hrs) 1:18

Our scan time has now changed from 6.5 hours for a SAN based solution to 1.22 hours for a DAS
based solution with the same number of virtual machines. This is a large reduction in overall scan
time.
The tradeoff is of course the loss of enterprise features such as VMware‟s VMotion, High Availability
and Distributed Resource Scheduler. In some environments such as Business to Business, offshoring,
productivity desktops and light data entry/kiosk desktops the loss of these features may not be an
issue as levels of availability provided by data redirection, connection brokers and load balancers
may be enough to satisfy corporate mandates.

The effects of VM size on scans

The numbers given throughout this section assume a 25GB VM with redirected user data and 4GB of
free space. As noted earlier, the size of the VM you build, along with the variance and structure of
the files it contains, will have a profound effect on scan times. To provide an example of differences in
overall scan times, let‟s compare the results of the 25GB scans with those of the 10GB scans. Table
12 shows the lab results.

Table 12. VM scan times based on VM size.

25GB 10GB

Total VMs 270 270

Concurrent Scans 8 8

Number of Scan Groups 34 34

Time Per Scan Group 21 10.7

Total Scan Time (Min) 714 364

Total Scan Time (Hrs) 11:54 6:04

In this simplistic example we see that based on size of the VM alone the scan times are reduced by
over 10 hours for our 270 VMs. The bottom line is that you should keep the size of your VMs as small
as is practical. Follow VMware best practices to reduce VM size.

Other approaches
You may as a secondary approach wish to ascertain in a POC environment the number of concurrent
scans possible during working hours before end users are affected. This approach should be in
addition to off hours scanning. Scheduling scans throughout working hours should account for the
following:
1. End user activity at scan time.
2. Disk availability. Insure other activities are not affecting available IO.

83
3. Disk controllers must be able to handle all simultaneous IO requests from scans and end users.

When combined with off hours scanning, this may push your peak user count higher. Be careful to
consider whether scans are indeed your peak IO load prior to committing working hour scans into
your sizing equations.

Emerging alternatives
There are alternatives to full system scans emerging from virus scan vendors that may help with
minimizing scan IO. This includes the concept of scanning files upon access. The end user could
harbor a virus or piece of malware in a VM harmlessly. When it is accessed the scanner would detect
and react to the threat. This promises a steadier IO stream that is potentially more manageable then
en masse scans.
VMware has introduced VMsafe. VMsafe is an enabler for third party vendors to introduce security
solutions optimized for virtualization at the memory and CPU, process execution, network and storage
layers. For more information, see
http://www.vmware.com/overview/security/vmsafe/security_technology.html.
Emerging technologies change frequently. HP recommends regularly checking the HP/VMware
website at http://www.hp.com/go/vmware and VMware web resources for updates.

84
Appendix C – Performance testing
HP began testing VDI in 2003. Over time, various methodologies have been used to determine
optimal sizing. Original testing utilized handmade scripts running within the virtual machines.
Secondary tests utilized heavily modified versions of the terminal services scaling toolkit and third
party free products, designed to drive automation in environments over extended time periods. These
approaches, while somewhat functional from an automation standpoint, delivered highly optimistic
sizings that failed to mirror real world implementations and workloads recorded by HP customers.
Beginning in 2008, HP began using HP LoadRunner software to create a new testing approach with
varied end user scenarios that allowed for true variability in application load and better
randomization of end user behaviors. The end result of this change includes what HP believes to be
more accurate sizing assessments that reflect real world data and many of the recommendations that
are included in this guide.
No test methodology is perfect. HP continues to seek new and better methods of testing and sizing its
solutions and will seek to disseminate those methods and results where possible.

85
 For more information
Virtualization information from HP
HP VDI homepage, http://www.hp.com/go/vdi
HP white papers referenced in this document, http://www.hp.com/go/vmware
Desktop virtualization: Implementing Virtual Desktop Infrastructure (VDI) with HP,
http://h71028.www7.hp.com/ERC/downloads/4AA1-8759ENW.pdf
Using HP StorageWorks AiO with VMware ESX Server Solution – overview and configuration guide,
http://h71028.www7.hp.com/ERC/downloads/4AA1-5829ENW.pdf

Virtualization information from VMware

Virtual Networking Concepts, http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf
Ready Time Observations, http://www.vmware.com/pdf/esx3_ready_time.pdf
VMware Introduction to Virtual Desktop Manager, http://www.vmware.com/pdf/vdm20_intro.pdf
VDM Installation and Administration Guide, http://www.vmware.com/pdf/vdm20_manual.pdf
VMware VDI documentation site, http://www.vmware.com/support/pubs/vdi_pubs.html
VMware Infrastructure documentation site,
http://www.vmware.com/support/pubs/vi_pages/vi_pubs_35.html
ESX Server 3 and VirtualCenter Installation Guide,
http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_installation_guide.pdf
VMsafe, http://www.vmware.com/overview/security/vmsafe/security_technology.html

Third party software

Thin Print, http://www.thinprint.com
AppSense, http://www.appsense.com
AppSense VDI How to, http://www.appsense.com/solutions/virtualdesktops.aspx
Veeam nWorks, http://veeam.com/vmware-esx-monitoring-hp-operations.html

To help us improve our documents, please provide feedback at www.hp.com/solutions/feedback

© 2008 Hewlett-Packard Development Company, L.P. The information contained

herein is subject to change without notice. The only warranties for HP products and
services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or
omissions contained herein.

Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.

4AA2-3017ENW, Revision 2, November 2008