EMC Infrastructure for Virtual Desktops

Transcription

1 EMC Infrastructure for Virtual Desktops Enabled by EMC Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 Proven Solution Guide

2 EMC <offerings> for <Application> Enabled by <Products/Services> on <OS> using <Network Transport>> Copyright December, 2010 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. Benchmark results are highly dependent upon workload, specific application requirements, and system design and implementation. Relative system performance will vary as a result of these and other factors. Therefore, this workload should not be used as a substitute for a specific customer application benchmark when critical capacity planning and/or product evaluation decisions are contemplated. All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other operating environments may vary significantly. EMC Corporation does not warrant or represent that a user can or will achieve similar performance expressed in transactions per minute. No warranty of system performance or price/performance is expressed or implied in this document. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners. Part number: h8111 2

3 Table of Contents Chapter 1: About this Document...4 Overview...4 Audience and purpose...4 Scope...5 Technology solutions...6 Virtual Desktop Infrastructure...6 Reference architecture...8 Validated environment profile...8 Prerequisites and supporting documentation...10 Terminology...11 Chapter 2: Virtual Desktop Infrastructure...12 Overview...12 XenDesktop VDI...12 Microsoft Virtualization...13 Windows infrastructure...14 Conclusion...15 Chapter 3: Storage Design...16 Overview...16 Concepts...16 Storage design layout...16 LUN layout...18 Capacity planning...20 Best practices...21 Chapter 4: Network Design...22 Overview...22 Considerations...22 Network layout...23 Virtual LANs...23 High availability network...24 Chapter 5: Installation and Configuration...25 Overview...25 Task 1: Set up and configure the FC LUNs...26 Task 2: Install and configure Desktop Delivery Controller...26 Task 3: Install and configure Provisioning Server...32 Task 4: Configure and provision the master virtual machine template...45 Task 5: Deploy virtual desktops...45 Chapter 6: Testing and Validation...51 Overview...51 Testing overview...51 Testing tools...51 Test results...53 Result analysis of Desktop Delivery Controller...54 Result analysis of Provisioning Server...58 Result analysis of the SCVMM Server...62 Result analysis of SQL Server...64 Result analysis of Windows 2008 R2 Hyper-V servers...68 Result analysis of Celerra unified storage...73 Login storm scenario...82 Test summary

4 Chapter 1: About this Document Overview Introduction EMC's Total Customer Experience (TCE) program, a commitment to continuously improving quality, is driven by Six Sigma methodologies. As a result, EMC has built Customer Integration Labs in its Global Solutions Centers to reflect real-world deployment scenarios where TCE use cases are developed and executed. These use cases provide EMC with insight into the challenges currently facing its customers. This document summarizes a series of best practices that were discovered, validated, and observed during the validation of the EMC Virtual Infrastructure for Virtual Desktops Enabled by EMC Celerra Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 solution. Use case definition A use case reflects a defined set of tests that validates the reference architecture for a customer environment. This validated architecture can then be used as a reference point for a Proven Solution. Contents The chapter includes the following topics: Topic Overview 4 Audience and purpose 4 Scope 5 Technology solutions 6 Virtual Desktop Infrastructure 6 Reference architecture 8 Validated environment profile 8 Prerequisites and supporting documentation 10 Terminology 11 See Page Audience and purpose Audience The intended audience for the Proven Solution Guide is: Internal EMC personnel EMC partners Customers 4

5 Purpose The purpose of this solution is to: Develop a recommended Citrix XenDesktop 4 VDI for 1,000 users with the EMC Celerra unified storage platform and the Microsoft Windows Server 2008 R2 Hyper-V virtualization platform. Test and document the user response time, and performance of the associated servers. Information in this document can be used as the basis for a solution build, white paper, best practices document, or training. It can also be used by other EMC organizations (for example, the technical services or sales organization) as the basis for producing documentation for technical services or a sales kit. Scope Scope This document describes the architecture of an EMC solution built at EMC s Global Solutions Lab. This solution is engineered to enable customers to: Implement a Citrix XenDesktop VDI 4 solution in their environment after considering the storage configuration, design, sizing, and software. Reduce operational costs with VDI, when compared against existing desktop solutions. Deliver the highest level of service level agreement (SLA) with the lowest cost per application workload. Provide the VDI with the flexibility of a solution that offers a simple footprint for midsize organizations, and can scale up to meet the requirements of large enterprises. This solution provides information for: Creating a high-performance storage design for a Citrix XenDesktop 4 VDI on a Microsoft Windows Server 2008 R2 Hyper-V virtualization platform for 1,000 desktop users on an EMC Celerra NS-120 unified storage system. Documenting the performance in the validated environment, and suggesting methods to improve the performance of the Citrix XenDesktop 4 solution. Not in scope Testing XenDesktop 4 VDI for a workload other than a typical office user workload was outside the scope of this testing. 5

6 Technology solutions Business challenges for midsize enterprises With limited resources and increasing demands, today's business must address the following challenges: Consolidate desktops across the enterprise Ensure information access, availability, and continuity Maximize server and storage utilization, and deliver high desktop performance Manage upgrades and migration quickly and easily Reduce the demands on limited IT resources and budgets Reduce the complexity of selecting the right technology Solution for midsize enterprises The EMC Virtual Infrastructure for Virtual Desktops Enabled by EMC Celerra Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 solution establishes a validated hardware and software configuration that permits an easy and repeatable deployment of virtual desktops using the storage provided by an EMC Celerra NS-120. This Proven Solution Guide describes the deployment and validation of Citrix XenDesktop 4 VDI on the Celerra NS-120 system in a configuration that provides high performance, recoverability, and protection. Virtual Desktop Infrastructure Introduction The VDI is used to run desktop operating systems and applications inside virtual machines that reside on servers running a virtualization hypervisor. The desktop operating systems inside the virtual machines are referred to as virtual desktops. Users access the virtual desktops and applications from a desktop PC client or a thin client by using a remote display protocol. The applications and storage are centrally managed. Citrix XenDesktop Citrix XenDesktop is a leader in desktop virtualization. It enables fully personalized desktops for each user while providing security, and the simplicity of centralized management. XenDesktop simplifies desktop management. Using centralized management, adding, updating, and removing applications are easily accomplished. HDX technology gives users instant access to applications. The HDX technology is a set of capabilities that delivers a high-definition user experience over any network, including low-bandwidth and high-latency wide area network (WAN) connections. XenDesktop can instantly deliver every type of virtual desktop, with each virtual desktop specifically tailored to meet the performance and flexibility requirements of individual users. 6

7 Components of Citrix XenDesktop VDI This solution has validated a XenDesktop 4 VDI deployment for high availability and simulated the workload of 1,000 real-world users. The VDI was built using the following components: Citrix DDC to broker and manage virtual desktops. Citrix Provisioning Services to provision the desktop operating system (OS). EMC unified storage to store virtual desktops. Microsoft Windows Server 2008 R2 Hyper-V and Microsoft System Center Virtual Machine Manager 2008 R2 as the server virtualization infrastructure. Windows infrastructure to support services such as Active Directory, dynamic host configuration protocol (DHCP), Domain Name System (DNS), and SQL Server. 7

8 Reference architecture Corresponding reference architecture This use case has a corresponding reference architecture document that is available on EMC Powerlink and EMC.com. Refer to EMC Virtual Infrastructure for Virtual Desktops Enabled by EMC Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 Reference Architecture for details. Reference architecture diagram The following diagram shows the overall physical architecture of the solution. Validated environment profile Environment profile and test results The solution was validated with the following environment profile. Profile characteristic Number of virtual desktops 1,000 Value 8

9 Size of each virtual desktop Number of building blocks 10 Number of virtual desktops per building block 100 Number of FC LUNs per building block 1 Number of XenDesktop Provisioning Services Servers 2 Number of XenDesktop Desktop Delivery Controllers 2 FC LUN RAID type, physical drive size, and speed Storage to host the Golden images, TFTP boot area, and ISO images RAID type, physical drive size, and speed 3 GB (thin provisioned) RAID 1, 450 GB, 15k rpm, FC disks RAID 5, 450 GB, 15k rpm, FC disks Chapter 6: Testing and Validation on page 51 provides more information on the performance results. Hardware resources The following table lists the hardware used to validate the solution. Equipment Quantity Configuration Notes EMC Celerra NS HP ProLiant DL380 G5 3 Cisco UCS B200 M1 Blade Server 16 Two Data Movers (active/passive) Two disk-array enclosures (DAEs) with 15 FC 450 GB 15k 2/4 Gb disks Memory: 20 GB RAM CPU: Two 3.0 GHz quad-core processors Storage: One 67 GB disk NIC: Two Broadcom NetXtreme II BCM 1,000 BaseT Adapters Memory: 48 GB RAM CPU: Two Intel Xeon 5500 Series processors GHz quad-core processors Storage: Two 146 GB disks Fibre Channel and Network Adapter: M71KR-Q QLogic Converged Network Adapter FC LUN storage and Trivial File Transfer Protocol (TFTP) server Windows Server 2008 R2 Hyper- V servers to host virtual machines for SCVMM Server, Active Directory, DHCP, DNS, DDC, PVS, and SQL Server Windows Server 2008 R2 Hyper- V servers to host 1,000 virtual desktops Software resources The following table lists the software used to validate the solution. Software Version Celerra NS-120 (Celerra shared storage, file systems) NAS or Data Access in Real Time (DART) Release

10 Software Version CLARiiON FLARE Release 28 ( ) XenDesktop desktop virtualization Citrix XenDesktop Citrix Desktop Delivery Controller Server Version 4 Platinum Edition Version 4.0 SP1 Citrix Provisioning Services Server Version Microsoft SQL Server Version 2005 Enterprise Edition (64-bit) Windows 2008 Hyper-V Virtualization Infrastructure Windows Server 2008 R2 Server Core with Hyper-V Windows 2008 Server R2 Hyper-V (Build 7600) QLogic FC HBA driver STOR Miniport version QLogic SanSurf FC HBA Manager Version Build 46 Navisphere Agent Version EMC PowerPath System Center Virtual Machine Manager (SCVMM) 2008 R2 Operating System for SCVMM Server Version 5.3 SP1 (64-bit) Version Virtual desktops or virtual machines (One vcpu and 512 MB RAM) Microsoft Windows Server 2008 R2 Enterprise Edition OS Microsoft Windows XP Pro Edition Microsoft Office 2007 Version 12 Internet Explorer Adobe Reader 9.1 Adobe Flash Player 10 Bullzip PDF Printer Prerequisites and supporting documentation Technology It is assumed that the reader has a general knowledge of the following products: EMC Celerra unified storage Citrix XenDesktop Microsoft Windows Server 2008 R2 Hyper-V 10

11 Supporting documents The following documents, located on Powerlink, provide additional, relevant information. Access to these documents is based on your login credentials. If you do not have access to the following content, contact your EMC representative. EMC Virtual Infrastructure for Virtual Desktops Enabled by EMC Celerra Unified Storage (FC), Microsoft Windows Server 2008 R2 Hyper-V, and Citrix XenDesktop 4 Reference Architecture Configuring Citrix XenDesktop 3.0 with Provisioning Server using EMC Celerra Build Document Third-party documents Product documentation is available on the Citrix and Microsoft websites. Citrix Product Documentation Library for XenDesktop Microsoft Hyper-V Server 2008 Configuration Guide Terminology Introduction Term Desktop Delivery Controller (DDC) Citrix Provisioning Services Server (PVS) PVS vdisk PVS write cache LoginVSI This section defines the terms used in this document. Definition Part of the Citrix XenDesktop virtual desktop delivery system, this controller authenticates users, manages the assembly of users' virtual desktop environments, and brokers connections between users and their virtual desktops. Part of the Citrix XenDesktop virtual desktop delivery system, this service creates and de-provisions virtual desktops from a single desktop image on demand, optimizes storage utilization, and provides a pristine virtual desktop to each user every time they log on. vdisk exists as a disk image file stored on a Provisioning Server or shared storage device. The vdisk images are configured to provide a choice between Private, Standard, or Difference Disk modes. Private mode gives exclusive read-write access to a single desktop. In Standard or Difference Disk mode, the vdisk is shared between multiple desktops with read-only permissions for each desktop. Any writes made to the desktop operating system are redirected to a temporary area called the write cache. The write cache can exist as a temporary file on a Provisioning Server in the virtual desktop s memory or on the virtual desktop s hard drive. A third-party benchmarking tool developed by Login Consultants, LoginVSI simulates a real-world VDI workload using an AutoIT script and determines maximum system capacity based on the user s response time. 11

12 Chapter 2: Virtual Desktop Infrastructure (VDI) Overview Introduction The VDI design layout instructions described in this chapter apply to the specific components used during the development of this solution. Contents This chapter contains the following topics: Topic Overview 12 Citrix XenDesktop VDI 12 Microsoft virtualization 13 Windows infrastructure 14 Conclusion 15 See Page Citrix XenDesktop VDI Introduction Citrix XenDesktop 4 is a desktop virtualization system that centralizes and delivers Microsoft Windows XP, 7, or Vista virtual desktops to users located anywhere, without any negative performance impact. XenDesktop 4 simplifies desktop management by using a single image to deliver personalized desktops to users and enables administrators to manage service levels with built-in desktop performance monitoring. The open architecture of XenDesktop 4 offers flexibility when virtualization platforms and user devices. Deploying a XenDesktop farm This VDI solution is deployed using a dual-server model in a XenDesktop 4 farm with high availability. This provides a working deployment on a minimal number of computers. As the farm grows, additional controllers and components can be seamlessly added to the farm. The essential elements of a XenDesktop 4 farm are: Desktop Delivery Controller Citrix Licensing Provisioning Server Apart from these Citrix elements, the following components are required for a XenDesktop 4 farm: Microsoft SQL Server to hold the configuration information and administrator account information Active Directory DNS Server PXE boot and TFTP servers 12

13 Desktop Delivery Controller The Desktop Delivery Controller (DDC) authenticates users, manages the assembly of users' virtual desktop environments, and brokers connections between users and their virtual desktops. It also controls the state of the virtual desktops. Starting and stopping the desktops are centrally-managed processes based on resource demand and administrative configuration. DDC also includes the User Profile Manager to manage user personalization settings in virtualized or physical Windows environments. The Citrix licensing service is also installed on the Desktop Delivery Controller. Provisioning Server The Provisioning Server creates and de-provisions virtual desktops on demand from a single desktop image, optimizes storage utilization, and provides a pristine virtual desktop to each user every time they log on. Desktop provisioning also simplifies desktop images, provides the most flexibility, and offers fewer points of desktop management for both applications and desktops. High availability of XenDesktop components In this solution, two DDCs and two Provisioning Servers were used to provide high availability and load balancing. For this solution with 1,000 virtual desktops, 500 virtual desktops were managed by each Desktop Delivery Controller. Similarly, each Provisioning Server managed 500 virtual desktops. If the DDC or Provisioning Server goes offline, the other DDC or Provisioning Server takes over the virtual desktops of the offline server and manages all 1,000 virtual desktops. Microsoft virtualization Introduction This Citrix XenDesktop 4 VDI solution is implemented on a Microsoft virtualization infrastructure. This enables organizations to leverage existing investments in Microsoft implementation and infrastructure. The following elements of Microsoft Hyper-V virtualization were used in this solution: Windows Server 2008 R2 Hyper-V System Center Virtual Machine Manager (SCVMM) 2008 R2 13

14 Windows Server 2008 R2 Hyper-V Microsoft Windows Server 2008 R2 Hyper-V is the virtualization hypervisor that can transform or virtualize computer hardware resources, including CPU, RAM, hard disks, and network controllers, to create a fully functional virtual machine that runs its own operating systems and applications like a physical computer. This solution uses Microsoft Windows Server 2008 R2 Hyper-V in Server Core mode for the Hyper-V servers that host the virtual desktops. The Server Core installation option reduces the attack surface of the operating system, limits the roles the server can host, uses 75 percent less disk space, and provides better performance. Windows Server 2008 R2 failover clustering, and high availability features coupled with cluster shared volumes (CSV) and live migration, enable movement of the virtual desktops from one hypervisor server to another with minimal impact to the end user. System Center Virtual Machine Manager (SCVMM) 2008 R2 SCVMM 2008 R2 enables simple, efficient, and scalable management for the Microsoft Windows Server 2008 R2 Hyper-V virtualized environment. SCVMM provides the interface that allows XenDesktop 4 to communicate with the Microsoft Windows Server 2008 R2 Hyper-V hosts. SCVMM also provides a service-based interface that can be used by the XenDesktop Pool Management service to manage the virtual desktop. Windows infrastructure Introduction Microsoft Windows infrastructure is used in this solution to provide the following services to virtual desktops and XenDesktop elements: Active Directory Service DNS server DHCP service SQL Server Domain controller The Windows domain controller contains the Active Directory service, which provides the ability to manage the identities and relationships of virtual desktops and other components in the VDI environment. Active Directory is used by the DDC to provide secure communication between the XenDesktop components. DNS server DNS is the primary name resolution mechanism of Windows servers, and serves as the backbone of Active Directory. Domain Controllers dynamically register information about themselves and about Active Directory in the DNS server. In this solution, the DNS server is installed on the domain controller. 14

15 DHCP service The virtual desktops receive their IP addresses, boot server names, and boot file names from the DHCP server. The IP range of DHCP is configured to allocate IP addresses for 1,000 virtual desktops. Because the virtual desktop virtual machines use PXE boot from a bootstrap image prior to loading the master desktop image supplied by Citrix Provisioning Services, DHCP options 66 and 67 are configured to redirect the virtual desktops to retrieve the bootstrap image from a TFTP server hosted on the EMC Celerra. SQL Server Microsoft SQL Server is a relational database management system (RDBMS). In this solution, Microsoft SQL Server 2005 satisfies the database requirement for Citrix Provisioning Services and DDC. It can also be used to satisfy the database requirements for an SCVMM 2008 R2 Server. Microsoft SQL Server 2005 Enterprise Edition (64-bit) is used in this solution. Though Microsoft SQL Server 2005 Express Edition is free, lightweight, and can satisfy the database requirements for a very small virtual desktop farm, it is not recommended for use in production environments because its support is limited to 1 CPU, 1 GB of addressable RAM, and a maximum database size of 4 GB. Conclusion Conclusion This XenDesktop 4 VDI implementation for 1,000 virtual desktops is configured in a desktop farm containing two Desktop Delivery Controllers and two Provisioning Servers for high availability, using existing Microsoft Hyper-V virtual infrastructure and Windows servers to provide networking and database services. 15

16 Chapter 3: Storage Design Overview Introduction The storage design and layout instructions described in this chapter apply to the specific components of this solution Contents This chapter contains the following topics: Topic See Page Overview 16 Concepts 16 Storage design layout 16 LUN layout 18 Capacity planning 20 Best practices 21 Concepts Introduction The EMC Celerra unified storage system is used for most of the storage needs of this solution. The Celerra is a multiprotocol storage system that provides access to data over FC, and other storage access protocols. It can scale quickly to manage anticipated data growth, especially as the storage need for virtual machines increases on Microsoft Hyper-V servers. Celerra thin provisioning improves the utilization of storage capacity, and simplifies storage management by presenting virtual machines with sufficient capacity. It can be shared across multiple Microsoft Hyper-V servers, enabling storage consolidation to provide efficient use of storage resources, which is valuable for clustering and migration. Storage design layout Building block approach This VDI solution is validated using a building block approach, which allows administrators to incrementally provision additional blocks of storage as the number of desktop users continues to increase. A building block is defined as two spindles on a 1+1 RAID 1 group. Each of these building blocks is designed to accommodate up to 100 virtual desktop users. The validation test uses up to 10 building blocks to support 1,000 virtual desktops. 16

17 Disk layout for 10 building blocks The following figure shows the disk layout for 10 RAID 1 building blocks on three shelves that are configured using Navisphere Manager. The NS-120 can be populated with up to eight disk shelves of 15 disk drives each. This validated solution uses three shelves of 450 GB 15k FC drives. Ten RAID 1 groups are used to store the virtual desktops. Two 4+1 RAID 5 groups (RG 0 and 10) are used to store the golden image of virtual desktops, the TFTP boot image, user profiles, and other support files. 17

18 LUN layout LUN Configuration Each building block consists of a single LUN in a RAID 1 group. LUNs of consecutive RAID groups are owned by a different storage processor (SP) for load balancing. Each LUN is presented to the Hyper-V host in as an NTFS-formatted volume within a primary partition. The following table shows the LUN ID selection for each of the volumes created. File system Storage TFTP boot Celerra FS from LUN ID 17 User Profiles (CIFS Share) Celerra FS from LUN ID 18 AD/SCVMM/SQL Server VMs LUN ID 19 DDC1/PVS1 VMs LUN ID 20 DDC2/PVS2 VMs LUN ID 21 Golden Image LUN ID 22 Failover Clustering Witness Disk LUN ID 23 Building Block 1 LUN ID 24 Building Block 2 - LUN ID 25 Building Block 3 - LUN ID 26 Building Block 4 - LUN ID 27 Virtual desktop groups (FC storage for virtual desktops) Building Block 5 - LUN ID 28 Building Block 6 - LUN ID 29 Building Block 7 - LUN ID 30 Building Block 8 - LUN ID 31 Building Block 9 - LUN ID 32 Building Block 10 - LUN ID 33 18

19 FC LUN usage The Celerra unified storage platform is used to store the following: Virtual desktop virtual machines Citrix Provisioning Services vdisk TFTP boot image Roaming user profiles Virtual desktop virtual machines The virtual desktops are deployed as virtual machines that are hosted on Windows 2008 R2 Hyper-V servers. Each desktop virtual machine has its own folder that contains xml, bin, vsv, vhd, and other files that are stored on Fibre Channel LUNs bound on the EMC Celerra NS-120 unified storage system. In this proven solution, each building block is configured with one FC LUN that accommodates up to 100 virtual desktops. There are a total of 10 FC LUNs to support up to 1,000 virtual desktops. Citrix Provisioning Services vdisk The master desktop image is stored on a Citrix Provisioning Services vdisk, which corresponds to a virtual hard disk (VHD) file that resides on a local drive (NTFS formatted) on one of the Provisioning Servers. Because the Provisioning Servers are virtualized as virtual machines, the local drive that holds the master image is a passthrough disk that corresponds to a LUN, which is created from a 4+1 RAID 5 group (RG 10 as shown in the Disk layout for 10 building blocks on page 17) on the Celerra. The following figure shows the storage layers of the vdisk. Desktop OS image vdisk VHD file Read-only NTFS Pass-through disk FC LUN The NTFS file system is made read-only when the master image is finalized and ready to be sealed. The read-only file system enables concurrent access for multiple Provisioning Servers without the need for a clustering file system to handle any locking issues that may arise. TFTP server All virtual desktops need to PXE boot from a bootstrap image when they are powered up. This bootstrap image is stored on a file system on RAID group 0 on the Celerra. The image is then made available through the Celerra TFTP server. 19

20 Roaming profiles and folder redirection Using the local user profile is not recommended in a VDI environment because a performance penalty is incurred when a new local profile is created whenever a user logs in to a new desktop image. Roaming profiles and folder redirection allow user data to be stored centrally on a network location that can reside on a Celerra CIFS share. This reduces the performance hit during user logon while allowing user data to roam with the profiles. Alternative profile management tools such as Citrix User Profile Manager or a third-party tool such as AppSense Environment Manager provide more advanced and granular features to manage various user profile scenarios. Refer to User Profiles for XenApp and XenDesktop on the Citrix website for further details. Capacity planning Building block of 100 virtual desktops Storage design layout on page 16 describes the building block approach used in this solution. Each building block consists of two spindles on a 1+1 RAID 1 group that is designed to accommodate up to 100 virtual desktop users. The Celerra NS-120 uses 450 GB FC 15k rpm spindles. As mentioned in Disk layout for 10 building blocks on page 17, a LUN is bound on a RAID 1 group that provides a storage space of approximately 402 GB. LUNs on consecutive RAID groups are owned by different storage processors (SPs) for load balancing. This 402 GB LUN presented to the Windows 2008 Server Hyper-V host is adequate for 100 virtual desktops of 3 GB each. The 3 GB is thin provisioned and used as Provisioning Services write cache storage, creating a temporary area to save changes made to the virtual desktops. Virtual desktops typically consume several hundred megabytes of write cache. Do not overflow the write cache area allocated to each virtual desktop. Users may experience disk errors when performing write operations if the write cache area has exceeded its capacity. In addition to virtual disk storage, each virtual desktop requires storage for a.bin file that stores the saved state information for a virtual machine. Its size is equal to the RAM allocated for each virtual machine. Because each virtual machine is allocated 512 MB of memory, 100 virtual desktops require 50 GB (100 x 512 MB) out of the 402 GB. Thin provisioning The virtual hard disk provided to virtual desktops from the FC LUN is thin provisioned. This enables users to control storage costs, provide a higher level of utilization, and eliminate storage waste and the need for dedicated storage capacity. 20

21 Best practices Disk drives The general recommendations for disk drives are: Drives with higher revolutions per minute (RPM) provide higher overall random-access throughput and shorter response times than lower rpm drives. For optimum performance, higher RPM drives are recommended for storing the file systems that house the virtual desktops. FC drives are preferred over Serial Advanced Technology Attached (SATA) drives because FC drives provide better performance than SATA drives. Enterprise Flash Drives (EFDs) could have been considered for their performance, efficiency, power, space, and cooling requirements. However, they increase the cost drastically. As technology cost tends to reduce over the course of time, EFD can be used in such solutions in the near future. RAID 1 compared to RAID 5 The I/O loads generated by virtual desktops are characterized as small, random, or write-intensive I/O. A workload is considered write-intensive when it consists of greater than 30 percent of random writes. In such a random workload, RAID 1 offers better performance than RAID 5 because of the write penalty that RAID 5 incurs when the parity bit is calculated for every write operation. Since RAID 1 does not calculate parity, it does not suffer a similar penalty when writing data. 21

22 Chapter 4: Network Design Overview Introduction This chapter describes the network design of Citrix XenDesktop 4 in the VDI solution. Contents This chapter contains the following topics: Topic Overview 22 Considerations 22 Network layout 23 Virtual LANs 23 High availability network 24 See Page Considerations Introduction Two types of network connections were configured in this solution, Fibre Channel (FC) and Internet Protocol (IP). FC connections were established between the Windows Server 2008 R2 Hyper-V hosts and the Celerra NS-120 unified storage platform to allow the Hyper-V hosts to access the FC LUNs stored on the Celerra. Gigabit Ethernet (GbE) and virtual local area network (VLAN) IP connections were designed to eliminate network bottlenecks and provide maximum performance over a secured network. Physical design considerations EMC recommends that the network switches support gigabit Ethernet (GbE) connections and Link Aggregation Control Protocol (LACP), and that the ports on the switches support copper-based media. Logical design considerations This validated solution uses virtual local area networks (VLANs) to segregate network traffic of various types to improve throughput, manageability, application separation, high availability, and security. The IP scheme for the virtual desktop network must be designed in such a way that there are enough IP addresses available in one or more subnets for the DHCP server to assign them to each virtual desktop. Link aggregation The Celerra unified storage platform provides network high availability and redundancy by using link aggregation. This is one of the methods to deal with the problem of link or switch failure. 22

23 Link aggregation is a high availability feature that enables multiple active Ethernet connections to appear as a single link with a single MAC address and multiple IP addresses. In this solution, link aggregation applied on the Celerra combines two GbE ports into a single virtual device. If a link is lost on one Ethernet port, the link fails over to the other port. All traffic is distributed across the active links. FC switch consideration The Windows 2008 R2 Hyper-V servers consist of two FC HBA ports that are connected to the Celerra NS-120 unified storage platform via FC switches in a SAN fabric. Zoning is configured on the switch to regulate the connections between the Hyper-V servers and Celerra NS-120. EMC recommends WWN-based zoning, by which access is controlled using WWNs. EMC also recommends single initiator zoning, by which a single HBA port of the Hyper-V server is connected to one or more storage ports. Network layout Network layout for the validated scenario The network layout implements the following physical connections: FC provides SAN connectivity between Windows Server 2008 R2 Hyper-V hosts and the Celerra unified storage system. GbE with TCP/IP provides network connectivity. NIC teaming on Windows Server 2008 R2 Hyper-V hosts along with link aggregation on Data Mover provide load-balancing and failover capabilities. Virtual desktop machines running on Windows Server 2008 R2 Hyper-V hosts are connected to the production network. Dedicated network switches and VLANs are used to segregate production and other networks. Virtual LANs Production VLAN The production VLAN is used for end users to access virtual desktops, Citrix XenDesktop components, and associated infrastructure servers such as DNS, Active Directory, and DHCP. Virtual desktops also use this VLAN to access a Celerra TFTP server for the PXE boot image. Other considerations In addition to VLANs, separate redundant network switches for storage can be used. It is recommended that these switches support GbE connections, jumbo frames, and port channeling. 23

24 High availability network Link aggregation on the Data Mover LACP is enabled with two GbE ports available on the Data Mover. To configure the link aggregation that uses two ports of the Ethernet NIC on server_2, type: $ server_sysconfig server_2 -virtual -name <Device Name> - create trk option "device=cge0,cge2 protocol=lacp" To verify if the ports are channeled correctly, type: $ server_sysconfig server_2 -virtual -info lacp0 server_2 : *** Trunk lacp0: Link is Up *** *** Trunk lacp0: Timeout is Short *** *** Trunk lacp0: Statistical Load C is IP *** Device Local Grp Remote Grp Link LACP Duplex Speed cge Up Up Full 1000 Mbs cge Up Up Full 1000 Mbs The remote group number for both cge ports needs to match and the LACP status must be Up. Confirm if the appropriate speed and duplex are established as expected. NIC teaming on the Windows 2008 R2 Hyper- V server NIC teaming is configured to provide highly available network connectivity to the Windows 2008 R2 Hyper-V server. If Intel NICs are installed, run the following command to create a two-port NIC team that uses the Virtual Machine Load Balancing (VMLB) algorithm. C:\Program Files\Intel\DMIX\CL>PROSetCL.exe team_create 1,2 Team1 VMLB Refer to the third-party vendor documentation for NIC teaming configuration detail. 24

25 Chapter 5: Installation and Configuration Overview Introduction This chapter provides procedures and guidelines for installing and configuring the components that make up the validated solution scenarios. It is not intended to be a comprehensive step-by-step installation guide, and highlights only configurations that pertain to the validated solution. Scope The installation and configuration instructions presented in this chapter apply to the specific revision levels of components used during the development of this solution. Before attempting to implement any real-world-based solution on this validated scenario, gather the appropriate installation and configuration documentation for the revision levels of the hardware and software components used in this solution. Contents This chapter contains the following topics: Topic See Page Overview 25 Task 1: Set up and configure the NFS datastore 26 Task 2: Install and configure Desktop Delivery Controller 26 Task 3: Install and configure Provisioning Server 32 Task 4: Configure and provision the master virtual machine 45 template Task 5: Deploy virtual desktops 45 25

26 Task 1: Set up and configure the FC LUNs Configure the Windows 2008 R2 Hyper-V servers to access the FC LUNs To prepare each Windows 2008 R2 Hyper-V server to access the shared FC LUNs as cluster shared volumes (CSV), complete the following steps: Step Action 1 Install the following components on the Windows servers: Fibre Channel HBA driver and utility Navisphere Agent PowerPath 2 Enable Failover Clustering features in Windows 3 Provision LUNs on the array and present them to the hosts 4 Configure Fibre Channel switch zoning 5 Quick format the FC LUNs using NTFS formatting 6 Add the newly formatted volumes to the shared storage in failover clustering 7 Convert the shared storage into CSV Task 2: Install and configure Desktop Delivery Controller Database server Microsoft SQL Server 2005 Enterprise Edition is installed on a dedicated Windows Server 2003 virtual machine to host the databases required to store the configurations for the following three components Desktop Delivery Controller, Provisioning Server, and SCVMM Server. Use the following options when configuring SQL Server: Configure Windows Authentication Mode as the SQL Server s Authentication Mode. Provide a custom SQL Server instance name or use the default instance name. Provide this SQL Server name and instance name as Database Server options while installing the Provisioning Server. Note: The Provisioning Server installation CD comes with Microsoft SQL Server 2005 Express Edition. However, the databases on Express Edition may not offer the scalability required for the Provisioning Server, Desktop Delivery Controller, and SCVMM Server. Install SCVMM Administrator Console The DDC has to communicate with the SCVMM server to manage Hyper-V virtual machines. Prior to installing the DDC software, it is recommended to install the SCVMM administrator console so the DDC setup wizard will automatically install the SCVMM plugin that is required when creating a desktop group using Microsoft Virtualization as the hosting infrastructure. If the SCVMM administrator console is installed after the DDC software is installed, then the plugin must be manually added to the Citrix Pool Management service. Follow these steps to add the SCVMM plugin manually. 26

27 Step Action 1 On the DDC, open the Control Panel and click Add/Remove Programs. 2 Select Citrix Pool Management, and click the Change button. The Welcome to the Citrix Pool Mangement Setup Wizard dialog appears. 3 Click Next. The Modify, Repair or Remove Installation dialog appears. 27

28 4 Click Modify. The Custom Setup dialog appears. 5 Select the Microsoft SCVMM plugin option and choose Will be installed on local hard drive option. Click Next. The Ready to Install dialog appears. 28

29 6 Click Install. After the Microsoft SCVMM plugin is successfully installed, the Completing the Citrix Pool Management Setup Wizard dialog appears. 7 Click Finish. Install Desktop Delivery Controller On the virtual machine designated as the first Desktop Delivery Controller, install the following components from the Citrix DDC installation CD (or ISO): Citrix Desktop Delivery Controller Citrix Management Console Citrix License Server Select Create new farm from the Create or Join a Farm dialog. To use an external SQL server, select Use an existing Database Server for the Optional Server Configuration dialog box of the installation wizard. The Database Configuration dialog box appears, as shown in the figure below. Select the Database server type as SQL Server. Click the Configure button to configure the ODBC connection to the SQL Server database. 29

30 Configure additional Desktop Delivery Controllers To install additional Desktop Delivery Controllers, select the Citrix Desktop Delivery Controller component from the installation CD (or ISO). Select Join existing Farm and type the name of the first DDC in the Type the name of the first controller in the farm dialog. 30

31 Throttle commands to SCVMM server By default, the DDC Pool Management service will attempt to start 10 percent of a desktop pool size. It may be necessary to throttle the number of concurrent requests sent to the vcenter Server and not to overwhelm the VMware infrastructure. To modify the number of concurrent requests, edit the following configuration on each DDC: 1. Open the CDsPoolMgr.exe.config file from C:\Program Files (x86)\citrix\vmmanagement\ using a text editor such as Notepad. 2. Add the MaximumTransitionRate parameter on a new line and set the value to the required number of concurrent requests. A value of 20 is used in this solution. <?xml version="1.0" encoding="utf-8"?> <configuration> <appsettings> <add key="logtocdf" value ="1"/> <add key= MaximumTransitionRate value= 20 /> </appsettings> </configuration> 3. After saving the file, restart either the DDC or the Citrix Pool Management Service for the change to take effect. Virtual desktop idle pool settings The DDC manages idle virtual desktops based on time, and automatically optimizes the idle pool settings in the desktop group based on the number of virtual desktops in the group. These default idle pool settings need to be adjusted according to customer requirements to have virtual machines powered on in advance to avoid a boot storm scenario. During validation testing, the idle desktop count is set to match the number of desktops in the group to ensure that all desktops are powered on in a steady state and ready for client connections. To change the idle pool settings after a desktop group is created: 1. Navigate to Start > All Programs > Citrix > Management Consoles > Delivery Services Console on the DDC. 2. In the left pane, navigate to Citrix Resources > Desktop Delivery Controller > <XenDesktopFarmName> > Desktop Groups 3. Right-click the desktop group name and select Properties. 4. Select Idle Pool Settings in the left pane under the Advanced option. 5. In the Idle Desktop Count section in the right pane, modify the number of desktops to be powered on during Business hours, Peak time, and Out of hours. You can optionally redefine business days and hours per your business requirements. 6. Click OK to save the settings and close the window. 31

32 Task 3: Install and configure Provisioning Server Install Provisioning Server Unlike the Citrix Desktop Delivery Controller, the installation process for the Provisioning Server is identical for the first Provisioning Server in the desktop farm and any additional Provisioning Servers installed in the farm. Run the Provisioning Services Configuration Wizard after the installation of the Provisioning Services software. The configuration options differ between the first and secondary (or additional) Provisioning Servers. The following steps highlight the configuration wizard options customized for this solution. 32

33 Provisioning Server DHCP services Since the DHCP services run on a dedicated DHCP server, select The service that runs on another computer for DHCP services when configuring the DHCP services in the configuration wizard. Click Next. 33

34 Provisioning Server PXE services The Provisioning Server is not used as a PXE server because DHCP services are hosted elsewhere. Select The service that runs on another computer for PXE services when configuring the PXE services in the configuration wizard. Click Next. 34

35 Provisioning Server Farm configuration From the Farm Configuration page of the Configuration Wizard, select Create farm to configure the first Provisioning Server or Join existing farm to configure additional Provisioning Servers. With either option, the wizard will prompt for a SQL server and its instance. First, Provisioning Server will use these inputs to create a database to store the configuration details of the Provisioning Server. Additional Provisioning Servers use these inputs to retrieve information about existing farms from the database. Click Next. 35

36 Provisioning Server User account Because the master desktop vdisk is stored on a local drive on each Provisioning Server, select Local system account (Use with SAN) as the user account to run the stream and soap services on the Provisioning Servers. Click Next. 36

37 Provisioning Server Stream services Select the appropriate network card for the stream services from the Available network cards pane. Use the default values for the First port, Last port, and Soap server port used for Console access fields. Click Next. 37

38 Provisioning Server TFTP Because the TFTP server is hosted on the Celerra, clear the Use the Provisioning Services TFTP service. Click Next. 38

39 Inbound communication Each Provisioning Server maintains a range of User Datagram Protocol (UDP) ports to manage all inbound communications from the virtual desktops. The values of 21 ports, and eight threads per port may not support a large number of virtual desktops in this validated solution. The total number of threads supported by a Provisioning Server is calculated as: Total threads = (Number of UDP ports * Threads per port * Number of network adapters) Ideally, there should be one thread dedicated for each desktop session. The number of UDP ports is increased to 64 (port range of 6910 to 6973) and the number of threads per port is increased to 10 on each Provisioning Server (PVS) (64 * 10 * 1 NIC = 640 threads per server) to accommodate up to 1,000 desktops. The number of UDP ports can be modified in the Network tab of the Server Properties dialog box (as shown in the following figure). The Server Properties dialog box appears when you double-click a Provisioning Server in the Provisioning Services Console. The threads per port parameter can be modified by using the Advanced option. 39

40 By default the Citrix PVS two-stage boot service uses port Since this solution does not require this service, the two-stage boot service is disabled to avoid conflict, and it enables the UDP port to range up to It is a best practice to maintain the same server properties among all PVS servers. In particular, all servers must have the same port range configured. Sharing the Master vdisk via Passthrough Disk The Master vdisk is stored on a LUN that is shared among the PVS servers. Since each PVS run as a virtual machine, the LUN can be presented to the PVS VMs via a Hyper-V pass-through disk as shown in the figure below. The pass-through disk is added via SCSI controller, which allows the virtual disk to be hot swappable. The Master vdisk is not hot swappable if it is configured with an IDE controller. Disk align virtual disk For better performance, it is recommended to align the virtual disk of the Provisioning Server and other virtual machines. For Windows 2003 virtual machines, disk alignment is done by using the diskpart.exe tool. Select the appropriate disk in the DISKPART prompt and type the following command to align the partition with 1024 KB offset: DISKPART> create partition primary align=

41 Citrix XenConvert is used when the golden image of the master virtual machine is cloned to the master vdisk. Provisioning Services 5.1 contains XenConvert 2.0.x. XenConvert 2.0.x fixes the partition offset at 252 KB, which causes disk misalignment. XenConvert version 2.1 or later contains an option to specify the desired offset to align the disk correctly. Locate the XenConvert.ini file in the same location as the XenConvert executable. To set the offset to 1024 KB, add the following section and the value to the file: [parameters] PartitionOffsetBase= To specify the offset manually, upgrade Xenconvert to the latest version. vdisk access mode After the golden image of the master virtual machine is cloned to the master vdisk, the Access Mode must be changed from Private Image to Standard Image to enable virtual desktops to share the common vdisk. Thereafter, the vdisk becomes read-only, and virtual desktop changes are redirected to a write cache area. In this solution, the write cache type is set to Cache on device s HD to ensure that each virtual desktop uses its own VHD to store the write cache. 41

42 Read only NTFS volume with vdisk Modifying the master vdisk access mode to Standard Image changes the underlying VHD file to write-protected because the golden image is sealed. As a result, the NTFS volume that is used to host the vdisk can be made read-only such that it can be shared across other Provisioning Servers without the need of a clustered file system to handle any file locking issues. Read-only access to the NTFS volume is enabled by using the diskpart command. Run this command from the command prompt, select the target volume, and type: DISKPART> attributes volume set readonly After setting the read-only attribute, the NTFS volume needs to be remounted for the read-only flag to take effect. Since the PVS runs as a virtual machine this can be done by removing and adding the virtual disk from the Virtual Machine Properties screen. When the virtual machine is powered on, the add/remove operations are available in vsphere 4 only. Configure a bootstrap file The bootstrap file required for the virtual desktops to PXE boot is updated using the Configure Bootstrap option. This option is available in the Provisioning Services Console (Farm > Sites > Site-name > Servers). The Configure Bootstrap dialog box is shown in the following figure. After the new PVS is added to the server farm, the bootstrap image must be updated to reflect the IP addresses used for all PVS servers that provide streaming services, in a round-robin fashion. The list of PVS servers can be obtained by either clicking Read Servers from Database or by manually adding the server information by clicking Add. 42

43 When modifying the configuration, click OK to update the ARDBP32.BIN bootstrap file, which is located at C:\Documents and Settings\All Users\Application Data\Citrix\Provisioning Services\Tftpboot. Navigate to the folder and examine the timestamp of the bootstrap file to ensure that the bootstrap file is updated on the intended Provisioning Server. Copy the bootstrap file to the TFTP server on Celerra In addition to serving FC LUNs, EMC Celerra unified storage is used as a TFTP server that provides a bootstrap image when virtual desktops PXE boot. To configure the Celerra TFTP server, complete the following steps: Step Action 1 Enable the TFTP service by using the following command: server_tftp <movername> -service start 2 Set the TFTP working directory and enable read/write access for file transfer by using the following command syntax. It is assumed that the path name references to a file system created in RAID group 0 as shown in Disk layout for 10 building blocks on page 17. server_tftp <movername> -set -path <pathname> -readaccess all writeaccess all 3 Use a TFTP client, of your choice, to upload the ARDBP32.BIN bootstrap file from C:\Documents and Settings\All Users\Application Data\Citrix\Provisioning Services\Tftpboot on the Provisioning Server to the Celerra TFTP server. 4 Set the TFTP working directory access to read-only to prevent accidental modification of the bootstrap file by running the following command: server_tftp <movername> -set -path <pathname> writeaccess none 43

44 Configure boot options 66 and 67 on the DHCP In order for the virtual desktops to PXE boot successfully from the bootstrap image supplied by the Provisioning Servers, the DHCP server must have boot options 66 and 67 configured. To configure boot options 66 and 67 on the DHCP, complete the following steps: Step Action 1 On the installed Microsoft DHCP server, select Scope Options. 2 Select 066 Boot Server Host Name. 3 Enter the IP address of the Data Mover configured as the TFTP server in the String value box. 4 Enable 067 Bootfile Name and enter ARDBP32.BIN in the String value field. The ARDBP32.BIN bootstrap image is loaded on a virtual desktop before the vdisk image is streamed from the Provisioning Server. 44

45 Task 4: Configure and provision the master virtual machine template Create a virtual machine as a template for virtual desktops To create a virtual machine to use as a template for the virtual desktops, use the Create New Virtual Machine wizard. This validated solution uses Microsoft Windows XP (32-bit edition) as the virtual desktop guest operating system. Ensure that the base virtual machine is allocated with one vcpu, 512 MB system RAM, and an emulated network adapter that uses a legacy driver. Emulated network adapter is chosen as opposed to synthetic adapter because when a desktop PXE boots to retrieve the desktop image from the PVS, a synthetic adapter cannot be used at that stage until the guest operating system is completely booted up. Creating a new virtual machine with a network adapter by default creates a synthetic network adapter. The synthetic adapter must be removed after the VM is created, and an emulated or legacy adapter needs to be added. New hardware found message When the virtual hard disk is attached to the master vdisk as a write-cache drive for the first time, Windows will detect the drive as new hardware and prompt for a reboot as soon as a virtual desktop session begins. To avoid such a reboot, attach the virtual hard disk to the master virtual machine before its image is cloned to the vdisk, such that the vdisk image contains the disk signature that will be recognized when the virtual desktops are started. Task 5: Deploy virtual desktops Install SCVMM Administrator Console Prior to running XenDesktop Setup Wizard on the PVS to provision virtual desktops, the SCVMM Administrator Console needs to be installed to ensure the PVS can communicate with the SCVMM server. Default virtual machine placement When a Windows Server 2008 R2 Hyper-V server is added to the SCVMM to be managed, be sure to specify the CSV paths as the default virtual machine placement locations. Otherwise, the default behavior is to create the virtual machines on the local drive. 45

46 XenDesktop Setup Wizard The XenDesktop Setup Wizard installed on the Provisioning Server simplifies virtual desktop deployment, and can rapidly provision a large number of desktops. To run this wizard, complete the following steps: Step Action 1 Select Start > All Programs > Citrix > Administration Tools > XenDesktop Setup Wizard on the Provisioning Server. The Welcome to XenDesktop Setup Wizard page appears. Click Next. 2 When the Desktop Farm page appears, select the relevant farm name from the Desktop farm list. The list of farms appears. Click Next. 3 On the Hosting Infrastructure page, select Microsoft virtualization 46

47 as the hosting infrastructure. Type the IP address or host name of the SCVMM Server. Click Next. Note: You will be prompted to specify the user credentials for the SCVMM Server. 4 On the Virtual Machine Template page, select the virtual machine that you want to use as a template for the virtual desktops. These virtual machines are retrieved from the SCVMM Server. Click Next. The Virtual Disk (vdisk) page appears. 47

48 5 Select the vdisk from which the virtual desktops will be created. Only vdisks in standard mode appear. As shown in the following figure, the list of existing device collections contains only the device collections that belong to the same site as the vdisk. Click Next. The Virtual Desktops page appears. 6 Enter the following and click Next. The number of desktops to create. The common name to use for all the desktops. The start number to enumerate the newly created desktops. The sequence of this number will be appended to the common name, and will be assigned to the virtual desktop names. The Organizational Unit Location page appears. 48

49 7 Select the OU to which the desktops will be added and click Next. The Desktop Group page appears. 8 Specify the group of the Desktop Delivery Services to which to add the desktops and click Next. The Desktop Creation page appears. 9 Ensure that the details are correct and then click Next to create the desktops. 49

50 The Summary page appears. Note: Clicking Next will start creating desktops and computer objects in the Active Directory. This process is irreversible. Attaching writecache drives Although XenDesktop Setup Wizard creates VMs according to the template VM, it will not attach any drives to the new VMs. All write-cache drives (VHD files) need to be added after the desktops are created. The SCVMM Server can be used to create the write-cache drive and attach it to the virtual machines. Powershell scripts can be used to automate this process for all 1,000 VMs. For more information about the Powershell scripts, refer to the Citrix blog post at ktop+part+2. 50

51 Chapter 6: Testing and Validation Overview Introduction This solution for Citrix XenDesktop 4 on EMC Celerra explores several configurations that can be used to implement a 1,000-user environment using EMC Celerra. Contents This section contains the following topics: Topic See Page Overview 51 Testing overview 51 Testing tools 51 Test results 53 Result analysis of Desktop Delivery Controller 54 Result analysis of Provisioning Server 58 Result analysis of the vcenter Server 62 Result analysis of SQL Server 64 Result analysis of ESX servers 68 Result analysis of Celerra unified storage 73 Login storm scenario 82 Test summary 84 Testing overview Introduction This chapter provides a summary and characterization of the tests performed to validate the solution. The goal of the testing was to characterize the end-to-end solution and component subsystem response under reasonable load for Citrix XenDesktop 4 with a Celerra NS-120 over FC. Testing tools Introduction To apply a reasonable real-world user workload, a third-party benchmarking tool LoginVSI from Login Consultants was used. LoginVSI simulates a VDI workload using the AutoIT script on each desktop session to automate the execution of generic applications like Microsoft Office 2007, Internet Explorer, Adobe Acrobat Reader, Notepad, and other third-party software. 51

52 LoginVSI Test methodology Virtual Session Index (VSI) provides guidance to gauge the maximum number of users a desktop environment can support. LoginVSI workloads can be categorized as light, medium, heavy, and custom. Medium is the only workload that is available in the VSI Express (free edition) and Pro editions. VSI Pro edition and a medium workload were chosen for testing this solution. They have the following characteristics: Emulate a medium knowledge worker using Office, Internet Explorer, and Acrobat Reader. Once a session is started, the medium workload will repeat every 12 minutes. The response time is measured every 2 minutes during each loop. The medium workload opens up to five applications simultaneously. The type rate is 160 ms for each character. The medium workload in VSI 2.0 is approximately 35 percent more resource-intensive than VSI 1.0. Approximately 2 minutes of idle time is included to simulate real-world users. Each loop of the medium workload will open and use: Outlook 2007: Browse 10 messages. Internet Explorer: One instance is left open (BBC.co.uk). One instance is opened to Wired.com, Lonelyplanet.com, and the heavy flash app, gettheglass.com (not used with MediumNoFlash workload). Word 2007: One instance to measure response time and one instance to review and edit the document. Bullzip PDF Printer and Acrobat Reader: The Word document is printed, and the PDF is reviewed. Excel 2007: A very large, randomized spreadsheet is opened. PowerPoint 2007: A presentation is reviewed and edited. 7-zip: Using the command line version, the output of the session is zipped. The current LoginVSI version is This version has a gating metric called VSImax that measures the response time of five operations: 1. Maximizing Microsoft Word. 2. Starting the File Open dialog box. 3. Starting the Search and Replace dialog box. 4. Starting the Print dialog box. 5. Starting Notepad. The LoginVSI workload is gradually increased by starting desktop sessions one after another at a specified interval. Although the interval can be customized, the default interval of 1 second is used during the testing. The desktop infrastructure is considered saturated when the average response time of three consecutive users crosses the 2,000 ms threshold. The administrator guide available at provides more information on the LoginVSI tool. LoginVSI launcher A LoginVSI launcher is a Windows system that launches desktop sessions on target virtual desktop machines. There are two types of launchers master and slave. There is only one master in a given test bed, but there can be as many slave launchers as required. Launchers coordinate the start of the sessions using a common CIFS share. In this validated testing, the share is created on a Celerra file 52

53 system that resides in the 4+1 RAID 5 group as shown in Disk layout for 10 building blocks on page 17. The number of desktop sessions a launcher can run is typically limited by CPU or memory resources. Login Consultants recommends using a maximum of 45 sessions per launcher with two CPU cores (or two dedicated vcpus) and 2 GB of RAM when the GDI limit has not been tuned (default). If the GDI limit has been tuned, this limit extends to 60 sessions per two-core machine. In this validated testing, 1,000 desktop sessions were launched from 48 launchers, resulting in 20 or 21 sessions established per launcher. Each launcher is allocated two vcpus and a 4 GB of RAM to prevent any system bottlenecks. Test results Result summary The following graph shows the response time compared to the number of active desktop sessions, as generated by the LoginVSI launchers. It shows that the average response time increases marginally as the user count increases. Throughout the test run, the average response time hovers around 500 ms, which is significantly lower than the 2,000 ms gating metric. The maximum response time increases nominally as the user count increases, with some spikes. However, it never exceeds 7,000 ms. 53

54 Result analysis of Desktop Delivery Controller Introduction Since the two DDCs are load balanced to host 1,000 desktops, their performance counters are comparable. As a result, only the statistics for the first DDC are reported in the following sections. CPU utilization The average percentage processor time is recorded at 9.99 percent with occasional spikes that reach as high as 68 percent. The percentage processor time is reported based on the average of two vcpus. 54

55 Memory utilization Each DDC virtual machine was configured with 4 GB of RAM. The memory utilization fluctuates between 1.3 GB and 1.8 GB; however, the utilization exceeds 4 GB towards the end of the test as a result of concurrent user logoff. The average utilization is around 1.5 GB, consuming less than half of the available memory. 55

56 Disk throughput A Windows operating system and XenDesktop software were installed on a local drive for each DDC. As seen in the following graph, despite spikes occurring at the end of the test due to concurrent user logoff, the average disk throughput is about 12.6 KB/s at the end of the test run. 56

57 Network throughput Each DDC virtual machine was configured with a gigabit Ethernet adapter that uses a synthetic network adapter to manage the virtual desktops. An average transfer rate of 270 KB/s translates to 2.2 Mb/s. A surge of 1009 KB/s (or 8.1 Mb/s) was measured at the end of the test run due to concurrent users logging off. 57

58 Result analysis of Provisioning Server Introduction Since the two PVSs are load balanced to host 1,000 desktops, their performance counters are comparable. As a result, this section covers only the statistics for the first PVS. CPU utilization Two vcpus were configured for each PVS server that communicates with 500 desktops. The following graph validates that the two-cpu virtual machine is sufficient. The average percentage processor time is recorded at 6.81 percent with spikes at the end of the test that reach as high as 89 percent due to concurrent user logoff. The percentage processor time is reported based on the average of two vcpus. 58

59 Memory utilization Each PVS virtual machine was configured with 4 GB of RAM. The memory utilization remains steady in the range of 1.2 GB to 1.3 GB. 59

60 Disk throughput The following graph shows the disk throughput measured for the physical disk that stores the master vdisk. Since the PVS servers cache the vdisk data blocks in memory, the initial read activity is observed at 1.9 MB/s. Negligible disk activity is observed thereafter. 60

61 Network throughput Each PVS virtual machine was configured with a gigabit Ethernet adapter that uses a synthetic network adapter to stream the vdisk image to virtual desktops. The average network throughput is recorded at 3.67 MB/s (or 29.4 Mb/s). The maximum network throughput is capped below 48 MB/s (or 384 Mb/s) towards the end of the run despite a spike in activity as a result of concurrent user logoff. 61

62 Result analysis of the SCVMM Server Introduction The SCVMM Server maintains a cluster of 16 Windows 2008 R2 Hyper-V servers that host a total of 1,000 desktop virtual machines. CPU utilization The SCVMM Server virtual machine is configured with four vcpus. The average CPU utilization is less than 9 percent throughout the test. Periodic surges hover around 75 percent while the logoff storm towards the end of the run momentarily catapults the utilization to as high as 100 percent. 62

63 Memory utilization 4 GB of RAM were allocated to the SCVMM Server virtual machine. Committed bytes seldom exceed 3 GB. Disk throughput A Windows operating system and SCVMM Server software were installed on an FC LUN. There is minimal disk I/O activity as seen in the following graph. 63

64 Network throughput The SCVMM Server was configured with a gigabit Ethernet adapter that uses a synthetic network adapter. The majority of the network activity comes from the DDCs that manipulate and detect the state of each virtual desktop. The average network throughput is measured at 1101 KB/s (or 8.8 Mb/s). Logoff activity towards the end of the run triggers a spike of 7679 KB/s (or 61.4 Mb/s). Result analysis of SQL Server Introduction Three databases were created on the SQL server, which is the central repository of the DDC, PVS, and SCVMM Server configurations. The database size for the SCVMM Server grows to nearly 2 GB the largest of the three databases. The DDC and PVS databases require 10 MB and 5 MB, respectively. 64

65 CPU utilization The SQL Server virtual machine was configured with dual vcpus. The average CPU utilization is less than 9 percent throughout the test. Periodic surges are curbed at 41 percent. 65

66 Memory utilization 4 GB of RAM were allocated to the SQL Server virtual machine. Committed bytes were steady around 3.2 GB, increasing towards the end, but never exceeding 3.7 GB. 66

67 Disk throughput A Windows operating system and SQL Server software were installed on an FC LUN. The average disk throughput is about 73 KB/s, while the maximum throughput is recorded around 2.2 MB/s, towards the end of the test during logoff storm. 67