VMware View has always automatically calculated Video RAM based on resolution and color depth. Up to VMware View 4.6 only 24-bit color depth was supported and VMware published few times the vRAM overhead that each resolution type would require. vRAM overhead is part of the VM memory overhead in virtual machines running on ESX/ESXi. The other part of the overhead comes from the number of vCPUs and amount of RAM.
In my article vSphere 5.0 New .vswp file & Storage Tax on VDI I talk about the changes to .vswp files. However, because I was under VMware View 5.0 NDA I could not expose more information.
VMware View 5.0 introduces 32-bit color depth and makes it the default option. On top of that, to allow 3D support, VMware introduced a new feature in View 5.0 that allow administrators to select how much video RAM should be assigned to virtual desktops.
VMware’s explanation of configuring VRAM for 3D support is not very helpful. Basically it says, the more VRAM, more 3D performance. I personally find the implementation cumbersome because no one knows how much vRAM is required for a particular performance.
I wanted to understand how vRAM works and how it is implemented. I wanted it to be part of my online VDI calculator http://myvirtualcloud.net/?page_id=1076. So, I reverse engineered the vRAM implementation.
The first thing to point out in VMware View 5.0 is that you will either calculate vRAM using display resolution with 32-bit color depth (there is no support for 24-bit), or you will assign a specific amount of vRAM (starting from 64MB, up to 128MB) to virtual desktops in a given desktop pool.
When calculating 24-bit display resolutions the following table should be used as guideline for the display memory overhead:
On the table above column 1 represents a single display; column 2 represents two displays and uses 4.0 as the multiplier. Displays 3 and 4 have multipliers 9 and 16.
As I mentioned, VMware View 5.0 uses 32-bit color depth. I figured out that for 32-bit resolution the multiplier used by VMware is 1.34 on average. Therefore, any number from the table above is represented below using the same multiplier. I have tested multiple scenarios and they all seem to validate the multiplier.
On 800×600 using 1 display the video overhead is 1.84MB. This number is 1.34 times biggers if compared to the 24-bit table above.
[RECAP] The tables above help to determine the amount of video memory used in a specific display condition. This condition is dictated by the resolution, color depth and number of displays. On top of that is it is necessary to calculate the amount of vCPU and RAM for each virtual machine.
3D support has a different calculation mechanism. Because there is no base table to find multipliers I tested and simulated a number of different configurations to come up with a base table that would demonstrate VM memory overhead in different situations. When the administrator enables 3D support and specify the amount of video RAM, then calculation is not anymore based on resolution, number of display and color depth.
The table below demonstrates the VM memory overhead and the .vswp file size for different configurations. Please refer to vSphere 5.0 New .vswp file & Storage Tax on VDI for understanding about the secondary .vswp file created by vSphere 5.0.
Note that now I am talking in terms of VM Memory Overhead and not Video Memory overhead. This is because I can only see the total amount of memory used by a VM. This should not be an issue when calculating the total overhead in use by all VMs in a View deployment. I have added this option in my online VDI calculator http://myvirtualcloud.net/?page_id=1076.
[IMPORTANT] When 3D is enabled a 256MB overhead is added to the secondary .vswp file. Therefore, if you are planning to use 3D you should size datastores appropriately to accommodate the difference. This additional 256MB help virtual machines not to run into performance issues when executing 3D display operations. The 256MB overhead is independent of how much vRAM you assigned in VMware View 5.0.
A datastore with 100 desktops will require additional 25GB for 3D support.
The table below demonstrates the .vswp file (swap) resulting from 3D support enabled.
Few VERY IMPORTANT things when using 3D support:
- The number of displays in use does not change the amount of VM Memory overhead.
- When enabled, 3D will automatically add 256MB to the .vswp file.
- The multipliers for number of displays are 1, 4, 9 and 16.
- From 24-bit to 32-bit the multiplier is 1.34
- For each additional GB of RAM added, 19.1MB is the overhead with 1vCPU
- For each additional GB of RAM added, 15.1MB is the overhead with 2vCPU
At this point I will start to get deep into the numbers. I also have identified the VM memory overhead for VMs with 1, 2 and 4 GB. Looking at the 1st table you are be able to identify the amount of Video RAM to be assigned when 3D support is enabled. The overhead in MB to be considered is on the rightmost column.
The tables below demonstrate how the amount of VM Memory Overhead will change according to the number of CPU, RAM and 3D vRAM. The first table is what I consider to the Base Table and is using 8MB vRAM. The 2nd table is an example with 128MB vRAM.
Now, all this can be very complex and if you have any questions please ask. However, I wanted to make it easier and I am adding all this calculation into my online VDI calculator http://myvirtualcloud.net/?page_id=1076. If you still want to do the calculations yourself use the TABLE.03 as base. Just make sure to include 256MB overhead to the .vswp file.