Solution 1:

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

Solution 2:

No, there is no direct mapping of logical processor vs physical processor... per-se... basically a new thread is created for each logical processor with the affinity set to a specific physical core... so each thread can consume 100% of the resources on each core. Allocating 2 machines to all 4 cores (2x4 logical cores) may or may not be a good idea. If your applications are cpu-intensive... or spawn lots of threads on both machines... both will lag periodically waiting for the other to finish... assigning dedicated cores per-instance means that there will be minimal delay throwing tasks at the CPU.

You can't really dedicate a specific amount of RAM to the host... other than limiting the amount the guests can consume. You can in other virtual frameworks... but hyper-v is the new-kid on the block without all the bells & whistles of the old-timers.