VMware Horizon 6.1, Horizon View - 6.1 Administrator’s Guide
Administering View Cloud Pod
Architecture
VMware Horizon 6
Version 6.1
This document supports the version of each product listed and
supports all subsequent versions until the document is
replaced by a new edition. To check for more recent editions
of this document, see http://www.vmware.com/support/pubs.
EN-001719-00
Administering View Cloud Pod Architecture
You can find the most up-to-date technical documentation on the VMware Web site at:
http://www.vmware.com/support/
The VMware Web site also provides the latest product updates.
If you have comments about this documentation, submit your feedback to:
docfeedback@vmware.com
Copyright © 2015 VMware, Inc. All rights reserved. Copyright and trademark information.
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com
2 VMware, Inc.
Contents
Administering View Cloud Pod Architecture 5
Introduction to Cloud Pod Architecture 7
1
Understanding Cloud Pod Architecture 7
Configuring and Managing a Cloud Pod Architecture Environment 8
Cloud Pod Architecture Limitations 8
Designing a Cloud Pod Architecture Topology 9
2
Creating Cloud Pod Architecture Sites 9
Entitling Users and Groups in the Pod Federation 10
Finding and Allocating Desktops in the Pod Federation 10
Global Entitlement Example 12
Cloud Pod Architecture Topology Limits 12
Cloud Pod Architecture Port Requirements 13
Security Considerations for Cloud Pod Architecture Topologies 13
Setting Up a Cloud Pod Architecture Environment 15
3
Initialize the Cloud Pod Architecture Feature 15
Join a Pod to the Pod Federation 16
Create and Configure a Global Entitlement 17
Create and Configure a Site 19
Assign a Home Site to a User or Group 20
Test a Cloud Pod Architecture Configuration 21
Example: Setting Up a Basic Cloud Pod Architecture Configuration 22
VMware, Inc.
Managing a Cloud Pod Architecture Environment 27
4
View a Cloud Pod Architecture Configuration 27
View Pod Federation Health in View Administrator 29
View Desktop Sessions in the Pod Federation 29
Determine the Effective Home Site for a User 30
Add a Pod to a Site 30
Modifying Global Entitlements 31
Remove a Home Site Association 34
Remove a Pod From the Pod Federation 34
Uninitialize the Cloud Pod Architecture Feature 35
lmvutil Command Reference 37
5
lmvutil Command Use 37
Initializing the Cloud Pod Architecture Feature 40
Disabling the Cloud Pod Architecture Feature 41
Managing Pod Federations 41
3
Administering View Cloud Pod Architecture
Managing Sites 43
Managing Global Entitlements 46
Managing Home Sites 52
Viewing a Cloud Pod Architecture Configuration 54
Managing SSL Certificates 58
Index 61
4 VMware, Inc.
Administering View Cloud Pod Architecture
Administering View Cloud Pod Architecture describes how to configure and administer a Cloud Pod
Architecture environment in VMware Horizon® 6, including how to plan a Cloud Pod Architecture
topology and set up, monitor, and maintain a Cloud Pod Architecture configuration.
Intended Audience
This information is intended for anyone who wants to set up and maintain a Cloud Pod Architecture
environment. The information is written for experienced Windows or Linux system administrators who are
familiar with virtual machine technology and data center operations.
VMware Technical Publications Glossary
VMware Technical Publications provides a glossary of terms that might be unfamiliar to you. For definitions
of terms as they are used in VMware technical documentation, go to
http://www.vmware.com/support/pubs.
VMware, Inc.
5
Administering View Cloud Pod Architecture
6 VMware, Inc.
Introduction to Cloud Pod
Security
Server
User
View
Connection
Server
View
Connection
Server
Security
Server
View
Connection
Server
View
Connection
Server
Security
Server
Security
Server
London Pod
London Datacenter
Interpod
communication
Remote
desktop
New York Pod
New York Datacenter
Global Data Layer
Architecture 1
The Cloud Pod Architecture feature uses standard View components to provide cross-datacenter
administration, global and flexible user-to-desktop mapping, high availability desktops, and disaster
recovery capabilities.
This chapter includes the following topics:
“Understanding Cloud Pod Architecture,” on page 7
n
“Configuring and Managing a Cloud Pod Architecture Environment,” on page 8
n
“Cloud Pod Architecture Limitations,” on page 8
n
Understanding Cloud Pod Architecture
With the Cloud Pod Architecture feature, you can link together multiple View pods to provide a single large
desktop brokering and management environment.
A View pod consists of a set of View Connection Server instances, shared storage, a database server, and the
vSphere and network infrastructures required to host desktop virtual machines. In a traditional View
implementation, you manage each pod independently. With the Cloud Pod Architecture feature, you can
join together multiple pods to form a single View implementation called a pod federation.
A pod federation can span multiple sites and datacenters and simultaneously simplify the administration
effort required to manage a large-scale View deployment.
Figure 1‑1. Basic Cloud Pod Architecture Topology
In the example topology, two previously standalone View pods in different datacenters are joined together
to form a single pod federation. An end user in this environment can connect to a View Connection Server
instance in the New York datacenter and receive a session on a desktop in the London data center.
VMware, Inc.
7
Administering View Cloud Pod Architecture
Sharing Key Data in the Global Data Layer
View Connection Server instances in a pod federation use the Global Data Layer to share key data. Shared
data includes information about the pod federation topology, user and group entitlements, policies, and
other Cloud Pod Architecture configuration information.
In a Cloud Pod Architecture environment, shared data is replicated on every View Connection Server
instance in a pod federation. Entitlement and topology configuration information stored in the Global Data
Layer determines where and how desktops are allocated across the pod federation.
View sets up the Global Data Layer on each View Connection Server instance in a pod federation when you
initialize the Cloud Pod Architecture feature.
Sending Messages Between Pods
View Connection Server instances communicate in a Cloud Pod Architecture environment by using an
interpod communication protocol called the View InterPod API (VIPA).
View Connection Server instances use the VIPA communication channel to launch new desktops, find
existing desktops, and share health status data and other information. View configures the VIPA
communication channel when you initialize the Cloud Pod Architecture feature.
Configuring and Managing a Cloud Pod Architecture Environment
You use View Administrator and the lmvutil command-line interface to configure and manage a Cloud Pod
Architecture environment. lmvutil is installed as part of the View installation. You can also use View
Administrator to view pod health and desktop session information.
NOTE You cannot use View Administrator to create and manage Cloud Pod Architecture home sites. You
must use the lmvutil command to perform these tasks.
Cloud Pod Architecture Limitations
The Cloud Pod Architecture feature has certain limitations.
It does not support using the HTML Access feature. With HTML Access, end users can use a Web
n
browser to connect to remote desktops and are not required to install any client software on their local
systems.
It does not support using remote Windows-based applications hosted on a Microsoft RDS host.
n
It is not supported in an IPv6 environment.
n
8 VMware, Inc.
Designing a Cloud Pod Architecture
Topology 2
Before you begin to configure the Cloud Pod Architecture feature, you must make decisions about your
Cloud Pod Architecture topology. Cloud Pod Architecture topologies can vary, depending on your goals,
the needs of your users, and your existing View implementation. If you are joining existing View pods to a
pod federation, your Cloud Pod Architecture topology is typically based on your existing network topology.
This chapter includes the following topics:
“Creating Cloud Pod Architecture Sites,” on page 9
n
“Entitling Users and Groups in the Pod Federation,” on page 10
n
“Finding and Allocating Desktops in the Pod Federation,” on page 10
n
“Global Entitlement Example,” on page 12
n
“Cloud Pod Architecture Topology Limits,” on page 12
n
“Cloud Pod Architecture Port Requirements,” on page 13
n
“Security Considerations for Cloud Pod Architecture Topologies,” on page 13
n
Creating Cloud Pod Architecture Sites
In a Cloud Pod Architecture environment, a site is a collection of well-connected pods in the same physical
location, typically in a single datacenter. The Cloud Pod Architecture feature treats pods in the same site
equally.
When you initialize the Cloud Pod Architecture feature, it places all pods into a default site called Default
First Site. If you have a large implementation, you might want to create additional sites and add pods to
those sites.
The Cloud Pod Architecture feature assumes that pods in the same site are on the same LAN, and that pods
in different sites are on different LANs. Because WAN-connected pods have slower network performance,
the Cloud Pod Architecture feature gives preference to desktops that are in the local pod or site when it
allocates desktops to users.
Sites can be a useful part of a disaster recovery solution. For example, you can assign pods in different
datacenters to different sites and entitle users and groups to desktop pools that span those sites. If a
datacenter in one site becomes unavailable, you can use desktops from the available site to satisfy user
desktop requests.
See “Create and Configure a Site,” on page 19.
VMware, Inc.
9
Administering View Cloud Pod Architecture
Entitling Users and Groups in the Pod Federation
In a traditional View environment, you use View Administrator to create entitlements. These local
entitlements entitle users and groups to a specific desktop pool on a View Connection Server instance.
In a Cloud Pod Architecture environment, you create global entitlements to entitle users or groups to
multiple desktops across multiple pods in the pod federation. When you use global entitlements, you do not
need to configure and manage local entitlements. Global entitlements simplify administration, even in a pod
federation that contains a single pod.
View stores global entitlements in the Global Data Layer. Because global entitlements are shared data,
global entitlement information is available on all View Connection Server instances in the pod federation.
NOTE As a best practice, you should not configure local and global entitlements for the same desktop pool.
If you use both types of entitlements for the same desktop pool, the same desktop might appear as a local
and a global entitlement in the list of desktops that Horizon Client shows to an end user.
Each global entitlement contains a list of member users or groups, a list of the desktop pools that can
provide desktops for entitled users, and a scope policy. The desktop pools in a global entitlement can be
either floating or dedicated pools. You specify whether a global entitlement is floating or dedicated during
global entitlement creation.
A global entitlement's scope policy specifies where View looks for desktops when it allocates desktops to
users in the global entitlement. It also determines whether View looks for desktops in any pod in the pod
federation, in pods that reside in the same site, or only in the pod to which the user is connected.
Finding and Allocating Desktops in the Pod Federation
View Connection Server instances in a Cloud Pod Architecture environment use shared global entitlement
and topology configuration information from the Global Data Layer to determine where to search for and
how to allocate desktops across the pod federation.
When a user requests a desktop from a global entitlement, the Cloud Pod Architecture feature searches for
an available desktop in the pools that are associated with that global entitlement. By default, the Cloud Pod
Architecture feature gives preference to desktops in the local pod, the local site, and pods in other sites, in
that order.
For global entitlements that contain dedicated desktop pools, the Cloud Pod Architecture feature uses the
default search behavior only the first time a user requests a desktop. After the Cloud Pod Architecture
feature allocates a dedicated desktop, it returns the user directly to the same desktop.
You can modify desktop search and allocation behavior for individual global entitlements by setting the
scope policy and configuring home sites.
Configuring Scope Policy to Control Desktop Search
When you create a global entitlement, you must specify its scope policy. The scope policy determines the
scope of the search when the Cloud Pod Architecture feature looks for desktops to satisfy a desktop request
from the global entitlement.
You can set the scope policy so that the Cloud Pod Architecture feature searches for desktops only on the
pod to which the user is connected, only on pods within the same site as the user's pod, or across all pods in
the pod federation.
For global entitlements that contain dedicated desktop pools, the scope policy affects where the Cloud Pod
Architecture feature looks for desktops only the first time a user requests a dedicated desktop. After the
Cloud Pod Architecture feature allocates a dedicated desktop, it returns the user directly to the same
desktop.
10 VMware, Inc.
Chapter 2 Designing a Cloud Pod Architecture Topology
For information about configuring the scope policy for a global entitlement, see “Create and Configure a
Global Entitlement,” on page 17.
Configuring Home Sites to Control Desktop Placement
A home site is a relationship between a user or group and a Cloud Pod Architecture site. With home sites,
you can ensure that a user always receives desktops from a specific site rather than receiving desktops based
on the user's current location. The Cloud Pod Architecture feature includes the following types of home site
assignments.
Global home site
You can assign home sites to users and groups. If a user who has a home site
belongs to a group that is associated with a different home site, the home site
associated with the user takes precedence over the group home site
assignment.
Global homes sites are useful for controlling where roaming users receive
desktops. For example, if a user has a home site in New York but is visiting
London, the Cloud Pod Architecture feature looks in the New York site to
satisfy the user's desktop request rather than allocating a desktop closer to
the user. Global home site assignments apply for all global entitlements.
IMPORTANT Global entitlements do not recognize home sites by default. To
make a global entitlement use home sites, you must select the Use home site
option when you create or modify the global entitlement.
Per-global-entitlement
home site
When you use the lmvutil command to create a home site for a user or
group, you can use the --entitlementName option to specify a global
entitlement. Per-global-entitlement home sites override global home site
assignments.
For example, if a user who has a home site in New York accesses a global
entitlement that associates that user with the London home site, the Cloud
Pod Architecture feature looks in the London site to satisfy the user's
desktop request rather than allocating a desktop from the New York site.
When you use the lmvutil command with the --createGroupHomeSite option to create a per-globalentitlement home site, you must explicitly entitle all Active Directory user groups that contain the home site
users. If you have nested user groups, it is not sufficient to entitle only the parent group. In this case, the
parent group is explicitly entitled to the global entitlement, but the subgroups are not, and the
--createGroupHomeSite option fails.
Configuring home sites is optional. If a user does not have a home site, the Cloud Pod Architecture feature
searches for and allocates desktops as described in “Finding and Allocating Desktops in the Pod
Federation,” on page 10.
For information about creating home sites, see “Assign a Home Site to a User or Group,” on page 20. For
information about creating global entitlements, see “Create and Configure a Global Entitlement,” on
page 17.
VMware, Inc. 11
New York Datacenter
Pod Federation
Global Entitlement
“My Global Pool”
Members:
NYUser1
NYUser2
Pools:
pool1
pool2
pool3
Scope: Any
pool1 pool2
NY Pod
London Datacenter
pool3 pool4
LDN Pod
NYUser1
Administering View Cloud Pod Architecture
Global Entitlement Example
In this example, NYUser1 is a member of the global entitlement called My Global Pool. My Global Pool
provides an entitlement to three floating desktop pools, called pool1, pool2, and pool3. pool1 and pool2 are
in a pod called NY Pod in the New York datacenter and pool3 and pool4 are in a pod called LDN Pod in the
London datacenter.
Figure 2‑1. Global Entitlement Example
Because My Global Pool has a scope policy of ANY, the Cloud Pod Architecture feature looks for desktops
across both NY Pod and LDN Pod when NYUser1 requests a desktop. The Cloud Pod Architecture feature
does not try to allocate a desktop from pool4 because pool4 is not part of My Global Pool.
If NYUser1 logs into NY Pod, the Cloud Pod Architecture feature allocates a desktop from pool1 or pool2, if
a desktop is available. If a desktop is not available in either pool1 or pool2, the Cloud Pod Architecture
feature allocates a desktop from pool3.
For information about creating global entitlements, see “Create and Configure a Global Entitlement,” on
page 17.
Cloud Pod Architecture Topology Limits
A typical Cloud Pod Architecture topology consists of two or more View pods, which are linked together in
a pod federation. Pod federations are subject to certain limits.
Table 2‑1. Pod Federation Limits
Component Limit
Desktops 20,000
Pods 4
Sites 2
View Connection Server instances 20
12 VMware, Inc.
Chapter 2 Designing a Cloud Pod Architecture Topology
Cloud Pod Architecture Port Requirements
Certain network ports must be opened on the Windows firewall for the Cloud Pod Architecture feature to
work. When you install View Connection Server, the installation program can optionally configure the
required firewall rules for you. These rules open the ports that are used by default. If you change the default
ports after installation, or if your network has other firewalls, you must manually configure the Windows
firewall.
Table 2‑2. Ports Opened During View Connection Server Installation
TCP Port Description
22389 The Global Data Layer LDAP instance runs on this port. Shared data is replicated on every View
Connection Server instance in a pod federation. Each View Connection Server instance in a pod
federation runs a second LDAP instance to store shared data.
8472 The View Interpod API (VIPA) communication channel runs on this port. View Connection Server
instances use the VIPA communication channel to launch new desktops, find existing desktops, and
share health status data and other information.
Security Considerations for Cloud Pod Architecture Topologies
To use View Administrator or the lmvutil command to configure and manage a Cloud Pod Architecture
environment, you must have the Administrators role. Users who have the Administrators role on the root
access group are super users.
When a View Connection Server instance is part of a replicated group of View Connection Server instances,
the rights of super users are extended to other View Connection Server instances in the pod. Similarly, when
a pod is joined to a pod federation, the rights of super users are extended to all of the View Connection
Server instances in all of the pods in the pod federation. These rights are necessary to modify global
entitlements and perform other operations on the Global Data Layer.
If you do not want certain super users to be able to perform operations on the Global Data Layer, you can
remove the Administrators role assignment and assign the Local Administrators role instead. Users who
have the Local Administrators role have super user rights only on their local View Connection Server
instance and on any instances in a replicated group.
For information about assigning roles in View Administrator, see the View Administration document.
VMware, Inc. 13
Administering View Cloud Pod Architecture
14 VMware, Inc.
Setting Up a Cloud Pod Architecture
Environment 3
Setting up a Cloud Pod Architecture environment involves initializing the Cloud Pod Architecture feature,
joining pods to the pod federation, and creating global entitlements. You can optionally create sites and
assign home sites.
This chapter includes the following topics:
“Initialize the Cloud Pod Architecture Feature,” on page 15
n
“Join a Pod to the Pod Federation,” on page 16
n
“Create and Configure a Global Entitlement,” on page 17
n
“Create and Configure a Site,” on page 19
n
“Assign a Home Site to a User or Group,” on page 20
n
“Test a Cloud Pod Architecture Configuration,” on page 21
n
“Example: Setting Up a Basic Cloud Pod Architecture Configuration,” on page 22
n
Initialize the Cloud Pod Architecture Feature
Before you configure a Cloud Pod Architecture environment, you must initialize the Cloud Pod
Architecture feature.
You need to initialize the Cloud Pod Architecture feature only once, on the first pod in a pod federation. To
add pods to the pod federation, you join the new pods to the initialized pod.
During the initialization process, View sets up the Global Data Layer on each View Connection Server
instance in the pod, configures the VIPA communication channel, and establishes a replication agreement
between each View Connection Server instance.
This procedure shows how to use View Administrator to initialize the Cloud Pod Architecture feature. To
use the lmvutil command to initialize the Cloud Pod Architecture feature, see “Initializing the Cloud Pod
Architecture Feature,” on page 40.
Procedure
1 Log in to the View Administrator user interface for any View Connection Server instance in the pod.
You can initialize the Cloud Pod Architecture feature from any View Connection Server instance in a
pod.
2 In View Administrator, select View Configuration > Cloud Pod Architecture and click Initialize the
Cloud Pod Architecture feature.
VMware, Inc.
15
Administering View Cloud Pod Architecture
3 When the Initialize dialog box appears, click OK to begin the initialization process.
View Administrator shows the progress of the initialization process. The initialization process can take
several minutes.
After the Cloud Pod Architecture feature is initialized, the pod federation contains the initialized pod
and a single site. The default pod federation name is Horizon Cloud Pod Federation. The default pod
name is based on the host name of the View Connection Server instance. For example, if the host name
is CS1, the pod name is Cluster-CS1. The default site name is Default First Site.
4 When View Administrator prompts you to reload the client, click OK.
After the View Administrator user interface is refreshed, Global Entitlements appears under Catalog
and Sites appears under View Configuration in the View Administrator Inventory panel.
5 (Optional) To change the default name of the pod federation, select View Configuration > Cloud Pod
Architecture, click Edit, type the new name in the Name text box, and click OK.
6 (Optional) To change the default name of the pod, select View Configuration > Sites, select the pod,
click Edit, type the new name in the Name text box, and click OK.
7 (Optional) To change the default name of the site, select View Configuration > Sites, select the site,
click Edit, type the new name in the Name text box, and click OK.
What to do next
To add more pods to the pod federation, see “Join a Pod to the Pod Federation,” on page 16.
Join a Pod to the Pod Federation
During the Cloud Pod Architecture initialization process, the Cloud Pod Architecture feature creates a pod
federation that contains a single pod. You can use View Administrator to join additional pods to the pod
federation. Joining additional pods is optional.
You can also use the lmvutil command to join a pod to the pod federation. See “Joining a Pod to the Pod
Federation,” on page 41.
IMPORTANT Do not stop or start a View Connection Server instance while you are joining it to a pod
federation. The View Connection Server service might not restart correctly. You can stop and start the View
Connection Server after it is successfully joined to the pod federation.
Prerequisites
Make sure the View Connection Server instances that you want to join have different host names. You
n
cannot join servers that have the same name, even if they are in different domains.
Initialize the Cloud Pod Architecture feature. See “Initialize the Cloud Pod Architecture Feature,” on
n
page 15.
Procedure
1 Log in to the View Administrator user interface for a View Connection Server instance in the pod that
you are joining to the pod federation.
2 In View Administrator, select View Configuration > Cloud Pod Architecture and click Join the pod
federation.
3 In the Connection Server text box, type the host name or IP address of any View Connection Server
instance in any pod that has been initialized or is already joined to the pod federation.
4 In the User name text box, type the name of a View administrator user on the already initialized pod.
Use the format domain\username.
16 VMware, Inc.
Chapter 3 Setting Up a Cloud Pod Architecture Environment
5 In the Password text box, type the password for the View administrator user.
6 Click OK to join the pod to the pod federation.
View Administrator shows the progress of the join operation. The default pod name is based on the
host name of the View Connection Server instance. For example, if the host name is CS1, the pod name
is Cluster-CS1.
7 When View Administrator prompts you to reload the client, click OK.
After the View Administrator user interface is refreshed, Global Entitlements appears under Catalog
and Sites appears under View Configuration in the View Administrator Inventory panel.
8 (Optional) To change the default name of the pod, select View Configuration > Sites, select the pod,
click Edit, type the new name in the Name text box, and click OK.
After the pod is joined to the pod federation, it begins to share health data. You can view this health data on
the dashboard in View Administrator. See “View Pod Federation Health in View Administrator,” on
page 29.
NOTE A short delay might occur before health data is available in View Administrator.
What to do next
You can repeat these steps to join additional pods to the pod federation.
Create and Configure a Global Entitlement
You use global entitlements to entitle users and groups to desktops in a Cloud Pod Architecture
environment. A global entitlement provides the link between users and their desktops, regardless of where
those desktops reside in the pod federation. You must create and configure at least one global entitlement to
use the Cloud Pod Architecture feature.
A global entitlement contains a list of member users or groups, a list of the desktop pools that can provide
desktops for entitled users, and a set of desktop policies. You can add both users and groups, only users, or
only groups, to a global entitlement. You can add a particular desktop pool to only one global entitlement.
Prerequisites
Decide which type of global entitlement to create, the users, groups, and pools to include in the global
n
entitlement, and the scope of the global entitlement. See “Entitling Users and Groups in the Pod
Federation,” on page 10.
Decide whether the global entitlement should use home sites. See “Configuring Home Sites to Control
n
Desktop Placement,” on page 11.
Create the desktop pools to include in the global entitlement. For information about creating desktop
n
pools in View, see the Setting Up Desktop and Application Pools in View document.
Create the users and groups to include in the global entitlement.
n
Initialize the Cloud Pod Architecture feature. See “Initialize the Cloud Pod Architecture Feature,” on
n
page 15.
Procedure
1 Log in to the View Administrator user interface for any View Connection Server instance in the pod
federation.
2 In View Administrator, select Catalog > Global Entitlements and click Add.
VMware, Inc. 17
Administering View Cloud Pod Architecture
3 Define the global entitlement.
a Type a name for the global entitlement in the Name text box.
The name can contain between 1 and 64 characters. The global entitlement name appears in the list
of available entitlements for the user in Horizon Client.
b (Optional) Type a description of the global entitlement in the Description text box.
The description can contain between 1 and 1024 characters. The global entitlement name appears in
the list of available entitlements for the user in Horizon Client.
c Select a user assignment policy for the global entitlement.
The user assignment policy specifies the type of desktop pool that the global entitlement can
contain. You can select only one user assignment policy.
Option Description
Floating
Dedicated
d Select a scope policy for the global entitlement.
Creates a floating entitlement. A floating entitlement can contain only
floating desktop pools.
Creates a dedicated entitlement. A dedicated entitlement can contain
only dedicated desktop pools.
The scope policy specifies where to look for desktops to satisfy a desktop request from the global
entitlement. You can select only one scope policy.
Option Description
All sites
Within site
Within pod
View looks for desktops on any pod in the pod federation.
View looks for desktops only on pods in the same site as the pod to
which the user is connected.
View looks for desktops only in the pod to which the user is connected.
e (Optional) If users have home sites, configure a home site policy for the global entitlement.
Option Description
Use home site
Entitled user must have home site
Causes View to look for desktops in the user's home site. If the user
does not have a home site and the Entitled user must have home site
option is not selected, the site to which the user is currently connected
is assumed to be the home site.
Causes the global entitlement to be available only if the user has a
home site. This option is available only when the Use home site option
is selected.
f (Optional) If you are creating a floating entitlement, use the Automatically clean up redundant
sessions option to specify whether to automatically clean up redundant sessions.
Multiple floating desktop sessions can occur when a pod that contains a session goes offline, the
user logs in again and starts another session, and the problem pod comes back online with the
original session. When multiple sessions occur, Horizon Client prompts the user to select a session.
This option determines what happens to sessions that the user does not select. If you do not select
this option, users must manually end their own extra sessions, either by logging off in
Horizon Client or by launching the sessions and logging them off.
g Select the default display protocol for desktops in the global entitlement and specify whether to
allow users to override the default display protocol.
h Select whether to allow users to reset desktops in the global entitlement.
18 VMware, Inc.
Chapter 3 Setting Up a Cloud Pod Architecture Environment
4 Click Next and add users or groups to the global entitlement.
a Click Add, select one or more search criteria, and click Find to filter Active Directory users or
groups based on your search criteria.
b Select the Active Directory user or group to add to the global entitlement and click OK.
You can press the Ctrl and Shift keys to select multiple users and groups.
5 Click Next, review the global entitlement configuration, and click Finish to create the global
entitlement.
The global entitlement appears on the Global Entitlements page.
6 Select the desktop pools that can provide desktops for the users in the global entitlement you created.
a Log in to the View Administrator user interface for any View Connection Server instance in the
pod that contains the desktop pool to add to the global entitlement.
b In View Administrator, select Catalog > Global Entitlements.
c Double-click the global entitlement.
d On the Local Pools tab, click Add, select the desktop pools to add, and click Add.
You can press the Ctrl and Shift keys to select multiple desktop pools.
NOTE Desktop pools that are already associated with a global entitlement or that do not meet the
criteria for the global entitlement policies you selected are not displayed.
The Cloud Pod Architecture feature stores the global entitlement in the Global Data Layer, which replicates
the global entitlement on every pod in the pod federation. When an entitled user uses Horizon Client to
connect to a desktop, the global entitlement name appears in the list of available desktop pools.
NOTE If a View administrator changes the pool-level display protocol or protocol override policy after a
desktop pool is associated with a global entitlement, users can receive a desktop launch error when they
select the global entitlement. If a View administrator changes the pool-level virtual machine reset policy
after a desktop pool is associated with the global entitlement, users can receive an error if they try to reset
the desktop.
Create and Configure a Site
If your Cloud Pod Architecture topology contains multiple pods, you might want to group those pods into
different sites. The Cloud Pod Architecture feature treats pods in the same site equally.
You can also use the lmvutil command to create and configure a site. See “Managing Sites,” on page 43.
Prerequisites
Decide whether your Cloud Pod Architecture topology should include sites. See “Creating Cloud Pod
n
Architecture Sites,” on page 9.
Initialize the Cloud Pod Architecture feature. See “Initialize the Cloud Pod Architecture Feature,” on
n
page 15.
Procedure
1 Log in to the View Administrator user interface for any View Connection Server instance in the pod
federation.
VMware, Inc. 19
Loading...