Azure VM stuck in 'Creating' after resizing: fix

When this hits

You're in the Azure portal, you just resized your VM from a Standard_D2s_v3 to a D4s_v3—maybe you needed more juice for a SQL Server workload. The blade says 'Updating', then 'Creating', and it sits there. Two hours later, still 'Creating'. Your app is down. Users are emailing. You refresh the page, nothing changes. I've seen this exact mess a dozen times, usually with older VMs that have been running for months without a restart.

What's really happening

Azure can't hot-swap a VM's size if the current host doesn't have capacity for the new SKU. The portal tries to orchestrate a live migration, but if the target host is full or the VM has attached disks that lock it to a specific cluster, it stalls. The 'Creating' state means Azure is trying to provision a new VM instance on a different host, but something's blocking it—maybe a reservation mismatch, maybe a failed allocation. The worst part: Azure won't time out gracefully. It'll sit there for hours unless you force it.

Fix it in 4 steps

1. Stop the VM. Go to your VM's overview page, click 'Stop'. Wait until the status shows 'Stopped (Deallocated)'. This releases the host and any pinned resources. Don't skip this—if you just try to resize again while it's stuck, you'll spin your wheels.
2. Resize while stopped. With the VM deallocated, go to 'Size' in the left menu. Pick the new size. Click 'Resize'. This should complete in under a minute because Azure just needs to assign a new host with spare capacity.
3. Start the VM. Click 'Start'. The status goes directly to 'Running'—no more 'Creating' limbo.
4. Verify. Check the VM's size in the overview. Also check any associated disks or IPs to make sure nothing got orphaned. I had a client last month whose NIC detached during a stuck resize—bizarre, but it happens.

If it still fails

If step 2 fails with an allocation error, you're probably in a region or availability set that's tight on resources. Try moving to a different size in the same family (e.g., D2s_v3 to D4s_v3 might work, but D4s_v3 to D8s_v3 might not). You can also deploy a new VM from a snapshot and delete the stuck one—that's a nuclear option, but it works when Azure's being stubborn. And check your Azure reservations: if the new size isn't covered, the portal can get confused. Finally, open a support ticket if it's been stuck for more than 4 hours—they can force-terminate the provisioning orchestration on the backend.

One last thing: never resize a production VM during peak hours. Always do it during maintenance windows. The 'hot resize' feature works maybe 70% of the time in my experience. The other 30%? You get this 'Creating' black hole. Save yourself the headache and stop the VM first.