É um trade-off. Digamos que você tenha quatro núcleos físicos e duas VMs.
Se você mapear dois núcleos virtuais em cada VM, praticamente cada convidado verá o que espera. Ele verá dois núcleos que espera ter controle total e mais ou menos conseguir isso. (Assumindo que a carga do host não seja alta.) Você não confundirá o planejador do convidado com um caso em que ele atribui uma tarefa a um núcleo esperando que a tarefa seja executada imediatamente e, em vez disso, a tarefa não é executada porque não há núcleo físico acessível. No entanto, se um convidado estiver com falta de CPU e o outro estiver ocioso, dois núcleos estarão girando o dedo.
Por outro lado, se você der a cada convidado quatro núcleos virtuais, cada convidado poderá usar todo o poder de CPU disponível quando o outro convidado e o host não precisarem dele. No entanto, quando há carga de outra fonte, o agendador do convidado não obterá o comportamento esperado e algumas tarefas serão iniciadas imediatamente e outras não serão de maneira que o agendador do convidado não possa facilmente esperar e lidar.
Minha recomendação é geralmente colocar quantos núcleos físicos você tiver em cada VM que possa precisar de muita CPU. A exceção seria se você tiver VMs que são extremamente dependentes da latência. Também reduziria a contagem de núcleos em VMs "menores" ou "menos importantes" que compartilham uma caixa física com VMs mais críticas.
O hypervisor atribui núcleos lógicos a núcleos físicos como parte de sua política de agendamento. Não há mapeamento fixo, a menos que você faça especificamente um. (O que não recomendo, exceto no caso específico em que você deseja reservar um núcleo para uma VM crítica à latência).