Existem várias métricas para usar ao determinar quando adicionar núcleos a uma VM. O uso principal, como você mencionou, é uma das métricas mais óbvias. Outros incluem o desempenho central real e a capacidade de multiencadeamento dos aplicativos.
Uma CPU pode ser um gargalo de desempenho sem ultrapassar 10% de uso. Normalmente, este é o caso quando o seu CPU é simplesmente lento (1ghz vs 2.5ghz), e você vai querer atualizar seu hardware host subjacente. (Meu tablet de 1.5ghz é dolorosamente lento, embora o uso da CPU nunca ultrapasse 10%. É apenas uma CPU lenta!)
Ainda há muitos aplicativos que não são multiencadeados, portanto, não importa quantos processadores (núcleos) você jogue neles, eles nunca usarão mais de um. Normalmente, nesse caso, você desejará investigar o upgrade de seu aplicativo para aproveitar várias CPUs antes de adicionar mais à VM. Além disso, alguns sistemas operacionais também têm restrições (geralmente baseadas em licenciamento); por exemplo, o Windows Server 2003 Standard suporta apenas 4 CPUs físicas, mas não se preocupa com os núcleos por CPU. Isso pode afetar se você adiciona CPUs virtuais ou núcleos por vCPU a uma VM.
Supondo que o uso do meu recurso de host seja mínimo, adicionaria núcleos a uma VM quando minhas métricas de desempenho mostrassem um uso de CPU médio (médio) maior que 50% durante o horário comercial normal. É um número arbitrário e, dependendo de seus aplicativos e padrões de uso, talvez você queira mais núcleos com 25% ou 75% de uso de CPU, embora quando sua média chegar a 75% provavelmente já passou da hora de fazer qualquer alteração. Você vai querer prestar atenção ao uso consistente versus picos de uso. Se sua CPU estiver normalmente em 5%, mas picos para 100% a cada poucos minutos, você não deseja adicionar núcleos até determinar a causa dos picos. Para sua informação, o vSphere tem essas métricas de desempenho incorporadas.
NOTA EDITORIAL: Isso provavelmente é mais apropriado para um aplicativo que tenha uma carga razoavelmente constante, como um servidor da Web. Aplicativos com uma carga hit-and-miss, como um servidor de desenvolvimento que compila código por 20 minutos a cada 4 horas, seriam muito diferentes. Nesse caso, você veria o desempenho do aplicativo (o compilador) e o pico de uso da CPU quando esse aplicativo está em execução (compilação). 100% da CPU durante toda a operação de compilação provavelmente se beneficiaria de mais CPU, contanto que o compilador seja multi-threaded. Mas então, você tem que se preocupar com seus desenvolvedores ficando bravos com você por cortar seu tempo de jogo pela metade.
Alguns aplicativos, como MS SQL Server e MS Exchange, intencionalmente hog seus recursos (a memória é a mais notável) e isso é por design, portanto, você precisa estar ciente do que seus aplicativos devem estar fazendo. Você precisa avaliar o desempenho real do aplicativo em relação ao uso de recursos - se o SQL Server estiver usando 100% da CPU e respondendo rapidamente, isso é diferente de um servidor SQL que usa 100% da CPU e responde lentamente.
Se o desempenho do aplicativo for lento, mas suas métricas e benchmarks revelarem que sua CPU não é o gargalo, não se preocupe em adicionar núcleos - embora, se o tempo de inatividade e os recursos do host não forem preocupantes, adicionar núcleos temporariamente para provar apontar para seus usuários não leva nada além de 10 minutos de tempo.
Além disso, lembre-se de que um bom hipervisor, como o VMWare ESXi, permite que você provisione demais. Isso significa que você pode aprovisionar 4 VMs com 4 núcleos cada (total de 16 núcleos), embora seu host tenha apenas 8 núcleos. O hipervisor aloca dinamicamente os recursos do host para a VM que mais precisa deles, portanto, com três VMs inativas, sua quarta VM pode mastigar o máximo de seu host que você pode alocar para ele. A captura que você quer observar é o licenciamento, já que alguns aplicativos são licenciados por núcleo ou por CPU e não por instalação de máquina ou SO.