How to Convert Azure VMs to v7 Sizes (and Upgrade AVD Session Hosts in Place)

By David, 2026-10-06

Microsoft's v7 virtual machine sizes are generally available on two platforms: the Dsv7, Dlsv7 and Esv7 series on Intel Xeon 6 and the Dasv7, Easv7 and Fasv7 series on AMD EPYC 9005 "Turin". For most Azure Virtual Desktop estates they're the obvious next home for session hosts still running on v3, v4 or v5.

The catch: you can't always get there by picking a new size in the portal. Try to resize a typical Standard_D4s_v5 to Standard_D4s_v7 and Azure either refuses, or accepts the change and the VM fails to boot. This article explains why, how to check each VM, the two ways to convert, and how to roll back.

The short version: v6 and v7 sizes need a Generation 2 VM running Trusted Launch, use an NVMe disk controller instead of SCSI, and use the MANA network adapter. A Gen2 Windows VM without a temporary disk or Azure Disk Encryption can be converted in place: prepare Windows for NVMe, deallocate, switch the controller and the size together, start. Anything else is redeployed from an updated image.

What actually changes on v6 and v7

The v6 and v7 series are built on Azure Boost. Microsoft's v6 and v7 modernization plan lists four platform changes compared with earlier generations:

Two of these decide whether a VM can be converted in place:

• The disk controller. The controller type is fixed when a VM is created, and most v6 and v7 sizes are NVMe-only. Windows has to load its NVMe driver early enough to find the OS disk on the new controller. If it doesn't, the VM stops at boot with INACCESSIBLE_BOOT_DEVICE (0x7B), as Microsoft's NVMe boot troubleshooting guide describes.
• The temporary disk. On Windows you can't resize between a size that has a local temporary disk and one that doesn't. On v6 and v7 the temporary disk, where there is one (the d sizes such as Ddsv7), is presented as raw NVMe rather than a formatted D: drive.

The MANA adapter only needs a current Windows build; current Windows 10 and 11 multi-session and Windows Server images include the driver.

Why move now

• Price-performance. v7 hosts often run the same users on fewer or smaller vCPUs. Size against what monitoring shows, not the old vCPU count. The AVD sizing guide covers how.
• v3 retirement. The Dv3, Dsv3, Ev3 and Esv3 series retire on November 15, 2029, and one- and three-year reservations for them can't be bought or renewed after July 1, 2026.
• Azure Disk Encryption retirement. ADE isn't available on v6 or v7 and retires on September 15, 2028. Encryption at host replaces it.

Check each VM before you convert

Run through these per VM. Each one decides whether the VM can be converted in place or has to be redeployed.

1. Hyper-V generation. Gen1 VMs can't use NVMe. Check it with PowerShell:

(Get-AzVM -ResourceGroupName rg-avd-prod -Name avd-prod-0 -Status).HyperVGeneration

V2 is ready. V1 means you either upgrade the VM to Trusted Launch first or redeploy from a Generation 2 image. Dv2 and Dv3 Gen1 VMs can't be converted at all.

2. Security type, disk controller and temporary disk.

$vm = Get-AzVM -ResourceGroupName rg-avd-prod -Name avd-prod-0
$vm.SecurityProfile.SecurityType           # TrustedLaunch, Standard or empty
$vm.StorageProfile.DiskControllerType      # empty or SCSI on pre-Boost sizes
$vm.HardwareProfile.VmSize                 # a 'd' in the suffix means a temp disk

A Gen2 VM on Standard security can turn Trusted Launch on while it is deallocated. A VM with a temporary disk (Standard_D4ds_v5, or any v3 size) should be redeployed rather than converted.

3. What the target size supports in your region.

az vm list-skus --location eastus --size Standard_D4s_v7 \
  --query "[0].capabilities[?name=='DiskControllerTypes' || name=='HyperVGenerations' || name=='MaxResourceVolumeMB']" -o table

Confirm the size is offered, has no restriction for your subscription, and that you have quota for the v7 family. Quota for v7 is separate from v5, so request it before the maintenance window.

4. The blockers. Azure Disk Encryption, a hibernated VM (resume it and deallocate first; no v6 or v7 size is on Microsoft's hibernation support list yet), an ephemeral OS disk, and third-party filter drivers that change storage or boot behaviour all mean redeploy rather than convert.

Option 1: redeploy from an updated image (recommended for pooled hosts)

For pooled host pools this is the cleanest route, and it's the one Microsoft recommends:

1. Rebuild your golden image as a Generation 2, Trusted Launch image (current marketplace Windows 11 multi-session images already are) and publish it to your Azure Compute Gallery with the feature DiskControllerTypes=SCSI,NVMe.
2. Add new session hosts on the v7 size from that image.
3. Put the old hosts in drain mode, let sessions end, and remove them.

Profiles live in FSLogix, so users don't notice which host they land on. The golden image management guide covers the image side and rolling a new version onto a pool without forcing users off.

Option 2: convert in place

In-place conversion keeps the existing OS disk. It suits personal desktops, hosts with apps that are hard to reinstall, and pools where rebuilding isn't practical this quarter. Microsoft documents it in Convert a VM from SCSI to NVMe in place, and the platform reference lists the exact steps:

1. Prepare Windows while the VM is still running on SCSI: sc.exe config stornvme start= boot, so the NVMe driver loads at boot.
2. Deallocate the VM.
3. Tag the OS disk as NVMe-capable: supportedCapabilities.diskControllerTypes = "SCSI, NVMe".
4. Change the size and the controller together: set hardwareProfile.vmSize to the v7 size and storageProfile.diskControllerType to NVMe, plus Trusted Launch if the VM doesn't have it yet.
5. Start the VM and validate.

Microsoft's conversion script, published by its SAP on Azure team as a community utility, runs these steps for one VM:

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/Azure/SAP-on-Azure-Scripts-and-Utilities/refs/heads/main/Azure-NVMe-Utils/Azure-NVMe-Conversion.ps1" -OutFile "Azure-NVMe-Conversion.ps1"

.\Azure-NVMe-Conversion.ps1 `
  -ResourceGroupName "rg-avd-prod" `
  -VMName "avd-prod-0" `
  -NewControllerType "NVMe" `
  -VMSize "Standard_D4s_v7" `
  -FixOperatingSystemSettings `
  -StartVM `
  -WriteLogfile

Validate before you call it done. After the restart, Device Manager should show Standard NVM Express Controller under Storage controllers, and the session host should report Available in the host pool. Data disks keep their contents, but drive letters can shift if anything relies on LUN order.

Rolling back

The disks themselves aren't touched, so a rollback is another controller and size change rather than a restore. Run the same script with -NewControllerType SCSI and the original size. Keep a snapshot of the OS disk until validation passes anyway.

Upgrade session hosts in place with Atlas AVD

Doing those steps by hand, one VM at a time, is fine for two desktops and tedious for forty. Atlas AVD runs the same sequence across a host pool from the Resize action:

1. Open Host Pools, pick the pool, and tick the hosts in Session Hosts.
2. Select Resize in the bulk action bar.
3. For each host, choose a size under Newer generation (upgrade in place), for example D4s_v5 → D4s_v7. Atlas only offers sizes of the same series that are available in the pool's region and not blocked for your subscription.
4. Confirm.

For each host, Atlas:

• checks the prerequisites: Generation 2, Windows, no Azure Disk Encryption, no temporary disk on either side, and that the target size is offered and unrestricted in the region;
• prepares Windows for NVMe over Run Command and confirms the driver setting stuck;
• deallocates the host, tags the OS disk as NVMe-capable, and sends the new size, the NVMe controller and (when the size requires it) Trusted Launch in a single update, so Azure either accepts the whole change or leaves the VM as it was;
• starts the host again only if it was running before, so hosts your power schedule had switched off stay off (a host that was off is started briefly to prepare Windows, then deallocated again).

A host that fails a check is left untouched, and its log row says exactly why: Generation 1, a temporary disk, an encryption extension, or a size that isn't available. To roll a host back, pick its old size under Older generation in the same dialog. Every change is recorded in the audit log and on the environment timeline with the disk controller before and after.

As with any resize, the host is deallocated, so drain it first if users are signed in.

Get your images ready in the same place

A v7 host built from an image also needs a v7-ready image definition: Generation 2, Trusted Launch allowed, and tagged for the NVMe controller. Many existing definitions miss the NVMe tag, because Azure treats a definition without DiskControllerTypes as SCSI-only. On the Imaging page, each image definition now has a v6 / v7 VM sizes card that shows which of the three it meets. For a Generation 2 definition that falls short, Upgrade for v6/v7 offers two routes:

• Update this definition adds the missing features in place, effective from the next version. Host pools that already use the definition pick up that version as the latest, with no reference to change.
• Create a v7-ready copy creates a new definition next to the original and leaves the original untouched until you move host pools across.

Either route can also copy the latest version into the v7-ready definition, so you don't have to rebuild. Atlas can't look inside an image, so it asks you to confirm that the image boots with the NVMe controller first. That holds if it was built from an NVMe-capable VM, or if Windows was prepared with stornvme set to start at boot. Deploy one test host on a v7 size from the copied version before you roll it out.

New Generation 2 definitions created in Atlas are tagged for both SCSI and NVMe from the start. Generation 1 definitions can't be upgraded. Their images have to be rebuilt from a Generation 2 VM, and the card says so.

Which v7 size?

Stay in the same series and suffix, and size against what the hosts actually use:

Reservations and savings plans are scoped to a VM family, so exchange reservations to follow the hosts, and reapply Azure Hybrid Benefit on redeployed VMs rather than assuming it carries over. The reserved instances vs savings plans guide covers the trade-offs.

FAQ

Can I resize a v5 VM straight to v7 in the Azure portal?

Usually not. If the v5 VM uses the SCSI controller and the v7 size is NVMe-only, the portal resize is refused or leaves a VM that fails to boot. The controller has to be switched as part of the move, after Windows is prepared for NVMe.

Do Windows 11 multi-session hosts support NVMe?

Yes. Current Windows 10 and 11 multi-session builds include the in-box stornvme driver. The conversion only changes its start type to boot so the OS disk is found on the new controller.

What about session hosts with a temporary disk?

Windows can't move between a size with a temporary disk and one without, and a v5 temporary disk doesn't carry over to the raw NVMe temporary disk of a v7 d size. Redeploy those hosts from an image on the new size.

Is the change reversible?

Yes. The OS and data disks are untouched, so switching the controller back to SCSI and the size back to the original reverts it. Keep a snapshot until you've validated the host.

Will Trusted Launch break my session hosts?

Trusted Launch turns on Secure Boot and a virtual TPM. Current Windows images and Microsoft-signed drivers boot normally. Older unsigned kernel or filter drivers from security, backup or monitoring agents might not, so update them before converting.

v7 series names, retirement dates and conversion steps are taken from Microsoft's documentation and announcements as of October 2026. Availability varies by region; check your region and quota before planning a migration.