Hello Sunny,
Welcome to Communities.
Are you changing the FTM (Fault Tolerance Method) and what is the current FTM? e.g. from RAID5/6 to RAID1 or vice-versa.
If you are changing the FTM (or if it is RAID5/6 FTT=2 in general IIRC) it will be creating whole new Objects when changing the Storage Policy - this of course means it will 1. temporarily have to use potentially a lot of extra space as it won't discard the original components until it has completed the job and 2. this is going to be a write and read intensive storage job which can of course cause contention unless managed carefully.
If you are not changing the FTM and it is currently RAID1 then it *should* just drop one of the replicas (and a witness component) and not need to create new components.
As when making any major changes to Storage Policies, please 1. first test this on a few Objects/VMs so you can get an indication of what it needs to change to apply the policy changes and
2. consider that it is preferable not to change the policy rules for all data at once (by editing the policy in situ) but instead to create a new policy with the desired configurations and apply this new policy to the VMs a few at a time (measure this in the amount of data they consume, not the number of VMs).
While doing any of this you should be monitoring the resync (Cluster > Monitor > vSAN > Resyncing Objects) and the impact this has on the latency of the workloads (Cluster > Monitor > vSAN > Performance > VM) and backend storage (Cluster > Monitor > vSAN > Performance > Backend).
In summary, Yes you can change the Storage Policy of a VM on the fly while powered on, whether this will have a negative impact on the clusters storage performance depends on a number of factors including the ones I noted above.
Bob