Hyper-V Processor Limitations

It is a trade-off. Say you have four physical cores and two VMs.

If you map two virtual cores in each VM, then pretty much each guest will see what it expects. It will see two cores that it expects to have full control over and more or less get that. (Assuming host load isn't high.) You won't often confuse the guest's scheduler with a case where it assigns a task to a core expecting the task to be done immediately and instead the task does not get done because no physical core is available. However, if one guest is CPU-starved and the other is idle, two cores will be twiddling their thumbs.

On the other hand, if you give each guest four virtual cores, each guest will be able to use all the available CPU power when the other guest and the host don't need it. However, when there is load from another source, the guest's scheduler will not get the behavior it expects and some tasks will get started immediately and some won't in a way that the guest's scheduler can't easily expect and deal with.

My recommendation is generally to put as many physical cores as you have in each VM that might ever be expected to need a lot of CPU. The exception would be if you have VM's that are critically dependent on latency. I would also reduce the core count on any "smaller" or "less important" VMs that share a physical box with more critical VMs.

The hypervisor assigns logical cores to physical cores as part of its scheduling policy. There is no fixed mapping unless you specifically make one. (Which I don't recommend except in the one specific case where you want to reserve a core for a latency-critical VM.)

8 threads would be ideal, assuming there's no significant additional overhead in result combining or anything like that. With only four threads, any execution units that couldn't be saturated by the single thread per virtual core would be wasted. With eight threads, they can be used.

Note that this only applies to the unrealistic assumption that each thread can saturate a core. Also, it might not apply if the division of the processor cache resources negatively impacted performance. Some tasks have performance that "falls off a cliff" at a certain cache size. If your cliff is between the full cache size of the physical core and half that cache size, then four threads might be better.