Michele Blum

Ephemeral OS Disk Support For AVD Now In Public Preview

Ephemeral OS disks are now (October 2025) in public preview for Azure Virtual Desktop (short AVD). If you manage pooled, non-persistent host pools, this preview can significantly speed up session host provisioning and re-image cycles by placing the operating system on the VM’s local storage instead of a remote managed disk. That change gives you lower read/write latency, faster resets, and snappier desktop performance for stateless workloads.

Below I explain what Ephemeral OS disks are, the benefits and limitations, sizing and autoscale guidance, how to deploy from the portal, and a short real-world note from my own test.

What Ephemeral OS disks actually are

Ephemeral OS disks store the OS on the VM’s local storage (OS cache or temporary disk) rather than on remote managed disks. They’re designed for non‑persistent environments where you don’t need to retain session host state between uses. Because I/O happens locally, you get higher IOPS, lower latency, and much faster reimage/reset operations compared with managed OS disks. Note that Azure is gradually moving away from explicit physical cache‑disk placement: older VM families (for example Dsv2/Dsv3) may still expose a dedicated OS cache, while newer generations typically use local NVMe (Dsv6+) or the VM temporary disk (Ddsv4/Ddsv5) for placement — so the placement options available for ephemeral OS disks depend on the VM size you choose.

Ephemeral OS disks for AVD are in PREVIEW; the Microsoft Supplemental Terms for Previews apply, so don’t treat this as GA functionality for production workloads.

Key benefits

  • Faster provisioning and re-imaging: Session hosts come up and reset far more quickly — great for autoscale and rapid replacement scenarios.
  • Improved performance: Local read/write beats remote disk latency for many desktop workloads.
  • Optimized for stateless workloads: Ieal for pooled host pools where persistent OS state isn’t required.

Supported scenarios and key features

  • Supported only for pooled host pools configured with session host configuration.
  • Supported for all image types: Marketplace, custom images, and Azure Compute Gallery.
  • Placement is controlled by DiffDiskPlacement and can target OS cache or temp disk.
  • For Windows VMs, additionally, the page file is configured on the OS disk.
  • VMs using ephemeral OS disks can be restarted, re-imaged, or deleted — they cannot be de-allocated.
  • Fast reset and re-image capability: Instances return quickly to their original boot state.

Limitations

The following aren’t supported with ephemeral OS disks during preview:

  • Deallocation of VMs
  • Capturing VM images
  • Disk snapshots
  • Azure Disk Encryption
  • Azure Backup
  • Azure Site Recovery
  • OS Disk Swap
  • Azure Government regions

Additional preview limitations on storage and VM families

NVMe and premium SSDs aren’t supported for ephemeral OS disks for AVD in preview, and in my tests the portal even blocked the Standard SSD configurations. Practically, that rules out many v6 VM families that rely on local NVMe (for example, D‑Series v6 and E‑Series v6) for now.

Microsoft Learn currently references Standard SSD as the preferred OS disk type for preview, but in my deployments, the portal consistently auto‑selected Standard HDD.

VM Sizing

The ephemeral OS disk must fit within the VM’s available temp or cache, so the image OS disk size has to be less than or equal to the VM’s temp/cache size. For example, many Windows 11 Enterprise multi‑session marketplace images are ~127 GiB.

  • For OS cache placement, pick a VM with cache ≥ 127 GiB — Standard_DS3_v3 exposes 127 GiB cache and is the smallest (and newer) DSv3 size that works.
  • For temp disk placement, the same 127 GiB image requires a VM with temp ≥ 127 GiB — Standard_D4ds_v5 (150 GiB temp) is a common match and would leave roughly 23 GiB free temp disk space after placing the OS.

Bottom line: Always check image size versus VM temp/cache before enabling ephemeral — the portal will block incompatible combinations, and preview limitations can further restrict your choices.

Autoscale recommendations

Because ephemeral session hosts can’t be de-allocated, Microsoft recommends to use Dynamic Autoscaling and set the Minimum percentage of active hosts (%) to 100% for each scaling phase. That ensures autoscale creates and deletes hosts rather than trying to start/de-allocate them, which would fail for ephemeral hosts.

How to create a session host with Ephemeral OS disks

Go to the Azure portal and create a pooled host pool. Configure it with a session host configuration. Ephemeral OS disks only work on pooled host pools with a session host configuration.

On the Session hosts tab, choose the VM size, image, and OS disk type. When you enable ephemeral, the portal auto‑selects the required OS disk type. Microsoft Learn currently lists only Standard SSD in preview as suitable, but in my tests the portal selected Standard HDD and even indicated only HDD was supported. 😀

Set the image value and choose placement (cache or temp) to configure the ephemeral OS disk. The portal will block the ephemeral option if the chosen VM size doesn’t expose enough temp/cache or isn’t supported. If that happens, pick a different VM size.

After deployment completes, open the session host’s Disk properties. Confirm the OS disk is set to ephemeral.


SPECIAL NOTE: If the portal rejects the config because the chosen VM doesn’t have enough temp/cache disk space, change to a size that does.

Enabling ephemeral on existing host pools

Before you schedule a session host update to enable ephemeral OS disks, edit and save the session host configuration to enable ephemeral — the update uses whatever configuration is current when it runs. If you forget, the scheduled update will redeploy hosts with the previous settings. Also note that the session host update and the session host configuration for pooled host pools feature are still in PREVIEW.

Conclusion

Ephemeral OS disks won’t suit every AVD scenario. For pooled, stateless deployments they’re often a clear win — faster provisioning, quicker reimages, and lower local I/O latency. I’m hopeful support for NVMe, premium SSDs, and newer VM families will arrive by GA. That would make the feature useful in more environments and even more powerful.

Sources

You might also like
Tags: Azure Virtual Desktop, Microsoft

More Similar Posts