Ultra Disk and Premium SSD v2

Keep the VM running for both breaks.

1Break it: attaching an Ultra Disk to a normal VM

The DBA asks for an Ultra Disk for the transaction log. Create it and try to attach it:

az disk create --resource-group rg-saat-l58 --name ultra-log --sku UltraSSD_LRS --zone 1 --size-gb 8 --disk-iops-read-write 1000 --disk-mbps-read-write 50 --tags course=saatvedha-azure lesson=58 -o none
az vm disk attach --resource-group rg-saat-l58 --vm-name vm-db --name ultra-log --lun 1

You’ll get an error like this:

(InvalidParameter) StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.
Code: InvalidParameter
Target: managedDisk.storageAccountType

The disk is fine and in the right zone. The VM hasn’t been made Ultra-compatible, and that switch can only change while the VM is deallocated.

Fix it: deallocate, enable Ultra compatibility, start, and attach (plan a short outage for this in production):

az vm deallocate --resource-group rg-saat-l58 --name vm-db
az vm update --resource-group rg-saat-l58 --name vm-db --ultra-ssd-enabled true -o none
az vm start --resource-group rg-saat-l58 --name vm-db
az vm disk attach --resource-group rg-saat-l58 --vm-name vm-db --name ultra-log --lun 1 -o none
az vm run-command invoke --resource-group rg-saat-l58 --name vm-db --command-id RunShellScript --scripts 'fio --name=rand --filename=/dev/disk/azure/scsi1/lun1 --rw=randread --bs=4k --iodepth=64 --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting | grep IOPS=' --query "value[0].message" -o tsv

You should see something like this:

[stdout]
  read: IOPS=1004, BW=3.92MiB/s (4.11MB/s)(118MiB/30001msec)

The Ultra Disk delivers the 1,000 IOPS you set. Build new database VMs with Ultra compatibility from day one, so you never need that outage later.

2Break it: month-end and the disk is too slow

Month-end reports need more IOPS. Check which limit is hit during a fio run, then raise the Premium SSD v2 disk’s IOPS live, with no detach or reboot:

$vmIdDb = az vm show --resource-group rg-saat-l58 --name vm-db --query id -o tsv
az vm run-command invoke --resource-group rg-saat-l58 --name vm-db --command-id RunShellScript --scripts 'fio --name=rand --filename=/dev/disk/azure/scsi1/lun0 --rw=randread --bs=4k --iodepth=64 --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting | grep IOPS=' --query "value[0].message" -o tsv
az monitor metrics list --resource $vmIdDb --metric "Data Disk IOPS Consumed Percentage" --interval PT1M --aggregation Maximum --query "value[0].timeseries[0].data[-3:].maximum" -o tsv
az disk update --resource-group rg-saat-l58 --name pv2-data --disk-iops-read-write 6000 --disk-mbps-read-write 200 -o none
az vm run-command invoke --resource-group rg-saat-l58 --name vm-db --command-id RunShellScript --scripts 'fio --name=rand --filename=/dev/disk/azure/scsi1/lun0 --rw=randread --bs=4k --iodepth=64 --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting | grep IOPS=' --query "value[0].message" -o tsv

You should see something like this:

  read: IOPS=3019, BW=11.8MiB/s (12.4MB/s)(354MiB/30001msec)
100.0
100.0
  read: IOPS=6011, BW=23.5MiB/s (24.6MB/s)(704MiB/30001msec)

The disk metric was at 100 percent, so the disk was the bottleneck, and raising its IOPS doubled the result while the database kept running. The change can take a little while to apply; if fio still shows 3,000, wait a few minutes and run it again.

Notice that 6,000 is above the VM’s base limit of 3,750. D2s_v5 is using its burst credits. Under a long, steady load the credits run out and VM Uncached IOPS Consumed Percentage hits 100: then the fix is a bigger VM, not a faster disk.

3Clean up

Delete the lab resource group (the Ultra Disk bills for its IOPS every hour):

az group delete --name rg-saat-l58 --yes
az resource list --tag lesson=58 -o table

The last command should print nothing.

✅ Checkpoint: You enabled Ultra compatibility to attach an Ultra Disk, raised Premium SSD v2 IOPS live, and know how to tell a disk limit from a VM limit.