Well, VSAN is finally GA today. Check out Duncan’s blog post which has lots of good links about where to get the GA bits.
In this post, I am going to address a question about the VM Home Namespace object on VSAN which has come up a number of times recently and has caused a little bit of confusion. If you’ve been following my series of Virtual SAN articles, you may recall that virtual machines deployed on a VSAN datastore are now made up as a set of objects (as opposed to the set of files that we’ve been used to traditionally). These objects may be virtual machine disk (VMDKs), snapshot deltas, VM swap space and of course the VM Home Namespace. The VM Home Namespace is where we store all the virtual machine configuration files, such as the .vmx, .log, digest files, memory snapshots, etc. Now what a number of folks have noticed is that even though they set a VM Storage Policy with various VSAN capabilities, the VM Home Namespace object does not seem to implement the policy settings when viewed via the vSphere web client. This post will aim to explain why.
The reason for this is that only the virtual machine disks and the snapshot deltas adhere to the full set of VM Storage Policy settings, which actually makes perfect sense. Both the VM Home Namespace and the VM Swap have certain default capability settings which they use in place of what is in the VM Storage Policy. If you think about it, why would you want to give something like the VM Home Namespace a % of cache or a stripe width? You wouldn’t, which is why the VM Home Namespace does not have these settings applied even when they are in the policy. The VM Home Namespace does however inherit the NumberOfFailuresToTolerate setting. This allows the virtual machine to survive multiple hardware failures in the cluster. For example, in the screenshot below, I deployed a VM with a NumberOfFailuresToTolerate set to 2 and StripeWidth set to 2.
If you want to learn more about VSAN objects and capabilities, consider reading some previous blogs posts of mine on the subject.
Just to close, let’s recap on which capabilities a VM Home Namespace is deployed with:
- Number of Disk Objects to Stripe: policy overwritten with value of 1
- Object Space Reservation: policy overwritten with value of 0%
- Read Cache Reservation: policy overwritten with value of 0%
- Number of Failures to Tolerate: policy setting used
- Force Provisioning: policy setting used
There are a few reasons why we did not allow a Flash Read Cache Reservation for the VM Home Namespace. The primary reason was that it doesn’t do much for performance to add cache to the VM Home Namespace, but another reason is that when folks were adding cache to their VMDKs, they were also mistakenly adding it to their VM Home Namespace, where it wasn’t needed. This was an unnecessary waste of a customer’s cache resources. For that reason, we gave the VM Home Namespace a default policy which excluded cache.