The resize that removes a disk
Dv5 without the d has no temporary disk at all, so /dev/sdb and D: disappear and anything pointing at them fails at boot
Standard_D4s_v5
Read an Azure VM size name: the family, the vCPU count, and what each feature letter means. Including the two whose absence matters, the d that is a temporary disk and the s that is premium storage.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Decode the sizes. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Dv5 without the d has no temporary disk at all, so /dev/sdb and D: disappear and anything pointing at them fails at boot
Standard_D4s_v5
Eight usable vCPUs on a machine billed for 32, which cuts a per-core database licence by four and keeps the larger size's memory
Standard_E32-8s_v5
The p letter is ARM, so x86 binaries do not run and every container image needs an arm64 build
Standard_D4ps_v5
A burstable size runs on CPU credits and is throttled to a fraction of its vCPU count once they are gone
Standard_B2s
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
From version 4 the local temporary disk is opt-in through the d letter, so a size without it has none at all. /dev/sdb on Linux and D: on Windows disappear, and a page file, a tempdb or a scratch directory pointing at either fails at boot or at first write.
Instead:Use the d variant, or move the scratch path to a data disk, which survives a deallocate as well.
The s letter is what makes a size premium storage capable. Without it the deployment fails with an error about the disk rather than about the VM size, which sends people to check the disk.
Instead:Use the s variant. It is the same machine with a different storage capability, and usually the same price.
Standard_E32-8s_v5 gives 8 usable vCPUs and is billed for 32. It exists to cut a per-core database licence by four while keeping the memory and disk throughput of the larger size, and paying the full compute price is the trade.
Instead:Use it deliberately for licensed software. For anything else the plain size without the -N is the same guest capacity for less.
The p letter is ARM. x86 binaries do not run, every container image needs an arm64 build, and any agent from a vendor's x86 repository will not install.
Instead:Confirm every image, package and agent has an arm64 build first. A multi-arch container image hides this until something in a base layer is not.
Burstable machines run on CPU credits and are throttled to a baseline once the credits run out. A B2s baseline is 40% of two vCPUs. The first hour is fine and everything after it is not.
Instead:Watch the CPU Credits Remaining metric, and use a D series for anything with a steady load.
Standard_D4ads_v5 is a sentence: a family, a vCPU count, three capabilities and a generation. Two of those letters change what the machine has rather than how fast it is.
From version 4 onwards the local temp disk is opt-in through the d letter. So moving from Dv3 to Dv4 removes /dev/sdb on Linux and the D: drive on Windows, and anything pointing at either, a page file, a SQL Server tempdb, a scratch directory, a Docker data root, stops. The failure is at boot or at first write, not at resize time, and nothing in the size name says it removes a disk.
Standard_D4_v3 has a temp disk
Standard_D4_v5 has none
Standard_D4d_v5 has one
The d is the difference. A data disk is the other
answer, and it survives a deallocate as well. Standard_E32-8s_v5 gives 8 usable vCPUs on a 32 vCPU machine. It exists so a database licensed per core costs a quarter of what it otherwise would, while keeping the memory, disk throughput and network of the larger size. The Azure compute charge is the full 32 vCPU price, and that is the trade.
Standard_E32-8s_v5
32 vCPUs billed by Azure
8 vCPUs the guest sees
8 cores your database is licensed for The p letter is an Ampere Altra processor. x86 binaries do not run, every container image needs an arm64 build, and any agent or driver from a vendor's x86 repository will not install. It is cheaper per vCPU, which is why it gets chosen without the architecture being noticed.
A burstable machine accrues CPU credits while idle and spends them above a baseline that is a fraction of the vCPU count. Under sustained load the credits run out and it is throttled to that baseline, which for a B2s is 40% of two vCPUs. The symptom is a workload that is fine for an hour and slow forever after, with nothing changed.
The storage optimised sizes are built around large local NVMe. It is fast and it does not survive a deallocate, a host maintenance event or a resize, and there is no snapshot of it. That is the right trade for a cache or a replicated datastore and the wrong one for a primary copy.
The SKU. It reads the name, so it cannot tell you whether the size exists in your region, whether your subscription's quota allows it, what it costs, or which accelerator it carries, and Azure withdraws and adds sizes constantly. az vm list-skus --location REGION is the authority, and it reports the real capabilities rather than the ones the name implies. The portal's size picker also shows a display name rather than the API name, and "D4as v5" is not a string a template accepts.