OpenVz: Failed to create system

Submitted by helpmin on Thu, 06/23/2011 - 01:04

An extra 1.11 GB free RAM is needed to create this system

It looks like that Cloudmin doesn't allow any memory over-commitment?

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Thu, 06/23/2011 - 01:41

No, we don't allow memory over committing. In fact I consider it a bad idea, as it can cause random failures when memory runs out unexpectedly - many Virtualmin users have reported problems running on VMs that user memory overcommitting.

Submitted by helpmin on Thu, 06/23/2011 - 02:14

So a user is able to create two containers with unlimited memory, but not allowed to create two containers with 2 or 3 GB memory each?

N containers with unimited memory == memory over-commitment?

Submitted by JamieCameron on Thu, 06/23/2011 - 02:18

The issue we have with over-committing is that from within the container it appears that more memory is available than there actually is. I guess this is also true for unlimited memory containers to a degree, but is less of an issue as the free and total memory visible from within the VM still reflects what is actually available.

For any kind of serious virtualization project where you need isolation between VMs, I would strongly recommend setting memory limits without any kind of over-committing.

Submitted by helpmin on Thu, 06/23/2011 - 03:00

Understand, but even (or actually because ) if you set memory limits, you will have the OpenVZ problem with random failures when memory runs out unexpectedly, right?

I am not sure whether I understood but is less of an issue as the free and total memory visible from within the VM still reflects what is actually available correctly. Is that true? If you create 10 OpenVZ VMs with unlimited memory (for example on a host with 4GB phys. memory) and one VM consumes all memory, then the other VM will still show almost 4GB free memory each, right?

Submitted by JamieCameron on Thu, 06/23/2011 - 20:23

From what I've seen, on a VM with unlimited memory you can see the actual memory memory available on the host system, taking into account memory used by other VMs.

Submitted by helpmin on Thu, 06/23/2011 - 20:37

I don't think this what I saw in my tests. Are you sure?

Regarding the fixed memory limit - let's say 512MB. If a VM reaches that limit, there will be random failures no matter if there are 5 VMs with 512MB on a 4GB host (under-committed) or 10 VMs (over-committed), right?

Submitted by JamieCameron on Fri, 06/24/2011 - 15:52

So the issue we have seen is on VMs where apps think they have 1 GB of RAM, but due to over-committing they actually have less than that at random times. This can cause programs to fail due to lack of RAM at un-expected times.

I'm interested to know what your use case for over-committing RAM is ?

Submitted by helpmin on Sat, 06/25/2011 - 01:53

I haven't mentioned that Cloudmin doesn't allow different values for

  • vmguarpages: guaranteed memory for the VE
  • privvmpages: upper bound on the memory for the VE
  • oomguarpages: guaranteed limit under OOM condition, typically same as vmguarpages

Use case, let's say on a 4GB host:

  • one production server P that get's a 3GB guarantee, but virtually most of the time uses around 1.5GB
  • one test server T with 512MB guarantee, but needs typically more and should be allowed to use memory if available (usually up to one 1GB more). In a critical memory situation (may be unexpected number of visitors on the production server) only the test server should be impacted.

So I would assign for server

  • P 3GB -> vmguarpages = oomguarpages = privvmpages
  • T 512MB -> vmguarpages = oomguarpages and 1.5GB > privvmpages

I am not really an expert, but hopefully you understand what I mean.

[And I am not an organization, just a hobby :) ]

Submitted by JamieCameron on Fri, 06/24/2011 - 23:55

Ok, that makes sense .. I will chat with the other Cloudmin developers to see what they think about allowing over-allocation and separate guaranteed and upper bound limits.

Most users use Cloudmin for providing VPSs to their own customers, and in that situation we consider over-allocation to be a source of problems as customers don't have any kind of certainty as to how much memory is really available.

Submitted by helpmin on Sat, 06/25/2011 - 01:58

Sounds great.

Actually I am confident they would want that, because especially in the hosting industry it is very common to offer bustable memory for OpenVZ (which is similiar to what I described, I guess)

Submitted by andreychek on Sat, 06/25/2011 - 10:53

Actually I am confident they would want that, because especially in the hosting industry it is very common to offer bustable memory for OpenVZ

It sounds like you guys covered some of this above -- but the issue from the Cloudmin/Virtualmin point of view is that the forums and issue tracker here are overflowing with users of over-allocated VPS's who are running into the strangest of problems. Often, they can't get Virtualmin to install at all onto it. And when they do, they frequently see applications mysteriously crashing.

The problem is that unlike swap space, which you can use on Xen and KVM, burstable RAM isn't guaranteed. If an application is using burstable RAM, and another VPS user on the server needs RAM, an application using burstable RAM will be killed off to make RAM available for that other VPS user.

It leads to really strange and unpredictable behavior... which generally isn't desirable when using a server :-)

But, we'll review what all you discussed above, and look into how best to handle that. Thanks for all your input!

Submitted by helpmin on Sat, 06/25/2011 - 11:16

Eric,

  1. The unpredictable behavior (OOM) can easily happen in Cloudmin as it is
    • For example you could create 20 OpenVZ VMs with unlimited memory
    • Or you could limit a VM to 1GB, and if the VM hits that limit ...
  2. OpenVZ also supports swap to some extent see also swappages

Submitted by JamieCameron on Tue, 07/05/2011 - 16:57

Cloudmin 5.7 will support setting separate guaranteed and maximum memory limits for OpenVZ, and optionally allow over-comitting.

Submitted by helpmin on Tue, 07/05/2011 - 17:37

Sounds great. Probably won't be able to test this (and centos 6.0), since my demo installation expires soon.

Submitted by Issues on Tue, 07/19/2011 - 19:21

Automatically closed -- issue fixed for 2 weeks with no activity.