This topic describes the remedies to take for common maintenance pre-check failures. When the system's pre-checks reveal conditions that would block maintenance activity on a pod, those errors are surfaced to you in the Horizon Universal Console so that you can take the actions required to remedy them.

Important: If you receive any notifications about pod update errors, you must take the specified actions to remedy the errors in a timely fashion. Time is of the essence. Failure to act to remedy those errors in the time that VMware requires, the pod will go into an unsupported state due to the failure to remedy the pod update process. .

As described in Horizon Cloud Pods - Maintenance and Updates, the system notifies you of the maintenance-blocking conditions that are under your control in your Microsoft Azure environment. Because the remedy is in your control and cannot be resolved by VMware, if you see notification of update errors in the console or you receive a notification email about such errors, you must complete the actions to resolve them and then contact VMware support to continue the maintenance activity.

Update-Blocking Errors that can Typically Occur

These are the update-blocking errors that can typically occur and which you can remedy in your Microsoft Azure environment.

Subscription does not have enough of the appropriate cores (vCPUs) or VM sizes available to instantiate all of the VMs for the parallel to-be VMs.
When the green components are built out, for each VM in your current pod, another VM gets created. As a result, you will have a duplicate number of pod manager VMs and Unified Access Gateway VMs from the time the green components are built out until the migration from the blue components to green components occurs at the time you scheduled in the console. To accommodate creating these green VMs, your subscription's quota levels for cores (vCPUs) from the relevant Microsoft VM families must be enough to encompass the parallel to-be VMs along with the quota you have already used from that subscription for its existing associated pods. See for the necessary cores for the various VM types and usages.
Pod is currently offline, or is not currently able to communicate with Horizon Cloud.
On the Capacity page, verify that the to-be-updated pod is reporting online status. Log in to the Microsoft Azure portal and check if the pod manager VM and its Unified Access Gateway VMs (if your pod has those) are running. If a VM is not running, power it on. For details about the resource groups in which those VMs are located, see Resource Groups Created For a Pod Deployed In Microsoft Azure.
Permission to create or delete resource groups is not enabled for this Microsoft Azure subscription.
The system pre-check validates that the service principal associated with this pod has the required permissions that the service requires. If the permission to create or delete resource groups is not enabled in the pod's subscription, that automation is blocked. To remedy this situation, follow the validation's guidance message on how to enable the required permissions using the Microsoft Azure Portal. For more information about the permissions that the service requires the service principal to have to perform the operations required by the service, read Operations Required by Horizon Cloud in Your Microsoft Azure Subscription.

Quota and Cores Needed For the Time from Deploying the Green VMs to When the Migration From the Blue VMs is Completed

If you are notified about an update error due to lack of available cores, use the following table to see the additional quota you need. For the various VM types used in the current as-is pod, the table at the end of this topic describes the quota used by those types, the additional quota needed when the green pod VMs are created, and the total quota needed for running both the blue and green VMs from when the green VMs are created until the migration to the green build-out completes. For details about the VM family types and cores used by a pod, see the VM requirements for a pod documentation topic in the Deployment Guide.

VM Types and Their Cores Description Total Quota for Running Blue VMs and Green VMs Until Switch to Green is Complete
Standard_D4_v3 VM type, 4 cores each
Note: If the Standard_D4_v3 type is not available in your Microsoft Azure region, your pod is typically using Standard_D3_v2 VM type. That type also uses 4 cores.
This VM type is used for the pod manager VMs.
For a pod with a single manager VM
Your quota must allow for the 4 cores of the existing (blue) manager VM plus an additional 4 cores for the parallel to-be manager VM. Eight (8) cores to cover this usage.
For a pod with high availability enabled, that has two manager VMs
Your quota must allow for the 8 cores of the existing (blue) manager VMs (2 VMs of 4 cores each) plus an additional 8 cores for the parallel to-be manager VMs. Sixteen (16) cores to cover this usage.
Depending on what you chose when deploying the pod:
  • Standard_A4_v2 VM type (has 4 cores)
  • Standard_F8s_v2 (has 8 cores)
This VM type is used for the Unified Access Gateway VMs in your pod's gateway configurations. The number of cores your subscription needs to support depends on which gateway types are configured on your pod.
For a pod with only an external gateway
That external gateway has two Unified Access Gateway VMs, therefore 2 VMs times the number of cores they have each. For the to-be set, your quota must allow for that total number of cores of the existing (blue) Unified Access Gateway VMs plus an additional duplicate number cores for the parallel green Unified Access Gateway VMs.
  • For example, if your VMs are the Standard_A4_v2 with 4 cores each, you need 2 times 4 times 2 equals 16 cores to cover this usage.
  • If your VMs are a VM size with 8 cores each, you need 2 times 8 times 2 equals 32 cores to cover that usage.
For a pod with only an internal gateway
That gateway has two Unified Access Gateway VMs, therefore 2 VMs times the number of cores they have each. For the to-be set, your quota must allow for that total number of cores of the existing (blue) Unified Access Gateway VMs plus an additional duplicate number cores for the parallel green Unified Access Gateway VMs.
  • For example, if your VMs are the Standard_A4_v2 with 4 cores each, you need 2 times 4 times 2 equals 16 cores to cover this usage.
  • If your VMs are a VM size with 8 cores each, you need 2 times 8 times 2 equals 32 cores to cover that usage.
For a pod with both types of gateways
That gateway has four Unified Access Gateway VMs, so 4 VMs times the number of cores they each have. For the to-be set, your quota must allow for 4 times the cores of the existing (blue) Unified Access Gateway VMs plus times two again for the parallel green Unified Access Gateway VMs.
  • For example, if your VMs are the Standard_A4_v2 with 4 cores each, you need 4 times 4 times 2 equals 32 cores to cover this usage.
  • If your VMs are a VM size with 8 cores each, you need 4 times 8 times 2 equals 64 cores to cover that usage.