Gen5 to Gen6: what to check before you resize a single Azure VM

Azure’s D and E series v6 VMs (Dsv6, Dasv6, Esv6, Easv6, and their variants) bring more vCPUs and memory per size than v5, on newer silicon. The move looks like a routine resize, but v6 changes enough underneath that a handful of prerequisites need checking before you touch anything in production.

The mapping is simple; the requirements aren’t

The size mapping itself is straightforward: Dv5/Dsv5/Ddsv5 → Dsv6/Ddsv6, Dasv5/Dadsv5 → Dasv6/Dadsv6, and the same pattern for the E-series. What’s not simple is that v6 sizes carry three hard requirements v5 didn’t:

• Generation 2 VMs only. A Gen1 VM has to be upgraded first (Trusted Launch is the supported path).
• NVMe disk controller, not SCSI. A SCSI-based VM can’t be resized directly into an NVMe-only v6 size; it needs a controller conversion first, using Microsoft’s own SCSI-to-NVMe migration script (linked from the checklist below).
• MANA (Microsoft Azure Network Adapter), for accelerated networking. Your OS image and driver stack need to support it.

There’s a fourth item that’s easy to miss because it doesn’t block the resize, it just changes what you’re allowed to do afterward: Azure Disk Encryption (ADE) isn’t supported on v6 sizes that carry local/temporary disks (Ddsv6, Dadsv6, Edsv6, Eadsv6, and similar). If you’re on ADE today and moving to one of those sizes, plan the move to Encryption at Host or Server-Side Encryption with customer-managed keys before migration, not after. ADE itself is also retiring in September 2028 regardless of which VM generation you’re on.

OS support is more specific than “is it recent”

NVMe and MANA aren’t universally supported across every OS version that otherwise runs fine on Azure. Recent LTS releases of Ubuntu, RHEL, SLES, Debian, Oracle Linux, and AlmaLinux all support NVMe; MANA’s list is narrower (Ubuntu 22.04 needs a kernel ≥ 6.8.0-1033 specifically). On Windows, Server 2019 supports NVMe but not shared disks on NVMe, so that’s one more thing to check if shared disks are part of your setup. The checklist linked below has the full version matrix; the short version is: verify your exact OS version against it before you assume “it’s a supported distro” is enough.

This applies beyond individual VMs

The same prerequisites apply to VM Scale Sets and anything VM-backed: Databricks, AKS node pools, analytics clusters, batch compute. A fleet migration is the same checklist run once per node image, not a different process.

Where the FinOps payoff actually shows up

Here’s the part worth saying plainly: performance gains alone don’t guarantee cost efficiency. v6 gives you more capability per size, which is exactly why right-sizing after migration is where the real value shows up, not the migration itself. Moving a fleet to v6 without revisiting whether each workload still needs the size it’s running just moves the same spend onto newer hardware. The migration is the opportunity to right-size; it isn’t the saving by itself.

What’s next: v7 is already in preview

Azure’s v7 series (AMD EPYC “Turin,” up to 160 vCPUs) is in public preview with the same prerequisites as v6, no SLA yet, and limited regional availability. If v6 covers what you need today, migrate to it now; it’s GA and fully supported. If you specifically need more than 128 vCPUs or the latest core performance, it’s worth tracking v7’s GA date rather than waiting on it for a migration you can do today.

Before you migrate

Back up or snapshot everything first, confirm quota for the target size in your region, and test in non-production before touching anything live. The full checklist, size mapping table, OS support matrix, and step-by-step commands are in the downloadable migration prerequisites checklist (PDF, 3.8 MB).