Azure VM Stuck in ProvisioningState/failed After Resize: Spot Instance Fixes

Cause #1: Spot Capacity Is Gone (Most Common)

You resized a spot VM and now it's stuck in ProvisioningState/failed. Nine times out of ten, it's because Azure evicted your spot capacity the moment you tried to resize. Spot instances run on spare capacity. When you resize, Azure has to reallocate the VM to a new host with the new size. If there's no spare capacity for that new size in your region, the allocation fails and the VM sits in a failed state.

I've seen this happen with Standard_D8s_v3 to Standard_D16s_v3 resizes during peak hours. Don't bother checking the activity log for a detailed error — it'll just say AllocationFailed or ProvisioningState/failed with no extra context. The fix is straightforward:

1. Deallocate the VM. This releases the current spot capacity and removes the failed state.
2. Retry the resize. With the VM deallocated, you can change the size and it'll attempt a fresh allocation.
3. If it fails again, wait or pick a different size. Spot capacity fluctuates. Try a different VM size in the same family, or wait 15-30 minutes and retry.

Here's the PowerShell to deallocate and resize:

Stop-AzVM -ResourceGroupName "myRG" -Name "myVM" -Force
Set-AzVMSize -ResourceGroupName "myRG" -VMName "myVM" -Size "Standard_D16s_v3"
Start-AzVM -ResourceGroupName "myRG" -Name "myVM"

But here's the thing — if you're running production workloads on spot instances, you're asking for trouble. Spot VMs can be evicted anytime, and resizing is a prime trigger. If you need reliability, use a standard (pay-as-you-go) VM. Spot is for batch jobs, dev/test, and other fault-tolerant stuff. I've said it a hundred times.

Cause #2: Quota or vCPU Limits on the Target Size

If you're not using spot, or if you've deallocated and retried but still get ProvisioningState/failed, check your subscription's vCPU quota. Each VM family has a separate quota. You might have plenty of total vCPUs but zero quota for the Dsv3 series because you've never used it.

This is especially common when you resize from an older generation like Dv2 to Dv3 or Dv4. The quota is per-family, so you can be out of quota for Dsv3 while having 50 idle vCPUs in Dv2.

Here's how to check and fix this:

1. Go to Subscriptions > Usage + quotas in the Azure portal.
2. Filter by your region and look for the VM family you're targeting.
3. If it shows 0 available, request a quota increase. That's a simple support ticket and usually takes a few hours to a day.

Alternatively, you can bypass this by choosing a different size in a family you already have quota for. For example, if you're stuck on Standard_D8s_v3 and need more RAM, try Standard_E8s_v3 instead — just make sure your quota for that family is sufficient.

Cause #3: Azure Platform Issue or Regional Capacity Crunch

Sometimes it's not your fault at all. Azure has had regional capacity issues, especially during big launches or in smaller regions. If you've deallocated, checked quota, and tried multiple sizes, it might be Azure's problem.

You'll know it's a platform issue if the activity log shows AllocationFailed even for a size you've used before. I've seen this happen in Central US and UK South during peak hours. The fix is to wait and retry, or deploy to a different region temporarily.

Don't waste time opening a support ticket for this unless it's been several hours. Azure usually resolves it on its own. I've had VMs stuck for 2-3 hours during these crunches, and then they just work.

Quick Reference

And remember — if you're using spot for anything that can't handle eviction, stop. Resizing is just one of many triggers. The spot instance will get evicted eventually, and you'll be back here staring at a failed VM. Move to a standard VM if uptime matters.