Change policy on a vSAN object via RVC

I had someone reach out to me recently, asking for a way to change the policy on a file that was uploaded to a vSAN datastore, e.g. an ISO image. When a file is uploaded to the vSAN datastore, a VM Home namespace object is created. It is into this ‘file system’ type object that the files/ISOs are stored. Initially, I looked at ways to change the VM Home namespace. I looked at various commands to change the policy and I did find some in RVC, the Ruby vSphere Console. Unfortunately all the spbm.namespace_change commands look for a VM as an argument, and there is no actual VM in this case, just an object. So I looked at the vsan.object_reconfigure. On my first attempt, it appears to do something, but nothing changes on the actual policy of the namespace.

Test #1

/vcsa-06/CH-Datacenter/computers> vsan.object_reconfigure 0 e439c35a-81aa-9294-7a35-246e962f4850 –policy=RAID-5
Reconfiguring ‘e439c35a-81aa-9294-7a35-246e962f4850’ to RAID-5

All reconfigs initiated. Synching operation may be happening in the background

 

/vcsa-06/CH-Datacenter/computers> vsan.object_info 0 e439c35a-81aa-9294-7a35-246e962f4850
DOM Object: e439c35a-81aa-9294-7a35-246e962f4850 (v6, owner: esxi-dell-f.rainpole.com, proxy owner: None, policy: SCSN = 137, hostFailuresToTolerate = 1, CSN = 145, stripeWidth = 1, proportionalCapacity = [0, 100])
RAID_1
Component: 981ad75a-e569-22b5-b411-246e962c2408 (state: ACTIVE (5), host: esxi-dell-g.rainpole.com, capacity: naa.500a07510f86d69d, cache: naa.5001e82002675164, votes: 1, usage: 1.9 GB, proxy component: false)
Component: 91090d5b-7d8c-fd31-a2a7-246e962c2408 (state: ACTIVE (5), host: esxi-dell-f.rainpole.com, capacity: naa.500a07510f86d6b3, cache: naa.5001e82002664b00, votes: 1, usage: 1.9 GB, proxy component: false)
Witness: 981ad75a-a0de-24b5-9c68-246e962c2408 (state: ACTIVE (5), host: esxi-dell-h.rainpole.com, capacity: naa.500a07510f86d6bd, cache: naa.5001e8200264426c, votes: 1, usage: 0.0 GB, proxy component: false)
Extended attributes:
Address space: 273804165120B (255.00 GB)
Object class: vmnamespace
Object path: /vmfs/volumes/vsan:52fae366e94edb86-c6633d0af03e5aec/contentlib-360a2e63-897e-4c05-91e6-94327295acf4
Object capabilities: NONE

 

Even after running the command to specify a RAID-5 policy (which already existed btw), it did not seem to work.

After some assistance, it seems that I was using the command incorrectly. The correct way to use the vsan.object_reconfigure command is to specify the object’s attributes. In the following example, we will switch an object that has an FTT=1 to an FTT=0 by specifying the attribute hostFailuresToTolerate.

 

Test #2

/vcsa-06/CH-Datacenter/computers> vsan.object_info 0 2a53c55b-ee0e-7561-7df0-02004203cd1a
DOM Object: 2a53c55b-ee0e-7561-7df0-02004203cd1a (v, owner: 10.161.106.101, proxy owner: None, policy: spbmProfileId = aa6d5a82-1c88-45da-85d3-3d74b91a5bad, spbmProfileName = vSAN Default Storage Policy, CSN = 2, stripeWidth = 1, spbmProfileGenerationNumber = 0, hostFailuresToTolerate = 1, cacheReservation = 0, proportionalCapacity = 0, forceProvisioning = 0)
RAID_1
Component: 2a53c55b-f217-d764-90cb-02004203cd1a (state: ACTIVE (5), host: 10.161.127.85, capacity: mpx.vmhba1:C0:T1:L0, cache: mpx.vmhba1:C0:T2:L0, votes: 1, usage: 0.0 GB, proxy component: false)
Component: 2a53c55b-efc6-d964-155d-02004203cd1a (state: ACTIVE (5), host: 10.161.106.101, capacity: mpx.vmhba1:C0:T1:L0, cache: mpx.vmhba1:C0:T2:L0, votes: 1, usage: 0.0 GB, proxy component: false)
Witness: 2a53c55b-1539-db64-d73d-02004203cd1a (state: ACTIVE (5), host: 10.161.109.225, capacity: mpx.vmhba1:C0:T1:L0, cache: mpx.vmhba1:C0:T2:L0, votes: 1, usage: 0.0 GB, proxy component: false)

 

/vcsa-06/CH-Datacenter/computers> vsan.object_reconfigure 0 2a53c55b-ee0e-7561-7df0-02004203cd1a –policy=”((\”hostFailuresToTolerate\” i0))”
Reconfiguring ‘2a53c55b-ee0e-7561-7df0-02004203cd1a’ to ((“hostFailuresToTolerate” i0))

 

/vcsa-06/CH-Datacenter/computers> vsan.object_info 0 2a53c55b-ee0e-7561-7df0-02004203cd1a
DOM Object: 2a53c55b-ee0e-7561-7df0-02004203cd1a (v, owner: 10.161.106.101, proxy owner: None, policy: hostFailuresToTolerate = 0, CSN = 4)
Component: 2a53c55b-efc6-d964-155d-02004203cd1a (state: ACTIVE (5), host: 10.161.106.101, capacity: mpx.vmhba1:C0:T1:L0, cache: mpx.vmhba1:C0:T2:L0, votes: 1, usage: 0.0 GB, proxy component: false)

 

The object was changed from having 3 components in a RAID-1 to a single component in a RAID-0 configuration.

 

Test #3

So we have successfully switch a RAID-1 to a RAID-0. Now lets convert a different object from RAID-0 to a RAID-1 by setting FTT=1. First we verify that it is a RAID-0 with only a single component.

 

Next, we will make it a RAID-1 by increasing the FTT from 0 to 1.

/vcsa-06/CH-Datacenter/computers> vsan.object_reconfigure 0 6fd65e5b-24ea-fa4c-a1bd-246e962f4910 –policy=”((\”hostFailuresToTolerate\” i1))”
Reconfiguring ‘6fd65e5b-24ea-fa4c-a1bd-246e962f4910’ to ((“hostFailuresToTolerate” i1))

All reconfigs initiated. Synching operation may be happening in the background

 

Let’s check it again:

/vcsa-06/CH-Datacenter/computers> vsan.object_info 0 6fd65e5b-24ea-fa4c-a1bd-246e962f4910
DOM Object: 6fd65e5b-24ea-fa4c-a1bd-246e962f4910 (v6, owner: esxi-dell-f.rainpole.com, proxy owner: None, policy: SCSN = 37, hostFailuresToTolerate = 1, CSN = 38)
RAID_1
Component: 6fd65e5b-636d-bd4d-4226-246e962f4910 (state: ACTIVE (5), host: esxi-dell-e.rainpole.com, capacity: naa.500a07510f86d685, cache: naa.5001e820026415f0, votes: 1, usage: 32.1 GB, proxy component: false)
Component: 6beccd5b-5980-a41b-662b-246e962f5270 (state: RECONFIGURING (10), host: esxi-dell-f.rainpole.com, capacity: naa.500a07510f86d6b3, cache: naa.5001e82002664b00, dataToSync: 31.77 GB, votes: 1, usage: 32.4 GB, proxy component: false)
Witness: 6beccd5b-14f3-a61b-615a-246e962f5270 (state: ACTIVE (5), host: esxi-dell-h.rainpole.com, capacity: naa.500a07510f86d6bd, cache: naa.5001e8200264426c, votes: 1, usage: 0.0 GB, proxy component: false)
Extended attributes:
Address space: 34359738368B (32.00 GB)
Object class: vdisk
Object path: /vmfs/volumes/vsan:52fae366e94edb86-c6633d0af03e5aec/6cd65e5b-1701-509f-8455-246e962f4910/30julytest2_2.vmdk
Object capabilities: STRICT_GWE

 

And now we have converted it to a RAID-1. We can also see that the data has to resync after this changes, so please use with caution so as not to create unnecessary resync traffic on your vSAN cluster. Eventually, the resync will complete to give us this object with all components ACTIVE.

/vcsa-06/CH-Datacenter/computers> vsan.object_info 0 6fd65e5b-24ea-fa4c-a1bd-246e962f4910
DOM Object: 6fd65e5b-24ea-fa4c-a1bd-246e962f4910 (v6, owner: esxi-dell-f.rainpole.com, proxy owner: None, policy: SCSN = 37, hostFailuresToTolerate = 1, CSN = 40)
RAID_1
Component: 6fd65e5b-636d-bd4d-4226-246e962f4910 (state: ACTIVE (5), host: esxi-dell-e.rainpole.com, capacity: naa.500a07510f86d685, cache: naa.5001e820026415f0, votes: 1, usage: 32.1 GB, proxy component: false)
Component: 6beccd5b-5980-a41b-662b-246e962f5270 (state: ACTIVE (5), host: esxi-dell-f.rainpole.com, capacity: naa.500a07510f86d6b3, cache: naa.5001e82002664b00, votes: 1, usage: 32.1 GB, proxy component: false)
Witness: 6beccd5b-14f3-a61b-615a-246e962f5270 (state: ACTIVE (5), host: esxi-dell-h.rainpole.com, capacity: naa.500a07510f86d6bd, cache: naa.5001e8200264426c, votes: 1, usage: 0.0 GB, proxy component: false)
Extended attributes:
Address space: 34359738368B (32.00 GB)
Object class: vdisk
Object path: /vmfs/volumes/vsan:52fae366e94edb86-c6633d0af03e5aec/6cd65e5b-1701-509f-8455-246e962f4910/30julytest2_2.vmdk
Object capabilities: STRICT_GWE