Reconfiguring mutliple VM policy’s with VSAN

Although on of the main advantages of Virtual SAN is the granularity of which you can apply policy’s, there may be occasions where you want to maintain a standard across a cluster of similar workloads. In turn, you may also need to re-configure more than a single VM’s policy at any given time. This post will explain how to use the RVC to achieve both of these scenarios.

By listing the current VSAN profiles that have been configured in the GUI under storage policies we can choose to apply to our VM’s. These match the policy’s set in the GUI.



The below command is going to set the VSAN-FFT0 policy to the VM’s guest2 and guest3. Notice I have used the entire path to these objects in the command.

>spbm.vm_change_storage_profile –profile /localhost/VSAN-DC/storage/vmprofiles/VSAN-FTT0 /localhost/VSAN-DC/computers/VSAN/hosts/ghetto-vsan3.vmware.local/vms/guest3 /localhost/VSAN-DC/computers/VSAN/hosts/ghetto-vsan2.vmware.local/vms/guest2
ReconfigVM guest3: success
ReconfigVM guest2: success

If I check the VM (specifically the Hard Disk) in the UI I can see that the policy has been applied to guest3 for example. Notice the single component.



In addition, you could find the object UUID for the object you would like to change and reconfigure using something like:

vsan.object_reconfigure ~path_to_cluster ~712b7c53-1ac9-7d71-af39-005056826b00 –policy (“hostFailuresToTolerate” i1)

while 712b7c53-1ac9-7d71-af39-005056826b00 is the UUID of the object you are configuring. Doing this across multiple VM’s would be a pain.

The available policy’s are:

(“hostFailuresToTolerate” i0) (“forceProvisioning” i0) (“stripeWidth” i1) (“proportionalCapacity” i1) (“cacheReservation” i0)


As I mentioned earlier there may be times where setting the default policy for the cluster is desirable. To check the default policy setting on the cluster (which I had previously set) you can use the esxcli.execute command.

policy 4

This output shows us the policy values for each class relative to a host. The cluster class is the thing we are interested in right now. To change the policy I use the vsan.cluster_set_default_policy and can use any of the values I choose.


I noted that although I changed the policy on the cluster this had no effect on the provisioned VM’s that already had a policy attached via the UI. I did however manage to show that any new VM’s that are provisioned inherit the policy I set at the cluster level. They will appear in the UI that they have no policy explicitly set. I generally recommend setting a policy in the UI for complete flexibility and visibility, even if it’s the default policy.

The other way in which this could be achieved is through the use of Host Profiles. With Host Profiles you have the ability to configure a default policy across the cluster or more correctly for each host that dynamically joins the cluster. See the below screenshot for the configuration settings available.