VERR_EM_NO_MEMORY ?

[eohrnberger]

Hi, I've been using VirtualBox for some time now, and have found it to be stable, reliable and usable.

Recently, I upgraded my Windows 10 Pro 64 bit host to an AMD 4 CPU processor with 16 GB RAM. It has an SSD for the OS and software, and a 500 GB SATA 3 drive for the VM's VDIs.

I have a Linux guest VM configured with 4 CPUs, and I wanted to start another Windows guest VM with 2 more CPUs. With these configurations, when I try to start the second VM guest, VirtualBox displays an VERR_EM_NO_MEMORY error on VM startup.

I check my Windows host's Task Manager, and it shows that only 40% of the 16 GB is being used.

I searched the forums here, and found the recommendation to reduce the number of CPUs configured for the VMs. When each of these VMs are allocated 2 CPUs, then it works out just fine.

I don't understand why VirtualBox seems to have issue with 4 CPU hardware with 6 CPU demand from VMs. Shouldn't VirtualBox handle this configuration?

[mpack]

Please provide a VM log file. With the VM fully shut down, right click it in GUI. Select "Show Log" and save "VBox.log" (ONLY) to a zip file. Attach the zip here.

[eohrnberger]

Thanks, I appreciate your prompt response.

Weird. I rebooted the Windows host, and set up the test case, allocating 4 CPUs to the Linux VM, and kept the two CPUs allocated to the Windows VM, and both came up and are running just fine.

Have to say, I'm slightly embarrassed, as previous to this, it was a consistent behavior. I'll capture logs and attach to the next post if I run into it again.

Sorry to have bothered you, but appreciate your prompt response.

[socratis]

I upgraded my Windows 10 Pro 64 bit host to an AMD 4 CPU processor

allocating 4 CPUs to the Linux VM, and kept the two CPUs allocated to the Windows VM

Do you see the problem with the CPU math? You have 4 for the host. You allocate 4+2=6 to the guests. That leaves you with -2 CPUs. Not good, the result has to be a positive integer.

If you're doing the same thing with the RAM, I expect the logs to be coming soon, but the answer will be known from now: you may be over-committing resources to your VMs, resources that you do not have.

Remember that simple rule:

• Total CPUs for your guests + 1 ≤ Host CPUs.
• Total RAM+vRAM+overhead for your guests ≤ Host RAM + some.

Edit: Fixed the math of the "simple rule", it was "simply wrong".

[eohrnberger]

Over committing physical resources to VMs, which aren't all always consuming them, shouldn't this be an allowable configuration?

If those rules you cite are the assumptions on which VirtualBox is built, then I'll have to abide by them. I'm not arguing that I shouldn't, if those are the rules.

[socratis]

Over committing physical resources to VMs, which aren't all always consuming them, shouldn't this be an allowable configuration?

They might consume them at some point and the results will be catastrophic. VirtualBox for example uses "lazy" memory allocation, so not all RAM is allocated for the guest from the get-go. There are ways to force it however.

And as far as the CPUs, that's a more sneaky problem. I've use a VM with 10 assigned CPUs on my 4 core/8 thread computer (yes, it was a test). I couldn't even move the mouse, had to kill the host. You're not allowed to do that anymore and you get a warning if you go over 3 vCPUs on a 4 core system.

If those rules you cite are the assumptions on which VirtualBox is built, then I'll have to abide by them. I'm not arguing that I shouldn't, if those are the rules.

Those are the rules of cruel nature, mathematics, and computers unfortunately.

You can bend the rules as you've seen, but as I said, you don't know when it's going to hit you, so it's best to stay within the (mathematical) limits.

[eohrnberger]

Those'd be the limits then. I think even the Windows 10 host OS takes a hit when it hits, starts stuttering and mouse moves don't, etc. Must reboot to to reset back to operable.

I'll have to test this scenario on Linux and see how it works on that as a host OS. Let you know.

The VM seems to have paused itself when it ran into this (see attached log)

Code: Select all

00:48:43.296712 PGM: Failed to procure handy pages; rc=VERR_NO_MEMORY rcAlloc=VINF_SUCCESS rcSeed=VINF_SUCCESS cHandyPages=0x8
00:48:43.296755      cAllPages=0x101456 cPrivatePages=0x48fc0 cSharedPages=0x0 cZeroPages=0xb8462
00:48:43.296933 GMM: Statistics:
00:48:43.296933      Allocated pages: 47bc4
00:48:43.296937      Maximum   pages: 10009e
00:48:43.296938      Ballooned pages: 0
00:48:43.297030 Host RAM: 9096MB available

Which is odd in that the Windows 10 Pro host showed much less than it's 16 GB RAM as being used in the Windows TaskManager.

[eohrnberger]

Confirmed. On a Linux dual core 64 bit machine, ran 2 VMs, each with 2 vCPUs allocated, and under load (i.e. installing updates on Win7 Pro 64 bit and an XP installing updates). Rock solid.

EDIT: Yeah, just fired up a 3rd 2 core VM on 2 core hardware, and all is well.