Virtual Machine swap files have been around since the early ESX days and overtime we have learnt how to play with Memory Reservations to constrain their maximum size and reduce storage footprint. This type of operation may not be as effective with server virtualization as it is with desktop virtualization.
The size of a .vswp file is equal to the memory size allocated to the VM, minus any assigned memory reservation. As an example, assume a virtual desktop with Windows 7 with2GB RAM, and 1GB memory reservation. In this case the .vswp file is 1GB.
As an example, in a deployment with 2,000 virtual desktops with 2GB RAM and 50% memory reservation the administrator would be able to save 1TB of storage footprint (2,000 x (2GB x 0.5) = 1TB).
If you want to find more about use of memory reservation in VDI environments please read the following articles: VDI and Storage De-Duplication: Good or Bad marriage? and Save [VDI] Storage using VM Swap File Host Placement.
The new .VSWP file
ESxi 5.0 implements a second .vswp file for every virtual machine created either with hardware version 7 or 8. This second .vswp file is dedicated to memory overhead and will be used when the host is under resource constraint. When the virtual machine is created the memory overhead is defined, however the VM and the VMkernel will not use the whole reserved memory until required.
The total memory overhead is defined by the following factors:
- Number of virtual CPU
- Amount of RAM
- Amount of VRAM (defined by Number of Displays, Screen Resolution and Color Depth)
- 3D Support
Memory overhead is not something new and most VMware administrators were used to calculate overhead based on vCPU, RAM and VRAM. However, with the introduction of a Video memory Calculator, vSphere Client 5.0 provides an easy way to define the amount of VRAM required for a given video configuration.
By now you should be starting to realize how this new overhead .vswp file will affect storage footprint; more specifically for VDI environments. Despite VMware View.next is not available yet it’s not hard to imagine that View will make use of the new 3D feature in vSphere.
In order to understand the real impact I have run some configuration tests with vSphere 5 (see table below).
If we assume that the most common VDI VM configuration in production environment is probably a Windows 7, 1vCPU, 2GB RAM and 1024×768 screen resolutions with 32 color depth; then there would be an additional 320MB swap file per virtual desktop.
For 2,000 virtual desktops this is an additional 625GB of storage footprint.
For cases where 128MB vRAM for 3D rendering is allowed this number could be 720GB for 2,000 virtual desktops.
Those numbers are not frightening at all, however keep in mind that .vswap files will reside with virtual desktops and will require storage from datastores that have been carefully carved for a given number of VMs per datastore, plus a small overhead. If you followed VMware Reference Architecture you probably have 64 Linked Clone VMs per datastore. Some deployments have more than 64 VMs per datastore.
vSphere Client 5 allow administrators to fully reserve all guest memory with a single tick (picture below). However, memory reservation does not affect the .vswap file created for the VM memory overhead. At this point in time I am not even sure that VM memory overhead is collapsed by TPS (Transparent Page Sharing).
On the other side of the spectrum, because of the new .vswp existence there is additional storage IO that may affect storage performance when all virtual desktops in a host or cluster are under memory constraint. That would happen when Virtual Desktops require offloading VRAM to the disk.
I have no numbers on IO requirements but I don’t expect to be such a number that would have to be considered when sizing storage arrays for performance.
My tests demonstrated that 3D support adds a considerable VM overhead and, if possible should be avoided. Using the same VM configuration and just adding 3D support the VM overhead has grown in 235% and the .vswp file has grown in 639%.
My take on the topic is –
Sure, go ahead and enable 3D support, Windows Aero, multi-display support and the best possible resolution to your users. Let them enjoy everything VDI can provide these days; but with power comes responsibility. Make sure you consider host memory, network (PCoIP and HDX) and storage aspects when implementing Windows Aero and 3D support to your environment.
Note: I have not seen any information from VMware on the subject discussed. All observation are based on my own findings and tests.