The answer given by @emanueleroserba is not correct.
2. yes if you want to hide speculative-execution control mechanism of the underlying CPU to these VMs, otherwise they could remain powered on and potentially vulnerable to meltdown/spectre.
The purpose of https://kb.vmware.com/s/article/52345 is to pull out the microcode patches. The CPUID masking is effectively to "undo" the the microcode patch. The microcode is being disabled because of the report of machines rebooting after the microcode update. The reboots also occur also on physical PCs/servers that are not ESXi hosts but has the Intel microcode update through EFI/BIOS update. Meltdown is mitigated with guest OS patch. The microcode update is for Spectre.
The effect of these recommendations for an affected ESXi host is that the speculative execution control mechanism is no longer available to virtual machines even if the server firmware provides the same microcode independently. (For customers who have applied the same microcode updates from their server vendor’s Firmware/BIOS, this recommendation may remove the need to downgrade the firmware. Consult your server vendor directly for guidance.)
As with almost vmx configuration change, there needs to be VM reboot for it to take effect especially for a CPUID masking. The placement in /etc/vmware/config is so that it will affect all VMs that boot off that ESXi host instead of having to change the vmx configuration file of every VM.
Note also the two other bullet points in the KB about the CPUID masking of leaf 7 edx register.
- This will hide the speculative-execution control mechanism for virtual machines which are power-cycled afterwards on the ESXi host.
- This line will need to be removed after applying a future fixed microcode from Intel in order to enable the full guest OS mitigations for CVE-2017-5715.