By configuring your pod with additional tenant subnets, you are able to specify using those subnets for your farms and VDI desktop assignments. Instead of having all farm and desktop VMs connected to the pod's tenant subnet, you can specify for each farm and VDI desktop 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.
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.
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.
This screenshot illustrates that same pod after two VM subnets are added to it — tenant5 and tenant6.
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.
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
Removing Added VM Subnets from the Pod's Configuration
If there are no farms or VDI desktop assignments using a VM subnet, you can use the Edit Pod workflow to remove the subnet from the pod's configuration. Start the Edit Pod workflow, unselect those subnets from the displayed list, and save your changes.
About Using the VM Subnets for Farms and VDI Desktop 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.
|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.|