6.2
Table Of Contents
- Administering View Cloud Pod Architecture
- Contents
- Administering View Cloud Pod Architecture
- Introduction to Cloud Pod Architecture
- Designing a Cloud Pod Architecture Topology
- Creating Cloud Pod Architecture Sites
- Entitling Users and Groups in the Pod Federation
- Finding and Allocating Desktops and Applications in the Pod Federation
- Global Entitlement Example
- Cloud Pod Architecture Topology Limits
- Cloud Pod Architecture Port Requirements
- Security Considerations for Cloud Pod Architecture Topologies
- Setting Up a Cloud Pod Architecture Environment
- Managing a Cloud Pod Architecture Environment
- View a Cloud Pod Architecture Configuration
- View Pod Federation Health in View Administrator
- View Desktop and Application Sessions in the Pod Federation
- Determine the Effective Home Site for a User
- Add a Pod to a Site
- Modifying Global Entitlements
- Remove a Home Site Association
- Remove a Pod From the Pod Federation
- Uninitialize the Cloud Pod Architecture Feature
- lmvutil Command Reference
- lmvutil Command Use
- Initializing the Cloud Pod Architecture Feature
- Disabling the Cloud Pod Architecture Feature
- Managing Pod Federations
- Managing Sites
- Managing Global Entitlements
- Managing Home Sites
- Viewing a Cloud Pod Architecture Configuration
- Listing Global Entitlements
- Listing the Pools in a Global Entitlement
- Listing the Users or Groups in a Global Entitlement
- Listing the Home Sites for a User or Group
- Listing the Effective Home Site for a User
- Listing Dedicated Desktop Pool Assignments
- Listing the Pods or Sites in a Cloud Pod Architecture Topology
- Managing SSL Certificates
- Index
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:
n
“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 and Applications 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
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 and applications that are in the local pod or
site when it allocates desktops and applications 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 pools that span those sites. If a datacenter in
one site becomes unavailable, you can use desktops and applications from the available site to satisfy user
requests.
VMware, Inc.
9