Machines, disks and effective capacity

Request and allocation

Resizing a running VM involves restart and may require deallocation to change available capacity. Do not approve the operation as interruption-free merely because the size is listed. After failure, the resource model can show the requested size while the VM still runs at the previous size.

Relate operation results to observed allocation and behavior. Prepare recovery and maintenance-window communication.

Disk role and compatibility

Comparing IOPS is insufficient for choosing disks. Ultra and Premium SSD v2 are not OS disk types. Confirm role, VM compatibility and applicable availability before evaluating performance.

VM capacity also limits I/O: a disk configured for 20000 IOPS cannot meet a 15000 requirement if the VM caps the aggregate at 12000. Adding those limits would be incorrect; they constrain the same chain.

Autoscale rules

Autoscale selects the applicable profile and respects capacity limits. When multiple scale-out rules fire, it computes each resulting capacity and chooses the largest instead of adding increases. For scale-in, every reduction condition must hold; reduction is conservative and may be deferred to avoid flapping.

Consider cooldown and the observed signal. A reached threshold does not establish instantaneous capacity or acceptance of new requests.

Capacity exercise

Start with four instances and two eligible increase actions: two and five instances, with a maximum of twelve. The decision yields nine, not eleven or twelve. Next, consider low CPU but a still-long queue, with both configured as scale-in conditions.

Explain why reduction should not occur in that evaluation. Complete the report with effective capacity, disk limits and surviving availability; do not infer zone tolerance from an availability set.

Common pitfalls

Do not add serial limits, equate requested size with running size, or add concurrent scale-out actions.