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: Use this page solely when you have access to a first-gen tenant environment in the first-gen control plane. As described in KB-92424, the first-gen control plane has reached end of availability (EOA). See that article for details.
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.
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.

Pod Manager VMs

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

Starting with the v2204 service release, new Horizon Cloud on Microsoft Azure deployments are deployed with high availability configured by default. The deployment has two pod manager VMs.

Table 1. Pod Management VM Requirements - For the Pod's Core VMs, Not Including Gateway Configurations
VM Microsoft Azure VM Specification Quantity Description
Pod manager 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.

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 Horizon Cloud Pods - Maintenance and Updates for a description of the pod's blue/green update process.

Gateway-Related VMs

The following instances fall into this category of gateway-related VMs:

  • The Unified Access Gateway instances configured to function as secure gateways for the end-user clients accessing the pod-provisioned resources.
  • The gateway connector VM, which is created in the scenario where you choose to deploy the external gateway into a VNet separate from the pod's VNet. This gateway connector handles the cloud management operations in that scenario.
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 2. 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 Horizon Cloud Pods - Maintenance and Updates for a description of the pod's blue/green update process.
Table 3. 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.

Golden Images - General

A golden 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.

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

In Horizon Cloud, you can create both single-pod golden images and multi-pod golden images. Creation of either type is done using the console's automated Import VM from Marketplace wizard.

The automated wizard automatically uses a specific VM size by default. This default is based on its internal settings and on your choices in the wizard for the specific operating system (OS) and whether to include GPU.

Golden Image VMs

As of the v2207 service release, single-pod images and multi-pod images both have the same VM model requirements. Single-pod images are imported using the console's Imported VMs page. Multi-pod images are imported using the console's Multi-Pod Images page.

Table 4. Golden Image VM Requirements
VM Microsoft Azure VM Specification Quantity Description
Golden images

For GPU-enabled golden images, the system uses:

  • The Standard_NV12s_v3 (from the Standard NVSv3 Family vCPUs)
  • OS disk: Standard HDD 127 GiB

Varied, based on your needs

A golden image is a Microsoft Windows operating system VM that is configured so that Horizon Cloud can convert it into a published image.

A Windows single-session operating system VM provides the base used to create the VDI desktops.

An RDS-capable Windows operating system VM provides the base used to create the VMs in farms that provide session-based desktops and remote applications to your end users. This RDS-capable category includes both Windows Server OSes and Windows Enterprise multi-session OSes.

Each golden 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 golden image VMs.

The process of converting a golden 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 golden image at completion the publishing workflow. When you update a published image, the system powers the VM on again.

Note: When you duplicate a single-pod image using the console's Duplicate action, the system temporarily powers on the golden image's VM to obtain its configuration for the duplicate, and then powers it off again.

For information about how to create a single-pod golden image, see the topic Creating Desktop Images and Your Horizon Cloud Pods.

For non-GPU-enabled golden images using non-Windows 11 OSes, the system uses:

  • The Standard_DS2_v2 (from the Standard DSv2 Family vCPUs)
  • OS disk: Standard HDD 127 GiB

For non-GPU-enabled golden images with Microsoft Windows 11 OS or a Windows 11 OS Enterprise multi-session OS, the system uses:

  • The Standard_D4s_v3 (from the Standard DSv3 Family vCPUs)
  • OS disk: Standard HDD 127 GiB

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 5. 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 6. 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.

Special Case Support-Related Jump Box VM

If you make a support request to VMware and the support team determines the way to service that request is to deploy a temporary jump box VM for communication with the VMware-managed appliances, your subscription cores and quota will need to accommodate that deployment at that time. Permission will be requested from you for a support-related jump box deployment.

This jump box would be deployed under supervision of the VMware Support team and deleted under supervision of the VMware Support team when the VM is no longer needed in service of your support request.

Table 7. Temporary Support-Related Jump Box VM Requirements
VM Microsoft Azure VM Specification Quantity Description
Support-related jump box Linux Standard F Family:

Standard_F2 (2 cores, 4 GB memory)

OS disk: Standard HDD 30 GiB

1

This support-related jump box VM is designed for secure communications to the VMware-managed appliances in service of your support request to VMware Support.