Working with unmanaged storage account quotas in VM Applications

Joseph Calev

While working with VM Applications, it’s possible to receive the following error.

Operation could not be completed as it results in exceeding approved UnmanagedStorageAccountCount quota. Additional details – Deployment Model: Resource Manager, Location: northeurope, Current Limit: 64, Current Usage: 64, Additional Required: 1, (Minimum) New Limit Required: 65. Please read more about quota increase at https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits

As errors go, this one is well done. It describes the problem, the current quota, and how to go about fixing the matter. The only problem is the document linked provides little clarity for VM applications.

So, what are these “unmanaged accounts” and why do I see a quota limit?

Well, when you publish a VM Application, we need to replicate it. You tell us how to do that by providing a list of regions and the replica count per region. We then create an unmanaged storage account for each of these. Therefore, to determine the number of unmanaged accounts an application uses, you may count the number of replicas across all applications.

When we first shipped the feature, we created this number of unmanaged accounts per version. This number quickly ballooned, so some time ago we changed that to per application. Therefore, no matter how many versions you have, they will use the same number of accounts.

So, how many storage accounts should you need? That depends on how many instantaneous installs of an application you’re planning. Detailed numbers on egress may be read here, but the going rule is that your average storage account can accomodate 200 simultaneous connections. So, with one storage account you can deploy an application to 200 VMs at the same time.

If you want more detail on which applications are using quotas, the following Powershell script may help. Note that it assumes the same replica count per region. If you have different counts, then you’ll need to modify the script.

$totalAccounts = 0
$galleries = Get-AzGallery
foreach ($gallery in $galleries)
{
$apps = Get-AzGalleryApplication -GalleryName $gallery.Name -ResourceGroupName $gallery.ResourceGroupName
foreach ($app in $apps)
{
$accounts = (Get-AzGalleryApplicationVersion -GalleryApplicationName Freedom -GalleryName testgallery -ResourceGroupName JCALEV | Measure-Object -Property {$_.ReplicaCount} -Maximum).Maximum
$totalAccounts += $accounts
Write-Host $app.Name"("$gallery.ResourceGroupName", "$gallery.Name") uses "$accounts "unmanaged accounts"
}
}

Write-Host "--------------------"
Write-Host "Total unmanaged accounts: "$totalAccounts

This will provide a list of applications and the number of accounts each uses. It comes without warranty or guarantees but I hope it should provide some more context.

Now, getting back to this annoying quota error: what can you do? Well, there are three options.

1. Use page blobs for your source application blobs. Unmanaged accounts are only used for block blob replication. Page blobs have no such limits.
2. Reduce the number of replicas for your VM Application versions or delete applications you no longer need.
3. File a support request to obtain a quota increase

Generally, the first option is the easiest to manage. You just need to align your package to page bounaries and then you can use VM Applications without running into these constraints.

Joseph Calev Principal Software Engineer, Azure Core Compute

Follow