I don't think they meant to block it. Please look at the link I posted. It's a issue with the kernel and it's an easy fix. There are people running way more then 49 machines using Openvz with the correct option set.
J
JoBlo69
Guest
I don't think it was meant to come across as "over committing resources".
As far as i know, the way openvz works, is that you are able to assign as all the resources you can to each VM, as the hardware has..
For example:
Lets say you have a PC with a dual core cpu 4gb memory, and 1tb hdd.
From what i can tell, you can assign each slice with full cpu access, 4gb or memory, and each slice will only actually allocate what resources it needs for any current task, then back off the resources, as it idles..
So you can stack up whatever amount of resources you want per VM minus the hdd space. You have to statically assign hdd space, but the system dynamically allocates resources per VM as it is needed. The assigned resources (cpu and memory) that you set are the max allowed per VM. You can set up a VM with a limit of 50% cpu 1gb (out of 4gb) and the VM will not ever use more than that....
This is why i can easily run 200+ slices (after bug fix) on my 3ghz+ quad core xeon with 8gb of ram. The only "real" limit is how much you want to cap off each VM. outside of the obvious hardware limitations..
So when it was said about over committing resources, you really can't do this. The system wont let you. the 49 max VM thing i found, is just a bug that will be fixed in the next release mentioned above.
As far as i know, the way openvz works, is that you are able to assign as all the resources you can to each VM, as the hardware has..
For example:
Lets say you have a PC with a dual core cpu 4gb memory, and 1tb hdd.
From what i can tell, you can assign each slice with full cpu access, 4gb or memory, and each slice will only actually allocate what resources it needs for any current task, then back off the resources, as it idles..
So you can stack up whatever amount of resources you want per VM minus the hdd space. You have to statically assign hdd space, but the system dynamically allocates resources per VM as it is needed. The assigned resources (cpu and memory) that you set are the max allowed per VM. You can set up a VM with a limit of 50% cpu 1gb (out of 4gb) and the VM will not ever use more than that....
This is why i can easily run 200+ slices (after bug fix) on my 3ghz+ quad core xeon with 8gb of ram. The only "real" limit is how much you want to cap off each VM. outside of the obvious hardware limitations..
So when it was said about over committing resources, you really can't do this. The system wont let you. the 49 max VM thing i found, is just a bug that will be fixed in the next release mentioned above.
Last edited by a moderator:
Overcommiting RAM should not be allowed, because it can randomly kill your containers.
If you want to use more than the physical available RAM, simple add enough swap space so that the OOM killer is never called.
- Dietmar
Thanks for taking the time to fix it. It works great now. What's the chances we could convince the proxmox guys to make the kernal have the squashfs-modules and either the aufs-modules or unionfs-modules?
I should have taken a look after upgrading to 1.3. What I was asking above might already be possible. I'm still new to some of this stuff, but when I type apt-get install aufs-modules and apt-get install squashfs-moduels it tells me it is a virtual package provided by:
Then it lists multiple versions, but all of them say for kernel 2.6.26+. I'm assuming if I tried to pick one on the list I would be asking for trouble. I really just need it for this firmware builder I mess with and make squashfs files.
Then it lists multiple versions, but all of them say for kernel 2.6.26+. I'm assuming if I tried to pick one on the list I would be asking for trouble. I really just need it for this firmware builder I mess with and make squashfs files.