[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111029092106.GA15576@openwall.com>
Date: Sat, 29 Oct 2011 13:21:06 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: vzctl update (was: support for newer Fedora)
Dmitry,
On Sat, Oct 22, 2011 at 02:12:13PM +0400, Dmitry V. Levin wrote:
> I have no personal experience with running Fedora 14+ ovz containers, but,
> according to vzctl changelog, some changes were made to address these and
> other Fedora 14+ and 15+ issues. In other words, vzctl package needs to
> be updated.
Would you update vzctl for us? That would be very helpful.
While at it, I think we'll need to make two changes:
1. As far as I'm aware, newer vzctl dropped the use of cron jobs in
favor of some event notification mechanism (which I am totally
unfamiliar with). However, I think they have no equivalent to this cron
job that we add with vzctl-3.0.23-owl-cron.diff:
# Update /var/vzquota/quota.* files, which is desirable such that the
# containers' recorded disk usage is closer to the actual one and, even more
# importantly, such that any per-user and per-group quotas are recorded (not
# only usage, but also the quotas themselves). Without a cron job like this,
# if the server crashes, then not only the recorded usage will be way off, but
# also any manually set per-user and per-group quotas inside the containers
# will be lost.
2,7,12,17,22,27,32,37,42,47,52,57 * * * * root /usr/sbin/vzlist -H -o veid | xargs -r -n1 /usr/sbin/vzquota stat > /dev/null
Is this understanding correct? If so, would you re-introduce the cron
jobs mechanism just for this specific cron job? If so, I think this
change would need to be submitted upstream.
2. I think the MODULES_DISABLED setting should accept more than just yes
or no. Maybe it should be made tri-state, with the extra value called,
say, "optional" (meaning to disable optional modules only, but load the
required ones). Or maybe it should accept a list of modules to disable.
Specifically, before our recent move to use of modules for vz* stuff in
Owl, we had:
CONFIG_SIM_FS=y
CONFIG_VZ_QUOTA=y
CONFIG_VZ_QUOTA_UGID=y
CONFIG_VE=y
CONFIG_VE_CALLS=y
CONFIG_VZ_GENCALLS=y
CONFIG_VE_NETDEV=y
CONFIG_VE_ETHDEV=y
CONFIG_VZ_DEV=y
CONFIG_VE_IPTABLES=y
CONFIG_VZ_WDOG=m
CONFIG_VZ_CHECKPOINT=m
CONFIG_VZ_EVENT=m
which means that CONFIG_VZ_WDOG, CONFIG_VZ_CHECKPOINT, and
CONFIG_VZ_EVENT were in modules and they were not being loaded by
default - and most systems worked without these just fine. So they're
optional. Also optional are other modules that these three depend on.
I think they bring in ip_nat, ip_conntrack, nfs, lockd, nfs_acl, sunrpc -
or maybe the "vz" script loads some of these explicitly. These should
also be disabled with our new setting for MODULES_DISABLED. I am
especially concerned about ip_conntrack, with increases CPU load from
network traffic and introduces an extra way that the system may fail
when the connection table fills up. (I actually saw it make things
worse during mild DDoS to a website served by nginx. Merely increasing
net.nf_conntrack_max helped, just like not loading the module would.)
Again, I think this enhancement to MODULES_DISABLED should be submitted
upstream, assuming that it's still relevant. (I haven't looked at
recent versions of vzctl.) Also, we'll want to have it in 3.0-stable
(so maybe make it before updating vzctl in -current).
What do you say?
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
