When the previous time it worked immediately was the configuration the same?
Anyway, possible explanations:
(1) too many vCPUs in the Windows 10 (although this is unlikely to be the cause)
You can check whether all vCPU within the Windows 10 VM are busy while loading. If only 1 or 2 vCPUs are busy while the 10-11 vCPUs are idle/near idle (close to 0% utilization), there is no advantage to having the additional vCPUs. There is a perverse effect of having too many vCPUs where most are idle in the VM. The idle instructions of the vCPU will still have to be executed in the host CPU and therefore take away the execution time slots from the actual vCPU that need to have its instructions executed on the host CPU. It is a bit like having 10-11 extra people blocking/disturbing 1-2 people who are doing actual work. Although this sort of perverse situation should have been addressed by a CPU feature called Paused-Loop Exiting that came with Westmere generation of CPUs and ESXi 6.5 should be able to take advantage of this feature.
(2) Meltdown patch to the Windows 10 VM
If you already have the Meltdown patch applied to the Windows 10 VM, it will likely experience some slow down especially with I/O intensive tasks (disk I/O, network I/O). Given that the CPU you have is 2.7GHz E5-4650 (Sandy Bridge), it does NOT have the INVPCID (INValidate PCID) instruction. The INVPCID is available on Haswell generation and later CPUs. Windows 10 will not be able to make use of PCID (Process Context Identifier) in the Translation Lookaside Buffer (TLB) if the CPU/vCPU does not have INVPCID to mitigate performance hits with the Meltdown patch. Without PCID/INVPCID, the performance hit come as the TLB needs to be flushed constantly with every context switch and I/O intensive tasks tend to have many process context switches. If you run the Get-SpeculationControlSettings Powershell within the VM it will show the PCID performance mitigation as FALSE.
