Frequently asked questions about Azure IaaS VM disks and managed and unmanaged premium disks

Managed Disks is a feature that simplifies disk management for Azure IaaS VMs by handling storage account management for you. For more information, see the Managed Disks overview.

A standard managed disk created from an 80-GB VHD is treated as the next available standard disk size, which is an S10 disk. You're charged according to the S10 disk pricing. For more information, see the pricing page.

Yes. You're charged for each transaction. For more information, see the pricing page.

You're charged based on the provisioned capacity of the disk. For more information, see the pricing page.

The pricing of premium managed disks is the same as unmanaged premium disks.

Yes. You can change the storage account type of your managed disks by using the Azure portal, PowerShell, or the Azure CLI.

Yes.

No.

Managed Disks eliminates the limits associated with storage accounts. However, the maximum limit is 50,000 managed disks per region and per disk type for a subscription.

No. The VMs in an availability set must use either all managed disks or all unmanaged disks. When you create an availability set, you can choose which type of disks you want to use.

Yes.

Yes. You can create an empty disk. A managed disk can be created independently of a VM, for example, without attaching it to a VM.

Depending on the region where the availability set that uses Managed Disks is located, the supported fault domain count is 2 or 3.

You set up a private storage account for VM diagnostics.

Managed Disks supports three key default roles:

• Owner: Can manage everything, including access
• Contributor: Can manage everything except access
• Reader: Can view everything, but can't make changes

You can generate a read-only shared access signature (SAS) URI for the managed disk and use it to copy the contents to a private storage account or on-premises storage. You can use the SAS URI using the Azure portal, Azure PowerShell, the Azure CLI, or AzCopy

Customers can take a snapshot of their managed disks and then use the snapshot to create another managed disk.

Yes, but they'll be retired by September 30, 2025, and as of November 18, 2022, new customer subscriptions won't be eligible to create unmanaged disks. We recommend that you use managed disks for new workloads and migrate your current workloads to managed disks.

No.

Yes.

Azure Managed Disks currently supports only locally redundant storage and zone-redundant storage managed disks.

No. This feature is not supported currently.

No. This is not supported currently as a lease is present to prevent accidental deletion when the disk is being used.

No. You can't update the computer name property. The new VM inherits it from the parent VM, which was used to create the operating system disk.

• List of templates using Managed Disks
• https://github.com/chagarw/MDPP

No, when the new disk is created it is a full standalone copy of that blob at that time and there is no connection between the two. If you like, once you've created the disk, the source blob may be deleted without affecting the newly created disk in any way.

For managed disks you cannot rename them. However, you may rename an unmanaged disk as long as it is not currently attached to a VHD or VM.

Generation 1 images can only use GPT partitioning on data disks, not OS disks. OS disks must use the MBR partition style.

Generation 2 images can use GPT partitioning on the OS disk as well as the data disks.

Disk reservation is the option to purchase one year of disk storage in advance, reducing your total cost. For details regarding Azure disk reservations, see our article on the subject: Understand how your reservation discount is applied to Azure Disk.

Azure disk reservation provides the option to purchase Premium SSDs in the specified SKUs from P30 (1 TiB) up to P80 (32 TiB) for a one-year term. There is no limitation on the minimum amount of disks necessary to purchase a disk reservation. Additionally, you can choose to pay with a single, upfront payment or monthly payments. There is no additional transactional cost applied for Premium SSD Managed Disks.

Reservations are made in the form of disks, not capacity. In other words, when you reserve a P80 (32 TiB) disk, you get a single P80 disk, you cannot then divide that specific reservation up into two smaller P70 (16 TiB) disks. You can, of course, reserve as many or as few disks as you like, including two separate P70 (16 TiB) disks.

Disks reservation follows a model similar to reserved virtual machine (VM) instances. The difference being that a disk reservation cannot be applied to different SKUs, while a VM instance can. See Save costs with Azure Reserved VM Instances for more information on VM instances.

Azure disks reservation are purchased for a specific region and SKU (like P30 in East US 2), and therefore cannot be used outside these constructs. You can always purchase an additional Azure Disks Reservation for your disk storage needs in other regions or SKUs.

You will receive email notifications 30 days prior to expiration and again on the expiration date. Once the reservation expires, deployed disks will continue to run and will be billed with the latest pay-as-you-go rates.

Yes, all disk types support single instance VM SLA.

No. All managed disks, even shared disks, must be in the same region as the VM they are attaching to.

Yes.

No, they must wait for the previous copy to finish.

Currently, yes.

You can check the status of the copy by checking the completionPercent property. A snapshot is ready when this property is 100.

No, snapshots must be copied to other regions in creation order.

The copy will fail.

Yes. All managed snapshots and images are automatically encrypted.

Premium SSD, standard SSD, and standard HDD support snapshots. For these three disk types, snapshots are supported for all disk sizes (including disks up to 32 TiB in size). Ultra disks do not support snapshots.

Deleting one of your incremental snapshots does not affect subsequent incremental snapshots. The system merges the data occupied by the first snapshot with the next snapshot under the hood to ensure that the subsequent snapshots are not impacted due to the deletion of the first snapshot.

No, it is only supported for a subset of managed disk types. For details, see the conceptual article.

For regional information, see our conceptual article.

No, shared disks are only supported for data disks.

For supported sizes, see our conceptual article.

All managed disks created with API version 2019-07-01 or higher can enable shared disks. To do this, you need to unmount the disk from all VMs that it is attached to. Next, edit the maxShares property on the disk.

Unmount the disk from all VMs that it is attached to. Then edit the maxShare property on the disk to 1.

Yes.

No.

The only supported host caching option is None.

If you are unsure what to set your disk throughput to, we recommend you start by assuming an IO size of 16 KiB and adjust the performance from there as you monitor your application. The formula is: Throughput in MBps = # of IOPS * 16 / 1000.

In addition to the disk throttle, there is an IO throttle that gets imposed at the VM level. Ensure that the VM size you are using can support the levels that are configured on your disks. For details regarding IO limits imposed by your VM, see Sizes for virtual machines in Azure.

No, ultra disks do not support the different caching methods that are supported on other disk types. Set the disk caching to None.

Maybe, your VM has to be in a region and availability zone pair that supports Ultra disks. See getting started with ultra disks for details.

No, ultra Disks are only supported as data disks and are only supported as 4K native disks.

No, but you can migrate the data from an existing disk to an ultra disk. To migrate an existing disk to an ultra Disk, attach both disks to the same VM, and copy the disk's data from one disk to the other or leverage a 3rd party solution for data migration.

No, snapshots are not yet available.

No, Azure Backup support is not yet available.

No, this is not yet supported.

No, Azure Site Recovery is not yet supported for ultra disks.

No, upload can only be used during the creation of a new empty disk with the ReadyToUpload state.

Create a managed disk with the createOption property of creationData set to "Upload", then you can upload data to it.

No.

No.

Standard SSD disks are standard disks backed by solid-state media, optimized as cost effective storage for workloads that need consistent performance at lower IOPS levels.

All Azure regions now support Standard SSD disks.

Yes, Azure Backup is now available.

Standard SSD disks deliver better latency, consistency, availability, and reliability compared to HDD disks. Application workloads run a lot more smoothly on Standard SSD because of that. Note, Premium SSD disks are the recommended solution for most IO-intensive production workloads.

No, Standard SSDs disks are only available as Managed Disks.

Migration involves movement of the Disk from one Storage location to another. This is orchestrated via background copy of data, which can take several hours to complete, typically less than 24 Hrs depending on the amount of data in the disks. During that time your application can experience higher than usual read latency as some reads can get redirected to the original location, and can take longer to complete. There is no impact on write latency during this period.

No changes are required.

Yes, backups work seamlessly.

No changes are required.

No. You can create a new scale set with Managed Disks using the image from your old scale set with unmanaged disks.

No. You can export a page blob snapshot as a page blob and then create a Managed Disk from the exported page blob.

Yes, you can choose to failover to a VM with Managed Disks.

No. Azure Site Recovery Azure to Azure protection for VMs with Managed Disks is available.

Yes

Yes. Managed Disks are encrypted with server-side encryption with platform managed keys.

Yes. By default, all managed disks are encrypted, including the OS disk.

Platform managed keys are managed by Microsoft. You can also use and manage your own keys stored in Azure Key Vault.

No.

No. Server-side Encryption with both platform and customer managed keys are available in all the regions where Managed Disks are available.

Yes.

Yes.

Yes

No. But if you export a VHD to an encrypted storage account from an encrypted managed disk or snapshot, then it's encrypted.

Yes.

Not all OS images support deploying with an unmanaged disk in the Azure portal. If your chosen image doesn't support this method of deployment, we recommend that you use managed disks for new workloads and convert your existing disk to a managed disk. If you’re unable to use managed disks, you can deploy a VM using unmanaged disks with either the Azure PowerShell module or the Azure CLI.

No. You can attach only standard data disks to VMs that don't use a size series that supports Premium SSD disks.

A premium data disk created from an 80-GB VHD is treated as the next-available premium disk size, which is a P10 disk. You're charged according to the P10 disk pricing.

There is a fixed cost for each disk size, which comes provisioned with specific limits on IOPS and throughput. The other costs are outbound bandwidth and snapshot capacity, if applicable. For more information, see the pricing page.

The combined limits for cache and local SSD for a DS series are 4,000 IOPS per core and 33 MiB per second per core. The GS series offers 5,000 IOPS per core and 50 MiB per second per core.

The local SSD is temporary storage that is included with a Managed Disks VM. There is no extra cost for this temporary storage. We recommend that you do not use this local SSD to store your application data because it isn't persisted in Azure Blob storage.

There is no downside to the use of TRIM on Azure disks on either premium or standard disks.

Credit-based bursting is currently supported in all regions in Azure Public Cloud, sovereign clouds are not currently supported.

On-demand bursting is available in all public Azure regions.

No, it is only supported on premium SSD managed disks.

No, standard SSD managed disks of any size cannot be used with unmanaged disks or page blobs.

The partition type that Azure supports for Gen1 operating system disks is the master boot record (MBR). Although Gen1 OS disks only support MBR the data disks support GPT. While you can allocate up to a 4 TiB OS disk, the MBR partition type can only use up to 2 TiB of this disk space for the operating system. Azure supports up to 32 TiB for managed data disks.

The partition type that Azure supports for Gen2 operating system disks is GUID Partition Table (GPT). Gen2 VMs support up to a 4 TiB OS disk. Azure supports up to 32 TiB for managed data disks.

The partition type that Azure supports for an operating system disk using unmanaged disks is the master boot record (MBR). While you can allocate up to a 4 TiB OS disk, the MBR partition type can only use up to 2 TiB of this disk space for the operating system. Azure supports up to 4 TiB for Unmanaged data disks.

The largest page blob size that Azure supports is 8 TiB (8,191 GiB). The maximum page blob size when attached to a VM as data or operating system disks is 4 TiB (4,095 GiB).

You don't need to upgrade your existing Azure tools to create, attach, or resize disks larger than 1 TiB. To upload your VHD file from on-premises directly to Azure as a page blob or unmanaged disk, you need to use the latest tool sets listed below. We only support VHD uploads of up to 8 TiB.

P4 (32 GiB) and P6 (64 GiB) disk sizes are not supported as the default disk tiers for unmanaged disks and page blobs. You need to explicitly set the Blob Tier to P4 and P6 to have your disk mapped to these tiers. If you deploy a unmanaged disk or page blob with the disk size or content length less than 32 GiB or between 32 GiB to 64 GiB without setting the Blob Tier, you will continue to land on P10 with 500 IOPS and 100 MiB/s and the mapped pricing tier.

Existing small premium disks less than 64 GiB continue to be billed according to the P10 pricing tier.

You can take a snapshot of your small disks and then create a disk to automatically switch the pricing tier to P4 or P6 based on the provisioned size.

Yes.

The largest disk size supported by Azure Backup is 32 TiB (4 TiB for encrypted disks). The largest disk size supported by Azure Site Recovery is 8 TiB. Support for the larger disks up to 32 TiB is not yet available in Azure Site Recovery.

To achieve the disk throughput of Standard SSD and Standard HDD large disk sizes (>4 TiB) beyond 500 IOPS and 60 MiB/s, we recommend you deploy a new VM from one of the following VM sizes to optimize your performance: B-series, DSv2-series, Dsv3-Series, ESv3-Series, Fs-series, Fsv2-series, M-series, GS-series, NCv2-series, NCv3-series, or Ls-series VMs. Attaching large disks to existing VMs or VMs that are not using the recommended sizes above may experience lower performance.

You can either stop and start the VM that the disk is attached to or, detach and re-attach your disk. The performance targets of larger disk sizes have been increased for both premium SSDs and standard SSDs at GA.

The 8 TiB, 16 TiB, and 32 TiB disk SKUs are supported in all regions under global Azure, Microsoft Azure Government, and Azure China 21Vianet.

Host Caching (ReadOnly and Read/Write) is supported on disk sizes less than 4 TiB. This means any disk that is provisioned up to 4095 GiB can take advantage of Host Caching. Host caching is not supported for disk sizes more than or equal to 4096 GiB. For example, a P50 premium disk provisioned at 4095 GiB can take advantage of Host caching and a P50 disk provisioned at 4096 GiB cannot take advantage of Host Caching. We recommend leveraging caching for smaller disk sizes where you can expect to observe better performance boost with data cached to the VM.

You can leverage Private Links for restricting the export and import to Managed Disks only from your Azure virtual network.

You must set the DiskAccessId property to an instance of a disk access object and also set the NetworkAccessPolicy property to AllowPrivate.

No. Currently, you can link a disk access object to only one virtual network.

No. Currently, you can link a disk access object to a virtual network in the same subscription.

No. Currently, you can link a disk access object to a virtual network in the same subscription.

5

Yes.

No.

What if my question isn't answered here?

If your question isn't listed here, let us know and we'll help you find an answer. You can post a question at the end of this article in the comments. To engage with the Azure Storage team and other community members about this article, use the Microsoft Q&A question page for Azure Storage.

To request features, submit your requests and ideas to the Azure Storage feedback forum.