VMware Reference Architecture Horizon 6 View Mirage Workspace

7/23/2019 VMware Reference Architecture Horizon 6 View Mirage Workspace

1/65

VMware Horizon 6

Reference Architecture

T E C H N I C A L W H I T E P A P E R


2/65

VMware Horizon 6 Reference Architecture

T E C H N I C A L W H I T E P A P E R / 2

Table of Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Workload Test Result Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VMware Reference Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Horizon Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VMware vSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VMware Horizon with View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Horizon Reference Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Horizon Pod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Management Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Desktop Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Storage Sizing for Server Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Storage Sizing for Desktop Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Desktop Storage Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Desktop Storage Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ESXi Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CPU Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Desktop Memory Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RDSH Memory Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VMware vCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VMware vSphere Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VMware vRealize Operations for Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


3/65


T E C H N I C A L W H I T E PA P E R / 3

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

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual Desktop Machine Image Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Remote Desktop Services Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Blast Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PCoIP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Persona and User Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Desktop Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VMware SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Windows File Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Functional Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

Appendix A Bill of Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix B View Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Run Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


4/65



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,000users, 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 perESXi Host

Consolidation Ratioper 16 core ESXi host for RemoteDesktop Services (RDS) apps(light worker)

100 Users perESXi Host

Consolidation Ratioper 16 core ESXi host for Viewvirtual desktops (medium worker)

PassedAccess from Any Deviceto applications and desktops

using VMware Horizon Client

PassedAccess fromWorkspace Portalto View desktops and applications

PassedSingle Image Managementwith dedicated virtual desktops

managed by Mirage

14 MinutesSet up Hosted Applicationsand Virtual Desktopsfrom 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.

Desktops and applications

delivered through a single platform

Streamline management andeasily 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.


5/65



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 anapplication 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


6/65



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


7/65



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. Thisreference 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


8/65



ViewComposer

vCenter vRealize Operationsfor Horizon

MirageServers

File PrintServer

MirageMgmt

Workspace Portal vApp

View Connection Servers

View RDSH Apps & Desktops

NFS Shared Storage

SSD

RDSH Cluster Desktop Cluster

HTTPS/PCoIP

DMZ (HTTPS/PCoIP)

PCoIP

ESX, vCenter, View, Mirage, AD traffic

NFS Storage

View Virtual Desktops

Management Cluster

View Security Servers

Thin Client

HorizonClients

PCMac OS

iOS/Android

Kiosk

MSSQL

ActiveDirectory

SSD

Figure 4: Horizon with View Components


9/65



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

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

1 x Supermicro 2027TR Chassis


System Boards

16 Cores, 128 GB RAM

- Horizon 6 Server Workload VMs

VDI &RDSH 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


10/65

T E C H N I C A L W H I T E P A P E R / 1 0


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 enterprise-level 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 confidence 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 v irtual 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.
http://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdfhttp://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdfhttp://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdfhttp://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdf


11/65



VMware Mirage

VMware Workspace Portal

Core Infrastructure

vRealizeOperations

Manager

ActiveDirectory

vCenterServer

View

View Connection

Server

View

Composer

View Security

Server

Windows 7Full Clone

Windows 7Linked Clone

Windows 73D Desktop

Full-Clone and Linked-CloneVirtual Desktop Pools

RDSH-HostedDesktops and Applications

SaaS Apps

VMware Workspace

Portal VA

ThinApp Repository

Physical/ContainerizedDesktops

VMware Mirage

Servers

Figure 6: Horizon 6 Components


12/65



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

Switched Ethernet Network

Server Cluster

vRealize OperationsManager

View SecurityServer

View SecurityServer

View Connection Server View Connection Server

vCenter Server and View Composer

Horizon Management Block

WorkspacePortal

MirageManagement

Server

MirageServer

View Desktop Pools

Desktop Cluster

View RDSHDesktop Pools

Desktop Cluster

Shared Storage

Desktop Block

Figure 7: Horizon Pod and Management Block


13/65



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.


14/65



The management block has a single vSphere cluster that supports the Horizon server virtual machines shown in

Figure 8.

vSphere Cluster

vCenter Server 2x ViewSecurity Server

2x Workspace PortalVA

View

Composer

2x View (Int.)

Connection Server

2x View (Ext.)

Connection Server

vRealize OperationsManager UI VA

2x MirageServer

MirageManagement

Server

vRealize OperationsManager Analytics VA

3x ESXi 5.5 Host2.1 GHz. 128 GB RAM

2x 2 TB LUNEMC VNX5500 NFS

SQL Server ActiveDirectory

TEMP, ISO LUNEMC 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.


15/65



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.

ESXi Desktop

Cluster

Windows 7Full-Clone Pool

200 Desktops

Management BlockvCenter

Windows 7Linked-Clone Pool

800 Desktops

11x ESXi 5.5 Host2.9 GHz, 128 GB RAM

6x 2 TB LUNEMC VNX5500

NFS

32x RemoteDesktop Services

Host

TEMP, ISO LUNSEMC VNX5500 NFS

ESXi Desktop

Cluster

9x ESXi 5.5 Host2.9 GHz, 128 GB RAM

4x 1 TB LUNEMC VNX5500

NFS

Figure 9: Desktop Block Logical Infrastructure Design


16/65



Software-Defined Data Center

Horizon leverages the VMware SDDC platform to ensure performance, security, manageability, scalability,

availability, and reliability.

Horizon 6

VMware vSphere

vSGA /vDGA

LinkedClones

VirtualSAN

NetworkSpecifications

SESparse

DiskCBRC VAAI

Availability

ApplicationServices

Security Scalability

vMotion

Storage vMotionHA

Fault Tolerance

Data Recovery

vShield Zones

VMsafe

DRS

Hot Add

vCompute

InfrastructureServices

vStorage vNetwork

ESX and ESXi

DRS and DPM

MemoryOvercommit

VMFS

Thin Provisioning

Storage I/O Control

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.


17/65



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 Networkingsection for more information on virtual machine networking. Configuring athird-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 full-

clone 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 GBSSD

4x 1 TBRD Session

Hosts10GbE 10GbE

6x 2 TBFull Clones,

Linked Clones,Linked-Clone

Replicas

EMC VNX5500NFS

2x 2 TBAll Servers

1x 490 GB ISO1x 1 TB TEMP

EMC VNX5500NFS

2x 300 GBSSD

Figure 11:Storage Options
http://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdfhttp://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdfhttp://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdfhttp://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdf


18/65



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 datastorebe 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.

DISK TYPE SIZE IOPS

15 K RPM SAS 600 GB ~150

SSD 300 GB ~1,500+

Table 1: Disk Properties


19/65



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 productionimplementation. 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.

ATTRIBUTE VALUE

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 4

RAID 10 penalty for writes 2

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.


20/65



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.

ATTRIBUTE SPECIFICATION DESCRIPTION

Number of OS disks per

datastore

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.

OS disk datastore size 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.


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.

OS disk datastore size At least 376 GB Size is based on the following calculations:

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.


21/65




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.


Number of OS disks

per datastore

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, thedatastore can support 8 RDSH virtual machines.

OS disk datastore size At least 524 GB Size is based on the following calculations:

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 9 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


22/65



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)


23/65



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) = 100virtual desktops per host

DES KTOP PERFORMANCE METRIC RECORDED VALUE

Average number of CPUs per physical desktop

system

1

Average CPU utilization per physical desktop system 350 MHz

vCPU overhead 10%

ATTRIBUTE SPECIFICATION

Number of CPUs (sockets) per host 2

Number of cores per CPU 8

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


24/65



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.


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


25/65



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.


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 4

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


26/65



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 ofserver 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.

ATTRIBUTE VCENTER SERVER APPLIANCE

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.

CLUSTER NUMBER OF HOSTS DESCRIPTION

Management 3 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 9 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


27/65



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.

RDSH

VirtualDesktop

ServerWorkloads

EMC VNXNFS

VMNet-172

dvSwitch1

10GbENICs

Management

VMNet-10

vMotion

vmk

ExternalWorkloads

Storage

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.


28/65



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


29/65



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.

vSphere metrics(ESXi, VM, datastore,

data center)

Objects, metrics, KPIs,alert, events

Desktop metrics(PCoIP, CPU, memory,

disk, session info)

View topologyand events

Desktop VMs

vRealize OperationsManager 5.7 vApp

vRealize Operations Manager Console (Browser)

Database ServerView Connection Server

View EventsDatabase

View Adapter

Custom UI

vRealize Operations Manager Enterprise

View Adapter 1

V4H DesktopAgent

V4H DesktopAgent

vCenterServer

View Dashboards

Figure 15: VMware vRealize Operations for Horizon Architecture


30/65



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 theanalytics and the Administration Portal to perform management tasks.

ATTRIBUTE WEB UI APPLIANCE ANALYTICS APPLIANCE

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 guidewith no additional

modifications. After deploying the virtual appliance, the configuration steps are

On the Admin Web console Update tab deploy the vCenter Operations Manager for Horizon PAK file to

add the custom dashboards

Log in to vCenter Operations Manager for Horizon and create the adapter instance

Select the full metric set and set pairing credentials for the broker agent

Install the broker agent on a View Connection Server
http://pubs.vmware.com/vcops-view-15/topic/com.vmware.ICbase/PDF/vcops-view-15-installation-guide.pdfhttp://pubs.vmware.com/vcops-view-15/topic/com.vmware.ICbase/PDF/vcops-view-15-installation-guide.pdf


31/65



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.


32/65



View RDSHApps and Desktops

View VirtualDesktops

HTTPS

HTTPS (DMZ)

View, Workspace Portal Traffic

Private Cloud (vSphere)

Management Cluster

External Load Balancer

InternalLoadBalancer

https://myworkspace.company.com https://myworkspace.company.com

Workspace Portal VA x 2

Thin Client

HorizonClients

PCMac OS

iOS/Android

Kiosk

ActiveDirectory

ViewConnection

Servers

ThinAppRepository

Oracle/vPostgresDatabase

Figure 17: Workspace Portal Architecture


33/65



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 HorizonClient 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.

API

OS (SLES)

ConnectorServices

tcserver DB

API

OS (SLES)

ConnectorServices

tcserver DB

API

Workspace Portal VA

OS (SLES)

Connector ServicesCore Services

tcserver DB (vPostgres)

API

Workspace Portal VA

Workspace Portal VA

Workspace Portal VA

OS (SLES)

ConnectorServices

tcserver DB

Application Proxy / Reverse Proxy

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 RAM HDD

VIRTUAL

APPLIANCE

SIZING

8 8 GB 72 GB

Table 12: Sizing for a Single Workspace Portal VA for 30,000 Users


34/65



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. Inthis 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.


35/65



vRealize Operationsfor Horizon

ViewComposer

ConnectionServers

DesktopAdmin

vSphereAdmin

ViewAdministrator

Console

vSphereClient

File/Print/ThinAppSecurityServers

vCenter

VirtualDesktops

ActiveDirectory

HTTPS TCP 443PCoIP (Direct)UDP 4172

PCoIP UDP 4172HTTPS TCP 443

RDSHServers

SQL

VMware ESXi


VMware ESXi

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 viavCenter 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.


36/65



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 directingincoming 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 vSphereClient. 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.

COMPONENT QUANTITY VCPU VRAM HDD

View Connection Server 4 (2 internal, 2

external)

4 16 50 GB

View security server 4 (2 per external View

Connection Server)

4 16 40 GB

View Composer 1 4 16 30 GB


37/65



COMPONENT QUANTITY VCPU VRAM HDD

File print server 1 4 10 140 GB

SQL Server 1 4 16 140 GB

RDSH server 32 4 24 40 GB

Windows 7 desktops 1,000 1 1 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 arestored 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.


38/65



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.


Desktop OS Windows 7 Enterprise SP1 (32-bit)

Hardware VMware virtual hardware version 9

CPU 1

Memory 1024 MB

Memory reserved 256 MB

Video RAM Up to 128 MB

3D graphics Off

NICs 1

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
http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdfhttp://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdfhttps://my.vmware.com/web/vmware/details%3FdownloadGroup%3DVIEW-PLAN-300%26productId%3D320https://my.vmware.com/web/vmware/details%3FdownloadGroup%3DVIEW-PLAN-300%26productId%3D320https://my.vmware.com/web/vmware/details%3FdownloadGroup%3DVIEW-PLAN-300%26productId%3D320https://my.vmware.com/web/vmware/details%3FdownloadGroup%3DVIEW-PLAN-300%26productId%3D320http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdfhttp://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf


39/65



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.


Desktop OS Windows Server 2012 R2

Hardware VMware virtual hardware version 9

CPU 4

Memory 24 GB

Memory reserved 0 MB

Video RAM 128 MB

NICs 1

Virtual network adapter 1 VMXNet3 Adapter

Virtual SCSI controller 0 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 .
http://www.vmware.com/files/pdf/techpaper/vmware-horizon-mirage-reference-architecture-branch-office.pdfhttp://www.vmware.com/files/pdf/techpaper/vmware-horizon-mirage-reference-architecture-branch-office.pdf


40/65



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).

Virtual Desktop(Full Clone)

SQL

MirageWindows

File ServerMirageServer

MirageAdmin

MirageEdge Gateway

MirageConsole

MirageManagement

Server

Mirage

Server

ExternalPhysicalEndpoints

PhysicalEndpoints

Active

Directory


VMware ESXiVMware 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


41/65



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.

SERVER QUANTITY VCPU VRAM HDD

Mirage Management server

and Mirage server

1 4 16 190 GB

Mirage Server 1 4 16 190 GB

SQL Server Uses the same SQL Server as View

(see SQL Serversection for sizing)

Mirage Single-Instance Store 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.


42/65



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 ProviderThe 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.
http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdfhttp://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf


43/65



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 LayerCapturing

Mirage Server

Full-Clone Pool

Mirage ManagementServer

App Layer

Base Layer

App Layer

User-Defined

Layer(Optional)

Base Layer

App Layer

Base Layer

App Layer

Base Layer

Reference

CVD VM

VM-1 VM-2 VM-n Template VM

App Layer

Base Layer

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 continuewithout loss of user data or applications.


44/65



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

Documents

VMware Reference Architecture Horizon 6 View Mirage Workspace