Expand Data Disks for Azure Local VMs

Introduction

Azure Local virtual machines (VMs), formerly known as Arc VMs, are VMs deployed from Azure via the Azure Resource Bridge (ARB) to Azure Local instances. These VMs are natively Arc-enabled and administrators can manage them using Azure management tools including the Azure portal, the Azure CLI, Azure PowerShell, and ARM templates.

There are three main types of VMs that can be deployed onto Azure Local:

• Azure Local VMs enabled by Azure Arc (as mentioned above)
• Arc-enabled servers (guest is onboarded to Arc)
• Unmanaged VMs (created or imported using local tools)

There are different management capabilities for these types of VMs, available through Azure tooling, and a comprehensive list can be found in the Microsoft documentation:
https://learn.microsoft.com/en-us/azure/azure-local/concepts/compare-vm-management-capabilities?view=azloc-2504?wt.mc_id=MVP_402473

The management capability we are focusing on in this article is the ability to expand the size of data disks for an Azure Local VM, which has been released in version 2504 of Azure Local.

Azure Local VM Operations

Before we get to the technical part, let’s discuss where we are with Azure Local VMs as you maybe asking: “isn’t disk expansion already supported for VMs running on Azure Local?”

This is a fair question and the answer is yes and no. Yes, they are Hyper-V VMs and expanding virtual hard disks is supported and a common task for Administrators using local tooling but, in this case No, we are talking about supported operations using Azure tooling that work exclusively with Azure Local VMs.

Certain operations performed using local tooling can lead to Azure Local VMs becoming unmanageable from Azure portal. This is because the configuration and state is synchronised down from Azure, the control plane, via the ARB, but isn’t currently synchronised back up to Azure. So most changes made using local tooling will not be reflected in Azure and, as mentioned for some operations, the configuration can get out of sync with Azure and lead to them becoming unmanageable.

Azure Local VMs offer numerous advantages, including the ability to deploy virtual machines using Azure Resource Manager (ARM) templates and automation, assign Role-Based Access Control (RBAC) permissions to Azure users, and leverage the full suite of features enabled by Azure Arc integration. Microsoft is actively enhancing these management capabilities, transitioning operations from local tools to Azure tooling, with dedicated teams working to deliver the comprehensive features administrators need for daily management. We are on a journey with Azure Local VMs and the currently unsupported operations will be addressed in due course. For now, a key feature that is supported since 2504 is the ability to extend data disks, which significantly enhances flexibility. Let’s explore how this feature works in the following section.

Data Disk Expansion

Current Disk Size

In this section we will expand the data disk of a test VM running in a lab environment made up of a 2-Node Azure Local instance that was recently updated to 2504. Please note that in the near future we expect this operation will be possible using the Portal, but it’s always good to know the cli commands.

The VM was deployed from Azure using the Windows Server 2025 Azure Edition image, and the name of the VM is ‘arcvm-1‘. Here’s how it looks in Azure:

As you can see it has a 10GB data disks attached:

Here’s a local view of the VM showing the attached VHDX:

Just to be thorough, let’s correlate with local PowerShell:

Expanding the Disk

Firstly, you’ll need to run a PowerShell Terminal with ‘az cli’ installed and the ‘stack-hci-vm’ extension upgraded to the latest version. The ‘az-stack-hci’ extension is used to manage Azure Local VMs on Azure Local instances, please see the documentation:
https://learn.microsoft.com/en-us/cli/azure/stack-hci?view=azure-cli-latest?wt.mc_id=MVP_402473

You can check the versions using the az --version command, or query the specific extension using az extension show --name "stack-hci-vm"

Here’s the versions used for this artcile:

To update just the specific extension your can use this command:
az extension update --name stack-hci-vm

Next you need to login to Azure az login, for example:

#complete az device login
$SubscriptionId = "********-****-****-****-************"
az login --use-device-code
az account set --subscription $SubscriptionId

#Set Resource Group
$resource_group = "lh-r630-c01-rg"

Next, let’s list the VMs and Disks in my Resource Group and then correlate the Disk id with the Disk attached to the VM:

#List VMs
az stack-hci-vm list --resource-group $resource_group -o table

#Show VM
az stack-hci-vm show --resource-group $resource_group --name "arcvm-1" --query "{name:properties.osProfile.computerName,dataDisks:properties.storageProfile.dataDisks}"

#List VM Disks
az stack-hci-vm disk list --resource-group $resource_group -o table

#Show VM disk
$diskname = "data1"
az stack-hci-vm disk show --resource-group $resource_group --name $diskname --query "{id:id,name:name,diskSizeGb:properties.diskSizeGb}"

Now let’s perform the Disk Expansion and then confirm the new size:

#Extend disk
$diskname = "data1"
$size_in_gb = "15"
az stack-hci-vm disk update --name $diskname --resource-group $resource_group --size-gb $size_in_gb

#Show VM disk
$diskname = "data1"
az stack-hci-vm disk show --resource-group $resource_group --name $diskname --query "{id:id,name:name,diskSizeGb:properties.diskSizeGb}"

Let’s check the new size is reflected in the portal:

Now, let’s confirm the new size is actually seen in the VM itself (in this case it’s the F: drive, Disk 1):

And we can now expand the filesystem:

Finally, let’s verify the local VMs config again:

Conclusion

I hope this article is useful. As mentioned above, we are on a journey with Azure Local VMs and they are already very powerful being able to treat local VMs like Azure compute, with all the power of Azure RBAC and the other capabilities open to us via Azure Arc. Any unsupported operations will be addressed / added in due course and we should expect the facility to synchronise local changes up to Azure.