[SOLVED] Sockets vs Cores vs Threads vs vCPU vs CPU Units

but all the rest is also about the virtual hardware? disks are virtual disks, memory consists of virtual DIMMs not real ones (although we don't expose the DIMMs, just the over all size), network is virtual NICs not real ones - why would CPU be different? ;)

if we would follow your suggest and double the core count passed to Qemu because your physical CPU on the current node supports hyper threading, what should we do if you migrate to another node that doesn't? or restore a backup on a server that doesn't? I understand your confusion, but it's caused by wrong assumptions - so the solution is to correct those, not make the world fit the assumptions :)
 
  • Like
Reactions: Cedrok and Neobin
but all the rest is also about the virtual hardware? disks are virtual disks, memory consists of virtual DIMMs not real ones (although we don't expose the DIMMs, just the over all size), network is virtual NICs not real ones - why would CPU be different? ;)

if we would follow your suggest and double the core count passed to Qemu because your physical CPU on the current node supports hyper threading, what should we do if you migrate to another node that doesn't? or restore a backup on a server that doesn't? I understand your confusion, but it's caused by wrong assumptions - so the solution is to correct those, not make the world fit the assumptions :)

Understood, and agreed. I hadn't thought of those issues. I had no idea you are simulating DIMMs as well. Proxmox is almost magical to non-technical users, so as you continue to make it easier to use, you shouldn't be surprised if you start getting incorrect assumptions by users.
 
  • Like
Reactions: fabian
I know this conversation is a little old, but I wasn't able to find my answer after reading. I'm on a single node PVE with no plans to utilize advanced features to migate nodes etc.

If I wish to give a VM 100% computing power of my AMD 5800X which has 8C, 16T, what should my settings be without overprovisioning?

Right now, I'm assigning it `16 cores` in PVE, would that be optimum?
 
Right now, I'm assigning it `16 cores` in PVE, would that be optimum?
IMHO no. Because that means the VM is always competing with the host, who is responsible for networking and other things. So it might just lag, hang, or provide rubbish user experience (depending what you are doing).
Also consider that threads are no real cores. So this might influence performance.
I'd Max out on 14, probably better 12 vcpus for your guest
 
Alright thanks, don't know if I speak for them, but I think this is the question+answer that most who are new to VMs seek, i.e. what are the settings to give a VM 100% for a hyperthreaded CPU.
 
  • Like
Reactions: friendofroot
But that is also not a common use case. If I only want to run a single VM and want as much performance as possible, I wound't use PVE and instead install that single guestOS bare metal on the host skipping all that limitations and overhead of virtualization.
 
Haha, you misunderstand. My goal was to figure out how to translate from hardware to software so that I can set things up correctly.

And the simplified answer is to just allocate the CPUs based on the total number of hardware threads. Once I know what is the 100%, I can assign with confidence without overprovisioning. I suspect that was the motivation behind this conversation in the first place.

That said, I think newbies should also be reminded that the hypervisor also consumes resources, i.e. only allocate about 90%, leave something for PVE.
 
Haha, you misunderstand. My goal was to figure out how to translate from hardware to software so that I can set things up correctly.

And the simplified answer is to just allocate the CPUs based on the total number of hardware threads. Once I know what is the 100%, I can assign with confidence without overprovisioning. I suspect that was the motivation behind this conversation in the first place.

That said, I think newbies should also be reminded that the hypervisor also consumes resources, i.e. only allocate about 90%, leave something for PVE.
Its not that easy. Lets for example think of CPU time. Lets say I got a 4 core CPU without hyperthreading...so 4 cores 4 threads. With that I got 400% CPU time to work with. So I could run 4 vCPUs at 100% or 8 vCPUs at 50% or 16 vCPUs at 25% CPU time and so on.
With hyperthreading it gets more complicated. A 4 core CPU with hyperthreading, so 4 cores 8 threads, doesn't mean it will be double as fast. Let's be generous and say it will be 25% faster. So 500% CPU time. Then I could run 5 vCPUs at 100% or 10 vCPUs at 50% and so on.
If you want your guests to be as snappy as possible (especially for single threaded workloads), you shouldn't allocate more vCPUs than you got physical cores. But then you are maybe also wasting some multithreaded performance as the CPU isn't 100% utilized.
So like always...it depends...
 
Last edited:
I think most of us know that a typical hyperthread CPU has X cores and 2X threads as it has been marketed that way by manufacturers for many years now. All I want to avoid is making the mistake of limiting computing power to only 50% because hypervisors only ask for cores with no mention of threads: PVE, including VirtualBox too.

By your logic, I could allocate 160 cores at 10%, but what is the point of doing that? I know fully understanding this is complex, so a simplified answer (which is an incomplete answer) can be a good starting point.
 
what are the settings to give a VM 100% for a hyperthreaded CPU.
If you want to assign 100% ressources then install the os without a hypervisor. This is not what a hypervisor was developed for.
wound't use PVE and instead install that single guestOS bare metal on the host skipping all that limitations and overhead of virtualization.
100% agreement!
 
so a simplified answer (which is an incomplete answer) can be a good starting point.
But that topic isn't simple. It is complex and even if you have a simplification at first: Latest if people complain abaut performance issues and very odd symptoms that need to understand the concepts anyways.

It is no binary choice. In the field There is no right or wrong. And there are a lot of people doing it "wrong" (so against physics and the concept of virtualization) and they still get along quite OK.

Anyways you can't fool physics. Water won't go up the hill and there is "no free lunch".
Also when it comes to virtualization...
 
If you want to assign 100% ressources then install the os without a hypervisor. This is not what a hypervisor was developed for.

100% agreement!

I wanted to assign 60%, but I don't know what is 60% without first knowing what is 100%. Asking for 100% is a hypothetical question, please don't take it that literally.
 
to give a VM 100% for a hyperthreaded CPU.
The problem with this idea is that a VM can only run when all resources are actually available. If it shall use all CPUs the VM can only run if nothing else is happening in the system, CPU-wise. This decision is made every millisecond or so. This means it may seem to work but is is really problematic in my recognition. "Strange" lockups/timeouts/malfunctions may happen and are hard to diagnose then...

(This was definitely true several years ago when Dual Core / Quad Core was a new concept. If this has changed someone may correct me.)

In my own experience overcommitting the number of cores is absolutely no problem if the assigned cores are distributed between several VMs - at least if they have light load. At home I have a MinisForum HM80 with 8C/16T and ~80 Cores assigned to 29 VMs. Overcommiting CPUs is a lot more acceptable than overcommitting Ram, which is always the limiting resource for me...

Good luck.
 
I wanted to assign 60%, but I don't know what is 60% without first knowing what is 100%
That depends in the workload as well.
Threads are giving you some benefits. But if it is 25% then this is a lot.
Let's assume 25% though.

So (totally oversimplified) 8Threads * 0,25 = 2Cores

Those 2 Cores plus the 8 (real Cores)
Total Core equivalent is 10 Cores - 60% would be (in this totally hillarious calculation) 6 Cores for the VM.

Btw: still you IMHO use a total inadequate approach. Ask yourself: what do I want to achieve? This is not "assign 60% of the resources". It is to run a specific task or application. THIS is what dictates the config.
If your gear is to weak, you need to adjust...
 
The problem with this idea is that a VM can only run when all resources are actually available
I'm clear that a CPU is shared across time, VM doesn't need all at once.

If you sum up the cores given to 29 VMs (~80 cores), it will definitely exceed 8C/16T.

In our case of 8C/16T, I think overcommit is only when we tell a single VM that we have 17T available, and that VM selects some custom algo that requires no less than 17T to run optimally, it's probably going to create problems.

I'm not looking to overcommit, in fact, my machine is only busy about 30% of the time across all VMs, but when one of them needs to get work done, I want it to give it its near 100% (less whatever PVE needs).
 
  • Like
Reactions: eleven45
Btw: still you IMHO use a total inadequate approach. Ask yourself: what do I want to achieve? This is not "assign 60% of the resources". It is to run a specific task or application. THIS is what dictates the config.
If your gear is to weak, you need to adjust...

Let's do this the other way round by elimination yea?

1. My machine is idle about 70% of the time, 120 of 168 hours
2. But when there is something to be done, do I only spend 20% resources and let the remaining 80% sit idle?
3. Or should I throw everything I have at it? (Assuming that my tasks can utilize all 16T fully)
4. The work could require Linux or Windows, but that is not predictable
5. Should I use PVE or instead double my cost and get 2 machines to install Linux and Windows so that they can get 100% resources when required?
6. A feasible (we can aim for optimal later) approach is to give both my VMs access to about roughly 60% of the resources and let them decide on what to do with them
7. 50% RAM is easy, but what is 60% CPU? The simple answer is 60% of 16T (and while 6% of 160T is also ~60% CPU, what's the point of such an example?)
8. Of course I understand the final performance is dependent on the algo being used, but the question is, have the VMs been given access to ~60% f the computing power in the first place?
9. I already found my answer several posts ago, 16T and I just have to decide how many concurrent threads (on the hardware) to allow for each VM.
 
3. Or should I throw everything I have at it? (Assuming that my tasks can utilize all 16T fully)
You wont, because you can't use 16T within the VM on a 16Thread system.
You will always compete with the host. Whatever you think the system is doing - that is not how a hypervisor operates. Please - I don't want to mess with you or play games. I just try to explain you have a fundamental glitch in your thought.

2. But when there is something to be done, do I only spend 20% resources and let the remaining 80% sit idle?
Kind off, because Virtualization means: Exchange flexibility with performance.
You can't have both. There is a trade-off.
Even though you think the system "does nothing" - it is not true. There is always something every VM does. It has an OS, there are tasks running.
And those tasks will interfer with your "big VM".
This is why cloud hyperscalers use very complex mechanisms to balance and optimize their environments. If you think a single Hypervisor can do this - you are wrong. Autoscaling is difficult and this is why your expectation is wishfull thinking.

5. Should I use PVE or instead double my cost and get 2 machines to install Linux and Windows so that they can get 100% resources when required?
if you want to have 100% ressources for one job, yes. But you also could use the same hardware and dual-boot. Depending on what you want to do.
Remember - flexibility vs. performance vs. cost. This all is a triangle - you can't have all.
6. A feasible (we can aim for optimal later) approach is to give both my VMs access to about roughly 60% of the resources and let them decide on what to do with them
usually less is more in virtualization environments. That also depends on the application. Means, if a VM always can get ressources when it needs, without waiting for it (e.g. your big VM being in a race condition by default) a small VM even might get the job done faster. There is a rule of thumb to "size to the minimum" rather than "maximum". Because every vCPU creates overhead.
7. 50% RAM is easy, but what is 60% CPU? The simple answer is 60% of 16T (and while 6% of 160T is also ~60% CPU, what's the point of such an example?)
RAM is relatively easy, unless you use oversubscription. But there as well. Memory of 16GB in guest means more on the host. You need memory to amanage the guest memory. Also don't forget the host OS (PVE) and services running there, ZFS for instance has a significant memory requirement.
1. My machine is idle about 70% of the time, 120 of 168 hours
This might look like it - but also can be caused through wait-states. So an overwhelmed system can also look like there is nothing going on it.
The performance analyses and tuning is a very difficult discipline. I am not saying that this is the case in your situation, but I have experienced those situations as well...

8. Of course I understand the final performance is dependent on the algo being used, but the question is, have the VMs been given access to ~60% f the computing power in the first place?
Forget about the host is my advice. Check what the VM needs to perform a proper operation. If you have cycles on the host to spare - that is ok. He is using them wisely and maybe prioritize another VM.

9. I already found my answer several posts ago, 16T and I just have to decide how many concurrent threads (on the hardware) to allow for each VM.
Not sure which question you exactly mean. You have 8 Cores. Real cores.
You should not use more than 6 vCPUs because everything else is a lie. It is no real core. 2 Cores (in mind) for the OS (PVE) help to prevent congestion.
And then use as minimal core count per VM as possible.
Linux might be even 1 vCPU
Windows typically needs at least 2 vCPUs.
Start with that and see how your VMs behave.
 
Each time I missed out a caveat in my reply, it gets picked to bits.

Several of my replies indicate I'm well aware that the hypervisor requires some resources. 16T as the answer is a simplified way to map the PVE GUI concept of core to the hardware of 8C/16T.
 
Last edited:
  • Like
Reactions: eleven45
Each time I missed out a caveat in my reply, it gets picked to bits.
It is Important to be precise, especially in these kind of discussions.
Several of my replies indicate I'm well aware that the hypervisor requires some resources.
I wasn't so sure about that, hence I wrote it again.

I am Spending time trying to help and now you are complaining about me trying to do so?
Bummer...
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!