Ibm and Xendesktop Xenapp

ibm.
com/redbooks
Implementing
Citrix XenDesktop on
IBM Flex System
Ilya Krutov
Andreas Groth
Gica Livada
Diego Pereira
Jean-Baptiste Valette
Brad Wasson
Introduces IBM Flex System and
Citrix XenDesktop offerings
Discusses design and
deployment considerations
Provides step-by-step
configuration guidance
Front cover
Implementing Citrix XenDesktop on IBM Flex
System
January 2014
International Technical Support Organization
SG24-8163-00
Copyright International Business Machines Corporation 2014. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
First Edition (January 2014)
This edition applies to IBM Flex System and Citrix XenDesktop 5.5 and 5.6.
Note: Before using this information and the product it supports, read the information in
Notices on page vii.
Copyright IBM Corp. 2014. All rights reserved. iii
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . xii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Chapter 1. IBM SmartCloud Desktop Infrastructure overview . . . . . . . . . . 1
1.1 Virtual desktop infrastructure overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 IBM SmartCloud Desktop Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 IBM Flex System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Citrix XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Integration with other IBM software products . . . . . . . . . . . . . . . . . . . . . . 12
Chapter 2. IBM Flex System components for the virtual desktop
infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Introduction to IBM Flex System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Planning for Flex System components . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 IBM Flex System compute nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 IBM Flex System x222 Compute Node. . . . . . . . . . . . . . . . . . . . . . . 17
2.3.4 IBM Flex System PCIe Expansion Node. . . . . . . . . . . . . . . . . . . . . . 21
2.3.5 IBM System x3650 M4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.6 VMware ESXi 5.1 Embedded Hypervisor . . . . . . . . . . . . . . . . . . . . . 23
2.4 Storage considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1 IBM Flex System V7000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2 IBM Flex System Storage Expansion Node . . . . . . . . . . . . . . . . . . . 26
2.4.3 IBM FlashSystem 820 and IBM FlashSystem 720 . . . . . . . . . . . . . . 27
2.4.4 Solid-state drives (SSDs) compared to hard disk drives (HDDs) . . . 28
2.4.5 RAID considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Network considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.1 Ethernet connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.2 Fibre Channel connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6 Management considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6.1 Introduction to IBM Flex System Manager . . . . . . . . . . . . . . . . . . . . 40
2.6.2 Management Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
iv Implementing Citrix XenDesktop on IBM Flex System
2.6.3 Chassis Management Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.6.4 Integrated Management Module II . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6.5 Working with configuration patterns . . . . . . . . . . . . . . . . . . . . . . . . . 45
Chapter 3. VMware vSphere design considerations . . . . . . . . . . . . . . . . . 47
3.1 ESXi and vSphere features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1.1 Hypervisor ESXi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1.2 VMware vCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.3 vMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.4 Distributed Resource Scheduler (DRS) . . . . . . . . . . . . . . . . . . . . . . 51
3.1.5 High Availability (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1.6 vSphere licensing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1.7 IBM Flex System integration with VMware . . . . . . . . . . . . . . . . . . . . 55
3.2 Networking considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.1 Virtual switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.2 Ports and port groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.3 Uplink ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3 Storage considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.1 Local or shared storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.2 Tiered storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.3 Redundancy and load balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapter 4. Citrix XenDesktop design basics . . . . . . . . . . . . . . . . . . . . . . . 61
4.1 Citrix XenDesktop components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2 Desktop and application delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3 Citrix XenDesktop provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.1 Provisioning Services (PVS) solution . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.2 Machine Creation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.3 Personal vDisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3.4 Image assignment models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4 Storage configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.6 Operational model and sizing guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.6.1 VDI compute node configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6.2 Management services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.6.3 Shared storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Chapter 5. IBM Flex System and Citrix XenDesktop lab environment . . . 89
5.1 Lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2 Use case for the lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3 Component model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4 Operational model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.5 Logical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5.1 Ethernet segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Contents v
5.5.2 Storage disk and host mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Chapter 6. Deploying IBM Flex System. . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.1 Initial configuration of the Chassis Management Module . . . . . . . . . . . . 100
6.1.1 Connecting to the Chassis Management Module . . . . . . . . . . . . . . 100
6.1.2 Using the initial setup wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.1.3 Configuring IP addresses for the chassis components . . . . . . . . . . 117
6.2 The IBM Flex System Manager setup wizard . . . . . . . . . . . . . . . . . . . . . 119
6.3 Selecting the chassis to manage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.4 Discovery and inventory collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.4.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.4.2 I/O modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.5 IBM Flex System Fabric EN4093 10Gb Ethernet Switch configuration. . 162
6.6 IBM Flex System x240 Compute Node configuration . . . . . . . . . . . . . . . 168
6.7 IBM Flex Storwize V7000 configuration . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.7.1 Flex System V7000 initial configuration . . . . . . . . . . . . . . . . . . . . . 182
6.7.2 V7000 Storage Node setup wizard . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.7.3 MDisk configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6.7.4 Volumes configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.7.5 Hosts configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.8 VMControl configuration and virtual server deployment . . . . . . . . . . . . . 211
6.8.1 Configure VMControl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.8.2 Create virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Chapter 7. Deploying Citrix XenDesktop. . . . . . . . . . . . . . . . . . . . . . . . . . 215
7.1 Configuring utility services and vSphere . . . . . . . . . . . . . . . . . . . . . . . . . 216
7.2 Provisioning VMs for Citrix XenDesktop components . . . . . . . . . . . . . . . 217
7.3 Installing the Citrix License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
7.3.1 Configuring the licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
7.4 Installing Citrix XenDesktop Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 228
7.4.1 Installing the SSL certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7.4.2 Installing the XenDesktop Controller . . . . . . . . . . . . . . . . . . . . . . . . 230
7.4.3 Advanced settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
7.5 Installing Citrix XenApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
7.5.1 Specify licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
7.5.2 Initial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
7.6 Installing Citrix Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
7.6.1 Configure the website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
7.7 Installing Citrix Provisioning Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
7.7.1 Install the Citrix Provisioning Console. . . . . . . . . . . . . . . . . . . . . . . 300
Chapter 8. Operating Citrix XenDesktop. . . . . . . . . . . . . . . . . . . . . . . . . . 303
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
8.2 Configuring the gold image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
vi Implementing Citrix XenDesktop on IBM Flex System
8.2.1 Preparing the gold image for streaming services . . . . . . . . . . . . . . 304
8.2.2 Preparing the gold image for persistent desktops. . . . . . . . . . . . . . 328
8.3 Configuring desktop distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
8.3.1 Configuring streamed desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
8.3.2 Configuring streaming desktops with personal vDisk . . . . . . . . . . . 353
8.3.3 Configuring persistent desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
8.3.4 Assigning a catalog to a group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
8.4 Roaming profiles and folder redirection. . . . . . . . . . . . . . . . . . . . . . . . . . 377
8.4.1 Configuring the roaming profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
8.4.2 Configuring folder redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
8.4.3 Configuring the Citrix Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
8.4.4 Group Policy Object link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
8.4.5 Configuring application distribution . . . . . . . . . . . . . . . . . . . . . . . . . 398
8.5 Monitoring health. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
8.5.1 Hardware monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
8.5.2 Hypervisor monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
8.5.3 Monitoring performance with VMControl . . . . . . . . . . . . . . . . . . . . . 401
8.5.4 Relocating the Virtual Server with VMControl . . . . . . . . . . . . . . . . . 403
8.5.5 Host Maintenance Mode with VMControl . . . . . . . . . . . . . . . . . . . . 407
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Copyright IBM Corp. 2014. All rights reserved. vii
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your
local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not infringe
any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and
verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the
information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the materials
for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any
obligation to you.
Any performance data contained herein was determined in a controlled environment. Therefore, the results
obtained in other operating environments may vary significantly. Some measurements may have been made on
development-level systems and there is no guarantee that these measurements will be the same on generally
available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual
results may vary. Users of this document should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them as
completely as possible, the examples include the names of individuals, companies, brands, and products. All of
these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is
entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any
form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs
conforming to the application programming interface for the operating platform for which the sample programs are
written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample
programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing
application programs conforming to IBM's application programming interfaces.
viii Implementing Citrix XenDesktop on IBM Flex System
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. These and other IBM trademarked
terms are marked on their first occurrence in this information with the appropriate symbol ( or ),
indicating US registered or common law trademarks owned by IBM at the time this information was
published. Such trademarks may also be registered or common law trademarks in other countries. A current
list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
BladeCenter
DS8000
Easy Tier
FlashCopy
FlashSystem
IBM
IBM Flex System
IBM Flex System Manager
IBM SmartCloud
Power Systems
PureFlex
PureSystems
Real-time Compression
Redbooks
Redbooks (logo)
Storwize
System Storage
System x
Tivoli
VMready
The following terms are trademarks of other companies:
Intel, Intel Xeon, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks
of Intel Corporation or its subsidiaries in the United States and other countries.
ITIL is a registered trademark, and a registered community trademark of The Minister for the Cabinet Office,
and is registered in the U.S. Patent and Trademark Office.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its
affiliates.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, or service names may be trademarks or service marks of others.
Copyright IBM Corp. 2014. All rights reserved. ix
Preface
The IBM SmartCloud Desktop Infrastructure offers robust, cost-effective, and
manageable virtual desktop solutions for a wide range of clients, user types, and
industry segments. These solutions help to increase business flexibility and staff
productivity, reduce IT complexity, and simplify security and compliance. Based
on a reference architecture approach, this infrastructure supports various
hardware, software, and hypervisor platforms.
The SmartCloud Desktop Infrastructure solution with Citrix XenDesktop running
on IBM Flex System offers tailored solutions for every business, from the
affordable all-in-one Citrix VDI-in-a-Box for simple IT organizations to the
enterprise-wide Citrix XenDesktop. XenDesktop is a comprehensive desktop
virtualization solution with multiple delivery models that is optimized for flexibility
and cost-efficiency.
This IBM Redbooks publication provides an overview of the SmartCloud
Desktop Infrastructure solution, which is based on Citrix XenDesktop running on
IBM Flex System. It highlights key components, architecture, and benefits of this
solution. It also provides planning and deployment considerations, and
step-by-step instructions about how to perform specific tasks.
This book is intended for IT professionals who are involved in the planning,
design, deployment, and management of the IBM SmartCloud Desktop
Infrastructure built on IBM Flex System running Citrix XenDesktop.
Authors
This book was produced by a team of specialists from around the world working
at the International Technical Support Organization, Raleigh Center.
x Implementing Citrix XenDesktop on IBM Flex System
Ilya Krutov is a Project Leader at the ITSO Center
in Raleigh. Ilya has more than 15 years of
experience in the IT industry, and he has been with
IBM since 1998. Before he joined the ITSO, Ilya
served in IBM as a Team Leader, Portfolio
Manager, Brand Manager, IT Specialist, and
Certified Instructor. Ilya has expertise in IBM
System x, BladeCenter, and Flex System
products; server operating systems; and
networking solutions. He has authored over 130
books, papers, Product Guides, and Solution
Guides. He has a Bachelors degree in Computer
Engineering from the Moscow Engineering and
Physics Institute.
Andreas Groth is the European Lead Architect for
Virtualization and Cloud for the IBM System x
Advanced Technical Skills (ATS) organization.
Andy is a recognized advocate of x86 virtualization
since early 2003 and leads technical consultancy
engagements for European clients at the senior
influence level. He is a Chartered Engineer of the
IET (CEng IET), a Chartered IT professional of the
British Computer Society (MBSC CITP), an
MCSE, and a VMware VCP2, 3, and 4. Andy is a
frequent speaker at international virtualization
conferences and a major contributor to technical
publications, including IBM Redbooks and various
technology papers. He has two international
patents to his name. Andy is an IBM WW
virtualization and cloud community lead,
practitioner, virtualization industry blogger, and the
creator of http://www.VirtualizationMatrix.com.
Preface xi
Special thanks to Matt Darlington, VDI lead in the Advanced Technical Skills
team, who made a significant contribution to the development of this book by
extensively consulting and guiding the team on VDI topics.
Gica Livada is a Certified IT Specialist with more
than 20 years experience in the IT field. He joined
IBM in 2006 and has held several different
positions: System Administrator, Customer
Technical Leader, and Virtualization Specialist. He
is currently a member of the VMware Centre of
Excellence team and preparing to become an IT
Architect. He is passionate about virtualization and
cloud technologies, and he has multiple
certifications from Citrix, Microsoft, and NetApp.
Diego Pereira is an Engagement Solution
Architect at GTS in Brazil. He has 15 years of
experience in the IT industry. His areas of
expertise include developing technical
architectures by using IBM, Citrix, Microsoft, and
VMware products. He has a Bachelors degree in
System Analysis from Pontifica Universidade
Catolica do Rio Grande do Sul (PUCRS). He holds
certifications from IBM, Microsoft, Citrix, and ITIL.
Jean-Baptiste Valette is an Associate Certified
Architect in IBM Montpelier, in France. He has
been in IBM since 2004. He supports client
projects related to user devices and desktop
management. He has expertise in IBM PureFlex
System products, Microsoft operating systems,
desktop management infrastructures, VMware,
and Citrix virtualization solutions. He also holds an
Engineering Diploma in Computer Science.
Brad Wasson is a Managing Technical Consultant
with ITXen, LLC, an IBM Business Partner. He has
over 15 years of IT experience in the
manufacturing, financial, healthcare, energy, and
education industries. Specializing in virtualization
with a focus on virtual desktop infrastructure (VDI),
Brad is a Citrix Certified and Microsoft Certified
Engineer and Architect. Additionally, he holds
certifications in the fields of information security
and application development.
xii Implementing Citrix XenDesktop on IBM Flex System
Thanks to the following people for their contributions to this project:
Kevin Barnes, Tamikia Barrow, Ella Buslovich, Mary Comianos, Shari Deiana,
Cheryl Gera, David Watts
International Technical Support Organization, Raleigh Center
Amy Freeman, Kenny Bain, Britni Coble, Michael Perks
IBM
Michael Cooper
Citrix
Now you can become a published author, too!
Heres an opportunity to spotlight your skills, grow your career, and become a
published authorall at the same time! Join an ITSO residency project and help
write a book in your area of expertise, while honing your experience using
leading-edge technologies. Your efforts will help to increase product acceptance
and customer satisfaction, as you expand your network of technical contacts and
relationships. Residencies run from two to six weeks in length, and you can
participate either in person or as a remote resident working from your home
base.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about
this book or other IBM Redbooks publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Send your comments in an email to:
redbooks@us.ibm.com
Mail your comments to:
Preface xiii
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Stay connected to IBM Redbooks
Find us on Facebook:
http://www.facebook.com/IBMRedbooks
Follow us on Twitter:
http://twitter.com/ibmredbooks
Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
Explore new Redbooks publications, residencies, and workshops with the
IBM Redbooks weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
xiv Implementing Citrix XenDesktop on IBM Flex System
Copyright IBM Corp. 2014. All rights reserved. 1
Chapter 1. IBM SmartCloud Desktop
Infrastructure overview
This chapter introduces IBM SmartCloud Desktop Infrastructure and discusses
one of its solutions, Citrix XenDesktop on IBM Flex System. The following topics
are covered:
1.1, Virtual desktop infrastructure overview on page 2
1.2, IBM SmartCloud Desktop Infrastructure on page 3
1.3, IBM Flex System on page 7
1.4, Citrix XenDesktop on page 9
1.5, Integration with other IBM software products on page 12
1
2 Implementing Citrix XenDesktop on IBM Flex System
1.1 Virtual desktop infrastructure overview
Today, businesses are looking for ways to securely bring in new ways for people
to communicate at work without having to limit them to an office. Personal tablets,
smartphones, and netbooks now dominate a landscape once owned by the
personal computer. Delivering the same business applications securely to these
new devices drives the adoption of the virtual desktop infrastructure (VDI).
VDI is based on a desktop-centric model to provide an environment to the remote
networked-based user. The user accesses the desktop using a remote display
protocol on their device in a secure manner. The resources are centralized and
allow users to move between locations while accessing the applications and
data. This allows administrators better control over the management of the
desktop as well as tighter security.
The idea of having a centralized infrastructure has been around since the day of
mainframe and terminal clients. In the early 1990s, there was a shift to a
client/server model to meet the need for more flexibility by the user. This led to
the idea of a centralized infrastructure for back-end processing and gave users
the ability to save programs and files locally on their hard disk drives.
As the workforce changed from an office orientation to a more mobile and always
on environment, the demand for flexibility grew. VDI has been the answer for
many businesses. The market for VDI has changed how vendors are marketing
their solutions. Traditional IT shops built out their infrastructure piece by piece
along with the software or hypervisor. This tends to increase the amount of time
needed to manage the storage, servers, and network environment.
A new market has emerged with the introduction of complete solutions of all
aspects needed to implement, deploy, and maintain a virtual desktop solution.
IBM has been at the top of this market with IBM PureSystems and leads the
way with the only homogeneous vendor infrastructure. Other vendors have put
pieces of the solution together but IBM is the only company to provide software,
servers, storage, and networking in a single, easy-to-use management system.
One of the most important aspects of deploying a virtual desktop solution is to
control costs while providing familiar user experience and functionality. The other
important aspect is the ability to scale to the demanding needs of the user. Too
many times, businesses are excited with a solution but soon outgrow the initial
deployment and find it hard to add the next 100 users or 100 TB of storage.
Therefore, careful planning and analysis must be done to ensure the successful
implementation of VDI projects.
IBM VDI solutions are consolidated under the SmartCloud Desktop Infrastructure
umbrella.
Chapter 1. IBM SmartCloud Desktop Infrastructure overview 3
1.2 IBM SmartCloud Desktop Infrastructure
IBM SmartCloud Desktop Infrastructure offers robust, cost-effective, and
manageable virtual desktop solutions for a wide range of clients, user types, and
industry segments. These solutions can help to increase business flexibility and
staff productivity, reduce IT complexity, and simplify security and compliance.
Based on a reference architecture approach, this infrastructure supports various
hardware, software, and hypervisor platforms.
The SmartCloud Desktop Infrastructure solution with Citrix XenDesktop running
on IBM Flex System offers tailored solutions for every business, from the
affordable all-in-one Citrix VDI-in-a-Box to the enterprise-wide Citrix XenDesktop.
XenDesktop is a comprehensive desktop virtualization solution with multiple
delivery models that is optimized for flexibility and cost-efficiency.
The hosted virtual desktop (HVD) approach, combined with the streaming
applications, is the most common form of implementing a virtualized user
desktop environment. With HVDs, all applications and data that the user interacts
with are stored centrally and securely in the data center. These applications
never leave the data center boundaries. This setup makes management and
administration much easier and gives users access to data and applications from
anywhere and at anytime.
The following drivers are key for virtual desktops in todays business climate:
Data security and compliance concerns
Complexity and costs of managing existing desktop environments
An increasingly mobile workforce
The changing ownership of endpoint devices with bring-your-own-device
(BYOD) programs
The need for rapid recovery from theft, failure, and disasters
IBM SmartCloud Desktop Infrastructure offers the following benefits:
Lowers the total cost of ownership (TCO) over an extended period compared
to traditional PCs
Simplifies desktop administration, support, and management
Enhances security and compliance management
Improves availability and reliability
Enables users to work anytime, anywhere quickly and easily regardless of
location or device
Supports growth initiatives for mobility and flexible work locations better
The IBM SmartCloud Desktop Infrastructure solution with Citrix XenDesktop
running on IBM Flex System includes the following components:
Virtual infrastructure software
Citrix XenDesktop
Hardware platform:
IBM Flex System
IBM System Storage
Integration services:
Assess and plan
Design
Implement
Operate and manage
Figure 1-1 shows the functional components of the SmartCloud Desktop
Infrastructure solution.
Figure 1-1 SmartCloud Desktop Infrastructure functional components
Storage
services
Virtual
infrastructure
services
End user
access
Management and
provisioning
Image repository VM files User profiles
Connection broker
Hypervisor
Thin client Notebook Tablet PC Desktop PC
HVD HVD HVD
HVD HVD HVD
Hypervisor
HVD HVD HVD
HVD HVD HVD
HVD HVD HVD
HVD HVD HVD
HVD HVD HVD
HVD HVD HVD
HVD HVD HVD
Display protocol
Storage protocol
Stateless HVD Dedicated HVD
High availability
The SmartCloud Desktop Infrastructure solution consists of three functional
layers:
User access layer
The user access layer is a user entry point into the virtual infrastructure.
Devices that are supported at this layer include traditional desktop PCs, thin
clients, notebooks, and handheld mobile devices.
Virtual infrastructure services layer
The virtual infrastructure services layer provides the secure, compliant, and
highly available desktop environment to the user. The user access layer
interacts with the virtual infrastructure layer through display protocols. The
Remote Desktop Protocol (RDP), half-duplex (HDX), and Independent
Channel Architecture (ICA) display protocols are available in Citrix
XenDesktop.
Storage services layer
The storage services layer stores user persona, profiles, gold master images,
and actual virtual desktop images. The storage protocol is an interface
between virtual infrastructure services and storage services. The storage
protocols supported by Citrix XenDesktop include Network File System
(NFS), Common Internet File System (CIFS), iSCSI, and Fibre Channel.
The virtual infrastructure services layer has the following key functional
components:
Hypervisor
The hypervisor provides a virtualized environment for running virtual
machines (VMs) with the desktop operating systems in them. These VMs are
called hosted virtual desktops.
Hosted virtual desktops
An HVD is a VM that runs a user desktop operating system and applications.
Connection broker
The connection broker is the point of contact for the client access devices that
request the virtual desktops. The connection broker manages the
authentication function and ensures that only valid users are allowed access
to the infrastructure. When authenticated, it directs the clients to their
assigned desktops. If the virtual desktop is unavailable, the connection broker
works with the management and provisioning services to have the VM ready
and available.
Management and provisioning services
The management and provisioning services allow the centralized
management of the virtual infrastructure, providing a single console to
manage multiple tasks. They provide image management, lifecycle
management, and monitoring for hosted VMs.
High availability services
High availability (HA) services ensure that the VM is up and running even if a
critical software or hardware failure occurs. HA can be a part of connection
broker function for stateless HVDs or a separate failover service for dedicated
HVDs.
There are two types of the assignment models for the user HVDs: persistent and
non-persistent.
A persistent (also known as stateful or dedicated) HVD is assigned permanently
to the specific user (similar to a traditional desktop PC). Users log in to the same
virtual desktop image every time they connect. All changes that they make and
each application that they install are saved when the user logs off. The dedicated
desktop model is best for users who need the ability to install more applications,
store data locally, and retain the ability to work offline.
A non-persistent (also known as pooled or stateless) HVD is allocated
temporarily to the user. After the user logs off, changes to the image are
discarded (reset). Then, the desktop becomes available for the next user, or a
new desktop is created for the next user session. A persistent user experience
(the ability to personalize the desktop and save data) is achieved through user
profile management, folder redirection, and similar approaches. Specific
individual applications can be provided to nonpersistent desktops by using
application virtualization technologies, if required.
Functional layers and components are supported by a hardware infrastructure
platform that must provide the following features:
Sufficient computing power to support demanding workloads
Scalability to satisfy future growth requirements
Reliability to support business continuity and 24x7 operations
High-speed, low-latency networking for a better user experience
Cost-efficient storage to handle large amounts of VM and user data
Centralized management of combined physical and virtual infrastructure from
a single user interface to simplify and automate deployment, maintenance,
and support tasks
IBM Flex System is an integrated platform that satisfies these requirements.
1.3 IBM Flex System
IBM Flex System is an integrated platform that delivers custom-tuned,
client-specific configurations for optimum flexibility. IBM Flex System combines
compute nodes, networking, storage, and management into a complete data
center building block that is built for heterogeneous data centers with flexibility
and open choice of architectures, hypervisors, and environments.
Figure 1-2 shows IBM Flex System.
Figure 1-2 IBM Flex System
IBM Flex System offers unique capabilities that make this platform an exceptional
choice for the deployment of the SmartCloud Desktop Infrastructure solution:
Compute nodes
Compute nodes provide sufficient processing capacity for the most
demanding SmartCloud Desktop Infrastructure deployments.
IBM Flex System x240 is a dual-socket Intel Xeon processor E5-2600 product
family-based compute node. It supports the most powerful 135 W Intel Xeon
processor E5-2690, up to 768 GB of memory, and up to 16 physical I/O
connections to provide scalable, high-density HVD deployments.
The x240 compute node also supports local solid-state drives (SSDs) to
address VDI IOPS performance questions, and it also supports graphics
processing unit (GPU) adapters through the Flex System PCIe Expansion
Node for a true high-performance graphics user experience.
IBM Flex System x222 Compute Node is a high-density dual-server offering
that has two independent dual-socket servers in one mechanical package.
Each server has two 10 GbE Virtual Fabric ports, and it supports up to 384
GB of memory. The
The x222 can be used as a dense VDI compute node for virtual desktops that
do not require large amounts of memory.
Networking
SmartCloud Desktop Infrastructure requires sufficient network bandwidth and
efficient traffic management to host as many VMs as possible to ensure that
all computing resources are not underutilized. IBM Flex System networking
with IBM Virtual Fabric capabilities, when integrated into a chassis, can help
to reduce communication latency and provide the required bandwidth with
10 Gb Ethernet LAN connectivity that has 40 Gb uplinks and 8 Gb or 16 Gb
FC SAN connectivity.
Virtual Fabric Adapters offer virtual network interface card (NIC) capability to
allow up to 32 logical ports on a single compute node, with controllable
bandwidth allocation to manage traffic prioritization. vNIC capability helps to
simplify deployment and bandwidth management for VDI hosts by providing
flexible network configuration capabilities.
Management
IBM Flex System Manager is a systems management appliance that drives
efficiency and cost savings in the data center. Flex System Manager provides
a pre-integrated and virtualized management environment across servers,
storage, and networking that is easily managed from a single interface. A
single focus point for seamless multichassis management provides an instant
and resource-oriented view of chassis and chassis resources for IBM
System x and IBM Power Systems compute nodes.
Flex System Manager allows centralized management of the ESXi
hypervisors used in the IBM XenDesktop architecture, and it also supports
configuration patterns to simplify deployment of VDI hosts.
Storage
As virtualized storage systems, integrated IBM Flex System V7000 Storage
Node or external IBM Storwize V7000 complement virtual desktop
environments. These systems offer robust enterprise-class storage
capabilities, which include thin provisioning, automated tiering, internal and
external virtualization, clustering, replication, multiprotocol support, and a
next-generation graphical user interface (GUI). These features can be applied
in virtual desktop environments to optimize storage capacity and performance
and to simplify desktop user profile management and backup. These systems
are flexible enough to support entry virtual desktop environments, but can
also be scaled to support enterprise virtual desktop environments.
In summary, IBM Flex System in a SmartCloud Desktop Infrastructure solution
can help to achieve the following advantages:
Better VM density due to support for top Intel Xeon processors and large
memory and I/O capacity
Better virtual desktop performance and better utilization of VDI server
resources with flexible local SSD support
Transparent support for high-performance remote graphics through PCIe
Expansion Node with GPU adapters installed
Lower communication latency due to integrated switching capabilities for a
better user experience
Simplified deployment and management of both physical and virtual
infrastructures due to integrated design and IBM Flex System Manager
capabilities
1.4 Citrix XenDesktop
IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop can help to
transform Microsoft Windows desktops, applications, and data into a cloud-type
service that is accessible on virtually any device, anywhere. Citrix offers tailored
solutions that range from the affordable, all-in-one Citrix VDI-in-a-Box for simple
IT organizations to the enterprise-wide Citrix XenDesktop. XenDesktop is a
comprehensive desktop virtualization solution for every user with multiple
delivery models that are optimized for flexibility and cost efficiency. Both solution
types deliver a rich, high-definition user experience across any network that uses
Citrix HDX technologies.
By using the open architecture of Citrix XenDesktop, clients can adopt desktop
virtualization quickly and easily with any hypervisor, storage, or management
infrastructure.
The following XenDesktop features and benefits provide a familiar experience for
the user:
Multiple monitor support
3D graphics business application support
Multimedia support
Printing from a virtual desktop
Accessing USB devices and other peripheral devices
Roaming user profiles
XenDesktop offers several levels of security features, including the following
features:
Multifactor authentication
Traffic encryption
Built-in password management
Secure Sockets Layer (SSL) tunneling to ensure that all connections are
encrypted
The following Citrix XenDesktop features provide centralized administration and
management:
Microsoft Active Directory
Web-based administrative console
Automated desktop provisioning and storage optimization
XenDesktop includes the following scalability, integration, and optimization
features:
VMware vSphere, Microsoft Hyper-V, and XenServer hypervisor support
Integration with VMware vCenter to achieve cost-effective densities, high
levels of availability, and advanced resource allocation control for virtual
desktops
Automated provisioning of desktop images that share virtual disks with a
master image
Citrix XenDesktop software components are shown in Figure 1-3.
Figure 1-3 Citrix XenDesktop software components
The Citrix XenDesktop core services have the following software components:
Citrix Receiver
Citrix Receiver is a client software for accessing virtual desktops by using the
Independent Channel Architecture (ICA) protocol. The client software can run
on different types of user access devices, including desktop PCs, notebooks,
thin clients, and others.
Citrix Virtual Desktop Agent
Citrix Virtual Desktop Agent is installed on virtual desktops and supports
Citrix Receiver direct connections through the ICA.
Citrix XenDesktop Controller
Citrix XenDesktop Controller is a software service that is responsible for
connection brokering, authenticating users, and starting virtual desktops and
user persona management if required. Authentication of users is performed
through Windows Active Directory.
IBM server
ESXi + HA
Non-persistent HVD server pool
IBM server
ESXi
OS Windows
VD agent
Management cluster
OS Windows
VD agent
OS Windows
VD agent
IBM server
ESXi
OS Windows
VD agent
OS Windows
VD agent
OS Windows
VD agent
Persistent HVD server cluster
IBM server
ESXi + HA
OS Windows
VD agent
OS Windows
VD agent
OS Windows
VD agent
IBM server
ESXi + HA
OS Windows
VD agent
OS Windows
VD agent
OS Windows
VD agent
vCenter
IBM server
ESXi + HA
Database
AD/DHCP
End user devices
IBM System Storage
Image repository VM files User profiles
License
Controller
PVS/MCS
vCenter
Database
AD/DHCP
License
Controller
PVS/MCS
Desktop PC
Receiver
Thin client
Receiver
Notebook
Receiver
Tablet PC
Receiver
RDP, ICA, HDX
NFS, CIFS, iSCSI, FC
Citrix Provisioning Services or Machine Creation Services
Citrix Provisioning Services and Machine Creation Services create and
provision virtual desktops from desktop images. Provisioning Services
support stateless HVD pools, and Machine Creation Services can support
both stateless and dedicated HVD pools.
Citrix License Server
Citrix License Server manages licenses for all XenDesktop components.
Citrix Data Store
Citrix Data Store is a database that stores configuration information for the
XenDesktop environment.
VMware ESXi
VMware ESXi is a hypervisor that is used to host VMs.
VMware vCenter
The VMware vCenter service acts as a central administrator for VMware ESX
and ESXi servers that are connected on a network. vCenter Server provides a
central point for configuring, provisioning, and managing VMs in the data
center.
1.5 Integration with other IBM software products
IBM SmartCloud Desktop Infrastructure enables easy integration with optional
security and endpoint management technologies, including the following
technologies:
IBM Security Access Manager for Enterprise Single Sign-On offers
streamlined user access with automated sign-on and sign-off plus a single
password for all applications. This technology can reduce help desk costs,
improve productivity, and strengthen security for virtualized desktops.
IBM Tivoli Endpoint Manager combines endpoint and security management
into a single solution. With this solution, your team can see and manage
physical and virtual endpoints, such as servers, desktops, roaming
notebooks, and specialized equipment, such as point-of-sale devices,
automated teller machines (ATMs), and self-service kiosks.
Chapter 2. IBM Flex System
components for the virtual
desktop infrastructure
This chapter introduces IBM Flex System building blocks and IBM System x
servers to consider during the design of the virtual desktop infrastructure (VDI). It
provides guidelines about how to use them to optimize the solution.
This chapter covers the following topics:
2.1, Introduction to IBM Flex System on page 14
2.2, Planning for Flex System components on page 15
2.3, IBM Flex System compute nodes on page 16
2.4, Storage considerations on page 23
2.5, Network considerations on page 29
2.6, Management considerations on page 40
2
2.1 Introduction to IBM Flex System
The IBM PureFlex System is a fully integrated system with unified management
of compute, storage, networking, and virtualization resources. These resources
use built-in patterns of expertise based on decades of IBM experience and
thousands of client deployments.
The IBM Flex System Enterprise Chassis is the foundation of the offering,
supporting intelligent workload deployment and management for maximum
business agility. The 14-node, 10U chassis delivers high-performance
connectivity for your integrated compute, storage, networking, and management
resources. The chassis is designed to support multiple generations of
technology, and offers independently scalable resource pools for higher
utilization and lower cost per workload. IBM Flex System is illustrated in
Figure 2-1.
Figure 2-1 IBM Flex System
Chapter 2. IBM Flex System components for the virtual desktop infrastructure 15
2.2 Planning for Flex System components
To design your Flex System infrastructure, you need to determine the resources
that are needed by your infrastructure servers, your persistent and non-persistent
desktops.
Each category of user operates a specific software platform with a given
workload, which involves different hardware resources. Consumption
assessment on resource utilization must be performed for each category of user
for the following resources:
CPU
Memory
I/O characteristics: size, percentage of reads and writes, and type of access:
random or sequential
Size of user data and user profile
Graphic utilization profile
Then, for each category of user or workload profile, you can translate the
assessed requirements into compute node resources. CPU, memory, and
graphic requirements have to be considered for compute node design.
Requirements for I/O and storage for data determine the network and storage
design.
Use the following considerations to size your compute nodes:
Do not overcommit memory because disk swapping will deteriorate the
performance.
Do not overcommit processors as a best practice. If too many virtual
machines (VMs) are used, the response time deteriorates quickly.
Plan for failover. If one or more compute nodes fail, the user VMs hosted on
the failed compute nodes need to be reallocated over the remaining compute
nodes. As a best practice, allow for overhead of 20% in both memory and
processor to support these additional VMs without reaching the compute
node boundaries.
The hypervisor uses 3 GB - 6 GB of compute node memory and 1 CPU core.
To define the storage solution, consider the subject in multiple parts:
Storage for the infrastructure servers. A shared storage is the best solution.
Storage for the persistent VMs. Privilege is also a shared storage.
Storage for the non-persistent VMs. Consider using local storage or shared
storage with high I/O performance.
Storage connectivity. Consider a separate Fibre Channel SAN to achieve
potentially better performance, availability, scalability, and security with
moderate to heavy storage workloads. Consider converged FCoE/iSCSI or
unified NAS storage to achieve potentially better total cost of ownership
(TCO) with light-to-medium storage workloads.
To achieve higher availability, consider redundancy for the I/O modules: Ethernet
network switches and storage SAN switches.
2.3 IBM Flex System compute nodes
The choice for computer nodes is wide because it is designed for multiple
generations of technology. The following available IBM Flex System compute
nodes offer high performance for virtualization:
Flex System x222
Flex System x240
Flex System x440
The choice of compute nodes depends on the computing requirements for the
VMs hosted.
Flex System x222 is designed for virtualization, dense cloud deployments, and
hosted clients. It is a good choice for the clients looking to virtualize their
general-purpose user applications while maximizing the density of their
computing resources.
Flex System x240 is a good choice for VDI workloads that require more memory
and I/O bandwidth.
For resource demanding VMs, Flex System x440 brings massive compute power
and memory resources. A high VM density on a compute node can be reached.
The impact for the users in a compute node failure is proportional.
Table 2-1 on page 17 compares key features of the compute nodes.
Table 2-1 x222, x240, and x440 compute node feature comparison
The following sections describe these compute nodes:
2.3.1, IBM Flex System x222 Compute Node on page 17
For specific graphic-intensive virtual desktops that run 3D or CAD applications,
IBM System x3650 M4 completes the PureFlex infrastructure by offering the
advantage of powerful graphics processing units (GPUs). See 2.3.5, IBM
System x3650 M4 on page 22.
2.3.1 IBM Flex System x222 Compute Node
The IBM Flex System x222 Compute Node is a high-density dual-server that is
designed for virtualization, dense cloud deployments, and hosted clients. The
x222 has two independent servers in one mechanical package, which means
that the x222 has a double-density design that allows up to 28 servers to be
housed in a single 10U Flex System Enterprise Chassis.
The x222 is the ideal platform for clients looking to virtualize their workloads
while maximizing the density of their computing resources.
An IBM Flex System x222 Compute Node is illustrated in Figure 2-2 on page 18.
Feature x222 (one half) x240 x440
Processor E5-2400 E5-2600 E5-4600
Number of sockets 2 2 4
Memory (max) 384 GB 768 GB 1.5 TB
Local storage (max) 1 TB 3.2 TB 3.2 TB
I/O ports (max) 4 8 16
Figure 2-2 IBM Flex System x222 Compute Node
This half-wide high-density server offers the following key features for VDI:
Processor: The Intel Xeon Processor E5-2400 with up to 8-core processors
and up to 2.4 GHz core speeds depending on the CPUs number of cores, up
to 20 MB of L3 cache, and QPI interconnect links of up to 8 Gigaticks per
second (GTps). Up to four processors in a standard (half-width) Flex System
form factor, 32 cores, and 64 threads maximize the concurrent execution of
multi-threaded applications.
Memory: Up to 24 DIMM sockets in a standard (half-width) Flex System form
factor. Each server provides up to 12 DIMM sockets DDR3 ECC memory.
RDIMMs provide speeds up to 1600 MHz and a memory capacity of up to 384
GB. Load-reduced DIMMs (LRDIMMs) are supported with a maximum
capacity of 768 GB.
Network: Up to eight virtual I/O ports per each server (up to 16 per one node)
with integrated 10 Gb Ethernet ports (see LAN-on-motherboard (LOM) on
page 37), offering the choice of Ethernet, Fibre Channel, iSCSI, or FCoE
connectivity.
Disk: Each server, one 6.35-cm (2.5-inch) simple-swap SATA drive bay
supporting SATA drives and SSDs. Optional SSD mounting kit to convert a
6.35-cm (2.5-inch) simple-swap bay into two 4.5-cm (1.8-inch) hot-swap SSD
bays.
Operating system: Support of VMware ESXi 5.1 Embedded Hypervisor.
Note: The two servers are independent and cannot be combined to form a
single four-socket system.
The IBM Flex System x240 Compute Node is a high-performance Intel Xeon
processor-based server that offers outstanding performance for virtualization
with new levels of processor performance and memory capacity, and high
networking bandwidth.
An IBM Flex System x240 Compute Node is illustrated on Figure 2-3.
This half-wide server offers the following key features for VDI:
Processor: The Intel Xeon Processor E5-2600 with up to 8-core processors
and up to 3.3 GHz core speeds depending on the CPUs number of cores, up
to 20 MB of L3 cache, and QPI interconnect links of up to 8 GTps. Up to two
processors, 16 cores, and 32 threads maximize the concurrent execution of
multi-threaded applications.
Memory: Up to 24 DDR3 ECC memory RDIMMs provide speeds up to 1600
MHz and a memory capacity of up to 384 GB. Load-reduced DIMMs
(LRDIMMs) are supported with a maximum capacity of 768 GB.
Network: Up to 16 virtual I/O ports per compute node with integrated 10 Gb
Ethernet ports (see LAN-on-motherboard (LOM) on page 37), offering the
choice of Ethernet, Fibre Channel, iSCSI, or FCoE connectivity.
Disk: Two 6.35-cm (2.5-inch) hot-swap serial-attached SCSI (SAS)/SATA
drive bays supporting SAS, SATA, and SSD drives.
The x240 compute node can also be equipped with the Flex System PCIe
Expansion Node, which is used to attach additional PCI Express cards, such as
next-generation graphics processing units (GPU), to it. This capability is ideal for
many desktop applications that require hardware acceleration using a PCI
Express GPU card.
The IBM Flex System x440 Compute Node is a four-socket Intel Xeon
processor-based server optimized for high-end virtualization, mainstream
database deployments, and memory-intensive high performance environments.
Compared to the x240 compute node, it provides double the amount of memory
capacity and processor sockets, and also a high networking bandwidth. An IBM
Flex System x440 Compute Node is illustrated in Figure 2-4.
This full-wide server offers the following key features for VDI:
Processor: The Intel Xeon processor E5-4600 with 8-core processors and up
to 2.9 GHz core speeds, up to 20 MB of L3 cache, and up to two 8 GTps QPI
interconnect links. Up to four processors, 32 cores, and 64 threads maximize
the concurrent execution of multithreaded applications.
Memory: Up to 48 DDR3 ECC memory RDIMMs provide speeds up to 1600
MHz and a memory capacity of up to 768 GB. Load-reduced DIMMs
(LRDIMMs) are supported with a maximum capacity of 1.5 TB of memory.
Network: Up to 32 virtual I/O ports per compute node with integrated 10 Gb
Ethernet ports, offering the choice of Ethernet, Fibre Channel, iSCSI, or
FCoE connectivity. Optionally, you can have up to 64 virtual I/O ports by
installing four CN4054 10Gb Virtual Fabric Adapters.
Disk: Two 6.35-cm (2.5-inch) hot-swap SAS/SATA drive bays supporting SAS,
SATA, and SSD drives.
2.3.4 IBM Flex System PCIe Expansion Node
For VDI, you can use the IBM Flex System PCIe Expansion Node to attach
next-generation graphics processing units (GPU) to x240 compute nodes. The
PCIe Expansion Node supports up to four PCIe adapters and two other Flex
System I/O expansion adapters.
Figure 2-5 shows the PCIe Expansion Node that is attached to a compute node.
Figure 2-5 IBM Flex System PCIe Expansion Node attached to a compute node
The PCIe Expansion Node has the following features:
Support for up to four standard PCIe 2.0 adapters:
Two PCIe 2.0 x16 slots that support full-length, full-height adapters (1x, 2x,
4x, 8x, and 16x adapters supported)
Two PCIe 2.0 x8 slots that support low-profile adapters (1x, 2x, 4x, and 8x
adapters supported)
Support for PCIe 3.0 adapters by operating them in PCIe 2.0 mode
Support for one full-length, full-height double-wide adapter (using the space
of the two full-length, full-height adapter slots)
Support for PCIe cards with higher power requirements
The Expansion Node provides two auxiliary power connections, up to 75 W
each for a total of 150 W of more power by using standard 2x3, +12 V six-pin
power connectors. These connectors are placed on the base system board so
that they both can provide power to a single adapter (up to 225 W), or to two
adapters (up to 150 W each). Power cables are used to connect from these
connectors to the PCIe adapters and are included with the PCIe Expansion
Node.
Two Flex System I/O expansion connectors
These I/O connectors expand the I/O capability of the attached compute
node.
Table 2-2 lists the PCIe GPU adapters that can be used in the VDI solutions.
Table 2-2 Supported adapters
NVIDIA GRID K1 and K2 are designed for VDI. NVIDIA GRID cards can be
shared between multiple users, with up to 100 concurrent users in GPU sharing
the configuration for K1. K2 is intended to support heavy 3D applications, such
as two power users in a GPU pass-through configuration.
2.3.5 IBM System x3650 M4
The IBM System x3650 M4 server provides great performance on a flexible and
scalable design. Its energy-efficient design supports more cores, memory, and
data capacity in a scalable 2U package that is easy to service and manage.
It completes the IBM Flex System infrastructure by providing a solution to
support graphics-intensive virtual desktops that run 3D or CAD applications. An
IBM System x3650 M4 is illustrated in Figure 2-6.
Figure 2-6 IBM System x3650 M4
Part
number
Description Maximum
supported
47C2120 NVIDIA GRID K1 for IBM Flex System PCIe Expansion Node 1
a
a. If installed, only this adapter is supported in the system. No other PCIe adapters can be installed.
47C2121 NVIDIA GRID K2 for IBM Flex System PCIe Expansion Node 1
a
The following components are key for VDI:
Processor: Intel Xeon processor E5-2600 with 8-core processors and up to
2.9 GHz core speeds, up to 20 MB of L3 cache, and up to two 8 GTps QPI
interconnect links. Up to two processors, 16 cores, and 32 threads maximize
the concurrent execution of multi-threaded applications.
Memory: Supports up to 24 Load Reduced DIMMs (LRDIMMs) of 1333 MHz
DDR3 ECC memory that provide speed, high availability, and a memory
capacity of up to 768 GB (running at 1066 MHz).
Video: Support for up to two NVIDIA Quadro graphics processing units
(GPUs) to maximize computing power (NVIDIA Quadro 6000, 4000, and
2000).
Network: Four integrated Gigabit Ethernet 1000BASE-T ports (RJ-45); two
embedded 10 Gb Ethernet ports (10GBASE-T RJ-45 or 10GBASE-SR
SFP+-based) on an optional 10 Gb Ethernet mezzanine card.
Disk: Support for 4.5-cm (1.8-inch) solid-state drives (SSDs), 6.35-cm
(2.5-inch) SSDs and HDDs, and 8.8-cm (3.5-inch) HDDs.
2.3.6 VMware ESXi 5.1 Embedded Hypervisor
IBM offers versions of VMware vSphere Hypervisor (ESXi) customized for select
IBM hardware to provide online platform management, including updating and
configuring firmware, platform diagnostics, and enhanced hardware alerts.
This option delivered on a USB flash drive is compatible with IBM Flex System
compute nodes and IBM System x. At the time of writing this book, the last
version provided by IBM is VMware vSphere Hypervisor (ESXi) 5.1.
Choose this option on the compute nodes that make up the VDI infrastructure:
Reduce server deployment time. IBM Flex System Management integrates
the management of the VMware vSphere Hypervisor (ESXi).
Use a diskless compute node, reducing cost and security exposures.
Use compute node local disks to host nonpersistent virtual desktops.
2.4 Storage considerations
Some of the storage options to consider for the VDI storage design are
described.
2.4.1 IBM Flex System V7000
IBM Flex System V7000 is integrated into IBM PureFlex Systems. It is designed
to be a scalable internal storage system to support the compute nodes of the
IBM Flex System environment.
The IBM Flex System V7000 is an innovative mid-range storage solution that
combines simplicity and outstanding performance, with a compact and modular
design.
It integrates the IBM SAN Volume Controller technology from the high-end IBM
System Storage DS8000 family, providing the ability to virtualize internal
storage and external SAN-attached storage. The IBM Flex System V7000 is
illustrated in Figure 2-7.
One key feature is the IBM System Storage Easy Tier. The system
automatically and nondisruptively moves frequently accessed data from HDD
MDisks to SSD MDisks, therefore placing such data in a faster tier of storage.
Figure 2-7 IBM Flex System V7000 Storage Node
The following sections provide a quick overview of the hardware and software.
Hardware overview
The IBM Flex System V7000 consists of a set of drive enclosures. Control
enclosures contain disk drives and two node canisters. A collection of up to four
control enclosures that are managed as a single system is an IBM Flex System
V7000 clustered system.
Expansion enclosures contain drives and are attached to a control enclosure.
You can connect up to a maximum of nine expansion enclosures to a control
enclosure. The expansion enclosures can be either or both the IBM Flex System
V7000 expansion enclosure and the IBM Storwize V7000 expansion enclosures.
Up to two IBM Flex System V7000 expansion enclosures can be connected to a
control enclosure. These expansion enclosures must be in the same IBM Flex
System chassis as the control enclosure. Up to nine IBM Storwize V7000
expansion enclosures can be connected to the control enclosure. These IBM
Storwize V7000 expansion enclosures must be mounted in the rack next to the
IBM Flex System chassis where the control enclosure is installed.
Expansion canisters include the SAS interface hardware that enables the node
canisters to use the drives of the expansion enclosures. An expansion enclosure
cannot be connected to more than one control enclosure at the same time.
Software overview
The IBM Flex System V7000 Storage Node provides thin provisioning,
automated tiering for automated SSD optimization, internal and external
virtualization, clustering, replication, multiprotocol support, and a next-generation
graphical user interface (GUI).
Advantages of the IBM Flex System V7000 Storage Node include greater
integration of server and storage management to automate and streamline
provisioning.
The IBM Flex System V7000 software performs the following functions for the
compute nodes that attach to IBM Flex System V7000:
Creates a single pool of storage
Provides logical unit virtualization
Manages logical volumes
Manages physical resources, including drives
The IBM Flex System V7000 system also provides the following functions:
Large scalable cache
Copy Services:
IBM FlashCopy (point-in-time copy) function, including thin-provisioned
FlashCopy to make multiple targets affordable
Metro Mirror (synchronous copy)
Global Mirror (asynchronous copy)
Data migration
Volume mirroring
Space management:
IBM System Storage Easy Tier to migrate the most frequently used data to
higher performing storage
Metering of service quality when combined with IBM Tivoli Storage
Productivity Center
Thin-provisioned logical volumes
Compressed volumes to consolidate storage
2.4.2 IBM Flex System Storage Expansion Node
The IBM Flex System Storage Expansion Node (SEN) is a storage enclosure that
attaches to a single half-wide compute node to provide that compute node with
additional direct-attach local storage.
The SEN adds 12 hot-swap 6.35-cm (2.5-inch) drive bays and an LSI RAID
controller and connects to the compute node via its PCIe expansion connector.
You can see a SEN attached to a x240 compute node in Figure 2-8.
Figure 2-8 Storage Expansion Node attached to an x240 compute node
The x240 compute node with the Storage Expansion Node can be used as an
entry-level NAS-only or unified server storage in VDI deployments.
The following features were retained for VDI:
Support for 6 Gbps SAS and SATA drives, both HDDs and SSDs
Support for RAID 0, 1, 5, 10, and 50 as standard
Support for logical unit number (LUN) sizes up to 64 TB
Optional support for SSD performance acceleration and SSD caching with
Features on Demand upgrades
2.4.3 IBM FlashSystem 820 and IBM FlashSystem 720
IBM FlashSystem storage systems deliver advanced performance, scalability,
reliability, security, and energy-efficiency features. FlashSystem 720 and
FlashSystem 820 storage systems are the appropriate choice for mission-critical
enterprise environments with the following characteristics: high storage
performance requirements, such as low latency (microseconds as opposed to
milliseconds), high bandwidth (gigabytes per second), or high IOPS (hundreds of
thousands of I/O operations per second).
IBM FlashSystem storage systems deliver over 500,000 read IOPS and up to
5 GBps bandwidth with less than 100 microseconds latency. They provide up to
24 TB of total usable capacity or up to 20 TB of 2D Flash RAID protected data
storage just in 1U of rack space. The IOPS specifications are shown in Table 2-3.
The FlashSystem 820, based on enterprise multi-level cell (eMLC) flash, is
targeted to read-heavy workloads, where workload is distributed across multiple
servers.
Based on single level cell (SLC) flash, the FlashSystem 720 is targeted to
write-heavy enterprise workloads.
Table 2-3 IOPS specification
It completes the IBM Flex System infrastructure by providing the best
performance solution for standard shared primary data storage devices, even
compared to those that incorporate SSDs or flash technology.
These storage options can be integrated with IBM Flex System V7000, to be
used as the top tier of storage with traditional arrays, provided by the IBM Easy
Tier functionality.
Figure 2-9 on page 28 shows the IBM FlashSystem 720 and FlashSystem 820.
FlashSystem 720 FlashSystem 820
Write IOPS 400,000 280,000
Read IOPS 525,000 525,000
Figure 2-9 IBM FlashSystem 720 and FlashSystem 820
2.4.4 Solid-state drives (SSDs) compared to hard disk drives (HDDs)
HDD is a proven technology with excellent reliability and performance, given the
physical limitations of its spinning platters and moving arms.
IBM solid-state drives (SSDs) use non-volatile flash memory rather than spinning
magnetic media to store data. The main advantage for VDI is the lower access
times and latency rates that are 10 times faster than the spinning disks in an
HDD.
All of the IBM Flex System compute nodes and the IBM Flex System V7000
support SSD disks within the internal drive bay.
Consider SSD disks for these reasons:
Provide the best performance for the non-persistent VDI hosts by installing
two SSDs, which are configured as RAID 0
Implement the Easy Tier function on the IBM Flex System V7000 to increase
its IOPS performance on the most frequently accessed data
2.4.5 RAID considerations
The RAID configuration affects only the performance for write operations. Read
operations are not affected.
The write penalty is the consequence of the RAID data protection technique,
which requires multiple disk IOPS requests for each user write IOPS.
RAID penalty is used to determine the functional IOPS of an array. The following
formulas are used:
Raw IOPS = Disk Speed IOPS x Number of disks
Functional IOPS = (Raw IOPS x Write % / RAID Penalty) + (RAW IOPS x
Read %)
Table 2-4 provides the write penalty for RAID configuration.
Table 2-4 RAID penalty
In scalable implementations, hosted virtual desktops can generate substantial
IOPS workload on the storage part of the VDI infrastructure. Therefore, select the
appropriate RAID level to match the workload:
For a read-intensive workload, use RAID 0, RAID 1, RAID 5, and RAID 10
levels that spread read operations across multiple disks simultaneously. If the
volume of data is important, you can also use a RAID level that optimizes disk
usability.
For a write-intensive workload, use a RAID level that offers a low write
penalty, such as RAID 0 and RAID 10.
To store the PVS write cache, redundant RAID configuration is not needed
due to the non-persistence of the environment.
2.5 Network considerations
This section introduces IBM Flex System I/O building blocks:
2.5.1, Ethernet connectivity on page 31
2.5.2, Fibre Channel connectivity on page 38
RAID Write penalty
0 1
1 2
5 4
6 6
10 2
The compute nodes are connected to I/O nodes through the I/O expansion
adapters. Half-wide servers have two I/O expansion adapters, and full-wide
nodes have four. Figure 2-10 shows the location of the adapter on an IBM Flex
System x240 compute node.
Figure 2-10 Location of the I/O adapter slots in the IBM Flex System x240 Compute
Node
Each I/O expansion adapter is connected to a switch bay by four links.
Figure 2-11 shows the connections between the adapters in the compute nodes
to the switch bays in the chassis.
Figure 2-11 Logical layout of the interconnects between I/O adapters and I/O modules
2.5.1 Ethernet connectivity
The following components are described:
EN4093/EN4093R 10Gb Scalable Switches
CN4093 Converged 10Gb Scalable Switch on page 33
SI4093 System Interconnect Module on page 35
EN4091 10Gb Ethernet Pass-thru Module on page 36
LAN-on-motherboard (LOM) on page 37
A1
A2
Node
bay 1
A1
A2
Node
bay 2
A1
A2
Node
bays
13/14
A3
A4
Switch
bay 1
Switch
bay 3
Switch
bay 2
Switch
bay 4
EN4093/EN4093R 10Gb Scalable Switches
The IBM Flex System Fabric EN4093 and EN4093R 10Gb Scalable Switches
provide unmatched scalability and performance, while also delivering innovations
to help address a number of networking concerns today and providing
capabilities that will help you prepare for the future. These switches are capable
of supporting up to sixty-four 10 Gb Ethernet connections while offering Layer 2/3
switching. They are designed to install within the I/O module bays of the IBM Flex
System Enterprise Chassis. These switches can help clients migrate to a 10 Gb
or 40 Gb Ethernet infrastructure. These switches offer virtualization features,
such as Virtual Fabric and IBM VMready, plus the ability to work with IBM
Distributed Virtual Switch 5000V. IBM Flex System Fabric EN4093 is shown in
Figure 2-12.
Figure 2-12 IBM Flex System Fabric EN4093
The EN4093 and EN4093R switches are initially licensed for fourteen enabled 10
Gb internal ports and ten enabled 10 Gb external uplink ports. More ports can be
enabled when needed with additional licenses, including 14 additional internal
ports and two 40 Gb external uplink ports with Upgrade 1, and 14 additional
internal ports and four additional SFP+ 10 Gb external ports.
The switches offer the following key features and benefits for VDI:
Integrated network management: EN4093 and EN4093R 10Gb Scalable
Switches are tightly integrated and managed through the IBM Flex System
Manager.
Optimized network virtualization with virtual NICs: IBM Virtual Fabric
provides a way for companies to carve up 10 Gb ports into virtual NICs.
Increased performance: The EN4093 and EN4093R are the embedded 10
GbE switches for a server chassis to support sub-microsecond latency and up
to 1.28 Tbps, while also delivering full-line rate performance, making them
ideal for managing dynamic workloads across the network. Furthermore,
these switches provide a rich Layer 2 and Layer 3 feature set that is ideal for
many of todays data centers, and they offer industry-leading uplink bandwidth
by being the first integrated switches to support 40 Gb uplinks.
VM-aware networking: IBM System Networkings Distributed Virtual Switch
5000V (sold separately) enables network administrators to simplify
management by having a consistent virtual and physical networking
environment. 5000V virtual and physical switches use the same
configurations, policies, and management tools. Network policies migrate
automatically along with VMs to ensure that security, performance, and
access remain intact as VMs move from server to server.
CN4093 Converged 10Gb Scalable Switch
The IBM Flex System Fabric CN4093 10Gb Converged Scalable Switch provides
unmatched scalability, performance, convergence, and network virtualization.
The switch offers full Layer 2/3 switching, as well as FCoE Full Fabric and Fibre
Channel NPV Gateway operations to deliver a truly converged integrated
solution, and it is designed to install within the I/O module bays of the IBM Flex
System Enterprise Chassis. The switch can help clients migrate to a 10 Gb or
40 Gb converged Ethernet infrastructure and offers virtualization features, such
as Virtual Fabric and VMready, plus the ability to work with IBM Distributed
Virtual Switch 5000V.
IBM Flex System Fabric EN4093 is shown in Figure 2-13 on page 34.
Note: Internal layer 2 switches provide a more effective approach for
communication between co-resident servers, by using a east/west
approach. Communication between nodes uses an internal, active Layer 2
switch to pass traffic to one other. By containing network traffic within the
Flex System chassis, latency is improved by 50% compared to a
north/south approach. In the north/south approach, all the traffic is routed
to the top-of-rack (TOR) switch, and the flow goes up to the TOR switch
and down to the co-located server.
Figure 2-13 IBM Flex System CN4093 Converged Switch
The CN4093 has flexible port licensing. The base switch configuration includes
fourteen 10 GbE connections to the node bays, two 10 GbE SFP+ ports, and six
Omni Ports with SFP+ connectors. The client then has the flexibility of turning on
more 10 GbE connections to the internal node bays, and more Omni Ports and
40 GbE QSFP+ uplink ports (or 4x 10 GbE SFP+ DAC uplinks on each QSFP+
port) when needed. The client turns them on by using IBM Features on Demand
licensing capabilities that provide pay as you grow scalability without the need
for additional hardware.
The switches offer the following key features and benefits for VDI:
Integrated network management: The CN4093R 10Gb Scalable Switch is
tightly integrated and managed through the IBM Flex System Manager.
provides a way for companies to divide up 10 Gb ports into virtual NICs. For
large-scale virtualization, the IBM Flex System solution can support up to 32
vNICs by using a pair of CN4054 10Gb Virtual Fabric Adapters in each
compute node.
Increased performance: The CN4093 is the embedded 10 Gb switch for a
server chassis to support aggregated throughput of 1.28 Tbps, while also
delivering full line rate performance on Ethernet ports, making it ideal for
managing dynamic workloads across the network. Furthermore, it offers
industry-leading uplink bandwidth by being the integrated switch to support
40 Gb uplinks.
VM-aware networking: IBM Flex System CN4093 simplifies management
and automates VM mobility by making the network VM aware with IBM
VMready, which works with all the major hypervisors. Network policies
migrate automatically along with VMs to ensure that security, performance,
and access remain intact as VMs move from server to server.
SI4093 System Interconnect Module
The IBM Flex System Fabric SI4093 System Interconnect Module enables
simplified integration of IBM Flex System into your existing networking
infrastructure.
The SI4093 System Interconnect Module requires no management for most data
center environments, eliminating the need to configure each networking device
or individual port, therefore reducing the number of management points. It
provides a low latency, loop-free interface that does not rely upon spanning tree
protocols, therefore removing one of the greatest deployment and management
complexities of a traditional switch.
The SI4093 System Interconnect Module offers administrators a simplified
deployment experience while maintaining the performance of intra-chassis
connectivity.
The SI4093 System Interconnect Module is shown in Figure 2-14.
Figure 2-14 IBM Flex System Fabric SI4093 System Interconnect Module
The SI4093 System Interconnect Module is initially licensed for fourteen enabled
10 Gb internal ports and ten enabled 10 Gb external uplink ports. More ports can
be enabled, including 14 additional internal ports and two 40 Gb external uplink
ports using the IBM Features on Demand licensing mode.
The switch offers the following key features and benefits for VDI:
Transparent (or VLAN-agnostic) mode: The interconnect module provides
traffic consolidation in the chassis to minimize TOR port utilization, and it also
enables server-to-server communication for optimum performance (for
example, vMotion).
provides a way for companies to divide up 10 Gb ports into virtual NICs. For
large-scale virtualization, the IBM Flex System solution can support up to 32
vNICs by using a pair of CN4054 10Gb Virtual Fabric Adapters in each
compute node.
VM-aware networking: IBM Flex System SI4093 simplifies management and
automates VM mobility by making the network VM aware with IBM VMready,
which works with all the major hypervisors. Network policies migrate
automatically along with VMs to ensure that security, performance, and
access remain intact as VMs move from server to server.
Increased performance: The SI4093 is the embedded 10 Gb interconnect
Module for a server chassis to support aggregated throughput of 1.28 Tbps,
while also delivering full line rate performance on Ethernet ports, making it
ideal for managing dynamic workloads across the network. Furthermore, it
offers industry-leading uplink bandwidth by being the integrated switch to
support 40 Gb uplinks.
EN4091 10Gb Ethernet Pass-thru Module
The IBM Flex System EN4091 10Gb Ethernet Pass-thru Module offers easy
connectivity of the IBM Flex System Enterprise Chassis to any external network
infrastructure. This unmanaged device enables direct Ethernet connectivity of the
compute node in the chassis to an external TOR data center switch. This module
can function at both 1 Gb and 10 Gb Ethernet speeds. It has fourteen internal
1 Gb or 10 Gb links, and fourteen external 1 Gb or 10 Gb SFP+ uplinks.
IBM Flex System EN4091 10Gb Ethernet Pass-thru Module is shown in
Figure 2-15.
Figure 2-15 IBM Flex System EN4091 10Gb Ethernet Pass-thru Module
The IBM Flex System EN4091 offers the following key features:
It offers intelligent workload deployment and management for maximum
business agility.
The module delivers high-speed performance complete with integrated
servers, storage, and networking.
The flexible design meets the needs of varying workloads with independently
scalable IT resource pools for higher utilization and lower cost per workload.
LAN-on-motherboard (LOM)
The x222 and certain models of the x240 and x440 compute nodes have an
Ethernet LAN-on-motherboard (LOM) controller integrated on the system board.
The LOM is installed on the I/O expansion adapter 1 (A1) of the compute node.
The I/O expansion adapter A1 routes to two switch bays for redundancy and
performance. The first port is linked to the I/O module 1 within the chassis. The
second port is connected to I/O module 2.
LOM offers two operational mode choices:
One-port physical NIC mode (pNIC), multichannel disabled, which is the
default. The adapter operates as a standard dual-port 10 Gbps Ethernet
adapter, and it functions with any 10 GbE switch.
Virtual NIC mode (vNIC), multichannel enabled. vNIC mode enables up to
four virtual NIC interfaces per 10 Gb physical port (eight total for the LOM).
Also, two options are available for vNIC linking: IBM Virtual Fabric Mode and
Switch Independent Mode. Both modes offer the same capabilities in terms
of the number of vNICs and the bandwidth for which each can be configured.
The difference is in the direction of bandwidth control and switch support.
IBM Virtual Fabric Mode works with IBM Flex System EN4093 and EN4093R
or CN4093 switches, and it allows bidirectional vNIC bandwidth metering and
control for both server-to-switch and switch-to-server traffic. It uses Q-in-Q
VLAN tagging to separate traffic flows from different vNICs, providing full
transparency for the existing client VLANs.
Switch Independent Mode works with any switch, and the vNIC bandwidth
metering and control are performed only on the adapter side, forming
unidirectional virtual channel (server-to-switch). This mode extends the
existing clients VLANs to the virtual NIC interfaces.
Note: With LOM enabled, the Ethernet I/O module can only be installed on
bays 1 and 2 on the chassis, because integrated NIC ports are routed to these
bays with a specialized periscope connector.
The IEEE 802.1Q VLAN tag is essential to the separation of the vNIC groups
by the NIC adapter or driver and the switch. The VLAN tags are added to the
packet by the applications or drivers at each end station rather than by the
switch.
Consider configuring the LOM to the vNIC mode with Virtual Fabric Mode
(EN4093 or EN4093R switches) or Switch Independent Mode (SI4093
Interconnect Module or 10 Gb Ethernet Pass-thru module connected to the
external top-of-rack switch) to allocate 10 GbE network bandwidth differently to
the VLANs used within the VDI infrastructure.
If you choose to implement an FCoE converged network for both storage and
network connectivity, an optional Advanced Upgrade can be activated on LOM to
enable FCoE processing.
2.5.2 Fibre Channel connectivity
The following Fibre Channel components are described:
FC5022 16Gb SAN Scalable Switch
FC3171 8Gb SAN Switch and Pass-thru on page 39
Fibre Channel adapters on page 39
FC5022 16Gb SAN Scalable Switch
The IBM Flex System FC5022 16Gb SAN Scalable Switch is a high-density,
48-port 16 Gbps Fibre Channel switch that is used in the IBM Flex System
chassis. The switch provides 28 internal ports to compute nodes by way of the
midplane, and 20 external SFP+ ports. These SAN switch modules deliver an
embedded option for IBM Flex System users deploying storage area networks in
their enterprise. They offer end-to-end 16 Gb and 8 Gb connectivity. The N-Port
Virtualization mode streamlines the infrastructure by reducing the number of
domains to manage while enabling the ability to add or move servers without
impact to the SAN. Monitoring is simplified via an integrated management
appliance, or clients using end-to-end IBM B-type SAN can leverage the IBM
management tools.
Figure 2-16 IBM Flex System FC5022 16Gb Scalable Switch
FC3171 8Gb SAN Switch and Pass-thru
The IBM Flex System FC3171 8Gb SAN Switch is a full-fabric Fibre Channel
component with expanded functionality. The SAN switch supports high-speed
traffic processing for IBM Flex System configurations, and offers scalability in
external SAN size and complexity, and enhanced systems management
capabilities. The IBM Flex System FC3171 8Gb Pass-thru supports a fully
interoperable solution for seamless integration of the Fibre Channel initiators to
an existing fabric. The pass-thru module uses industry-standard N_Port ID
virtualization (NPIV) technology to provide a cost-effective connectivity solution
for the IBM Flex System chassis. FC3171 is shown in Figure 2-17.
Figure 2-17 IBM Flex System FC3171 8Gb SAN Switch
Fibre Channel adapters
If you decided to implement Fibre Channel connectivity for your VDI storage, the
following adapters are available:
IBM Flex System FC3172 2-port 8Gb FC Adapter
IBM Flex System FC5024D 4-port 16Gb FC Adapter
IBM Flex System FC5052 2-port and FC5054 4-port 16Gb FC Adapters
Note: On the compute node where LOM is activated, the Fibre Channel
adapter is installed on the I/O expansion adapter 2 (A2) of the compute node.
IBM Flex System FC5022 can only be installed on switch bays 3 and 4.
Note: On the compute node where LOM is activated, the Fibre Channel
adapter is installed on the I/O expansion adapter 2 (A2) of the compute node.
The SAN switch can only be installed on switch bays 3 and 4.
For more information, refer to the following IBM Flex System Product Guides for
the I/O adapters:
http://www.redbooks.ibm.com/Redbooks.nsf/portals/puresystems?Open&page=
pg&cat=adapters&count=999
2.6 Management considerations
This section introduces management components and features:
2.6.1, Introduction to IBM Flex System Manager on page 40
2.6.2, Management Network on page 42
2.6.3, Chassis Management Module on page 43
2.6.4, Integrated Management Module II on page 44
2.6.5, Working with configuration patterns on page 45
2.6.1 Introduction to IBM Flex System Manager
IBM Flex System Manager (FSM) is a systems management appliance that
drives efficiency and cost savings in the data center. IBM Flex System Manager
provides a pre-integrated and virtualized management environment across
servers, storage, and networking that is easily managed from a single interface.
A single focus point for seamless multichassis management provides an instant
and resource-oriented view of the chassis and chassis resources for both IBM
System x and IBM Power Systems compute nodes. Flex System Manager helps
you realize these advantages:
Reduce the number of interfaces, steps, and clicks that it takes to manage IT
resources
Manage and deploy workloads that are based on resource availability and
predefined policies intelligently
Manage events and alerts to increase system availability and reduce
downtime
Reduce operational costs
The IBM Flex System Manager management appliance is shown in Figure 2-18
on page 41.
Figure 2-18 IBM Flex System Manager management appliance
IBM Flex System Manager is designed to help you get the most out of your IBM
PureFlex System while automating repetitive tasks. IBM Flex System Manager
can reduce the number of manual navigational steps for typical management
tasks. IBM Flex System Manager provides core management functions along
with automation so you can focus your efforts on business innovation. These
functions include simplified system setup procedures with wizards and built-in
expertise to consolidated monitoring for all of your physical and virtual resources
(compute, storage, and networking).
IBM Flex System Manager has the following key features:
Optimizing your workload management through built-in expertise
Managing all of your resources with one solution: compute, storage,
networking, and virtualization
The IBM Flex System Manager base feature set offers the following functions:
Support for up to 16 managed chassis
Support for up to 5,000 managed elements
Auto-discovery of managed elements
Overall health status
Monitoring and availability
Hardware management
Security management
Administration
Network management (Network Control)
Storage management (Storage Control)
VM lifecycle management (VMControl Express)
I/O address management (IBM Fabric Manager)
The IBM Flex System Manager Advanced feature set upgrade offers the following
advanced features:
Image management (VMControl Standard)
Pool management (VMControl Enterprise)
The Manager Node of the IBM Flex System Manager has the following fixed
hardware specifications:
One Intel Xeon processor E5-2650 8C 2.0 GHz 20 MB Cache 1600 MHz
95 W 32 GB of memory with eight 4 GB (1x4 GB, 1Rx4, 1.35 V) PC3L-10600
CL9 ECC DDR3 1333 MHz LP RDIMMs
Integrated LSI SAS2004 RAID controller
Two IBM 200 GB SATA 1.8 MLC SSDs configured in a RAID 1
One IBM 1 TB 7.2 K 6 Gbps NL SATA 2.5 SFF HS HDD
Dual-port 10 Gb Ethernet Emulex BladeEngine 3 (BE3) network controller for
data network connections
Dual-port Broadcom 5718-based network adapter with integrated Broadcom
5389 8-port basic L2 switch for internal chassis management network
connections
Integrated Management Module II (IMM2)
2.6.2 Management Network
The management network is a private and secure Gigabit Ethernet network. It is
used to complete management-related functions throughout the chassis,
including management tasks that are related to the compute nodes, switches,
and the chassis itself.
The management network is shown in Figure 2-19 on page 43 as the blue line. It
connects the Chassis Management Module (CMM) to the compute nodes, the
switches in the I/O bays, and the Flex System Manager (FSM). The FSM
connection to the management network is through a special Broadcom
5718-based management network adapter (Eth0). The management networks in
multiple chassis can be connected through the external ports of the CMMs in
each chassis by using a GbE top-of-rack switch.
The yellow line in Figure 2-19 on page 43 shows the production data network.
The Flex System Manager also connects to the production network (Eth1) so that
it can access the Internet for product updates and other related information.
Figure 2-19 Separate management and production networks
One of the key functions that the data network supports is discovery of operating
systems on the various network endpoints. Discovery of operating systems by
the Flex System Manager is required to support software updates on an
endpoint, such as a compute node. The Flex System Manager Checking and
Updating Compute Nodes wizard assists you in discovering operating systems
as part of the initial setup.
2.6.3 Chassis Management Module
The CMM provides single-chassis management, and it is used to communicate
with the management controller in each compute node. It provides system
monitoring, event recording, and alerts; and manages the chassis, its devices,
and the compute nodes.
The chassis supports up to two CMMs. If one CMM fails, the second CMM can
detect its inactivity, activate itself, and take control of the system without any
disruption. The CMM is central to the management of the chassis, and is
required in the Enterprise Chassis.
Enterprise chassis
Management network
CMM CMM CMM
Top-of-Rack switch
Flex system
manager
Eth0 Eth1
System x
compute node
Power
systems
compute node
CMM
P
o
r
t
Management network
CMM CMM CMM
Top-of-Rack switch
Flex system
manager
Eth0 Eth1
System x
compute node
Power
systems
compute node
CMM
L2 Switch
IMM FSP
Management
workstation
CMMs in
other
enterprise
chassis
Eth0 = GbE
management
network adapter
with integrated
L2 switch
Eth1 =
embedded 2-port
10 GbE controller
with Virtual
Fabric Connector
P
o
r
t
IMM
I/O bay 1 I/O bay 2 I/O bay 1 I/O bay 2
Data network
Through an embedded firmware stack, the CMM implements functions to
monitor, control, and provide external user interfaces to manage all chassis
resources. The CMM allows you to perform these functions:
Define login IDs and passwords
Configure security settings, such as data encryption and user account
security
Select recipients for alert notification of specific events
Monitor the status of the compute nodes and other components
Find chassis component information
Discover other chassis in the network and enable access to them
Control the chassis, compute nodes, and other components
Access the I/O modules to configure them
Change the startup sequence in a compute node
Set the date and time
Use a remote console for the compute nodes
Enable multichassis monitoring
Set power policies and view power consumption history for chassis
components
2.6.4 Integrated Management Module II
The Integrated Management Module II (IMM2) is the next generation of the
integrated service processors for the IBM x86-based server family. The IMM2
enhancements include a more responsive user interface, faster power-on
capability, and increased remote presence performance. The IMM2 incorporates
a new web user interface that provides a common interface across all IBM
System x software products.
The IMM2 provides the following major features as standard:
Intelligent Peripheral Management Interface (IPMI) V2.0 compliance
Remote configuration of IMM2 and Unified Extensible Firmware Interface
(UEFI) settings without the need to power on the server
Remote access to system fan, voltage, and temperature values
Remote IMM and UEFI update
UEFI update when the server is powered off
Remote console by way of a serial over LAN
Remote access to the system event log
Predictive failure analysis and integrated alerting features (for example, by
using Simple Network Management Protocol (SNMP))
Remote presence, including remote control of server by using a Java or
Active x client
Operating system failure window (blue screen) capture and display through
the web interface
Virtual media that allow the attachment of a diskette drive, CD/DVD drive,
USB flash drive, or disk image to a server
Syslog alerting mechanism that provides an alternative to email and SNMP
traps
Support for Features On Demand (FoD) enablement of server functions,
option card features, and System x solutions and applications
2.6.5 Working with configuration patterns
Using configuration patterns, you can quickly provision or pre-provision multiple
systems from a single pattern, and subsequent pattern changes will
automatically be applied to all associated systems.
Server Configuration Patterns give us the ability to configure the storage, I/O
adapter, boot order, and other Integrated Management Module (IMM) and Unified
Extensible Firmware interface (UEFI) settings.
Configuration patterns also integrate support for IBM Fabric Manager so that you
can virtualize server fabric connections, and failover or repurpose servers
without disruption to the fabric. Also, you can initiate fabric change requests
through your change management process before your hardware arrives by
preconfiguring host interconnect addresses.
Chassis Configuration Patterns allow you to configure the CMM network
management interface, users and security, power and acoustic settings, and
basic I/O module and node IP address assignments.
Consider using this powerful method to configure your IBM Flex System
infrastructure easily and quickly.
Chapter 3. VMware vSphere design
considerations
VMware vSphere management infrastructure and ESXi hypervisor are the core
virtualization components used in the XenDesktop on the IBM Flex System
solution. One of the key features of ESXi hypervisor is its ability to be embedded
into a server, providing bare metal virtualization capabilities without a need to
perform additional installation and configuration tasks.
The technical and commercial features of VMware vSphere have steadily
evolved from version to version. Throughout this progression, two main
components have continued to define the fundamental virtualization platform: the
ESXi hypervisor and the vCenter management layer.
In addition to these two significant components, it is important to note that a
complete virtualization platform includes two additional components: storage and
networking.
This chapter provides an overview of VMware vSphere 5.1 and design guidelines
adapted for IBM Flex System hardware and Citrix XenDeskop.
This chapter includes the following topics:
3.1, ESXi and vSphere features on page 48
3.2, Networking considerations on page 56
3.3, Storage considerations on page 58
3
3.1 ESXi and vSphere features
This section describes the main features of VMware vSphere 5.1, including the
ESXi Hypervisor, the VMware vCenter server, vMotion, the Distributed Resource
Scheduler (DRS), and vSphere High Availability.
The VMware vCenter server is the core management component for virtual
desktop infrastructure (VDI). It is widely used to manage the full VM lifecycle and
to monitor the virtual environment. It also provides advanced functionality for
virtual machines (VMs), such as high availability, live migration, and workload
allocation.
In a VDI environment, advanced functions are used to provide required levels of
availability for the server management components, as well as for persistent
virtual desktops. For non-persistent desktops, these advanced functions are not
required since the availability and workload management functions are
performed by the XenDesktop Controller.
3.1.1 Hypervisor ESXi
In the vSphere infrastructure, the hypervisor is ESXi. ESXi provides a
virtualization layer and creates an abstraction layer for processor, memory,
storage, and networking resources of the hosted client.
Evolved from ESX, ESXi has a small disk footprint - just 144 MB in Version 5.
This allows it to reside on internal flash memory, such as a USB key plugged into
the motherboard of IBM PureFlex System compute nodes. The IBM Customized
version provides additional drivers and Common Information Model (CIM)
modules specific to IBM hardware.
Starting with vSphere Version 5.0, VMware offers only ESXi as the hypervisor.
In the VDI environment, ESXi supports management clusters and VDI compute
clusters, as explained in Chapter 4, Citrix XenDesktop design basics on
page 61.
Consider these design suggestions:
Consult the VMware HCL when selecting the server model.
Use the latest stable version of ESXi that is compatible with all other products
used in the solution.
Select hosts with a higher CPU core count per CPU socket to minimize
VMware licensing costs.
Chapter 3. VMware vSphere design considerations 49
Use fewer, larger hosts in big environments and more, smaller hosts in
smaller environments. For Flex System, the IBM server models commonly
used in the desktop virtualization are x222, x240, and x440 compute nodes
(see 2.3, IBM Flex System compute nodes on page 16).
Typically, memory overcommitment is not used, or it is used only for
non-critical environments. If the ESXi host does not run into memory
contention issues, ballooning or memory compression and swapping do not
occur.
ESXi hosts must have fully redundant hardware components, including
redundant network cards, redundant host bus adapters (HBAs) for SAN
access, and redundant power supplies. Flex compute nodes x240 match
perfectly with these requirements.
3.1.2 VMware vCenter Server
VMware vCenter Server is a mandatory component to provide a centralized and
extensible platform for managing virtual infrastructure. Many advanced features
such as High Availability (HA), Distributed Resource Scheduler (DRS), vMotion,
and dvSwitches are available only through vCenter Server.
VMware vCenter Server is also a critical component in a XenDesktop
environment due to its central role of managing all communication between
XenDesktop and vSphere. Each VMware cluster relies on vCenter to perform
cluster management and other hosting infrastructure tasks. The delivery of
desktops might be affected if vCenter becomes slow or unresponsive under high
stress conditions, such as in a large XenDesktop environment with many
morning logons or rapid shift changes.
The VMware recommendation is to use vCenter as a VM, which allows for
protection of vCenter with high availability. Achieving high availability for the
VMware vCenter Server is also recommended by Citrix for XenDesktop
deployments.
Starting with Version 5.1, the vCenter architecture has changed by decoupling
components, such as inventory services, or by introducing new components such
as single sign-on, which can be installed on separate servers. This allows more
flexibility in sizing and designing.
In addition to the classic vSphere client, VMware introduced a new Web client.
All operations are possible now via the Web client and certain operations can be
performed only via the Web client.
An important consideration is the communication between vCenter Server and
XenDesktop Desktop Delivery Controller (DDC): a third-party or self-signed
certificate must be installed on the vCenter server and the DDCs in the
environment. Although a self-signed certificate can be used in non-production
environments, Citrix suggests the use of a certificate provided by a third-party
certificate authority (CA) or an internal enterprise CA for production use.
3.1.3 vMotion
Live migration or vMotion technology allows you to move running VMs from one
physical server to another with zero downtime. This enables companies to
perform hardware maintenance without disrupting business operations.
vMotion relies on three mechanisms:
Encapsulation of the VM state in files stored on shared storage
Transfer of the active memory of a VM over a network
Virtualized network being used by the VM to ensure that the network identity
and network connections are preserved
vMotion preserves the execution state, network identity, and active network
connections with no disruption to users.
Storage vMotion enables moving VM disks from one physical storage location to
another without an outage in the guest operating system and applications.
Storage vMotion is used by system administrators to relocate VMs when
changes need to be implemented in the physical infrastructure, or when the VM
needs to grow its storage and there is not enough available space in the current
physical container.
Before vSphere 5.1, vMotion required shared storage between hosts. Storage
vMotion required a host to have access to the source and destination data
stores.
vSphere 5.1 removes this requirement and allows combining vMotion and
storage vMotion into one process. This combined migration copies both the VM
memory and its disk over the network to the destination host. After all memory
and disk data are sent, the destination VM will resume and the source VM will be
powered off (see Figure 3-1 on page 51).
In the VDI environment, vMotion is used to provide live migration capabilities for
management server VMs and persistent virtual desktops.
The following designs and preferred practices are suggested:
VMs will use virtual hardware Version 9.
Separate the vMotion network from management and VM networks.
If possible, leave some CPU resources for vMotion operations. To ensure the
ability to use full network bandwidth, ESXi reserves CPU resources on both
the source and destination hosts.
Figure 3-1 vMotion
3.1.4 Distributed Resource Scheduler (DRS)
vSphere DRS works with vMotion (see Figure 3-2 on page 52) to provide
automated resource optimization and VM placement. DRS uses vMotion to
balance the workload across all hosts in a cluster based on CPU and memory
activity.
It enhances the consolidation ratio by deciding how the resources can be
optimized in terms of workload placement. It enables performance management
and capacity planning savings, as well as incident management savings. It is
also used to automate workload distribution when physical hosts are placed in
maintenance mode during changes.
With DRS enabled, you can create resource pools spanning all hosts in the
cluster and apply cluster-level resource allocation policies.
VMware ESXi VMware ESXi
VM VM VM VM VM VM VM VM vMotion
Storage vMotion
In addition, DRS can perform these functions:
Initial placement
Each time a VM is powered on, DRS places it on an appropriate host or
generates a recommendation depending on the automation level.
Load balancing
DRS distributes VM workloads across the vSphere hosts inside the cluster.
DRS continuously monitors the workload and the available resources and
performs or suggests VM migrations to maximize workload performance.
Power management
Distributed Power Management (DPM) can place vSphere hosts in standby
mode or power them back on as capacity needs. DPM can also be set to
issue recommendations for power on/off operations.
Constraint correction
DRS redistributes VMs across vSphere hosts as needed to adhere to
user-defined affinity and anti-affinity rules following host failures or hosts
being placed in maintenance.
Figure 3-2 Distributed Resource Scheduler (DRS)
VMware ESX VMware ESX VMware ESXi
VM VM VM VM VM VM VM VM VM
Resource Pool
Physical Servers
VMotion
Enable DRS on the entire cluster in fully automated mode, unless there are
specific constraints.
If needed, you can change the default DRS settings on specific VMs.
Configure affinity/anti-affinity rules and DRS groups only when necessary (if
certain VMs must run on certain hosts, run the VMs on separate hosts or the
same host). A use case for these rules is vCenter, which needs to run on 1 - 2
hosts to locate it faster for troubleshooting purposes.
3.1.5 High Availability (HA)
vSphere High Availability (HA) provides an automated process for restarting VMs
when a physical host becomes unavailable (see Figure 3-3). VMs are
automatically registered and restarted on the remaining hosts in the cluster.
HA helps to meet service level agreements (SLAs) and to manage the risk of
having aggressive consolidation ratios on physical hosts by reducing the
potential for long outages. When hardware failures occur, HA helps to reduce
labor by providing recovery automation.
Figure 3-3 High Availability (HA)
When vSphere HA is enabled for a cluster, all active hosts choose the clusters
master host. Only one master host exists per cluster and all other hosts are slave
hosts. A new election is held if the master host fails, is shut down, or is removed
from the cluster.
VMware ESXi VMware ESXi VMware ESXi
Resource Pool
Failed Server
VM VM VM VM VM VM
Operating Server Operating Server
The master host in a cluster has a number of responsibilities:
Monitoring the state of slave hosts. If a slave host fails or becomes
unreachable, the master host identifies which VMs need to be restarted.
If VM monitoring is enabled, the master host monitors the power state of all
protected VMs. If one VM fails, the master host ensures that it is restarted.
Managing the lists of cluster hosts and protected VMs.
Acting as the vCenter Server management interface to the cluster and
reporting the cluster health state.
The slave hosts primarily run VMs, monitoring their runtime states, and reporting
state updates to the master host. A master host can also run and monitor VMs.
Both slave hosts and master hosts implement the VM and Application Monitoring
features.
In the VDI environment, VMware HA provides high availability for management
services VMs and persistent virtual desktops, if required.
HA will be enabled on all clusters with strict admission control, with one
exception, the cluster for non-persistent desktops, which will have HA
disabled.
Clusters that have 12 or fewer hosts needs to allow for the loss of at least one
physical host. Clusters with more than 12 hosts need to allow for the loss of at
least two physical hosts.
Configure the Percentage of Cluster Resources Reserved policy and reserve
failover capacity for at least one host. Use the Host Failures Cluster Tolerates
policy if VM reservations are not used and you do not need granular control of
reserved failover capacity. Use the percentage policy if you have a cluster of
only two hosts. There might be a requirement for desktop groups to offer
varying levels of redundancy. For example, a desktop group might require
N+100% redundancy while another one might only require N+10%.
HA works even if vCenter is down; however, vCenter is needed to initially
configure HA.
3.1.6 vSphere licensing considerations
vSphere 5.1 is licensed on a per-processor basis. Each physical processor
(CPU) in a server needs to have at least one vSphere 5.1 processor license key
assigned to be able to run vSphere. vRAM entitlement introduced in vSphere 5.0
was ended with vSphere 5.1.
vCenter Server is licensed per instance. One instance is required in a vSphere
deployment to enable the centralized management and deployment of core
vSphere features, such as vMotion, Distributed Resource Scheduler, and others.
vSphere is available in three editions that provide basic features in the Standard
edition to the full range of features in the Enterprise Plus edition.
Table 3-1 outlines several vSphere features and the required vSphere edition.
Table 3-1 vSphere features and editions
3.1.7 IBM Flex System integration with VMware
The IBM Flex System Manager accelerates the provisioning of compute node,
networking, and storage resources to the VMware ESX software layer and
supporting Citrix XenDesktop components. These capabilities decrease
deployment time significantly.
Feature vSphere edition
Thin provisioning Standard
vMotion Standard
High Availability Standard
Hot-Add RAM and CPU Enterprise
Fault Tolerance Enterprise
DRS Enterprise
Storage multipathing Enterprise
Storage vMotion Enterprise
Host profiles Enterprise Plus
Storage DRS Enterprise Plus
Storage I/O Control Enterprise Plus
Network I/O Control Enterprise Plus
Distributed Switches Enterprise Plus
VMware integration offers these features:
Deploying hardware patterns from the Flex System Manager to new compute
nodes, ensuring that standard hardware adapter interfaces are logically
assigned to the compute resources, as suitable for a new vCloud Suite
compute node.
Installing IBM customized ESXi 5.1 images to the new compute nodes from
inside the Flex System Manager interface.
Providing VMware environment visibility and ESX resource inventory and
topology views from within the Flex System Manager interface, including the
ability to deploy new VM images.
Providing extensibility from the native vCenter server to the IBM Flex System
hardware, using the specialized IBM Systems Director Upward Integration
Module (UIM). Capabilities of the UIM include monitoring power and thermals
of the IBM Flex System components, viewing and updating firmware and
software levels for various components in the chassis, and modifying settings
for predictive failure alerts in the chassis.
3.2 Networking considerations
Networking can be seen as physical network infrastructure and VMware vSphere
virtual network infrastructure.
From a physical network perspective, the hosts networking resources are shared
by the virtual desktops that it supports. If there is no sufficient bandwidth, users
experience a degraded level of performance. It is suggested to use fast network
cards and IBM Flex System compute nodes to address this issue by using 10 Gb
network cards.
Also, performance might be improved by separating different types of network
traffic. For example, management, VM, storage, provisioning, and backup traffic
can all be isolated from each other. For details about network design, see 4.5,
Network configuration on page 76.
The VMware virtual network consists of various subcomponents, such as virtual
switches (standard and distributed), ports, port groups, virtual Ethernet adapters,
and uplink ports. These components build the communication channel between
the VMs and the external or physical network.
3.2.1 Virtual switch
Virtual switches (vSwitches) are a software-based switch that resides in the
VMkernel and provides traffic management for VMs. There are two types of
virtual switches in vSphere: standard switch (VSS) and distributed switch (VDS).
While standard virtual switches are defined at the host level, distributed virtual
switches are defined at the data center level, which means that virtual switch
configuration is then pushed consistently to all hosts within the same data center.
A vSphere Distributed Switch is abbreviated as VDS and is also called a
dvSwitch.
In addition, distributed virtual switches enable advanced features, such as Rx
traffic shaping, improved monitoring through port mirroring (dvMirror), consistent
network statistic monitoring or Link Layer Discovery Protocol (LLDP), which is a
vendor-neutral standard equivalent of Cisco Discovery Protocol (CDP).
The VDS requires an Enterprise license. Use distributed switches to enable the
benefits.
Note that when using dvSwitches, they can usually be controlled only from your
vCenter server (unless you use a third-party distributed vSwitch, such as a Cisco
1000V or an IBM System Networking 5000V). If your vCenter Server becomes
unavailable, networking continues to function, but you cannot make any
modifications until the vCenter Server is back online.
3.2.2 Ports and port groups
A port or port group is a logical object on a vSwitch that provides specialized
services for the VMkernel or VMs. A virtual switch can contain a VMkernel port or
a VM port group. On a vSphere Distributed Switch, these are called dvPort
groups.
A VMkernel port is a specialized virtual switch port type that is configured with
an IP address to allow vMotion, iSCSI storage access, network-attached storage
(NAS) or Network File System (NFS) access, or vSphere Fault Tolerance (FT)
logging. Because vSphere 5.x only includes ESXi hosts, a VMkernel port also
provides management connectivity for managing the host. A VMkernel port is
also referred to as a vmknic.
A VM port group is a group of virtual switch ports that share a common
configuration and allow VMs to access other VMs or the physical network.
3.2.3 Uplink ports
Uplink ports are ports associated with physical adapters, providing a connection
between a virtual network and a physical network.
Distributed Virtual Uplinks (dvUplinks) are a new concept introduced with VDS.
dvUplinks provide a level of abstraction for the physical NICs (vmnics) on each
host. NIC teaming, load balancing, and failover policies on the VDS and DV Port
Groups are applied to the dvUplinks and not the vmnics on individual hosts. Each
vmnic on each host is mapped to a dvUplink, permitting teaming and failover
consistency regardless of vmnic assignments.
Ensure redundancy by using a single dvSwitch with more uplinks on all of the
hosts in the cluster.
Create separate, highly available port groups for each management and
vMotion traffic. The IBM PureFlex System platform positions Ethernet switch
hardware inside the chassis, providing inherent network performance
improvement for activities that use network bandwidth (such as VMware
vMotion) from traditional top-of-rack (TOR) network switching.
Improve the network performance by using the TCP offload engine (TOE)
capabilities of integrated network adapters on the Flex System compute
nodes, by enabling stateless offload of the following tunables:
Checksum offload
TCP segmentation offload (TSO)
Jumbo frames (JF)
Large receive offload (LRO)
3.3 Storage considerations
Storage has a major impact on the performance, scalability, and availability of the
XenDesktop implementation.
3.3.1 Local or shared storage
Virtual deployments typically use shared storage in preference to local storage.
Shared storage is required to support vMotion, DRS, and High Availability.
Although these features are less critical when hosting non-persistent virtual
desktops, they are important for management server workloads and persistent
desktops.
3.3.2 Tiered storage
A one-size-fits-all storage solution is unlikely to meet the requirements of most
virtual desktop implementations. The use of tiered storage, where storage
technologies, such as solid-state drives (SSDs) and network-attached and Fibre
Channel-attached storage systems, as well as drive access technologies, such
as SAS and SATA, are grouped into storage tiers, provides an effective
mechanism for offering a range of storage options differentiated by performance,
scalability, redundancy, and cost. In this way, different virtual workloads with
similar storage requirements can be grouped together and a similar cost model
applied.
3.3.3 Redundancy and load balancing
vSphere Datastores must be designed to meet the redundancy requirements of
the components that they support, such as RAID levels, storage adapters, and
the back-end storage configuration. The preferred practice for shared storage is
to configure two NICs or HBAs in a bonded or multipath setup.
VMware vSphere uses a default storage multipath policy of Fixed (VMware),
which means that the same storage path is always used to access that specific
logical unit number (LUN). If you have a configuration where you have multiple
access paths to your storage LUNs, this is not the optimal multipath policy
because it does not take advantage of your redundant hardware.
Selecting Round Robin (VMware) is usually a good choice. It means that at any
time, the LUN is accessed over a single path, but that path will change the next
time that it is accessed.
Chapter 4. Citrix XenDesktop design
basics
This chapter describes the details of the Citrix XenDesktop design process
based on IBM SmartCloud Desktop Infrastructure Reference Architecture (RA)
for Citrix XenDesktop. The IBM RA for XenDesktop, an IBM validated reference
design, uses a VMware ESXi back-end infrastructure based on VMware ESXi
that is managed by VMware vCenter Server.
The IBM RA is updated on a regular basis to include new features and
components. The most recent IBM RA for Citrix XenDesktop is at this website:
http://ibm.co/150EytE
This chapter includes the following topics:
4.1, Citrix XenDesktop components on page 62
4.2, Desktop and application delivery on page 66
4.3, Citrix XenDesktop provisioning on page 67
4.4, Storage configuration on page 74
4.5, Network configuration on page 76
4.6, Operational model and sizing guidelines on page 78
4
4.1 Citrix XenDesktop components
Figure 4-1 shows the components of a Citrix XenDesktop architecture that
supports several models for desktop delivery: Hosted Virtual Desktop (HVD),
streamed HVD, and hosted and streamed applications.
Figure 4-1 Citrix XenDesktop components
The IBM Reference Architecture for XenDesktop includes these main
components:
Compute cluster:
It hosts the virtual desktop workloads.
It consists of multiple IBM compute nodes.
Quantities of compute nodes per cluster vary with building block type (see
4.6, Operational model and sizing guidelines on page 78).
It must not be used to host workloads other than virtual desktops.
Management cluster:
It hosts the VMware and Citrix XenDesktop management components.
Storage connectivity
Users
Production network
Shared storage
User data
VM
repository
ESXi 5.1
Local SSDs
Non-persistent HVD pool
SSD
PVS write caches
ESXi 5.1
Persistent HVD pool
VDI management cluster (ESXi 5.1)
XenDesktop
Web interface
Citrix license
MCS
AD vCenter
DB
PVS
User profiles Data store
Difference
and Identity
disks
XenApp
Chapter 4. Citrix XenDesktop design basics 63
It can be hosted on an existing or new vSphere environment (or on other
systems).
This cluster contains VMware vCenter, XenDesktop, Machine Creation
Services (MCS), Provisioning Services (PVS), License Server, Web
Interface, database server, and other optional components.
It can host additional infrastructure services (Active Directory (AD),
Domain Name System (DNS), Dynamic Host Configuration Protocol
(DHCP), and so on) if they do not already exist in the environment.
The components are described:
Web Interface
The Web Interface provides the user interface to the XenDesktop
environment. Web Interface brokers user authentication, enumerates the
available desktops and, upon launch, delivers an .ica file to the Citrix
Receiver on the users local device to initiate a connection. Because the Web
Interface is a critical component, redundant servers must be available to
provide fault tolerance.
Domain Controller
The Domain Controller hosts Active Directory (AD), Dynamic Host
Configuration Protocol (DHCP), and DNS services. Active Directory provides
a common namespace and secure method of communication between all the
servers and desktops in the environment. The Domain Name System (DNS)
server provides IP host name resolution for the core XenDesktop
infrastructure components. DHCP is used by the virtual desktops to request
and obtain IP addresses. DHCP uses Option 66 and 67 to specify the
bootstrap file location and file name to a virtual desktop. The DHCP service
receives requests on UDP port 67 and sends data to UDP port 68 on a virtual
desktop. Citrix Provisioning Services then streams the operating system over
the network to the virtual desktops.
Desktop delivery controller
The desktop delivery controllers (DDCs) are responsible for maintaining the
proper level of idle desktops to allow for instantaneous connections,
monitoring the state of online and connected desktops, and shutting down
desktops, as needed.
A XenDesktop farm is a larger grouping of virtual machine (VM) servers. The
primary DDC is configured as the XenDesktop farm master server. The
master focuses on farm management while an additional DDC acts as a
dedicated XML server. The XML server is responsible for brokering user
authentication, resource enumeration, and desktop launching. Because a
failure in the XML service results in users being unable to start their desktops,
it is suggested that you configure multiple controllers per farm.
PVS or MCS
Provisioning Services (PVS) can be used to provision non-persistent VMs.
Machine Creation Services (MCS) can be used to provision both persistent
and non-persistent VMs (see 4.3, Citrix XenDesktop provisioning on
page 67 for details).
vCenter Server
vCenter Server is the managing server for VMware ESXi hypervisor. Using a
single console, it provides centralized management of the VMs.
Redundancy for vCenter Server is achieved through VMware HA. The
vCenter Server also contains a licensing server for VMware ESXi.
vCenter SQL Server
vCenter requires a SQL database. The vCenter SQL server can be Microsoft
Data Engine (MSDE), Oracle, or SQL Server. Because the vCenter SQL
Server is a critical component, redundant servers must be available to provide
fault tolerance. Existing client SQL databases (including respective
redundancy) can be used.
License Server
The Citrix License Server is responsible for managing the licenses for all
XenDesktop components. XenDesktop has a 30-day grace period that allows
the system to function normally for 30 days if the license server becomes
unavailable. This grace period offsets the complexity of otherwise building
redundancy into the license server.
XenDesktop SQL Server
Each Citrix XenDesktop farm requires a SQL Server database called the data
store that is used to centralize farm configuration information and transaction
logs. The data store maintains all static information about the XenDesktop
environment. Because the XenDesktop SQL server is a critical component,
redundant servers must be available to provide fault tolerance.
Virtual Desktop Agent
Each VM needs a Citrix Virtual Desktop Agent (VDA) to capture VM data and
send it to the Receiver in the client device. The VDA also emulates the
keyboard and gestures sent from the Receiver. Note that the VDA is different
for HDX 3D Pro because it has to capture data from a graphics processing
unit (GPU) rendering a 3D scene. Independent Channel Architecture (ICA) is
the Citrix display protocol for both 2D and 3D virtual desktop infrastructure
(VDI).
Client devices
XenDesktop supports a broad set of devices, including PCs, Mac OS devices,
tablets, smartphones, and thin clients, along with all major device operating
platforms, including Apple iOS, Google Android, and Google Chrome OS.
XenDesktop enables a rich, native experience on each device, including
support for gestures and multi-touch features, customizing the experience
based on the type of device. Each client device has a Citrix Receiver, which
acts as the agent to communicate with the virtual desktop using the ICA/HDX
protocol.
Hypervisor
XenDesktop has an open architecture that supports the use of XenServer,
Microsoft Hyper-V, and VMware ESX or vSphere hypervisors. VMware
vSphere 5.1 is the hypervisor that is used in the IBM Reference Architecture
(RA) for Citrix XenDesktop.
Citrix XenApp
Citrix XenApp allows most Windows applications to be instantly delivered as a
service to users anywhere on any device. It can be used to deliver both
virtualized applications and virtualized desktops. In the Hosted VDI model,
XenApp is typically used for on-demand access to streamed and hosted
applications.
Shared storage
Shared storage is used to store user profiles and user data files. Depending
on the provisioning model used, different data is stored for VM images.
Shared storage also holds the redirected vSwap files.
4.2 Desktop and application delivery
Citrix XenDesktop offers FlexCast delivery technology that provides flexible
desktop and application delivery ranging from hosted shared desktops and
applications to hosted virtual desktops using published, installed, or streamed
deployment models.
The choice of specific delivery model or a combination of the delivery models
depends on user and application compatibility and customization requirements,
as shown in Table 4-1.
Table 4-1 Application and desktop delivery model comparison
Note: The terms Low, Medium, and High used in Table 4-1 on page 66 are
relative indicators for comparison purposes and do not represent any meaning
in terms of absolute values. For example, values in the Relative user density
row mean that non-persistent desktops have better user density than
persistent desktops, and hosted applications have better user density than
non-persistent desktops.
Feature or requirement Hosted virtual desktops Hosted applications
Persistent Non-persistent Published Streamed
Application compatibility with desktop OS Yes Yes
Application compatibility with server OS Yes Yes
User customization Yes Yes
Application customization Yes
Standard application installer Yes Yes Yes Yes
Custom application installer Yes Yes Yes
Multi-user aware application Yes Yes Yes Yes
Single-user application Yes Yes
Provisioning model MCS MCS or PVS XenApp XenApp
Management Complex Simplified Simplified Simplified
Relative storage IOPS High Low Low Low
Relative user density Low Medium High High
Relative cost High Medium Low Low
In general, if the application can work in a multi-user environment, requires no
user customization, and is compatible with the server operating system, the most
cost-efficient way to deploy VDI is to use hosted applications with a published or
streamed delivery model.
For highly customized user application environments, hosted virtual desktops
provide an efficient way to deploy a centralized desktop infrastructure, with a
non-persistent model that is cost optimized and a persistent model that is
application customization optimized.
4.3 Citrix XenDesktop provisioning
Citrix XenDesktop supports two primary provisioning models:
Machine Creation Services (MCS)
Provisioning Services (PVS)
MCS is a part of the XenDesktop Studio management console, but is limited to
hosted virtual desktops only, pooled or dedicated. Organizations looking to use a
streamed VHD model need to use PVS. However, PVS requires a separate
server and potentially multiple servers within the infrastructure. Both PVS and
MCS support ESXi hypervisors.
An additional consideration is the requirement for dedicated private desktops.
Private desktops allow users to completely control their virtual desktops. With
private desktops, the initial delivery of the desktop is identical. After it is
deployed, each desktop becomes unique as changes persist across reboots.
Within the hosted VDI desktop FlexCast model, this level of personalization can
be achieved with installed images, MCS images, and PVS images.
Using built-in technology to provide each desktop with a unique identity, MCS
thin-provisions each desktop from a master image. Only changes made to the
desktop consume additional disk space. PVS also uses built-in technology to
provide each desktop with a unique identity, but it uses a complete copy of the
base desktop image in read/write mode. Each copy consumes disk space that
expands as the user adds additional items to the desktop image.
When dedicated desktops are required, most organizations use MCS images.
Most organizations use PVS for pooled desktop configurations because PVS
requires fewer IOPS and offers faster patching and image updates. A single
XenDesktop environment can host any mix of PVS and MCS desktops that an
organization needs to meet its design goals.
For more information about choosing the appropriate image delivery option, see
XenDesktop Planning Guide: Desktop Image Delivery:
http://support.citrix.com/article/CTX128643
We describe PVS in 4.3.1, Provisioning Services (PVS) solution on page 68
and MCS in 4.3.2, Machine Creation Services on page 71.
4.3.1 Provisioning Services (PVS) solution
Hosted VDI desktops can be deployed with or without Citrix PVS. The advantage
of using PVS is that you can stream a single desktop image to create multiple
virtual desktops on one or more servers in a data center. Figure 4-2 outlines the
sequence of operations executed by XenDesktop to deliver a Hosted VDI virtual
desktop to the user.
Figure 4-2 PVS provisioning steps
When using PVS, the administrator performs the following steps:
1. Prepare a master target device to be imaged by installing an operating
system and software.
2. Create a virtual disk (vDisk) image from the hard disk drive of the master
target device and save it to the PVS server.
3. The PVS server streams vDisk contents to the target device on demand. In
real time, use software-streaming technology.
Tip: When managing a VDI farm, pooled VDI desktops provide better total
cost of ownership (TCO) and reduced administrative overhead. While most
organizations typically require a few dedicated desktops, it is better to limit
their use when possible.
Virtual desktop
Write
cache
5 GB
vDisk
20 GB
Provisioning service server
Request for vDisk
Streaming vDisk
After the vDisk image is available from the network, the VM on a target device no
longer needs its local hard disk drive to operate; it boots directly from the network
and behaves as if it is running from a local drive on the target device. This is why
PVS is suggested for stateless virtual desktops. PVS is not generally used for
dedicated virtual desktops because the write cache is not stored on shared
storage.
PVS is also used with Microsoft Roaming Profiles (MSRPs) so that the users
profile information can be separated out and reused. Profile data is available
from shared storage.
PVS streaming configuration details are discussed in 8.3.1, Configuring
streamed desktops on page 338.
Write cache options
PVS supports several write cache destination options. The write cache
destination for a vDisk is selected on the General tab on the vDisk File Properties
dialog.
The following write cache destinations are valid:
Cache on Device Hard Drive
The write cache can exist as a file in New Technology File System (NTFS)
format located on the target devices hard disk drive. This write cache option
frees up the PVS server because it does not have to process write requests
and does not have the finite limitation of RAM.
Cache in Device RAM
In this case, the write cache exists as a temporary file in the target devices
RAM. This provides the fastest method of disk access because memory
access is always faster than hard disk access.
Cache on a Server
The write cache can exist as a temporary file on a PVS server, which can
increase disk I/O and network traffic.
For additional security, the PVS server can be configured to encrypt write
cache files. Because the write cache file exists on the hard disk drive between
reboots, the data is encrypted in the event that a hard disk drive is stolen.
Note: The write cache file is temporary unless the vDisk mode is set to
Difference Disk Image mode.
Cache on Server Persistent
This cache option allows for the saving of changes between reboots. Using
this option, after rebooting, a target device is able to retrieve changes made
from previous sessions that differ from the read-only vDisk image. If a vDisk is
set to Cache on Server Persistent, each target device that accesses the vDisk
automatically has a device-specific, writable disk file created. Any changes
made to the vDisk image are written to that file, which is not automatically
deleted upon shutdown.
The drawback of using this cache option is that the cache file is available only
while the file remains valid. Any changes made to the vDisk force the cache
file to be marked invalid. For example, if the vDisk is set to Private Image
Mode, all associated cache files are marked invalid.
Write cache sizing
The size of the cache file for each VM depends on several factors, including the
types of applications, user workloads, and reboot frequency. A general estimate
is 300 MB - 500 MB for the cache size of a provisioned workstation. If a
workstation is not rebooted very often, or will use applications that are virtualized
using Microsoft App-V or similar programs, cache size can grow much larger.
Because application workloads can vary for each environment, perform a
detailed analysis to determine expected cache file sizes for your environment.
For more information about write cache sizing, see the PVS Write Cache Sizing
& Considerations article:
http://blogs.citrix.com/2011/10/06/pvs-write-cache-sizing-considerations/
Communication Ports
The following User Datagram Protocol (UDP) ports are typically defined:
PVS server to target device communication
Each PVS server must be configured to use the same UDP ports to
communicate with target devices (using the StreamProcess). The port range
is configured using the Consoles Network tab on the Server Properties
dialog. Default ports are UDP ports 6910 - 6390.
Login server communication
Each PVS server used as a login server must be configured on the Stream
Servers Boot List dialog when the administrator runs the configuration wizard.
The default port for login servers is UDP 6910.
For the best practices for PVS sizing and configuration, see the Provisioning
Services 5.x and 6.x Best Practices article:
http://support.citrix.com/article/ctx127549
4.3.2 Machine Creation Services
Unlike PVS, MCS does not require additional servers. Instead, it uses integrated
functionality built into VMware vSphere and communicates through the
respective APIs. Each desktop has one difference disk and one identity disk
(Figure 4-3 on page 72).
The difference disk is used to capture any changes made to the master image.
The identity disk is used to store information, such as machine name and
password.
There are three types of image assignment models for MCS:
Pooled-Random
Desktops are assigned randomly. When they log off, the desktop is free for
another user. When rebooted, any changes made are destroyed.
Pooled-Static
Desktops are permanently assigned to a single user. When a user logs off,
only that user can use the desktop, regardless of whether the desktop is
rebooted. During reboots, any changes that are made are destroyed.
Dedicated
Desktops are permanently assigned to a single user. When a user logs off,
only that user can use the desktop, regardless of whether the desktop is
rebooted. During reboots, any changes that are made persist across
subsequent restarts.
Figure 4-3 shows MCS provisioning.
Figure 4-3 MCS provisioning
For more information about MCS, see the blog article at this website:
http://bit.ly/1acsLuK
4.3.3 Personal vDisk
The personal vDisk feature in XenDesktop provides single image management
for the administrator. At the same time, it provides users with complete
personalization.
Personal vDisk technology enables the single-image management of pooled and
streamed desktops while enabling users to install applications and change
desktop settings as they do in a dedicated user-to-image model. In a traditional
VDI deployment with pooled desktops, users lose customizations and personal
applications when an administrator alters the base virtual machine (VM). In
contrast, XenDesktop deployments using personal vDisks can retain those
changes not only across reboots but even base image updates.
Master virtual desktop
Storage repository 2
Base disk
(read only)
Pooled desktop 2
Difference
Identity
Pooled desktop 4
Difference
Identity
Storage repository 1
Base disk
(read only)
Pooled desktop 1
Difference
Identity
Pooled desktop 3
Difference
Identity
Master image Snapshot
This means administrators can easily and centrally manage base VMs while
providing users with a customized and personalized desktop experience.
Personal vDisks provide this separation by redirecting all changes made on the
users VM to a separate disk (the personal vDisk) attached to the users VM. The
content of the personal vDisk is blended at run time with the content from the
base VM to provide a unified experience. In this way, users can still access
applications provisioned by their administrator in the base VM.
This users specific Virtual Hard Disk file (a .vhd or .vmdk file) contains all the
users customizations, such as applications installed in C:\Program Files.
Physically, a personal vDisk does not need to be stored on the same storage with
the base VM but can reside on other data stores.
Personal vDisk provides the best option: single image management with
complete user personalization and customization. For details and help about
whether personal vDisks are the correct approach for your environment, see the
following documents:
Citrix Personal vDisk Technology Planning Guide
Personal vDisk FAQs
4.3.4 Image assignment models
We describe two primary user-to-image assignment models:
Non-persistent (preferred)
Persistent (if needed)
Citrix has various image delivery options that allow you to achieve either of the
two assignment models using PVS and MCS. In reality, they can be combined
with various profile management options and also the Personal vDisk feature.
The Personal vDisk feature allows you to simulate a persistent user experience
(for example, installing personal applications) even when using non-persistent
images, providing a simulated or hybrid model.
In our book, we describe two image assignment scenarios:
Non-persistent: Streamed PVS image with Microsoft Roaming Profiles
(MSRP)
Persistent: Pooled image delivered through Machine Creation Services with
MSRP
4.4 Storage configuration
The architecture assumes that all VMware datastores are hosted on a supported
shared storage that uses one of the storage protocols: FC, Fibre Channel over
Ethernet (FCoE), Internet Small Computer System Interface (iSCSI), or Network
File System (NFS).
The following sections describe the required storage-related components and
configurations for each model.
Non-persistent model (PVS)
The following local storage components make up the PVS model:
Hypervisor
Each compute node is running the IBM ESXi custom image uploaded from an
internal USB key.
Local storage for each compute node
Two local SSD drives are configured in a RAID-0 configuration to store the
PVS Write Cache (delta files).
Due to the stateless nature of the architecture, there is little added value in
configuring reliable SSD drives in more redundant RAID configurations.
Redundancy is not achieved on a host level but achieved inherently through
the ability of a user to connect to virtual desktops hosted on any of the
surviving nodes in the event of an individual node failure.
The following shared storage components are valid for the PVS model:
Data stores
For PVS-delivered stateless virtual desktops, shared storage is only used to
host the redirected vswap files for the hosts.
User profiles (if using Roaming Profiles):
Common Internet File System (CIFS): A CIFS-based file share to host the
user profile data (for Microsoft Roaming Profiles) is required.
User data on network drives
CIFS: Specifically for the stateless user model, it is essential to redirect
persistent user data (documents, other file repositories, and so on) to
user-specific file shares (CIFS-based) or network drives. The detailed designs
of these network shares (for example, aspects of redundancy and
performance) is not within the scope of this book.
Persistent model (MCS)
The following local storage components make up the PVS model:
Hypervisor
Each compute node is running the IBM ESXi Custom image uploaded from
an internal USB key.
Local storage for each compute node
For dedicated hosts, no local storage is configured.
The following shared storage components are valid for the PVS model:
Shared storage data stores
vSphere Datastores are required to host all VM-associated data:
MCS-provisioned desktops (including base disks, identity, and difference
disks), the MCS Master Image, and the vswap files.
User profiles (for example, if using Roaming Profiles)
CIFS: The user profiles are typically hosted on a CIFS-based file share. There
are many ways to manage user profiles from native Microsoft profile
management over Citrixs profile management solution to third-party
solutions. Our environment assumes the use of Microsoft Roaming Profiles.
User data and network drives
CIFS-based file shares are primarily used for the stateless user model to
redirect persistent user data (documents, other file repositories, and so on) to
user-specific file shares or network drives. However, they can also be used to
complement the dedicated model.
Figure 4-4 on page 76 illustrates the required storage tiers. It represents a
XenDesktop hybrid environment that consists of a non-persistent PVS-delivered
model and a dedicated MCS pool connected to the same storage system.
The vDisk used to stream the images to the individual targets resides on the PVS
server on either local or shared storage. In our environment, we assume that the
PVS server is in a VM hosted on the dedicated VDI management cluster
(typically on shared storage for high availability purposes).
Figure 4-4 Storage layout for Citrix XenDesktop: Persistent versus non-persistent
4.5 Network configuration
A redundant 10 Gb Ethernet network infrastructure is used to provide the
network connectivity between all components of the Citrix XenDesktop
architecture, including storage.
The following VLANs are commonly deployed:
Storage VLAN to provide storage connectivity (if NFS storage, such as IBM
Storwize V7000 Unified, is used)
VM data VLAN for production (user) access and PVS image streaming (if
there is no separate VLAN for PVS image streaming)
BM 10 Gb Ethernet
vswap
FC, FCoE, iSCS, NFS
User profiles (MSRP) +
user data
CFS/file share(s)
MCS
master
image
MCS base
disk
MCS difference
disks + vswap
FC, FCoE, iSCS, NFS
Shared storage
Non-persistent host storage Persistent host storage
PVS pool Dedicated MSC pool
Non-persistent host 1
VFA
LOM
PVS write caches
(2+ SSD in RAD-0)
Local SSD
vm1 vmx vm2 ...
USB
key
ESXi 5.1
Persistent host 1
VFA
LOM
vm1 vmx vm2 ...
USB
key
ESXi 5.1
Diskless
Storage
connectivity
Management VLAN for dedicated access to the management interface of
systems
Dedicated PVS VLAN for desktop image streaming in highly scalable
deployments
VM control traffic VLAN for inter-VM communications, such as vMotion
On the server side, all networks are provided by a single dual-port IBM 10GbE
Virtual Fabric LAN-on-motherboard (LOM). Each physical 10 Gbps port can be
divided into four virtual ports with bandwidth allocation in 100 Mbps increments
to the maximum 10 Gbps per physical port.
You might use the following starting points for traffic bandwidth allocation:
Management: 0.5 Gbps
VM control traffic: 1 Gbps
VM data: 1 - 2 Gbps
PVS image streaming (if separate VLAN): 1 Gbps
Storage (if used): 1-2 Gbps
Note: The actual VLAN configuration and bandwidth allocation will depend on
your individual requirements; ensure that you have adequate bandwidth
available for each traffic type.
Figure 4-5 shows logical network separation.
Figure 4-5 Logical network separation
4.6 Operational model and sizing guidelines
Two separate main operational models are described in the book, to cover both
non-persistent and persistent image models. In some client environments, both
non-persistent and persistent image models might be required, therefore, a
mixed operational model is required.
To illustrate the operational model for different clients environments and size
needs, four configurations are described to support 600, 1,500, 4,500, and
10,000 users. Because the operational model for 10,000 users is roughly seven
times larger than the model for 1,500 users, you can estimate the needs for
intermediate numbers of users by using different multiples of the 1500-user
model.
P
V
S

V
L
A
N
P
h
y
s
i
c
a
l

S
y
s
t
e
m
s
H
y
p
e
r
v
i
s
o
r
VM1
VM2
VM3
VM4
VM5
VM6
VMn-1
VMn
AD DNS DHCP
U
s
e
r

V
L
A
N
User VLAN
M
g
m
t

V
L
A
N
Management
MCS provisioning
V
M

t
r
a
f
f
i
c

V
L
A
N
PVS
provisioning
User
4.6.1 VDI compute node configuration
The VDI compute node is the base system unit that makes up the compute
clusters. The compute clusters can consist of any IBM systems listed in 2.3, IBM
Flex System compute nodes on page 16.
Compute nodes run the VMware ESXi hypervisor and host Citrix XenDesktop
user VMs. For non-persistent users, the typical range of memory required for
each desktop VM is 1.5 GB - 4 GB. For persistent users, the typical range of
memory for each desktop VM is between 2 GB - 6 GB. High-end computer-aided
design (CAD) users that need 3D VDI technology might require between
8 GB - 16 GB of memory per desktop. In general, power users that require larger
memory sizes also require more virtual processors. The virtual desktop memory
must be large enough so that swapping is not needed and vSwap can be
disabled.
As a part of the IBM Reference Architecture (RA) validation, x222 and x240
compute nodes running VMs with different memory sizes of 1.5 GB, 2 GB, and
3 GB were tested
1
. The results are summarized in Table 4-2.
Table 4-2 Number of virtual desktops per compute node
If a server goes down, users on that server need to be transferred to the
remaining servers. For the degraded failover case, it is typical to keep 25%
headroom on servers, to cope with possible failover scenarios.
1
IBM Reference Architecture for Citrix XenDesktop: http://ibm.co/150EytE
Feature
(per node)
VM memory size
1.5 GB 2 GB 3 GB
x222 compute node (dual-server)
System memory 384 GB (2 x 192 GB) 384 GB (2 x 192 GB) 384 GB (2 x 192 GB)
Desktop VMs 204 (2 x 102) 158 (2 x 79) 104 (2 x 52)
Desktop VMs (failover) 250 (2 x 125) 190 (2 x 90) 126 (2 x 63)
x240 compute node
System memory 256 GB 256 GB 384 GB
Desktop VMs 125 105 105
Desktop VMs (failover) 150 126 126
The following configurations of the compute nodes are suggested:
Non-persistent host:
Processor: Dual socket (8-core Intel Xeon processor E5-2680 or E5-2470)
Memory: 256 GB (16 x 16 GB) or 384 GB (24 x 16 GB)
Disks: IBM 2.5-inch MLC HS SSDs
Disk controller: Standard integrated disk controller
Hypervisor: IBM USB Memory Key for VMware ESXi 5.1 (ESXi IBM
Custom Image)
Network adapter: Integrated Dual Port 10 GbE Virtual Fabric LOM
Persistent host:
Processor: Dual socket (8-core Intel Xeon processor E5-2680 or E5-2470)
Memory: 256 GB (16 x 16 GB) or 384 GB (24 x 16 GB)
Disks: none
Disk controller: None
Hypervisor: IBM USB Memory Key for VMware ESXi 5.1 (ESXi IBM
Custom Image)
Network adapter: Integrated Dual Port 10 GbE Virtual Fabric LOM
If you intend to use the host in a dedicated user model (MCS in dedicated
mode), you can remove the local SSD drives because all data other than the
ESXi hypervisor will reside on shared external storage.
Table 4-3 on page 81, Table 4-4 on page 81, and Table 4-5 on page 81 show the
number of compute nodes needed for each user size (based on desktop VM
quantity per server from Table 4-2 on page 79 for different VM sizes).
Table 4-3 Compute nodes needed: VM size of 1.5 GB
Table 4-4 Compute nodes needed for different numbers of users (VM size of 2 GB)
Table 4-5 Compute nodes needed for different numbers of users (VM size of 3 GB)
Description 600 users 1,500 users 4,500 users 10,000
users
Compute nodes @ 204 users 4 8 22 49
Compute nodes @ 250 users (failover) 3 6 18 40
Failover ratio 3:1 3:1 4.5:1 4.5:1
x240 compute node
Failover ratio 4:1 5:1 5:1 7:1
Description (VM size of 2 GB) 600 users 1,500 users 4,500 users 10,000
users
x240 compute node
users
4.6.2 Management services
A typical XenDesktop environment requires several management components. It
is suggested that you install the management components on a separate
management environment (for example, on a virtual management cluster
instance). However, to separate desktop and server workloads for organizational,
licensing, and workload attribute reasons, install management components on a
cluster other than the one used for VDI compute nodes.
In practice, a management cluster can be built on an existing vSphere
environment with spare capacity or you can use additional IBM systems to create
a new management cluster with the hypervisor of your choice.
For larger scale implementations, it makes sense to have a separate vCenter
instance dedicated to the management components of all VDI building blocks.
When using Provisioning Services, it is suggested to keep the PVS server close
to the compute nodes running the target VMs to optimize network traffic.
The following example is of the VMs required to host the management
components residing on the management cluster (the Reference Architecture
assumes that you run each of these components in VMs):
VM1: Citrix Provisioning Server
VM2: Citrix XenDesktop Controller
VM3: SQL Server
VM4: License Server
VM5: Web Interface Server
VM6: VMware vCenter Server
For other VMs, depending on your existing environment, you can also host
additional infrastructure servers on this cluster, such as Active Directory and
associated services, or the XenApp Controllers for Application Delivery.
x240 compute node
users
Management servers have the same hardware specification as VDI compute
nodes (see 4.6.1, VDI compute node configuration on page 79) so they can be
used interchangeably in a worst-case scenario. The management servers also
use ESXi as the hypervisor but have management VMs instead of user VMs.
Table 4-6 summarizes the VM requirements and performance characteristics of
each management service.
Table 4-6 VM requirements for management services
Table 4-7 on page 84 lists the number of management VMs for each size of users
following the high-availability and performance characteristics listed. Note that
the number of vCenter servers is half of the number of vCenter clusters shown in
Table 4-3 on page 81. This is because each vCenter server can handle two
clusters of up to 1,000 desktop VMs, and each cluster exists on two vCenter
servers.
Management
service
Virtual
processors
Memory Storage Windows
OS
HA
needed
Performance
characteristic
vCenter server 4 4 GB 15 GB 2008 R2 No Up to 2,000 VMs
vCenter SQL
server
4 4 GB 15 GB 2008 R2 Yes Double the virtual
processors and
memory for more than
2,500 users
Controller 4 4 GB 15 GB 2008 R2 Yes 5,000 user connections
Web server 4 4 GB 15 GB 2008 R2 Yes 30,000 connections per
hour
Licensing
server
2 4 GB 15 GB 2008 R2 No 170 licenses per
second
XenDesktop
SQL server
2 4 GB 15 GB 2008 R2 Yes Double the virtual
processor and memory
for more than 2,500
users
PVS server 4 32 GB 40 GB 2008 R2 Yes Up to 1,000 VMs,
memory needs to be a
minimum of 2 GB, plus
1.5 GB per image
served
Table 4-7 Management VMs needed
Note that it is assumed that common services, such as Microsoft Active
Directory, Dynamic Host Configuration Protocol (DHCP), DNS server, and
Microsoft licensing servers, already exist in the clients environment.
Based on the number and type of VMs, Table 4-8 lists the appropriate number of
physical management servers. In all cases, there is redundancy in both the
management servers and the management VMs.
Table 4-8 Physical management servers needed
4.6.3 Shared storage
VDI workloads, such as virtual desktop provisioning, VM loading across the
network, and access to user profiles and data files, place huge demands on
network shared storage. In our book, we describe the performance requirements
of both non-persistent and persistent virtual desktops and then show the storage
configuration that meets those requirements based on IBM RA.
Experimentation with VDI infrastructures shows that the input/output operation
(IOP) performance takes precedence over storage capacity. This means that
more of the slower speed drives are needed to get the required performance
than higher speed drives. Even with the fastest drives available today
(15,000 rpm), there still can be an excess capacity in the storage system.
Management service 600 users 1,500 users 4,500 users 10,000 users
vCenter server 1 1 3 7
vCenter SQL server 2 (1 + 1) 2 (1 + 1) 2 (1 + 1) 2 (1 + 1)
Controller:
Includes Licensing server
Includes Web server
2 (1 + 1)
Yes
Yes
2 (1 + 1)
No
No
2 (1 + 1)
No
No
4 (3 + 1)
No
No
Web server N/A 2 (1 + 1) 2 (1 + 1) 2 (1 + 1)
Licensing server N/A 1 1 1
XenDesktop SQL server 2 (1 + 1) 2 (1 + 1) 2 (1 + 1) 2 (1 + 1)
PVS server 2 (1 + 1) 4 (2 + 2) 8 (6 + 2) 14 (10 + 4)
Delivery model 600 users 1,500 users 4,500 users 10,000 users
Persistent 2 2 2 4
Non-persistent 2 2 4 7
The large rate of IOPs and therefore large number of drives needed for dedicated
virtual desktops can be ameliorated to some extent by caching read data in flash
memory (flash cache feature of some IBM System Storage N series controllers)
or by implementing SSD storage combined with IBM Easy Tier functionality in the
V7000 storage systems. However, there is a limit to how much flash memory is
useful because of the relatively low percentage of read operations.
The storage configurations are based on the peak performance requirement,
which usually occurs during a so-called logon storm. This is when all workers at
a company arrive at the same time in the morning and try to start their virtual
desktops, all at the same time. The storage configurations presented in this
section have conservative assumptions about the VM size, changes to the VM,
and user data sizes to ensure that the configurations can cope with the most
demanding user scenarios.
The storage configurations tend to have more storage that is strictly required to
meet the performance objectives for IOPs. In our experience, this extra storage
is more than sufficient for the other types of data needed for VDI, such as SQL
databases and transaction logs.
The storage configurations do not include facilities for data replication, data
compression, or data deduplication. These are all value-added features that
might not be required. These features can also affect the storage configuration.
The storage configurations, where possible, include flash memory as a means to
cache frequently used data.
Non-persistent virtual desktops
Non-persistent virtual desktops using Citrix XenDesktop are provisioned from
shared storage using PVS. The PVS write cache is maintained on a local SSD.
Table 4-9 summarizes the peak IOPs and shared disk space requirements for
stateless virtual desktops on a per-user basis.
Table 4-9 Shared storage performance requirements: Non-persistent VHD
Data type Protocol Size IOPS % write
User data files CIFS or NFS 5 GB 1 75%
User profiles
(through MSRP)
CIFS 100 MB 0.8 75%
Persistent virtual desktops
Table 4-10 summarizes the peak IOPs and disk space requirements for
persistent virtual desktops on a per-user basis. The last two rows are the same
as used for non-persistent desktops.
Table 4-10 Shared storage performance requirements: Persistent VHD
The sizes and IOPS for user data files and user profiles given in Table 4-9 on
page 85 and Table 4-10 can vary depending on the clients environment. For
example, power users might require 10 GB and 5 IOPS for user files because of
the applications they use. It is assumed that 100% of the users at peak load
times require concurrent access to user data files and profiles.
Storage capacity estimation
For our discussion, we assume that each user has 5 GB for shared folders and
profile data and uses an average of 2 IOPS to access those files. Investigation
into the performance shows that 600 GB 10,000 rpm drives in a RAID 10 array
give the best ratio of input/output operation performance to disk space. We found
that 300 GB 15,000 rpm drives have the required performance but extra drives
are needed even when configured as RAID 5. Therefore, it is suggested to use a
mixture of both drives for persistent desktops, shared folders, and profile data.
If users need more than 5 GB, the 900 GB 10,000 rpm drives can be used
instead of 600 GB. If less capacity is needed, the 300 GB 15,000 rpm drives can
be used for shared folders and profile data.
Depending on the number of master images, one or more RAID 1 arrays of SSDs
can be used to store the VM master images. This helps with the performance of
provisioning virtual desktops, which is a boot storm. Each master image
requires at least double the space. The actual number of SSDs in the array
depends on the number and size of images. In general, more users require more
images.
Data type Protocol Size IOPS % write
Master image FC, FCoE, iSCSI, NFS 30 GB 18 85%
Difference disks FC, FCoE, iSCSI, NFS 10 GB
User AppData folder
User data files CIFS 5 GB 1 75%
User profiles (MSRP) CIFS 100 MB 0.8 75%
Table 4-11 shows an example scenario of calculating storage capacity for VM
images.
Table 4-11 Storage capacity for storing VM images
In our example scenario, we discuss IBM Flex System V7000 Storage Node as a
shared storage.
For stateless desktops, the Flex System V7000 storage configuration is
summarized in Table 4-12.
Table 4-12 Flex System V7000 configuration for stateless desktops
Description 600 users 1,500 users 4,500 users 10,000 users
Image size 30 GB 30 GB 30 GB 30 GB
Number of master images 2 4 8 16
Required disk space (doubled) 120 GB 240 GB 480 GB 960 GB
Stateless desktops 600 users 1,500 users 4,500 users 10,000
users
400 GB SSDs in a RAID 1 for master
images
2 (1 x
RAID 1)
2 (1 x
RAID 1)
4 (2 x
RAID 1)
8 (4 x
RAID 1)
Hot spare SSDs 2 2 4 4
600 GB 10,000 rpm HDDs in a RAID 10
for users
12 28 80 168
Hot spare 600 GB HDDs 2 2 4 12
V7000 Control Enclosure 1 1 1 1
V7000 Expansion Enclosure 0 1 3 7
For persistent desktops, the Flex System V7000 storage configuration is
summarized in Table 4-13.
Table 4-13 Flex System V7000 configuration for persistent desktops
It is typical to cluster multiple Flex System V7000 storage systems by using a
separate control enclosure for every 2,500 dedicated desktops.
If CIFS or NFS services do not already exist, they can be enabled in the VDI
environment with Windows Storage Server. In this case, two more physical
management nodes are added to the solution, and Windows Storage Server is
deployed on them in a highly available cluster.
Stateless desktops 600 users 1,500 users 4,500 users 10,000
users
400 GB SSDs in a RAID 1 for master
images
2 (1 x
RAID 1)
2 (1 x
RAID 1)
4 (2 x
RAID 1)
8 (4 x
RAID 1)
Hot spare SSDs 2 2 4 4
600 GB 10,000 rpm HDDs in a RAID 10
for users
12 28 80 168
Hot spare 600 GB HDDs 2 2 4 12
300 GB 15,000 rpm in RAID 10 for
persistent desktops
40 104 304 672
Hot spare 300 GB drives 2 4 4 12
400 GB SSDs for Easy Tier 4 12 32 64
V7000 Control Enclosure 1 1 2 4
V7000 Expansion Enclosure 2 6 16 (2 x 8) 36 (4 x 9)
Chapter 5. IBM Flex System and Citrix
XenDesktop lab environment
This chapter describes the structure of the environment and the implementation
plan for Citrix XenDesktop in the International Technical Support Organization
(ITSO) lab.
The lab setup described in this chapter illustrates the main infrastructure patterns
applied to the production virtual desktop infrastructure (VDI) environments.
This chapter contains the following topics:
5.1, Lab environment on page 90
5.2, Use case for the lab environment on page 91
5.3, Component model on page 93
5.4, Operational model on page 94
5.5, Logical design on page 96
5
5.1 Lab environment
The physical environment and the software components used in the
implementation of the Citrix XenDesktop landscape are described.
The IBM Flex System environment consists of these components:
An IBM Flex System Enterprise chassis
Three IBM Flex System x240 compute nodes equipped with VMware ESXi
5.1 embedded hypervisor
An IBM Flex System V7000 used as shared storage
An IBM Flex System Manager for management purposes
An IBM Flex System Fabric EN4093 10Gb Ethernet Scalable Switch for
Ethernet flow management
An IBM Flex System Feature Code (FC) 3171 8Gb SAN Switch for storage
flow management
Table 5-1 describes the software components used in the landscape and their
roles.
Table 5-1 Software solution
Software component Description
VMware ESXi 5.1 Hypervisor officially supported by IBM and used to virtualize the
XenDesktop landscape.
VMware vCenter 5.1 This component manages the VMWare Hypervisor
environment.
Windows 2008 R2 Operating system for the database server, Citrix products, and
vCenter server.
Windows 7 Operating system for virtual desktops.
SQL Server 2008 R2 Database server to store Citrix configuration databases of
Provisioning Services, EdgeSight, XenApp, and XenDesktop.
Citrix Web Interfaces Version 5.4 This component provides users with access to their virtualized
desktops on XenDesktop and virtualized applications on
XenApp.
Citrix Provisioning Services Version 6.1 This component enables a standardized desktop image to be
streamed to all desktops while centralizing the administrative
efforts.
Citrix Licensing Server Version 11.10 This component manages the Citrix licenses.
Chapter 5. IBM Flex System and Citrix XenDesktop lab environment 91
5.2 Use case for the lab environment
IBM Flex System Manager is used to manage the Flex System components:
compute nodes, shared storage, and network switches (LAN and SAN). Flex
System Manager is also used to create the patterns to be applied in the
computer nodes to standardize the configuration characteristics and accelerate
the deployment.
The VDI is distributed across three different VMware clusters within the same
data center. This allows for segmentation of the resource consumption and also
to align with a standard pattern deployed in production environments where each
cluster has a specific purpose, as described:
Management cluster
The management cluster concentrates all infrastructure server components,
such as Active Directory, database server, and Citrix infrastructure servers.
Persistent desktop cluster
This cluster is responsible for processing the persistent desktops. This node
is separate from the audience for persistent desktops because, in general,
persistent desktops are more sensitive than non-persistent desktops and
require more aggressive service-level agreements (SLAs).
Citrix XenApp Version 6.5 This component virtualizes the application to deliver it
integrated with XenDesktop.
Citrix XenDesktop Version 5.6 This component virtualizes the desktops.
Software component Description
Note: The provisioning services server has a critical role in the Virtual
Desktop environment because this server is responsible for managing the
target devices and also for streaming the standard image for these
desktops. In scenarios where it is necessary to have many different
images, for example, with specific requirements for financial areas, industry
areas, and so on, it is common to have a separate computer node for
provisioning to avoid bottlenecks that affect the environments usage.
Non-persistent desktop cluster
The non-persistent desktops are separated from the persistent desktop
cluster because, in general, they do not need high availability (HA) enabled. If
a failure occurs at the computer nodes, desktops are restarted during the
normal recovery process by using the standard image configured at the
Provisioning Services.
For both management and persistent desktop clusters, in a production
environment, you have to include additional computer nodes for fault tolerance
(N+1) and enable high availability (HA) at the vSphere level.
Each cluster is composed of only one IBM Flex System compute node.
The storage used by the clusters is a shared storage, provided by the IBM Flex
System V7000. Two volumes are presented to physical hosts:
One volume to be used as a data store for the management cluster
One volume to be used as a data store for the persistent and non-persistent
clusters
The network traffic is split on different VLANs, managed by the IBM Flex System
Fabric EN4093 10Gb Ethernet Scalable Switch. It also provides external
connectivity for client device connection.
The storage flows are managed by the IBM Flex System FC3171 8Gb SAN
Switch. All nodes are on the same storage zone.
Table 5-2 shows the position of the software components on the infrastructure
servers.
Table 5-2 Software components installed on the servers
Server name Component installed Additional usage
vCenter Windows 2008 R2
VMware vCenter 5.1
File Server Windows 2008 R2 Host roaming profiles,
folder redirection
SQL Server Windows 2008 R2
SQL Server 2008 R2
Domain Controller Windows 2008 R2 DNS server
Web Interface Windows 2008 R2
Citrix Web Interfaces Version 5.4
5.3 Component model
The component model of the VDI is shown in Figure 5-1.
Figure 5-1 Component model
Provisioning Services Windows 2008 R2
Citrix Provisioning Services Version 6.1
Dynamic Host
Configuration Protocol
(DHCP), Trivial File
Transfer Protocol
(TFTP), and Preboot
Execution Environment
(PXE)
License Server Windows 2008 R2
Citrix Licensing Server Version 11.10
XenDesktop Controller Windows 2008 R2
Citrix XenDesktop Version 5.6
XenApp Windows 2008 R2
Citrix XenApp Version 6.5
Server name Component installed Additional usage
Client devices
vCenter
File Server
SQL Server
Domain Controller
Web Interface
Provisioning Services
License Server
XenDesktop Controller
XenApp
Management cluster
Persistent Desktops
cluster
Non-persistent Desktop
cluster
Agent
Client
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Virtual Desktop
Agent
Client
Agent
Client
Shared storage
Network protocol
Storage Protocol
Management Volume Persistent / Non-persistent Volume
Flex
System
Manager
Administrator
tools
5.4 Operational model
The components described in Table 5-1 on page 90 are installed on an IBM Flex
System Enterprise Chassis. It integrates compute nodes, storage, Ethernet
switches, and SAN switches in a single machine. This chassis is configured and
managed by the Flex System Manager node.
Figure 5-2 shows the location of each building block within the chassis.
Figure 5-2 IBM Flex System Enterprise chassis - front view
The rear of the chassis shows common management modules (CMMs) and
Ethernet and SAN switches, which manage internal communication flows within
the chassis, and communication flows with external infrastructure components.
Figure 5-3 on page 95 shows where these components are installed on the
chassis.
IBM Flex System V7000
IBM Flex System Manager (FSM)
IBM Flex System x240
sed as Non-Persistent Desktops cluster
Used as Management cluster
Used as Persistent Desktops cluster
Figure 5-3 IBM Flex System Enterprise Chassis - rear view
Figure 5-4 shows the physical view of the network between components.
Figure 5-4 Physical view of the network between components
I8M I S I LN G L S S
I8M I S IC G SAN S
CMM
I S M x C
lMM
lMM
CMM
LCM lC
L
V
IC
IC G
L S
L
1k S
M
lMM
IC
LN G

n
5.5 Logical design
The different network flows (internal and external) between Flex components and
software components, administrators, and users are described.
5.5.1 Ethernet segment
The Ethernet segment is configured to split the traffic according to the software
component requirements using the following perspective:
Management VLAN (VLAN42)
The management VLAN allows the technical support team to connect to the
environment for management purposes. It connects all Flex components
(Flex System Manager, compute nodes, storage, and switches) and ESXi
hosts. For security reasons, management traffic is not shared with the user
access segment (Public/Access).
Kernel/vMotion VLAN (VLAN10)
The Kernel/VMotion virtual LAN (VLAN) is used for VMware ESXi operation.
This VLAN is responsible for allowing the virtual machines (VMs) to be
transferred from one physical node to another in case of maintenance or a
hardware failure.
Public/Access Network (VLAN20)
Network segment for user access. This VLAN is available for a user to access
the desktops. It is also available for software component communication
needs, for example, Active Directory authentication, database access, and
other Citrix traffic (with the licensing server, XenApp, and so on).
PVS Network VLAN (VLAN30)
This segment was created to isolate the streaming traffic from Provisioning
Services to desktops. The traffic segment is a good way to avoid the network
conflicts or bottlenecks that can negatively affect the desktop deployment.
Note: The landscape created in the lab is for illustration purposes, and it does
not include cluster elements for high availability (HA) and fault tolerance (FT).
You must consider HA and FT in a production environment.
Figure 5-5 shows the logical view of the networks between components.
Figure 5-5 Network logical view
Table 5-3 shows how bandwidth is allocated for each VLAN.
Table 5-3 Ethernet adapter bandwidth allocation
Bandwidth allocation is a process step to virtualize the network adapters, where
virtual network interface cards (vNICs) are created to be presented to the hosts
as traditional adapters configured at your own VLAN.
The standard switch is used for the management port group (VLAN 42). It is
created during ESXi deployment.
VLAN Bandwidth
VLAN42 10%
VLAN10 10%
VLAN20 40%
VLAN30 40%
x C
LCM
lC lC
x C
LCM
lC lC
I8M I S I LN G L S S
l
v
L
A
n

v
L
A
n

v
L
A
n

v
L
A
n

l
v
L
A
n

v
L
A
n

v
L
A
n

v
L
A
n

x C
LCM
lC
l
v
L
A
n

v
L
A
n

v
L
A
n

v
L
A
n

L L
v
L
A
n

lC
M
n
v
L
A
n

vS

To have a consistent network configuration across the hosts, a distributed virtual
switch (dvSwitch) is created at the data center level for VM traffic (VLAN 20 and
VLAN 30), as well as for vMotion (VLAN 10).
5.5.2 Storage disk and host mapping
The MDisk is created on Flex System V7000. It is divided into two volumes with
Thin Provision preset.
For external storage access, two volumes are created:
Management: One volume to store all infrastructure servers and Citrix
components
Desktops: One volume dedicated to store the desktops write cache disks and
persistent vDisks.
Figure 5-6 shows how the volumes are mapped to the hosts.
Figure 5-6 Volume mapping
On the vSphere level, two data stores (formatted with VM Filesystem (VMFS) 5)
are created from these volumes.
Volume 1
Thin Provision
Volume 2
Thin Provision
x240
Management Node
x240
Persistent Desktops
x240
Non-persistent Desktops
Chapter 6. Deploying IBM Flex System
This chapter describes initial setup and configuration tasks that need to be
performed on IBM Flex System for virtual desktop infrastructure (VDI)
deployment.
6.1, Initial configuration of the Chassis Management Module on page 100
6.2, The IBM Flex System Manager setup wizard on page 119
6.3, Selecting the chassis to manage on page 136
6.4, Discovery and inventory collection on page 141
6.5, IBM Flex System Fabric EN4093 10Gb Ethernet Switch configuration
on page 162
6.6, IBM Flex System x240 Compute Node configuration on page 168
6.7, IBM Flex Storwize V7000 configuration on page 182
6.8, VMControl configuration and virtual server deployment on page 211
6
6.1 Initial configuration of the Chassis Management
Module
This section describes how to initially configure the Chassis Management
Module (CMM) to enable chassis management tasks.
The following tasks are described:
6.1.1, Connecting to the Chassis Management Module on page 100
6.1.2, Using the initial setup wizard on page 102
6.1.3, Configuring IP addresses for the chassis components on page 117
6.1.1 Connecting to the Chassis Management Module
You can cable the CMM to support a management connection that best matches
your site configuration. You must connect a client system to the CMM to
configure and manage the operation of the IBM Flex System Enterprise Chassis.
By default, the CMM does not have a fixed static IPv6 IP address. For initial
access to the CMM in an IPv6 environment, you can either use the IPv4
IP address or the IPv6 link-local address.
By default, the CMM is configured to respond to Dynamic Host Configuration
Protocol (DHCP) first before it uses its static IP address.
The HTTP connection is not available when the CMM security policy is set to
Secure (the manufacturing default setting). When the security policy is set to
Secure, Ethernet connections must be made by using HTTPS.
To connect to the CMM, perform the following steps.
1. Make sure that the subnet of the client computer is set to the same value in
the CMM (the default CMM subnet is 255.255.255.0). The IP address of the
CMM must also be in the same local domain as the client computer. To
connect to the CMM for the first time, you might have to change the Internet
Protocol properties on the client computer.
2. Open a web browser on the client computer, and direct it to the CMM
IP address. For the first connection to the CMM, use the default IP address of
the CMM, as shown in Figure 6-1.
Figure 6-1 Log in to Chassis Management Module with the default IP address
Chapter 6. Deploying IBM Flex System 101
3. In the CMM window shown in Figure 6-2, log in to the CMM by using the
default credentials: USERID/PASSW0RD. Click Log In.
Figure 6-2 CMM login
Clarification: The Chassis Management Module has the following default
settings:
Subnet: 255.255.255.0
User ID: USERID (all capital letters)
Password: PASSW0RD (note the number zero, not the letter O, in
PASSW0RD)
IP address: 192.168.70.100
The Chassis Management Module main window is displayed, as shown in
Figure 6-3.
Figure 6-3 CMM main window
6.1.2 Using the initial setup wizard
The next step is the initial configuration of the Chassis Management Module. The
initial setup wizard can help you configure the CMM through a web interface. The
wizard starts automatically when you first access the web interface of a new
CMM or a CMM that has been reset to its default settings.
Use the following steps to manually start the initial setup wizard and perform the
initial configuration:
1. From the CMM web interface home window, click Mgt Module Management,
as shown in Figure 6-4.
Figure 6-4 CMM main window: Mgt Module Management
The initial setup wizard is contained in the Configuration menu, as shown in
Figure 6-5. Click Configuration.
Figure 6-5 Mgt Module Management window
Several options are displayed for managing the Chassis Management Module
configuration.
2. For the first-time connection, click Initial Setup Wizard, as shown in
Figure 6-6.
Figure 6-6 Manage Configuration window
3. When the wizard starts, the first window displays the steps to be performed
on the left side of the window. The basic description of the steps is displayed
in the main portion of the window.
Figure 6-7 shows the Welcome window of the setup wizard. This wizard is
similar to other IBM wizards. Navigation buttons for the wizard are in the
lower-left corner of each window. Click Next.
Figure 6-7 Welcome window
4. Select the Health status tab on the Inventory and Health window to view the
detected components in Chassis and their current health status, as shown in
Figure 6-8. Click Next.
Figure 6-8 Inventory and Health window
5. If you have saved a configuration file, the Import Existing Configuration
window allows you to select the file that you created. It automatically enters
the appropriate values in the fields of the wizard, as shown in Figure 6-9.
Click Next.
Figure 6-9 Import Existing Configuration window
6. The General Settings window prompts you to enter some descriptive
information about Chassis, including location and contact person, as shown in
Figure 6-10 General Settings window
7. Set the date and time for the CMM in the Date and Time window, as shown in
Figure 6-11. There are two options to sync the time: Using Network Time
Protocol (NTP) or setting it manually. Click Next.
Figure 6-11 Date and Time window
8. Each CMM is configured with the same static IP address. Use the IP
Configuration window shown in Figure 6-12 to create a unique static
IP address for each CMM. If DHCP is not used, only one CMM at a time can
be added onto the network for discovery. Adding more than one CMM to the
network without a unique IP address assignment for each CMM results in
IP address conflicts. Click Next.
Figure 6-12 IPv4 tab configuration window
9. If you need to set up IPv6, select the IPv6 tab, as shown in Figure 6-13. Click
Next.
Figure 6-13 IPv6 configuration window
10.You can view the status and configure the options for the I/O modules that are
connected to the CMM, as shown in Figure 6-14. Click Next.
Figure 6-14 I/O Modules window
11.Select the security policy for your CMM, as shown in Figure 6-15. Click Next.
Figure 6-15 Security Policy window
Restriction: When the CMM is set to Secure security mode, only the secure
file transfer methods, HTTPS and Secure File Transfer Program (SFTP), can
be used for firmware updates and other tasks that involve file transfers. These
other tasks include transferring a backup configuration file to restore a
configuration. The insecure file transfer protocols, HTTP, FTP, and Trivial File
Transfer Protocol (TFTP), are disabled when security is set to the Secure
mode.
12.Select the appropriate Domain Name Server (DNS) options for your CMM, as
shown in Figure 6-16. Click Next.
Figure 6-16 DNS setup window
13.Enter the email addresses where notifications are to be sent as CMM events
occur, as shown in Figure 6-17. Click Next.
Figure 6-17 Event Recipients window
14.Confirm all of the information that has been entered in the setup wizard, as
shown in Figure 6-18. Click Finish.
Figure 6-18 Confirm window
6.1.3 Configuring IP addresses for the chassis components
The Component IP Configuration menu allows you to set the IP parameters on
I/O modules and compute nodes, as shown in Figure 6-19.
Figure 6-19 Component IP Configuration window
Click the I/O module or compute node link to open its IP properties window, as
shown in Figure 6-20.
Figure 6-20 IP Address Configuration node01 window
6.2 The IBM Flex System Manager setup wizard
The IBM Flex System Manager (FSM) is an appliance that comes with all
required software preinstalled. When this software stack is started for the first
time, a startup wizard is initiated. This wizard guides you through the required
configuration process, such as licensing agreements and Transmission Control
Protocol/Internet Protocol (TCP/IP) configuration for the appliance.
When the configuration is complete, the Flex System Manager is ready to
manage the chassis on which it is installed and up to four additional chassis.
After the chassis is managed, individual components, such as compute nodes
and switches, can also be managed.
The Flex System Manager is based on an x86 compute node, and has the same
options for obtaining an initial console. You can use the Integrated Management
Module II (IMM2) remote console or use the supplied dongle and front port on
the Flex System Manager node to connect directly to a keyboard, display, and
mouse or to a console manager unit.
To monitor the Flex System Manager startup process, connect a console by
using one of these methods before powering on the Flex System Manager node.
The following steps use the IMM2 remote console method.
Perform these steps:
1. Start a browser session, as shown in Figure 6-21, and navigate to the IP
address of the Flex System Manager IMM2.
Figure 6-21 IMM2 login
Tip: The IP address of the IMM2 of x86 compute nodes can be determined
from the Chassis Management Module (CMM) or command-line interface
(CLI). By default, the interface is set to use DHCP. However, it can be
changed to a static address by using the CMM, a CLI, or a console that is
connected directly to the video graphics adapter (VGA) port on the front of
the Flex System Manager. The console is accessible with the use of the
console breakout cable.
2. After you log on to IMM2, click the Server Management tab, as shown in
Figure 6-22.
Figure 6-22 Remote control option in IMM2
3. In the Remote Control window, click Start remote control in single-user
mode, as shown in Figure 6-23. Clicking this button starts a Java applet on
the local desktop that will be a console session to the Flex System Manager.
Figure 6-23 Starting remote console from IMM2
4. The Flex System Manager can be powered on from several locations,
including the physical power button on the Flex System Manager, or from the
CMM. For this example, selecting Tools Power On from the remote
console menu, as shown in Figure 6-24, is the most convenient method.
Figure 6-24 Powering on the Flex System Manager from the remote console session
5. As the Flex System Manager powers up and boots, the process can be
monitored. No input is accepted until the License Agreement window, which is
shown in Figure 6-25 on page 124, is displayed. Click I agree to continue.
Figure 6-25 Flex System Manager license agreement
6. The startup wizard Welcome window is displayed, as shown in Figure 6-26.
Figure 6-26 Flex System Manager Welcome window
7. Click Data and Time from the wizard menu to display the window shown in
Figure 6-27. Set the time, date, time zone, and Network Time Protocol server,
as needed. Click Next.
Figure 6-27 Setting the Flex System Manager date and time
8. Create a user ID and password for accessing the GUI and CLI. User ID and
password maintenance, including creating more user IDs, is available in IBM
Flex System Manager after the startup wizard completes. Figure 6-28 shows
creating the user ID USERID and entering a password. Click Next to continue.
Figure 6-28 Flex System Manager system-level user ID and password step
9. Network topology options include separate networks for management and
data, or a single network for both data and management traffic from the
chassis. Generally, it is best to have separate management and data
networks. To simplify this example, a combined network is configured by
using the topology on the right side of Figure 6-29. Click Next to continue to
the actual network configuration.
Figure 6-29 Flex System Manager network topology options
Separate networks for data and management traffic.
Separate management and data networks
One network for both data and management traffic.
Single management and data network
There are two possible network topologies that can be configured for Flex System Manager (refer to
network diagrams below). Note: Your network topology determines Ethernet adapter (eth0 and eth1)
settings that will be made on later pages in this wizard.
Network Topology
want to set up advanced routing in this wizard. Advanced routing provides settings for multiple gateways or subnets
within your network. (Advanced routing involves defining specific network paths for data traffic. f you are unfamiliar with
network paths, do this after the management server is running.)
Advanced Routing
Enterprise chassis
Management network
CMM CMM CMM
Top-of-Rack switch
Flex system
manager
Eth0 Eth1
System x
compute
node
Power
systems
compute
node
CMM
P
o
r
t
/O bay 1 /O bay 2
Data network
Enterprise chassis
Flex system
manager
System x
compute
node
Power
systems
compute
node
CMM
P
o
r
t
Top-of-Rack switch
Management network
/O bay 1 /O bay 2
CMM CMM CMM
Eth0 Eth1
10.The LAN adapter configuration is shown in Figure 6-30. There are two
adapters listed. The first adapter is from the Flex System Manager
management network that allows Flex System Manager to communicate on
the chassis management network. Traffic from this adapter flows through the
Chassis Management Module and uses the CMM physical connection to the
network.
The second LAN adapter represents one of the integrated Ethernet ports or
LAN-on-motherboard (LOM). Traffic from this adapter flows through the
Ethernet switch in the first I/O switch bay of the chassis. This switch is
typically used as a separate data connection to the Flex System Manager.
Notice that the first adapter is preselected, as shown in Figure 6-30.
Click Next to continue.
Figure 6-30 Flex System Manager LAN adapter configuration
11.The Configure IP Address window is displayed, as shown in Figure 6-31. This
window allows the selection of DHCP or static IP options for IPv4 and IPv6
addressing. Select the options that you want, enter the information as
required, and then click Next.
Figure 6-31 Flex System Manager IP address assignment
The wizard returns to the Configure Local Area Network (LAN) Adapters
window and preselects the next adapter in the list, as shown in Figure 6-32.
Figure 6-32 Flex System Manager LAN adapter configuration continuation option
This example uses a combined network topology and a single adapter, so it
does not need more IP addresses.
12.Select No for the Do you want to configure another LAN adapter? prompt,
as shown in Figure 6-32. Click Next to continue.
13.After the IP address assignment, the host name and gateway are configured,
as shown in Figure 6-33 on page 131. Enter the host name, domain name,
and default gateway address. Ensure that the IP address and the default
gateway adapter are correct. Click Next to continue.
Important: Click to clear the Perform network validation and recovery
when the setup wizard is complete check box (selected by default) if
DNS is not available or not configured.
Figure 6-33 Flex System Manager host name and gateway configuration
14.You can enable the use of a DNS service and add the address of one or more
servers and a domain suffix search order. Enter the information, as shown in
Figure 6-34, and click Next to continue.
Figure 6-34 Flex System Manager DNS services configuration
Tip: The host name of the Flex System Manager must be available on the
domain name server.
15.The summary window of all configured options is displayed, as shown in
Figure 6-35. To change a selection, click Back. If no changes are needed,
click Finish.
Figure 6-35 Flex System Manager startup wizard summary window
The final configuration and setup proceeds automatically without the need for
more input. Figure 6-36 on page 133 shows the processing status display.
Figure 6-36 Flex System Manager system setup processing status
Figure 6-37 shows the message when the processing is complete.
Figure 6-37 Flex System Manager system setup processing completed
Figure 6-38 shows the message when the server is started.
Figure 6-38 Flex System Manager startup
Figure 6-39 shows the startup process display.
Figure 6-39 Flex System Manager startup status
16.When the startup is completed, the local browser on the Flex System
Manager also starts. A list of untrusted connection challenges is displayed.
Click I Understand the Risks, as shown in Figure 6-40.
17.Accept these challenges by clicking Add Exception.
Figure 6-40 Flex System Manager browser add exception
18.With the security exceptions cleared, the Login window of the IBM Flex
System Manager GUI is displayed. Enter the user ID and credentials that you
entered in the startup wizard, and click Log in, as shown in Figure 6-41.
Figure 6-41 Flex System Manager Login window
The startup wizard and initial login are complete. The Flex System Manager is
ready for more configuration and use. The example uses a console from the
remote console function of the IMM2. A secure browser session can now be
started to the Flex System Manager.
6.3 Selecting the chassis to manage
Most tasks in IBM Flex System Manager can be performed with more than one
method when you are using the GUI. In this example, the most common method
is shown.
After the initial setup of Flex System Manager (FSM), it discovers any available
chassis. Selections can then be made as to which chassis are managed by the
current Flex System Manager. Use the following steps to select a chassis:
1. Click the Home tab.
2. Click the Initial Setup tab to display the Initial Setup window.
3. Click Configure Chassis Components, as shown in Figure 6-42.
Figure 6-42 Flex System Manager initial setup window
A list of available chassis displays, as shown in Figure 6-43.
Figure 6-43 Flex System Manager chassis selection for management
4. Select the check box for the chassis that you want to manage and click
Manage.
5. The Manage Chassis window is displayed, which lists the selected chassis,
as shown in Figure 6-44. A drop-down box lists the available IBM Flex System
Manager systems. Ensure that the chassis and IBM Flex System Manager
selections are correct.
Figure 6-44 Flex System Manager Manage Chassis options
6. Click Manage to update the Status column from Waiting to Finalizing, as
Figure 6-45 Flex System Manager manage chassis
The Status column eventually changes to Success, as shown in Figure 6-46
on page 140.
7. After the successful completion of the manage chassis process, click Show
all chassis, as shown in Figure 6-46.
Figure 6-46 Flex System Manager manage chassis steps completed
The original IBM Flex System Manager Management Domain window is
displayed with the target chassis as the managing IBM Flex System Manager
(Figure 6-47).
Figure 6-47 Flex System Manager with management domain updated
The Enterprise Chassis is now managed by the IBM Flex System Manager.
6.4 Discovery and inventory collection
To manage a resource within an environment or view inventory data about the
resource, that resource must first be discovered. After access is granted, an
inventory must be collected. The resource is recognized and added to the
comprehensive list of native resources and native attributes for the system.
Discovery and inventory collection are the two primary tasks that are used to
connect to supported network resources and collect information about them.
6.4.1 Discovery
Discovery is the process by which IBM Flex System Manager identifies and
establishes connections with network-level resources that IBM Flex System
Manager can manage, for example:
Compute nodes
Switches
Storage devices
Operating systems
Hypervisors
Virtual machines (VMs)
Use system discovery to identify resources within your environment, collect data
about those resources, and establish connections with them.
Choosing which discovery method to use
Discovering your resources in the most efficient manner means deciding which
method best suits your needs. Each method has advantages and disadvantages
to consider.
Collecting the inventory of a chassis component requires three action steps:
1. Discovery
2. Grant access
3. Collect inventory
There are several paths to discover and collect the inventory on the IBM Flex
System components. This section addresses the method that uses Discovery
Manager. The subsequent sections present different paths to discover the three
main components in an Enterprise Chassis (CMM, compute nodes, and I/O
modules).
Discovery protocols
A discovery protocol is any network communication protocol that IBM Flex
System Manager uses during the discovery process to discover a resource. The
default discovery profile uses a predetermined list of protocols. When you specify
a single IP address, a single host name, or a single range of IP addresses,
system discovery uses one or more protocols. These protocols are based on the
selected target resource type. With a discovery profile, you can refine the target
resource type and configure specific protocols that you want to use.
The communication protocols that IBM Flex System Manager uses during
discovery depend on the protocols that are used by the target resource type. You
need to decide about the different protocols only when you create or edit a
discovery profile. The Discovery Profile wizard helps you select and configure the
correct protocol for the type of resource that you want to discover.
When you are discovering many resources, network traffic that is associated with
the discovery process might cause timeouts. These timeouts might result in
some discoverable resources remaining undiscovered. To help prevent this
problem, use one or more discovery profiles. With a discovery profile, you can
target specific resources and limit the number of communication protocols that
are used during discovery.
By default, IBM Flex System Manager supports the following discovery protocols:
Agent manager discovery
Agent manager discovery specifically targets the discovery of Tivoli common
agents. In the Tivoli paradigm, Service Location Protocol (SLP) is not
supported. Management nodes must contact an agent manager that knows
about the agents in their environment. You can select the agent managers
that you want to use in discovery.
Common Agent Services discovery
This discovery uses SLP discovery, with which clients can locate servers and
other services in the network.
Common Information Model (CIM) discovery
CIM discovery uses the Service Location Protocol (SLP) for discovery. With
CIM discovery, clients can locate servers and other services in the network.
Interprocess communication (IPC) discovery
IPC uses services that IBM Flex System Manager provides that components
use to communicate with each other. By using these services, a server task
can communicate with an agent task that is running on a target.
Secure Shell (SSH) discovery
Secure Shell is a command interface and protocol that is based on UNIX for
securely accessing a remote computer. With SSH discovery, you can specify
either a single IP address or a range of IP addresses upon which to run
discovery.
Simple Network Management Protocol (SNMP) discovery
SNMP is a network management standard that is widely used in Internet
Protocol networks. SNMP runs management services by using a distributed
architecture of management systems and agents. SNMP provides a method
of managing network hosts, such as workstation and server computers,
routers, bridges, and hubs, from a centrally located computer that runs the
network-management software.
Storage Management Initiative Specification (SMI-S) discovery
With SMI-S discovery, clients can locate servers and other services in the
network. This design specification was developed by the Storage Networking
Industry Association (SNIA). It specifies a secure and reliable interface with
which storage management systems can identify, classify, monitor, and
control physical and logical resources in a storage area network (SAN). The
interface integrates the various devices to be managed in a SAN and the tools
that are used to manage them.
Windows distributed component object model (DCOM) discovery
Use Windows DCOM (an extension of the Microsoft Component Object Model
(COM)) to support objects that are distributed across a network configuration.
Use DCOM to specify either a single IP address or a range of IP addresses
on which to run discovery.
Discovery Manager
With Discovery Manager, you can discover and connect to the systems at your
site. This window displays an overview of all discovered systems, the systems to
which you have access, and the systems from which you collected inventory. It
has options to explore all discovered resources, in order by category, as shown in
Figure 6-48 on page 144.
To use Discover Manager, perform these steps:
1. Select System Discovery under Common tasks, as shown in Figure 6-48 on
page 144.
Figure 6-48 Discovery Manager window
2. In this example, you run a discovery on an IP address range. Select Range of
IPv4 addresses, as shown in Figure 6-49 on page 145.
Tip: You can run a discovery on a single IP address or on an IP address
range.
Figure 6-49 IP address range selection
3. Enter your IP address range and click Discover Now, as shown in
Figure 6-50.

Figure 6-50 Enter IP address range for discovery
Tip: You can also choose to schedule your discovery, if required.
4. A blue information square is displayed that indicates that the job is started, as
shown Figure 6-51. Click Display Properties to check the job status.
Figure 6-51 Discovery job information
Wait until the progress bar reaches 100%, which indicates that the discovery
is complete, as shown in Figure 6-52.
Figure 6-52 Discovery completed
Remember: Do not forget to grant the access for the object on which you
want to collect inventory as described in the following example.
If granting access to your object is required, the system displays No access in
the Access field, as shown in Figure 6-53.
Figure 6-53 Granting access to the object
5. After you request access to the object, ensure that access is granted by
clicking the General tab, as shown in Figure 6-54.
Figure 6-54 Access is granted
6. Click the Resource Explorer tab and click Action Inventory View and
Collect Inventory, as shown in Figure 6-55.
Figure 6-55 Inventory collection
7. Click Run Now.
8. Your object is selected, as shown under Target systems. Click Collect
Inventory, as shown in Figure 6-56.
Figure 6-56 Collect Inventory option
9. To begin the inventory collection, select Run Now, as shown in Figure 6-57,
and click OK.
Figure 6-57 Run collect inventory
10.A blue information square is displayed that indicates that the job is started, as
shown in Figure 6-58. Click Display Properties to check the job status.
Figure 6-58 Collect inventory information
Wait until the job is completed, as shown in Figure 6-59.
Figure 6-59 Collect inventory is completed
6.4.2 I/O modules
To discover I/O modules, perform these steps:
1. Select your chassis from the Chassis Manager view, as shown in Figure 6-60.
Figure 6-60 Chassis selection
A graphical front view of the chassis displays, as shown in Figure 6-61. You
can get information about chassis components by positioning the mouse
cursor over them.
Figure 6-61 Front chassis view (left part of the window)
You also get a rear view that functions in the same way (Figure 6-62).
Figure 6-62 Rear chassis view (right part of the window)
2. Select your chassis component, in this case, the switch module in bay 1, as
Figure 6-63 Select I/O module component from the physical view
3. Scroll down to the Action menu, and select Security Configure Access,
Figure 6-64 Configure access
The general access status is Partial access, as shown in Figure 6-65.
Figure 6-65 I/O switch module partial access
4. Different protocols are displayed, and most of them have no access. Click
Request Access, as shown in Figure 6-66.
Figure 6-66 IBM switch protocols
5. Enter credentials for your I/O module and click Request Access, as shown in
Figure 6-67.
Figure 6-67 Partial access on an Ethernet I/O module
You might receive a message that all protocols are not enabled on the
managed component. This error message indicates that not all discovery
protocols are supported by the switch, as shown in Figure 6-68.
Figure 6-68 Partial access message
6. Scroll down to note that more protocols are enabled now, as shown in
Figure 6-69.
Figure 6-69 Partial access with more protocols
7. To collect inventory for the I/O modules, select Action your I/O module
name Inventory View and Collect Inventory, as shown in Figure 6-70.
Figure 6-70 I/O module inventory collection
Remember: Some protocols must be directly enabled on the I/O module
itself. For example, if SSH was not enabled, you must enable it on the
switch before you enable access for this protocol from Flex System
Manager. To enable SNMP on the switch, you must configure SNMP
credentials.
8. Click Collect Inventory, as shown in Figure 6-71.
Figure 6-71 Collect Inventory
9. Click OK to run your collection task, as shown in Figure 6-72.
Figure 6-72 Run job
10.Click Display Properties to see the job status, as shown in Figure 6-73.
Figure 6-73 Job information
It takes a few minutes for the job to complete. You can check the status, as
Figure 6-74 Job completed
6.5 IBM Flex System Fabric EN4093 10Gb Ethernet
Switch configuration
This section describes the configuration of the IBM Flex System Fabric EN4093
10Gb Ethernet Switch. This configuration applies the VLAN configuration
designed in the previous sections.
The IBM Flex System Fabric EN4093 10Gb Ethernet Switch has the following
number of activated ports:
Fourteen internal ports activated
Ten external ports activated
The compute nodes are connected on the internal ports INT1, INT2, and INT3 of
the IBM Flex System Fabric EN4093 10Gb Ethernet Switch.
EXT1 (port 43) and EXT2 (port 44) are external ports of the network switch. Use
them to connect VLAN20 and VLAN42. Use the following steps:
1. In your browser, open the Flex System Manager web interface, select the
Additional Setup tab, and then select Manage Network Devices, as shown
in Figure 6-75.
Figure 6-75 IBM Flex System Manager web interface Home Additional Setup menu
2. In the Manage section of the Network Control page, select Ethernet
Switches.
3. Select EN4093 10Gb Ethernet Switch, as shown in Figure 6-76.
Figure 6-76 Ethernet Switches page
4. Select IBM Flex System Fabric EN4093 10Gb Scalable Switch VLAN
configuration (Figure 6-77).
Figure 6-77 EN4093 Ethernet Switch properties
5. Select the check box for IBM Flex System Fabric EN4093 10Gb Scalable
Switch VLAN configuration, and then click Edit, as shown in Figure 6-78.
Figure 6-78 VLAN Configuration
6. The VLAN configuration starts. Follow these steps:
a. On the Welcome window, click Next.
b. On the Bay Number window, select bay number 1 and click Next.
c. On the VLAN configuration window, click Create.
d. Enter the name of the VLAN and the VLAN ID, as shown in Figure 6-79.
Repeat this step for each VLAN (42, 10, 20, and 30), and then click Next.
Figure 6-79 Create VLAN Configuration task
7. On the Create VLAN egress configuration window, click Create and create
the VLAN egress configuration for VLAN 10 with port number 1, set the
Egress status to tagged, as shown in Figure 6-80. For VLAN 10, repeat the
step for ports 2 and 3. Repeat the configuration for VLANs 20, 30, and 42.
Figure 6-80 Create VLAN egress configuration
8. Delete the egress VLAN 1, port number 43.
9. Delete the egress VLAN 1, port number 44.
10.Create an egress for VLAN ID 20 and port 43, and set the egress status to
untagged.
11.Create an egress for VLAN ID 42 and port 44, and set the egress status to
untagged.
12.On the VLAN port configuration window, click Next.
13.On the Summary window, click Finish.
14.On the VLAN Configuration window shown in Figure 6-81, click Deploy to
deploy the configuration.
Figure 6-81 VLAN configuration - Deploy the configuration
15.On the Launch Job window, select Run Now to run the configuration, and
then click OK, as shown in Figure 6-82.
Figure 6-82 Launch job
6.6 IBM Flex System x240 Compute Node configuration
Using configuration patterns, you can quickly provision or pre-provision multiple
systems from a single pattern, and subsequent pattern changes will
automatically be applied to all associated systems.
Server configuration patterns give you the ability to configure the storage, I/O
adapter, boot order, and other Integrated Management Module (IMM) and
Extensible Firmware interface (UEFI) settings.
This section describes the configuration pattern configuration and deployment on
x240 compute nodes.
Use the following steps:
1. On the Initial Setup tab of the Flex System Manager web interface, click
Launch IBM FSM Explorer, as shown in Figure 6-83.
,
Figure 6-83 IBM Flex System Manager Web interface - Home
2. In the IBM Flex System Manager Explorer window, select Configuration
Patterns, as shown in Figure 6-84.
Figure 6-84 IBM Flex System Manager Explorer
3. Select New Port Pattern, as shown in Figure 6-85.
Figure 6-85 Create new pattern menu
4. Complete the form, as shown in Figure 6-86. Configure the Target port
operational mode by selecting vNic switch independent mode, and allocate
bandwidth and VLAN to the different physical functions. Click Create.
Figure 6-86 New Port Pattern configuration
5. Create a pattern for the adapter by selecting New Adapter Pattern in the
Create New Pattern menu shown in Figure 6-85 on page 170.
6. Complete the form, as shown in Figure 6-87. Set the Adapter type to
Embedded 10Gb Virtual Fabric Ethernet Controller (LOM) and the
operational mode to vNIC switch independent mode. Click Create.
Figure 6-87 New Adapter Pattern configuration
7. Configure a pattern for the server by selecting New Server Pattern in the
Create New Pattern menu shown in Figure 6-85 on page 170.
8. Select Create a new pattern from scratch, as shown in Figure 6-88.
Figure 6-88 New Server Pattern Wizard - General configuration
9. Select the pattern form factor 1 Bay Compute Node, and specify the name of
the pattern, ESXi Server Pattern, as shown in Figure 6-89. Click Next.
Figure 6-89 New server Pattern Wizard - General
10.For compute nodes that will run persistent VDI servers, we can disable the
local disk. Select Disable local disk, as shown in Figure 6-90, and then click
Next.
Figure 6-90 New Server Pattern Wizard - Local Storage
11.Configure I/O Adapters by selecting Add I/O Adapter 1 or LOM, as shown in
Figure 6-91 New Server Pattern Wizard - I/O Adapters
12.Select Embedded 10Gb Virtual Fabric Ethernet Controller (LOM), as
shown in Figure 6-92, and then click Add.
Figure 6-92 New Server Pattern Wizard - Add I/O Adapter 1 or LOM
13.Select the patterns created for the adapter (ESXi Adapter Pattern) and port
(ESXi Port Pattern) in the Initial adapter pattern and Initial port pattern fields,
as shown in Figure 6-93, and then click Add.
Figure 6-93 Pattern selection for initial port and adapter configurations
14.Click Next in the window shown in Figure 6-94.
Figure 6-94 New Server Pattern Wizard - I/O Adapter configured
15.Configure the Normal Boot Order to set Embedded Hypervisor in the first
position of the boot sequence, as shown in Figure 6-95, and then click Next.
Figure 6-95 New Server Pattern Wizard - Boot
16.Leave the default firmware settings shown in Figure 6-96, and click Save.
Figure 6-96 New Server Pattern Wizard - Firmware Settings
6.7 IBM Flex Storwize V7000 configuration
We configure the IBM Flex Storwize V7000. We configure one pool. In this pool,
we implement the following volumes:
A Thin-Provisioned volume that stands for the ESXi Management Datastore.
A Thin-Provisioned volume that is used as the ESXi Virtual Desktops
Datastore.
6.7.1 Flex System V7000 initial configuration
The following procedure guides you through the necessary steps when using the
Flex System Manager web user interface:
1. Open a web browser and point it to the IP address of the Flex System
Manager and log in. The menu panel shown in Figure 6-97 on page 183
opens, offering several selections.
Select Launch IBM FSM Explorer from the menu list.
Figure 6-97 Launch IBM FSM Explorer
A new browser tab is opened, which allows you to select the applicable
enclosure from the Chassis Map, as shown in Figure 6-98.
Figure 6-98 Select and launch the chassis in the Chassis Manager
2. In the Chassis Manager, select the applicable chassis that will launch the
chassis map for that chassis, as shown in Figure 6-99.
Figure 6-99 IBM Flex System Manager - Hardware Map
3. Right-click V7000 Storage Node in the chassis map, and then select Remote
Access. Click Launch IBM Flex System V7000, as shown in Figure 6-100,
to start the initial setup wizard.
Figure 6-100 Launch Storage Manager (V7000)
4. The next window is a welcome window from the IBM Flex System V7000
Storage Node interface, asking to either create a new system (cluster) or add
to an existing system, as shown in Figure 6-101 on page 187.
In this example, we are creating a new system. Select Create a new system,
and then click Next.
Figure 6-101 IBM Flex System V7000 Storage Node first-time setup welcome window
5. In the window shown in Figure 6-102, select whether you are using an IPv4 or
IPv6 management IP address and type the IP address (you can use either
DHCP or the static address that was assigned). The subnet mask and
gateway already show the defaults, which you can edit.
Figure 6-102 Create a new storage cluster
6. Click Finish to set the management IP address for the system. System
initialization begins and might take several minutes to complete.
When system initialization is complete, system setup is launched
automatically. The setup wizard will take you through the steps to configure
basic system settings, such as time and date, system name, and hardware
detection and verification.
6.7.2 V7000 Storage Node setup wizard
After the initial configuration described in 6.7.1, Flex System V7000 initial
configuration on page 182 is complete, the IBM Flex System V7000 Storage
Node Welcome window opens (Figure 6-103).
Figure 6-103 IBM Flex System V7000 Storage Node Welcome window
Tip: During the initial setup of the Flex System V7000, the installation wizard
asks for various information that you need to have available during the
installation process. If you do not have this information or choose not to
configure some of the items at this time, you can configure them later through
the GUI.
Follow these steps:
1. Read and accept the license agreement, as shown in Figure 6-104. Click
Next after accepting the license agreement.
Figure 6-104 Setup wizard - License Agreement
2. Specify a System Name and Superuser Password, as shown in Figure 6-105.
Click Next.
Figure 6-105 Setup wizard - Set system name and superuser password
3. Set up the system date and time, as shown in Figure 6-106. Click Next.
Figure 6-106 Setup wizard - Set Date and Time
4. Optionally, you can type in system licenses, as shown in Figure 6-107 on
page 191, and click Next. The system licenses include External Virtualization
Limit, Remote-Copy Limit, and IBM Real-time Compression Limit. The
virtualization license for all directly attached expansion enclosures is already
included in the system license and is not added here.
Figure 6-107 System license
5. Configure support notifications, as shown in Figure 6-108. Click Next.
Figure 6-108 Configure Support Notifications
6. Define company contact information, as shown in Figure 6-109 on page 192.
Click Next.
Figure 6-109 Define Company Contact
7. Verify that all hardware has been detected by the system correctly, as shown
in Figure 6-110. Click Next.
Figure 6-110 Verify hardware
8. Do not select Yes to automatically configure internal storage now because
you will create a customized storage layout.
9. Click Finish to complete the setup wizard task and log in to IBM Flex System
V7000 Storage Node, as shown in Figure 6-111. You log in as a Superuser
with your newly defined password. If you have not changed the password, the
default is passw0rd.
Figure 6-111 Setup wizard task complete
10.After a successful login, the IBM Flex System V7000 Storage Node Home
Overview window looks similar to Figure 6-112.
Figure 6-112 IBM Flex System V7000 Storage Node Home Overview window
11.The IBM Flex System V7000 Storage Node initial configuration is complete
and the cluster is up and running, as shown in Figure 6-113.
Figure 6-113 System Details view in the management GUI
12.You can continue to configure additional functions and features for your
environment to meet your implementation requirements.
6.7.3 MDisk configuration
Use the following steps to configure the MDisk:
1. Go back to the Overview window, as shown in Figure 6-114. Click the Pools
icon. On the Pools menu, select Internal Storage.
Figure 6-114 IBM Flex System V7000 - Overview
2. Click Configure Storage, as shown in Figure 6-115.
Figure 6-115 BM Flex System V7000 - Internal Storage
Choose Select a different configuration. On the Preset drop-down list,
select Basic RAID-10. In the Number of drives to provision field, specify the
number of drives (10, in our case). Click Next. As shown in Figure 6-116, the
RAID-10 is constituted by 8 drives, 1 drive is a Hot Spare, and 1 drive is left
Unconfigured.
Figure 6-116 Configure Internal Storage - RAID configuration
Note: You can specify 9 as the number of drives to provision and the result
will be the same.
3. Select Create one or more new pools and specify ESXiPool as the Pool
Name or Prefix, as shown in Figure 6-117. Click Finish.
Figure 6-117 Configure Internal Storage - pool creation
4. When the task is completed, click Close, as shown in Figure 6-118.
Figure 6-118 Create RAID Arrays task
5. Configure the spare disks. By default, there is only one spare disk configured.
Click the Pools icon. On the Pools menu, select MDisks by Pools, as shown
in Figure 6-119.
Figure 6-119 MDisks by Pools
6. Select mdisk0, right-click to display the menu and select RAID Actions
Set Spare Goal, as shown in Figure 6-120.
Figure 6-120 Set Spare Goal
7. Set the value to 2, as illustrated in Figure 6-121. Click Save.
Figure 6-121 Spare Goal
8. In the Set Spare Goal window, click Close when the task is completed.
9. Select the drive defined as Candidate, right-click to display the menu, and
select Mark as Spare, as shown in Figure 6-122.
Figure 6-122 Mark Candidate disk as Spare
10.Validate this action by clicking OK on the Information window that displays.
11.Click Close in the Mark drive as spare window when the task is completed.
6.7.4 Volumes configuration
Use the following steps to configure the volumes:
1. Click the Volumes icon. On the Volumes menu, select Volumes, as shown in
Figure 6-123.
Figure 6-123 Volumes creation
2. Select New Volume, as shown in Figure 6-124.
Figure 6-124 New Volume
3. Select Thin-Provision, as shown in Figure 6-125.
Figure 6-125 Preset selection
4. Select the pool created earlier named ESXiPool, as shown in Figure 6-126.
Figure 6-126 Pool selection
5. Create a volume named ESXi Management Volume and set the size to 300.
Select GB, as shown in Figure 6-127. Click Create.
Figure 6-127 Select Names and Sizes
6. Click Close in the Create Volumes window when the task is completed.
7. Create a volume named ESXi Virtual desktops Volume and set the size to
300. Select GB, as shown in Figure 6-128. Click Create.
Figure 6-128 ESXi Virtual desktops Volume creation
6.7.5 Hosts configuration
Use the following steps to configure the hosts:
1. Click the Hosts icon. In the correct menu, select Hosts, as shown in
Figure 6-129.
Figure 6-129 Hosts
2. Click New Host, as shown in Figure 6-130.
Figure 6-130 New Host
3. Select Fibre Channel Host, as shown in Figure 6-131.
Figure 6-131 Choose the Host Type
4. Specify the Host Name. We entered ESXi host 2. Select a port from the Fibre
Channel Ports list box, and click Add Port to List. Click Create Host, as
shown in Figure 6-132. Repeat this step for all hosts.
.
Figure 6-132 Create Host
5. To modify the host mappings, select a host, right-click to display the menu,
and select Modify Mappings, as shown in Figure 6-133.
Figure 6-133 Modify Mappings
6. Assign the needed volumes to each host, as defined in 6.7.4, Volumes
configuration on page 203, and click Apply, as shown in Figure 6-134.
Figure 6-134 Modify Host Mappings
6.8 VMControl configuration and virtual server
deployment
The steps to configure VMControl and the procedure to deploy virtual servers are
described.
6.8.1 Configure VMControl
The first step of the VMControl configuration is to discover the vCenter operating
system endpoint by using Flex System Manager, and then to request access by
using the Administrator local user. The local administrator user has full vCenter
privileges. All ESXi hosts are discovered automatically after the vCenter compute
node is accessed by Flex System Manager.
Use the following steps to configure VMControl:
1. On the Flex System Manager Home page, select the Plug-ins tab and then
launch Discovery Manager.
2. On the Common tasks panel on the right, select System Discovery.
3. Enter the IP address of the vCenter virtual server and click Discover Now, as
Figure 6-135 System Discovery
4. Flex System Manager displays the vCenter in the Discovered Manageable
Systems table, as shown in Figure 6-136. Request access by selecting No
access.
Figure 6-136 Discovered Manageable Systems
5. Enter the vCenter local administrator credentials and click Request Access,
Figure 6-137 Request Access
6.8.2 Create virtual servers
Use the following steps to create virtual servers:
1. On the Common tasks panel on the right, select Virtual servers and hosts.
2. The hosts are displayed. Right-click the host where you want to deploy the
virtual server to display the menu. Select System Configuration Create
Virtual Server, as shown in Figure 6-138.
Figure 6-138 Create Virtual Server menu
The Create Virtual Server wizard starts. Perform the following steps:
1. In the Welcome window, click Next.
2. In the Name step, specify the name of the virtual server to create and click
Next.
3. In the Source step, specify the operating system and click Next.
4. In the Processor step, specify the number of processors and click Next.
5. In the Memory step, specify the memory size and click Next.
6. In the Disks step, click Create New, and then select the Storage Pool to use
to store the disk. In Additional Settings, specify the disk name and the size.
Click OK to validate your choice. Click Next.
7. In the Network step, select the network interface to connect the virtual server.
Click Next to validate your choice.
8. In the Summary step, review the configuration shown in Figure 6-139. Click
Finish.
Figure 6-139 Create Virtual Server Summary window
9. Repeat this procedure for each virtual server.
Chapter 7. Deploying Citrix XenDesktop
How to provision virtual machines (VMs) for Citrix XenDesktop components and
how to install the Citrix XenDesktop components are described.
7.1, Configuring utility services and vSphere on page 216
7.2, Provisioning VMs for Citrix XenDesktop components on page 217
7.3, Installing the Citrix License on page 217
7.4, Installing Citrix XenDesktop Controller on page 228
7.5, Installing Citrix XenApp on page 248
7.6, Installing Citrix Web Interface on page 271
7.7, Installing Citrix Provisioning Services on page 280
7
7.1 Configuring utility services and vSphere
To save time, the VMware suggested method to deploy multiple VMs is to use
templates. A template is a master copy of a VM that can be used to create and
provision VMs. In this scenario, we performed a classic build for the Microsoft
Windows 2008 R2 server in a VM named W2K8R2 and converted it in the
template.
In this scenario, the template W2K8R2 is used to build the necessary VMs for
installing network and utility services.
A summary of VMs and their characteristics is shown in Table 7-1.
Table 7-1 Network and utility services VMs
Note: For more information about templates, see the VMware documentation:
http://bit.ly/16MDNGQ
VM name vCPU
(number)
RAM (GB) VMDK (GB) Network
(VLAN)
Purpose
DC1 2 4 30 20 Domain
Controller and
Remote Desktop
Licensing
Manager
FS 2 4 30 + 10 20 File server
SQL 4 4 15 20 MS SQL 2008 R2
vCenter 4 4 15 42, 20 vCenter 5.1
Win7 1 2 30 42, 20 User desktop
Note: Installing and configuring Windows Server roles, such as Domain
Controller, Internet Information Services (IIS), or File Server, are not in the
scope of this book and are not documented.
Also, VMware vCenter Server installation is not documented in this book. For
details about installing vCenter Server 5.1, go to this website:
http://bit.ly/1cqNJxD
Chapter 7. Deploying Citrix XenDesktop 217
7.2 Provisioning VMs for Citrix XenDesktop
components
In this scenario, a template, W2K8R2, is used to build the necessary VMs for
installing Citrix components.
A summary of VMs and their characteristics is shown in Table 7-2.
Table 7-2 Citrix XenDesktop VMs
7.3 Installing the Citrix License
Because the Citrix License appliance is not supported in the VMware
environment, install this component on a separate VM.
VM name vCPU
(number)
RAM (GB) VMDK (GB) Network
(VLAN)
Purpose
XLS 2 4 15 20 License server
XDC 4 4 15 20 XenDesktop
Controller
XAP 2 4 30 20 XenApp
XWI 4 4 15 20 Web interface
PVS 4 32 40 20, 30 Provisioning
services
Note: In this scenario, License Server Version 11.10 (bundled with
XenDesktop installation media) is installed. For a reference to Citrix
documentation for License Server, see this website:
http://bit.ly/1aTEaRa
Use the following steps to install License Server Version 11.10:
1. Mount the remote media on the XLS VM.
2. After mounting the Citrix XenDesktop 5.6 installation media, the AutoRun
window opens, as shown in Figure 7-1. Select Install XenDesktop.
Figure 7-1 XenDesktop AutoRun
3. Accept the licensing agreement shown in Figure 7-2. Click Next.
Figure 7-2 XenDesktop Licensing Agreement
4. Select License Server and clear the other options, as shown in Figure 7-3.
Click Next.
Figure 7-3 XenDesktop Select Components to Install window
5. Select Enable these ports to allow TCP Ports 27000 and 7279 to be used for
License Server connections, as shown in Figure 7-4, License Server Firewall
Configuration window on page 221. Click Next.
Figure 7-4 License Server Firewall Configuration window
6. Review the summary for the installation, as shown in Figure 7-5. Click Install.
Figure 7-5 License Server Summary window
7. Allow the Setup Wizard to complete the installation. After the installation is
complete, a final summary is displayed, as shown in Figure 7-6. Click Close.
Figure 7-6 License Server Installation Successful
7.3.1 Configuring the licenses
After installing the License Server, the licenses need to be configured. The setup
creates a shortcut to the License Administrator Console and opens a browser to
https://localhost:8082, as shown in Figure 7-7.
Use the following steps to configure the licenses:
1. Select Administration.
Figure 7-7 Citrix Licensing Console
2. After entering the credentials used for installation, select Vendor Daemon
Configuration (Figure 7-8).
Figure 7-8 License Server Vendor Daemon Configuration
3. Import the license file by selecting Import License File. Click Browse to
locate the correct file and then select Import License (Figure 7-9).
Figure 7-9 License Server Import License File window
Note: It is not in the scope of this book to describe the process of obtaining
the license file from the Citrix website. However, it is important to
remember that the name of the server on which the licensing components
are installed is encoded in the license file and is case-sensitive.
4. Restart the vendor daemon service and select Reread License Files
(Figure 7-10).
Figure 7-10 License Server Reread License Files
5. The message The license file was successfully reread displays, as
Figure 7-11 License Server with license
7.4 Installing Citrix XenDesktop Controller
The Desktop Delivery Controller brokers the connections between the user and
the virtual desktop, as well as the creation and management of virtual desktops
on the provisioning and hypervisor infrastructures. The controllers enumerate
resources for the users and direct user launch requests to the appropriate virtual
desktop.
Note: Ensure that you install this component on a separate VM.
Before proceeding with the installation, you need to add the Secure Sockets
Layer (SSL) certificate of vCenter on the server where you plan to install
XenDesktop Controller. Citrix suggests that you use a digital certificate that is
issued from a certificate authority (CA). The VMware self-signed certificate can
be also used if the organizations security policy permits it.
If multiple XenDesktop Controllers are planned, apply the next procedure for all
of them.
7.4.1 Installing the SSL certificate
Use the following steps to install the certificate:
1. Open Internet Explorer and enter the address of the computer running
vCenter Server as https://vcenter.abclab.local.
2. Accept the security warnings.
3. Click Certificate Error in the Security Status bar, and select View
certificates.
4. Click Install certificate, and then click Next.
5. Select Place all certificates in the following store, and then click Browse.
6. Select the Show physical stores check box.
7. Expand Trusted People and select Local Computer.
8. Click OK, and then click Finish.
Note: For additional information about installing this component, see this
website:
http://support.citrix.com/proddocs/topic/xendesktop-bdx/cds-create-f
arm-bdx.html
7.4.2 Installing the XenDesktop Controller
Use the following steps to install the XenDesktop Controller:
1. Mount the remote media on the XLS VM.
2. After mounting the Citrix XenDesktop 5.6 installation media, the AutoRun
window opens, as shown in Figure 7-12. Select Install XenDesktop.
3. Accept the license agreement, as shown in Figure 7-13. Click Next.
Figure 7-13 XenDesktop Licensing Agreement
4. Select the components that you want to install and clear the other option
selections (Figure 7-14).
Click Next.
Figure 7-14 XenDesktop Select Components to Install
Note: Because we are using an existing (dedicated) SQL server in our
environment, clear Install SQL Server Express.
5. The Firewall Configuration window opens (Figure 7-15). Click Next.
Figure 7-15 Controller Firewall Configuration window
6. Review the summary for the installation, as shown in Figure 7-16. Click
Install.
Figure 7-16 Controller Summary
7. Allow the installation process to finish. If you want to configure Machine
Provisioning Services, select Configure XenDesktop after closing, as
shown in Figure 7-17. Click Close.
Figure 7-17 Controller Installation Successful
8. If you chose to configure XenDesktop, the Citrix Desktop Studio console is
automatically started. Alternatively, you can select Start All Programs
Citrix Desktop Studio. Select Desktop deployment, as shown in
Figure 7-18.
Figure 7-18 Citrix Desktop Studio
9. The initial configuration starts. Specify the site name, database server
location, and database name (see Figure 7-19). Click Next.
Figure 7-19 Controller database initial configuration
10.Select Test connection and enter the credentials that are required for
database connection, as shown in Figure 7-20. Click OK.
Figure 7-20 Controller - Enter credentials for database connection
11.If the test is successful, a dialog displays the message All database
connection tests passed (see Figure 7-21). Click OK, and then click Next.
Figure 7-21 Controller - Database connection tests passed
12.Configure the license server. Set your XenDesktop edition and licensing
model, as shown in Figure 7-22, or you can add license files and edit your
licensing model later via XenDesktop Studio. Click Next.
Figure 7-22 Controller - License server configuration
13.Follow these steps to configure the type and connection details for the
virtualization layer (see Figure 7-23):
a. Choose VMware virtualization as the host type.
b. Enter the url https://<fqdn_vcenter>/sdk in the Address field.
c. Provide a user name and password used for connection to vCenter.
d. Provide a connection name.
e. Select Use XenDesktop to create virtual machines, as shown in
Figure 7-23.
f. Click Next.
Figure 7-23 Controller connection to virtualization layer
14.In the Host section, enter the host name, then select the cluster used for
desktops (in our example, Non-persistent Desktops), as shown in
Figure 7-24. Click OK, and then, click Next.
Figure 7-24 Controller - Select a cluster for desktops
15.In the Network section, select the network for the VMs to use (VM VLAN 20 in
our scenario), as shown in Figure 7-25. Click Next.
Figure 7-25 Controller - Configure VM network
16.Continue with selecting data stores used for desktops (see Figure 7-26). Use
the default setting in the Personal vDisk storage section, and click Next.
Figure 7-26 Controller - Select data stores
Review the summary and click Finish (see Figure 7-27).
Figure 7-27 Controller - Initial configuration summary
17.The Desktop Studio displays the results shown in Figure 7-28.
Figure 7-28 Desktop Studio
7.4.3 Advanced settings
To finish the initial configuration, a couple of advanced settings are still needed:
Store Controller information in Active Directory (AD)
This stores the FarmGUID and connector information in AD so that when the
vda (virtual desktop agent) is loaded, the FarmGUID can be pulled from AD
and not have to be manually entered.
To perform AD-based controller discovery, run the PowerShell script
Set-ADControllerDiscovery.ps1 that is installed on each controller in the
folder $Env:ProgramFiles\Citrix\Broker\Service\Setup Scripts (see
Figure 7-29 on page 247). The script must be run on a controller in the site by
a user who is a full administrator of the controller and who has the appropriate
permissions to make changes in the relevant organizational unit (OU) in AD.
Domain Name System (DNS) server resolution of desktops
This setting is an enabled/disabled setting that is disabled by default. It helps
with desktop discovery. Enter the command Set-BrokerSite
-DnsResolutionEnabled 1 in PowerShell SDK (see Figure 7-29).
Trust XML service requests
This setting is an enabled/disabled setting that is disabled by default. Enter
the command Set-BrokerSite -TrustRequestsSentToTheXmlServicePort
$true in PowerShell SDK (see Figure 7-29).
Figure 7-29 Controller advanced settings in PowerShell SDK
Change the default port of 80 for XML
Port 80 is used by other services and processes and that can sometimes lead
to conflicts. It is a good idea to change this port; Citrix suggests using 8082.
Enter the command BrokerService.exe -wiport 8082 in a command prompt
opened with administrative-level rights (see Figure 7-30).
Figure 7-30 Controller advanced settings in a command prompt
The result of the advanced settings can be seen in Desktop Studio as shown in
Figure 7-31.
Figure 7-31 Desktop Controller - Site-wide settings
7.5 Installing Citrix XenApp
XenDesktop integrates well with XenApp. Together, XenDesktop and XenApp
achieve true abstraction of the operating system, applications, and user data.
Note: See the eDoc with the configuration for the Active Directory OU
configuration for XenDesktop:
http://bit.ly/1ae29JE
Details about enabling the DNS server resolution for XenDesktop are at this
website:
The eDoc with the configuration to enable the XML trust for XenDesktop is at
the bottom of this page:
http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-config-s
ite-rho.html
Read this article to learn how to change the XML port for XenDesktop:
Use the following steps to install Citrix XenApp on a separate VM:
1. Connect to the server selected to be the XenApp Server and navigate to the
location of the XenApp Installer Media and launch using AutoPlay. Select
Install XenApp Server, as shown in Figure 7-32.
Figure 7-32 XenApp setup
Note: For more information about installing XenApp 6.5, see this website:
http://bit.ly/17XV7Jo
2. If necessary, confirm the installation of .Net 3.5 SP1, and then select Add
server roles, as shown in Figure 7-33.
Figure 7-33 XenApp Add server roles
3. Select the XenApp edition that you want to install, as shown in Figure 7-34.
Figure 7-34 XenApp editions
4. After accepting the licensing agreement, select the role XenApp and clear all
of the other options, as shown in Figure 7-35. Click Next.
Figure 7-35 XenApp Server Roles
5. Do not select any of the Optional Components shown in Figure 7-36. Click
Next.
Figure 7-36 XenApp Server Roles - Optional Components
6. Review the prerequisites and then click Next, as shown in Figure 7-37.
Figure 7-37 XenApp Review prerequisites
7. Review the summary and click Install, as shown in Figure 7-38.
Figure 7-38 XenApp Ready to install
8. Installation begins. When a prerequisite requires a restart, restart the server.
Click Finish to allow the reboot, as shown in Figure 7-39.
Figure 7-39 XenApp Prerequisite requires restart
9. After the restart, log in to the server by using the same administrator account
and allow the wizard to load. Then, select Resume Install, as shown in
Figure 7-40.
Figure 7-40 XenApp Resume Install
10.If necessary, repeat step 9 on page 257. When you are finished, Figure 7-41
displays. Click Finish.
Figure 7-41 XenApp installed successfully
7.5.1 Specify licensing
Use the following steps to specify the licensing:
1. Select Specify Licensing, as shown in Figure 7-42.
Figure 7-42 XenApp Specify Licensing
2. Enter the license server name and then click Test Connection, as shown in
Figure 7-43. A dialog displays confirming the license version.
Figure 7-43 XenApp Licensing Configuration
3. You can select the licensing model or select it at a later time, as shown in
Figure 7-44. Click Apply.
Figure 7-44 XenApp Select Licensing Model
7.5.2 Initial configuration
Use the following steps to perform the initial configuration for XenApp:
1. Select Configure, as shown in Figure 7-45.
Figure 7-45 XenApp Configure
2. Because this server is the first XenApp server, you need to create a new
server farm. Select Create a new server farm, as shown in Figure 7-46.
Figure 7-46 XenApp - Create a new server farm
3. Specify the farm name and the Citrix administrator, as shown in Figure 7-47.
Click Next.
Figure 7-47 XenApp - Enter basic information about the new server farm
4. Select Existing Microsoft SQL Server database to configure the database,
as shown in Figure 7-48. Click Next.
Figure 7-48 XenApp - Choose a database for the new server farm
5. Specify the server name, database name, and authentication model, as
Figure 7-49 XenApp - Database connection information
6. Specify the credentials to connect the database and test the connection, as
Figure 7-50 XenApp - Enter database credentials and test database connection
Note: Both Microsoft Windows and Microsoft SQL Server authentication
methods are shown. For increased security environments, Citrix suggests
using Windows authentication only. The user account for installing the data
store must have database owner (db_owner) rights to the database.
7. Configure the shadowing, as shown in Figure 7-51. Click Next.
Figure 7-51 XenApp - Configure shadowing
8. Do not configure any advanced server settings, as shown in Figure 7-52.
Click Next.
Figure 7-52 XenApp - Specify advanced server settings
9. Review the summary information and click Apply. Then, wait the process to
complete (see Figure 7-53), and click Finish.
Figure 7-53 XenApp - Server configured successfully
10.Reboot the server (see Figure 7-54).
Figure 7-54 XenApp - Server Configuration Tasks
7.6 Installing Citrix Web Interface
The Web Interface provides secure access to XenApp and XenDesktop
resources.
Important: For more information about installing Web Interface version 5.4,
see this website:
http://bit.ly/HswjD1
Microsoft .NET 4.x must not be installed on the web interface server because
it is incompatible, by default, with web interface configuration. For more
information, see this website:
Use the following steps to install Citrix Web Interface on a separate VM:
1. Mount remote media on the XWI VM.
2. After inserting the Citrix XenDesktop 5.6 installation media, the AutoRun
window opens. Accept the license agreement. Then, select the component
Web Access and clear the other options, as shown in Figure 7-55. Click
Next.
Figure 7-55 XenDesktop components to install
3. Review the summary information and click Install, as shown in Figure 7-56.
Figure 7-56 Web Interface review summary
4. After the installation process completes, click Close, as shown in Figure 7-57.
Figure 7-57 Web Interface Installation Successful
7.6.1 Configure the website
Use the following steps to configure the website:
1. Select Start All Programs Citrix to open the Citrix Web Interface
Management. A wizard for the initial configuration displays, as shown in
Figure 7-58. Specify the farm name (XenDesktopFarm1 in our example) and
add the server (XenDesktop Controller). Change the default XML Service port
from 80 to 8082. Click Next.
Figure 7-58 Initial configuration of Web Interface
2. Configure the authentication method, as shown in Figure 7-59. (It depends on
your companys security policy and it can be changed later, if needed). Click
Next.
Figure 7-59 Web Interface Configure Authentication Methods
3. Select the domain restriction, as shown in Figure 7-60. Click Next.
Figure 7-60 Web Interface Domain Restriction
4. Specify the appearance of the logon window, as shown in Figure 7-61. Click
Next.
Figure 7-61 Web Interface Specify Logon Screen Appearance
5. Select the published resource type, as shown in Figure 7-62. Click Next.
Figure 7-62 Web Interface Select Published Resource Type
6. Review the summary information, as shown in Figure 7-63. Click Finish.
Figure 7-63 Web Interface Confirm Settings
7.7 Installing Citrix Provisioning Services
As part of the XenDesktop implementation, Provisioning Services streaming
technology is the main delivery method for non-persistent desktops in scalable
implementations.
Note: For more information about installing and configuring Provisioning
Services 6.1, see this website:
http://bit.ly/1bD3a0u
Use the following steps to install Provisioning Services on a dedicated VM. The
Dynamic Host Configuration Protocol (DHCP) service role is configured on this
VM:
1. Mount the remote media on the PVS VM.
2. After mounting the Provisioning Services installation media, the Provisioning
Services AutoRun window opens, as shown in Figure 7-64. Select Server
Installation.
Figure 7-64 Provisioning Services AutoRun
3. The window shown in Figure 7-65 displays the prerequisite items that need to
be installed. Click Install to install all of the prerequisites.
Figure 7-65 Provisioning Services Prerequisites
4. Accept the License Agreement for the prerequisites. The Installation Wizard
for Citrix Provisioning Services displays, as shown in Figure 7-66.
Figure 7-66 Citrix Provisioning Services wizard
5. Accept the License Agreement shown in Figure 7-67. Click Next.
Figure 7-67 Citrix Provisioning Services License Agreement
6. Specify the company information as shown in Figure 7-68. Click Next.
Figure 7-68 Citrix Provisioning Services Customer Information
7. Accept the default installation folder, and then the complete setup type.
Review the summary and then click Install.
8. When the installation completes, the Provisioning Services Configuration
Wizard displays, as shown in Figure 7-69. Click Next.
Figure 7-69 Provisioning Services Configuration Wizard
9. Specify the DHCP services, as shown in Figure 7-70. Click Next.
Figure 7-70 Provisioning Services DHCP Services
10.Specify the Preboot Execution Environment (PXE) services, as shown in
Figure 7-71 Provisioning Services PXE Services
11.Create a new farm, as shown in Figure 7-72. Click Next.
Figure 7-72 Provisioning Services Farm Configuration
12.Specify the database server name and the instance name, as shown in
Figure 7-73 Provisioning Services Database Server
13.After entering the credentials needed for database connection, specify the
name for the database, farm, site, and collection, as well the farm
administrator group, as shown in Figure 7-74. Click Next.
Figure 7-74 Provisioning Services farm details
14.Define a new store name and the default path, as shown in Figure 7-75. Click
Next.
Figure 7-75 Provisioning Services - Store configuration
15.Specify the License Server name and select Validate license server version
and communication, as shown in Figure 7-76. Click Next.
Figure 7-76 Provisioning Services - License Server
16.Set a user account to run the Stream and Soap Services. Select Configure
the database for the account, as shown in Figure 7-77. Click Next.
Figure 7-77 Provisioning Services - User account for Stream and Soap Services
17.Select Automate computer account password updates in the Active
Directory (AD), as shown in Figure 7-78. Click Next.
Figure 7-78 Provisioning Services - AD computer account password update
18.Specify the network cards for stream services, as shown in Figure 7-79.
Choose the NIC connected to the dedicated network for streaming (in our
scenario, VM VLAN 30). Click Next.
Figure 7-79 Provisioning Services - Network Communications
19.Specify the Trivial File Transfer Protocol (TFTP) option and Bootstrap location,
as shown in Figure 7-80. Click Next.
Figure 7-80 Provisioning Services - TFTP Option and Bootstrap Location
20.Specify the servers that target devices can contact to complete the boot
process, as shown in Figure 7-81. Click Next.
Figure 7-81 Provisioning Services - Stream Servers Boot List
21.Review the summary information of the settings and select Automatically
Start Services, as shown in Figure 7-82. Click Finish.
Figure 7-82 Provisioning Services - Finish
When the installation completes, the Configuration Wizard displays, as shown in
Figure 7-83. Click Done.
Figure 7-83 Provisioning Services configuration completed
7.7.1 Install the Citrix Provisioning Console
Use the following steps to install the Citrix Provisioning Console:
1. After inserting the product installation media, the Provisioning Services
AutoRun window opens, as shown in Figure 7-84. Select Console
Installation.
Figure 7-84 Provisioning Services AutoRun
2. Accept the license agreement, and then select the installation path and setup
type: full or custom. After you finish, the setup wizard displays, as shown in
Figure 7-85. Click Finish.
Figure 7-85 Provisioning Services - Install Console x64
3. Select Start All programs Citrix Provisioning Services Console
to access the console, as shown in Figure 7-86.
Figure 7-86 Provisioning Services Console
Chapter 8. Operating Citrix XenDesktop
This chapter describes the steps to prepare your virtual desktop infrastructure
(VDI) environment to deliver desktops to your users.
8.1, Introduction on page 304
8.2, Configuring the gold image on page 304
8.3, Configuring desktop distribution on page 336
8.4, Roaming profiles and folder redirection on page 377
8.5, Monitoring health on page 398
8
8.1 Introduction
The VDI operations consist of the initial desktop installation and configuration in
accordance with your companys business requirements and security policies.
This chapter describes how to prepare the desktop image (gold image) to be
integrated with Provisioning Services and the XenDesktop Controller to be
published to users.
This chapter also covers the user data that describes the profile and folder
redirection and the integration with XenApp infrastructure to provide the business
applications to desktops.
8.2 Configuring the gold image
The concept of the gold image means the initial installation of a virtual desktop
that contains all of the customizations to meet your companys directives and
requirements.
One of the benefits of using a gold image installation is the reduction of
administrative effort. As the VDI administrator, you perform the security and
business applications update at the gold image and then you schedule when this
new version will be available to your users.
The desktops that you will deliver by using the Citrix XenDesktop infrastructure
will be a derivative of this gold image.
The following sections describe how to prepare the gold image and integrate it
with your XenDesktop infrastructure.
8.2.1 Preparing the gold image for streaming services
The gold image preparation consists of installing your client operating system
using a virtual machine (VM) and all of the other required components before
integrating with the Citrix infrastructure.
Note: This procedure does not cover the installation of the operating system.
It is assumed that you already have the operating system installed and the VM
sizing (processor and memory) configured.
Chapter 8. Operating Citrix XenDesktop 305
Integrating the gold image with the Citrix Infrastructure consists of the following
main steps:
1. Include an additional hard disk to your VM to store the write cache file (used
for streaming desktops). Make the following configuration changes to this
disk:
Create a new partition and format the new disk by using the New
Technology File System (NTFS).
Assign the letter D: for this new disk.
Move the pagefile location from C: to the new disk (D).
2. Install the Citrix Profile Manager
The Citrix Profile Manager is responsible for managing the user profile by
loading the files when the user logs on to the desktop and saving the files
when the user logs off from the desktop.
The product offers two methods to set the parameters:
By using the .INI file that is stored on the installation folder
Through Group Policies that are created at the Active Directory (AD) level
In this scenario, we use the Group Policy to create the configuration and to
apply it to the desktops.
The version of Citrix Profile Manager that is used in the landscape is 4.1.2
and the parameters that we used to install were not changed from the default
options suggested by the installer. For more information about the
configuration, see 8.4, Roaming profiles and folder redirection on page 377.
3. Install the Virtual Desktop Agent
The Virtual Desktop Agent is responsible for registering the provisioned
desktop in XenDesktop Controller after the startup. After this registration
process, the XenDesktop Controller acts as a broker to deliver the desktops
to the users. In this scenario, we chose to install the Virtual Desktop by
running AutoRun.exe, which is located on the Citrix XenDesktop media.
Installing the Virtual Desktop Agent
Use the following procedure to install the Virtual Desktop Agent:
1. After you insert the Citrix XenDesktop 5.6 installation media, the AutoRun
XenDesktop window opens, as shown in Figure 8-1. Select Install Virtual
Desktop Agent.
2. Select Advanced Install, as shown in Figure 8-2.
Figure 8-2 Deployment method
3. This installation does not test graphic applications, so we install the regular
Virtual Desktop Agent. Select Virtual Desktop Agent and click Next
(Figure 8-3).
Figure 8-3 Virtual Desktop Agent
4. Select Citrix Receiver and click Next (Figure 8-4). The Citrix Receiver
configuration is applied by using the Group Policy Object (GPO), as described
in Figure 8-4.
Figure 8-4 Components selection
5. Select Yes, enable personal vDisk to install this option on the gold image, as
This feature allows the user to customize their desktop, but also permits
centralized administration from Provisioning Services. For a description about
how to configure a personal vDisk, see 8.3.2, Configuring streaming
desktops with personal vDisk on page 353. Click Next.
Figure 8-5 Personal vDisk installation
6. Specify the location of the XenDesktop Controller to which the Virtual
Desktop Agent will register, as shown in Figure 8-6. Click Next.
Figure 8-6 Configuring the XenDesktop Controller
7. Select Optimize XenDesktop Performance, User Desktop Shadowing,
and Real Time Monitoring, as shown in Figure 8-7, and click Next.
Figure 8-7 Virtual Desktop Configuration
Note: In this environment, the Windows Firewall service is disabled. If you
need to use the Windows Firewall services, you must ensure that the
required traffic for required ports is allowed.
8. Figure 8-8 shows the installation summary. Click Install.
Figure 8-8 Installation Summary
Installing Provisioning Services
The Provisioning Services target device is the gold image to allow streaming
desktops.
Use the following procedure to install the Provisioning Services target device,
configure the agent to communicate with the Provisioning Server (PVS), and to
convert the gold image as a vDisk on PVS to be delivered to the desktops:
1. The installation folder for the Provisioning Services target device is on
XenApp ISO in D:\Provisioning Services\Device (where D: is your CD
drive). Figure 8-9 shows the initial window of the installation process. Click
Next.
Figure 8-9 Provisioning Services Target Device
2. Select Launch Imaging Wizard and click Finish, as shown in Figure 8-10.
Figure 8-10 Wizard configuration
3. After the agent is installed, the Provisioning Services Imaging Wizard
displays, as shown in Figure 8-11. Click Next.
Figure 8-11 Target device configuration
4. Specify the PVS Server name and the port number to connect the PVS agent
to the PVS Server, as shown in Figure 8-12. Click Next.
Figure 8-12 Connection configuration
5. After the connection, the new vDisk is created on the store that is defined
during the Provisioning Server installation. Select Create new vDisk and
click Next, as shown in Figure 8-13.
Figure 8-13 Provisioning vDisk configuration
6. Specify the vDisk name, store, VHD type, and vDisk block size, as shown in
Figure 8-14 Provisioning vDisk configuration
7. On Figure 8-15, under Source Volume, the second disk (D:) and the CD-ROM
drive must be changed to None so that they are not converted. Optionally,
you can adjust the size for the C: partition. Click Next.
Figure 8-15 Provisioning vDisk configuration - Convert disk and space
8. Create the target device at the Provisioning Server by providing the target
device name, MAC, and collection. This target device configuration is an
association between the Provisioning Server and the client using the Media
Access Control (MAC) address from the desktop VM, as shown in
Figure 8-16 Target device inclusion
9. Figure 8-17 shows the summary of farm changes before the configuration.
Select Optimize for Provisioning Services.
Figure 8-17 Provisioning Services target device installation summary
10.Review the options that are checked and click OK to return to the summary of
changes (Figure 8-18). On Figure 8-17 on page 322, click Finish to complete
the configuration.
Figure 8-18 Provisioning Services Device Optimization Tool
11.Restart the gold image. You must click No to shut down your VM, as shown in
Figure 8-19.
Figure 8-19 Gold image restart
12.You must adjust the boot order of your VM before it restarts. Your network
adapter must be at the top of the list to boot using the network. With this
configuration, connect in the PVS and upload your image. Figure 8-20 shows
the configuration order for the boot options.
Figure 8-20 Boot order adjustment
13.After adjusting the boot order, start your VM. After you log on with
administrative rights, Citrix XenConvert starts to convert your machine to
Provisioning Services, as shown in Figure 8-21.
Figure 8-21 Gold image conversion
14.After the conversion process is complete, you must shut down your VM. Using
the Provisioning Services Console, you must change the target device to boot
the VM from vDisk, as shown in Figure 8-22. Click OK.
Figure 8-22 Target Device boot adjustment
15.After adjusting the target device in the Provisioning Services Console, power
on your VM normally. At this time, your gold image boots by using the
streaming services. Your vDisk is running in private mode, which means that
the changes that you perform in your VM are stored on the vDisk. Figure 8-23
shows the vDisk status after the boot.
Figure 8-23 Target device verification
16.After this final validation, the next step is to modify the vDisk to Standard
Image mode. Then, you configure the cache type to be stored by using the
local hard disk drive in the target device (disk D:), which was created at the
beginning of 8.2.1, Preparing the gold image for streaming services on
page 304).
To perform this configuration, you must shut down your VM. By using the
Provisioning Services Console, locate your vDisk and go to vDisk Properties
(right-click in the vDisk and select Properties). Change the Access mode to
Standard Image (multi-device, read-only access) and the Cache type to
Cache on device hard drive, as shown in Figure 8-24. Click OK.
Figure 8-24 Provisioning vDisk mode
17.After making these adjustments, power on your VM. After you log on, go to
the D: drive to see the vdiskcache file that is created, as shown in
Figure 8-25.
Figure 8-25 Write cache file verification
Before you create your new VMs to deliver to the users, you must clone your gold
image in a VMware template. For the procedure to create a template, see this
website:
http://bit.ly/1atCyR5
Now, you are ready to create your new desktops integrating the XenDesktop and
Provisioning Services. The next section shows how to create the desktop
catalogs and associate them for your domain users.
8.2.2 Preparing the gold image for persistent desktops
Dedicated desktops are provided directly by XenDesktop Controller integrated
with a VMware environment.
The persistent desktop model uses Machine Creation Services instead of
Provisioning Services to provision the desktop image. Therefore, you need to
create a separate gold image for dedicated desktops.
Note: From this point, any modification that you perform is lost after the VM
restarts.
Use the following procedure to create a gold image for dedicated desktops:
1. After inserting the Citrix XenDesktop 5.6 installation media, the AutoRun
window opens, as shown in Figure 8-26. Select Install Virtual Desktop
Agent.
Figure 8-26 Virtual Desktop Agent installation
2. Select Advanced Install, as shown in Figure 8-27.
Figure 8-27 Deployment method
3. This installation does not test graphical applications, so we install the regular
Virtual Desktop Agent. Select Virtual Desktop Agent and click Next
(Figure 8-28).
Figure 8-28 Select the Virtual Desktop Agent
4. Select Citrix Receiver and click Next (see Figure 8-29). The Citrix Receiver
configuration is applied by using Group Policy Object (GPO), as described in
8.3, Configuring desktop distribution on page 336.
Figure 8-29 Component selection
5. For dedicated desktops, the personal vDisk is not used. Select No, dont
enable personal vDisk right now, as shown in Figure 8-30. Click Next.
Figure 8-30 Personal vDisk Configuration
6. Specify the location of the XenDesktop Controller to which the Virtual
Desktop Agent will register, as shown in Figure 8-31. Click Next.
Figure 8-31 Controller Location
7. Select Optimize XenDesktop Performance, User Desktop Shadowing,
and Real Time Monitoring, as shown in Figure 8-32, and click Next.
Figure 8-32 Virtual Desktop Configuration
Note: In this environment, the Windows Firewall service is disabled. If you
need to use the Windows Firewall services, you must ensure that the
required traffic for the required ports is allowed.
8. Figure 8-33 shows the installation summary. Click Install.
Figure 8-33 Installation Summary
Now, your gold image for persistent desktops is ready.
For the configuration at the Desktop Studio to create and publish dedicated
desktops, see 8.3.3, Configuring persistent desktops on page 367.
8.3 Configuring desktop distribution
The process to create desktop catalogs consists of creating a group of VMs
based on the gold image that you created and making these VMs accessible to
the users.
In this environment, we create three types of desktop catalogs:
Non-persistent streamed desktops
The catalog is desktop streamed at Citrix Desktop Studio. You create a catalog
with a predetermined number of desktops integrated with Provisioning
Services and associated to a group of users.
These desktops are available for use, but they are not fixed for these users.
When the users log off and log on again, they can log on to any available
desktop in the catalog.
From a management perspective, if you modify your vDisk that is stored on
Provisioning Services (PVS) and release it for production, the next time that
your desktops restart, this new version is available for use.
Non-persistent streamed with the personal vDisk desktops
The non-persistent streamed with personal vDisk (pvDisk) desktops are
similar to the first catalog (they are integrated with Provisioning Services).
However, in this catalog, a new disk is created and associated with each
desktop. On this disk, all customizations made by the users are stored to be
available after the machine is restarted.
Another difference is that the desktop is associated to the user that logs on for
the first time and is always associated with this user.
Persistent desktops
Persistent (or dedicated) desktops consist of virtual desktops created by
Machine Creation Services based on a template that is stored on your
hypervisor.
This procedure creates a predetermined number of desktops that are
available to a specific group of users.
When the user logs on to the desktop for the first time, the user is associated
with this desktop and always uses this desktop.
From an administrative perspective, these desktops are not integrated with
PVS, and new update requirements for security patches or business
applications must be performed with the additional tools. For more
information, see Endpoint Security and Compliance Management Design
Guide Using IBM Tivoli Endpoint Manager, SG24-7980.
Note: Because these desktops are non-persistent, any customizations
made by the user will be lost after the machine is restarted.
8.3.1 Configuring streamed desktops
The process to configure the streamed desktop catalog starts at the Provisioning
Services Console where you create the catalog and target devices. Then, the
process finishes at the Desktop Studio where you grant the permission for a
domain group to access these desktops.
Use the following procedure to configure this catalog:
1. In the Provisioning Services Console, create a new device collection by
selecting Farms Sites your site name Device Collections, as
shown in Figure 8-34. Enter the collection name and a description. Click OK.
Figure 8-34 Device collection creation
2. After you create the device collection, run the XenDesktop wizard by
right-clicking the site name that you created and selecting XenDesktop
Setup Wizard, as shown in Figure 8-35.
Figure 8-35 XenDesktop Setup Wizard
3. In the initial XenDesktop Setup window (Figure 8-36), click Next.
Figure 8-36 XenDesktop Setup wizard initial window
4. Specify the address of your XenDeskop Controller, as shown in Figure 8-37.
Click Next.
Figure 8-37 XenDesktop Controller configuration
5. The wizard connects to your VMware vCenter to load the defined templates.
Select your vCenter and click Set Template, as shown in Figure 8-38.
Figure 8-38 vCenter selection
6. Enter your user name and password in the Username and Password fields
and click Log On, as shown in Figure 8-39.
Figure 8-39 vCenter logon
7. Select a VM template and click OK, as shown in Figure 8-40.
Figure 8-40 VM template selection
8. Select the device collection that was created in Figure 8-34 on page 338 and
confirm the vDisk, as shown in Figure 8-41. Click Next.
Figure 8-41 Device Collection selection
9. Define the parameters to create the catalog in XenDesktop Controller, as
shown in Figure 8-42:
Machine type: Streamed
Catalog name: Specify the catalog name to be displayed in Desktop
Studio.
Description: Specify a description for the catalog that is created.
Click Next.
Figure 8-42 XenDesktop catalog creation
10.Define the following settings, as shown in Figure 8-43:
Number of virtual machines to create: Select the number of desktops to
create.
VM characteristics:
vCPUs: Select the number of vCPUs.
Memory: Select the amount of memory.
Active Directory computer accounts: Select whether new computer
accounts are created or existing accounts are reused (imported).
Click Next.
Figure 8-43 Virtual machine preferences
11.To create new Active Directory computer accounts, specify the Active
Directory location for the computer accounts and the account naming scheme
to create these accounts, as shown in Figure 8-44. Click Next.
Figure 8-44 Active Directory accounts and location
12.At the Summary window, click Finish (Figure 8-45).
Figure 8-45 Summary window
13.The wizard creates new VMs at VMware, the target devices at the
Provisioning Server, and the computer accounts at the Active Directory
(Figure 8-46).
Figure 8-46 Execution process
14.Confirm the operation by refreshing the device collection that you created.
Select Provisioning Services Console your site name Device
Collections Streamed_Desktops. Right-click to select Refresh.
Figure 8-47 shows the collection.
Figure 8-47 Target device list
15.In the Desktop Studio, confirm the creation by selecting Desktop Studio
Machines. Right-click to select Refresh. Figure 8-48 shows the result.
Figure 8-48 Machine catalog
16.The next step is to associate the machine catalog that was created with a
domain users group. When this group accesses the Web Interface, these
desktops will display. In the Desktop Studio, right-click Assignments and
then select Create Desktop Group, as shown in Figure 8-49.
Figure 8-49 Create Desktop Group
17.Select the desktop catalog that you created, and then, select how many
desktops will be available for the users, as shown in Figure 8-50. Click Next.
Figure 8-50 Catalog configuration
18.Select the domain group that will have access to these desktops, as shown in
Figure 8-51 Domain users group selection
19.Define a specific group to which to delegate the administrative privileges to
manage the desktop groups, as shown in Figure 8-52. Click Next.
Figure 8-52 Delegation settings
20.Type a display name and a desktop group name, as shown in Figure 8-53.
Click Finish.
Figure 8-53 Desktop group summary
21.The new desktops that are created on VMware are powered on and will
register their Virtual Desktop Agents to the XenDesktop Controller to be
available for users. Confirm this process by right-clicking Assignments and
then selecting Refresh. Figure 8-54 shows the result.
Figure 8-54 Desktop group status
8.3.2 Configuring streaming desktops with personal vDisk
The process to configure the streamed desktop with personal vDisk is similar to
configuring streaming desktops. The main difference is that to create streaming
desktops with personal vDisk, the wizard creates an additional disk to store the
users customization.
Use the following procedure to configure streaming desktops with personal
vDisk:
1. At the Provisioning Services Console, create a new device collection by
selecting Farms/Sites your site name Device Collections.
2. Specify a name and description for the device collection, as shown in
Figure 8-55. Click OK.
Figure 8-55 Device collection creation
3. After you create the device collection, run the XenDesktop wizard by
right-clicking your site name and selecting XenDesktop Setup Wizard, as
Figure 8-56 XenDesktop Setup Wizard
4. In the initial XenDesktop Setup window that is shown in Figure 8-57, click
Next.
Figure 8-57 XenDesktop Setup wizard initial window
5. Type the name of your XenDeskop Controller, as shown in Figure 8-58. Click
Next.
Figure 8-58 XenDesktop Controller configuration
6. The wizard connects to your VMware vCenter to load the defined templates.
Select your vCenter and click Set Template, as shown in Figure 8-59.
Figure 8-59 vCenter selection
7. For the Username and Password fields, type your username and password.
Click Log On, as shown in Figure 8-60.
Figure 8-60 vCenter logon
8. Select a VM template, and click OK, as shown in Figure 8-61.
Figure 8-61 VM selection
9. Define your preferences to create the catalog in XenDesktop Controller, as
shown in Figure 8-62:
Machine type: Select Streamed with personal vDisk.
Catalog name: Type the catalog name to be displayed in Desktop Studio.
Description: Type a description for the catalog that is created.
Click Next.
Figure 8-62 Desktop group settings
10.Define the following settings, as shown in Figure 8-63:
Select the number of virtual machines to create (how many desktops will
be created).
Select the number of vCPUs.
Select the amount of memory.
For the Personal vDisk size field, select how much space to allocate for
this disk. This decision affects the storage requirements.
For the Personal vDisk drive letter field, select the pvDisk letter that will be
associated with the VM.
For Active Directory computer accounts, select whether to create new
accounts or import (reuse) existing accounts.
Click Next.
Figure 8-63 VM characteristics
11.To create new computer accounts at the Active Directory, define the location
where these accounts will be created and the naming scheme to use to
create these accounts, as shown in Figure 8-64. Click Next.
Figure 8-64 Active Directory location and computer naming scheme
12.At the Summary window, click Finish (Figure 8-65).
Figure 8-65 Wizard Summary
13.The wizard creates new VMs at VMware, the target devices at the
Provisioning Server, and the computer accounts at the Active Directory
(Figure 8-66). Click Done.
Figure 8-66 VM Setup process
14.The next step is to associate the machine catalog that you created with a
domain users group. When this group accesses the Web Interface, these
desktops will display. In Desktop Studio, right-click Assignments. Then,
select Create Desktop Group, as shown in Figure 8-67.
Figure 8-67 Create Desktop Group
15.Select the desktop catalog that you created. Then, define how many desktops
will be available for the users, as shown in Figure 8-68. Click Next.
Figure 8-68 Catalog configuration
16.Select the domain group to have access to these desktops, as shown in
Figure 8-69 User group selection
17.Define a specific group to which to delegate the administrative privileges to
manage the desktop groups, as shown in Figure 8-70. Click Next.
Figure 8-70 Delegation permission
18.Specify a name and description for the desktop group, as shown in
Figure 8-71. Click Finish.
Figure 8-71 Desktop group summary
19.The new desktops that are created on VMware are powered on. They will
register their Virtual Desktop Agents to the XenDesktop Controller to be
available for users. Confirm this process by right-clicking Assignments and
then selecting Refresh. Figure 8-72 shows the result.
8.3.3 Configuring persistent desktops
Use Desktop Studio to configure the collection for persistent desktops by using
the gold image that was created in 8.2.2, Preparing the gold image for persistent
desktops on page 328.
Use the following procedure to create the desktop collection and publish the
collection for your users:
1. In Desktop Studio, right-click Machines, and select Create Catalog.
2. Select Dedicated as the Machine Type, and click Next, as shown in
Figure 8-73.
Figure 8-73 Collection type
3. Select the gold image that was created in 8.2.2, Preparing the gold image for
persistent desktops on page 328, as shown in Figure 8-74. Click Next.
Figure 8-74 Select Master Image
4. Select the number of virtual desktops to create. Select the number of vCPUs
and the amount of memory to allocate for these desktops, as shown in
Figure 8-75. Select Create new accounts. Click Next.
Figure 8-75 VM characteristics
5. Select the domain and then select the organizational unit (OU) and the
account naming scheme for the new desktops, as shown in Figure 8-76. Click
Next.
Figure 8-76 Active Directory specifications
6. Define a specific group to delegate the administrative privileges to manage
this desktop group, as shown in Figure 8-77. Click Next.
7. Type a name for the new catalog, as shown in Figure 8-78. Click Finish.
Figure 8-78 Desktop catalog name
8. After the process concludes, confirm the creation of your new desktops.
Right-click Machines in the Desktop Studio and select Refresh (the result is
shown in Figure 8-79).
Figure 8-79 Catalog status
8.3.4 Assigning a catalog to a group
After you create the catalog, you need to assign the new catalog to a group of
users that will access these desktops.
Use the following procedure to assign a catalog to a group:
1. In Desktop Studio, right-click Assignments and select Create Desktop
Group.
2. Select the catalog that you created in the previous procedure and specify how
many virtual desktops will be available to the users, as shown in Figure 8-80.
Click Next.
Figure 8-80 Machine assignment
3. Select the domain group that will have access to these desktops and how
many desktops will be available to the users, as shown in Figure 8-81. Click
Next.
Figure 8-81 User permission
4. Define a specific group to which to delegate administrative privileges, as
5. Enter a display name and a desktop group name for the new group, as shown
in Figure 8-83. Click Finish.
Figure 8-83 Group name
After the process completes, confirm that the new virtual desktops are available
to the users, as shown in Figure 8-84.
8.4 Roaming profiles and folder redirection
Defining roaming user profiles is an important part of the VDI configuration
because it allows profiles to be stored in a centralized server. When a user logs
on from a different desktop, that users profile is loaded.
The concept is similar for folder redirection. Redirection occurs to the same
centralized server for accessing personal folders, such as My Documents,
Favorites, and Desktop, is important for three main reasons:
If the user logs on from a different desktop.
If the administrator modifies the desktop image, the users files are not lost
because the files are stored on a centralized server.
For business applications, you can redirect the application settings folder to
the same centralized server, and the configuration is loaded without
reconfiguring.
To configure the roaming profile and folder redirection, we used the Group Policy
on the Active Directory to centralize the configuration and to apply it at the
organizational unit (OU) level to standardize the configuration for the
environment.
The following sections describe the procedures for implementing roaming
profiles and folder redirection.
8.4.1 Configuring the roaming profile
To initiate roaming profile functionality, we used the Citrix Profile Manager UPM
installed on the desktop gold image and on the Citrix XenApp servers. Citrix
provides an administrative template (ADM) that needs to be imported on the
Group Policy Object to configure how the Profile Manager works.
Use the following procedure to configure the GPO:
1. After you create a new GPO, import the Citrix Profile Manager ADM template
(Figure 8-85).
Figure 8-85 GPO ADM template import
2. Obtain the template, a subfolder named GPO_Templates, which is in the Profile
Manager installation folder (see Figure 8-86).
Figure 8-86 ADM file location
3. On the Add/Remove Templates window, confirm the ADM template, as shown
in Figure 8-87.
Figure 8-87 ADM template list
4. After the import procedure, you need to customize the template according to
your requirements. For this implementation, the Citrix Profile Manager is
configured to process all logons from a group called UPMUsers and to store
the users profiles at a centralized file server. On Figure 8-88, we selected
UPM_FolderRedirectionGPO Policy Computer Configuration
Policies Administrative Templates: Policy definitions (ADMX files)
Classic Administrative Templates (ADM) Citrix Profile Management
to find the new Profile Management section.
Figure 8-88 Citrix Profile Manager - Policies
5. The first parameter to enable is the User Profile Manager (UPM) process
(Figure 8-89).
Figure 8-89 Enable Citrix Profile Management
6. Next, determinate the group that the UPM will process. In our scenario
environment, a group named UPMUsers was created to filter the users that
need to process the UPM. Figure 8-90 shows this configuration.
Figure 8-90 Domain group filter
7. Figure 8-91 shows the exception that was created to not process the local
administrators logon, which is helpful when troubleshooting.
Figure 8-91 Disable the administrators profile process
8. The next configuration defines where the profiles will be created. In our
scenario, we created a file share on a centralized server to store the profiles.
We used the variable #SAMAccountName# to create the profile folder according
to the username (Figure 8-92).
Figure 8-92 Define centralized profile store
9. The active write back is enabled to reduce the time of synchronization during
the logoff (Figure 8-93).
Figure 8-93 Active write back configuration
10.The next configuration sets how the UPM processes the user if the user
already has a local profile at the desktop. In our scenario, we delete the local
profile and load the profile from the central file server (Figure 8-94).
Figure 8-94 Local profile conflict handling configuration
11.Next, configure the location of the template profile. UPM uses this template
folder to create new profiles. The second part of configuration specifies for
UPM that the template will overwrite the existing local and roaming profiles
(Figure 8-95).
Figure 8-95 Template profile configuration
12.Next, enable profile streaming. The streaming profile feature loads the users
profile when it is needed. This feature can reduce the logon time for users
(Figure 8-96).
Figure 8-96 Streaming profile configuration
13.Enable the UPMUsers profile group so that their profiles are processed by
using the streaming profile feature (Figure 8-97).
Figure 8-97 Streaming profile filter
8.4.2 Configuring folder redirection
The folder redirection policy is responsible for moving the default location of the
important users folders from the local disk to a centralized store. Examples of
these folders are My Documents, Favorites, and Desktop.
By configuring the folder redirection policy, when the users create a new favorite
link, this link will be available if this user logs on to a different desktop.
In our scenario, we use the same GPO to configure both UPM and folder
redirection. The following procedure shows how to configure folder redirection:
1. Figure 8-98 shows the location to access the folder redirection policies.
Figure 8-98 Folder Redirection policy location
2. Figure 8-99 shows the parameters to redirect the Desktop folder. We specified
the centralized file server using the same location and domain group used to
configure the UPM.
Figure 8-99 Desktop folder redirection configuration
3. We used a similar configuration to redirect the Documents, Favorites, and
Contacts folders. See Figure 8-100, Figure 8-101 on page 393, and
Figure 8-102 on page 394.
Figure 8-100 Documents folder redirection configuration
Figure 8-101 Favorites folder redirection configuration
Figure 8-102 Contacts folder redirection configuration
8.4.3 Configuring the Citrix Receiver
To automatically configure Citrix Receiver or Online Plug-in with the Web Server
Address on client computers, use Group Policy Preferences to create the
necessary registry key.
After creating the key, you must link this GPO to all organizational units (OUs)
where you have your virtual desktop accounts.
Follow these steps:
1. Create a new or modify an existing GPO and go to Computer
Configuration Preferences Windows Settings Registry New
Registry Item, as shown in Figure 8-103.
Figure 8-103 Group policy editor
2. Specify the following parameters for the new registry key, as shown in
Figure 8-104:
Action: Replace
Hive: HKEY_LOCAL_MACHINE
Key Path:
32-bit client computers: SOFTWARE\Citrix\PNAgent
64-bit client computers: SOFTWARE\Wow6432Node\Citrix\PNAgent
Value name: ServerURL
Value type: REG_SZ
Value data: http://your web interface server
hostname/Citrix/PNagent/config.xml
Click OK.
Figure 8-104 New registry key properties
3. After refreshing the GPO, check the Citrix Receiver configuration by
accessing your virtual desktop after clicking Start Apps published
your applications, as shown in Figure 8-105.
Figure 8-105 Accessing published applications at the virtual desktop
8.4.4 Group Policy Object link
The GPO created was linked on a specific OU created to store all computer
accounts created for VDI. Figure 8-106 shows the structure created to store
these desktop computer accounts.
Figure 8-106 Organization units for XenDesktop accounts
The GPO created was linked on three OUs:
XenApp Computers
The OU created to store the XenApp servers. The GPO was linked to this OU
to ensure that when users open an application published on XenApp, the
same profiles are loaded and the users folders are available to open files.
XenDesktop NonPersistents
The OU created to store non-persistent computer accounts. The GPO was
linked to ensure that all virtual desktops will receive the same settings for
UPM and folder redirection.
XenDesktop Persistents
The OU created to store persistent computer accounts. The GPO was linked
to ensure that all virtual desktops will receive the same settings for UPM and
folder redirection.
Note: An OU to store the gold image was created in order to not apply these
settings on the gold image, but only for production desktops.
Figure 8-107 shows the GPO linked on these three OUs.
Figure 8-107 Group policy link
8.4.5 Configuring application distribution
In this scenario, the business applications are not installed on the desktop base.
All applications are centralized at Citrix XenApp and delivered to desktops by
using the Citrix Receiver that was installed and configured in previous sections.
8.5 Monitoring health
Monitoring hardware and software in the VDI environment by using IBM Flex
System Manager is described.
For more information about IBM Flex System Manager, see Implementing
Systems Management of IBM PureFlex System, SG24-8060.
The following tasks are covered:
8.5.1, Hardware monitoring on page 399
8.5.2, Hypervisor monitoring on page 400
8.5.3, Monitoring performance with VMControl on page 401
8.5.4, Relocating the Virtual Server with VMControl on page 403
8.5.5, Host Maintenance Mode with VMControl on page 407
8.5.1 Hardware monitoring
IBM Flex System Manager provides features to monitor hardware.
When you connect on the FSM interface, in the upper-right corner of the window,
FSM informs you of any active critical and warning problems that are detected,
as shown in Figure 8-108. Click the Problems icon to see the problem details.
Figure 8-108 Active problem detected on FSM welcome window
IBM FSM Explorer provides a graphical view of the chassis. In the Hardware
Map, it highlights the components in red where problems are detected, as shown
in Figure 8-109. Click the related components to see the problem details.
Figure 8-109 FSM Explorer - Hardware Map
8.5.2 Hypervisor monitoring
Use FSM Explorer to monitor the CPU utilization of each host, as shown in
Figure 8-110.
Figure 8-110 Hosts monitoring
8.5.3 Monitoring performance with VMControl
VMControl provides the ability to manage and monitor the virtualized
environment, as shown in Figure 8-111.
Figure 8-111 VMcontrol overview
Generate a performance summary to gather CPU utilization on a specific host or
virtual server. Use the following procedure to generate a performance summary
for all servers on a host:
1. Select Performance Summary in the Common Tasks panel.
2. Select a host server, and click Add. The host is now selected, as shown in
Figure 8-112. Click OK.
Figure 8-112 Launch Performance Summary job
3. The wizard asks whether you want to select all of the virtual servers for the
host server that you selected. Click OK.
The Performance Summary is displayed, as shown in Figure 8-113.
Figure 8-113 Processor Performance Summary results
8.5.4 Relocating the Virtual Server with VMControl
VMControl enables you to relocate the Virtual Server from one host to another.
Before this feature, source and destination hosts had to be in the same VMware
Distributed Resource Scheduler (DRS) cluster.
Use the following procedure to relocate the Virtual Server:
1. In the Virtual Servers and Hosts table, select the Virtual Server to relocate,
right-click to display the menu, and select Availability Relocate, as shown
in Figure 8-114.
Figure 8-114 Relocate Virtual Server menu
2. After the Relocate wizard starts, confirm the source virtual server to relocate
and then click Next, as shown in Figure 8-115.
Figure 8-115 Virtual Server source selection
3. Select the target host to which the virtual server will be relocated, and then
click Next, as shown in Figure 8-116.
Figure 8-116 Target selection
4. Select Relocate only and click Next, as shown in Figure 8-117.
Figure 8-117 Save plan selection
5. Validate your choices and then click Finish, as shown in Figure 8-118.
Figure 8-118 Relocate wizard summary
8.5.5 Host Maintenance Mode with VMControl
VMControl allows you to set a host in Maintenance Mode. If the host is part of a
VMware DRS cluster, the virtual servers hosted on it will be relocated on the
other host within the cluster.
Use the following procedure to set a host in Maintenance Mode:
1. In the Virtual Servers and Hosts view, select a host, click Actions, and select
Availability Enter Maintenance Mode, as shown in Figure 8-119.
Figure 8-119 Enter Maintenance Mode action
2. Schedule the task to run now, and click OK. The host enters Maintenance
Mode.
3. To exit from maintenance mode, select the host, click Actions, and select
Availability Exit Maintenance Mode, as shown in Figure 8-120.
Figure 8-120 Exit Maintenance Mode action
Then, schedule the task to run now, and click OK. The host exits maintenance
mode.
AD Active Directory
ATMs Automated teller machines
ATS Advanced Technical Skills
BE3 BladeEngine 3
BYOD Bring-your-own-device
CAD Computer-aided design
CIFS Common Internet File System
CIM Common Information Model
CMM Chassis Management Module
COM Component Object Model
DCOM Distributed component object
model
DDC Desktop Delivery Controller
DPM Distributed Power
Management
DRS Distributed Resource
Scheduler
FSM Flex System Manager
FT Fault tolerance
FoD Features On Demand
GPO Group Policy Object
GPUs Graphics processing units
GUI Graphical user interface
HA High availability
HDDs Hard disk drives
HVD Hosted virtual desktop
IBM International Business
Machines Corporation
ICA Independent Channel
Architecture
IMM2 Integrated Management
Module II
IOP Input/output operation
Abbreviations and acronyms
IPC Interprocess communication
ITSO International Technical
Support Organization
JF Jumbo frames
LAN Local area network
LOM LAN-on-motherboard
LRO Large receive offload
LUN Logical unit number
MCS Machine Creation Services
MDisk Managed disk
MSDE Microsoft Data Engine
MSRP Microsoft Roaming Profile
MSRPs Microsoft Roaming Profiles
NAS Network-attached storage
NFS Network File System
NIC Network interface card
NPIV N_Port ID virtualization
OU Organizational unit
OUs Organizational units
PVS Provisioning Services
RA Reference Architecture
SAN Storage area network
SAS Serial-attached SCSI
SEN Storage Expansion Node
SLC Single level cell
SLP Service Location Protocol
SNIA Storage Networking Industry
Association
SNMP Simple Network Management
Protocol
SSDs Solid-state drives
SSH Secure Shell
TCO Total cost of ownership
TOE TCP offload engine
TSO TCP segmentation offload
UIM Upward Integration Module
VDA Virtual Desktop Agent
VLAN Virtual LAN
VM Virtual machine
VMs Virtual machines
eMLC Enterprise multi-level cell
pNIC Physical NIC
pvDisk Personal vDisk
vDisk Virtual disk
vNIC Virtual NIC
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this book.
IBM Redbooks
The following IBM Redbooks publications provide additional information about
the topic in this document. Note that some publications referenced in this list
might be available in softcopy only.
Implementing Systems Management of IBM PureFlex System, SG24-8060
IBM PureFlex System and IBM Flex System Products and Technology,
SG24-7984
IBM Flex System Networking in an Enterprise Data Center, 2nd Edition,
REDP-4834
IBM SmartCloud Desktop Infrastructure: Citrix XenDesktop on IBM Flex
System, TIPS0928
You can search for, view, download or order these documents and other
Redbooks, Redpapers, Web Docs, draft and additional materials, at the following
website:
ibm.com/redbooks
Online resources
These websites are also relevant as further information sources:
IBM Reference Architecture for SmartCloud Desktop Infrastructure
http://ibm.co/186BJt7
IBM Reference Architecture for Citrix XenDesktop
http://ibm.co/150EytE
Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
(
0
.
5

s
p
i
n
e
)
0
.
4
7
5
<
-
>
0
.
8
7
5
2
5
0

<
-
>

4
5
9

p
a
g
e
s
I
m
p
l
e
m
e
n
t
i
n
g

C
i
t
r
i
x

X
e
n
D
e
s
k
t
o
p

o
n

I
B
M

F
l
e
x

S
y
s
t
e
m
SG24-8163-00 ISBN 0738438952

INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks
Implementing
Citrix XenDesktop on
IBM Flex System
Introduces IBM Flex
System and
Citrix XenDesktop
offerings
Discusses design
and deployment
considerations
Provides
step-by-step
configuration
guidance
The IBM SmartCloud Desktop Infrastructure offers robust,
cost-effective, and manageable virtual desktop solutions for a wide
range of clients, user types, and industry segments. These solutions
help to increase business flexibility and staff productivity, reduce IT
complexity, and simplify security and compliance. Based on a
reference architecture approach, this infrastructure supports
various hardware, software, and hypervisor platforms.
The SmartCloud Desktop Infrastructure solution with Citrix
XenDesktop running on IBM Flex System offers tailored solutions for
every business, from the affordable all-in-one Citrix VDI-in-a-Box
for simple IT organizations to the enterprise-wide Citrix XenDesktop.
XenDesktop is a comprehensive desktop virtualization solution with
multiple delivery models that is optimized for flexibility and
cost-efficiency.
This IBM Redbooks publication provides an overview of the
SmartCloud Desktop Infrastructure solution, which is based on Citrix
XenDesktop running on IBM Flex System. It highlights key
components, architecture, and benefits of this solution. It also
provides planning and deployment considerations, and
step-by-step instructions about how to perform specific tasks.
This book is intended for IT professionals who are involved in the
planning, design, deployment, and management of the IBM
SmartCloud Desktop Infrastructure built on IBM Flex System running
Citrix XenDesktop.
.
Back cover

Ibm and Xendesktop Xenapp

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ibm and Xendesktop Xenapp

Uploaded by

Copyright:

Available Formats

ibm.

98 Implementing Citrix XenDesktop on IBM Flex System

SG24-8163-00 ISBN 0738438952

You might also like