Can plenty of CPU cores and RAM be detrimental to the performance?

[fth0]

I assign the cores

Depending on what you mean by that, there's perhaps a misconception here. Let me explain a few details, trying to answer some of your questions at the same time:

1. vCPUs: In a VM configuration, you tell VirtualBox to provide <n> virtual CPUs (vCPUs) to a VM. To the guest OS, VirtualBox provides the <n> vCPUs as 1 CPU with <n> cores and no (hyper-)threads (1s/<n>c/<n>t). Note that in principle, <n> is independent of the host CPU and currently limited to 64 by VirtualBox 7.0 (try VBoxManage modifyvm "VM name" --cpus 64 for some nice display in your favorite guest OS's task manager ).

2. OS process(es) and threads: The VirtualBoxVM process ("the VM") creates 1 thread for each of the <n> vCPUs and several (<m>) additional threads (*). The VirtualBoxVM process does not tell the host OS how to schedule those <n+m> threads.

3. Host OS scheduling: The host OS decides itself when and how to schedule the <n+m> threads of the VirtualBoxVM process on the physical host CPU(s). The different Linux and Windows variants have different schedulers with different default settings, and the administrator can influence the schedulers and their settings in various ways.

3.1 Hyperthreads: AFAICS, host OS schedulers often try to avoid using both hyperthreads of a CPU core as long as possible, because the second hyperthread only adds 30 % performance on average.

3.2 Sockets: AFAICS, the scheduler of Windows Server variants tries to keep the threads of one process on a single socket, because the sockets do not share the faster CPU caches (L1 + L2 at least).

3.3 Hybrid CPUs: AFAICS, on Intel's hybrid CPUs with performance and efficiency cores (P-cores, E-cores), the Windows 11 scheduler tends to select the CPU cores dependent on its power management settings.

(*) Douglas Adams was right: When I first analyzed this behavior, the VirtualBoxVM process on my VM with 2 vCPUs had 42 threads in total.

PS: Threads: Note that I tried to maintain a clear distinction between (OS) threads as part of OS processes and (CPU) hyperthreads here. I've seen several discussions in the VirtualBox forums and also in other forums, where people were confusing them, resulting in misunderstandings.

[FranceBB]

Very clear and informative answer, as always.
So, if I got it right:

- in a single socket, multicore/thread configuration, the threads of the vCPU (+ other threads) will be assigned to the host real CPU cores most of the time and it will try to avoid using hyperthreads (so both "lines" to the same physical core) as much as possible as it would only add a minor performance improvement compared to using two different *real* cores.

- in a multi socket, multicore/thread configuration, the threads of the vCPU will be assigned to the different physical cores on the same socket 'cause moving things around to the other socket would add delay as they don't share a common cache and it will also still try to avoid using hyperthreads as it would only add a minor performance improvement.


Gotcha!
Thank you so much for this, it really solved some of the doubts I've been having for a really long time.

[fth0]

Very clear and informative answer, as always.

Thanks, appreciated!

So, if I got it right

Mostly, I think. There is one aspect where I'm not sure:

Scheduling vs Assigning: While I used the term "schedule", you used the term "assign", which could be understood wrongly as "persistent". If we assume (for simplicity) that scheduling takes place each millisecond (ms), the OS thread for vCPU0 can "jump" from one CPU core to another CPU core each ms, and still obey the rules that I described. And the OS threads do jump around in practice, and differently on Linux and Windows hosts. For a test, provide 2 vCPUs to a VM, create 100% CPU load in the guest, and watch your favorite task manager on the host.

[FranceBB]

Yep you're right to point that out, I got that it was "temporary", I just expressed it "badly".
The reason being that I actually did that very test in the past on a normal single socket motherboard while encoding with Avisynth (frameserver) + x264 (encoder).
If one assigns let's say 1 vCore on Linux, people are gonna see one core being at 100% for a few seconds, then another one being at 100% for a few seconds, then another one and so on, cycling through all the cores of the actual physical CPU. With two vCore it would be the same but cycling through two physical cores at the time every few seconds, leading to some very interesting graphs.

If I have some time tomorrow I'll show one in case other users are interested.

[arQon]

Host OS: Linux and Windows are behaving quite different
Hyperthreading: Many current CPUs use Hyperthreading, so it cannot be ignored (for simplification)

Those are good points to keep in mind later while evaluating things, but they don't have anything to do with the specific claim we're trying to refute here, which is that you "have to" keep a "spare" core free or Bad Things will Mysteriously Happen. There will undoubtedly be cases where that *is* true, but over a decade of experience has shown that they're likely to be a small minority of real-world cases, not a general rule.

What we want is for that advice to become "You can load as many CPUs in VMs as you have cores without any meaningful negative impact at all", or at worst, "unless XYZ", where XYZ is some small set of rare HW/workloads, like trying to run 10GbE; or a software RAID5 array, etc. The first step though is to establish that this position is valid, and for that none of the aspects you mention are relevant unless they apply to a majority of users in a way that matters (e.g. HT is "a majority", but it's only relevant in the sense that assigning 16 CPUs to a VM on an 8C/16T host is a Bad Idea, and the UI already covers that). Since we already know that none of them do, they all fall into the "unless XYZ" stage of things at best, and will self-classify appropriately from the results produced by the basic testing.