VDI + Windows PageFile Done Right!

Windows pagefile configuration for VDI environments has been a long standing discussion ground. I first wrote about it in 2010 (Pagefiles and VDI. Not so simple). However, because of few recent discussions I decided to review the subject and run some validation tests against well-known best practices. “The problem with best practices is that they around stay for longer than the technology they were based on.”

This validation is rather simple; one Windows 7 virtual desktop configured with pagefile, and one Windows 7 virtual desktop configured without pagefile. Besides pagefile, the virtual desktops are configured with exact same setting. In fact, both desktops originate from the same Parent VM. (Windows 7, 2GB RAM, 1GB Pagefile)

Additionally, for this test I have enabled Linked Clones. The reason for that is that with Linked Clones I am able to analyze individually the base image and the delta utilization.


Myth Number One – The Windows boot

The first myth is that during boot time a Windows virtual desktop with pagefile will produce more write IOs against virtual disks than a virtual desktop without the pagefile. The graphs below demonstrate that during boot storms read IOs are very similar. However during the boot without pagefile there was 27% less write IOs. On average number of write IOs is smaller in virtual desktops with pagefile.


Virtual Desktop with Pagefile during Boot



Virtual Desktop without Pagefile during Boot



Myth Number Two – The IDLE time

Many administrators think that the existence of pagefile automatically means that there will be more write activity, even when Windows is idle. The truth is that there is no such thing as idle time, since Windows is always running processes in the background and those processes are in most part write IO intensive. This is the reason why Windows operating systems can be as much as 80% writes during an average workload.

The graphs below demonstrate that virtual desktops during idle time with or without pagefile behave in a very similar fashion in regards to disk IO. For write IOs both virtual desktops had a maximum of 3 IOPs and an average of 0.23 IOPs.

For read IOs there was a little spike in the virtual desktop without pagefile, but that could have been a process that kicked off during the analysis period. It didn’t happen again.

What the graph below proves, is that when there is no memory pressure both virtual desktops will behave very similarly in regards to disk IO during the idle period.


Virtual Desktop Performance with pagefile during IDLE




Virtual Desktop Performance without pagefile during IDLE




Myth Number Three– The User Login

User login process generates different type of activity then boot and idle periods. Logins are as write intensive as read intensive, and that is clearly demonstrated on the average numbers when we compare read and write IOs.

For user login I ran tests multiple times. Below you will find one of the tests that represent the resultant set of all tests. The virtual desktop with pagefile enabled required less read IOs than the desktop without pagefile; on average 20% less read IOs.

On the other hand, the virtual desktop without pagefile required approximately 4% less write IOs during user login process.

The results look very similar, but the read IO difference at peak time could represent almost 16,000 IOPs in an environment with 1,000 virtual desktops. From an infrastructure perspective that could represent the requirement to add more spindles of even an additional storage array.

Most storage arrays nowadays have some type of cache to serve read IOs; some have features to serve write IOs from cache. However, write IOs cost more than read IOs due to the RAID striping mechanism that needs to occur for every write IO. The 3 IO difference at peak time would represent 3,000 IO for 1,000 virtual desktops. After RAID penalty is applied we would have 12,000 write IOs when using RAID5; or 18,000 write IOs if using RAID6.


Virtual Desktop with Pagefile during Login



Virtual Desktop without Pagefile during Login


If my workload was purely made up of Logins, than I probably would choose not to have pagefile, just to alleviate write IO pressure on storage. Please, bear in mind that this is applicable to any type of shared storage, SSD or PCIe appliance or DAS implementation.


The Truth

There is a good article from Citrix’s Nicholas Rintalan (The Pagefile Done Right!) where he explains how pagefile should be used and created. Nicholas also makes mention to Mark Russinovich article (Pushing the Limits of Windows: Virtual Memory).

“To optimally size your paging file you should start all the applications you run at the same time, load typical data sets, and then note the commit charge peak (or look at this value after a period of time where you know maximum load was attained). Set the paging file minimum to be that value minus the amount of RAM in your system (if the value is negative, pick a minimum size to permit the kind of crash dump you are configured for). If you want to have some breathing room for potentially large commit demands, set the maximum to double that number.”

I utterly agree with both authors, however Russinovich is not talking about Windows operating system running in virtual environments; and Nicholas is completely ignoring the disk IO aspect. There is more to it ($$$$) when talking about VDI.

If pagefile is not good from a disk IO perspective, what would be the impact of completely disabling pagefile? The reality is that when available memory is full Windows will start throwing Low Memory errors, and eventually generating a BSOD. I have purposely created a video demonstrating that behavior.


There are two screens side-by-side in this video. I recommend watching full screen and HD.


Most VDI deployments run on top of hypervizors and most hypervisor have some type of memory overcommit feature. VMware vSphere TPS feature allow administrators to overcommit host memory, allowing virtual desktops to have more virtual memory assigned than the total physical host memory available.

Following this idea, one could assign 4GB RAM to virtual desktops when the maximum load required is only 3GB. This way a user is able to load all the required applications without incurring in Windows swap. In this case the VMTools ballooning doesn’t seem apply, since there is no swap file.

The caveat is when all users simultaneously start using more virtual memory than existing physical host memory. In this case vSphere will compress and then host swap to disk, degrading performance for all virtual desktops on the host.

In the ideal world the administrator have carefully measure memory utilization and know the applications that users commonly use. In this case the administrator should be able to size Windows RAM properly, without having to enable pagefile.

In my work life experience I have seen organizations successfully running virtual desktop without pagefile.

For VMware View Premier and vSphere Desktop Edition there is no additional licensing costs for assigning additional virtual memory to virtual desktops.

In saying all that, if you don’t feel that you know your VDI environment, applications, and users well enough, don’t disable pagefile.


This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net. Visit myvirtualcloud.net for more articles about Virtualization, VDI and End User Computing.


1 ping

Skip to comment form

  1. Another great article, Andre. I had been wondering about this myself, and typically opt to use a page file while also taking advantage of the savings with TPS.

    • Tim on 02/17/2012 at 7:53 am

    I love reading articles that think outside of the box. Thanks for continuing to put out quality work Andre.

    • Greg on 02/17/2012 at 1:22 pm

    Great article, Andre.

  2. @Chris Wahl
    Thank you for your support, and I’m glad you enjoyed the article.


    • Ben Wood on 02/22/2012 at 12:43 am

    Or you could try putting the Pagefile in a small Ramdisk and revisit your testing….

  3. @Ben Wood
    If you will use RAM to create a RAMdisk for Windows pagefile, perhaps it’s better to just assigned that amount of RAM to Windows itself and disable pagefile. The result will be the same with less complexity.

    In the past I have successfully used RAMdisk for VDI, but I don’t think I would use it nowadays.


    • Chilli on 10/02/2012 at 5:42 am

    simple test yet pefect to prove your point!
    Thank you very much.

    • Joe O'Bremski on 07/16/2015 at 5:29 am

    Old article but first I found that talked about the IO penalty of PageFiles in a VDI enviroment. I have over 1000 Win7 VMs running in about 7 Win2012 4 blade Clusters. Each cluster has 4 CSVs running on 5 disk RAID5 15k drives with 30-50 VMs on each CSV each. If each of those VMs had pagefiles writing to disk as well as normal operations IOs those disks would be going crazy. The fear is always the Out of Memory BSOD but with servers each having hundreds of GB of memory if a users complains of perfomance issues I bump thier 1-4GB dyamic memory up to 6GB, 8GB, whatever it takes for that “power user”. Average users barely break the 2GB mark so giving them 4GB top end which they never hit.

    PageFiles in my mind are left over from an era where memory was expensive. Those days are long gone.

    • SquareSlice on 11/24/2016 at 6:36 pm

    An old, but still a valuable article I return to. We were running, on Windows 7, 4Gb memory and a 2 Gb pagefile (VMware View). We then encountered a number of PCoIP session disconnects. Looking at the PCoIP Server logs, these issues coincided with low Windows memory conditions (under 200MB available). However, in vROps, the VM’s seem to have sufficient memory. I then noticed in the Windows Event Log that at the time of incident there were warnings of low Virtual Memory (pagefile). I road-tested the scenario and found with a larger pagefile Windows seemed to be using available memory more and sustaining itself better. Since the pagefile was raised to $gb our disconnect issues in this respect have seemingly gone.

Comments have been disabled.