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.
