topic erasure coding and HA in VMware vSAN Discussions

erasure coding and HA

vmb01 — Mon, 16 May 2022 14:48:48 GMT

A customer has a 4 nodes vSAN cluster and created a storage policy using FTT=1 and RAID5 (erasure coding)

They states that if they have an host failure, HA is not able to power on the failed VMs.

It seems that to power on the VM is necessary to create a new VSWP using FTT=1 and RAID5 but having only 3 hosts is not possible to create a RAID5 object.

Is it correct?

Re: erasure coding and HA

IRIX201110141 — Mon, 16 May 2022 20:00:08 GMT

Try to enable "Force provisioning = ON" within the vSAN Storage police to work around.

Regards,
Joerg

Re: erasure coding and HA

vmb01 — Tue, 17 May 2022 08:48:16 GMT

If It works using "Force provisioning = ON" it's correct to say that the VSWP object receive the storage policy assigned to the VM.
Is it possible to define a different storage policy to be assigned to the VSWP objects?

Re: erasure coding and HA

depping — Tue, 17 May 2022 09:27:40 GMT

The VM will power-on even if a host is unavailable with a RAID-5 in a 4 host cluster? Swap will then simply be created as a RAID-0 on a single host? It drops down basically to the lowest option. Force provisioning is configured to "enabled" by default for the swap file!

Re: erasure coding and HA

depping — Tue, 17 May 2022 09:28:53 GMT

See screenshot. Something else must be wrong here.

Re: erasure coding and HA

TheBobkin — Wed, 18 May 2022 21:13:00 GMT

Hello All,

Just some minor clarifications and points:

@IRIX201110141 It is not advisable to set ForceProvisioning=1 on the policy in general - this is bad idea because it may result in someone creating vmdk snapshots as FTT=0 and them being in the middle of a chain e.g. FTT=1 vmdk > FTT=0 vmdk > FTT=1 vmdk , so when you look at the VM physical disk placement you will be looking at the last object in the chain which is the last FTT=1 vmdk - this can give the false impression that everything related to this VM is FTT=1 when it is not, I have seen this in real life and the outcome is obviously not good. If you need to set ForceProvisioning=1 e.g. to take backups during a partial outage where you have insufficient nodes then do that at the time and then revert it and then validate 100% you don't have any FTT=0 data (give us folks in vSAN GS a shout if unsure how to do either of these things).

So, with the relatively recent changes to .vswp taking the policy assigned to the namespace this actually does a bit of a sly trick when creating a .vswp when it doesn't have enough nodes/FDs/disks to create the object with this policy: it looks to still leverage the host default policies (checkable via #esxcli vsan policy getdefault) which is FTT=1,ForceProvisioning=1 for .vswp objects, one difference between this and the old behaviour is that it still retains the link to the SPBM policy and UUID that it *should* have (even if those rules are completely different) whereas before these .vswp object would just have a 'dumb' non-SPBM policy applied and no SPBM labelling.