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 actually 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.
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.
For more information on how Azure uses the temporary disk, see Understanding the temporary drive on Microsoft Azure 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 details 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 details, 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 two performance tiers for storage that you can choose from when creating your disks -- Standard Storage and Premium Storage. Also, there are two types of disks -- unmanaged and managed -- and they can reside in either performance tier.
Standard Storage is backed by HDDs, and delivers cost-effective storage while still being performant. Standard storage can be replicated locally in one datacenter, or be geo-redundant with primary and secondary data centers. For more information about storage replication, please see Azure Storage replication.
For more information about using Standard Storage with VM disks, please see Standard Storage and Disks.
Premium Storage is backed by SSDs, and delivers high-performance, low-latency disk support for VMs running I/O-intensive workloads. You can use Premium Storage with DS, DSv2, GS, Ls, or FS series Azure VMs. For more information, please see Premium Storage.
Unmanaged disks are the traditional type of disks that have been used by VMs. With these, you create your own storage account and specify that storage account when you create the disk. You have to 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. Even 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, please 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 Premium vs Standard for both unmanaged and managed disks to help you decide what to use.
|Azure Premium Disk||Azure Standard Disk|
|Disk Type||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||HDD-based cost effective disk support for Dev/Test VM scenarios|
|Scenario||Production and performance sensitive workloads||Dev/Test, non-critical,
|Disk Size||P4: 32 GB (Managed Disks only)
P6: 64 GB (Managed Disks only)
P10: 128 GB
P20: 512 GB
P30: 1024 GB
P40: 2048 GB
P50: 4095 GB
|Unmanaged Disks: 1 GB – 4 TB (4095 GB)
S4: 32 GB
S6: 64 GB
S10: 128 GB
S20: 512 GB
S30: 1024 GB
S40: 2048 GB
S50: 4095 GB
|Max Throughput per Disk||250 MB/s||60 MB/s|
|Max IOPS per Disk||7500 IOPS||500 IOPS|
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 accessbile 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.