Azure Local storage path availableSizeMB stops at 1,048,576 MB

Question

Azure Local storage path availableSizeMB stops at 1,048,576 MB

Singh, Sapana 0

We read storage path (Microsoft.AzureStackHCI/storageContainers) free space through ARM to check that VM disks will fit before creating them. On our instance, availableSizeMB seems to stop at 1,048,576 MB (1 TiB) whenever the volume has more free space than that.

Instance: solution version 12.2609.1003, single machine, region eastus, api-version 2024-01-01. Two storage paths, both on volume C:\ClusterStorage\UserStorage_1.

What we saw (MB = MiB):

|---|---|---|---|

| Before creating a 50 GiB disk | 1,061,029 | 1,048,576 (exactly) | 3,355,443 |

| After creating it | 1,009,825 | 1,009,868 (one path; the other updated later) | 3,355,443 |

Once free space dropped below 1 TiB, availableSizeMB matched the volume. While it was above 1 TiB, it showed exactly 1,048,576. containerSizeMB shows 3.2 TiB, so the size is not limited the same way.

Your documentation says the free space of the storage path is the available space on its cluster shared volume and mentions no limit (Create storage path for Azure Local; Storage Containers - Get REST reference).

Questions:

Is availableSizeMB limited to 1,048,576 MB? If so, is that intended, and is it fixed in a later version?
If it is limited, which ARM property or API gives the real free space of the volume behind a storage path?
How often is availableSizeMB refreshed after a disk is created or deleted? We saw a delay of a few minutes, and different times for two paths on the same volume.

Thanks,

Sapana

0 comments

2 answers

Your answer

Answer 1

availableSizeMB should not be used as an authoritative preflight value above 1 TiB on the reported build; obtain SizeRemaining directly from the backing CSV until Microsoft confirms or fixes the apparent reporting ceiling.

What can be concluded

Azure Local documentation says a storage path’s available capacity is determined by the available space on its backing cluster shared volume (CSV). It does not document a 1 TiB maximum.^1^
The API model defines availableSizeMB as a nullable 64-bit integer representing available disk space. The schema itself therefore does not impose a 1,048,576 MB limit.^2^
Your boundary test strongly indicates that the reported value is being clamped or truncated to 1 TiB somewhere in the Azure Local reporting path: it stayed at exactly 1,048,576 MiB above the boundary, then tracked the CSV after free space fell below it. However, no public documentation identifies that behavior as intentional.
The 2610 release notes do not list this issue among the fixes or known issues. Consequently, there is no documented basis for claiming that upgrading from 12.2609.1003 to 12.2610.1004.50 fixes it.^3^

Authoritative capacity check

No documented property on Microsoft.AzureStackHCI/storageContainers provides an uncapped alternative to status.availableSizeMB. The related SDK properties expose the same serialized value, not a second capacity measurement.^4^

For provisioning automation that can run against the Azure Local machine, query the backing CSV directly:

$csvPath = 'C:\ClusterStorage\UserStorage_1'
$volume  = Get-Volume -Path $csvPath

[pscustomobject]@{
    Path          = $csvPath
    FreeBytes     = [int64]$volume.SizeRemaining
    FreeMiB       = [math]::Floor($volume.SizeRemaining / 1MB)
    RequiredBytes = 50GB
    Fits          = $volume.SizeRemaining -ge 50GB
}

Get-Volume exposes SizeRemaining and Size for the actual filesystem volume.^5^

Additional safeguards:

Compare in bytes rather than rounded MiB.
Reserve operational headroom instead of treating every free byte as allocatable.
Resolve each storage path to its underlying CSV and deduplicate by volume. In this case, both storage paths point to UserStorage_1, so their reported capacities must not be added together.
If only ARM access is available, treat exactly 1,048,576 as “at least 1 TiB or indeterminate,” not as exact free capacity. There is no documented ARM replacement that supplies the real value.

Refresh behavior

No public Azure Local documentation specifies a polling interval, maximum propagation delay, or freshness guarantee for availableSizeMB. The property is described as observed status, so it should be treated as eventually updated rather than transactionally synchronized with disk creation or deletion.^6^

Different update times for two storage-path resources on the same CSV are therefore possible, but the available documentation does not define an expected delay. Do not use a fixed sleep as a correctness mechanism; poll until the value changes or a timeout expires, while using the direct CSV measurement for the admission decision.

Escalation

Open an Azure support request and include:

Solution version 12.2609.1003, region eastus, and API version 2024-01-01.
Full resource IDs and timestamps for both storage paths.
Raw ARM responses before and after crossing the 1 TiB boundary.
Simultaneous Get-Volume -Path C:\ClusterStorage\UserStorage_1 output.
The reproducible boundary: values above 1 TiB return exactly 1,048,576; values below it track the CSV.
The per-resource refresh delay after create and delete operations.

Ask Microsoft to confirm whether this is a service-side clamp or an appliance/resource-provider defect, identify the affected versions, and provide the fixed build or supported capacity API.

References

Answer 2

Your boundary test is a strong signal that availableSizeMB is being clamped to 1 TiB on that build, and the documentation does not say it is capped. Until Microsoft confirms or fixes the ceiling, treat an exact value of 1,048,576 as "at least 1 TiB or indeterminate" rather than a true reading, and get the real free space directly from the CSV with Get-Volume SizeRemaining on the appliance before you admit a new disk. For the ARM side there is no documented uncapped replacement property, so polling until the value changes (or timing out) is the only freshness signal you get from the API, and you should not add the two storage-path readings together since they both sit on the same CSV.