vSphere 5.0 New .vswp file & Storage Tax on VDI

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.


23 pings

Skip to comment form

  1. Nice writeup Andre. For quite a while in vSphere 4 I have understood that the usually small memory overhead was consolidated with and an add to VMkernel swap. For instance, a 1×2 VM has 90MB of overhead. The VMkernel swap file would be 2GB + 90MB. This was my foundation for why the virtual memory limit of a VM was 255GB because the additional overhead would exceed the maximum file size of 256GB on a VMFS datastore with a 1MB block size.

    After doing some testing in the lab, I’m finding that the VMkernel swap size does not increase when cranking up virtual CPUs and memory in vSphere 4.1. However, memory overhead does increase as displayed by the VM details in the vSphere Client. This would indicate memory overhead shares in the VMkernel swap which backs the vRAM assigned to the VM.

    My conclusion is that a 256GB VM in vSphere 4 could still create a VMkernel swap which slighly exceeds the size of the vRAM assigned, but not by the amount memory overhead would add. Thus in the end the vRAM limit in vSphere 4 is still 255GB.

  2. @Jason Boche
    I am not sure I understand your point. Are you implying that memory overhead in vSphere 4 would also increase VMkernel swap? On the same proportions?
    I personally don’t remember seeing this behaviour and would also nee to run some tests.
    …or you are implying that memory overhead is affected by TPS in vSphere 4?


    • TMS on 08/04/2011 at 2:38 am

    Useful info, thanks for the post.
    From initial viewing, it looks like when sizing a CAD deployment for View 5, one should ensure that an additional 4GB (max) per VDI is available on the datastore for the new video memory overhead (vswap), and this cannot be off loaded to physical RAM at this point – is this correct?

  3. Thanks for spotting and sharing this.

    I understand that this second swap file is for the memory _overhead_ itself. But what issue does this second swap file solve, since it comes at the expense of disk capacity (and IOPS as it has to be read and written)?

    Seems like “Swap to host cache” does not include this one?

    Thanks from Singapore

    • FredK on 09/20/2011 at 12:39 am


    i didn’t understand everything on the new vswp file… to be honest, it will require more time for me 🙂
    But there is something i can’t believe :
    How a single display can consume more than twice the RAM overhead of the dual display ??? (same vcpu and same resolution…)

  4. @FredK
    That’s when 3D support is enabled for the VM.

  5. @iwan ‘e1? rahabok
    The video swap was created for 3D support and aleviate host memory preassure.
    However, it’s used even when 3D support is disabled, using a smaller swap footprint.

  6. @TMS
    That seems correct… the video swap will be created when using ESXi 5.0 with Hardware v8.
    You may user my VDI calculator to size your VDI environment.

    • FredK on 10/13/2011 at 7:32 am

    @Andre Leibovici

    Ohh yes… i have to clean my glasses ! Sorry ! This sounds more logical to me now 😉

  1. […] in vSphere 5 (ESX Virtualization) vSphere 5.0 Datastore Clusters & VDI (My Virtual Cloud) vSphere 5.0 New .vswp file & Storage Tax on VDI (My Virtual Cloud) vSphere 5 What’s New – Profile Driven Storage (NTPro.nl) vSphere 5 […]

  2. […] high VM:phyicsal consolidation ratios.  I’m not saying not to optimize – many, such as reserving a portion of your View desktop’s RAM to save on vSwap space and improve responsiveness of idle but in-use desktops, will pay off.  But I […]

  3. […] vSphere 5.0 New .vswp file & Storage Tax on VDI […]

  4. […] attention to the vmx-*.vswp file. That’s new to ESXi 5.x, and it’s not related to the guest’s operating system memory pressure (it’s for VMX process heap, guest peripherals and management agents). In addition, the […]

  5. […] attention to the vmx-*.vswp file. That’s new to ESXi 5.x, and it’s not related to the guest’s operating system memory pressure (it’s for VMX process heap, guest peripherals and management agents). In addition, the […]

  6. […] vSphere 5.0 New .vswp file & Storage Tax on VDI » myvirtualcloud.net […]

  7. […] vSphere 5.0 New .vswp file & Storage Tax on VDI » myvirtualcloud.net […]

  8. […] to vSphere 5.0 such as 3D have been preserved and can be added to the calculations. Refer to vSphere 5.0 New .vswp file & Storage Tax on VDI for specific information on those […]

Leave a Reply