This article answers some frequently asked questions about Azure Managed Disks and Azure Premium SSD 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.
For a standard managed disk, will I be charged for the actual size of the data on the disk or for the provisioned capacity of the disk?
You're charged based on the provisioned capacity of the disk. For more information, see the pricing page.
Can I use a VHD file in an Azure storage account to create a managed disk with a different subscription?
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.
Can I change the computer name property when a specialized (not created by using the System Preparation tool or generalized) operating system disk is used to provision a VM?
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.
When creating a disk from a blob, is there any continually existing relationship with that source blob?
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.
I configured my disk to 40000 IOPS but I'm only seeing 12800 IOPS, why am I not seeing the performance of the disk?
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.
What changes are required in a pre-existing Azure Backup service configuration prior/after migration to Managed Disks?
No changes are required.
Yes, backups work seamlessly.
What changes are required in a pre-existing Azure Disks Encryption configuration prior/after migration to managed disks?
No changes are required.
Is automated migration of an existing virtual machine scale set from unmanaged disks to managed disks supported?
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.
Can I fail over my on-premises machines protected by Azure Site Recovery to a VM with managed disks?
Yes, you can choose to failover to a VM with Managed Disks.
Is there any impact of migration on Azure VMs protected by Azure Site Recovery via Azure to Azure replication?
No. Azure Site Recovery Azure to Azure protection for VMs with Managed Disks is available.
Can I migrate VMs with unmanaged disks that are located on storage accounts that are or were previously encrypted to managed disks?
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.
Does Azure Site Recovery support server-side encryption with customer-managed key for on-premises to Azure and Azure to Azure disaster recovery scenarios?
Yes.
Can I backup Managed Disks encrypted with server-side encryption with customer-managed key using Azure Backup service?
Yes.
Can I convert VMs with unmanaged disks that are located on storage accounts that are or were previously encrypted to managed disks?
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:
- Sign in to the Azure portal.
- Select the disk you'd like to change the encryption type of.
- Select Encryption.
- For Key management select Platform-managed key and select save.
Your managed disk has successfully switched from being secured with your own customer-managed key to a platform-managed key.
Then, encrypt your current disk with Azure Disk Encryption.
If a VM uses a size series that supports Premium SSD disks, such as a DSv2, can I attach both premium and standard data disks?
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.
Can I attach both premium and standard data disks to a size series that doesn't support Premium SSD disks, such as D, Dv2, G, or F series?
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.
If my existing premium managed disk less than 64 GiB was created before the small disk was enabled (around June 15, 2017), how is it billed?
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.
What are the recommended VM sizes for larger disk sizes (>4 TiB) for Standard SSD and Standard HDD disks to achieve optimized disk IOPS and Bandwidth?
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.
How can I upgrade my disks (>4 TiB) which were deployed during the larger disk sizes preview in order to get the higher IOPS & bandwidth at GA?
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.
Can I use the SAS URI of a disk or snapshot to download the underlying VHD of a VM in the same subnet as the subnet of the private endpoint associated with the disk?
Yes.
Can I use a SAS URI of a disk/snapshot to download the underlying VHD of a VM not in the same subnet as the subnet of the private endpoint not associated with the disk?
No.
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.