Someone in my organization wrote the following:
For what should be fairly obvious reasons, Microsoft doesn't publish details of their activation scheme. However, several of the VM files (.vmx, .vmdk) contain several unique hardware IDs such as Virtual NIC MAC addresses, Virtual HD serial numbers, a bios UUID, etc. all of these values can be read by the guest OS. We know that hardware serial numbers like these are used in generating the hardware hash Microsoft uses to determine the identity of a system for activation even though the exact algorithms are secret.
We also know that when you copy a VM to a new location VMware Workstation will ask if it was moved or copied. If you select "copy" it generates new UUIDs, new MAC addresses, etc. and the system requires reactivation because as far as Windows is concerned, it's a different system or a major enough "hardware" change to qualify as such. If you select "I moved it", it does not generate new hardware IDs and the system remains activated.
I'll need to snapshot/backup my activated VM before testing, but it stands to reason that booting from the install media (Microsoft has a tool to generate or download ISOs) and formatting (or diskpart clean) the virtual drive before doing a clean install on a previously activated VM, like one might do on a physical system they wanted to rebuild, will allow one to perform a clean install in the VM and allow a reactivation per Microsoft's license terms. Assuming the reinstall auto activation works as Microsoft has described, it is installing on the same Virtual Hardware as long as you don't tell VMware to generate new hardware ID's.
https://www.microsoft.com/en-us/software-download/windows10ISO
On the flip side, there is also that "factory reset" "feature" that also supposedly will revert it to a "clean install" state you mentioned which could be another possibility.
