I had this question recently regarding the best way to format volumes in a Windows 2008 Guest OS, and if there were any considerations with the different formatting types on a volume which resides on a thin provisioned VMDK. Just to be certain that what I was stating was actually true, I set up a small test. Bottom line – use quick format when formatting the volume as a normal format will fill the volume, negating the space-saving associated with thin provisioned volumes.
In this post, we talk about a particular behaviour with using the default (or None) policy with VSAN. I have stated many times in the past that when a VM is deployed on the VSAN datastore, it behaves like it is thinly provisioned unless the capability ‘Object Space Reservation’ (OSR) is specified in the VM Storage Policy. The OSR will pre-allocate space on the VSAN datastore for the virtual machine’s storage objects, and is specified as a percentage of the actual VMDK size. However, there is a slightly different behaviour when the default policy is used. Once again, I was in a conversation with a customer who stated that when he used the default policy of “None”, he could see space being consumed on the VSAN datastore was equal to the size of the VMDK * FTT (Number of Failures To Tolerate). He wondered why this was the case when the default policy clearly did not contain an Object Space Reservation capability.
Those of you familiar with VSAN will know that one of the capabilities which can be placed in a VM Storage Policy is Number of Disk Stripes Per Object (stripe width for short). I covered this in an earlier post which looked at the various VSAN capabilities. Recently, a customer who had not specified a stripe width in the VM Storage Policy was perplexed to find that his storage objects had indeed been striped across a number of disks. He reached out to me if I could provide an explanation.
At this stage, VSAN has only been in GA for a number of weeks, even though many of us here at VMware have been working on it for a year or two (or even more). Sometimes when we get into explaining the details of storage objects, components, etc, we forget that this is all so new for so many people. In a recent post, someone asked me to explain the concept of a witness on VSAN. Looking back over my posts, I was surprised to realize that I hadn’t already explained it. That is the purpose of this post – explain what a witness disk is in VSAN, and what role it provides.
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.
[Updated] This is a very short post as I only learnt about this recently myself. I thought it was only available in vSphere 5.5 but it appears to be in vSphere 5.1 too. Anyhow Storage DRS now has a new setting that allows you to configure the default VM affinity setting. Historically, VMDKs from the same virtual machine were always kept together on the same datastore by default; you had to set a VMDK anti-affinity rule to keep them apart. Now you can set a default for this option, which can either be to keep VMDKs together on the same datastore or to keep VMDKs apart on different datastores.
In my recent post about the new large 64TB VMDKs available in vSphere 5.5, I mentioned that one could not hot-extend a VMDK (i.e. grow the VMDK while the VM is powered on) to the new larger size due to some Guest OS partition formats not being able to handle this change on-the-fly. The question was whether hot-extend was possible if the VMDK was already 2TB or more in size. I didn’t know the answer, so I decided to try a few tests on my environment. Continue reading