Reading Time: 14 minutes

VMware Horizon is an End User Computing (EUC) solution that simplifies administration and delivery of personalized virtual desktops, remote sessions, and applications.

The Virtual Desktop Infrastructure (VDI) part (in past called VMware View) consists of several components and delivers a secure optimized virtual desktop infrastructure:

  • Virtual Desktops are the virtual machines hosted on a VMware vSphere infrastructure usually with Windows client OS (but also Linux and Windows Server are supported). Horizon can also manage physical PC, RDSH server (for remote desktop and/or remote applications).
  • Desktop pools are a collection of multiple virtual desktops, usually with a common image. VMware instant clones or linked clones (no longer supported in Horizon 8) can be used to share the common image and optimize space.
  • Horizon Clients are the endpoints used by the authorized users to access their virtual desktops, with any device (Windows, Mac, iOS, Linux, and Android) from any (enabled) network. Note that you can also use a browser as a client with the HTML5 interface (useful for example for Chrome OS devices).
  • Network Protocols used by the horizon clients to access the virtual desktops. Horizon support Microsoft RDP, Teradici PCoIP and VMware Blast.
  • Connection Servers are the core management component of VMware Horizon used to defines virtual desktop pools, applications, permissions, access, …. They also act as a connection broker for the clients in the local network.
  • Unified Access Gateway (UAG) is a Unified Gateway designed to protect desktop and application resources to enable remote access from the internet.
  • App Volume Manager is a console for managing configuration, creation of AppStacks, and assignment of AppStacks and writable volumes.

This describes a single Horizon pod, but you can have more pods (distributed also across different cloud) and federate and/or manage them together.

Kemp VLM overview

The Kemp Virtual LoadMaster (VLM) is a highly efficient load balancer and application delivery controller (ADC) that supports the major application workloads with easy-to-use templates to simplify and speed-up the deployment and configuration.

LoadMaster is available as a dedicated hardware appliance or as a Virtual Appliance (VLM). The virtual appliance is available on leading cloud providers (Azure and AWS and their Government variants) and the major on-premises hypervisors (VMware vSphere, Microsoft Hyper-V, XEN, KVM and VirtualBox).

Note that regardless of where Virtual LoadMasters are deployed, a consistent administration interface is presented via Web UI, API and Kemp 360 Central. Kemp 360 Central provides cross-platform configuration and monitoring of load balancing resources to simplify the administration of multi-load balancer environments. 

Why use a 3rd party LB with VMware Horizon?

The short answer is because you need it for production and a redundant environment and because VMware does not provide any embedded load balancer (LB) in the VMware Horizon deployment (unless you have also a NSX deployment).

Most of the Horizon components can be redundant:

  • Connection servers: you can have up to 7 for each pod
  • UAG: each can manage max 2000 connections, but you can use more than one
  • AppVolume Manager: you can scale with more than one

In order to provide not only redundancy and availability, but also to scale the performance and have active-active components, a proper load balancer is needed in all these cases.

Note that other VMware products (like identity manager) may require an external load balancer in a full redundant and scalable architecture.

In the rest of this document we will focus only on the connection servers and UAG components.

Note that you will need at least a pair of load balancers for availability and redundancy purposes. But with UAG you will need a dedicated LB pair, because for security reasons those components are in the DMZ network.

Why use Virtual LoadMaster (VLM) with VMware Horizon?

First question may be why should you use a VLM and not the hardware appliances? Basically the answer could be for flexibility purpose and to use a software defined model.

If you have a full deployment, only for the View part, you need at least four LB (2 for the internal network + 2 for the DMZ). However with a VLM you just have to spin up new VMs.

Also for backup and deployment purposes you will benefit from a VLM approach, because you can backup all of the VMs in your infrastructure (including the VLM) and you can also automate the build of a new infrastructure (for example, using Terraform) using an Infrastructure as a Code approach.

Note that the automation the configuration of LoadMaster is possible both for VLM and hardware appliances due to the powerful LoadMaster API that enables automation (for example, with RESTful or PowerShell) of the load balancer configuration and administration.

The second question is why Kemp and not a generic LB? There are a lot of different answers, but mainly the reasons are simplicity, flexibility and effectiveness.

For VMware Horizon the Kemp LoadMaster can be used to load-balance the VMware Unified Access Gateway, Connection Servers, Identity Manager, App Volume Manager and it has specific templates to simplify this configuration and reduce possible mistakes.

It’s not just to balance some ports: Kemp LoadMaster offers advanced Layer 4 and Layer 7 server load balancing, SSL/TLS offload and acceleration, and a multitude of other advanced Application Delivery Controller (ADC) features.

SSL/TLS offload could be an interesting option to be considered – for more information see:

The last reason is the flexibility in the different license models that can match your specific needs and use cases.

For more information, see the VLM datasheet at:

Configuring VLM for Horizon

There is a great Kemp deployment guide for Horizon 7 with a lot of information and detailed procedures:

Note that from a load balancing point of view the components and configuration for Horizon 8 remain the same.

Deployment type

Kemp offer virtual LoadMaster appliances with capacities of 500Mbps, 3Gbps and unlimited and they may be deployed as highly available (HA) pairs for resilience.

How many VLM? As written in a fully redundant deployment (HA configuration) with UAG you will need 2+2 VLM, one pair in the external/DMZ network, one in the internal. Each pair works in an active-standby mode. Note that the internal pair can balance not only connection servers, but also other internal components, like AppVolume Managers.

In most cases the HA configuration is enough to manage your traffic and easier to manage and troubleshoot.

For more information see:

VLM installation and setup

Installing the Kemp LoadMaster load balancer is simple enough. Just download a ZIP file that contains the OVF files (and also the Installation Guide and the release notes) for VMware vSphere and deploy it like any other virtual appliance.

There are a lot of guides, posts and articles with step by step procedures, included this guide on the Kemp support site:

Starting with LoadMaster Operating System (LMOS) version 7.2.50 the VLM for vSphere environment has the following requirements:

  • Virtual hardware version 10 (note that you can upgrade to a higher virtual hardware, if needed)
  • VMware ESXi 5.5 and above
  • VMware vCenter Server 5.5 and above

The virtual appliance will generate a VM with the following settings:

  • 2 x virtual CPU in 2 virtual core per virtual socket (suggested to reserve 2 GHz)
  • 2 GB RAM
  • 16 GB disk space (sparse where possible) connected to a PVSCI controller
  • One or two virtual network interfaces with VMXNET3 driver (note that a static MAC address is needed due to the Kemp license being tied to the MAC address)
  • VMware Tools are guest managed

When the VM is running you can easily set up the network configuration using the Quick Setup connected to the console of the VLM.

The default administrator credentials are:

  • Default user: bal
  • Default password: 1fourall

When the VLM is configured with the proper network settings you can just manage and configure it through the web interface (just point your browser to the VLM IP).

Then repeat the procedure for all the other VLM. For an HA (or cluster) deployment you will enable this feature later from the web interface.

So what about Infrastructure as a Code? Which options are available to automate the Kemp VLM deployment and configuration?

Depending on which tool are you using there are different resources, for example:

Of course automation is not limited to the LB part, but you can extend it to the entire infrastructure. Building an entire Horizon pod using automation can be very interesting for large and/or cloud environments.

VLM configuration

There are some generic settings that are global.

  • For example; in an HA configuration you will need some specific setting on virtual switches:
  • Ensure that MAC Address changes and Forged Transmits are both selected and set to Accept. Ensure this is forced (hard coded) on the port group as any changes to the vSwitch will affect all port groups by default.
  • Set the Notify Switches option to No to prevent the transmission of RARP packets from being sent every time a Virtual Machine is powered on (this is needed when using HA and the VLM are on different hosts, for a better resiliency).

If you plan to balance the UAG, then additional settings are recommended at VLM level (see page 16 and 17 of the Deployment Guide for VMware Horizon 7):

  • It is recommended that you change the Always Check Persist option to Yes – Accept Changes
  • In a two-armed setup Subnet Originating Requests should be enabled on LoadMasters with firmware version 7.1-16 and above.

Now you can configure the LB services for Horizon.

For connections servers and UAG, LoadMaster supports the forwarding of VMware traffic on the following ports:

HTTPSClient authentication and ongoing framework traffic443
PCoIPSupport the PCoIP protocol4172
BlastSupport the VMware Blast protocol8443
RDPSupport the RDP protocol3389

But the best way to configure a Kemp LB for a specific service is to use a template.

For Horizon you can download the proper and official templates from

Then add the template in VLM from Virtual Services > Manage Templates > Add New Template

When uploaded you will see the different templates in the same menu:

LB for Connection Servers

Connection servers are the core and mandatory component of a Horizon environment and as written you can have up to seven in each pod. All of them replicate the data together but do not distribute the connection and do not manage the availability across the different servers.

For this reason, you need an external LB like VLM. Using a solution like multiple DNS aliases does not provide the right scalability and availability level.

The first step for the configuration is to create on the VLM the Connection Server Virtual Services by choosing Virtual Services > Add New:

Remember to select the VMware Connection Server template, that will configure the proper settings.

Now you need, at least, to specify the real server (the connection server FQDN or IP):

Two rows will appear in Virtual Services > View/Modify Services.

One for port TCP 80 (a simple redirect) and one for port TCP 443 for the control and management protocol.

Note that in an internal network the Horizon Client will connect first on the connection servers (through the LB VIP) and then they will connect directly with the entitled virtual desktop. Unless you specify that all connections must pass thought the connection servers (this case will be not considered and usually it’s not used for internal networks).

LB for UAG

In order to provide external access to your virtual desktop, in the past there was a Secure Server role used to separate, secure and control the external access from the internal access.

The Secure Server has become deprecated and is no longer supported (in the latest version VMware Horizon 2006 it does not exist and it’s not possible upgrade from a previous version). VMware Unified Gateways (UAG) have replaced this component.

Note that UAG already has a built-in high-availability feature, but it only works in an active-standby mode. It could be useful and simple for an environment with less than 2000 external connections, otherwise you will need more UAGs in active-active mode. In this case an external LB is needed.

A critical aspect to consider with UAG is how to manage persistency and sessions affinity.

The Deployment Guide for VMware Horizon 7, on page 19, describes three main configuration options for session affinity:

  • Source IP Affinity
  • Multiple Port Number Groups
  • Multiple VIPs

Let’s consider only IP Affinity mode because it’s simpler and can be applied in most cases.

The different UAG appliances will be configured with the virtual name and virtual VIP of the LB virtual server:

Note that only RDP and Blast protocol can be fully tunneled on a single SSL/TLS port (443 by default), PCoIP instead requires also the 4172 TCP/UDP ports to work properly. For this reason it is becoming much more common disable PCoIP on the UAG and just use Blast. Starting with Blast Extreme and Horizon 7.10 ( this has become the preferred protocol and almost has feature parity with PCoIP (plus several advantages like the HTML5 client support).

The Virtual Service configuration will depend on the configuration described before because you have to download and import the proper template:

Note that you can import all those templates and the important aspect is to choose the right one when you create the Virtual Service for UAG.

For example; for Source IP Affinity the template will create a set of rules like this:

You must add the real servers (the UAG external IPs) and you can delete the rules that are not needed for your environment. If only RDP or Blast are used, potentially the only mandatory lines are the first two.

LB for hybrid or multi-cloud environments

There is an interesting deployment topology for the Kemp LB, suitable for hybrid or multi-cloud VDI environments: the LoadMaster Hybrid topology.

Global Server Load Balancing (GSLB) enables multi-data center and multi-cloud resilience by leveraging service resource awareness and DNS to steer traffic across geographically distributed pools based on defined business logic. When deployed across multiple data centers, provides application load balancing at geographic scale – across town or across the globe – using any mix of hardware, virtual and cloud platforms. For more information see

But note that also VMware has a solution for this specific case and it’s called Universal Broker.

Universal broker service can connect end-users to their personal desktop in any pod, globally, anywhere (on-premises and in the public cloud) and minimizes network traffic on the corporate LAN.

It’s one of the specific SaaS services offered by VMware for VDI environment multi-cloud or hybrid cloud.

For more information see:

Anyway, there are some cases where the Kemp solution can be considered instead of the Universal Broker. For example; in a geographic multi-pod environment where SaaS external components are not allowed.