• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

spbm

Which vSAN policy changes will trigger a rebuild?

Duncan Epping · Nov 10, 2020 ·

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.

 

FromToResync
RAID-1RAID-1 with higher FTTYes
RAID-1RAID-1 with lower FTTNo
RAID-1RAID-5/6Yes
RAID-5/6RAID-1Yes
RAID-5RAID-6Yes
RAID-6RAID-5Yes
Stripe width 1Stripe width increase by 1 (or more)Yes
Stripe width xStripe width decrease by 1 (or more)Yes
Space Reservation 0Increase to larger than 0No
Space Reservation >= 1Increase by 1 (or more)No
Space reservation > 0Decrease to 0No
Read Cache 0Increase to larger than 0No
Read Cache >= 1Increase by 1 (or more)No
Read Cache >= 1Decrease by 1 (or more)No
Checksum enabledChecksum disabledNo
Checksum disabledChecksum enabledYes

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?

VM storage policy for VSAN

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.

VM storage policy for VSAN

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!

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007), the author of the "vSAN Deep Dive", the “vSphere Clustering Technical Deep Dive” series, and the host of the "Unexplored Territory" podcast.

Upcoming Events

29-08-2022 – VMware Explore US
07-11-2022 – VMware Explore EMEA
17-11-2022 – VMUG UK
….

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2022 · Log in