VMware Reference Architecture Horizon 6 View Mirage Workspace

VMware Horizon 6
Reference Architecture
T E C H N I C A L W H I T E PA P E R
VMware Horizon 6 Reference Architecture
Table of Contents
Executive Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Workload Test Result Highlights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
VMware Reference Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Horizon 6 Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Hardware Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Software Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
VMware vSphere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
VMware Horizon 6 with View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Horizon 6 Reference Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Modular Pod and Block Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Horizon Pod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Management Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Desktop Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Software-Defined Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Storage Sizing for Server Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Storage Sizing for Desktop Workloads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Virtual Desktop Storage Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Virtual Desktop Storage Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ESXi Hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
CPU Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Virtual Desktop Memory Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
RDSH Memory Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
VMware vCenter Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
VMware vSphere Clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Virtual Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
VMware vRealize Operations for Horizon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
/ 2
Unified Access with Workspace Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Windows Desktops and Remote Applications with View . . . . . . . . . . . . . . . . . . . . . . . 34
Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Virtual Desktop Machine Image Build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Remote Desktop Services Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Single Image Management with Mirage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

User Experience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Blast Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
PCoIP Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Persona and User Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Desktop Persistence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Active Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
VMware SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Windows File Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Test Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Functional Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Workload Testing RDSH Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Mirage Operations Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Test: Assign an Updated Base Layer to Full-Clone Virtual Desktops . . . . . . . . . . . . . 56
Appendix A: Bill of Materials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Appendix B: View Planner 3.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

View Planner Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Run Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Quality of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
/ 3
Executive Summary
This reference architecture provides guidance for implementing a VMware Horizon 6 deployment that supports
2,00010,000 users with an existing server and storage infrastructure. Although hardware is specified for 2,000
users, you can scale the deployment up to 10,000 users using the pod and block architecture approach.
This reference architecture combines the technologies of standard rack mount server hardware running on
EMC VNX storage leveraging View Storage Accelerator (to accelerate existing SAN) with VMware ESXi 5.5
and Horizon 6 software to produce a highly efficient, robust, and scalable next-generation virtual workspace
deployment. This document includes information on View, VMware Mirage 5.0, and VMware Workspace
Portal 2.1 running on top of VMware vSphere 5.5.
120 Users per

ESXi Host
Consolidation Ratio
100 Users per

ESXi Host
Consolidation Ratio
Passed
Passed
per 16 core ESXi host for Remote

Desktop Services (RDS) apps
(light worker)
per 16 core ESXi host for View

virtual desktops (medium worker)
Access from Any Device

to applications and desktops
using VMware Horizon Client
Access from
Workspace Portal
to View desktops and applications
Passed
14 Minutes
Single Image Management

with dedicated virtual desktops
managed by Mirage
Set up Hosted Applications

and Virtual Desktops
Desktops and applications

delivered through a single platform
Streamline management and
easily entitle end users by delivering
virtual or remote desktops and
applications through a single
platform.
Unified workspace with great user
experience Securely provide a
consistent end-user experience
across devices, locations, media, and
connections.
Central image management Easily
manage physical, virtual, and bring
your own devices (BYOD).
Optimized for the software-defined
data center Dynamically allocate
resources with virtual storage,
computing, and networking to
simply and cost-effectively manage
and deliver desktop services on
demand.
from View Administrator
Figure 1: Solution Highlights
This document describes how to size and configure a solution that encompasses View, Mirage, and
Workspace Portal, as well as the VMware vCenter and vSphere core technologies. You can provision, manage,
and access hosted applications and virtual desktops from a single place quickly and efficiently. The example
solution supports 1,000 hosted application users, 800 stateless virtual desktop users, and 200 persistent virtual
desktop users. As part of the architecture validation, VMware performed functional, operational, and workload
tests to highlight how the entire software stack integrates to provide a complete virtual workspace solution.
T E C H N I C A L W H I T E PA P E R / 4
Workload Test Result Highlights

Horizon 6 harnesses the capabilities of Remote Desktop Services (RDS) to allow multiple users to connect to
a single Windows Server, but have individual desktop instances and applications. The user can connect to an
application or a full desktop using PC over IP (PCoIP) for a rich end-user experience.
Test highlights include the following results:
RDSH access using PCoIP and VMware View Planner office worker workload validated for 120 users per ESXi,
30 RDSH desktop sessions per RDSH server.
View Planner testing passed comfortably within operational latency thresholds.
ESXi average CPU usage was 71 percent, with a peak of 96 percent, and memory usage was 78 percent with a
peak of 79 percent.
RDSH server average CPU usage was 70 percent, with a peak of 96 percent, and average memory usage was
40 percent, with peak of 59 percent.
Peak of 218 IOPS per RDSH server; peak reads of 100 and peak writes of 167.
A single ESXi 5.5 host was provisioned with four Windows 2012 RDSH servers as a View RDSH desktop pool.
View Planner was used to simulate 120 end-user desktop sessions over PCoIP to the RDSH desktop pool and
carrying out office worker tasks.
The View Planner workload test performed five test run iterations. During this time, ESXi CPU usage averaged
71 percent, with a peak of 96 percent. The four RDSH servers averaged 70 percent CPU usage, with a peak of 96
percent.
Figure 2: ESXi and RDSH Server CPU Usage
The ESXi 5.5 host averaged 78 percent memory usage, with a peak of 79 percent throughout View Planner
testing. The four Windows 2012 RDSH servers averaged 40 percent memory usage, with a peak of 59 percent.
Figure 3: ESXi and RDSH Server Memory Usage
VMware Reference Architectures

VMware reference architectures, built and validated in the field by VMware and supporting partners, address
common use cases, such as enterprise desktop replacement, remote access, and disaster recovery. This
reference architecture guide helps customersIT architects, consultants, and administratorsinvolved in the
early phases of planning, designing, and deploying Horizon 6 solutions. It provides a standard and scalable
design that can be easily adapted to specific environments and customer requirements.
The reference architecture building-block approach uses common components to minimize support costs and
deployment risks. It is based on information and experiences from large VMware deployments that are currently
in production. It draws on best practices and integrates easily into existing IT processes and procedures.
VMware reference architectures offer customers
Standardized, validated, repeatable components
Scalable designs that allow room for future growth
Validated and tested designs that reduce implementation and operational risks
Quick implementation, reduced costs, and minimized risk
Horizon 6 Solution
The Horizon 6 virtual workspace solution combines the best-of-breed data center and desktop virtualization
technologies.
The high-level infrastructure consists of
ESXi hosts with a 2.1 GHz Intel E5-2658 or 2.9 GHz E5-2690 processor
128 GB RAM per ESXi host
EMC VNX5500based NFS storage (20 TB)
10 Gigabit Ethernet (GbE) networking
Windows 7 virtual machines with one vCPU and 1 GB vRAM
Microsoft Remote Desktop Session Host (RDSH) virtual machines with four vCPUs and 24 GB RAM
Thin Client
Mac OS
PC
Horizon
Clients
Kiosk
iOS/Android
View Security Servers
View Connection Servers
Workspace Portal vApp

File Print
Server
Mirage
Mgmt
Mirage
Servers
View RDSH Apps & Desktops
MS
SQL
Active
Directory
View Virtual Desktops

View
vCenter vRealize Operations
Composer
for Horizon
SSD
SSD
RDSH Cluster
Desktop Cluster
NFS Shared Storage
Management Cluster
HTTPS/PCoIP
DMZ (HTTPS/PCoIP)
PCoIP
ESX, vCenter, View, Mirage, AD traffic
NFS Storage
Figure 4: Horizon with View Components
Hardware Components
This section provides an overview of the hardware components of the architecture.
Extreme Summit x670 10GbE

Desktop & RD Session Hosts
5 x Supermicro 2027TR Chassis
11 x Supermicro X9DRT-HF
System Boards for VDI
System Boards for RDSH
16 Cores, 128 GB RAM
VDI &
RDSH VMs
EMC VNX 5500

Horizon 6 Server Workloads
Linked-Clone Desktops
Full-Clone Desktops
RD Session Hosts
User Profiles
User Data
ThinApp Repository
Mirage Single-Instance Store
Management Hosts
System Boards
- Horizon 6 Server Workload VMs
Figure 5: Hardware Components
Server
Supermicro SuperServer provides four hot-pluggable nodes in a 2U form factor. The system is ideal for running
virtualized and cloud computing environments in a highly dense form factor.
The Supermicro SuperServer system includes the following components:
Intel Xeon ES-2600 and ES-2600 v2 processor family
128 GB DDR3 ECC registered memory
Two 300 GB SSDs
Intel 82599EB 10 GB SFI/SFP+ dual-port interconnection for connectivity
Network
The Extreme Summit x670 series switches are versatile, purpose-built, top-of-rack switches that support the
emerging 10GbE-enabled servers in enterprise and cloud data centers.
Benefits include
High-density 10GbE switching in a small 1U form factor
Scalable, with up to 48 ports in a single system and up to 352 ports in a stacked system
Enterprise-ready High-availability ExtremeXOS operating system provides simplicity and ease of operation
by using a single OS throughout the network
Storage
All virtual desktops, virtual RDSH servers, management server virtual machines, user profiles, user data, and
Mirage storage use the EMC VNX5500 model for NFS storage. VNX5500 can hold 250 drives, scalable up to
480 TB. It has up to 12 GB system memory at the block level, with support for Fibre Channel (FC), iSCSI, and FC
over Ethernet (FCoE) connectivity. VNX5500 is suitable for those who want to take advantage of enterpriselevel storage at a lower TCO.
Note: This reference architecture assumes that the existing server platform, whether it is blade or rack-mount
server, cannot accommodate the VMware Virtual SAN hardware requirements, and therefore will use VNX
as the storage solution. Virtual SAN is a viable solution for Horizon 6. For more information, see the VMware
Horizon with View and Virtual SAN Reference Architecture.
Software Components
This section provides an overview of the software components of the architecture.
VMware vSphere
VMware vSphere is the industry-leading virtualization platform for building cloud infrastructures. It enables
users to run business-critical applications with condence and respond quickly to business needs.
VMware vSphere accelerates the shift to cloud computing for existing data centers and underpins compatible
public cloud offerings, forming the foundation for the industrys best hybrid cloud model.
VMware Horizon 6 with View
Horizon 6 delivers hosted virtual desktops and applications to end users through a single platform. These
desktop and application servicesincluding RDSH applications, packaged applications with VMware ThinApp,
software-as-a-service (SaaS) applications, and even virtualized applications from Citrixcan all be accessed
from one unified workspace across devices, locations, media, and connections. Leveraging closed-loop
management and optimized for the software-defined data center, Horizon helps IT control, manage, and
protect the Windows resources that end users want at the speed they expect and with the efficiency that
business demands.
Horizon 6 also provides the ability to manage both virtual and physical desktop images using VMware Mirage.
Mirage allows you to manage persistent, full-clone desktops.
Horizon 6 allows users to access desktops and applications via VMware Workspace Portal. Workspace Portal
also provides IT a central place to entitle and deliver Windows applications, desktops, SaaS applications,
ThinApp packaged applications, and XenApp applications to users.
T E C H N I C A L W H I T E PA P E R / 1 0
VMware Workspace Portal

SaaS Apps
ThinApp Repository
VMware Workspace
Portal VA
Core Infrastructure
Active
Directory
VMware Mirage
VMware Mirage
Servers
View
View Security
Server
Windows 7
Full Clone
Physical/Containerized
Desktops
vRealize
Operations
Manager
vCenter
Server
Windows 7
Linked Clone
View Connection
Server
View
Composer
Windows 7
3D Desktop
Full-Clone and Linked-Clone

Virtual Desktop Pools
RDSH-Hosted
Desktops and Applications
Figure 6: Horizon 6 Components
Horizon 6 Reference Architecture

The architecture leverages the benefits of the VMware software-defined data center (SDDC) stack to provide
an enterprise-class virtualization platform. Horizon with View for virtual desktops and hosted applications,
Workspace Portal for unified application and desktop access, and Mirage for single image management run
on top of the vSphere platform. The solution uses VMware vRealize Operations Manager to provide a single
point to monitor the health and performance of all components. In addition, the solution offers a best-of-breed
user experience through Blast Adaptive UX (including PCoIP and an HTML5 protocol) and a huge number of
supported clients.
Modular Pod and Block Design

This Horizon 6 reference architecture is based on the proven approach of scalable and modular pod and block
design principles. The View, Mirage, and Workspace Portal server workloads are placed in the management
block of a Horizon 6 pod. All desktop workloads are in the desktop block within the pod, with the separation of
desktop and RDSH server workloads maintained via distinct clusters and ESXi hosts.
Horizon 6 Pod
~1,000 Desktops
~1,000 RD Sessions
Desktop Block
Desktop Cluster
Desktop Cluster
View Desktop Pools
View RDSH
Desktop Pools
Shared Storage
Switched Ethernet Network
vCenter Server and View Composer
View Connection Server

View Security
Server
Mirage
Server
vRealize Operations
Manager
Mirage
Management
Server
Server Cluster
View Security
Server
Workspace
Portal
Horizon Management Block
Figure 7: Horizon Pod and Management Block
Horizon Pod
A Horizon pod is a logical administrative entity that can support up to 10,000 users or sessions. You can
increase that limit to 20,000 users or sessions using 24 pods. A pod contains a management block and one or
more desktop blocks. In this reference architecture, the pod supports 2,000 users or sessions.
Management Block
The management block contains all the Horizon server virtual machines.
In customer production deployments, VMware vCenter Server is typically deployed for every 2,000 virtual
desktops. VMware supports up to 10,000 desktop virtual machines in a single vCenter instance, but keeping to
2,000 desktops improves power and provisioning operation times.
VMware supports a maximum of 2,000 concurrent sessions per View Connection Server. An additional View
Connection Server is deployed for redundancy (n+1). Two additional View Connection Servers are paired with
View security servers to provide secure, redundant external access to View desktops. Each security server can
handle up to 2,000 connections.
A single Workspace Portal virtual appliance can scale to extremely high numbers (30,000 users); therefore
we recommend deploying a single instance. You can add virtual appliances for each component to provide
redundancy.
A single Mirage server can handle up to 1,500 managed desktops. You can use multiple Mirage servers to
provide redundancy. A Mirage Management server is also required to manage the Mirage servers and desktop
operations.
A single vRealize Operations Manager virtual appliance can handle up to 10,000 virtual desktops.
You can easily scale out each management component to support 10,000 users within a Horizon pod.
The management block has a single vSphere cluster that supports the Horizon server virtual machines shown in
Figure 8.
vSphere Cluster
vCenter Server
View
Composer
2x View
Security Server
2x Workspace Portal
VA
2x View (Int.)
2x View (Ext.)
Connection Server Connection Server
vRealize Operations
Manager UI VA
2x Mirage
Server
Mirage
Management
Server
vRealize Operations
Manager Analytics VA
SQL Server
Active
Directory
3x ESXi 5.5 Host

2.1 GHz. 128 GB RAM
2x 2 TB LUN
EMC VNX5500 NFS
TEMP, ISO LUN

EMC VNX5500 NFS
Figure 8: VMware vSphere Cluster
Desktop Blocks
In a standard View reference architecture design, a desktop block, delineated by a dedicated vCenter instance,
supports 2,000 concurrent sessions. You can architect multiple desktop blocks within a pod to support up to
10,000 concurrent sessions.
In this reference architecture, the desktop block supports 2,000 sessions1,000 virtual desktops and 1,000 RD
sessions, running on virtual RDSH servers.
The desktop block contains two vSphere clusters to isolate the differentiated workloads of hosted virtual
desktop instances from the RDSH server instances. One cluster supports 800 linked-clone and 200 full-clone
Windows 7 virtual desktops across 11 ESXi hosts. The other cluster supports 32 RDSH virtual machines on 9 ESXi
hosts, sized to support approximately 1,000 hosted application sessions running between 46 applications.
Linked-clone desktop workloads and RDSH virtual machines are stored on the VNX5500 presented as an NFS
datastore. Linked-clone desktops and RDSH servers are part of a pool of resources. If a host fails, users can be
quickly connected to an alternative desktop or server on another host. Shared storage also allows linked-clone
desktops and RDSH servers to be quickly recovered and run on another host in the cluster.
Full-clone desktops are also deployed on the VNX5500 NFS-based datastore. Using shared storage reduces the
impact of potential host failures for dedicated persistent desktop users.
Management Block
vCenter
ESXi Desktop
Cluster
Windows 7
Full-Clone Pool
200 Desktops
ESXi Desktop
Cluster
6x 2 TB LUN
EMC VNX5500
NFS
4x 1 TB LUN
EMC VNX5500
NFS
Windows 7
Linked-Clone Pool
800 Desktops
11x ESXi 5.5 Host

2.9 GHz, 128 GB RAM
32x Remote
Desktop Services
Host
TEMP, ISO LUNS

EMC VNX5500 NFS
9x ESXi 5.5 Host

2.9 GHz, 128 GB RAM
Figure 9: Desktop Block Logical Infrastructure Design
Software-Defined Data Center

Horizon leverages the VMware SDDC platform to ensure performance, security, manageability, scalability,
availability, and reliability.
Horizon 6
vSGA /
vDGA
CBRC
SE
Sparse
Disk
Linked
Clones
VAAI
Virtual
SAN
Network
Specifications
VMware vSphere
Availability
Application
Services
vMotion
Storage vMotion
HA
Fault Tolerance
Data Recovery
vCompute
Infrastructure
Services
ESX and ESXi

DRS and DPM
Memory
Overcommit
Security
vShield Zones
VMsafe
vStorage
VMFS
Thin Provisioning
Storage I/O Control
Scalability
DRS
Hot Add
vNetwork
Distributed Switch
Network I/O Control
Figure 10: Software-Defined Data Center Platform
Horizon benefits from proven vSphere features, such as a distributed resource scheduler, high availability,
VMware VMsafe, distributed vSwitch, thin provisioning, transparent page sharing, and memory compression.
Horizon also takes advantage of and integrates with several unique features within vSphere 5.5, including
View Storage Accelerator Host-based memory cache of the most commonly read disk blocks to help reduce
read I/O storms during boot or login events
Linked clones Single image management and storage optimization to reduce the desktop storage requirement
Space-efficient (SE) sparse disks Reclamation of unused disk blocks in linked clones, providing the ability to
manage the growth of linked clones over time
GPU virtualization Support for a wide range of 3D-based use cases, using both shared (vSGA) and
dedicated (vDGA) GPU virtualization
vSphere Storage APIs Array Integration Ability to offload virtual machine provisioning operations to a
storage array
Virtual SAN Storage layer abstraction and virtualization by pooling local storage resources into a virtual
shared storage array
In addition, Horizon can be managed and monitored using vCenter Server and vRealize Operations for Horizon.
Networking
The physical networking infrastructure is standardized on 10GbE. Each host includes a dual port 10GbE card
and a dual port 1GbE card. Each host is connected to a 10GbE Extreme Summit x670 Ethernet switch in its
associated rack. Each Extreme x670 switch is connected to a core 10GbE switch, providing connectivity across
racks. See the Virtual Networking section for more information on virtual machine networking. Configuring a
third-party firewall and load balancing are out of the scope of this reference architecture.
Storage
This reference architecture leverages an existing EMC VNX5500 storage system to host all linked-clone and fullclone desktops, RDSH servers, server workloads, user profiles, user data, and Mirage storage. Local solid-state
drives (SSD) were not used, but could be, for example, to host RDSH server workloads.
In any virtual desktop deployment, it is critical to use storage acceleration technologies for desktop
performance. Storage acceleration technologies include read/write cache, inline deduplication, I/O optimization,
I/O compression, and storage tiering. Storage acceleration can occur as part of the hypervisor or as part of the
storage solution. To reduce the read I/O requirements on the VNX, View Storage Accelerator caches read I/O
locally on the ESXi host. To reduce the capacity requirement for linked clones, the SE sparse disk format is used
to reclaim unused disk blocks.
Software-defined storage solutions, such as VMware Virtual SAN, can also reduce the impact on or need for
legacy SAN devices by performing acceleration at the ESXi host. Virtual SAN is a viable storage platform for
Horizon and many of the workloads described in this reference architecture. However, this architecture did not
use Virtual SAN to demonstrate how to use existing server platforms that might not support the Virtual SAN
hardware requirements. For more information on Horizon with View running on Virtual SAN, see the VMware
Horizon with View and Virtual SAN Reference Architecture.
Horizon Desktop Cluster
Horizon Management Cluster

2x 300 GB
SSD
10GbE
4x 1 TB
RD Session
Hosts
2x 300 GB
SSD
10GbE
2x 2 TB
All Servers
1x 490 GB ISO
1x 1 TB TEMP
6x 2 TB
Full Clones,
Linked Clones,
Linked-Clone
Replicas
EMC VNX5500
NFS
EMC VNX5500
NFS
Figure 11: Storage Options
Based on the powerful new family of Intel Xeon 5600 processors, the EMC VNX5500 implements a modular
architecture that integrates hardware components for object-based storage with concurrent support for native
network-attached storage, iSCSI, FC, and FCoE protocols. The series delivers file functionality via 28 X-blade
data movers and block storage via dual storage processors leveraging full 6Gb SAS disk drive topology.
The EMC VNX5500 has 20 TB of usable disk available. ISO (490 GB) and temp (1 TB) datastores are presented
to ESXi hosts across both clusters. In this reference architecture, VNX is configured to present two 2 TB
datastores via NFS to all hosts in the management cluster. It is also configured to present six 2 TB datastores via
NFS to all hosts in the desktop cluster and four 1 TB datastores to all hosts in the RDSH cluster.
Both the 2 TB and 1 TB datastores provide about 3,000 IOPS, based on the number of disks provided per
datastore. VNX caching features increase the number of IOPS that each datastore can deliver. Work with
your storage vendor to understand the datastores configuration, sizing, and IOPS capability. Keep in mind
the following sizing and performance calculations and that you need to size for peak average IOPS. When
consulting the storage vendor, ensure that the front-end IOPS requirement and the RAID-level impact on the
backend IOPS are understood.
Storage Sizing for Server Workloads
All server workloads running in the management block are hosted on the EMC VNX5500 array. The solution
uses 22 server virtual machines, vSphere components, and infrastructure services.
The server workloads require about 2 TB of disk for virtual machine disk format (VMDK) files. Each server
workload also requires swap files. The size of the swap file is equivalent to the amount of memory allocated to
the virtual machine. Virtual machine swap files total 272 GBno memory reservation is used. With an additional
20 percent overhead, the total disk requirement is 2.83 TB. The VNX presents two 2 TB NFS datastores to each
host in the management cluster, with room to add additional server workloads as necessary.
Storage Sizing for Desktop Workloads
Storage plays an important role in desktop performance and the user experience. The following tables provide
sample calculations for working out the capacity and performance requirements for datastores hosting desktop
workloads. The tables do not take specific storage optimization or acceleration technologies into consideration.
Consult your storage vendor to validate desktop storage sizing.
In many implementations, it is more important that the limit on the number of virtual machines per datastore
be influenced by the I/O requirements of the virtual machine and the spindle types. When considering the
number of virtual machines to place on a single datastore, consider the following factors in conjunction with
any recommended virtual machines per datastore ratio:
Types of disks used (SATA, SAS, SSD)
Typical virtual machine size (including configuration files, logs, swap files, snapshots)
Virtual machine workload and profile (specifically, the IOPS)
The following table shows the IOPS for two different types of disks, which affects the overall number of disks
required per datastore.
D I S K TY P E
SIZE
IOPS
15 K RPM SAS
600 GB
~150
SSD
300 GB
~1,500+
Table 1: Disk Properties
Virtual Desktop Storage Workload

When designing a storage solution, it is important to understand the I/O profile of the virtual machines that
will be placed on the storage. For instance, some applications are heavy on reads, some are heavy on writes,
some are heavy on sequential access, and some are heavy on random access. Although the profile can be
assumed based on application type, it is best to measure the I/O patterns before rolling out to a production
implementation. The profile dictates the RAID type to use.
This reference architecture uses an existing VNX SAN offering 2 TB datastores capable of about 3,000 IOPS
without caching. Based on this, the number of virtual machines per datastore was calculated to be 168, with
an 80/20 mix of linked-clone and full-clone desktops. The following table shows the storage calculations for
desktops on a per datastore basis. Numbers are always rounded up in these calculations.
ATTRI BUTE
VALU E
Virtual machines per datastore
168
IOPS per virtual machine (normal user)
10
IOPS per virtual machine (heavy user)
20
Total IOPS (80% normal user,

20% heavy user)
(135 x 10 IOPS) + (34 x 20 IOPS) =

1350 IOPS + 680 IOPS = 2030 IOPS
Average throughput per virtual

machine (normal user)
200 KBps (estimated)
Average throughput per virtual

machine (heavy user)
300 KBps (estimated)
Total throughput
(80% normal user, 20% heavy user)
(135 x 200 KBps) + (34 x 300 KBps) =

27,000 KBps + 10,200 KBps = 37,200 KBps (37.2 MBps)
RAID 5 penalty for writes
RAID 10 penalty for writes
Total IOPS required

(70% reads, 30% writes)
1421 + (609 x 4) = 3857 IOPS (RAID 5)

1421 + (609 x 2) = 2639 IOPS (RAID 10)
Total IOPS required

1015 + (1015 x 4) = 5075 IOPS (RAID 5)

1015 + (1015 x 2) = 3045 IOPS (RAID 10)
Total IOPS required

609 + (1421 x 4) = 6293 IOPS (RAID 5)

609 + (1421 x 2) = 3451 IOPS (RAID 10)
Table 2: Desktop Storage Performance Calculations
Note: Based on the read/write I/O split, the worst case during steady statenot boot or login stormis 6293
IOPS per datastore. The best case is 2639 IOPS per datastore.
You can use the total IOPS to calculate the number of disks required to back the datastore. For example, based
on the IOPS capability of the disks, between 1843 SAS hard-disk drives (HDD) would be required as compared
to just one or two SSDs. This number does not take storage caching or acceleration into account.
You can calculate RDSH workloads in a similar manner. The IOPS per RDSH user session can be between 310
for steady state.
Virtual Desktop Storage Capacity

Full-clone and linked-clone desktops share the same datastores, so the total datastore size is a combination of
both datastores.
ATTRI BUTE
S P ECIFICATION
Number of OS disks per

datastore
OS disk datastore size
DESCR IPTION
2 TB datastores offering 3,000 IOPS were already

provisioned. Based on storage performance calculations,
each datastore could accommodate 168 desktops, consisting
of 135 linked clones and 34 full clones.
At least 1.47 TB
Size is based on the following calculations:

Desktop size 40 GB (Windows 7)
Swap file size 256 MB (75% memory reservation)
Log file size (max) 10 MB
Free space allocation 10% additional overhead
Minimum allocated datastore size:
1.47 TB (34 virtual machines * (40960 +
256 +10) + 10% free space overhead
Total number of
datastores (based on
capacity)
1 per 34 virtual
machines
Six datastores required for 200 desktops. These are the

same datastores used for linked clones.
Hosts per datastore
11
All hosts in the desktop cluster have access to six NFS

datastores of 2 TB each, provided by the VNX.
Table 3: Full-Clone Desktop Datastore Sizing
The following table lists the datastore sizing calculations for linked clones.
ATTRI BUTE
S P ECIFICATION
DESCR IPTION
OS disks per datastore
64128 VMFS
140 with VAAI
250+ NFS
Based on best practices, 64 VMFS datastores is conservative,

while 128 is possible, depending on the IOPS of the physical
array and desktop performance expectations. More than 250
linked clones per datastore is possible with NFS. Maximum
of 512 linked clones per replica.
At least 376 GB

Master replica size 40 GB (Windows 7)
Swap file size 256 MB (75% memory reservation)
Page file 1024 MB
Maximum VMDK growth 1024 MB (optimistic)
376 GB (134 virtual machines * (256 + 1024
+ 10 + 1024) + 40 GB replica + 10% free
space overhead)
Swap file can be eliminated or reduced by reserving memory
for all virtual desktops.
ATTRI BUTE
S P ECIFICATION
DESCR IPTION
Total number of
capacity)
1 per 134 virtual

machines (NFS)
Six datastores required for 800 virtual machines.
Hosts per datastore
11 hosts per
datastore
For floating-pool linked clones, each host must have access

to each datastore hosting linked clones.
Table 4: Linked-Clone Desktop Datastore Sizing
The following table lists the datastore sizing calculations for RD Session Hosts.
ATTRI BUTE
S P ECIFICATION
Number of OS disks
per datastore
DESCR IPTION
1 TB datastores offering 3,000 IOPS were already

provisioned. Assuming 3 IOPS per RDSH session (known
light worker test I/O profile), the datastore can support
about 1,000 sessions. Given 120 sessions per RDSH, the
datastore can support 8 RDSH virtual machines.
At least 524 GB

Server size 40 GB (Windows Server 2012 R2)
Swap file size 24 GB
524 GB (8 virtual machines * (40960 +
24576 +10) + 10% free space overhead)
Spare capacity is available if RDSH servers need to be larger
than 40 GB.
Total number of
capacity)
1 per 8 virtual
machines
Four datastores required for 32 RDSH servers.
Hosts per datastore
All hosts in the desktop cluster have access to four NFS

datastores of 1 TB each, provided by the VNX.
Table 5: RDSH Datastore Sizing
ESXi Hosts
This architecture uses standard rack mount servers with dual socket, 8-core, 2.1 GHz or 2.9 GHz CPUs, and
128 GB RAM running ESXi version 5.5. The desktop and RDSH workloads use the 2.9 GHz hosts, and the
management workloads use the 2.1 GHz hosts.
The hosts are split into three clusters. The management cluster uses 3 hosts, the virtual desktop cluster uses 11
hosts, and the RDSH workload cluster uses 9.
Figure 12: ESXi Host Specification
VMware has conducted a number of performance and system tests to validate the scalability of View in terms
of desktop workloads. The results were used to size the hosts for this reference architecture. To determine
sizing calculations, it is recommended to assess your user workloads and CPU, memory, and disk I/O
requirements.
In this reference architecture, virtual desktop users are considered normal office workers, and RDSH users are
considered light office workers (five common applications).
CPU Sizing
Based on VMware testing, experience from field deployments, and industry analysis of RDSH sizing, this
reference architecture uses the recommended specification of four vCPU virtual RD Session Hosts with no CPU
overcommit.
This specification means that a 2-CPU, 8-core host with 16 physical cores can support up to 4 vCPU RD Session
Hosts on a single ESXi server. Our testing indicates that we can expect approximately 30 light office worker
sessions per RDSH.
1 x 4 vCPU virtual RD Session Host per 4 CPU cores / 16 cores = 4 RDSH per
ESXi host with 30 sessions per RDSH (120 sessions per ESXi host)
VMware testing and field experience shows that customers can expect anywhere from 510 1 vCPU virtual
desktops per physical core. For a normal office worker workload, we are using eight 1 vCPU virtual desktops per
core.
8 x 1vCPU virtual desktops per CPU core * 16 cores * 80% (max. CPU) = 100
virtual desktops per host
D E S KTO P P E RFO RM ANCE METR IC
R ECOR DED VALU E
Average number of CPUs per physical desktop

system
Average CPU utilization per physical desktop system
350 MHz
vCPU overhead
10%
ATTRI BUTE
SPECIFICATION
Number of CPUs (sockets) per host
Number of cores per CPU
GHz per CPU core
2.9 GHz
Total GHz per CPU
23.2 GHz
Total CPU GHz per host
46.4 GHz
Proposed maximum host CPU utilization
80%
Available CPU GHz per host
37.12 GHz
Virtual machines per host
~100 (37.12 GHz / 385 MHz)
Total ESXi hosts required
10 (+1 for HA)
Table 6: ESXi Host CPU Requirements
Virtual Desktop Memory Sizing

In View deployments, the majority of Windows 7 x86 virtual desktops have between 1 GB and 2 GB vRAM, with
no memory overcommit. For this reference architecture, we are simulating a known office-user workload that
does not exceed 1 GB RAM, therefore we are using 1 GB RAM per virtual desktop. For your deployment, assess
the memory requirements for the expected user workloads and size the virtual desktops appropriately.
This reference architecture uses existing server hardware that is already configured with 128 GB RAM. To handle
a host failure, an additional host to the cluster is added to ensure that hosts are running above 80 percent only
in the event of a host failure.
ATTRI BUTE
SPECIFICATION
Total amount of RAM per virtual machine
1024 MB
Memory reservation
25% (256 MB)
Resolution
1920 x 1600 (1 monitor)
Memory overhead per virtual machine
41 MB
Total RAM required for desktop virtual machines
104 GB
Total RAM required per host (100 virtual machines)
128 GB
Impact of additional host for HA purposes
10% saving
Anticipated savings from transparent page sharing

(in event of a host failure)
10%20%
Proposed maximum host memory usage
80%
Total amount of RAM per host
128 GB
Table 7: Virtual Desktop Memory Sizing for a 1 GB RAM Workload
RDSH Memory Sizing

RDSH workloads vary in memory requirements depending on the application workload. In VMware testing of
light, normal, and heavy workloads, the memory requirement is approximately 512 MB, 768 MB, and 1 GB RAM
per session, respectively.
The light workload for RDSH in this instance consists of
Microsoft Office (Excel, Word, and PowerPoint)
Adobe Acrobat Reader
Internet Explorer (browsing a picture library)
7Zip (compressing and decompressing files)
Firefox (browsing a picture library)
Internet Explorer (browsing text pages)
RDSH (with PCoIP) workload calculation:
512 MB * 30 sessions per RDSH = 16 GB RAM used
4 * 16 GB RDSH per ESXi host = 64 GB RAM used
To accommodate peaks in memory usage, RDSH servers are given 24 GB RAM, with an expectation that on
average only 16 GB is consumed.
ATTRI BUTE
SPECIFICATION
Total amount of RAM per RDSH session
512 MB
Total number of sessions per RDSH
30
Total RAM required per RDSH
16 GB
Number of RDSH per ESXi host
Memory overhead per virtual machine
41 MB
Total RAM required per ESXi host
64 GB
Total RAM allocated per RDSH
24 GB
Total RAM required per host
97 GB
Proposed maximum host memory usage
80%
Total amount of RAM per host
128 GB
Table 8: RDSH Memory Sizing for Light Workloads
VMware vCenter Server

VMware vCenter Server manages the ESXi hosts, vSphere clusters, virtual networking, VMFS and NFS
datastores, and the provisioning of virtual machines. For the purposes of automated testing using View
Planner, a single vCenter Server manages the management cluster and the desktop clusters. In production
implementations, VMware recommends deploying an additional vCenter Server to separate the management of
server and desktop workloads. Ideally, a vCenter Server running on an existing vSphere platform manages the
management block, and another vCenter Server running in the management block manages the desktop block.
vCenter Server is sized to accommodate both server workloads and up to 2,000 virtual desktops. vCenter
Server can scale to 10,000 virtual machines, if appropriately sized. You can also deploy multiple vCenter Servers
for provisioning concurrency and higher availability.
ATTRI BUTE
VCEN TER SERV ER APPLIAN CE
OS
Microsoft Windows Server 2012
vCPU
4 vCPUs
vRAM
24 GB
Storage
100 GB
Table 9: VMware vCenter Server Configuration
VMware vSphere Clusters

The following vSphere clusters were configured using vCenter Server.
CLUSTE R
NUMB ER OF HOSTS
DESCR IPTION
Management
Contains all server workload virtual machines for View,

Mirage, Workspace Portal, and vCenter.
Desktop
11
Contains all full-clone and linked-clone virtual desktops

created by View.
1,000 users / 100 virtual machines per
host = 10 hosts + 1 host for HA
RDSH
Contains all RDSHs created for View.

1,000 users / 30 sessions per RDSH = 34
/ 4 RD Sessions per host = 9 hosts
Table 10: VMware vSphere Clusters
Virtual Networking
In typical customer deployments, a vSphere implementation uses three types of network connections: virtual
machine, management network, and VMkernel. Each type connects to a virtual switch that has one or more
physical adaptersat least two adapters are required for resilienceto provide connectivity to the physical
networks.
Storage
External
Workloads
RDSH
Virtual
Desktop
Server
Workloads
EMC VNX
NFS
Management
vMotion
VMNet-172
VMNet-10
vmk
dvSwitch1
10GbE
NICs
Figure 13: Virtual Network
The Horizon environment has a distributed vSwitch (dvSwitch) to handle ESXi management, Horizon
workloads, NFS, and VMware vSphere vMotion. The dvSwitch uses dual port NICs connected to redundant
switches, providing resiliency across network adapters.
The port groups and VLANs created on each ESXi host are shown in the following figure.
Figure 14: Port Groups and VLANs
The virtual machine port groups are

dvPG-Management Network for ESXi management
dvPG-VMNET-10 Network for external access
dvPG-VMNET-172 Network for all virtual machines
dvPG-Storage Network for EMC VNX5500 NFS traffic
dvPG-vMotion Network for moving virtual machines between hosts in the cluster
VMware vRealize Operations for Horizon

VMware vRealize Operations for Horizon simplifies the management of your virtual desktop infrastructure
(VDI) and provides end-to-end visibility into its health and performance. It presents data through alerts, in
configurable dashboards, and on predefined pages in the user interface.
VMware vRealize Operations for Horizon extends the functionality of VMware vRealize Operations Manager
Enterprise and enables IT administrators and help desk specialists to monitor and manage Horizon with View
environments.
Architecture
VMware vRealize Operations Manager uses an adapter to pull data from View Connection Server and View
Agent. The View adapter obtains the topology from the Horizon environment, collects metrics and other types
of information from the desktops, and passes the information to vRealize Operations Manager.
Another vCenter Server adapter pulls data relating to vSphere, networking, storage, and virtual machine
performance.
Out-of-the-box dashboards monitor the health of the Horizon infrastructure and components. You can access
the dashboards via the Web-based vRealize Operations Manager console.
Desktop VMs
Database Server
V4H Desktop
Agent
V4H Desktop
Agent
View Events
Database
Desktop metrics
(PCoIP, CPU, memory,
disk, session info)
View topology
and events
vCenter
Server
vSphere metrics
(ESXi, VM, datastore,
data center)
vRealize Operations
Manager 5.7 vApp
View Adapter
View Adapter 1
vRealize Operations Manager Enterprise
Objects, metrics, KPIs,

alert, events
vRealize Operations Manager Console (Browser)
Custom UI
View Dashboards
Figure 15: VMware vRealize Operations for Horizon Architecture
Components
VMware vRealize Operations for Horizon consists of two SUSE Linux Enterprise 11 (64-bit) virtual appliances
that support 1,000 virtual desktops. The analytics appliance collects data from vCenter Server, VMware vCenter
Configuration Manager, and third-party sources, such as metrics, topology, and change events. Raw data is
stored in a scalable file system database (FSDB). The Web UI appliance allows you to access the results of the
analytics and the Administration Portal to perform management tasks.
ATTRI BUTE
WEB U I APPLIAN CE
AN ALYTICS APPLIAN CE
OS
SUSE Linux Enterprise 11 (64-bit)
SUSE Linux Enterprise 11 (64-bit)
vCPU
4 vCPUs
4 vCPUs
vRAM
11 GB
14 GB
Storage
100 GB
800 GB
Table 11: VMware vRealize Operations for Horizon Sizing
Configuration
VMware vRealize Operations for Horizon is configured as described in the installation guide with no additional
modifications. After deploying the virtual appliance, the configuration steps are
1. On the Admin Web console Update tab, deploy the vCenter Operations Manager for Horizon PAK file to
add the custom dashboards.
2. Log in to vCenter Operations Manager for Horizon and create the adapter instance.
3. Select the full metric set and set pairing credentials for the broker agent.
4. Install the broker agent on a View Connection Server.
For most environments, it is necessary to dedicate a View Connection Server for the broker agent.
Figure 16: VMware vRealize Operations for Horizon Broker Agent Configuration
Unified Access with Workspace Portal

Workspace Portal provides an easy way for users to access applications and virtual desktops on any device
and enables IT to centrally deliver, manage, and secure these assets. For end users, the result is true mobility:
anytime, anywhere access to everything they need to work productively. For IT, it offers more control over
corporate access across devices.
In this reference architecture, Workspace Portal is the primary way to access View virtual desktops, RDSH
desktops, ThinApp packaged applications, and SaaS-based applications.
Architecture
Workspace Portal is delivered as a SUSE Linux-based virtual appliance, an Open Virtualization Archive (OVA)
file consisting of a single virtual appliance deployed through vCenter. This solution uses the Workspace Portal
virtual appliance described below, plus View and ThinApp. You can configure Workspace Portal with additional
virtual appliances to scale out the solution.
https://myworkspace.company.com
https://myworkspace.company.com
Thin Client
Mac OS
PC
Horizon
Clients
Kiosk
iOS/Android
Private Cloud (vSphere)

Internal
Load
Balancer
External Load Balancer
Workspace Portal VA x 2
ThinApp
Repository
Oracle/vPostgres
Database
View
Connection
Servers
View RDSH
Apps and Desktops
Active
Directory
View Virtual
Desktops
Management Cluster
HTTPS
HTTPS (DMZ)
View, Workspace Portal Traffic
Figure 17: Workspace Portal Architecture
Access to Workspace Portal is via HTTPS, from anywhere, including from within a View or RDSH desktop.
Workspace Portal supports both internal and external access. The user is connected to Workspace Portal to
access their applications and desktops. All Workspace Portal components sit within the internal network.
When launching a View desktop, RDSH desktop, or hosted application, Workspace Portal launches the Horizon
Client if it is available. Alternatively, HTML5 protocol can be used to access View desktops if a
Horizon Client is not installed.
You can use a third-party load balancer to provide highly available access to multiple Workspace Portal virtual
appliances. Do not deploy the Workspace Portal virtual appliance in the DMZ.
Components
Workspace Portal 2.1 is composed of a single virtual appliance that can be duplicated for scaling purposes.
Application Proxy / Reverse Proxy
Workspace Portal VA
API
Workspace Portal VA
Workspace Portal VA
Services
API
API
Core Services
Workspace Portal
VA
tcserver
Services
API
Connector Services
Services
tcserver
Connector
tcserver
DB (vPostgres)
DB
OS (SLES)
DB
Connector
OS (SLES)
DB
tcserver
OS (SLES)
Connector
OS (SLES)
Figure 18: Workspace Portal Virtual Appliances
Workspace Portal virtual appliance enables a single, user-facing domain for access to Workspace Portal
for both user and administrators. The Workspace Portal virtual appliance is the single point of entry for all
purposes. It contains all the components for integrating with Horizon with View or third-party solutions.
vCPU
VI RTUAL
AP P LI ANC E
S I Z I NG
R AM
8 GB
HDD
72 GB
Table 12: Sizing for a Single Workspace Portal VA for 30,000 Users
Configuration
Workspace Portal virtual appliances get their time from the ESXi hosts that they are running on. Before
installing Workspace Portal virtual appliances, make sure that the time settings across all ESXi hosts are
accurate and have no skew because this can affect the Security Assertion Markup Language (SAML)
configuration.
SAML 2.0 authentication is configured across the participating View Connection Servers. After SAML 2.0
authentication is configured, the View Connection Servers are added to the connector virtual appliance used for
synchronization operations.
The View Client Access URL is configured in the Workspace Admin Console interface (Network Ranges) to point
to the load balancer in front of the participating View Connection Servers so that all traffic is load balanced.
The virtual appliance used for single sign-on (SSO) via Kerberos is joined to the domain, and Windows
authentication is enabled on the administrative interface, providing users a seamless experience without
prompts when accessing resources.
Windows Desktops and Remote Applications with View

View provides access to and management of virtual desktops, RDSH desktops, and hosted applications. In
this reference architecture, View is sized and configured to provision 800 stateless desktops, 200 persistent
desktops, and 1,000 RDSH sessions running 45 applications each.
Architecture
View is accessed via a Horizon Client installed on a users device that connects to View security servers for
external access or View Connection Servers for internal access. View Connection Servers provision and broker
to virtual desktops, hosted applications, or RDSH desktops running on vSphere ESXi hosts. View Administrator
and vCenter Server provide ESXi host and virtual machine management functions. In addition, VMware View
Composer and Mirage provide single image management, and vRealize Operations Manager provides health
and performance monitoring for all components within the architecture.
PCoIP UDP 4172

HTTPS TCP 443
PCoIP (Direct)
UDP 4172
HTTPS TCP 443
Active
Directory
Security
Servers
File/Print/ThinApp
Connection
Servers
vSphere
Admin
RDSH
Servers
View
Composer
View
Administrator
Console
Desktop
Admin
Virtual
Desktops
SQL
vRealize Operations
for Horizon
VMware ESXi
vCenter
VMware ESXi
vSphere
Client
Figure 19: Windows Desktops and Remote Applications with View
View Connection Server handles authentication to Active Directory and then brokers a connection to a virtual
desktop, RDSH desktop, or hosted application using either PCoIP or HTML5 if using a Web browser.
For external users, PCoIP traffic is forwarded by the View security server to the desktop session. For internal
users, the client is connected directly to the desktop session.
If a desktop is not available, View Connection Server can provision additional desktops automatically via
vCenter Server. Entitling users or a group to preconfigured pools of desktops in View Administrator enables
automatic provisioning. View Composer minimizes storage requirements by using linked clones for virtual
desktops.
View easily scales by adding more View Connection Servers or security servers. Each View Connection
Server can handle up to 2,000 concurrent connections. Additional View Connection Servers also provide high
availability.
View Connection Servers and security servers are installed in the management block. A Horizon pod can
support up to seven View Connection Servers, not to exceed 10,000 concurrent sessions. Up to four View
security servers per View Connection Server are permitted.
It is recommended to deploy one vCenter Server per desktop block, along with a single instance of View
Composer. View Composer can be installed on vCenter Server or be standalone.
Components
View consists of the following components:
Horizon Client Horizon Clients are available for Windows, Mac, Ubuntu Linux, iOS, and Android to provide
the connection to remote desktops from your device of choice. By installing Horizon Client on each endpoint
device, end users can access their virtual desktops from smartphones, zero clients, thin clients, Windows PCs,
Macs, and iOS and Android mobile devices. Unity Touch for Horizon Clients makes it easier to run Windows
apps on iPhone, iPad, and Android devices.
View Connection Server View Connection Server streamlines the management, provisioning, and deployment
of virtual desktops. Administrators can centrally manage thousands of virtual desktops from a single console.
End users connect through View Connection Server to securely and easily access their personalized virtual
desktops. View Connection Server acts as a broker for client connections by authenticating and directing
incoming user desktop requests.
View security server A View security server is an instance of View Connection Server that adds an additional
layer of security between the Internet and your internal network. Outside the corporate firewall, in the DMZ,
you can install and configure View Connection Server as a View security server. Security servers in the DMZ
communicate with View Connection Servers inside the corporate firewall. Security servers ensure that the only
remote desktop traffic that can enter the corporate data center is traffic on behalf of a strongly authenticated
user. Users can only access the desktop resources for which they are authorized.
View Composer View Composer is an optional service that enables you to manage pools of like desktops,
called linked-clone desktops, by creating master images that share a common virtual disk. Linked-clone
desktop images are one or more copies of a parent virtual machine that share the virtual disks of the parent,
but which operate as individual virtual machines. Linked-clone desktop images can optimize your use of
storage space and facilitate updates. You can make changes to a single master image through VMware vSphere
Client. These changes trigger View Composer to apply the updates to all cloned user desktops that are linked
to that master image, without affecting users settings or persona data.
View Agent (including Remote Experience Pack) The View Agent service communicates between virtual
machines and Horizon Client. You must install View Agent on all virtual machines managed by vCenter Server
so that View Connection Server can communicate with them. View Agent provides features such as connection
monitoring, virtual printing, persona management, and access to locally connected USB devices. View Agent is
installed in the guest OS.
View requires Active Directory for authentication and vCenter Server for virtual desktop provisioning and
management. SQL Server is required by vCenter Server, View Composer, and View Connection Server for
database purposes.
CO M P O NENT
QUAN TITY
VCPU
V R AM
HDD
4 (2 internal, 2
external)
16
50 GB
View security server
4 (2 per external View

Connection Server)
16
40 GB
View Composer
16
30 GB
CO M P O NENT
QUAN TITY
VCPU
V R AM
HDD
File print server
10
140 GB
SQL Server
16
140 GB
RDSH server
32
24
40 GB
Windows 7 desktops
1,000
40 GB
Table 13: Sizing for View Deployment of 2,000 Users
Configuration
You use the Web-based View Administrator console to configure and manage View. You can also configure
View Connection Servers and security servers from the console. This reference architecture uses the following
settings:
Global Policies
View is configured to allow USB and PCoIP hardware acceleration, but to deny multimedia redirection (MMR).
MMR is out of the scope of this reference architecture.
View Configuration Settings
All View Connection Servers and security servers are added to the View instance to create the View pod. Each
externally facing View Connection Server is paired with two security servers.
A ThinApp repository was not configured. Instead, Workspace Portal is used to access ThinApp packaged
applications.
An event database is configured and implemented on a standalone SQL Server.
View Connection Server Settings
Workspace Portal is the delegated authentication mechanism for View. The SAML authenticator is set to the
externally facing fully qualified domain name of the Workspace Portal Gateway virtual appliance load-balanced
IP address.
vCenter Settings
vCenter is configured to reclaim virtual machine disk space (for SE sparse disks). View Storage Accelerator is
enabled with a 1 GB host cache. The settings 32, 50, 32, and 32 were used for concurrent operation limits. These
settings are increased based on the storage device capabilities.
Resources
The created application farm, AppFarm01, consists of 32 RDSH servers. The farm is used for all RDSH desktop
and application sessions.
An RDSH desktop pool allows users to access a Windows 2012 RDSH desktop running via PCoIP. An application
pool was created for each application tested and assigned to AppFarm01, again using PCoIP as the protocol.
An automated floating desktop pool with 800 Windows 7 linked-clone desktops is provisioned with View
Composer to enable load testing. No persistent disk or disposable disks are used. Replica and OS disks are
stored on the same NFS datastore. The default settings are used for the advanced storage options.
Another automated dedicated desktop pool with 200 Windows 7 full-clone desktops is provisioned using
vCenter Server. The full clones are deployed across the six 2 TB NFS datastores.
View Storage Accelerator is enabled to regenerate the manifest every 7 days.
Virtual Desktop Machine Image Build

A single master OS image is used to provision desktop sessions in the View environment. Use a fresh
installation of the guest OS so that the correct versions of the HAL, drivers (including the optimized network
and SCSI driver), and OS components are installed. A fresh install also avoids performance issues with legacy
applications or configurations of the desktop virtual machine.
The reference architecture used a Windows 7 golden image with the specifications listed in the following table.
The image is optimized in accordance with the VMware Horizon with View Optimization Guide for Windows
7 and Windows 8. It is modified to meet View Planner 3 requirements (see Sections A, B, and C of the View
Planner Installation and Users Guide). We used the free VMware OS Optimization Tool (available for download
at labs.vmware.com) to make the changes.
ATTRI BUTE
SPECIFICATION
Desktop OS
Windows 7 Enterprise SP1 (32-bit)
Hardware
VMware virtual hardware version 9
CPU
Memory
1024 MB
Memory reserved
256 MB
Video RAM
Up to 128 MB
3D graphics
Off
NICs
Virtual network adapter 1
VMXNet3 Adapter
Virtual SCSI controller 0
LSI Logic SAS
Virtual disk VMDK
40 GB
Table 14: Windows 7 Golden Image Virtual Machine Specifications
Remote Desktop Services Host Configuration

The RD Session Hosts are Microsoft Windows 2012 R2 servers with the RDS feature and RDSH role added.
View Agent is also installed on each RDSH server and registered to one of the View Connection Servers.
ATTRI BUTE
SPECIFICATION
Desktop OS
Windows Server 2012 R2
Hardware
VMware virtual hardware version 9
CPU
Memory
24 GB
Memory reserved
0 MB
Video RAM
128 MB
NICs
VMXNet3 Adapter
LSI Logic SAS
Virtual disk VMDK
40 GB C:
174 GB View Planner workload data (not required
outside of testing)
Table 15: RD Session Host Specifications
Single Image Management with Mirage

Mirage provides unified image management for physical desktops, virtual desktops, and bring your own
devices. Dynamic layering and full system recovery ensure that IT can quickly and cost-effectively deliver,
manage, and protect updates to operating systems and applications across tens of thousands of endpoints.
Designed for distributed environments, Mirage requires little to minimal infrastructure at branch sites, reducing
CapEx. Mirage also complements and extends PC Lifecycle Management tools to drive down IT help desk and
support costs.
This reference architecture uses Mirage to manage full-clone, persistent virtual desktops and linked-clone
parent virtual machine images. For more information on managing physical endpoints with Mirage, see the
VMware Horizon Mirage Branch Office Reference Architecture.
Architecture
Mirage consists of a Mirage Management server, Mirage server, and Windows file server, which are used to
manage and store data from Mirage clients (endpoints). Endpoints can be physical or virtual desktops (full
clones only).
External
Physical
Endpoints
Physical
Endpoints
Mirage
Server
Active
Directory
Mirage
Edge Gateway
Mirage
Admin
Mirage
Management
Server
Mirage
Console
Virtual Desktop
(Full Clone)
SQL
Mirage
Windows
File Server
Mirage
Server
VMware ESXi
VMware ESXi
Figure 20: Mirage Architecture
To manage View desktops with Mirage, you need the following desktop virtual machines:
Reference Windows desktop virtual machine for base layer capturing
Windows desktop virtual machine for app layer capturing to add updates or new applications
Template Windows desktop virtual machine to create a persistent full-clone pool
Mirage has the following components:

Mirage Management server The management server is the main component that controls and manages the
Mirage server cluster and coordinates all Mirage operations, including backup, migration, and operating system
deployment.
Mirage server Mirage servers perform backups, migrations, and the deployment of base and app layers to
endpoints. Multiple Mirage servers can be deployed as a server cluster to provide system redundancy and
support larger organizations.
Mirage Web and Protection Manager These Web-based tools enable help desk personnel to efficiently
respond to service queries and ensure that endpoints are protected by Mirage backup capabilities.
Mirage client The Mirage client enables an endpoint to be managed by Mirage. It supports both physical and
virtual desktops, including those hosted by both Type 1 and Type 2 hypervisors.
S ERVER
QUAN TITY
VCPU
V R AM
HDD
Mirage Management server

and Mirage server
16
190 GB
Mirage Server
16
190 GB
SQL Server
Uses the same SQL Server as View

(see SQL Server section for sizing)
Set up as a file share on the file and print server:

Base layer Allow up to the size of the used disk in virtual
desktop image per layer
CVD storage (only metadata for full clones) ~500 MB per
full clone
Table 16: Recommended Sizing for Mirage for a 200 Full-Clone Desktop Deployment
Configuration
For this reference architecture, Mirage Management server is installed on one of the two Windows 2012 R2
virtual machines that also function as Mirage servers in the environment. The Mirage database is hosted on a
Windows 2012 R2 virtual machine that is running SQL Server 2008 R2 Standard Edition. The SQL Server also
hosts databases for View Composer and View events within the environment.
Each Mirage server is configured with a separate 150 GB virtual disk to host the server local cache. This location
is specified during server installation.
The Mirage Console is a plug-in that is installed on and run from Mirage Management server. It is the single pane
of glass for all Mirage management tasks across the environment; creating and deploying reference CVDs, base
layers, and application layers are performed in this management tool. Built-in wizards to perform many of these
tasks streamline management operations.
Figure 21: Mirage Console Built-in Wizards
This Mirage install manages images for 200 full-clone, persistent desktops in View. A Mirage client is installed
on a Windows desktop virtual machine (the reference desktop). A reference CVD is created, and a base layer
that had 138 Microsoft updates and an application is captured with the Capture Base Layer wizard. Do not
optimize the CVD policy for Horizon.
The following two services must be enabled for Mirage when optimizing the virtual machine template:
Volume Shadow Copy
Microsoft Software Shadow Copy Provider
The script attached to the VMware Horizon with View Optimization Guide for Windows 7 and Windows 8
disables these services. Either edit the script to enable these services or re-enable them on the template before
deploying your pool of full-clone desktops.
A Mirage client is installed on a Windows desktop machine, which is used to manage application updates. An
administrator can capture an application layer by recording the state of the virtual desktop before and after an
application install or update.
The Mirage client is then installed on a template virtual machine to be used for full-clone desktops. A full-clone
dedicated desktop pool can now be created using the template virtual machine and View. Each new virtual
desktop in the pool appears as a pending device in the Mirage Console.
Now the full-clone desktops can be centralized using the CVD upload policy. Ensure that the CVD policy
includes the option Optimize for VMware Horizon View. This option disables uploading of user data, which can
cause considerable network, storage, and CPU load per desktop, so you cannot revert to a snapshot or restore
user files to previous versions. However, user data and applications are not lost on base layer or application
layer updates.
VM for App Layer
Capturing
Mirage Server
Mirage Management
Server
App Layer
Base Layer
Reference
CVD VM
UserDefined
Layer
(Optional)
App Layer
App Layer
App Layer
App Layer
Base Layer
Base Layer
Base Layer
Base Layer
VM-1
VM-2
VM-n
Template VM
Full-Clone Pool
Figure 22: Creating a Full-Clone Desktop Pool
An administrator can use the Mirage Management server to apply the base layer or application layers to the
full-clone desktops. Before applying new layers, it is recommended to run a layer conflict report to ensure that
the changes do not interfere with user-installed applications. After the layers are applied, the user can continue
without loss of user data or applications.
User Experience
All client devices use either Workspace Portal or Horizon Client to connect to desktops and applications.
Horizon Client is publicly available for download and can be installed on many different devices. This reference
architecture uses the following Horizon Clients to access desktops and applications:
Apple iPhone 5
Apple iPad 2
Apple MacBook
Android tablet
Microsoft PC running Windows 7, single monitor
The Horizon Client is required to access View-hosted (RDSH) applications and View RDSH desktops. To access
View virtual desktops, either Horizon Client or a supported HTML5 browser is used.
Blast Features
With Horizon, IT can deliver desktops and applications to end users through a unified workspace using the Blast
features to enable consistently great experiences across devices, locations, media, and connections.
Blast includes the following features:
Adaptive UX Optimized access across the WAN and LAN through an HTML browser or the purpose-built
desktop protocol PCoIP
Multimedia High-performance multimedia streaming for a rich user experience
3D Rich virtualized graphics delivering workstation-class performance
Live communications Fully optimized unified communications and real-time audio and video support
(Horizon 6 includes support for Microsoft Lync with Windows 8)
Unity Touch Intuitive and contextual user experience across devices, making it easy to run Windows on
mobile
Local access Access to local devices, USB, and device peripherals
For this reference architecture, not all the Blast features were tested. The reference architecture tested the
adaptive UX, Unity Touch, and local access features.
PCoIP Settings
PCoIP is the default protocol for View desktops and applications. It can be configured using a Group Policy
Administrative Template. An Active Directory organizational unit (OU) is established for both RDSH services
and virtual desktops. A single PCoIP policy is set across two OUs.
Figure 23: PCoIP Policy Settings
Persona and User Data

To provide a consistent experience for users, it is imperative to maintain desktop and application configurations
and settings across user sessions. This reference architecture uses View Persona profiles for all users across
virtual desktops and a Microsoft RDSH profile (redirected to a network drive) for when users access RD
Session Hosts (because View Persona does not support RDS session Profiles). View Persona is configured to
synchronize the user profile every 90 minutes to a network share.
Folder redirection for documents is used to minimize the profile size, and redirect user data to a network drive.
Desktop Persistence
For users requiring a dedicated desktop where they can install applications, a full-clone dedicated desktop
is provided. Mirage is used to patch the operating system of the dedicated desktops. All user changes to the
desktop are maintained.
The benefit of using Mirage is that it provides a single point to manage both physical and virtual desktops. For
more information, see Single Image Management with Mirage in this guide.
For linked-clone, nonpersistent desktops, changes to the desktop operating system are lost when the desktops
are refreshed or recomposed. View Composer is used to refresh, reset, or recompose linked-clone desktops. It
uses a single desktop image, known as the Parent VM. Optionally, Mirage can update the Parent VM to provide
true single-image management.
Integration
This section details the integration considerations for this reference architecture.
Active Directory
The design uses OUs created specifically for View desktops and RD Session Hosts, An OU is an Active Directory
subdivision that contains users, groups, computers, or other OUs.
By creating dedicated OUs, View policies are applied via Group Policy Objects (GPOs) to all machines created
dynamically by View without knowing the workstation account name. RD Session Hosts can also be added
manually to an OU to apply RDSH-specific policies.
View has administrative templates for managing View virtual desktops and RD Session Hosts. Administrators
can import these templates and apply them via GPO to the respective OUs. This method provides a
straightforward and consistent way to manage policies specific to View virtual desktops and users.
For this reference architecture
The created OUs allow management of users, virtual desktops, and RDSH.
Virtual desktops are added automatically to the VirtualDesktops OU when provisioned by vCenter or View
Composer.
RD Session Hosts are added manually to the RDSH Services OU when provisioned using vCenter.
Group policies are applied to RD Session Hosts and virtual desktops for folder redirection, profile
management, and PCoIP.
RD Session Hosts and virtual desktops need Allow Log On Locally and Allow Log on Through Remote
Desktop Services to be set for the appropriate user groups.
Group policy loopback processing is enabled to ensure that policies are applied to users accessing computers
within the RDSH Services or Virtual Desktop OUs.
Figure 24: Group Policy for Home Drive Redirection
VMware SQL Server

VMware vCenter, View, and Mirage require database connectivity to store information. This reference
architecture uses a single server running SQL Server 2008 R2. The following tables list the SQL Server
specifications. For more information, see VMware vCenter Server 5.1 Database Performance Improvements and
Best Practices for Large-Scale Environments.
ATTRI BUTE
SPECIFICATION
Version
SQL Server 2008 R2 Standard
Virtual machine hardware
VMware Virtual Hardware version 10
OS
Windows Server 2012 R2 Standard
vCPU
vMemory
16 GB
vNICs
VMXNet3 Adapter
LSI Logic SAS
Virtual disk VMDK
40 GB Windows OS
100 GB mssql01 SQL Server master and msdb
databases, VCDB, View Composer database,
View events database, and Mirage database
(.mdf, .ldf)
Table 17: SQL Server Virtual Machine Specifications
The following settings were used to create the databases.

ATTRI BUTE
SPECIFICATION
Vendor and version
Microsoft SQL Server 2008 R2 Standard
Authentication method
SQL authentication
Recovery method
Simple
Database autogrowth
Enabled in 1 MB increments
Transaction log autogrowth
In 10% increments, restricted to 2 GB maximum
Database size
5 GB
Table 18: View Composer and Events Database Specifications
The following settings were used to create the Mirage database.

ATTRI BUTE
SPECIFICATION
Vendor and version
Microsoft SQL Server 2008 R2 Standard
Authentication method
SQL authentication
Recovery method
Simple
Database autogrowth
Enabled in 1 MB increments
Transaction log autogrowth
In 10% increments, restricted to 2 GB maximum
Database size
<1 GB
Table 19: Mirage Database Specifications
Windows File Services

View, Workspace Portal, and Mirage rely on file services to provide users with access to data, applications, and
image updates. Two Microsoft Windows file servers provide network shares for user data, View Persona user
profiles, RDS profiles, ThinApp applications, and Mirage data. Each file server is allocated a 100 GB disk.
Microsoft Distributed File System (DFS) is a highly available file services solution. The following table shows
how the DFS shares are set up to replicate the data between the two file servers.
Note: Size your file shares based on user quota, expected profile size, ThinApp application sizes, and Mirage
Single Instance Store sizing.
ATTRI BUTE
SPECIFICATION
Number of file servers
VM hardware
VMware Virtual Hardware version 10
OS
Windows Server 2012 R2 (64-bit)
vCPU
vMemory
10 GB
vNICs
VMXNet3 Adapter
LSI Logic Parallel
ATTRI BUTE
SPECIFICATION
Virtual disk VMDK
40 GB Windows OS
100 GB data disk:
User home drives \HomeDrives
View Persona \Persona
RDS profiles \RDSProfiles
Mirage Single Instance Store \Mirage
ThinApps \ThinApp
Table 20: Windows File Services Specifications
Availability
The system is resilient in the event of a component system failure. The design does not cover a disaster
recovery scenario in which the entire site is lost, but it does cover limited component failure.
ATTRI BUTE
S PECIFICATION
Workspace Portal
Gateway
Multiple Gateway virtual appliances provide a highly available access solution. A

third-party load balancer is required.
Workspace Portal
Service virtual appliance
Multiple Service virtual appliances provide a highly available Workspace Portal

solution. No load balancer is required.
Workspace Portal
Connector virtual
appliance
Multiple Connector virtual appliances provide a highly available Workspace Portal

solution. No load balancer is required.
Mirage server failure
Multiple Mirage servers provide a highly available solution. A third-party load

balancer is required for inbound traffic. Desktop use is not impacted, but image
or application updates cannot be delivered to desktops.
View security server
At least two load-balanced View security servers are required for redundancy. If a
server fails, users are disconnected from their session. User data is not lost, and a
user can reconnect quickly. A third-party load balancer is required.
At least two load-balanced View Connection Servers are required for redundancy.
If a server fails, users are not disconnected from their session. A third-party load
balancer is required.
View desktop
If a desktop fails, the user might lose data. A new desktop can be provisioned if
the current desktop cannot be fixed. Alternatively, a pool of preprovisioned
desktops allows users to quickly connect to another desktop.
RD Session Host
Users are disconnected from their session. View supports RDSH farms in which
multiple RD Session Hosts are pooled for desktop or application access. Users
can reconnect to a different RD Session Host, but might have lost data.
vCenter Server
If vCenter Server fails, View is not affected. Virtual desktops can still be
connected, but new desktops cannot be provisioned. Workloads are not balanced
across clustered hosts. Desktops cannot be powered on or off.
ATTRI BUTE
S PECIFICATION
ESXi host
If a virtual desktop host fails, the user loses connection to the desktop. The
desktop can be migrated to another host in the cluster and started (if using
shared storage). The user can connect to the desktop within minutes. Users might
lose data.
View desktop cluster

failure
If all hosts in a View desktop cluster lose connectivity or fail, users assigned to the
desktop pools hosted on the affected cluster cannot access a virtual desktop until
the cluster is restored.
Management cluster
failure
The service is unavailable if the management cluster fails. Users directly accessing
virtual desktops and RDSH sessions are disconnected, but might lose services,
such as printing, Active Directory, and user profile data.
Table 21: Potential Failure Points and Redundancy
Test Results
Testing consisted of manual functional tests to highlight usability and manageability, operational tests to verify
provisioning and administration tasks, and workload testing to validate performance and the user experience.
Functional Testing
Functional testing was performed across a number of client devices manually and also included common
administrative tasks.
After Horizon is installed and configured, it takes 14 minutes to set up and provide access to RDSH desktops
and applications. It takes an additional 18 minutes to provision an initial pool of 100 desktops. Users can connect
to desktops or applications in 10 seconds after being authenticated.
FUNC TI O NAL TEST
TIME TO
COMPLETE
VALIDATION
R ESULT
Configure Workspace Portal

to integrate with View
7 minutes
Entitled application appears in

Workspace Portal
PASSED
Install a Mirage client on a

template virtual machine (for
full clones)
3 minutes
Template virtual machine appears in

the Mirage Console as a pending
device
PASSED
Create desktop base layer in

Mirage (14 GB used)
23 minutes
Base layer appears in Mirage

Console
PASSED
Provision RDSH server using

vCenter Server
6 minutes
RDSH virtual machine appears in

vCenter Server as powered on
PASSED
Create RDSH farm in View
3 minutes
Added RD Sesssion Hosts show up

in the created farm
PASSED
Create RDSH desktop pool in

View
5 minutes
Desktop pool shows up in View

Administration console, and entitled
users can access the pool
PASSED
Create application pools in

View
2 minutes
Applications chosen from the RDSH

farm show up in View
Administration console and can be
accessed by users
PASSED
Entitle users to RDSH

desktops in View
2 minutes
Entitlements show up in View

Administration console
PASSED
Entitle users to RDSH

applications in View
2 minutes

PASSED
Access RDSH desktop from

Horizon Client (iOS, Mac OS,
Windows, Android)
10 seconds
(68 second
reconnect)
Clicking an RDSH desktop in

Horizon Client after user login
presents the desktop to the user
PASSED
FUNC TI O NAL TEST
TIME TO
COMPLETE
VALIDATION
R ESULT
Access RDSH application

from Horizon Client (iOS, Mac
OS, Windows, Android)
810 seconds
(68 second
reconnect)
Clicking an RDSH application in

presents the application to the user
PASSED
Access any RDSH

application from
Workspace Portal
810 seconds
(68 second
reconnect)
Clicked RDSH application entitled

from View and synced to
Workspace Portal catalog
PASSED
Create a floating desktop

pool (linked clones) for 800
desktops in View
63 minutes
View desktops for the pool appear

in the View Administration console
PASSED
Create a dedicated desktop

pool (full clones) of 32
desktops in View
89 minutes
View desktops for the pool appear

in the View Administration Console
PASSED
Entitle users to floating

desktop pool in View
2 minutes

PASSED
Entitle users to dedicated

desktop pool in View
5 minutes
Each individual entitlement shows

up in View Administration console
PASSED
Access floating desktop from

Horizon Client (iPad, Mac OS,
PC, Android)
10 seconds
(68 second
reconnect)
Clicking a View desktop in Horizon

Client after user login presents the
desktop to the user
PASSED
Access dedicated desktop

from Horizon Client (iPad,
Mac OS, PC, Android)
10 seconds
(68 second
reconnect)
Clicking a View desktop in Horizon

Client after user login presents the
desktop to the user
PASSED
Access any virtual desktop

from Workspace Portal
10 seconds
(68 second
reconnect)
Clicking an RDSH desktop in

presents the desktop to the user
PASSED
Access any RDSH application

from within a virtual desktop
session
810 seconds
(810 second
reconnect)
Clicking an RDSH application in

presents the application to the user
PASSED
Centralize 32 full-clone virtual

desktops
2 minutes
Full clones appear as CVDs in

Mirage Console
PASSED
Update 32 full-clone virtual

desktops using Mirage (base
layer updates 2080 MB)
35 minutes
New base layer is deployed to

virtual desktops with new OS
updates, and user changes are
maintained
PASSED
Table 22: Functional Test Results
Workload Testing RDSH Desktops

Horizon 6 with View harnesses the capabilities of RDS, allowing multiple users to connect to a single Windows
Server but have individual desktop instances and applications. Users can connect to a single application or a full
desktop over PCoIP for a rich end-user experience.
For testing, a single ESXi 5.5 host was provisioned with four Windows 2012 RDSH servers. The RDSH servers
were clones, each with the same base applications and configuration. The RDSH servers were added to a new
farm in Horizon with View. The farm was then added to a new RDSH desktop pool.
VMware View Planner was used to simulate 120 end-user desktop sessions carrying out office worker tasks
over PCoIP to the RDSH desktop pool. The application set consisted of seven common office applications and
simulated 35 different user operations. The latency of these operations was used to calculate the View Planner
score, as described in more detail in Appendix B.
Figure 25: View Planner Operational Latencies
To satisfy View Planner test requirements, Group A operation latencies had to be less than 1 second, and Group
B application latencies less than 6 seconds. The workload passed comfortably: The Group A scored 0.513369
seconds, and Group B scored 4.023978 seconds.
TEST GRO UP
O P ERATI ON TYPE
R ESU LT
Group A
Interactive or fast-running operations that

are CPU bound, like browsing through a PDF
le, modifying a Word document, etc.
95th percentile: 0.513369 s

(BR: <= 1.0 s)
Group B
Long-running, slow operations that are IO

bound, like opening a large document,
saving a PowerPoint le, etc.
95th percentile: 4.023978 s

(BR: <= 6.0 s)
Table 23: Test Groups
The View Planner workload test performed five test run iterations. During this time, ESXi CPU usage averaged
71 percent, with a peak of 96 percent. The four RDSH servers averaged 70 percent CPU usage, with a peak of 96
percent.
Figure 26: ESXi and RDSH Server CPU Usage
The ESXi 5.5 host averaged 78 percent memory usage, with a peak of 79 percent. The four Windows 2012 RDSH
servers averaged 40 percent memory usage, with a peak of 59 percent.
Figure 27: ESXi and RDSH Server Memory Usage
RDSH server commands per second peaked at 218 during View Planner workload. Peak reads reached 100 per
second, and peak writes 167 per second.
Figure 28: RDSH Server Average IOPS
Mirage Operations Testing

Mirage is a layered image management solution that separates desktop, laptop, or virtual endpoints into logical
layers that are owned and managed by either IT or the end user.
The base layer usually contains the operating system, core or infrastructure software, and common applications,
such as MS Office. App layers are useful when you are distributing certain applications to a particular group
of users. You can also use app layers to update or replace specific applications, instead of capturing new base
layers.
When you need to update a base layer or app layer, assign the new base or app layers to the Horizon with View
desktop pool, and all the machines in the pool are updated.
Test: Assign an Updated Base Layer to Full-Clone Virtual Desktops
A pool of Windows 7 (32-bit) full-clone virtual desktops was provisioned in Horizon with View. A new base layer
containing Windows updates, office files, and an application was captured from a reference virtual machine.
The base layer was assigned to the pool. The base layer was 2080 MB (1910 MB when compressed).
It took just 35 minutes to deploy the new base layer image to the pool of 32 full-clone virtual desktops.
Figure 29: Time to Assign a Base Layer to Full-Clone Virtual Desktops
The Mirage server had low resource usage throughout testing, with peak CPU usage of 26 percent and peak
memory usage of 13 percent.
Figure 30: Mirage Server CPU and Memory Usage
The Mirage server had a peak network transmit of 85 MBps and receive of over 15 MBps.
Figure 31: Mirage Server Network Usage
Average full-clone CPU usage peaked at 57 percent. Average full-clone memory usage peaked at 97 percent
during the base layer assignment operation.
Figure 32: Full Clone Average CPU and Memory Usage
Average full-clone network transmits peaked at 64 KBps, while average network receives peaked at 4485 KBps
during the base layer assignment operation.
Figure 33: Full Clone Average Network Transmits and Receives
The base layer assignment operation goes through an intensive read and write phase, with full-clone virtual
desktop average reads per second peaking at 209 per desktop, and average writes per second peaking at 304
per desktop.
Figure 34: Full Clone Average Read and Writes
Appendix A: Bill of Materials
EMC VNX 5500

Horizon 6 Server Workloads
Linked-Clone Desktops
Full-Clone Desktops
RD Session Hosts
User Profiles
User Data
ThinApp Repository
Extreme Summit x670 10GbE

Desktop & RD Session Hosts
System Boards for VDI
System Boards for RDSH
VDI &
RDSH VMs
Management Hosts
System Boards
- Horizon 6 Server Workload VMs
Figure 35: Hardware Components
The test configuration bill of materials is summarized in the following table.

ARE A
Server
CO M P O NEN T
QUAN TITY
Supermicro 2027TR chassis
Supermicro X90RT-HF system boards

(2 x Intel E5 2690 2.9 GHz 8-core, 128 GB RAM)
20
Supermicro X90RT-HF system boards

(2 x Intel E5 2658 2.1 GHz 8-core, 128 GB RAM)
Storage
EMC VNX5500 (20 TB)

Desktop pools: 6 x 2 TB
RDSH servers: 4 x 1 TB
Management servers: 2 x 2 TB
Network
Extreme Summit x670 10GbE switch
ARE A
Software
CO M P O NEN T
QUAN TITY
Horizon Enterprise Edition (View, Mirage,

Workspace Portal)
2,000 users
vCenter Server
Included in Horizon
Enterprise Edition
ESXi
Included in Horizon
Enterprise Edition
vRealize Operations for Horizon
Included in Horizon
Enterprise Edition
Microsoft Windows 7 VDA
1,000 users
Microsoft RDS CAL
1,000 users
Microsoft Windows Server 2012 Datacenter Edition
Microsoft SQL Server 2008 R2
Table 24: Bill of Materials
Appendix B: View Planner 3.5

The View Planner tool simulates application workloads for various user types by running applications typically
used in a Windows desktop environment. During the execution of a workload, applications are randomly called
to perform common desktop user operations.
Web
Interface
Harness
VMware vCenter
View
View
Planner Appliance
Client
Management
Manage
Desktop
Management
Virtual Client VMs
Virtual Desktops
Physical
Servers
Physical
Servers
Remote
Display
Protocol
Storage
Storage
Figure 36: View Planner Simulation Tool
View Planner Operations

The View Planner workload consisted of seven applications, performing a total of 35 user operations. These
user operations are separated into three groups, as shown in the following table. Group A are interactive
operations, Group B are I/O operations, and Group C includes background load operations. The operations in
Group A are used to determine quality of service (QoS). The Group C operations generate additional load.
GRO UP A
GR OU P B
GR OU P C
AdobeReader: Browse
AdobeReader: Open
7zip: Compress
AdobeReader: Close
Excel_Sort: Open
PowerPoint: SaveAs
AdobeReader: Maximize
Excel_Sort: Save
GRO UP A
GR OU P B
AdobeReader: Minimize
Firefox: Open
Excel_Sort: Close
IE_ApacheDoc: Open
Excel_Sort: Compute
IE_WebAlbum: Open
Excel_Sort: Entry
PowerPoint: Open
Excel_Sort: Maximize
Word: Open
Excel_Sort: Minimize
Word: Save
GR OU P C
Firefox: Close
IE_ApacheDoc: Browse
IE_ApacheDoc: Close
IE_WebAlbum: Browse
IE_WebAlbum: Close
PowerPoint: AppendSlides
PowerPoint: Close
PowerPoint: Maximize
PowerPoint: Minimize
PowerPoint: ModifySlides
PowerPoint: RunSlideShow
Word: Close
Word: Maximize
Word: Minimize
Word: Modify
Table 25: View Planner Operations
Run Phases
For this test, View Planner performed a total of five iterations:
Ramp up (first iteration)
Steady state (second, third, fourth iterations)
Ramp down (fifth iteration)
During each iteration, View Planner reported the latency for each operation performed within each virtual
machine.
Quality of Service
QoS, determined separately for Group A user operations and Group B user operations, is the 95th percentile
latency of all the operations in a group. The default thresholds are 1.0 seconds for Group A, and 6.0 seconds for
Group B.
References
VMware Product Page
View Documentation
View Technical Resources
VMware End-User Computing Solutions
VMware Desktop Virtualization Services
Horizon with View Optimization Guide for Windows 7 and Windows 8
Antivirus Best Practices for Horizon View 5.x
View Planner 3 Resources
View Storage Accelerator
VMware vCenter Database Performance Improvements and Best Practices for Large-Scale Environments
VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com
Copyright 2015 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at
http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be
trademarks of their respective companies. Item No: VMW-TWP-HORIZ6REFERENCEARCH-USLET-20150625-WEB

VMware Reference Architecture Horizon 6 View Mirage Workspace

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VMware Reference Architecture Horizon 6 View Mirage Workspace

Transféré par

Droits d'auteur :

Formats disponibles

VMware Horizon 6

VMware Horizon 6 Reference Architecture

Modular Pod and Block Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Software-Defined Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

VMware Horizon 6 Reference Architecture

Unified Access with Workspace Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Windows Desktops and Remote Applications with View . . . . . . . . . . . . . . . . . . . . . . . 34

Single Image Management with Mirage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Workload Testing RDSH Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Mirage Operations Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Test: Assign an Updated Base Layer to Full-Clone Virtual Desktops . . . . . . . . . . . . . 56

Appendix A: Bill of Materials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

View Planner Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

VMware Horizon 6 Reference Architecture

120 Users per

100 Users per

per 16 core ESXi host for Remote

per 16 core ESXi host for View

Access from Any Device

to View desktops and applications

Single Image Management

Set up Hosted Applications

Desktops and applications

from View Administrator

Figure 1: Solution Highlights

VMware Horizon 6 Reference Architecture

Workload Test Result Highlights

Figure 2: ESXi and RDSH Server CPU Usage

VMware Horizon 6 Reference Architecture

Figure 3: ESXi and RDSH Server Memory Usage

VMware Horizon 6 Reference Architecture

VMware Reference Architectures

VMware Horizon 6 Reference Architecture

View Security Servers

View Connection Servers

Workspace Portal vApp

View RDSH Apps & Desktops

View Virtual Desktops

NFS Shared Storage

Figure 4: Horizon with View Components

VMware Horizon 6 Reference Architecture

Extreme Summit x670 10GbE

EMC VNX 5500

VMware Horizon 6 Reference Architecture

VMware Horizon 6 Reference Architecture

VMware Workspace Portal

Full-Clone and Linked-Clone

Figure 6: Horizon 6 Components

VMware Horizon 6 Reference Architecture

Horizon 6 Reference Architecture

Modular Pod and Block Design

View Desktop Pools

Switched Ethernet Network

vCenter Server and View Composer

View Connection Server

View Connection Server

Horizon Management Block

Figure 7: Horizon Pod and Management Block

VMware Horizon 6 Reference Architecture

VMware Horizon 6 Reference Architecture

3x ESXi 5.5 Host

TEMP, ISO LUN

Figure 8: VMware vSphere Cluster

VMware Horizon 6 Reference Architecture