Azure VM’s and their Temporary Storage

Every virtual machine deployed in Azure automatically gets an operating system disk and a temporary (virtual hard) disk. As the temporary disk is labeled as the D:\ drive by default, it causes some confusion or problems when used for the wrong purpose. But what is the right purpose? Let me start by sharing some background information, why there is a need to have this temporary disk and how to make the best use of it.

The Temporary Storage

In Azure, every VM – regardless if Linux or Windows – gets a temporary disk assigned automatically. This temporary disk is located on the physical server (the hypervisor) where the Azure VM is hosted and is non-persistent. Disks used by the operating system or additionally added data disks are persistent disks and stored in Azure Storage.

Azure VM’s can be moved from its current host to new host at any time due to maintenance, hardware failures or other reasons. In such an event, the data from the temporary storage will not preserve or moved to the new host. Apart from the hardware failures, there are many other reasons data from the temporary disk will be lost:

• Resizing of the VM
• Restarting of the VM
• Moving from one host to another
• Updating/upgrading of host

Really, the temporary disk should never be used for data that has to be persistent. To avoid misconfiguration, the disk also has the drive label “Temporary Storage” and includes a text file “DATALOSS_WARNING_README.txt”. It couldn’t be more obvious…

For Windows Server, the temporary disk is mounted as D:\. Linux based VM’s have the temporary disk mounted as “/dev/sdb1”. Of course, the same principles apply, your risk losing data that can’t be recovered when storing data on this disk.

The size of the temporary disk varies, based on the size of the virtual machine (and it’s available physical memory). For more information, see Sizes for Windows virtual machines. Look for the column “Temp storage (SSD) GiB” to understand how big the temporary disk will be. Good to know, the temporary storage provided with each Azure VM has no extra cost associated.

Memory Extension and the pagefile.sys

As the temporary disk can’t be used to store any persistent data, why should you care? Let’s take it a step further and have a look at the page file. Windows Memory Management is based on virtual memory, where every process has its own private virtual address space. In case the operating system runs low on memory, it will move the least used memory pages from the physical memory to a page file (pagefile.sys). This ensures the processes still have access to resources. This process is called “paging”. The main purpose of the page file is the following:

• Extend the physical memory;
• Store information in case of a system crash.

In the old days, sysadmins liked to tweak the size and location of this pagefile.sys. However, those old rules of thumb (e.g., page file size equals physical memory * 1.5) makes no sense anymore when using the modern operating system. Since Windows Server 2012 the Microsoft recommendation is to leave the option system managed. This still is a valid recommend practice, unless recommended different for a specific application. You can find some further reads in the Microsoft KB 2860880.

Good to know, newly created VM’s already have the pagefile.sys configured to be located on this temporary disk.

pagefile.sys for Azure VM’s

Putting it into the context of Azure – the temporary disk (D:\) is used by default to store the pagefile.sys. As applications often are installed on D:\ drive, this might cause some problems and change corporate policies might not be the firsts (or most comfortable) choice. To remap the temporary disk to a different drive letter, follow the instructions in this article Change the drive letter of the Windows temporary disk.

As most of the deployments these days are performed using ARM templates, it would be a good opportunity to extend the script to move the temporary disk already during the deployment. There is a project on GitHub (MoveAzureTempDrive) which is a great starting point. You only have to modify the azuredeploy.parameters.json file with the vmName and desired tempDriveLetter to be used.

There’s just one more thing…

The temporary storage drive is non-persisted storage, and you shouldn’t store any data on this drive. However, we always have this one exception…. SQL Server. When working with SQL Server, you can get significant improvements of I/O throughputs when storing the TempDB on the temporary disk – only the TempDB, no user database or transaction log files.

For SQL Server using D-series, Dv2-series, and G-series VM’s, the temporary disk is SSD-based. If the workload makes heavy use of TempDB, storing this file on the D:\ drive could result in higher throughput and lower latency. For VMs that support Premium Storage (DS-series, DSv2-series, and GS-series), it is recommended storing TempDB on a disk that supports Premium Storage with read caching enabled.