One of my readers posted a comment on my VDI Calculator page mentioning that he would not see the VM storage consumption increasing when Suspend VM option was select at “Desktop State when Not in use”. Suresh Thoppay thanks for the comment!
According to Suresh, “ESX suspend file, which has a .vmss extension, is created if you set the desktop pool policy to suspend on logoff. The size of this file is equal to the size of guest RAM.”
His explanation is spot on! So I diligently reviewed my formulas and not satisfied with the results I performed some tests in my lab. It turns out that the original formula was working, however it was taking into consideration the difference between the total number of VMs and concurrent VMs.
I assumed that VMs back to PoweredOn estate would not utilise any additional storage with the .vmss files. Unfortunately I was wrong and according to my tests any VM that goes into Suspend mode, at any point in time, will refrain from deleting the .vmss file until the VM is PoweredOff.
A simple example would be a VMware View environment with 2000 desktops, each with 2GB RAM. The total additional storage consumption for Suspension Mode could be near 4TB if all virtual desktops go into suspension state at night after work hours.
(1) Suspend – VM in suspend state and .vmss file is created.
(2) PowerOn – VM is then powered on but .vmss file is not deleted.
(3) PowerOff – VM is then powered off and .vmss file is finally deleted.
If floating pools are in use, because the desktop refresh and re-compositions are more frequent this problem should be minimized; unless off course your desktop pool is configured with Suspend and Delete/Refresh policies. In this case every time the users logoff the VMs will be either deleted or reverted to the original snapshot, and then they will enter into suspension mode. I can’t think of something worst than that to eat your precious storage array disk space.
Now, If storage capacity is not an issue for your organisation you may also want to think about the number of IOPs and throughput required to create those .vmss files, and then the amount of IOPS to reload them when the VM goes out of suspension. I actually would like to run some tests and compare the IOPS and throughput required to return a VM from suspension against booting a VM from PoweredOff state. I’ll leave this one for another post.
Furthermore, some application such as Lotus Notes do not resume well after the VM went into suspend state. Make sure you test your applications against Suspension Mode.
I updated the formulas in my VDI calculator and the only factor I know for sure is that if a desktop pool is using the Suspend Power Policy, at some point in time there is a chance that all VMs go into Suspension. For this reason the method to calculate the storage utilisation would be using the total number of VMs to make sure there is enough storage provisioned.
For the example above the total additional storage to support Suspend Mode would be around 2 terabytes.
My personal preference is to not use the Suspend Power Policy. Whilst Suspension Mode may help with reduction of the CPU cycles and power consumption the IO and storage price is too high. Instead, have a preference to use PowerOff, or a combination of DPM and a well customised Master Image that will consume the least amount of memory, CPU and IOPs when not in use.