I received an interesting question from one of my customers about the behaviour of vSAN with regards to policy changes to a policy which is applied to a content library and then especially the templates that reside within it.

The customer told me that when they changed the Default vSAN Policy that was attached to a content library, the OVF-templates inside that content library, were not updated to comply with the changes made to the policy.

So I tried that out in my lab environment.

As I understand it (and see when I work with it), the Content Library vSAN Storage Policy is based on the vSAN Default Policy for that vCenter Server. The only “problem” is, is that it doesn’t change when the default policy is changed.

So I am starting with the vSAN Default Storage Policy configured as follows:

Most important setting in here is the RAID-5 setting, because I will be changing that later on.

After this, I create a Content Library, with the following settings:

I then use an existing VM, to publish to the newly created content library. This template has been created to also use the vSAN Default Storage Policy, because that will help us demonstrate the change, when I set it to RAID-1, later on:

So I create an OVF template, that I publish to the newly created Content Library:

And select the just created Content Library:

After this has finished, I can see the vSAN object, with the expected placement, based on RAID-5:

At this point I have changed the “original” Template to a VM, in order to have changes to the vSAN Default Storage Policy applied to it.

When I then change the “vSAN Default Storage Policy” from RAID-5 to RAID-1, and select to change the current objects (see that only 1 object is registered):

I can see that that will change the placement for the template I converted to a VM:

But not for the template that is part of the content library:

This confirms what my customer told me (and it also made me see that this is not just the case for Templates in Content Libraries, but also for “regular” Templates).

This will lead to an issue when decommissioning a host in a VCF Workload domain, when that domain will then not be able to comply with the “old” setting for the Default Storage Policy.

That will give us the uuid, like this:

What we can now do, is use the objtool command to change the settings for the template objects.

First we need to find the uuid for the object. One way of doing this, is by using the command:

esxcli vsan debug object list

Another would be to look it up in the GUI:

Then we can change the policy for these specific uuids, to RAID-1.

To do this, we start with querying the current policy settings, because when changing the settings, it will override all the settings, not just the one you are entering. So we need to configure all the existing (and remaining) settings as well. We can query the policy settings, like so:

/usr/lib/vmware/osfs/bin/objtool getAttr -u 49d31766-ecd7-f5d7-5313-0050560150d2|grep Policy

We then select the response and change the setting we want to change for this object:

/usr/lib/vmware/osfs/bin/objtool setPolicy -u 49d31766-ecd7-f5d7-5313-0050560150d2 -p "((\"stripeWidth\" i1) (\"cacheReservation\" i0) (\"proportionalCapacity\" i0) (\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i0) (\"spbmProfileId\" \"aa6d5a82-1c88-45da-85d3-3d74b91a5bad\") (\"spbmProfileGenerationNumber\" l+6) (\"storageType\" \"Allflash\") (\"replicaPreference\" \"Performance\") (\"iopsLimit\" i0) (\"checksumDisabled\" i0) (\"spbmProfileName\" \"vSAN Default Storage Policy\"))"

As you can see, I changed the setting “ReplicaPreference” from “Capacity” to “Performance” (and make sure you use exact case, since it is a “free text field”, which will accept any value, but won’t react on false entries)

And the same process (both getting and setting) for the other object:

Leading to:

So, RAID-1.

Special thanks to my colleagues Duncan Epping and Paul Twomey for pointing me in the right direction.