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

A standard managed disk created from an 80-GiB 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.

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

Yes.

No.

Yes. 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. 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.

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.

You can take a snapshot of a managed disk and then use the snapshot to create another managed disk. You can also create a new managed disk from an existing managed disk.

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

No.

No.

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's a full standalone copy of that blob at that time and there's 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.

Managed disks can't be renamed. However, you may rename an unmanaged disk as long as it isn't 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 and the data disks.

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're attaching to.

• You can have more efficient backup and recovery operations, reducing downtime in the event of data loss or system failure, by frequently backing up your data disks. If the data disk experiences an issue, it's easier to recover since it's separate from the OS disk.

• You can expand your storage capacity by adding or expanding data disks without affecting the OS disk. Only data disks support live resize, you can't increase the size of OS disks without stopping the VM.

• Separating the OS from your applications and data onto different disks helps ensure that disks IOPs from the operating system and the application data don't interfere with each other. This can enhance overall system performance, and prevent contention issues that might happen when both the OS and applications are competing for disk resources.

• If there's a system failure or corruption occurs on the OS disk, you can reimage or reinstall the operating system without affecting the data disk. This reduces the risk of data loss and makes it easier when troubleshooting and for maintenance procedures.

• You can apply separate access controls and permissions to the OS disk and the data disk. This separation limits access to critical system files on the OS disk, mitigating potential security risks.

Yes.

No. Snapshots must be copied to other regions in creation order.

The copy fails.

Yes. All managed snapshots and images are automatically encrypted.

All disk types support some form of snapshot. For Ultra Disks, they only support incremental snapshots and have some limitations. For details, see Create an incremental snapshot for managed disks. The other disk types support both types of snapshots for all their disk sizes.

Deleting one of your incremental snapshots doesn't 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 aren't impacted due to the deletion of the first snapshot.

Compatible managed disks created with API version 2019-07-01 or newer can enable shared disks. To do this, you need to unmount the disk from all VMs that it's attached to. Then, edit the maxShares property on the disk.

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

Yes.

If you're 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 MB/s = # of IOPS * 16 / 1000.

In addition to the disk throttle, there's an IO throttle that gets imposed at the VM level. Ensure that the VM size you're 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 don't 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. You can migrate data from an existing data disk to an Ultra Disk. Attach both disks to the same VM and directly copy the data to the Ultra Disk, or utilize a third party solution for data migration.

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 use a third party solution for data migration.

No, this isn't currently supported.

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

No.

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's 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.

No.

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.

It isn't possible to switch in-place, but it's possible to create copies of the disks and attach them to a new VM encrypted with server-side encryption. However, for Linux VMs if you encrypted the OS disk of a Linux VM with ADE, you can't disable ADE on Linux when the OS disk is encrypted. To migrate Windows VMs with ADE enabled or Linux VMs with only the data disks ADE encrypted,

• Disable encryption and remove the encryption extension on Windows or on Linux.
• Then make a new managed disk using the current disk as a source.
• Attach the new disk to a new VM that has never enabled ADE.
• Encrypt that new disk with customer-managed keys.

Yes. First, switch your disk to use platform-managed keys with one of the following steps:

rgName=yourResourceGroupName
diskName=yourDiskName

az disk update -n $diskName -g $rgName --encryption-type EncryptionAtRestWithPlatformKey

$rgName = "yourResourceGroupName"
$diskName = "yourDiskName"

New-AzDiskUpdateConfig -EncryptionType "EncryptionAtRestWithPlatformKey" | Update-AzDisk -ResourceGroupName $rgName -DiskName $diskName

Then, encrypt your current disk with Azure Disk Encryption.

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.

There's a fixed cost for each disk size, which comes provisioned with specific limits on IOPS and throughput. The other costs are outbound bandwidth, snapshot capacity, and costs associated with on-demand bursting, 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 MB/s per core. The GS series offers 5,000 IOPS per core and 50 MB/s per core.

The local SSD is temporary storage that is included with a VM using managed disks. There's no extra cost for this temporary storage. You shouldn't use this local SSD to store application data because it isn't persisted in Azure Storage.

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

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 4 TiB for an 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).

P4 (32 GiB) and P6 (64 GiB) disk sizes aren't 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 an 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'll continue to land on P10 with 500 IOPS and 100 MB/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. You can also use performance tiers, see the articles for changing performance tiers with either the Azure CLI/PowerShell module or the Azure portal.

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 isn't 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 MB/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 aren't 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 reattach your disk. The performance targets of larger disk sizes have been increased for both premium SSDs and standard SSDs at GA.

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

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

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.