Opened 5 years ago
Last modified 5 years ago
#18193 new enhancement
Increase vCore limit, 32 Cores are not enough
| Reported by: | multicoreuser | Owned by: | |
|---|---|---|---|
| Component: | VMM | Version: | VirtualBox 5.2.22 |
| Keywords: | Cc: | ||
| Guest type: | other | Host type: | other |
Description
Increase the CPU Limit from 32 processors to actually available cores.
The current 32 Cores Limit does not account for modern processors in combination with multisocket systems.
Change History (7)
follow-up: 2 comment:1 by , 5 years ago
- The CPU limit is based upon the capabilities of your CPU. Mine is set at 8 for example, and it's red after 4, the actual number of cores that I have. Not threads, cores.
- It's usually better and faster, if issues get first addressed in the VirtualBox forums, a lot more eyes there. More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of. For example, yours is most probably not a bug and someone from the developers has to deal with it and close it as "Invalid".
- You were supposed to follow these steps when you filed the bug, and provide a VBox.log:
comment:2 by , 5 years ago
Replying to socratis:
- The CPU limit is based upon the capabilities of your CPU. Mine is set at 8 for example, and it's red after 4, the actual number of cores that I have. Not threads, cores.
We're not talking about tiny home-machines with 4 cores here. I was not mentioning threads. I clearly stated in the title that I'm focussing the 32 core limit. Go ahead and read the manual at 3.5.2: https://www.virtualbox.org/manual/ch03.html
VirtualBox supports symmetrical multiprocessing (SMP) and can present up to 32 virtual CPU cores to each virtual machine
Furthermore if you check the gui, the slider won't go further than 32 processors.
- It's usually better and faster
It's usually better and faster if you read the ticket and think about if further information is needed before posting incoherent information in bullet points.
comment:3 by , 5 years ago
Instead of going "Oh, I'm sorry that I forgot the VBox.log, here it is" (so we can see what you're talking about), you're going into counter attack mode? With snarky comments about my computer and whether or not my comments are coherent or not? Seriously now? Are you for real?
From what I gather, you can't even get 8 cores up, that's your problem! See your other, soon-to-be-closed-as-a-duplicate, ticket #18192. Why would you care at this point about your 32 cores when you can't even get more than 8 up and running?
I'm out of here...
follow-up: 5 comment:4 by , 5 years ago
Don't be offended. There is no need for further information or a log in this ticket. My message was:
Increase the CPU limit from 32 processors to actually available cores. The current 32 Cores Limit does not account for modern processors in combination with multisocket systems.
The title was: Increase vCore limit, 32 Cores are not enough.
- No one was talking about threads. You brought it up out of nowhere.
- No one was talking about 4 cores. You brought it up out of nowhere.
- I'm talking about the limit which is set by software.
- The cores are obviously available.
- This limitation is a well documented behaviour in the manual.
- I've created the ticket as an enhancement proposal.
Seriously now? For real, why would you need a log for this? Your comment was completely useless. How would you react to random lorem impsum just for the sake of it after you've stated something concrete?
Please also read carefully what is going on in https://www.virtualbox.org/ticket/17898 before making incoherent conclusions again. It is completely not related to the situation here.
While this ticket is adressing an documented software limitation, the other post is adressing an already recognized bug which I wasn't able to find in a brief search.
follow-up: 6 comment:5 by , 5 years ago
Replying to multicoreuser:
Don't be offended.
That depends on the way the discussion is heading... And you might have taken a wrong turn somewhere in there...
No one was talking about threads. You brought it up out of nowhere.
You wouldn't believe how many people are confused (hint: the vast majority). I don't know what you know or you don't. I have to make the clarification in case you don't have it right.
No one was talking about 4 cores. You brought it up out of nowhere.
I brought up the 4 cores to show you that the slider is not fixed, it adjusts itself based on the host's capabilities. And I have no clue about your host's capabilities because... there's no log.
I'm talking about the limit which is set by software.
Yes. 640 KB was a famously set limit by a guru in the field. 16-bits was a limit at some point, so was 32-bits, so is 64-bits (for the majority) today. Software (and hardware) has limits, nothing new about that.
The cores are obviously available.
You see? That's exactly where the log comes in! Because the log contains vital information about your host and the CPU(s) it wears. Right now, we have absolutely no clue. Without the log, this is a vague, theoretical discussion at best, nothing more.
I've created the ticket as an enhancement proposal.
Funny, because the "Priority" is shown as "major" (bug), not as an "enhancement". Maybe you missed changing that part, and it now shows as a major existing issue, not as a RFE...
Seriously now? For real, why would you need a log for this? Your comment was completely useless. How would you react to random lorem impsum just for the sake of it after you've stated something concrete?
- Because it's asked and expected of you when you filed the ticket maybe? I don't recall any conditions being set. You were told to follow some basic instructions and you failed to do so.
- See above the "why" your log is needed.
Finally,
- Comments about your other ticket belong on your other ticket...
- Snarky comments do not belong anywhere...
comment:6 by , 5 years ago
You wouldn't believe how many people are confused (hint: the vast majority). I don't know what you know or you don't. I have to make the clarification in case you don't have it right.
I don't care. Just by reading the ticket you'd realize that this is valid regardless of an log. You can't even provide a log for this.
I brought up the 4 cores to show you that the slider is not fixed, it adjusts itself based on the host's capabilities. And I have no clue about your host's capabilities because... there's no log.
The slider has an fixed end at 32. Do you want a log for that?
Yes. 640 KB was a famously set limit by a guru in the field. 16-bits was a limit at some point, so was 32-bits, so is 64-bits (for the majority) today. Software (and hardware) has limits, nothing new about that.
Yes, and there is no need to talk about that. I've had an request for more cores and I've forwarded it.
You see? That's exactly where the log comes in! Because the log contains vital information about your host and the CPU(s) it wears. Right now, we have absolutely no clue. Without the log, this is a vague, theoretical discussion at best, nothing more.
Regardless of what you try to prove the software has an limit here. I won't provide you useless logs. You can figure out on your own how to generate a log for the current case. Feel free to waste your time with nonsense.
Funny, because the "
Priority" is shown as "major" (bug), not as an "enhancement". Maybe you missed changing that part, and it now shows as a major existing issue, not as a RFE...
The title shows (new enhancement) the priority is not related to whether it is a defect (true bug) or a feature request (enhancement).
- Because it's asked and expected of you when you filed the ticket maybe? I don't recall any conditions being set. You were told to follow some basic instructions and you failed to do so.
Nope, I won't provide any logs for this. This is utter bullshit. You're wasting your and my time resources.
Finally,
- Comments about your other ticket belong on your other ticket...
- Snarky comments do not belong anywhere…
Nice that you've mentioned the other ticket first. Im off here, it's a time waste.
comment:7 by , 5 years ago
I will not read through all of the previous comments, as there seems to be some off-topic bits there (happy to delete them if both parties agree). The immediate question which comes to mind is: what do you expect to gain from more than 32 cores in a virtual machine? Noting by the way that overhead for managing cores in a virtual machine is higher than on physical hardware, and at some point tends to cancel out the gains, and that for certain workloads, running them directly on the hardware just makes more sense. (If you want your full hardware performance for a CPU-intensive task, why pay the overhead of virtualisation at all?) We are more interested in working to reduce overhead than in extending the nominal number of cores available.
Note as well (I do not develop in that area) that extending the maximum number of cores may not be a trivial task which would benefit only a few people, if at all. It is hard for us to prioritise "special" requests unless someone is willing to pay for the work.
