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.

/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 = 0, CSN = 42)
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)
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
/vcsa-06/CH-Datacenter/computers>

 

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

2 comments
  1. Hey Cormac,
    Is it possible to reapply a Storage Policy to a VM (all objects) from RVC?
    Can this be scripted to get all machines with an Outdated Storage Policy and reapply the Storage Policy?

    Thanks

    • Yes – you can use the spbm.vm_change_storage_profile:

      usage: spbm.vm_change_storage_profile [opts] vm…
      Change storage profile of VM namespace and its disks
      vm: Path to a VirtualMachine
      -p, –profile= Profile
      -d, –dryrun Doesn’t apply the profile. Computes whether profile can be statisfied and if yes what is the cost of applying the profile

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.