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.)