RAM costs more for servers than it does for PCs. Because the cost of RAM is a high percentage of overall server hardware costs and total storage capacity needed, determining the correct memory allocation is crucial to planning your desktop deployment.

If the RAM allocation is too low, storage I/O can be negatively affected because too much Windows paging occurs. If the RAM allocation is too high, storage capacity can be negatively affected because the paging file in the guest operating system and the swap and suspend files for each virtual machine grow too large.

When allocating RAM, avoid choosing an overly conservative setting. Take the following considerations into account:

Insufficient RAM allocations can cause excessive Windows paging, which can generate I/O that causes significant performance degradations and increases storage I/O load.

VMware ESXi supports sophisticated memory resource management algorithms such as transparent page sharing and memory ballooning, which can significantly reduce the physical RAM needed to support a given guest RAM allocation. For example, even though 2GB might be allocated to a virtual desktop, only a fraction of that number is consumed in physical RAM.

Because virtual desktop performance is sensitive to response times, on the ESXi host, set nonzero values for RAM reservation settings. Reserving some RAM guarantees that idle but in-use desktops are never completely swapped out to disk. It can also reduce storage space consumed by ESXi swap files. However, higher reservation settings affect your ability to overcommit memory on an ESXi host and might affect VMotion maintenance operations.

The amount of RAM that you allocate to a virtual machine is directly related to the size of the certain files that the virtual machine uses. To access the files in the following list, use the Windows guest operating system to locate the Windows page and hibernate files, and use the ESXi host's file system to locate the ESXi swap and suspend files.

Windows page file

By default, this file is sized at 150 percent of guest RAM. This file, which is by default located at C:\pagefile.sys, causes thin-provisioned storage to grow because it is accessed frequently. On View Composer linked-clone virtual machines, the page file and temporary files can be redirected to a separate virtual disk that is deleted when the virtual machines are powered off. Disposable page-file redirection saves storage, slowing the growth of linked clones and also can improve performance. Although you can adjust the size from within Windows, doing so might have a negative effect on application performance.

For instant clones, any guest operating systems paging and temp files are automatically deleted during the logoff operation and so do not have time to grow very large. Each time a user logs out of an instant clone desktop, View deletes the clone, and provisions and powers on another instant clone based on the latest OS image available for the pool.

Windows hibernate file for laptops

This file can equal 100 percent of guest RAM. You can safely delete this file because it is not needed in View deployments.

ESXi swap file

This file, which has a .vswp extension, is created if you reserve less than 100 percent of a virtual machine's RAM. The size of the swap file is equal to the unreserved portion of guest RAM. For example, if 50 percent of guest RAM is reserved and guest RAM is 2GB, the ESXi swap file is 1GB. This file can be stored on the local data store on the ESXi host or cluster.

ESXi suspend file

This file, which has a .vmss extension, is created if you set the desktop pool logoff policy so that the virtual desktop is suspended when the end user logs off. The size of this file is equal to the size of guest RAM.

In addition to system memory, a virtual machine also requires a small amount of RAM on the ESXi host for video overhead. This VRAM size requirement depends in on the display resolution and number of monitors configured for end users. PCoIP or Blast Extreme Client Display Overhead lists the amount of overhead RAM required for various configurations. The amounts of memory listed in the columns are in addition to the amount of memory required for other PCoIP or Blast Extreme functionality.

PCoIP or Blast Extreme Client Display Overhead

Display Resolution Standard

Width, in Pixels

Height, in Pixels

1-Monitor Overhead

2-Monitor Overhead

3-Monitor Overhead

4-Monitor Overhead





























UHD (4K)






Not supported

For calculating system requirements, the VRAM values are in addition to the base system RAM for the virtual machine. Overhead memory is automatically calculated and configured when you specify the maximum number of monitors and select the display resolution in View Administrator.

If you use the 3D rendering feature and select Soft3D or vSGA, you can recalculate using the additional VRAM values in a View Administrator control for configuring VRAM for 3D guests. Alternatively, and for other types of graphics acceleration besides Soft3D and vSGA, you can specify the exact amount of VRAM if you elect to manage VRAM by using vSphere Client.

By default, the multiple-monitor configuration matches the host topology. There is extra overhead precalcuated for more than 2 monitors to accommodate additional topology schemes. If you encounter a black screen when starting a remote desktop session, verify that the values for the number of monitors and the display resolution, which are set in View Administrator, match the host system, or manually adjust the amount of memory by using selecting Manage using vSphere Client in View Administrator and then set the total video memory value to maximum of 128MB.

Because the amount of RAM required can vary widely, depending on the type of worker, many companies conduct a pilot phase to determine the correct setting for various pools of workers in their enterprise.

A good starting point is to allocate 1GB for 32-bit Windows 7 or later desktops and 2GB for 64-bit Windows 7 or later desktops. If you want to use one of the hardware accelerated graphics features for 3D workloads, VMware recommends 2 virtual CPUs and 4GB of RAM. During a pilot, monitor the performance and disk space used with various types of workers and make adjustments until you find the optimal setting for each pool of workers.