I have added vswap confguration samples to vzctl git. Basically, you set physpages and swappages and leave every other beancounter at unlimited. For example, this is how ve-vswap-256m-conf.sample looks like:
# UBC parameters (in form of barrier:limit) PHYSPAGES="0:256M" SWAPPAGES="0:512M" KMEMSIZE="unlimited" LOCKEDPAGES="unlimited" PRIVVMPAGES="unlimited" SHMPAGES="unlimited" NUMPROC="unlimited" VMGUARPAGES="unlimited" OOMGUARPAGES="unlimited" NUMTCPSOCK="unlimited" NUMFLOCK="unlimited" NUMPTY="unlimited" NUMSIGINFO="unlimited" TCPSNDBUF="unlimited" TCPRCVBUF="unlimited" OTHERSOCKBUF="unlimited" DGRAMRCVBUF="unlimited" NUMOTHERSOCK="unlimited" DCACHESIZE="unlimited" NUMFILE="unlimited" NUMIPTENT="unlimited" # Disk quota parameters (in form of softlimit:hardlimit) DISKSPACE="1G" DISKINODES="200000" QUOTATIME="0" # CPU fair scheduler parameter CPUUNITS="1000"
As you can see, physpages (ie RAM size) is set to 256 megabytes, while swappages (ie swap size) is set to 512 megabytes, all the other beancounters are unlimited. Wow, it's never been easier to configure your containers!
Now, we can utilize this stuff using RHEL6 based kernel. This is what we see from inside the container:
[root@localhost ~]# vzctl enter 103
entered into CT 103
[root@localhost /]# free
total used free shared buffers cached
Mem: 262144 23936 238208 0 0 10968
-/+ buffers/cache: 12968 249176
Swap: 524288 0 524288
[root@localhost /]# cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
103: kmemsize 4722976 4853726 9223372036854775807 9223372036854775807 0
lockedpages 0 0 9223372036854775807 9223372036854775807 0
privvmpages 4296 13875 9223372036854775807 9223372036854775807 0
shmpages 31 31 9223372036854775807 9223372036854775807 0
dummy 0 0 0 0 0
numproc 33 33 9223372036854775807 9223372036854775807 0
physpages 5984 5985 0 65536 0
vmguarpages 0 0 9223372036854775807 9223372036854775807 0
oomguarpages 2696 2696 9223372036854775807 9223372036854775807 0
numtcpsock 4 4 9223372036854775807 9223372036854775807 0
numflock 5 6 9223372036854775807 9223372036854775807 0
numpty 1 1 9223372036854775807 9223372036854775807 0
numsiginfo 12 18 9223372036854775807 9223372036854775807 0
tcpsndbuf 69760 0 9223372036854775807 9223372036854775807 0
tcprcvbuf 65536 0 9223372036854775807 9223372036854775807 0
othersockbuf 2312 10768 9223372036854775807 9223372036854775807 0
dgramrcvbuf 0 0 9223372036854775807 9223372036854775807 0
numothersock 51 53 9223372036854775807 9223372036854775807 0
dcachesize 1172451 1172451 9223372036854775807 9223372036854775807 0
numfile 370 390 9223372036854775807 9223372036854775807 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 14 14 9223372036854775807 9223372036854775807 0
[root@localhost /]# cat /proc/meminfo
MemTotal: 262144 kB
MemFree: 238208 kB
Cached: 10968 kB
Active: 16956 kB
Inactive: 1384 kB
Active(anon): 6352 kB
Inactive(anon): 1020 kB
Active(file): 10604 kB
Inactive(file): 364 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 524288 kB
SwapFree: 524288 kB
Dirty: 0 kB
AnonPages: 7364 kB
Mapped: 3416 kB
Shmem: 124 kB
Slab: 4012 kB
SReclaimable: 1088 kB
SUnreclaim: 2924 kB


Comments
So, I can see how adding Vswap might change the need/want the memory related parameters to unlimited... but what about everything else? Why would I want to set numproc to unlimited? I assume that the non-memory related parameters are still functional... right?
I plan on using this in a class starting next week and give each student their own container... so hopefully it'll get a good testing.
I tried installing Scientific Linux 6 beta 2 but the install media griped about missing or bad packages... and I don't think I had bad media so I gave up on it. I hope CentOS 6 comes out sometime next month. In the meantime, luckily I had a free RHEL entitlement. We do have a number of RHEL systems but usually not any extras for playing with.
> are still functional... right?
All the parameters are functional (e.g. privvmpages, too) and you can definitely use those. The idea is that you are not *required* to configure those, since physpages and swappages already gives you enough protection. In fact it's not quite true in test006 kernel yet (for example, kernel memory is not limited unless you explicitly set kmemsize) -- there are more fixes and improvements coming along the way.
Thanks for testing this stuff! :)