How To Virtualize Citrix XenApp on vSphere 4.1

As organizations continue on the journey of virtualizing more servers, there's a need for more attention and customization in order to yield the desired performance benefits while taking advantage of the virtualization drivers. This is especially true for those servers that host applications dubbed as tier-1 applications, such as SQL, Exchange and Citrix XenApp.

Citrix XenApp is particularly interesting when virtualized due to the nature of the server that typically consumes a lot of CPU, memory and disk I/O. So, addressing these categories in particular is imperative. Here are some best practices on how to tweak Citrix XenApp on VMware vSphere 4.1.

At the vSphere Infrastructure Level
At the virtual infrastructure level, the use of VMware vSphere 4.1 or newer with vStorageAPIs for Array Integration is imperative. VAAI offloads certain tasks previously executed in the hypervisor onto the storage array; however, the most important feature of VAAI as it pertains to virtualizing XenApp is that it offloads SCSI locking to the array. When you have multiple XenApp VMs on the same LUN and they are simultaneously utilizing the disk, the benefits of VAAI will surely be apparent.

If you have not upgraded to vSphere 4.1, I strongly recommend it, especially if you intend on virtualizing tier-1 applications. Check with your storage manufacturer to make sure your array supports VAAI. In some cases you may have to upgrade the firmware on your controller to take advantage of it.

Another tweak to the vSphere host is again related to heavy workload disk performance, and XenApp is most definitely fits that category. This tweak addresses the maximum simultaneous number of outstanding disk requests to a specific LUN.

By default, the limit is set to 32 and can be increased to a maximum of 256. This value should be set to the maximum as a regular performance best practice, and in particular when tier-1 applications are involved. This value can be changed by navigating to the Configuration tab of a vSphere host, selecting Advanced Settings and selecting the node Disk. You should then browse to Disk.SchedNumReqOutstanding and set it to 256.

At the VM Virtual Hardware Level
It is critical that the the virtual hardware that is configured for a XenApp deployment be configured with the most efficient components as follows:

• Disable and remove any unnecessary virtual hardware components such as CD-ROM and Floppy
• When configuring a virtual network Interface Card, select the VMXNET3 adapter, this provides the most efficient vNIC possible and yields the best performance while minimizing load on the vSphere host CPU
• The ideal disk controller for XenApp is the LSI Logic SAS Controller. While converting a XenApp server from physical to VM is strongly discouraged (particularly because changing the disk controller results in an unstable operating system), if you have to convert, try and change the disk controller as this will affect performance.
• You can edit the VM settings and select the Options tab, configure CPU and meory hardware assist appropriately. By default it is set to Automatic; your testing might reveal a performance gain if hardcoded.

For 32-bit Windows Operating Systems
When using a 32-bit operating system, you are limited to the amount of memory that Windows 32-bit can effectively take advantage of. Therefore, I suggest CPU and memory configurations to be 4096 MB virtual RAM and one or two vCPUs. While you can most certainly configure four vCPUs, XenApp does not linearly scale very well. As such, two vCPUs is recommended before adding another XenApp VM.

Ideally, if you have to use 32-bit operating system, use Windows Server 2008, aside from the fact that Windows Server 2003 is almost end of life, Windows Server 2008 has many specific advantages, including one that automatically aligns the virtual disk to the underlining storage where it resides. This is significant from a disk I/O performance stand point.

However, if you must use Windows Server 2003, I suggest splitting the operating system and the data drive into separate VMDKs for the simple sake of being able to disk align the data drive. In Windows Server 2003, disk alignment is a manual process that should be performed on the data drive.

To align the drive on Windows Server 2003, use follow these steps:

1. Add a Virtual Disk to the VM settings
2. In the operating system, do not use the GUI to initialize the partition, instead open a command line and use the following command: Diskpart
3. Then type list disk, this will display a list of available disks
4. Use the select disk command in conjunction with the appropriate disk number to set the focus on the disk you want
5. Finally type create partition primary align=64
6. You can now use the Disk Management MMC to assign the disk a drive letter and format it

You will not be able to align the system drive and you don’t need to, considering that all your applications will be installed on the data drive anyway and that is the drive that will drive the disk I/O when the applications are used.

Multiple Drives for OS and Applications
I have read many times about the benefits of splitting the operating system and the applications onto separate drives. The fact of the matter is, if you are splitting them up logically but they physically reside on the same disk, then there is no performance benefit whatsoever. If you are splitting them up on different physical disks of different tier class (ex: SSD, SAS, SATA) with different RAID configurations, then a performance gain is noticeable, albeit not significant.

What I am trying to say here is, if you are going to have a dedicated VMDK for operating system and applications that live on the same datastore, then might as well have one large C: drive, as you will gain no performance at all. But if you plan on splitting your VMDKs on different datastores which have different tier of disk and RAID levels, then go for it.

General Recommendations
Disable the Last Time Access Attribute for NTFS process. It's a chatty process that keeps track of the last time a file was accessed. Disabling it relieves the operating system from having to constantly read and write this information. To disable, run the following command:

fsutil behavior set disablelastaccess 1

Finally, as with the build and setup of traditional XenApp servers, any unnecessary processes, services, USB, screen savers, animations, etc., should be disabled for best performance.

This process may seem long and exhausting at first, but isn’t that the case for every build of XenApp? Those of you that have been working with XenApp for a while can appreciate it this. That being said, virtualization makes it easier for us to create templates and deploy from these templates, thereby streamlining and efficiently increasing our ability to deploy a XenApp server.

Posted by Elias Khnaser on 03/14/2011 at 12:49 PM