Standard_B2als_v2 can be selected for a new VM but omitted for an existing VM when that VM’s disk layout or placement constraints make an in-place resize unsupported; first check whether this is a Windows VM crossing from a size with a local temporary disk to the diskless Basv2 target.
1. Check the temporary-disk boundary
Standard_B2als_v2 has no local temporary storage, supports both Generation 1 and Generation 2 VMs, and permits up to four remote disks.^1^
For Windows VMs, Azure supports only these direct combinations:
- Local temporary disk → local temporary disk
- No local temporary disk → no local temporary disk
A Windows VM cannot be resized directly across that boundary. Linux VMs do support such a resize.^2^
Check the existing VM for a resource/temporary disk, commonly presented as D: on Windows. If it has one, there is no supported direct in-place resize to Standard_B2als_v2. The documented Windows migration process requires moving pagefile.sys off the temporary disk, taking a snapshot, and creating a diskless VM from it.^3^
That means the requirement to avoid recreating the VM cannot be met in this specific Windows/temp-disk case. Select another target SKU with a local temporary disk if an in-place resize is mandatory.
Also verify that the VM has no more than four attached data disks, because that is the target SKU’s maximum.
2. Query availability for this specific VM
Since deallocating the individual VM did not expose the size, use Cloud Shell to distinguish regional SKU availability from resize availability for the existing VM:
rg="my-resource-group"
vm="my-vm"
region="my-region"
target="Standard_B2als_v2"
az vm list-vm-resize-options \
--resource-group "$rg" --name "$vm" \
--query "[?name=='$target'].name" -o tsv
az vm list-skus \
--location "$region" --size "$target" --all \
--query "[].{Name:name,Restrictions:restrictions,Zones:locationInfo[].zones}" \
-o json
The first command reports sizes available to that existing VM; the second shows regional, zonal, and subscription restrictions. Azure explicitly recommends az vm list-vm-resize-options before resizing, rather than relying on what can be selected during creation.^4^ The --all option includes SKUs restricted for the current subscription.^5^
If the first command returns the target, resize it:
az vm resize \
--resource-group "$rg" --name "$vm" \
--size Standard_B2als_v2
az vm start --resource-group "$rg" --name "$vm"
3. If the VM belongs to an availability set
Deallocating only the affected VM is insufficient when other VMs in the same availability set remain allocated. The resize is constrained to the availability set’s original cluster, which might not support Basv2 or might lack capacity.^6^
During a maintenance window:
- Azure portal → Virtual machines.
- Add an Availability set filter.
- Select every VM in that availability set.
- Select Stop and wait until all show Stopped (deallocated).
- Resize the applicable VMs.
- Start all VMs together.
Full deallocation allows Azure to allocate the set from all clusters supporting the requested sizes. Be aware that deallocation can release dynamic public IP addresses, although OS and data disks are unaffected.^2^
4. Remaining cases
- Zonal VM: The SKU may be available in the region but unavailable or out of capacity in that VM’s zone.
- Subscription restriction: If
list-skus --all reports a restriction, submit a SKU availability request through Azure Support.^5^
- Standalone, compatible VM with no reported restriction: Open an Azure support request under Virtual Machine running Windows/Linux → Assistance with resizing my VM. Regional creation availability alone does not prove that the existing VM’s placement can accept that size.
References
- Basv2 sizes series
- Change the size of a virtual machine
- Azure VM sizes with no local temporary disk
- Tutorial: Create and Manage Linux VMs with the Azure CLI
- Resolve errors for SKU not available
- Troubleshoot allocation failures when you create or resize VMs in Azure