is recomendations to scalable vCPU count for new VM?

[sav1]

When I create every new VM for general purpose Apps (often not known HW geometry previously), I'm ask myself - how many vCPU should I create and how it must be balanced - more to sockets or to cores? And would scaling vCPU counts may take worse for VM working? Finaly, _what happening_ w/ guest's OS and apps - when I do it. I think it is not exact, like when we set second/third-fourth CPU to HW server in empty slot, or change CPU's (physical) w 6 cores to modern 8/12 etc.

So I have couple questions set:

Firstly:

so f.e. (from one hands) should I create 2 vCPU -s better 2 sockets and 1 core per socket, or 1 socket w/ 2 cores. Or maybe better way make all of them in full set.

From other hands, I was told on courses VMFT 5.5 that many vCPUs in rare case better than few of them (2-4), and more  in count of sets it maybe worse. So better way make 1-2 vCPU.

Secondly:

is well known OS-s (f.e. Windows Server 2008-2016, linux ubuntu /redhat 5-7, freebsd) sense vCPU's on setup, or works worse when I scale vCPU-s instead when i give them final set of vCPU? So maybe I should create VM w/ 4 vCPU instead 1 or 2 as minimum. And, secondly, is a different w/ starting 1 vCPU vs 2 vCPU.

Also to Apps, is common purposed Apps sense that scaling? I mean such apps as windows services (WSUS, AD) or mail systems (windows exchange or linux sendmail/postfix) or webservices (Firefront, apache/tomcat). Also and more interest RDBMS apps: MS SQL, Oracle database (standalone/RAC), MySQL.

P.s.: I did scale few times and didnt noticed smth especial w/ VM guest and apps internal. I didnt noted those events and didnt inspect VM health after that.

But a question is ...

TY.

[AishR]

It is important to understand the difference between virtual socket, virtual CPU and virtual cores. It will allow us in sizing the virtual machines.

First thing is to check the physical CPU on the host

If you have a physical server with single physical CPU socket that has 4 cores (quad-core) and hyperthreading is also enabled, which doubles the number of cores presented, for a total of 8 cores:

this means is that the maximum number of vCPUs that I could configure for a VM on this host would be 8.

If we edit the settings of a VM on that host, we see that we can either configure it with 8 virtual sockets and 1 virtual core per socket, 4 sockets and 2 cores per socket, 2 sockets and 4 cores per socket, or 8 sockets and 1 core per socket (all of which, if you multiple, totals 8):

Now that you know the limitations of the physical hosts and hypervisor, let’s look at why this differentiation of virtual sockets vs virtual cores is available and what you should choose.

Note: A very important part of understanding this is that when you configure a vCPU on a VM, that vCPU is actually a Virtual Core, not a virtual socket. Also, a vCPU has been traditionally presented to the guest OS in a VM as a single core, single socket processor.

What you might not have thought about is that the guest operating systems know not only the number of “CPUs” but also the number of sockets and cores that the CPU has available

The guest OS is just scheduling the threads from each process onto a CPU core and, using the hypervisor, those virtualized threads are scheduled, by the VMkernel scheduler, on a logical CPU core of the operating system.

If it doesn’t have any effect on performance, why would VMware even offered this option to specify the number of sockets per core for each VM? The answer is that it’s all related to software licensing for the OS and applications.

Most of the operating systems and applications are licensed “per socket”. You might pay $5000 per socket for a particular application. Let’s say that Windows Server 2003 is limited to running on “up to 4 CPUs” (or sockets). Say that you had a physical server with 4 quad core CPUs, for a total of 16 cores and then enabled hyperthreading for a total of 32 logical cores. If you configured your VM to have up to 4 “CPUs”, as the license specified, those 4 vCPUs would only run on 4 physical cores. However, if you had of installed that same Windows OS on the same phsyical server, it would have run on up to 4 sockets but, with each socket having 4 cores, it would have offered up to 16 logical cores for Windows (which still not breaking your end user license agreement). In other words, you would get to use more cores and likely receive more throughput.