VMware Horizon 7 – Cloud Pod Architecture

Last Modified: Oct 17, 2017 @ 10:03 am


This post applies to all VMware Horizon versions 7.0 and newer


Cloud Pod Architecture lets you publish a single icon that load balances connections across multiple pools in multiple pods in multiple sites (datacenters).

  • Global Entitlements – Entitlements are the same thing as published icons. When you create an entitlement (local or global), you are publishing an icon from a pool.
    • For local entitlement, the icon is only published from one pool.
    • For global entitlement, the icon can be published from multiple pools. The pools can be in one pod or from multiple pods.
    • Don’t configure both global and local entitlements for the same pool.
    • A single pool can only belong to one global entitlement.
    • Horizon 6.2 and newer supports Global Entitlements for applications. However, it’s one application per global entitlement.
  • Pod Federation – Global entitlements can’t be created until a Pod Federation is created. This federation could be one pod or multiple pods.
    • The pods can be separated into sites. A site can contain multiple pods.
  • Global Load Balancing – Use NetScaler GSLB or F5 GTM to connect Horizon Clients to a globally available Horizon Connection Server. The connected Horizon Connection Server then uses Global Entitlements to select a site/pod/pool.
    • When a user launches a Global Entitlement, the Connection Server selects a pod based on the Global Entitlement Scoping, which can be All Sites, Within site, or Within Pod. This is from the perspective of the Connection Server the user is currently connected to. Horizon will prefer the local pod if possible.
    • Users or groups can be assigned to Home Sites. Global Entitlements can be configured to prefer Home Sites over the normal site/pod selection criteria.
  • Dedicated Assignment – For Dedicated Assignment pools, global entitlement only helps with the initial connection. Once the user is assigned to a desktop then that desktop is always selected. Users are not automatically provided with a desktop from another site if the site containing their dedicated desktop has gone down. The desktop request will fail because the dedicated desktop isn’t available. The administrator could configure a separate Global Entitlement for the users to provide a floating desktop until such time the original site recovers. That floating entitlement should be arranged to deliver desktops from other sites as required.
  • Firewall Ports – The Horizon Connection Servers participating in Cloud Pod Architecture communicate with each other over TCP 22389, TCP 22636, and TCP 8472. Make sure these ports are open.
  • RBAC – View Administrator includes a new administrator privilege: Manage Global Sessions. The regular Administrators role has access to multiple pods. The new Local Administrators role can only manage the local pod.

Limits in Horizon 7.3: Note: these limits seem to be increasing with each release of Horizon 7.

  • Max users = 140,000
  • Max Pods = 25
  • Max Sessions per Pod = 10,000
  • Max Sites = 7
  • Max Horizon Connection Servers = 175

Traffic flow (Rob Beekmans – VMware Horizon View Cloud Pod – unwanted routing?):

  • Use F5 GTM or NetScaler GSLB to connect users to a Horizon Connection Server in any pod. If active/active, use proximity load balancing to control which pod is initially accessed.
  • The Horizon Connection Server looks up the Global Entitlements to determine the destination pod for the Pool.
  • User’s PCoIP session goes through the initially connected Horizon Connection Server and across the DCI (Datacenter Interconnect) circuit to the remote pod. There’s no way to re-route Blast/PCoIP through a Horizon Connection Server in the remote pod. In fact, the Horizon Connection Servers in the remote pod are never accessed. You need sufficient DCI bandwidth to handle this Blast/PCoIP traffic.

For more information on multi-datacenter design for Horizon 7, see VMware Horizon 7 Enterprise Edition Multi-Site Reference Architecture, which is an 88 page document that includes the following:

  • Identity Manager
  • App Volumes
  • Horizon 7 Cloud Pod Architecture
  • User Environment Manager
  • SQL AlwaysOn Availability Groups
  • Nnetworking
  • Storage (e.g vSAN)
  • Active Directory
  • Distributed File System
  • Global Load Balancing

Initialize First Pod

  1. In View Administrator, on the left, expand View Configuration, and click Cloud Pod Architecture.
  2. On the right, click Initialize the Cloud Pod Architecture feature.
  3. Click OK to initialize.
  4. A status page is displayed.
  5. Click OK to reload the client.
  6. On the left, expand View Configuration, and click Cloud Pod Architecture.
  7. On the right, feel free to rename the federation by clicking the Edit button.

  8. On the left, expand View Configuration, and click Sites.
  9. On the right, click the Edit button to rename the Default First Site to be more descriptive.

  10. If you click the site to highlight it, you can Edit the Pod in the lower half to make the name more descriptive.

  11. If you add a Replica server after global entitlements are enabled, see VMware 2080521 Setting up the Cloud Pod Architecture feature on a replicated View Connection Server instance.
  12. See VMware 2080522 Restoring View Connection Server instances in a Cloud Pod Architecture pod federation.

Additional Pods – Join Federation

  1. Connect to View Administrator in the second pod.
  2. On the left, expand View Configuration, and click Cloud Pod Architecture.
  3. On the right, click Join the pod federation.
  4. Enter the name of an existing Horizon Connection Server that is already joined to the federation.
  5. Enter credentials, and click OK.
  6. The Join status is displayed.
  7. Click OK to reload the client.
  8. On the left, expand View Configuration, and click Sites.
  9. If this pod is in a different site, then click Add to create a new site.
  10. Give the site a name, and click OK.
  11. Highlight the first site.
  12. On the bottom, highlight the new pod, and click Edit.
  13. Rename the pod and put it in the 2nd site. Click OK.

Global Entitlements

Do not create both global and local entitlements for the same pool otherwise users might see two icons. Create the local pool, but don’t entitle it. Instead, create a Global Entitlement and add the local pool to it.

  1. In View Administrator, on the left, expand Catalog, and click Global Entitlements.
  2. On the right, click Add.
  3. In the Type page, select Desktop Entitlement or Application Entitlement, and click Next.
  4. In the Name and Policies page, give the entitlement (icon) a name. For Application Entitlements, it’s one entitlement per application so include the application name.
    1. Horizon 7.2 lets you configure tag restrictions (Connection Server restrictions) from this wizard.

      1. In Horizon 7.1, it’s only configurable from the lmvutil command. See Restrict Access to a Global Entitlement at VMware Pubs.
    2. Horizon 7.3 lets you select a Category Folder where the published icon will be placed on the client’s Start Menu. This applies to Horizon Client 4.6 and newer. See Configuring Start Menu Shortcuts for Desktop and Application Pools at VMware Docs.

  5. In the Policies section:
    1. The Use home site checkbox tells the global entitlement to respect user home sites.
    2. Change the Default display protocol to VMware Blast.
      1. In Horizon 7.3.1 and newer, if you set the Default display protocol to PCoIP, then HTML5 Blast won’t work unless Allow users to choose protocol is set to Yes. See VMware Communities Upgraded from 7.0.1 to 7.3.1, getting “You cannot access your applications or desktops”… error.  💡
    3. Check the box next to HTML Access.
    4. Horizon 7.2 adds a Pre-launch checkbox. Enable it on at least one application, and entitle the application to the users that need the Pre-launch feature.
    5. Horizon 7.3 adds a checkbox named Client Restrictions. When this is enabled, you can add Client Computer Accounts to an AD Group and entitle the published icon to that AD group. The published icon can then only be accessed from the client computers in the AD group. Notes:
    6. Make other selections.
  6. Click Next.
  7. In the Users and Groups page, add users that can see the icon. Click Next.
  8. In the Ready to Complete page, click Finish.
  9. Double-click the new global entitlement.
  10. On the Local Pools tab, click Add.
  11. Select the pools you want to add and click Add. Remember, only one app per Global Entitlement.
  12. Go to another pod and view the Global Entitlements.
  13. On the right, double-click the Global Entitlement.
  14. On the Local Pools tab, click Add to add pools from this pod.


  1. Once Global Entitlements are enabled, a new Search Sessions node is added to View Administrator. This allows you to search for sessions across federated pods.
  2. The Dashboard shows the health of remote pods.

Home Sites

Horizon 7 lets you configure Home Sites from within Horizon Administrator. For Global Entitlements, Horizon will prefer pools in the user’s Home Site before looking for pools in remote sites.

  1. On the left, click Users and Groups.
  2. On the right, switch to the Home Site tab, and click Add.
  3. Find a user or group for this home site, and click Next.
  4. Select the site to assign the users to and click Finish.
  5. Home Sites can be assigned to both users and groups. User assignments override group assignments.
  6. Each Global Entitlement can have its own Home Site configuration. Double-click a Global Entitlement, switch to the Home Site Override tab, and click Add.
  7. Since you could have a combination of default Home Site for user, default Home Site for group, and Global Entitlement-specific Home Sites, it’s helpful to know which Home Site is effective for each user and Entitlement. On the Users and Groups page, on the Home Site tab, if you switch to the Resolution sub-tab, you can find a user name, click Look Up and see which Home Site is assigned to the user for each entitlement.

Related Pages

10 thoughts on “VMware Horizon 7 – Cloud Pod Architecture”

  1. Carl – If a client deploys an active/active cloud pod arch and they want to do maintenance on one site (plenty of capacity on each side), how does the cloud pod arch behave? This used to easy prior, as before cloud pod, they stretched the connection server lay out between two sites, stopped a service and traffic was routed to the site no under maintenance.

    Thanks! Tim

  2. Carl, Thank you so much for such detailed information.

    I don’t suppose you have plans of writing one on Citrix’s latest 7.15 LTSR release.

Leave a Reply