Today marks the public release of the scalability report for XenDesktop 4 on Microsoft Windows 2008 R2 Hyper-V. I am excited about the release of this document, since it represents the culmination of six-months of work and a joint effort with Citrix, HP, and Microsoft. The co-branded report includes the following information:

Testing methodology and test procedures for single-server and large-farm testing
2. Physical and logical architecture including hardware specifications, network connectivity, and software configurations
3. Single-server scalability results for the BL460C HP blade servers with 48GB and 96GB RAM
4. Single-server scalability results when SSDs were used to host the write-cache drive for Provisioning Services
5. Large-farm scalability results for 700, 1400, 2100, 2800, and 3500 Windows 7 desktops
6. Detailed performance counters for the key infrastructure components, including the XenDesktop DDC, Provisioning Services, Microsoft System Center Virtual Machine Manager, SQL Server, and P4500 storage

This report is a “must read” for anyone who currently is planning to design or implement a XenDesktop 4 farm using Microsoft Windows 2008 R2 Hyper-V as the hypervisor. The report provides key findings and performance data that is necessary for architects, consultants, and virtualization engineers to be successful with XenDesktop 4. You can find the Scalability of XenDesktop 4 on Microsoft Windows Server 2008 R2 Hyper-V here or as Citrix support article CTX126389.

Just to give you an idea of the content here are a few of the key observations during the tests:

The farm could be grown by adding RAM to the existing servers assuming the user workload remained close to the tested Login VSI Medium workload. Conversely, the existing farm could support a workload that was more CPU-intense than the one tested.
The SSDs provided the best response times for the login test and the fastest boot times for the images. In fact, if the SSDs are used to host the write-cache drives the boot time for the VM is under 30 seconds suggesting that an idle pool of desktops may not be necessary in situations where users are willing to wait for their desktop to be started.
From the data gathered, it appears that VM density per core is at least somewhat dependent on the speed and responsiveness of the storage layer.
Each PVS server averaged 146 guests per physical core or 292 per core when the unused CPU capacity is adjusted out. In addition each 1Gb of network bandwidth supported approximately 450 guests for bootup and about 745 guests for login.

I have also added this report to my AskTheArchitect website under the Integration Resources tab.

If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98 or visit my XenDesktop on Microsoft website.