In a previous post I spoke in-depth about the different objects which go to make up a virtual machine which resides on a VSAN datastore. To recap, these are the VM Home Namespace, the VM Swap, the VMDK objects and the snapshot delta objects. Now, VMDKs comply with the full set of rules that are placed in a VM Storage Policy and applied to a virtual machine. Snapshot deltas inherit the same VM Storage Policies as their VMDK base disk and also comply with the full set of rules in the VM Storage Policy – so far so good. VM Home Namespace is a little different – its behaviour and which capabilities it complies with are discussed in this earlier article. This leaves the VM Swap object, and that is what I plan to cover in this article.
VM Swap, just like snapshot deltas, are not displayed in the Manage > VM Storage Policies of a virtual machine deployed on VSAN. It’s a bit of a drag, but only the VM Home Namespace and the VMDK (Hard Disk) objects are visible via the vSphere web client:
However, let’s refocus on the policy for VM Swap. Just like we discussed in the VM Home Namespace article, there is no point in giving valuable resources to an object like VM Swap. In fact, for VM swap, we do not implement any of the capabilities placed in the VM Storage Policy. Instead, we simply pick up the capabilities as defined in the default policy for VM Swap.
So what are the capabilities that the VM swap is deployed with:
- Number of Disk Objects to Stripe: value of 1
- Object Space Reservation: value of 100%
- Read Cache Reservation: value of 0%
- Number of Failures to Tolerate: value of 1
- Force Provisioning: value of 1 (enabled)
Some of these should be familiar to you now. For example, stripe width is 1, i.e. no striping. There is also no read cache allocated to the VM Swap object.
Why is Number of Failures to Tolerate (FTT) set to 1 and why doesn’t it follow the Number of Failures To Tolerate set in the policy? The reason is because the VM swap contents don’t need to persist. Even if a virtual machine fails because of a host failure, the swap object will be recreated when the virtual machine is powered up on a different host after a failure. So there is no need to maintain multiple copies.
Another question you might ask is why is object space reservation set to 100%? This means that VSAN will try to allocate the full amount of swap space required by the virtual machine at deployment time. It should be noted that this is not unique to VSAN. Even on traditional VMFS datastores, all VM Swap files are created thick. This is to ensure that when there are memory resource constraints, the VM can always be swapped to disk.
The other capability to consider is the Force Provisioning setting, which is enabled by default for VM Swap. This means that even if VSAN cannot meet the policy requirements for this object, it will still deploy it. Later, when more resources become available, the object will be reconfigured to meet all of its policy requirements. Lets take the following example of a cluster that contains 3 ESXi hosts and one of the ESXi hosts fail. If the compute of a virtual machine was running on that host which failed, then the virtual machine will need to be started (either manually by user intervention or automatically by vSphere HA). Either way, a new VM swap object for that virtual machine has to be created. That swap object creation would fail if Number of Failures To Tolerate = 1 (as per the default policy) was enforced. Therefore the use of Force Provisioning allows VSAN to handle this kind of scenario.
A final note about VM swap object failure, and what would happen if a virtual machine needed to swap, and the VM swap was missing or failed (due to multiple failures in the cluster). In this case, the VM would fail, and would once again have to be restarted, either manually by user intervention or automatically by vSphere HA. Again, a new swap object in instantiated in the exact same way as we discussed previously.