About disks storage for Azure Linux VMs
Just like any other computer, virtual machines in Azure use disks as a place to store an operating system, applications, and data. All Azure virtual machines have at least two disks – a Linux operating system disk and a temporary disk. The operating system disk is created from an image, and both the operating system disk and the image are virtual hard disks (VHDs) stored in an Azure storage account. Virtual machines also can have one or more data disks, that are also stored as VHDs.
In this article, we will talk about the different uses for the disks, and then discuss the different types of disks you can create and use. This article is also available for Windows virtual machines.
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager model.
Disks used by VMs
Let's take a look at how the disks are used by the VMs.
Operating system disk
Every virtual machine has one attached operating system disk. It's registered as a SATA drive and is labeled /dev/sda by default. This disk has a maximum capacity of 2048 gigabytes (GB).
Each VM contains a temporary disk. The temporary disk provides short-term storage for applications and processes and is intended to only store data such as page or swap files. Data on the temporary disk may be lost during a maintenance event or when you redeploy a VM. During a standard reboot of the VM, the data on the temporary drive should persist. However, there are cases where the data may not persist, such as moving to a new host. Accordingly, any data on the temp drive should not be data that is critical to the system.
On Linux virtual machines, the disk is typically /dev/sdb and is formatted and mounted to /mnt by the Azure Linux Agent. The size of the temporary disk varies, based on the size of the virtual machine. For more information, see Sizes for Linux virtual machines.
A data disk is a VHD that's attached to a virtual machine to store application data, or other data you need to keep. Data disks are registered as SCSI drives and are labeled with a letter that you choose. Each data disk has a maximum capacity of 4095 GB. The size of the virtual machine determines how many data disks you can attach to it and the type of storage you can use to host the disks.
For more information about virtual machines capacities, see Sizes for Linux virtual machines.
Azure creates an operating system disk when you create a virtual machine from an image. If you use an image that includes data disks, Azure also creates the data disks when it creates the virtual machine. Otherwise, you add data disks after you create the virtual machine.
You can add data disks to a virtual machine at any time, by attaching the disk to the virtual machine. You can use a VHD that you've uploaded or copied to your storage account, or one that Azure creates for you. Attaching a data disk associates the VHD file with the VM, by placing a 'lease' on the VHD so it can't be deleted from storage while it's still attached.
The VHDs used in Azure are .vhd files stored as page blobs in a standard or premium storage account in Azure. For details about page blobs, see Understanding block blobs and page blobs. For details about premium storage, see High-performance premium storage and Azure VMs.
Azure supports the fixed disk VHD format. The fixed format lays the logical disk out linearly within the file, so that disk offset X is stored at blob offset X. A small footer at the end of the blob describes the properties of the VHD. Often, the fixed-format wastes space because most disks have large unused ranges in them. However, Azure stores .vhd files in a sparse format, so you receive the benefits of both the fixed and dynamic disks at the same time. For more information, see Getting started with virtual hard disks.
All VHD files in Azure that you want to use as a source to create disks or images are read-only, except the .vhd files uploaded or copied to Azure storage by the user (which can be either read-write or read-only). When you create a disk or image, Azure makes copies of the source .vhd files. These copies can be read-only or read-and-write, depending on how you use the VHD.
When you create a virtual machine from an image, Azure creates a disk for the virtual machine that is a copy of the source .vhd file. To protect against accidental deletion, Azure places a lease on any source .vhd file that’s used to create an image, an operating system disk, or a data disk.
Before you can delete a source .vhd file, you’ll need to remove the lease by deleting the disk or image. To delete a .vhd file that is being used by a virtual machine as an operating system disk, you can delete the virtual machine, the operating system disk, and the source .vhd file all at once by deleting the virtual machine and deleting all associated disks. However, deleting a .vhd file that’s a source for a data disk requires several steps in a set order. First you detach the disk from the virtual machine, then delete the disk, and then delete the .vhd file.
If you delete a source .vhd file from storage, or delete your storage account, Microsoft can't recover that data for you.
Types of disks
Azure Disks are designed for 99.999% availability. Azure Disks have consistently delivered enterprise-grade durability, with an industry-leading ZERO% Annualized Failure Rate.
There are three performance tiers for storage that you can choose from when creating your disks -- Premium SSD Disks, Standard SSD, and Standard HDD Storage. Also, there are two types of disks -- unmanaged and managed.
Standard HDD disks
Standard HDD disks are backed by HDDs, and deliver cost-effective storage. Standard HDD storage can be replicated locally in one datacenter, or be geo-redundant with primary and secondary data centers. For more information about storage replication, see Azure Storage replication.
For more information about using Standard HDD disks, see Standard Storage and Disks.
Standard SSD disks
Standard SSD disks are designed to address the same kind of workloads as Standard HDD disks, but offer more consistent performance and reliability than HDD. Standard SSD disks combine elements of Premium SSD disks and Standard HDD disks to form a cost-effective solution best suited for applications like web servers that do not need high IOPS on disks. Where available, Standard SSD disks are the recommended deployment option for most workloads. Standard SSD disks are available as Managed Disks in all regions but are currently only available with the locally redundant storage (LRS) resiliency type.
Premium SSD disks
Premium SSD disks are backed by SSDs, and delivers high-performance, low-latency disk support for VMs running I/O-intensive workloads. Typically you can use Premium SSD disks with sizes that include an "s" in the series name. For example, there is the Dv3-Series and the Dsv3-series, the Dsv3-series can be used with Premium SSD disks. For more information, please see Premium Storage.
Unmanaged disks are the traditional type of disks that have been used by VMs. With these disks, you create your own storage account and specify that storage account when you create the disk. Make sure you don't put too many disks in the same storage account, because you could exceed the scalability targets of the storage account (20,000 IOPS, for example), resulting in the VMs being throttled. With unmanaged disks, you have to figure out how to maximize the use of one or more storage accounts to get the best performance out of your VMs.
Managed Disks handles the storage account creation/management in the background for you, and ensures that you do not have to worry about the scalability limits of the storage account. You simply specify the disk size and the performance tier (Standard/Premium), and Azure creates and manages the disk for you. As you add disks or scale the VM up and down, you don't have to worry about the storage being used.
You can also manage your custom images in one storage account per Azure region, and use them to create hundreds of VMs in the same subscription. For more information about Managed Disks, see the Managed Disks Overview.
We recommend that you use Azure Managed Disks for new VMs, and that you convert your previous unmanaged disks to managed disks, to take advantage of the many features available in Managed Disks.
The following table provides a comparison of Standard HDD, Standard SSD, and Premium SSD for unmanaged and managed disks to help you decide what to use. Sizes denoted with an asterisk are currently in preview.
|Azure Premium Disk||Azure Standard SSD Disk||Azure Standard HDD Disk|
|Disk Type||Solid State Drives (SSD)||Solid State Drives (SSD)||Hard Disk Drives (HDD)|
|Overview||SSD-based high-performance, low-latency disk support for VMs running IO-intensive workloads or hosting mission critical production environment||More consistent performance and reliability than HDD. Optimized for low-IOPS workloads||HDD-based cost effective disk for infrequent access|
|Scenario||Production and performance sensitive workloads||Web servers, lightly used enterprise applications and Dev/Test||Backup, Non-critical, Infrequent access|
|Disk Size||P4: 32 GiB (Managed Disks only)
P6: 64 GiB (Managed Disks only)
P10: 128 GiB
P15: 256 GiB (Managed Disks only)
P20: 512 GiB
P30: 1024 GiB
P40: 2048 GiB
P50: 4,095 GiB
P60: 8,192 GiB * (8 TiB)
P70: 16,384 GiB * (16 TiB)
P80: 32,767 GiB * (32 TiB)
|Managed Disks only:
E10: 128 GiB
E15: 256 GiB
E20: 512 GiB
E30: 1024 GiB
E40: 2048 GiB
E50: 4095 GiB
E60: 8,192 GiB * (8 TiB)
E70: 16,384 GiB * (16 TiB)
E80: 32,767 GiB * (32 TiB)
|Unmanaged Disks: 1 GiB – 4 TiB (4095 GiB)
S4: 32 GiB
S6: 64 GiB
S10: 128 GiB
S15: 256 GiB
S20: 512 GiB
S30: 1024 GiB
S40: 2048 GiB
S50: 4095 GiB
S60: 8,192 GiB * (8 TiB)
S70: 16,384 GiB * (16 TiB)
S80: 32,767 GiB * (32 TiB)
|Max Throughput per Disk||P4: 25 MiB/s
P6: 50 MiB/s
P10: 100 MiB/s
P15: 125 MiB/s
P20: 150 MiB/s
P30: 200 MiB/s
P40-P50: 250 MiB/s
P60: 480 MiB/s *
P70-P80: 750 MiB/s *
|E10-E50: Up to 60 MiB/s
E60: Up to 300 MiB/s *
E70-E80: 500 MiB/s *
|S4 - S50: Upt o 60 MiB/s
S60: Up to 300 MiB/s *
S70-S80: Up to 500 MiB/s *
|Max IOPS per Disk||P4: 120 IOPS
P6: 240 IOPS
P10: 500 IOPS
P15: 1100 IOPS
P20: 2300 IOPS
P30: 5000 IOPS
P40-P50: 7500 IOPS
P60: 12,500 IOPS *
P70: 15,000 IOPS *
P80: 20,000 IOPS *
|E10-E50: Up to 500 IOPS
E60: Up to 1300 IOPS *
E70-E80: Up to 2000 IOPS *
|S4-S50: Up to 500 IOPS
S60: Up to 1300 IOPS *
S70-S80: Up to 2000 IOPS *
For preview sizes, see our FAQ to learn what regions they are available in.
When adding data disks to a Linux VM, you may encounter errors if a disk does not exist at LUN 0. If you are adding a disk manually using the
azure vm disk attach-new command and you specify a LUN (
--lun) rather than allowing the Azure platform to determine the appropriate LUN, take care that a disk already exists / will exist at LUN 0.
Consider the following example showing a snippet of the output from
[5:0:0:0] disk Msft Virtual Disk 1.0 /dev/sdc [5:0:0:1] disk Msft Virtual Disk 1.0 /dev/sdd
The two data disks exist at LUN 0 and LUN 1 (the first column in the
lsscsi output details
[host:channel:target:lun]). Both disks should be accessible from within the VM. If you had manually specified the first disk to be added at LUN 1 and the second disk at LUN 2, you may not see the disks correctly from within your VM.
host value is 5 in these examples, but this may vary depending on the type of storage you select.
This disk behavior is not an Azure problem, but the way in which the Linux kernel follows the SCSI specifications. When the Linux kernel scans the SCSI bus for attached devices, a device must be found at LUN 0 in order for the system to continue scanning for additional devices. As such:
- Review the output of
lsscsiafter adding a data disk to verify that you have a disk at LUN 0.
- If your disk does not show up correctly within your VM, verify a disk exists at LUN 0.