So I have a Storage Policy that is RAID5 (EC) with Stripe Width=1. I cloned this and the new policy's only difference is Stripe Width=2. I set a VM to use this policy about 36 hours ago. I expected that instead of seeing 4 components for my disks I would see 8, due to the increased stripe width, but I am not seeing that. Is there something I have to manually do to force this change, or is it just a timing thing?
My understanding is vSAN can apply a new policy on the fly using cloning and snapshots, am I misunderstanding this? Concerned that if I switch from a Thick policy to a Thin policy that I would still have to do a Storage vMotion, which is comical because with vSAN you only have one datastore.
There are a number of ways but simplest is likely just getting the output from the following (run on any host in the cluster) and then using less or any text editor to identify the vmdk and current Owner:
# esxcli vsan debug object list --all > /tmp/objout
No you don't need to vmotion, you need to apply the policy to the disk. Right click on the VM and go to VM Policies and click "check policy", or "reapply".
there should be a screen in the summary that shows the state.
That's what I thought, but when I went back to check the physical object placement, I still only see 4 components for each disk object. I did test with Thin->Thick->Thin and can see this work, it's not completely obvious it's doing anything, but after some time you can start to see the storage used difference (depending on the Thick/Thin application). The stripe width thing though is still something I am not seeing any change to.
For reference, I am doing this to increase throughput to the VM disks, potentially for use with SQL DB servers. Also, both the stripe width 1 and stripe width 2 policies are R5, RTT=1 and the datastore does have Dedupe/Compression. I'm running 7.0 u2c for ESXi/vSAN.
Hi,
when you cloned the policy, did you check if a compatible vSAN Datastore was listed/selected?
The datastore does show as compatible.
Poking the topic
@Tibmeister, Can you confirm you are applying this to a VM/vmdk that has no snapshots? Applying a different policy while running on snapshots will just apply it to the last snapshot in each disk-chain.
What does the storage configuration on this cluster look like? e.g. do you have at least 2 Capacity-tier devices in at least 4-nodes that would be required for a RAID5, SW=2, FTT=1 Object?
clomd.log of the DOM-Owner of the Object you are trying to apply this to is generally the most informative log for reason why it can't/won't apply.
VM has no snapshots.
The current config would be RAID 5, FTT = 1. The cluster has 6 nodes, each with 3 disk groups of 3 disks each. I basically cloned the current Storage Policy and changed the SW to 2.
How do I determine the DOM owner of the object?
There are a number of ways but simplest is likely just getting the output from the following (run on any host in the cluster) and then using less or any text editor to identify the vmdk and current Owner:
# esxcli vsan debug object list --all > /tmp/objout
Ok, went a slightly different route with PowerCLI and Get-ESXCLI, and found the owner. Nice trick to keep in the back pocket. For others coming across this, here's what I did
$esxcli = Get-ESXCLI -V2 -VMHost (Get-VM myVMName | Get-VMHost)
$params = $esxcli.vsan.debug.object.list.CreateArgs()
$params.all = $true
$params.vmname = "myVMName"
$esxcli.vsan.debug.object.list.Invoke($params)| Where type -eq vdisk | select owner, ObjectUUID, path
That made life easy and didn't have to start the SSH session right away just to find the owner and get the ObjectUUID.
To me, it looks like it worked, I don't see any errors anyway, but looking at the physical disk placement of the VM I see a hard disk across 4 disks groups, which is the same as all of my other RAID-5. Personally I would've expected to see 3 disks groups, not 4, but I am not a vSAN expert by any means.