Forum Discussion

Seb30470's avatar
Seb30470
Occasional Reader
Aug 03, 2026

Azure VM resize: PowerShell lists Dv5 sizes, but Azure Portal only offers Dv4

Hello,

 

We recently migrated two production Azure virtual machines away from the retiring Bv1 family.

 

Initially, the VMs were running as:

 

Standard_B2ms

Standard_B4ms

 

Our goal was to move them to a newer supported VM family.

 

Environment

Region: France Central

Managed OS disks (one Standard SSD, one Standard HDD/Standard LRS)

SCSI disk controller

Windows Server virtual machines

What we observed

 

After stopping and deallocating the VM, we queried the available resize targets using PowerShell:

 

Get-AzVMSize ` -ResourceGroupName "<ResourceGroup>" ` -VMName "<VMName>"

 

For one VM, PowerShell returned, among others:

 

Standard_D2ads_v5 Standard_D2ds_v5 Standard_D2d_v5 Standard_D2as_v4 Standard_D2ds_v4

 

For the other VM, it returned:

 

Standard_D4ads_v5 Standard_D4ds_v5 Standard_D4d_v5 Standard_D4as_v4

 

However, when opening VM → Size in the Azure Portal, the v5 sizes were not available.

 

Only the following sizes appeared:

 

Standard_D2as_v4

Standard_D4as_v4

 

As a precaution, we resized both VMs using the sizes proposed by the Azure Portal:

 

Standard_B2ms → Standard_D2as_v4

Standard_B4ms → Standard_D4as_v4

 

The migration completed successfully and both VMs are running correctly.

 

Question

 

Can someone explain why there is a difference between:

 

the sizes returned by Get-AzVMSize, and

the sizes displayed by the Azure Portal?

 

More specifically:

 

Does Get-AzVMSize return VM sizes that are not actually valid resize targets?

Does the Azure Portal apply additional compatibility or capacity checks that PowerShell does not?

Is this related to:

regional capacity,

VM generation,

disk controller,

managed disk type,

host cluster,

or another compatibility requirement?

Would you recommend staying on Das_v4, or should we plan another migration to Dads_v5 if possible?

 

I am trying to understand the reason behind the different behavior rather than forcing the resize through PowerShell.

 

Thank you in advance for your insights.

azure
Azure Resource Management

2 Replies

  • Kidd_Ip's avatar
    Kidd_Ip
    MVP
    Aug 04, 2026

    The difference you observed is expected which mean Get-AzVMSize lists all theoretically available SKUs in the region, while the Azure Portal filters that list based on actual cluster capacity, compatibility, and allocation feasibility. In practice, the Portal is authoritative for valid resize targets, while above may show SKUs that cannot be allocated to your VM at that moment.

     

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

     

  • Jamony's avatar
    Jamony
    MCT
    Aug 03, 2026

    You are seeing a real inconsistency: the VM-specific PowerShell query lists Dv5 resize targets, while the portal exposes only Das_v4 after deallocation. Get-AzVMSize with a VM name is intended to return sizes available for that VM on its current hardware cluster, so those results are not merely every regional SKU. Capacity and cluster placement are the most likely variables; generation, SCSI, and ordinary managed disk tiers do not by themselves explain all three Dv5 omissions. Re-run Get-AzVMSize immediately after confirming the VM is fully deallocated, then check the desired SKU’s regional restrictions with Get-AzComputeResourceSku. If Dads_v5 still appears, test the resize on a nonproduction clone or during a rollback-ready maintenance window, rather than forcing production first. Staying on Das_v4 is reasonable while it meets performance and support requirements. Move to Dads_v5 only for a measured benefit, and open an Azure support case if portal and API results continue to disagree.