Format and mount temporary disk to Azure Linux VMs

2025-10-11

Applies to: ✔️ Linux VMs ✔️ Flexible scale sets

This article covers how to format and mount temporary disks (also known as resource disks) on Azure Linux virtual machines (VMs). Depending on your VM series, temporary disks use either SCSI or NVMe interfaces. Temporary disks aren't managed disks, and aren't persistent.

Store important data on managed disks instead of local temporary disks. Temporary disks are generally meant to store items like page files, swap files, or SQL Server tempdb files.

Prerequisites

Before formatting temporary disks:

Identify the correct disk to avoid data loss
Understand that data isn't persistent across VM stops/deallocations
Have SSH access to your VM with root or sudo privileges

Format disks

Warning

Formatting will permanently erase all data on the disk. Ensure you're working with the correct disk and that no important data exists on it.

Use the latest version of parted available for your distribution. If the disk size is 2 tebibytes (TiB) or larger, you must use GPT partitioning. If the disk size is under 2 TiB, then you can use either MBR or GPT partitioning.

The following example uses parted on /dev/sdb, which is typically where the SCSI temporary disks appear. Replace sdb with the correct device for your disk. We're using the XFS file system for better performance.

sudo parted /dev/disk/azure/resource --script mklabel gpt mkpart xfspart xfs 0% 100%  
sudo partprobe /dev/sdb
sudo mkfs.xfs /dev/sdb1

The following examples assume you identified your disk as shown in the identifying disks section. If you have azure-vm-utils installed, use it to identify local disks.

# Example: Format local NVMe disk (replace nvme1n1 with your identified disk)
sudo parted /dev/disk/azure/local/by-index/0 --script mklabel gpt mkpart xfspart xfs 0% 100%
sudo partprobe /dev/nvme1n1
sudo mkfs.xfs /dev/nvme1n1p1

Some VM sizes provide multiple local NVMe disks. You can set up RAID for better performance or redundancy:

# Example: Create RAID 0 with two local NVMe disks for performance
sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme1n1 /dev/nvme2n1
sudo mkfs.xfs /dev/md0

Use the partprobe utility to make sure the kernel is aware of the new partition and file system. If you don't use partprobe, then blkid or lsblk commands might not return the UUID for the new file system immediately.

Mount temporary disks

Now, create a directory to mount the file system by using mkdir. For temporary storage, common mount points include /mnt, /tmp, or application-specific directories.

sudo mkdir /mnt/temp

Use mount to mount the file system. The following example mounts the /dev/sdb1 partition to the /mnt/temp mount point:

sudo mount /dev/sdb1 /mnt/temp

You can also use the Azure device path:

sudo mount /dev/disk/azure/resource-part1 /mnt/temp

The following examples assume you identified your disk as shown in the identifying disks section. If you have azure-vm-utils installed, use it to identify local disks.

# Using direct device path (replace nvme1n1p1 with your identified disk's partition)
sudo mount /dev/nvme1n1p1 /mnt/temp

# Or using Azure device path
sudo mount /dev/disk/azure/local/by-index/0-part1 /mnt/temp

For RAID arrays created as shown in the formatting section:

sudo mkdir /mnt/raid
sudo mount /dev/md0 /mnt/raid

TRIM/UNMAP support for temporary disks

Local temporary disks support TRIM/UNMAP operations. For optimal performance:

Use the `discard` mount option in `/etc/fstab`:

UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e   /mnt/temp   xfs   defaults,discard,nobootwait   0   0

Alternatively, run `fstrim` periodically:

sudo apt install util-linux
sudo fstrim /mnt/temp

sudo yum install util-linux
sudo fstrim /mnt/temp

sudo zypper in util-linux
sudo fstrim /mnt/temp

Troubleshooting

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 az 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 lsscsi:

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

Note

The Azure 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 lsscsi after 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.