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 memory swapping 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.


This topic addresses issues regarding memory allocation for remote access to View desktops. If users run View desktops in local mode, on their client systems, the amount of memory used is some proportion of that available on the client device.

You need enough memory to run the host operating system on the client computer, plus the memory required for the View desktop's operating system and for applications on the client computer and the View desktop. VMware recommends that you have 2GB or more for Windows XP and Windows Vista, and 3GB or more for Windows 7.

If you attempt to check out a desktop that is configured in vCenter Server to require more memory than the local client system can accommodate, you will not be able to check out the desktop unless you change a Windows registry setting. For instructions, see the VMware View Administration document.

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

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

VMware ESX/ESXi supports sophisticated memory resource management algorithms such as transparent memory 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 ESX/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 ESX/ESXi swap files. However, higher reservation settings affect your ability to overcommit memory on an ESX/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 ESX/ESXi host's file system to locate the ESX/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 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.

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, even if you use View Client with Local Mode.

ESX/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 ESX/ESXi swap file is 1GB. This file can be stored on the local datastore on the ESX/ESXi host or cluster.

ESX/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.

If you use PCoIP, the display protocol from VMware, the amount of extra RAM that the ESX/ESXi host requires depends in part on the number of monitors configured for end users and on the display resolution. PCoIP 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 functionality.

PCoIP Client Display Overhead

Display Resolution Standard

Width, in Pixels

Height, in Pixels

1-Monitor Overhead

2-Monitor Overhead

4-Monitor Overhead

















































When you consider these requirements, note that virtual machine configuration of allocated RAM does not change. That is, you do not need to allocate 1GB of RAM for applications and another 31MB for dual 1080p monitors. Instead, consider the overhead RAM when calculating the total physical RAM required for each ESX/ESXi host. Add the guest operating system RAM to the overhead RAM and multiply by the number of virtual machines.


To use the new 3D rendering feature, available with View 5.0, you must allocate between 64MB and 128MB of VRAM for each Windows 7 View desktop. This non-hardware accelerated graphics feature allows you to use 3D applications such as Windows Aero themes or Google Earth.

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 Windows XP desktops and 32-bit Windows Vista and Windows 7 desktops and 2GB for 64-bit Windows 7 desktops. 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.