Balaji Ramamoorthy
Download CV

Azure VM will not start: AllocationFailed and OverconstrainedAllocationRequest

Real issue · 2 min read

What the allocation errors mean, how to check VM size restrictions, and the order of fixes that gets a stuck virtual machine running.

Share on LinkedIn

Symptom

A virtual machine will not start, resize or deploy. Azure returns one of these errors:

  • AllocationFailed: "Allocation failed. We do not have sufficient capacity for the requested VM size in this region."
  • OverconstrainedAllocationRequest: "Allocation failed. VM(s) with the following constraints cannot be allocated, because the condition is too restrictive."
  • ZonalAllocationFailed: the same problem, but in a specific availability zone.

Where it happened

Any region, most often with newer or larger VM sizes, with GPU sizes, or when a VM is started again after being stopped and deallocated for a while.

What I checked

  • Whether the VM size is offered in the region and zone, and whether it has restrictions on the subscription.
  • Whether the VM sits in an availability set, a proximity placement group or a specific zone. These limit which hardware Azure may use.
  • Whether other VM sizes from the same family start without trouble.
Get-AzComputeResourceSku -Location uksouth |
  Where-Object { $_.ResourceType -eq 'virtualMachines' -and $_.Name -eq 'Standard_D4s_v5' } |
  Select-Object Name, LocationInfo, Restrictions

A non-empty Restrictions value means the size is blocked for that subscription, region or zone. That is a quota or access request, not a capacity problem.

Root cause

The request asked for hardware that was not free at that moment. A VM that is stopped but not deallocated keeps its place on the hardware. A deallocated VM gives that place up, so starting it again needs fresh capacity in the same cluster, and the extra constraints (zone, set, placement group) make the choice smaller.

The fix

Work through these in order and stop when the VM starts:

  1. Wait a few minutes and try again. Capacity changes quickly.
  2. Deallocate the VM completely, then start it. Azure can then pick a different cluster.
  3. Change the size to another size in the same family, or a newer version of the same size, then start it.
  4. If a proximity placement group or an availability set is not needed, remove the VM from it. This takes a deallocation.
  5. Try another availability zone, or another region, and restore from a snapshot or backup if the data must move.
Stop-AzVM -ResourceGroupName rg-app -Name vm-app01 -Force
Get-AzVMSize -ResourceGroupName rg-app -VMName vm-app01 | Where-Object Name -like 'Standard_D*s_v5'
$vm = Get-AzVM -ResourceGroupName rg-app -Name vm-app01
$vm.HardwareProfile.VmSize = 'Standard_D4s_v5'
Update-AzVM -ResourceGroupName rg-app -VM $vm
Start-AzVM -ResourceGroupName rg-app -Name vm-app01

How to stop it happening again

  • Avoid pinning workloads to a single size, zone or placement group unless the design needs it.
  • For a critical VM, keep a tested plan to start it in a second zone or region.
  • Consider a capacity reservation for sizes the business cannot do without. It costs money while unused, so apply it only where the cost is justified.
  • Ask for quota early when a project will need many VMs of one size.