By configuring your pod with additional tenant subnets, you are able to specify using those subnets for your farms and VDI assignments. Instead of having all farm and desktop VMs connected to the pod's tenant subnet, you can specify for each farm and VDI assignment the specific subnet or subnets to which you want their VMs connected. Without having additional VM subnets configured on the pod, all of your farm and VDI desktop VMs get connected to your pod's tenant subnet by default. This feature to edit a pod to add multiple tenant subnets is available for pod manifests of 2298.0 or later. This feature is available for tenant environments configured to use Universal Broker and those configured for single-pod brokering.

Note: These tenant subnets are also known as VM subnets. In the documentation and in the Horizon Universal Console, you might see reference to both names.

The additional VM subnets can be in the same VNet as the pod (the pod manager VMs) or can be in separate VNets that are peered with the VNet in which the core pod resides. When using peered VNets, those peered VNets must be in the same subscription and Microsoft Azure region as the pod.

Important: When you add these additional VM subnets to your pod, you are responsible for adding the Network Security Groups (NSGs) using the Microsoft Azure portal to provide network isolation for them. The Horizon Cloud Edit Pod workflow does not create such NSGs for you.

When you use the pod deployer to create the pod in the first place, you specify a tenant subnet in the pod deployment wizard. That tenant subnet is known as the primary VM subnet. In the console, the pod detail's page's Networking section contains the information about the pod's tenant subnets — both the primary one and any added ones. The following screenshot illustrates a pod that has not had any additional tenant subnets added to it yet. In this case, the pod was deployed using named subnets. The subnet named tenant was selected in the pod deployment wizard for the pod's primary VM subnet. All of the core pod VMs, the gateway VMs, and the base image VMs have connections to this primary VM subnet.


Networking section of the pod's details page

This screenshot illustrates that same pod after two VM subnets are added to it — tenant5 and tenant6.


Screenshot illustrating the Networking section with two subnets added.

To add additional VM subnets, you use the Edit Pod workflow. See Editing Your Horizon Cloud Pod to Make Use of Multiple Tenant Subnets for Farms and VDI Desktop Assignments. A pod can be configured with up to 40 VM subnets total — its primary VM subnet and 39 additional VM subnets for a total of 40.

Operations that Happen as the Additional Subnets are Added

After you click Save & Exit in the Edit Pod workflow to add selected subnets, the system runs some background tasks that update the pod manager VMs and gateway VMs so that they can communicate over the added subnets with the farm VMs and desktop VMs that will eventually be attached to those subnets. If that update completes without errors, the added subnets are set to READY state. If an error occurs, the subnets are set to ERROR state.

This screenshot illustrates the added subnet in READY state.


Screenshot of the READY tool tip on a successfully added subnet

If a subnet shows as ERROR, you can use the Redeploy failed networks action to retry the system tasks. On the pod's details page, click … > Redeploy failed networks > .

Removing Added VM Subnets from the Pod's Configuration

When you no longer have a need to use a VM subnet that is set in the pod's configuration, you can use the Edit Pod workflow to remove that subnet from the pod's configuration. Perform this workflow to remove a VM subnet only when you no longer have any farms or VDI desktops assignments using that subnet. Start the Edit Pod workflow, unselect those subnets from the displayed list, and save your changes.

Important:
  • If you attempt to remove VM subnets that are being used by a farm or VDI desktop assignment, even though you can save your changes in the Edit Pod wizard, such subnets will not be deleted from the pod's configuration. In this situation, you can see the information about such subnets using the console's Monitor > Activity > Audit Logs.
  • Removing the primary VM subnet from the pod is not supported. That subnet is the pod's required tenant subnet.

About Using the VM Subnets for Farms and VDI Assignments

When the subnets are in READY state, you can use them in the definitions of farms and VDI desktop assignments. The farm VMs and VDI desktop VMs will get connected to the subnets that you specify in their definitions.

  • You can specify these VM subnets for your farms and VDI desktop assignments both when creating them and when editing them.
  • When you specify more than one VM subnet for a farm or VDI desktop assignment, the farm's or assignment's VMs are load balanced across the specified subnets.
    Note: When you create a farm or desktop assignment with these VM subnets, you have the option to select the pod's primary VM subnet (the pod's tenant subnet) along with the added VM subnets.
  • In the current release, after you have assigned a subnet to a farm or desktop assignment, you cannot later unassign that subnet from the farm or desktop assignment.

VM Subnet Status

The colored icons on the pod detail's page indicates the status of these subnets. In the console, hover over the icon to see the status label.

Status Description
PENDING After you run the Edit Pod workflow to add a new tenant subnet, the subnet starts out in PENDING status while the system background tasks run. The time for this status is typically brief.
READY If all operations related to the tenant subnet are successful, the indicator shows READY status.
ERROR If any operation related to the subnet fails, the indicator shows ERROR status.
DELETING After you run the Edit Pod workflow to remove a tenant subnet, its indicator shows DELETING status while the system background tasks are in progress.