Month: August 2016

Horizon 7 VSAN Policy Update

When you first deploy a Horizon desktop pool onto Horizon it will create a number of policies that it will apply to the desktops.

In Horizon 6 the policy applied to Floating Clones (Linked or Full) had a Failure to Tolerate of 0.  The rationale is that Floating Clones are volatile and it doesn’t matter if they are lost, which is fairly reasonable. The impact though was if a host failed, it would loose all VMs running on that host AND all VMs with their storage on that host which could cause a significant outage.   Since the size of the delta disks is relatively small and not a constraining factor I usually recommended increasing the FTT to 1.

Now in Horizon 7 this has become the default policy! If you upgrade a Horizon 6 environment to Horizon 7 it will not update the existing policy, but you can change the FTT to 1 even if running Horzion 6 and it will never override that. But if you are deploying a greenfield Horizon 7 environment it will deploy linked clones with an FTT of 1.  But of course you can change this to 0 if you want to reduce storage consumption at the risk of losing desktops in host failures.

Below is an overview of the default policies in Horizon 7.

Object FTT Method FTT Stripes Space Reservation Flash Read Cache Reservation
Floating Linked/Instant Clone RAID 1 1 1 0% 0%
Dedicated Linked Clone RAID 1 1 1 0% 0%
Floating Full Clone RAID 1 1 1 100% 0%
Dedicated Full Clone RAID 1 1 1 100% 0%
Replicas/ Instant Clone Parents RAID 1 1 1 0% 10%
Persistent Disk RAID 1 1 1 100% 0%

Using VSAN Sparse Swap Disks with Horizon

For those of us working with Horizon for a while we have long known that the VSWAP file has a significant impact on storage.  Just to clarify, when a VM is Powered On, vSphere will create a VSWAP file equal to the allocated memory minus the memory reservation.  For a 4GB VM this is 4GB, or with a 1GB reservation it would be 3GB.  This VSWAP file is also created for Instant Clone parents, unless reservations are used.  The space required for these files adds up quickly we are talking about  thousands of desktops.

Reservations are a perfectly valid way of reducing the size of these files, but the draw back comes in Horizon when you have a lot of Powered On VMs but perhaps lower user concurrency. For example if you have 100 dedicated VMs you may want them all Powered On for the users, but at any given time there may be only 50 people using them. If you reserve 100% of your memory to eliminate the VSWAP file then you cannot over-commit memory even if the machines are mostly idling, using very little active memory.

So enter the Sparse Swap Disk VSAN 6.2.  Up until now the VSWAP file on VSAN was provisioned with 100% space reservation, mimicking the behaviour of a thick-disk on SAN storage. This is to guarantee the VSWAP space is available if needed. But VSWAP files are only used as a last resort. vSphere will use Transparent Page Sharing (if enabled) and ballooning before using the VSWAP file.  Enabling Sparse Swap disks removes the space reservation form the VSWAP, so they are still there and can be used but have no space reserved for them, almost eliminating the space utilized by these files.

vswap disabled

How do I enable them?

Sparse Swap Disks are enabled on a Per-Host level through the command line and only available on vSphere 6.0U2 hosts.  The command is:

esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled

vswap sparse nabled

When to use Sparse Swap Disks or Reservations?

If your hosts are not over-committed in memory which method should you use?  One issue with memory reservations is they affect HA Slot sizing and need to be managed on a per-VM basis.  In a typical VDI environment where all the VMs are identical and provisioned off the same parent image which has the memory reservation set then there is little benefit to using Sparse Swap Disks. You can fully reserve the memory for the VMs (because your not over-committed) and eliminate the VSWAP file that way. But if you’ve already provisioned a number of full clone desktops without a reservation and have found that you have not over-committed your memory, then perhaps you may use Sparse Swap Disks.

What about if you are over-committing memory? What I see typically in VDI environments is memory is just slightly over-committed, for example 10-20% because Transparent Page Sharing will save memory, it’s rare to have 100% concurrency of users and many users will not use their entire allocated memory. In this instance full reservations are not possible but the intent is to never need to use VSWAP files, as this causes a significant performance impact to the VMs and the users.  Here Sparse Swap disks are more beneficial as in these sort of environment people typically only reserve 50% of the VM memory, still leaving a significant amount of storage used for VSWAP files that will never write data.

What if the VSWAP is needed but there is no free space?

This would be bad….don’t do this. If there is not enough free space to write memory pages to disk then the VM will initially freeze and then crash.  If you are over-committing then ensure you allow some free space in your VSAN datastore to use VSWAP if required and monitor it as your roll out your environment.


I think the Sparse Swap Disk is an excellent new feature. The 100% Space Reservation for the VSWAP was set as a failsafe, to ensure the space was always available. By removing this restriction it allows architects to design their environment based on their requirements, just make sure you monitor it properly so you don’t get any nasty surprises.

Further reading:

Some of the top VSAN bloggers have written some good articles on Sparse Swap disks.

Yellow Bricks: VSAN 6.2 : Sparse Swap, what is it good for?
Cormac Hogan: VSAN 6.2 Part 5 – New Sparse VM Swap Object

There is a great HOL where you can check out the setting as well as other 6.2 features:

HOL-SDC-1608 What’s New with Virtual SAN 6.2