DevOps & Cloud Engineer. Building Control Cloud: one console to see, validate and operate your multi-cloud infrastructure. https://controlcloud.dev
The distinction between the three errors is what makes this useful in practice. I had not realized SkuNotAvailable fails during validation and never starts the deployment, while AllocationFailed is the only one where a retry can actually help. The tip about az vm list-skus with --all is also practical, since the portal hides the reason a size is missing and the Location versus Zone restriction changes the fix. One detail I would add from experience is how often stopped VMs still count against quota, because that is easy to miss when the error message points at capacity instead.
Agreed on the stopped VMs. The confusing part is that az vm list-usage lumps them into "Current in use", so the number looks right until you remember the three deallocated test boxes from last month. What helped me was listing them explicitly before asking for more quota: az vm list -d --query "[?powerState=='VM deallocated'].{n:name,size:hardwareProfile.vmSize}" -o table. Deleting two of those freed the family quota in minutes; the increase request would have taken a day. Which family did you hit it on?
OneLifeVibe
The distinction between the three errors is what makes this useful in practice. I had not realized SkuNotAvailable fails during validation and never starts the deployment, while AllocationFailed is the only one where a retry can actually help. The tip about az vm list-skus with --all is also practical, since the portal hides the reason a size is missing and the Location versus Zone restriction changes the fix. One detail I would add from experience is how often stopped VMs still count against quota, because that is easy to miss when the error message points at capacity instead.