This article covers expanding OS disks and data disks for a Linux virtual machine (VM). You can add data disks to provide for more storage space, and you can also expand an existing data disk. The default virtual hard disk size for the operating system (OS) is typically 30 GB on a Linux VM in Azure. This article covers expanding either OS disks or data disks. You can't expand the size of striped volumes.
An OS disk has a maximum capacity of 4,095 GiB. However, many operating systems are partitioned with master boot record (MBR) by default. MBR limits the usable size to 2 TiB. If you need more than 2 TiB, consider attaching data disks for data storage. If you do need to store data on the OS disk and require extra space, convert it to GUID Partition Table (GPT).
Warning
Always make sure that your filesystem is in a healthy state, your disk partition table type (GPT or MBR) will support the new size, and ensure your data is backed up before you perform disk expansion operations. For more information, see the Azure Backup quickstart.
Identify Azure data disk object within the operating system
When expanding a data disk, when there are several data disks present on the VM, it may be difficult to relate the Azure LUNs to the Linux devices. If the OS disk needs expansion, it is clearly labeled in the Azure portal as the OS disk.
Start by identifying the relationship between disk utilization, mount point, and device, with the df command.
df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 xfs 97G 1.8G 95G 2% /
<truncated>
/dev/sdd1 ext4 32G 30G 727M 98% /opt/db/data
/dev/sde1 ext4 32G 49M 30G 1% /opt/db/log
Here we can see, for example, the /opt/db/data filesystem is nearly full, and is located on the /dev/sdd1 partition. The output of df shows the device path whether the disk is mounted using the device path or the (preferred) UUID in the fstab. Also take note of the Type column, indicating the format of the filesystem. The format is important later.
Now locate the LUN that correlates to /dev/sdd by examining the contents of /dev/disk/azure/scsi1. The output of the following ls command shows that the device known as /dev/sdd within the Linux OS is located at LUN1 when looking in the Azure portal.
You can expand your managed disks without deallocating your VM. The host cache setting of your disk doesn't change whether or not you can expand a data disk without deallocating your VM.
This feature has the following limitations:
Only supported for data disks.
If a Standard HDD, Standard SSD, or Premium SSD disk is 4 TiB or less, deallocate your VM and detach the disk before expanding it beyond 4 TiB. If one of those disk types is already greater than 4 TiB, you can expand it without deallocating the VM and detaching the disk. This doesn't apply to Premium SSD v2 or Ultra Disks.
Or an Azure Resource Manager template with an API version that's 2021-04-01 or newer.
Not available on some classic VMs. Use this script to get a list of classic VM SKUs that support expanding without downtime.
Expand with Ultra Disk and Premium SSD v2
Expanding Ultra Disks and Premium SSD v2 disks have the following additional limitations:
You can't expand a disk while a background copy of data is also occurring on that disk, like when a disk is being hydrated from snapshots.
You can't expand a VM that's using NVMe controllers for Ultra Disks or Premium SSD v2 disks without downtime.
Regional availability
Resizing Ultra Disks and Premium SSD v2 disks is currently available in all Premium SSD v2 and Ultra supported regions except the following:
US West 2
West Europe
Expand Azure Managed Disk
Make sure that you have the latest Azure CLI installed and are signed in to an Azure account by using az login.
This article requires an existing VM in Azure with at least one data disk attached and prepared. If you don't already have a VM that you can use, see Create and prepare a VM with data disks.
In the following samples, replace example parameter names such as myResourceGroup and myVM with your own values.
Shrinking an existing disk isn’t supported and may result in data loss.
After expanding the disks, you need to expand the volume in the operating system to take advantage of the larger disk.
Operations on virtual hard disks can't be performed with the VM running. Deallocate your VM with az vm deallocate. The following example deallocates the VM named myVM in the resource group named myResourceGroup:
az vm deallocate --resource-group myResourceGroup --name myVM
Note
The VM must be deallocated to expand the virtual hard disk. Stopping the VM with az vm stop doesn't release the compute resources. To release compute resources, use az vm deallocate.
View a list of managed disks in a resource group with az disk list. The following example displays a list of managed disks in the resource group named myResourceGroup:
az disk list \
--resource-group myResourceGroup \
--query '[*].{Name:name,size:diskSizeGB,Tier:sku.tier}' \
--output table
Expand the required disk with az disk update. The following example expands the managed disk named myDataDisk to 200 GB:
az disk update \
--resource-group myResourceGroup \
--name myDataDisk \
--size-gb 200
Note
When you expand a managed disk, the updated size is rounded up to the nearest managed disk size. For a table of the available managed disk sizes and tiers, see Understand Azure Disk Storage billing.
Start your VM with az vm start. The following example starts the VM named myVM in the resource group named myResourceGroup:
az vm start --resource-group myResourceGroup --name myVM
Expand a disk partition and filesystem
Note
While there are many tools that may be used for performing the partition resizing, the tools detailed in the remainder of this document are the same tools used by certain automated processes such as cloud-init. As described here, the growpart tool with the gdisk package provides universal compatibility with GUID Partition Table (GPT) disks, as older versions of some tools such as fdisk did not support GPT.
Detecting a changed disk size
If a data disk was expanded without downtime using the procedure mentioned previously, the reported disk size doesn't change until the device is rescanned, which normally only happens during the boot process. This rescan can be called on-demand with the following procedure. In this example, we find using the methods in this document that the data disk is currently /dev/sda and was resized from 256 GiB to 512 GiB.
Identify the currently recognized size on the first line of output from fdisk -l /dev/sda
sudo fdisk -l /dev/sda
Disk /dev/sda: 256 GiB, 274877906944 bytes, 536870912 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x43d10aad
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 536870878 536868831 256G 83 Linux
Insert a 1 character into the rescan file for this device. Note the reference to sda in the example. The disk identifier would change if a different disk device was resized.
echo 1 | sudo tee /sys/class/block/sda/device/rescan
Verify that the new disk size is now recognized
sudo fdisk -l /dev/sda
Disk /dev/sda: 512 GiB, 549755813888 bytes, 1073741824 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x43d10aad
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 536870878 536868831 256G 83 Linux
The remainder of this article uses the OS disk for the examples of the procedure for increasing the size of a volume at the OS level. If the expanded disk is a data disk, use the previous guidance for identifying the data disk device, and follow these instructions as a guideline, substituting the data disk device (for example /dev/sda), partition numbers, volume names, mount points, and filesystem formats, as necessary.
All Linux OS guidance should be viewed as generic and may apply on any distribution, but generally matches the conventions of the named marketplace publisher. Reference the Red Hat documents for the package requirements on any distribution based on Red Hat or claiming Red Hat compatibility.
Increase the size of the OS disk
The following instructions apply to endorsed Linux distributions.
Note
Before you proceed, make a full backup copy of your VM, or at a minimum take a snapshot of your OS disk.
On Ubuntu 16.x and newer, the root partition of the OS disk and filesystems are automatically expanded to utilize all free contiguous space on the root disk by cloud-init, provided there's a small bit of free space for the resize operation. In this case, the sequence is simply
Increase the size of the OS disk as detailed previously
Restart the VM, and then access the VM using the root user account.
Verify that the OS disk now displays an increased file system size.
As shown in the following example, the OS disk was resized from the portal to 100 GB. The /dev/sda1 file system mounted on / now displays 97 GB.
To increase the OS disk size in SUSE 12 SP4, SUSE SLES 12 for SAP, SUSE SLES 15, and SUSE SLES 15 for SAP:
Follow the procedure previously described to expand the disk in the Azure infrastructure.
Access your VM as the root user by using the sudo command after logging in as another user:
sudo -i
Use the following command to install the growpart package, which is used to resize the partition, if it isn't already present:
zypper install growpart
Use the lsblk command to find the partition mounted on the root of the file system (/). In this case, we see that partition 4 of device sda is mounted on /:
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 48G 0 disk
├─sda1 8:1 0 2M 0 part
├─sda2 8:2 0 512M 0 part /boot/efi
├─sda3 8:3 0 1G 0 part /boot
└─sda4 8:4 0 28.5G 0 part /
sdb 8:16 0 4G 0 disk
└─sdb1 8:17 0 4G 0 part /mnt/resource
Resize the required partition by using the growpart command and the partition number determined in the preceding step:
In the preceding example, we can see that the file system size for the OS disk was increased.
Follow the procedure previously described to expand the disk in the Azure infrastructure.
Access your VM as the root user by using the sudo command after logging in as another user:
sudo -i
Use the lsblk command to determine which logical volume (LV) is mounted on the root of the file system (/). In this case, we see that rootvg-rootlv is mounted on /. If a different filesystem is in need of resizing, substitute the LV and mount point throughout this section.
Check whether there's free space in the LVM volume group (VG) containing the root partition. If there's free space, skip to step 12.
vgdisplay rootvg
--- Volume group ---
VG Name rootvg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 7
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 6
Open LV 6
Max PV 0
Cur PV 1
Act PV 1
VG Size <63.02 GiB
PE Size 4.00 MiB
Total PE 16132
Alloc PE / Size 6400 / 25.00 GiB
Free PE / Size 9732 / <38.02 GiB
VG UUID lPUfnV-3aYT-zDJJ-JaPX-L2d7-n8sL-A9AgJb
In this example, the line Free PE / Size shows that there's 38.02 GB free in the volume group, as the disk has already been resized.
Install the cloud-utils-growpart package to provide the growpart command, which is required to increase the size of the OS disk and the gdisk handler for GPT disk layouts This package is preinstalled on most marketplace images
dnf install cloud-utils-growpart gdisk
In Red Hat versions 7 and below you can use yum command instead of dnf.
Determine which disk and partition holds the LVM physical volume (PV) or volumes in the volume group named rootvg by using the pvscan command. Note the size and free space listed between the brackets ([ and ]).
Expand the partition containing this PV using growpart, the device name, and partition number. Doing so expands the specified partition to use all the free contiguous space on the device.
Expand the LV by the required amount, which doesn't need to be all the free space in the volume group. In the following example, /dev/mapper/rootvg-rootlv is resized from 2 GB to 12 GB (an increase of 10 GB) through the following command. This command also resizes the file system on the LV.
The lvresize command automatically calls the appropriate resize command for the filesystem in the LV. Verify whether /dev/mapper/rootvg-rootlv, which is mounted on /, has an increased file system size by using the df -Th command:
Example output:
df -Th /
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv xfs 12G 71M 12G 1% /
Note
To use the same procedure to resize any other logical volume, change the lv name in step 12.
Follow the procedure previously described to expand the disk in the Azure infrastructure.
Access your VM as the root user by using the sudo command after logging in as another user:
sudo -i
When the VM restarts completely, perform the following steps:
Install the cloud-utils-growpart package to provide the growpart command, which is required to increase the size of the OS disk and the gdisk handler for GPT disk layouts. This package is preinstalled on most marketplace images
dnf install cloud-utils-growpart gdisk
In Red Hat versions 7 and below you can use yum command instead of dnf.
Use the lsblk -f command to verify the partition and filesystem type holding the root (/) partition
For verification, start by listing the partition table of the sda disk with gdisk. In this example, we see a 48.0 GiB disk with partition #2 sized 29.0 GiB. The disk was expanded from 30 GB to 48 GB in the Azure portal.
gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 100663296 sectors, 48.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 78CDF84D-9C8E-4B9F-8978-8C496A1BEC83
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 62914526
Partitions will be aligned on 2048-sector boundaries
Total free space is 6076 sectors (3.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 1026048 2050047 500.0 MiB 0700
2 2050048 62912511 29.0 GiB 0700
14 2048 10239 4.0 MiB EF02
15 10240 1024000 495.0 MiB EF00 EFI System Partition
Expand the partition for root, in this case sda2 by using the growpart command. Using this command expands the partition to use all of the contiguous space on the disk.
Now print the new partition table with gdisk again. Notice that partition 2 has is now sized 47.0 GiB
gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 100663296 sectors, 48.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 78CDF84D-9C8E-4B9F-8978-8C496A1BEC83
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 100663262
Partitions will be aligned on 2048-sector boundaries
Total free space is 4062 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 1026048 2050047 500.0 MiB 0700
2 2050048 100663261 47.0 GiB 0700
14 2048 10239 4.0 MiB EF02
15 10240 1024000 495.0 MiB EF00 EFI System Partition
Expand the filesystem on the partition with xfs_growfs, which is appropriate for a standard marketplace-generated RedHat system: