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 NIC’s 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:

  • Don’t 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 vCPU’s;
  • 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)

Normal Load 20 users per virtual XenApp server (total 120 users)

Please don’t 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.