Opened 12 years ago
Closed 12 years ago
#11483 closed defect (fixed)
cannot start a VM with a lot of CPUs and RAM
Reported by: | rogozin | Owned by: | |
---|---|---|---|
Component: | VMM | Version: | VirtualBox 4.2.6 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Linux |
Description
All the details are in here: https://forums.virtualbox.org/viewtopic.php?f=7&t=53941
Repeating the essentials: VM fails to start with this message: 00:00:02.048555 VMSetError: /home/vbox/vbox-4.2.6/src/VBox/VMM/VMMR3/VM.cpp(373) int VMR3Create(uint32_t, PCVMM2USERMETHODS, PFNVMATERROR, void*, PFNCFGMCONSTRUCTOR, void*, VM); rc=VERR_NO_MEMORY 00:00:02.048563 VMSetError: Memory allocation failed. 00:00:02.051779 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={db7ab4ca-2a3f-4183-9243-c1208da92392} aComponent={Console} aText={Memory allocation failed. (VERR_NO_MEMORY)}, preserve=false
It seems to happen if the number of CPUs and the RAM combination hit some kind of limit (not the general RAM limit). In the above thread I have two logs: one with 18 CPUs which work and same with 20 CPUs which does not.
Change History (5)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Hi Klaus,
Thanks for the feedback! I do agree with you and will take the CPU number down. It does allow me to go much higher on the memory.
Interesting point about not reporting HT. Do I have any benefits from HT? Remember, I do have about 8 different VMs on that host.
Thanks, D.
comment:3 by , 12 years ago
Hyperthreads provide a benefit up to a certain point. Not for guests but for host processes and lightweight processes. Just treat a guest as very heavyweight process (the context switch between host and guest takes quite long). So HT might help to speed up all host processes including the VMM itself but never assign more CPUs to all your guests then the number of real CPU cores.
comment:4 by , 12 years ago
We get the same exact error with VBox 4.1.24 on our system. It is an AMD Opeteron 6176 (48 cores) with 256 GB of RAM, of which over 200GB are free and not cached.
If we launch a machine with 8 cores and 32 GB RAM, it fails
If we launch a machine with 4 cores and 32 GB RAM, it succeeds
If we launch a machine with 8 cores and 24 GB RAM, it succeeds
Edit: Did some more tests and concluded that there are just some odd combinations of CPU and RAM that fail:
16 CPU, 24000 MB RAM - success
1 CPU, 110000 MB RAM - success
2 CPU, 110000 MB RAM - success
4 CPU, 110000 MB RAM - success
8 CPU, 110000 MB RAM - success
8 CPU 32000 MB RAM - success
8 CPU 34000 MB RAM - fail
8 CPU 36000 MB RAM - fail
8 CPU 38000 MB RAM - success (?)
16 CPU 34000 MB RAM - success (?)
16 CPU 36000 MB RAM - success (?)
8 CPU 40000 MB RAM - success
4 CPU 67000 MB RAM - success
8 CPU 67000 MB RAM - success
8 CPU 110000 MB RAM - success
16 CPU 110000 MB RAM - success
comment:5 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Please reopen if still relevant with VBox 4.2.12.
The free memory reported in VBox.log is just for sanity checking purposes, it's not an authoritative limit. Just FYI.
Your observed failure with 20 virtual CPUs appears to be a bug, that much is clear.
However I don't agree at all with your perception of "cannot fully utilize my hardware", at least not in the sense that a VM with 20 virtual cores would make sense on a host system which has 16 cores (don't mix this up with the number of threads due to HT). VirtualBox does not support reporting HT to the VM, and that means the absolutely maximum sane number of VCPUs is 16 in your case, and even that's stretching things since in the extreme case (all VCPUs executing guest code) the other activities of VirtualBox would be competing for resources.