Pod deployments, deployments of the pod's gateway configurations, and standard operations require specific types and sizes of virtual machines (VMs) in your Microsoft Azure cloud capacity. Your subscription needs the appropriate quotas and configuration to support these VMs. When you are using the option to deploy the pod's external gateway in a separate subscription, that subscription needs the quota and configuration to support that external gateway configuration.

Important: The pod deployment wizard validates that your Microsoft Azure environment has sufficient quota of cores to build the pod and the gateway configuration you specified, if any. If the wizard determines there is not sufficient quota given the subscription information you specified in the wizard, an on-screen message will display and the wizard will not proceed to its next step.

Starting with the September 2019 release's pod manifest version, both for pods newly deployed at that version and pods updated to that version, each pod has a Microsoft Azure load balancer and Microsoft Azure Database for PostgreSQL server. When a pod is updated to the September 2019 manifest or later versions, the updated pod include a Microsoft Azure load balancer and Microsoft Azure Database for PostgreSQL server. The Microsoft Azure Database for PostgreSQL server is deployed using the Single Server deployment.

Note: GPU-enabled VMs are only available in some Microsoft Azure regions. See Microsoft Azure Products by region for details.

In the tables below, the VM specification column provides:

  • The series names that are used in the Microsoft Azure documentation
  • The vCPUs family names that are used in the quotas displayed in the Microsoft Azure portal
  • The specific name of the VM type from that family

To see a subscription's current quotas in the Microsoft Azure portal, navigate to All services > Subscriptions, click the subscription, and then click Usage + quotas. For more information about sizes for Microsoft Windows virtual machines in Microsoft Azure, see this topic and its subtopics in the Microsoft Azure documentation: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.

Jump Box VMs

Jump box VMs are temporarily created in your Microsoft Azure subscriptions for the purposes described in the tables below.

Table 1. Pod Jump box VM Requirements
VM Microsoft Azure VM Specification Quantity Description
Jump box Linux Standard F Family:

Standard_F2 (2 cores, 4 GB memory)

OS disk: Standard HDD 30 GiB

1 per pod A VM created in your Microsoft Azure environment and used during the initial pod creation, and during subsequent software updates on the environment. One jump box VM for each pod you deploy. This jump box VM is deleted automatically when the pod creation or update process is finished and the VM is no longer needed.
Note: A jump box VM is newly deployed for creating a pod, for building out an update's green components when the next version of the pod software is available, for orchestrating the blue/green update process on the pod, and for the process of adding a gateway configuration to an existing pod.
Table 2. When Having the External Gateway in a Separate VNet: Jump box VM Requirements
VM Microsoft Azure VM Specification Quantity Description
Jump box Linux Standard F Family:

Standard_F2 (2 cores, 4 GB memory)

OS disk: Standard HDD 30 GiB

1 per pod When optionally deploying the external gateway in its own VNet or own subscription, it needs a jump box VM separate from the jump box VM used for the pod's own core resources. This jump box VM is created in your Microsoft Azure environment in a separate resource group from the pod's jump box VM, and is used during the initial deployment of the external gateway configuration, and during subsequent software updates on that external gateway. One jump box VM for each external gateway in its own VNet or subscription that you deploy. This jump box VM is deleted automatically when the external gateway deployment or update process is finished and the VM is no longer needed.
Note: A jump box VM is newly deployed for creating one of these external gateways in its own VNet or subscription (during pod creation or when using the Edit Pod workflow to add the external gateway to an existing pod), for building out an update's green components for that external gateway when the next version of the external gateway or pod software is made available to you, for orchestrating the blue/green update process on that external gateway.

Pod Manager VMs

These VMs are generally considered the heart of the pod itself. The pod manager VMs are responsible for brokering the connection of the end-user clients to the Horizon agent software running in the pod-provisioned virtual desktops.

Table 3. Pod Management VM Requirements - For the Pod's Core VMs, Not Including Gateway Configurations
VM Microsoft Azure VM Specification Quantity Description
Pod without high availability enabled: Pod management instances Linux - Standard Dv3 Family:

Standard_D4_v3 (4 cores, 16 GB memory).

OS disk: Standard HDD 30 GiB

Note: If the Standard_D4_v3 type is not available in your Microsoft Azure region, the deployer instead uses Standard_D3_v2 (4 cores, 14 GB memory), from the Standard Dv2 Family.
1 per pod during steady-state operations

2 per pod during the end-to-end time for the pod's blue/green update process.

For a pod without high availability enabled, during steady-state operations, one VM exists, is powered on, and runs the pod. When a new pod manifest is made available to you by VMware Operations, and the system begins building out the green components for the pod's blue/green update process, a second instance is created and powered on. As part of the end-to-end update process, you schedule the time at which the system switches to using the green components. After the switch is completed, the pod is using the newly created VM for steady-state operations and the previously used one in the blue component set is stopped and then deleted.

Your environment's size must accommodate the two pod manager instances running side-by-side for the end-to-end update time period starting from the time when the system starts building out the pod's green components for the blue/green update process, to when update activities are completed and the pod is switched over to using the new green components. See the Administration Guide for a description of the pod's blue/green update process.

High- availability-enabled pod: Pod management instances Linux - Standard Dv3 Family:

Standard_D4_v3 (4 cores, 16 GB memory).

OS disk: Standard HDD 30 GiB

Note: If the Standard_D4_v3 type is not available in your Microsoft Azure region, the pod deployer instead uses Standard_D3_v2 (4 cores, 14 GB memory), from the Standard Dv2 Family.
2 per pod during steady-state operations

4 per pod during the end-to-end time for the pod's blue/green update process.

For a high-availability-enabled pod, during steady-state operations, two VMs exist, are powered on, and run the pod. When a new pod manifest is made available to you by VMware Operations, and the system begins building out the green components for the pod's blue/green update process, a second instance per pod manager VM is created and powered on. At that time, the total running pod manager VMs is four (4). As part of the end-to-end update process, you schedule the time at which the system switches to using the green components. After the switch is completed, the pod is using the two newly created VM for steady-state operations and the previously used two in the blue component set are stopped and then deleted.

Your environment's size must accommodate the four pod manager instances running side-by-side for the end-to-end update time period starting from the time when the system starts building out the pod's green components for the blue/green update process, to when update activities are completed and the pod is switched over to using the new green components. See the Administration Guide for a description of the pod's blue/green update process.

Gateway-Related VMs

Gateway-related VMs are:

  • The Unified Access Gateway instances configured to function as secure gateways for the end-user clients accessing the pod-provisioned resources.
  • When you deploy the external gateway into a separate VNet, the gateway connector VM that handles the cloud management operations on that external gateway configuration.
Note: Starting with the July 2020 quarterly release, you can choose from a list of supported VM models for the Unified Access Gateway instances when you are deploying a brand new gateway — either at the time of deploying the whole pod or when adding a new gateway. Prior to the July 2020 release, the gateway instances were required to use the Standard_A4_v2 VM model. The list of supported VM models that you can choose from in the on-screen wizard will depend on which VM models are available in the Microsoft Azure region into which you are deploying the gateway instances. The displayed choices will also depend on your VM quota in the Microsoft Azure subscription that you are using for the gateway deployment. The pod deployment wizard's VM Model menu will dynamically reflect the VM models that meet those requirements.

Software updates will maintain the gateway instances' VM models. Whatever the gateway instances' VM model is prior to a pod update will be their VM model after the update.

Table 4. Unified Access Gateway VM Requirements
VM Microsoft Azure VM Specification Quantity Description
Unified Access Gateway instances Starting in this release, you can choose from the following VM models for new gateway deployments.
  • Linux Standard Av2 Family — Standard_A4_v2 (4 cores, 8 GB memory), OS disk: Standard HDD 20 GiB
  • Linux Standard FSv2 Family:
    • Standard_F8s_v2 (8 cores, 16 GB memory), OS disk: SSD 32 GiB

Varied based on whether you choose to have an external or internal Unified Access Gateway configuration, or both types for the same pod.

For an external-only or an internal-only configuration:
  • 2 per pod during steady-state operations
  • 4 per pod during the end-to-end time for pod-related blue/green update activities.
For a pod with both an external and internal Unified Access Gateway configuration,
  • 4 per pod during steady-state operations
  • 8 per pod during the end-to-end time for pod-related blue/green update activities.
Unified Access Gateway is an optional feature that is deployed for your pod when you configure the gateway settings in the deployment wizard. If you decide to have Unified Access Gateway instances for the pod, your environment must accommodate these instances running during the pod's end-to-end blue/green update process. The number of steady-state instances depends on whether you choose to have both external and internal Unified Access Gateway configurations.

When you have only an external or only an internal Unified Access Gateway configuration, during steady-state operations, two instances exist, are powered on, and provide the Unified Access Gateway capabilities. During an update process, two additional instances are created and powered on to run the software updates on Unified Access Gateway. After the update is completed, the pod migrates to using the newly created VMs and the previously used ones in the blue component set are stopped and then deleted.

When you have both internal and external Unified Access Gateway configurations, during steady-state operations, four instances exist, are powered on, and provide the Unified Access Gateway capabilities. Two instances provide the capabilities for the external configuration and two instances provide the capabilities for the internal configuration. During an update process, two additional instances per configuration are created and powered on to run the software updates on Unified Access Gateway. After the update is completed, the pod migrates to using the newly created VMs and the previously used ones in the blue component set are stopped and then deleted.

Your environment's size must accommodate the indicated Unified Access Gateway instances running side-by-side for the end-to-end update time period starting from the time when the system starts building out the pod's green components for the blue/green update process, to when update activities are completed and the pod is switched over to using the new green components. See the Administration Guide for a description of the pod's blue/green update process.

Table 5. When Having the External Gateway in a Separate VNet: Gateway Connector VM Requirements
VM Microsoft Azure VM Specification Quantity Description
Gateway Connector instance Linux Standard Av2 Family:

Standard_A1_v2 (1 cores, 2 GB memory)

OS disk: Standard HDD 10 GiB

1 per this external-gateway type during steady-state operations

2 per this external-gateway type during the end-to-end time for pod-related blue/green update activities.

When the external gateway is deployed into a separate VNet, this VM is created and used for the cloud management operations on that external gateway configuration. During an update process, an additional instance is created and powered on to run the software updates on the Unified Access Gateway in the external gateway configuration. After the update is completed, migration to the newly created VM occurs and the previously used one is stopped and then deleted. If you decide to use this optional configuration, your environment must accommodate these instances running end-to-end during the pod-related blue/green update activities.

Master Image VMs

A master image is a Microsoft Windows operating system VM that is configured so that Horizon Cloud can convert it into a published image. Sometimes you'll see these VMs referred to as gold patterns or golden images.

Table 6. Image VM Requirements
VM Microsoft Azure VM Specification Quantity Description
Master images

Master images are either GPU-enabled or not, depending on your selection when you create them.

For GPU-enabled master images, the system uses:

  • The NV-series NV6 Standard (from the Standard NV Family vCPUs)
  • OS disk: Standard HDD 127 GiB

Varied, based on your needs

A master image is a Microsoft Windows operating system VM that is configured so that Horizon Cloud can convert it into a published image. An RDSH-capable Windows operating system VM provides the base used to create the RDSHs in farms that provide session-based desktops and remote applications to your end users. A Windows client operating system VM provides the base used to create the VDI desktops. Each master image is a combination of Microsoft Windows operating system and whether it is GPU-enabled or not. So if you want your pod to provide:

  • RDSH desktops using Microsoft Windows 2016 Datacenter, no GPU
  • RDSH desktops using Microsoft Windows 2016 Datacenter, with GPU

Then you need at least 2 master image VMs.

The process of converting a master image into a published image is sometimes called publishing the image, or also called sealing the image. The resulting published image is sometimes called a sealed image or an assignable image, because it is in a finalized state for use in assignments.

The system automatically powers off the master image when it is published (when you perform the Convert to Image action on the master image in the administrative console). When you update a published image, the system powers the VM on again.

Note: When you duplicate an image using the console, the system temporarily powers on the master image's VM to obtain its configuration for the duplicate, and then powers it off again.

For information about how to create a master image, see the topic Creating Desktop Images for a Horizon Cloud Pod in Microsoft Azure in the Administration Guide.

For non-GPU-enabled master images and Microsoft Windows client operating systems, the system uses:

  • The Standard_D4_v3 (from the Standard Dv3 Family vCPUs)
  • OS disk: Standard HDD 127 GiB

If Microsoft does not provide the Standard Dv3 Family in the Microsoft Azure region where you deployed the pod, the system uses the Standard_D3_v2 instead from the Standard Dv2 Family.

For non-GPU-enabled master images and Microsoft Windows RDSH-capable operating systems, the system uses:

  • The Standard_D2_v3 (from the Standard Dv3 Family vCPUs)
  • OS disk: Standard HDD 127 GiB

If Microsoft does not provide the Dv3-series in the Microsoft Azure region where you deployed the pod, the system uses the Standard_D2_v2 instead from the Standard Dv2 Family.

Farm VMs

RDSH farm VMs are the RDS-capable instances that provide session-based desktops and remote applications to your end users. You need at least one RDSH farm to deliver session desktops and one RDSH farm to deliver remote applications. To meet administrator or end-user needs, you can decide to deploy additional farms.

Note: In the current service release, you cannot deliver both session-based desktops and remote applications from the same farm.
Table 7. Farm VM Requirements
VM Microsoft Azure VM Specification Quantity Description
RDSH farm

You can customize the set of Microsoft Azure VM types that you want available for selection when creating farms in your pod. You can customize your own list from the set of Microsoft Azure VM sizes that are generally available in the standard Microsoft Azure regions. For more information about customizing the set of VM types available to use in your farms, see the Horizon Cloud Administration Guide.

When creating or editing a farm, you can customize the OS disk size of the farm's RDSH instances to change it from the system default value.

For specific details about the Windows VM sizes that are generally available in the standard Microsoft Azure regions, see the Microsoft documentation at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.

Note: For production environments, ensure the VM types you use for your farms have a minimum of two (2) CPUs. Meeting this criteria avoids unexpected end-user connection issues. This criteria is a result of the Horizon Agent recommendations to have a minimum of 2 CPUs to install or update Horizon Agent from version 7.x or later. This Horizon Agent criteria is stated in the Horizon product documentation starting at version 7.8 (the references to a 2 CPU minimum starts with this version 7.8 of Install Horizon Agent on a Virtual Machine).
Varied, based on your needs and how you have customized the VM sizes in your Horizon Cloud environment.

The power state of these VMs varies, depending on the farm configuration settings and the end-user demand.

VDI Desktop VMs

VDI desktop VMs are the instances that provide VDI desktops to your end users.

Note: A new feature in the July 2020 quarterly service release is the use of App Volumes features with pods in Microsoft Azure. When you use the console's App Volumes capture process to add native applications to your Horizon Cloud inventory, the system creates a VDI desktop assignment of two VMs to support the capture process. The VM type used for this system-generated assignment is the same model as is used for the published image you selected in the console for the application capture process.
Table 8. VDI Desktop VM Requirements
VM Microsoft Azure VM Specification Quantity Description
VDI desktops

You can customize the set of Microsoft Azure VM types that you want available for selection when creating VDI desktop assignments in your pod. You can customize your own list from the set of Microsoft Azure VM sizes that are generally available in the standard Microsoft Azure regions. For more information about customizing the set of VM types available to use in your VDI desktop assignments, see the Horizon Cloud Administration Guide.

Note: A small set of Microsoft Azure VM sizes that Microsoft has determined are not appropriate for VDI use cases are automatically omitted from use, such as Standard_B2ls and Standard_B1s.

When creating or editing a VDI desktop assignment, you can customize the OS disk size of the VDI desktop instances to change it from the system default.

For specific details about those Windows VM sizes, see the Microsoft documentation at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.

Note: For production environments, ensure the VM types you use for your VDI desktop assignments have a minimum of two (2) CPUs. Meeting this criteria avoids unexpected end-user connection issues. This criteria is a result of the Horizon Agent recommendations to have a minimum of 2 CPUs to install or update Horizon Agent from version 7.x or later. This Horizon Agent criteria is stated in the Horizon product documentation starting at version 7.8 (the references to a 2 CPU minimum starts with this version 7.8 of Install Horizon Agent on a Virtual Machine).
Varied, based on your needs and how you have customized the VM sizes in your Horizon Cloud environment.

The power state of these VMs varies, depending on the VDI desktop assignment settings and the end-user demand.