Error code: AllocationFailed or ZonalAllocationFailed
Error message: “Allocation failed. We do not have sufficient capacity for the requested VM size in this region. Read more about improving likelihood of allocation success at https://aka.ms/allocation-guidance”
When you create a virtual machine (VM), start stopped (deallocated) VMs, or resize a VM, Microsoft Azure allocates compute resources to your subscription.
Microsoft is continually investing in additional infrastructure and features to ensure that they always have all VM types available to support customer demand. However, you may occasionally experience resource allocation failures because of unprecedented growth in demand for Azure services in specific regions.
This error could also be caused by a parameter issue with your Infrastructure as Code deployments, if you are to restrictive and it attempts to create a resource that isn’t supported - an example is a SKU that doesn’t support Accelerated Networking, or an attempt to deploy an Ultra SSD disk for a SKU that doesn’t deploy it.
Waiting for more Compute to be added to the Azure server clusters may not be an option, so what can you do?
Raise a Support Case
- Take a screenshot of the error
- Copy the Activity/Deployment ID
- Take note of the Region
- Take note of the Availability Zone.
Let Azure Support know; that Microsoft may already be aware, but raising a support request helps identify potentially impacted customers. If you know of other SKUs you need to deploy, you can let them know.
Purchase On-demand Capacity Reservation
On-demand Capacity Reservation enables you to reserve Compute capacity in an Azure region or an Availability Zone for any duration of time.
Unlike Reserved Instances, you do not have to sign up for a 1-year or a 3-year term commitment.
Once the Capacity Reservation is created, the capacity is available immediately and is exclusively reserved for your use until the reservation is deleted.
Capacity Reservations are priced at the same rate as the underlying VM size.
For example, if you create a reservation for the D2s_v3 VMs, you will start getting billed for the D2s_v3 VMs, even if the reservation is not being used.
So why would you purchase On-demand Capacity reservations?
- You are operating Azure workloads that scale out and run off a fresh image, like a Citrix farm and want to ensure the capacity is available for the minimum workloads you need.
- You have a project coming up where you need the capacity to be available.
Redeploy to another Availability Zone
The server cluster that ARM (Azure Resource Manager) attempted to deploy your workload may not have the necessary capacity, but another Availability Zone (datacenter) might.
Make sure your Virtual Machine is not in a Proximtry or Avalibility Group and do the following.
- Take note of the Availability Zone that your deployment failed (i.e. Availability Zone 1)
- Remove any resources that may have been created as part of the original failed deployment.
- Redeploy your workload and select another Availability Zone, such as (2 - if your failed deployment was in Zone 1)
Change the Virtual Machine version
By version, I don’t mean Generation 1 and Generation 2 Virtual Machines; I mean the version of underlying Compute; when you look at a VM SKU size, you will see:
[Family] + [Sub-family]* + [# of vCPUs] + [Constrained vCPUs]* + [Additive Features] + [Accelerator Type]* + [Version]
You can read more about Virtual Machine Naming conversions “here”.
The version of the VM series links to the underlying hardware associated with the Virtual Machine series; with most new hardware releases, the version changes; an example is: from v3 to v4.
#Tip: Microsoft may run a promotion on the pricing for early adopters from time to time, to move to the new version; they can be seen from the Azure Portal with “Promo” in the name.
- You can change the version of the SKU by looking in the Azure Portal, Sizing, and you should be select different versions of the same SKU; if you are at v5, try resizing to v4 - or the other way around.
Remember that changing the VM SKU will force the Virtual Machine to deallocate (stop), as it triggers ARM to stand up the Virtual Machine on different server clusters/hardware.
I have found that there are no noticeable decreases in performance for most workloads, but keep in mind you may be returning on older hardware - but it should get you going, and then you can update the SKU to the latest version later.