Best practices XenApp on vSphere

Based on the real life results when virtualizing XenApp I thought it was about time to summarize some of the best
practices for virtualizing XenApp servers.
Why we DO want to virtualize XenApp?
1.

For server consolidation: vSphere enables scale up XenApp deployments;

2.

For mixing server editions: 32-bit and 64-bit XenApp VMs can coexist;

3.

For management: Better management through flexibility & isolation think about Change Management
and VMware DRS;

4.

For high availability and disaster recovery: VMware HA and vCenter Site Recovery Manager;

5.

For less costs for server hardware, maintenance contracts, power, cooling, floor and rackspace.

Virtualizing XenApp servers is very complex. There are a lot more layers involved, like the type of hardware, the
capabilities of the processor, the performance of the shared storage, the hypervisor used, the specific settings per
hypervisor, operating system settings in a virtual environment, the XenApp settings in a virtual environment, the
Workspace management settings in a virtual environment etc, etc.
In the following sections I tried to summarize some of the best practices we use in our projects:
Hardware:

Use the latest processors from AMD Barcelona with RVI of Intel Nehalem with EPT;

Use two physical processors;

Maximize the number of NICs or use HP Flex-10;

Always use the last BIOS version: enable processor virtual extensions, enable hyper treading and enable
AMD RVI or Intel EPT.

Windows OS:

Because a lot of business applications are not yet supported under a 64Bits OS use Windows2003 for
better compatibility and better overall project results.

Creating the virtual XenApp servers:

Dont use P2V tools. Always build new virtual XenApp severs;

Select the right operating systems durin the virtual machine setup in vSphere;

Make sure the HAL of the operating system matches the number of vCPUs;

Do not disable Transparent Page Sharing (TPS);

Disable unneeded and unused hardware (COM & LPT ports, USB, CD-ROM, Floppy);

Disable unneeded operating system features like Wallpaper, menu animations, desktop themes, and
active desktop, all animated icons in the system tray, including the network indicator and the system
clock;

Disable realtime antivirus checking.

Virtual disk:

Use a separate VMDK for the sytem partition and program files;

Use a separate disk for the Windows page file. Size it 1.5 till 2 times the size of the RAM (W2003 std max.
4096MB);

Measure the number of IOPS you need on your shared storage.

Network Settings:

Us the enhanced vmxnet network driver;

Enable Transmit coalescing;

Disable unnecessary services:

DHCP Client if you are using static IPs;

Help and Support;

HTTP SSL;

IMAPI CD-Burning COM Service;

Indexing Service;

Intersite Messaging;

Messenger;

Remote Access Auto Connection Manager;

Remote Access Connection Manager;

Remote Desktop Help Session Manager.

User profiles:

Use roaming profiles;

Tune the profile size and set a limit on: temporary internet files, delete profile after log-off and exclude
directories from roaming;

Host profiles on a different disk or partition on a diferrent dedicated server;

Install the User Profile Hive Cleanup Service (UPHclean);

Move the spool file to a separate partition or disk drive;

If you take al this into consideration you can use the following sizing rules. Depending on the workload you can use
the following building blocks:
Heavy Load 20 users per virtual XenApp server (total 80 users)
4 Virtuele XenApp Server per host
2 vCPU direct on 2 cores
4GB internal memory
48GB external memory
Normal Load 20 users per virtual XenApp server (total 120 users)
6 Virtuele XenApp Server per host
1 vCPU
4GB internal memory
48GB external memory
Please dont forget real-life workloads vary drastically. The usage and load for a XenApp server is hard to predict
because there are users involved. User behavior is the most difficult to predict! Also for a virtual XenApp counts,
test your specific workload as I could make a huge differentiator in sizing and even the success of your project.

Virtualizing Citrix XenApp on vSphere, part II

This is the second part of my articles on virtualizing XenApp on vSphere. You can read the first part here.

vSphere design considerations

I recommend to create a dedicated VMware cluster for virtualized XenApp servers. The reason for this is use of
vSphere functionality and the resulting licensing costs. Because XenApp VMs are highly resource intensive there is
no need for VMware DRS. VMware DRS is useful when there are a lot of VMs with different resource demands but
with XenApp VMs this is not the case. All XenApp VMs are resource intensive. Furthermore I do not recommend
to use vmotion on XenApp VMs because end-users could experience a delay in there XenApp session during a
vmotion. Based on these facts a vSphere Standard edition license gives enough functionality for the VMware
cluster with XenApp servers, which I will call the VMware XenApp cluster in the rest of this article. By using
vSphere standard, the XenApp servers are protected against hardware failures by VMware HA and using the
vSphere standard license keeps the cost of a virtualized XenApp server low. Theres one caveat, if you use
distributed vSwitches in your environment you are stuck with standard vSwitches with vSphere standard or you
should use the vSphere Enterprise Plus license for the VMware XenApp cluster.
Hardware considerations
Selecting the right server hardware is essential for successful virtualization of XenApp servers. I recommend to use
hardware based on the Intel Nehalem processor architecture. At time of writing this article, this is the Intel Xeon
55XX series. The Nehalem processor architecture provides support for hardware-assisted memory management
unit (MMU) virtualization. MMU virtualization provides a significant performance increase.
The number of physical CPU cores should be matched with the number of vCPUs. For virtualized XenApp servers,
do not overcommit CPU resources. For example, if you intend to run 4 XenApp servers with 2 vCPUs, your ESX
server should have 8 cores. It is possible to slightly overcommit but you should monitor your CPU ready time for
bottlenecks.
I used diskless HP Proliant BL460 G6 servers for building a VMware XenApp cluster, but any modern server will do.
These servers are equipped with 2 Quadcore Intel E5540 CPUs and 24 GB of RAM. With this configuration I
managed to run 5 XenApp VMs with a good performance. With 6 XenApp VMs the CPU ready time becomes
greater than 5% and the performance isnt acceptable anymore.
Because XenApp VMs are disk I/O intensive (especially during logon hours) I recommend to make dedicated
datastores with the size for holding a maximum of four XenApp VMs within the VMware XenApp cluster. This way

the XenApps VMs make optimal use of the I/O queues each lun provide. Also create the datastores on the fastest
lun you can provide. I used raid 1 fibrechannel luns for the XenApp VM datastores.

Application Landscape
Each XenApp VM will contain some standard applications and custom application specific to the business. In this
article I focus only on the standard applications. Heres a quick overview of the standard application set I use on a
XenApp VM:
- Microsoft Internet Explorer 7
- Microsoft Office 2003
- Antivirus software
I used Internet Explorer 7 because Internet Explorer 8 had more CPU spikes. I dont know the reason for this,
maybe some web application has not been optimized for IE8 but I didnt have the time to investigate this problem.
By default IE8 also starts two iexplorer processes for each user which requires a little more resources. Office 2003
was used because the customer was still using Office 2003. This is a plus because Office 2007 requires more
resources. I recommended to use antivirus software on your XenApp VM.
With this configuration I managed to run 5 XenApp VMs on a single ESXi host with each XenApp VM supporting 25
users. This makes a total of 150 users on one physical server. The user experience with this configuration is within
normal range.
The following chart shows the CPU usage from the ESXi host with 5 XenApp servers

running.
The following chart shows the CPU usage from a XenApp VM.

Please note that the CPU ready time is below the 5%.