identify the possible blocking state while executing resizing and idle automation for virtual machine

Question

identify the possible blocking state while executing resizing and idle automation for virtual machine

Sree Aravind M 40

Find all the possible blocking conditions that can stop or affect resizing and idle automation for VM, EC2, and Compute Engine.

We have already completed the checks for:

Delete protection

Permission check

Now, we need to identify any other possible blockers before starting the resizing and idle automation.

Saraswathi Devadula 16,040 Reputation points Microsoft External Staff Moderator

2026-09-09T18:01:27.99+00:00
Hello Sree Aravind M

It sounds like you’re looking for *all additional blocking conditions that can prevent or affect VM resizing and idle automation workflows (including the related “stop/start/deallocate” actions that automation typically triggers).

Possible blocking conditions for VM resizing / idle automation:

Cluster capacity / wrong cluster for the original placement:

Several resize/start/restart failures are caused by the fact that the resize (or start) request must be attempted at the original cluster that currently hosts the VM/availability set.

Common symptoms:

Allocation failures during resize or start

“Requested VM size isn’t supported by the hosting cluster” / “not enough capacity”

Availability set issues: partially deallocated VMs:

For availability sets, the documentation notes that if you have partially deallocated VMs (some stopped/deallocated, others not), then starting/resizing can behave like adding VMs to an existing availability set, which again requires allocation from the right original cluster and can fail due to capacity.

VM not fully deallocated when resizing disk (Stopped vs Stopped (Deallocated)):

For disk resize operations where deallocation is required, stopped is not the same as Stopped (deallocated).

If you only shut down inside the OS, the VM can remain in Stopped (still billed and may still hold leases).

Some resize flows require Stopped (deallocated).

Active disk export SAS lease (disk resize blocked by SAS URI)

Disk resize can be blocked by an active Shared Access Signature (SAS) lease, such as from Disk Export or related operations.

How to detect

Disk resource → Disk Export

If a download URL with an expiry timestamp exists, the SAS is still active

Azure CLI check:

az disk show ... --query diskState

If diskState is ActiveSAS, a lease is active

Running or pending Azure Backup jobs affecting disk operations:

If an Azure Backup job is running (or pending), it can hold leases related to restore/snapshot operations and block certain disk actions.

Disk resize restrictions require specific disk type / attach combinations (online vs deallocated resize):

Some disk resize operations can only succeed when the VM is deallocated, and some online resize without deallocation is explicitly unsupported depending on disk type and configuration.

Pending stop-deallocate operation not completed (VirtualMachineIsStopDeallocating):

If the VM is in a stop-deallocation in-progress state from a previous automation run, subsequent operations (restart/resize/reapply) can be blocked.

VM state failures after network profile processing errors (VM put into failed state):

There’s also a documented case where stop/start/restart/redeploy can fail and the VM is put into a failed state with an error about processing the VM network profile.

What to do

Use Redeploy + reapply → Reapply to rerun provisioning and help recover.

References:
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/allocation-failure?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#resize-a-vm,-add-vms,-or-start-partially-stopped-deallocated-vms,-to-an-existing-availability-set

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/restart-resize-error-troubleshooting?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#issue-error-when-resizing-an-existing-vm

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-disk-resize?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#deallocate-the-vm-before-resizing

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-disk-resize-sas-block?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#diagnostic-steps

2 answers

Your answer

Answer 1

For Azure Virtual Machines, possible blocking conditions beyond delete protection and permission checks include:

VM not fully deallocated when resize requires it
- Some resize operations require the VM to be in Stopped (deallocated) state.
- A VM shut down from inside the guest OS can remain Stopped instead of Stopped (deallocated), which can block the operation.
VM size/SKU does not support live disk resize
- Not all VM sizes support resizing attached disks while the VM is running.
- If the VM SKU does not support live resize, the VM must be deallocated first.
OS disk live resize requirements not met
- OS disk resize has stricter requirements than data disk resize.
- If the VM SKU or storage type is unsupported, resize is blocked until the VM is deallocated.
Shared disk attached (maxShares > 1)
- Shared disks cannot be live-resized while attached to running VMs.
- All attached VMs must be deallocated, or the disk must be detached.
Disk SKU and size combination does not support online resize
- Online resize is not supported for:
  - OS disks
  - Shared disks
  - Standard HDD, Standard SSD, or Premium SSD data disks that are 4 TiB or smaller when expanding them beyond 4 TiB
Active SAS token on the disk
- An active SAS URI places a lease on the disk and blocks modifications.
- This can happen because of:
  - Disk export
  - Azure Backup job in progress
  - Azure Site Recovery replication
  - Third-party backup tools
Backup job in progress
- A running Azure Backup job can hold the lease and block disk resize until the job finishes or is canceled.
Disk export in progress
- If a disk export URL exists, the disk may have an active SAS lease that blocks resize.
Target disk size is invalid
- Resize fails if the requested size is outside the valid range for the disk SKU or if the operation attempts to shrink the disk.
Disk attached while crossing the 4 TiB threshold

A Standard HDD, Standard SSD, or Premium SSD disk that is 4 TiB or smaller cannot be expanded beyond 4 TiB while attached.
The disk must be detached first.

Availability set allocation constraints during VM resize/start

If the VM is in an availability set, resize or restart can fail because the original cluster may not support the requested size or may lack capacity.
This is especially relevant when only some VMs in the availability set are deallocated.

Partial deallocation in an availability set

Starting or resizing VMs in a partially deallocated availability set can behave like adding capacity to the existing set and fail due to cluster capacity restrictions.
Deallocating all VMs in the availability set and starting them together is a documented workaround.

VM in transitional or updating state

A VM in provisioning or updating state can affect automation actions such as start/stop.
Failed or in-progress extensions can also affect accessibility and operations.

For idle automation on Azure VMs, the context supports these blockers:

VM in transitional state
Pending operations such as disk resize
Provisioning state issues
Extension installation or extension failure
Automation identity lacks required access
Bad request from automation due to configuration mismatch or conflicting VM state

The provided context does not contain supported blocker lists for AWS EC2 or Google Compute Engine, so only Azure VM blockers can be listed from the available material.

Answer 2

Welcome to Microsoft Q&A, @Sree Aravind M I hope you are doing well today,

Beyond delete protection and permissions, I would also validate the VM state and any dependencies before running automated resize or idle operations that may be blocking ....

For Azure VMs, the main conditions to check are:

VM is in a transitional state such as Updating, Provisioning, Starting, or Stopping.
The VM is not fully deallocated when the target resize requires deallocation.
The requested VM size/SKU is unavailable in the region or cannot be allocated due to capacity constraints.
Availability Set constraints prevent the VM from being allocated to the requested size.
Another operation is already in progress on the VM or its disks.
A disk has an active SAS lease, for example from disk export or a backup operation.
Disk resize prerequisites are not satisfied, particularly when crossing the 4-TiB boundary for certain disk SKUs.
The VM is protected by another automation/policy that may start, stop, or resize it concurrently.
Azure Policy or resource locks prevent the required operation.
The automation identity has permission to the VM but not to a dependent resource required by the operation.
For idle automation, verify that monitoring data is available and current; missing/stale metrics can prevent the automation from correctly identifying an idle VM.

For the resize workflow, I would check the VM's provisioningState, powerState, current SKU, pending operations, disk state/SAS leases, Availability Set configuration, and regional SKU capacity before executing the action.

Microsoft references:

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-disk-resize-errors

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/allocation-failure

https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/resize-vm