spbm

Which vSAN policy changes will trigger a rebuild?

Duncan Epping · Nov 10, 2020 · 2 Comments

A couple of years ago I did a VMworld session with Cormac and we discussed the top things everyone should know about vSAN. One of the items discussed was which policy changes would trigger a rebuild. We tested the various situations and documented them. Two weeks ago a question around this was asked on a VMware internal Slack channel so I shared our findings. Considering it is already a few years ago, I wanted to make sure that our documented findings were still valid, so I redid the tests.

Now before I provide a table with the findings, I just want to explain what I tested, what I did is I created a VM with a default policy. I dumped a bunch of random data on the two VMDKs attached to the VM, and I then changed the policy of the VM while the VM is running. After changing the policy I verified through the command-line, and UI, if a rebuild of the objects was occurring or not. In some cases a policy change does not require a rebuild, while in other cases it does. This, of course, depends on what is being changed within the policy, and what that means for the objects associated with the policy. Hopefully, you will find the below table useful.

From	To	Resync
RAID-1	RAID-1 with higher FTT	Yes
RAID-1	RAID-1 with lower FTT	No
RAID-1	RAID-5/6	Yes
RAID-5/6	RAID-1	Yes
RAID-5	RAID-6	Yes
RAID-6	RAID-5	Yes
Stripe width 1	Stripe width increase by 1 (or more)	Yes
Stripe width x	Stripe width decrease by 1 (or more)	Yes
Space Reservation 0	Increase to larger than 0	No
Space Reservation >= 1	Increase by 1 (or more)	No
Space reservation > 0	Decrease to 0	No
Read Cache 0	Increase to larger than 0	No
Read Cache >= 1	Increase by 1 (or more)	No
Read Cache >= 1	Decrease by 1 (or more)	No
Checksum enabled	Checksum disabled	No
Checksum disabled	Checksum enabled	Yes

SPBM integration with vRealize Automation

Duncan Epping · Sep 8, 2016 ·

Last week a new vRealize Automation plugin was released. The plugin enables the use of storage policies within vRealize Automation, or as the Solutions Exchange page says:

Integrating storage policy consumption model into vRealize Automation. This integration enables VM-granular control based on the Storage policy based management framework. This solution exposes vSphere VM Storage policies to vRealize Automation service catalog allows the ability to dynamically assign individual VM storage polcies to virtual disks based on their storage requirements characteristics (performance, availability, security, etc).

Pretty neat solution which was shown also during the VMworld keynote. More extensive demos around the capabilities can be viewed below, and more details around the plugin and how to install / use it can be found here.

Be careful when defining a VM storage policy for VSAN

Duncan Epping · Sep 19, 2013 ·

I was defining a VM storage policy for VSAN and it resulted in something unexpected. You might have read that when no policy is defined within vCenter that VSAN defaults to the following for availability reasons:

Failures to tolerate = 1

So I figured I would define a new policy and include “stripe width” in this policy. I wanted to have a stripe width of 2 and “failures to tolerate” set to the default of 1. I figured as “failures to tolerate” is set to 1 anyway by default I would specify it, but would just specify stripe width. Why add rules which already have the correct value right?

Well that is what I figured, no point in adding it… and this was the result:

Do you notice something in the above screenshot? I do… I see no “RAID 1” mentioned and all components reside on the same host, esx014, in this case. So what does that mean? It means that when you create a profile and do not specify “failures to tolerate” that is default to 0 and no mirror copies are created. This is not the situation you want to find yourself in! So when you define stripe width, make sure you also define “failures to tolerate”. Even better, when you create a VM Storage Policy always include “failures to tolerate. Below is an example of what my policy should have looked like.

So remember this: When defining a new VSAN VM Storage Policy always include “Number of failures to tolerate”! If you did forget to specify it, the nice thing here is that you can change VM Storage Policies on the fly and apply them directly to your VMs. Cormac has a nice article on this subject!