Deploying VM Images to Azure Local extremely slow

Hi @Pawel Niemczyk ,

Thank you for the detailed description and the comparison of download behaviors that’s very helpful.

Based on your observations, this behavior is not expected from a raw Azure Storage performance perspective, but it can occur due to how the image creation workflow is implemented in Azure Local / Azure Stack HCI.

The command:

az stack-hci-vm image create

does not directly stream data like AzCopy or CURL. Instead, it relies on internal image provisioning workflows that:

• Use Azure Compute Gallery image ingestion mechanisms
• May involve buffered copy operations, service-side validation, and chunked transfers
• Do not leverage the optimized data-plane transfer path used by AzCopy

As a result, throughput can be significantly lower compared to AzCopy, which is specifically optimized for high-performance data transfer to/from Azure Storage.

AzCopy is the recommended tool for high-performance data movement to/from Azure Storage:

https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-connect-to-secure-cluster

Secure or managed cluster operations often use certificate-based or service-layer workflows rather than direct data streaming

https://docs.azure.cn/en-us/service-fabric/service-fabric-cluster-security

To achieve expected performance, the recommended approach is:

Stage the image locally using AzCopy (best practice)

1. Download the VHDX from Blob Storage using AzCopy:

      azcopy copy "https://<storage-account>.blob.core.windows.net/<container>/<file>.vhdx" "C:\localpath\image.vhdx"
   

2. Verify that the download is completed at expected speed (as you observed ~Gbps range).
3. Use the local file as the image source:

      az stack-hci-vm image create --path "C:\localpath\image.vhdx" ...
   

4. Ensure the storage account and Azure Local cluster are in the same region/network proximity
5. Validate that the VHDX is fixed-size (not dynamic) for better ingestion performance
6. Avoid repeated downloads via control-plane commands

your testing is absolutely valid the large difference in throughput clearly indicates that this is not a network issue, but a difference in how the tooling performs the data transfer internally.

For practical deployments, we strongly recommend using AzCopy for initial image transfer, as this aligns with Microsoft best practices for high-throughput data movement.

Thanks,
Manish.

hi Pawel Niemczyk & thanks for join me here at Q&A portal,

So what i see Blob is fine, AzCopy proves it, the Azure Local image create download path is the bottleneck. Azure Local image import path is using a simple single-stream download, not AzCopy-style parallel block transfer. That explains the huge difference curl / Invoke-WebRequest are basically one stream and can be awful against Blob for large VHDX files, while azcopy splits the blob into chunks and downloads in parallel. So the slow part is probably not ur 5Gbps link, firewall, or Blob itself. It is the download implementation used by az stack-hci-vm image create. For now I would not treat this as expected “network performance”, it is a tooling or performance limitation. Best workaround is to pre-stage the VHDX locally on the Azure Local cluster using azcopy, then create/import the VM image from local storage if the command path supports local source in ur version. If not, use the Azure Local image creation workflow that points to an already-local VHDX or create the gallery artifact after staging. Also test with the newest az stack-hci-vm extension because this may be improved between versions. If the command only supports blob URI and still downloads single-threaded, open support ticket with exact timings and ask whether image create supports AzCopy/parallel transfer or local staged VHDX import.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal