let's assume we have one Nutanix block with 3 nodes. In each node we only have 1 CPU socket with 10 Cores.
A VM can only run on one node. So, in this case, wouldn't it make more sense to let a VM with 4 CPUs run on 1 VCPU and 4 Cores, instead of 4 VCPUs with 1 core, as each node has only 1 CPU socket?
Or does Nutanix always recommend to use only 1 Core per VCPU not matter how much CPU sockets are available in a node?
Best answer by Jon
Let's say that said AHV host had 40 total cores, which would show up as "40" in the "CPU(s)" line of lscpu on AHV (or hostssh lscpu within a CVM, or total cores in Prism UI -> Hardware).
Within a single virtual machine, the amount of "CPU(s)" that lscpu in Linux should never exceed the amount of "CPU(s)" on a single AHV host.
Let's say you assigned 40 "CPUs" to this hypothetical single Linux VM.
If that VM drove its CPUs to 100%, you'd have no more CPU to run ... anything, as each physical core would be at 100%.
This is a universal rule of thumb for any virtualization platform. There are situations where it makes sense to oversubscribe, from a single VM, but if you're looking for an 80/20 recommendation, this is it.
To be clear, for the 90/10 rule, it does not make a difference 2x20 or 1x40 in this made up example, as we'll process it just the same.
For the 10% / micro-optimization situations, lets use SAP HANA as a practical example
For HANA, you would want to very purposefully align your "Sockets x Cores" to align with the underlying Quad Socket server, which is defined in our SAP HANA BPG. This comes along with additional special settings to very particularly align the HANA VM with the underlying hardware.
This is similar on AHV as it is on ESX.
I use this very narrow example (not everyone runs HANA of course) to highlight, when you need to micro-optimize, its to grab the last few %'s of performance out of the hardware and the hypervisor.
This is almost entirely when consolidation isn't the top priority of your deployment, but rather things like hardware abstraction, business continuity, rapid HA, life cycle management, and NOT how much you can pack in a single server.
When you want to make things easy to manage
- don't micro-optimize, as that will actually make managing your environment harder. This is universally true for any platform, on-prem, aws, azure, etc etc.
- Size for the requirements. If you need 4x CPUs, provision some math that gives you 4. 1x4, 2x2, go nuts.