On Tue, Feb 4, 2014 at 7:27 PM, Vladimir Davydov vdavy...@parallels.com wrote:
On 02/04/2014 07:11 PM, Michal Hocko wrote:
On Tue 04-02-14 18:59:23, Vladimir Davydov wrote:
On 02/04/2014 06:52 PM, Michal Hocko wrote:
On Sun 02-02-14 20:33:48, Vladimir Davydov wrote:
Suppose we are creating
On Mon, Feb 3, 2014 at 10:57 AM, Vladimir Davydov
vdavy...@parallels.com wrote:
On 02/03/2014 10:21 AM, David Rientjes wrote:
On Sun, 2 Feb 2014, Vladimir Davydov wrote:
Per-memcg kmem caches are named as follows:
global-cache-name(cgroup-kmem-id:cgroup-name)
where cgroup-kmem-id is the
will stay away from converting the actual users, you are all welcome
to do so.
Signed-off-by: Glauber Costa glom...@openvz.org
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Acked-by: Anton Vorontsov an...@enomsg.org
Acked-by: Pekka Enberg penb...@kernel.org
Reviewed-by: Greg Thelen gthe
One correction:
int vmpressure_register_kernel_event(struct cgroup_subsys_state *css,
- void (*fn)(void))
+void (*fn)(void *data, int level), void
*data)
{
- struct vmpressure *vmpr = css_to_vmpressure(css);
+
On Fri, Dec 20, 2013 at 8:44 PM, Luiz Capitulino lcapitul...@redhat.com wrote:
On Fri, 20 Dec 2013 10:03:32 -0500
Luiz Capitulino lcapitul...@redhat.com wrote:
The answer for all of your questions above can be summarized by noting
that for the lack of other users (at the time), this patch
On Fri, Dec 20, 2013 at 8:53 PM, Luiz Capitulino lcapitul...@redhat.com wrote:
On Fri, 20 Dec 2013 20:46:05 +0400
Glauber Costa glom...@gmail.com wrote:
On Fri, Dec 20, 2013 at 8:44 PM, Luiz Capitulino lcapitul...@redhat.com
wrote:
On Fri, 20 Dec 2013 10:03:32 -0500
Luiz Capitulino
On Thu, Dec 19, 2013 at 11:07 AM, Vladimir Davydov
vdavy...@parallels.com wrote:
On 12/18/2013 09:41 PM, Michal Hocko wrote:
On Wed 18-12-13 17:16:55, Vladimir Davydov wrote:
The memcg_params::memcg_caches array can be updated concurrently from
memcg_update_cache_size() and
On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote:
[CCing Glauber - please do so in other posts for kmem related changes]
On Mon 02-12-13 17:08:13, Vladimir Davydov wrote:
The KMEM_ACCOUNTED_ACTIVATED was introduced by commit a8964b9b (memcg:
use static branches when code not
On Mon, Dec 2, 2013 at 10:51 PM, Michal Hocko mho...@suse.cz wrote:
On Mon 02-12-13 22:26:48, Glauber Costa wrote:
On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote:
[CCing Glauber - please do so in other posts for kmem related changes]
On Mon 02-12-13 17:08:13, Vladimir
On Mon, Dec 2, 2013 at 11:21 PM, Vladimir Davydov
vdavy...@parallels.com wrote:
On 12/02/2013 10:26 PM, Glauber Costa wrote:
On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote:
[CCing Glauber - please do so in other posts for kmem related changes]
On Mon 02-12-13 17:08:13
Hi, Glauber
Hi.
In memcg_update_kmem_limit() we do the whole process of limit
initialization under a mutex so the situation we need protection from in
tcp_update_limit() is impossible. BTW once set, the 'activated' flag is
never cleared and never checked alone, only along with the 'active'
Could you do something clever with just one flag? Probably yes. But I
doubt it would
be that much cleaner, this is just the way that patching sites work.
Thank you for spending your time to listen to me.
Don't worry! I thank you for carrying this forward.
Let me try to explain what is
Please note that in contrast to previous versions this patch-set implements
slab shrinking only when we hit the user memory limit so that kmem allocations
will still fail if we are below the user memory limit, but close to the kmem
limit. This is, because the implementation of kmem-only
On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov
vdavy...@parallels.com wrote:
I need to move this up a bit, and I am doing in a separate patch just to
reduce churn in the patch that needs it.
Signed-off-by: Vladimir Davydov vdavy...@parallels.com
Reviewed-by: Glauber Costa glom...@openvz.org
On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov
vdavy...@parallels.com wrote:
This reduces the indentation level of do_try_to_free_pages() and removes
extra loop over all eligible zones counting the number of on-LRU pages.
Looks correct to me.
___
On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov
vdavy...@parallels.com wrote:
From: Glauber Costa glom...@openvz.org
During the past weeks, it became clear to us that the shrinker interface
It has been more than a few weeks by now =)
___
Devel
On Tue, Dec 10, 2013 at 3:50 PM, Vladimir Davydov
vdavy...@parallels.com wrote:
On 12/10/2013 08:18 AM, Dave Chinner wrote:
On Mon, Dec 09, 2013 at 12:05:54PM +0400, Vladimir Davydov wrote:
From: Glauber Costa glom...@openvz.org
In very low free kernel memory situations, it may be the case
On Tue, Dec 10, 2013 at 5:59 PM, Vladimir Davydov
vdavy...@parallels.com wrote:
Hi,
Looking through the per-memcg kmem_cache initialization code, I have a
bad feeling that it is prone to a race. Before getting to fixing it, I'd
like to ensure this race is not only in my imagination. Here it
OK, as far as I can tell, this is introducing a per-node, per-memcg
LRU lists. Is that correct?
If so, then that is not what Glauber and I originally intended for
memcg LRUs. per-node LRUs are expensive in terms of memory and cross
multiplying them by the number of memcgs in a system was not
On Mon, Dec 16, 2013 at 8:47 PM, Michal Hocko mho...@suse.cz wrote:
On Sat 14-12-13 12:15:33, Vladimir Davydov wrote:
The mem_cgroup structure contains nr_node_ids pointers to
mem_cgroup_per_node objects, not the objects themselves.
Ouch! This is 2k per node which is wasted. What a shame I
got nowhere in the past.
Glauber Costa (8):
don't call cpuacct_charge in stop_task.c
sched: adjust exec_clock to use it as cpu usage metric
cpuacct: don't actually do anything.
sched: document the cpu cgroup.
sched: account guest time per-cgroup as well.
sched: record per-cgroup number
this call quite useless.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Mike Galbraith mgalbra...@suse.de
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Thomas Gleixner t...@linutronix.de
---
kernel/sched/stop_task.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/stop_task.c b
the independent hierarchy walk executed by
cpuacct.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Dave Jones da...@redhat.com
CC: Ben Hutchings b...@decadent.org.uk
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
CC: Lennart Poettering lenn...@poettering.net
CC: Kay
The CPU cgroup is so far, undocumented. Although data exists in the
Documentation directory about its functioning, it is usually spread,
and/or presented in the context of something else. This file
consolidates all cgroup-related information about it.
Signed-off-by: Glauber Costa glom
We already track multiple tick statistics per-cgroup, using
the task_group_account_field facility. This patch accounts
guest_time in that manner as well.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
---
kernel/sched
.
[ glom...@openvz.org: incorporated mailing list feedback ]
Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl
Signed-off-by: Glauber Costa glom...@openvz.org
---
kernel/sched/core.c | 20 +++-
kernel/sched/fair.c | 6 +-
kernel/sched/idle_task.c | 6 +-
kernel
not likely, it seems a fair
price to pay.
2. Those figures do not include switches from and to the idle or stop
task. Those need to be recorded separately, which will happen in a
follow up patch.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul
classes are recorded in the root_task_group. One can easily
derive the total figure by adding those quantities together.
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
---
kernel/sched/core.c | 17 +++--
kernel
1996534 7205 1
cpu1 58800 0 1700 0 0 0 0 2848680 6510 1
cpu2 50500 0 1400 0 0 0 0 2350771 6183 1
cpu3 47200 0 1600 0 0 0 0 19766345 6277 2
Signed-off-by: Glauber Costa glom...@openvz.org
CC: Peter Zijlstra a.p.zijls...@chello.nl
CC: Paul Turner p...@google.com
and creating a base on
top of which cpu can implement proper optimization.
[ glommer: don't call *_charge in stop_task.c ]
Signed-off-by: Tejun Heo t...@kernel.org
Signed-off-by: Glauber Costa glom...@openvz.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Michal Hocko mho...@suse.cz
Cc: Kay Sievers
All the information we have that is needed for cpuusage (and
cpuusage_percpu) is present in schedstats. It is already recorded
in a sane hierarchical way.
If we have CONFIG_SCHEDSTATS, we don't really need to do any extra
work. All former functions become empty inlines.
Signed-off-by: Glauber
files.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Glauber Costa glom...@openvz.org
---
include/linux/cgroup.h | 1 +
kernel/cgroup.c| 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
(and it
is not clear if it will ever be)
With this patches, I can successfully run vzctl enter and ssh into containers
running totally unmodified kernels for: centos, ubuntu and suse.
Please comment
Glauber Costa (3):
hooks_ct: create devices inside container
allow for distro-specific fix ups at creation
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
side. We can do it from
the container side provided we do it before we chroot - and then the host side
fs is still visible.
The fact that we join a mount namespace will act to keep those mounts totally
private, and exempt us from cleaning it up.
Signed-off-by: Glauber Costa glom...@openvz.org
scripts.
Signed-off-by: Glauber Costa glom...@openvz.org
---
src/lib/hooks_ct.c | 44
1 file changed, 44 insertions(+)
diff --git a/src/lib/hooks_ct.c b/src/lib/hooks_ct.c
index f769865..a4f9425 100644
--- a/src/lib/hooks_ct.c
+++ b/src/lib/hooks_ct.c
On 05/21/2013 12:32 AM, Kir Kolyshkin wrote:
On 05/20/2013 05:49 AM, Glauber Costa wrote:
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream,
since some
support is very unlikely to ever land in the Kernel. We need to do
things like
Kir,
Here is a new attempt at implementing fixups scripts.
They look nicer than the last version, and rely on a more
generic and configurable script instead, that should make
our lives a lot easier in the future.
Please let me know what you think
Glauber Costa (2):
allow for distro-specific
/.autofsck. We
can check if the file was modified (non-existent - existent, or different
modification time) and run our fixups after this.
Signed-off-by: Glauber Costa glom...@openvz.org
---
etc/dists/scripts/prestart.sh | 36
1 file changed, 36 insertions
On 05/19/2013 09:41 PM, Kir Kolyshkin wrote:
+ */
+#define VZ_DEFAULT_UID10
+#define VZ_DEFAULT_GID10
I assume these are no longer used, right?
right
___
Devel mailing list
Devel@openvz.org
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
+{
+char buf[STR_SIZE];
+
+/* Distributions that don't need the fixup will can stop right
here */
+if (!actions || !actions-ct_fixup)
+return 0;
+
+if (snprintf(buf, sizeof(buf), %s/%s, root,
/etc/rc3.d/S00vz-fixups.sh) 0)
Again and again :(
How this snprintf
On 05/17/2013 04:18 AM, Kir Kolyshkin wrote:
+stat(res-fs.private, private_stat);
+if ((local_uid (private_stat.st_uid != *local_uid)) ||
+(local_gid (private_stat.st_gid != *local_gid))) {
As I just commented at the very end of a previous patch,
indeed it does
On 05/17/2013 04:11 AM, Kir Kolyshkin wrote:
+if ((arg-userns_p != -1) (read(arg-userns_p, ret,
sizeof(ret)) != sizeof(ret))) {
+logger(-1, errno, Cannot read from user namespace pipe);
We don't close arg-userns_p in case of error here.
And it seems we do not close the other
On 05/17/2013 05:35 AM, Kir Kolyshkin wrote:
This is kinda becoming over-engineered (and now I realized I should have
said it earlier,
when reviewing the patch that added the first param).
I understand well why you need local_uid and local_gid from config and
cmdline
in ct_open(), but
will go back to it
ASAP.
Glauber Costa (6):
user namespace support for upstream containers
add user mismatch test
allow local uid and gid to be specified at container creation
modify tar extraction to account for user namespace
automatically add bridge venet0 when needed
allow for distro
From: Glauber Costa glom...@parallels.com
This patch allows the execution of unprivileged containers running ontop
of an upstream Linux Kernel. We will run at whatever UID is found in the
configuration file (so far empty, thus disabled).
Signed-off-by: Glauber Costa glom...@parallels.com
From: Glauber Costa glom...@parallels.com
In theory, we won't be able to run if our private area is not owned by
ourselves. We could, if it have very wide open security permissions, but we
should never set up a container like that.
Aside from a basic sanity check, this is intended to catch
From: Glauber Costa glom...@parallels.com
It is a valid use case to run a container with host uid and gid different than
the default. In particular, already deployed versions of vzctl are expected to
have this value unset, effectively meaning they are not expecting user
namespaces to be present
From: Glauber Costa glom...@parallels.com
If we are running upstream with user namespaces, we need to create the
container filesystem not with the ownership preserved, but reflecting the
mapping we need to apply. Note that according to our documentation, we should
ignore this if the user
From: Glauber Costa glom...@parallels.com
The chosen architecture to deal with --ipadd with upstream containers is to
create a veth pair and add the host side information to a bridge called venet0.
This way, all the code that expects venet0 to exist can still work without
modifications
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
On 05/16/2013 04:14 PM, Andrey Vagin wrote:
+ ret = ct_env_create_real(arg);
+ if (ret 0)
return VZ_RESOURCE_ERROR;
- }
Isn't it better to just keep the return values intact in create_real,
and then return them as is if ret != 0 ?
On 05/16/2013 04:14 PM, Andrey Vagin wrote:
CRIU requires a pid of the init.
Signed-off-by: Andrey Vagin ava...@openvz.org
The way you coded it, it seems to me that we will always overwrite the
pid file, which is fine: this way we won't run into the usual pid file
already exists kinds of
On 05/14/2013 07:02 AM, Kir Kolyshkin wrote:
Oh my, four cases of whitespace-at-eol which I had to fixed manually.
Sorry about that. I think I got to used to checkpatch and the such that
I forget to verify all of those manually.
Wanted to apply it nevertheless and fix some things myself, but
On 05/14/2013 07:03 AM, Kir Kolyshkin wrote:
On 04/29/2013 10:16 PM, Glauber Costa wrote:
Kir,
Please review the following patchset. The main difference from last
version is that
we support running with userns disabled even if it is present. This
effectively means
that containers that were
On 05/14/2013 07:17 AM, Kir Kolyshkin wrote:
Hmm...
If I understand it correctly, in case LOCAL_UID/LOCAL_GID is not set in
the global configuration file,
and not supplied from command line, here you apply the default values of
1.
The problem I see these values are not saved into
On 05/14/2013 07:09 AM, Kir Kolyshkin wrote:
+When running with an upstream Linux Kernel that supports user
namespaces (=
+3.8), the parameters \fB--local_uid\fR and \fB--local_gid\fR can be
used to
+select which \fIuid\fR and \fIgid\fR respectively will be used as a
base user
+in the host
On 05/14/2013 07:17 AM, Kir Kolyshkin wrote:
Hmm...
If I understand it correctly, in case LOCAL_UID/LOCAL_GID is not set in
the global configuration file,
and not supplied from command line, here you apply the default values of
1.
The problem I see these values are not saved into
the command line.
If that is the case, this value should take precedence. To achieve this, we
should also pass the cmd_p information to the open functions.
Signed-off-by: Glauber Costa glom...@openvz.org
---
include/env.h | 8 +---
src/lib/env.c | 7 ---
src/lib/hooks_ct.c | 2
From: Glauber Costa glom...@parallels.com
It is a valid use case to run a container with host uid and gid different than
the default. In particular, already deployed versions of vzctl are expected to
have this value unset, effectively meaning they are not expecting user
namespaces to be present
From: Glauber Costa glom...@parallels.com
If we are running upstream with user namespaces, we need to create the
container filesystem not with the ownership preserved, but reflecting the
mapping we need to apply. Note that according to our documentation, we should
ignore this if the user
From: Glauber Costa glom...@parallels.com
The chosen architecture to deal with --ipadd with upstream containers is to
create a veth pair and add the host side information to a bridge called venet0.
This way, all the code that expects venet0 to exist can still work without
modifications
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
From: Glauber Costa glom...@parallels.com
This patch allows the execution of unprivileged containers running ontop
of an upstream Linux Kernel. We will run at whatever UID is found in the
configuration file (so far empty, thus disabled).
Signed-off-by: Glauber Costa glom...@parallels.com
From: Glauber Costa glom...@parallels.com
In theory, we won't be able to run if our private area is not owned by
ourselves. We could, if it have very wide open security permissions, but we
should never set up a container like that.
Aside from a basic sanity check, this is intended to catch
for userns presence very early during creation time. I
think this very much clarifies our handling of the command line option. The
documentation is also changed as you requested, for consistency.
Glauber Costa (7):
user namespace support for upstream containers
add user mismatch test
Also pass
On 05/11/2013 03:53 AM, Igor M Podlesny wrote:
On 30 April 2013 13:16, Glauber Costa glom...@openvz.org wrote:
From: Glauber Costa glom...@parallels.com
To work around that, we can employ a trick to allow container creation right
now, as well as to avoid compatibility problems: we will resort
On 05/11/2013 05:07 AM, Igor M Podlesny wrote:
On 30 April 2013 11:46, Glauber Costa glom...@openvz.org wrote:
Currently, vps_setup_res() have an explicit test for state != VPS_STARTING
before applying beancounter limits. This means that we can set limits without
further problems when
On 05/11/2013 04:14 AM, Igor M Podlesny wrote:
On 30 April 2013 13:16, Glauber Costa glom...@openvz.org wrote:
@@ -576,7 +765,9 @@ int ct_do_open(vps_handler *h, vps_param *param)
{
int ret;
char path[STR_SIZE];
+ char upath[STR_SIZE];
struct stat st
On 05/13/2013 12:11 PM, Igor M Podlesny wrote:
On 13 May 2013 16:11, Glauber Costa glom...@parallels.com wrote:
On 05/13/2013 12:08 PM, Igor M Podlesny wrote:
On 13 May 2013 15:50, Glauber Costa glom...@parallels.com wrote:
[...]
Aren't macroses supposed to be UPPER CASE named?
Yes
-vz option, while
Patch #3 fixes a bug present in all versions.
Thanks
Glauber Costa (3):
hooks_ct: fix gcc warning
ub: compile ub support for non vz kernels as well
hooks_ct: fix ub limits setting for upstream containers
include/ub.h| 40 --
src/lib/Makefile.am | 3
Signed-off-by: Glauber Costa glom...@openvz.org
---
src/lib/hooks_ct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/hooks_ct.c b/src/lib/hooks_ct.c
index 03a18e7..63af536 100644
--- a/src/lib/hooks_ct.c
+++ b/src/lib/hooks_ct.c
@@ -247,7 +247,7 @@ static int
From: Glauber Costa glom...@parallels.com
Commit c9d9170b0 fixed a bug by not including the ub functions if VZ support
was not present in the running kernel, and replacing them with empty stubs.
This approach, however, proved to be too aggressive. We need to at least be
able to read and write
for it in its
startup function.
We should do the same, and call our version of setlimits ourselves when the
container is coming up.
Signed-off-by: Glauber Costa glom...@openvz.org
---
src/lib/hooks_ct.c | 147 +++--
1 file changed, 76 insertions
amount minus two
pages, which should effectively mean accounting turned on, but unlimited
Signed-off-by: Glauber Costa glom...@openvz.org
---
src/lib/cgroup.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/lib/cgroup.c b/src/lib/cgroup.c
index 9185d46..ae7fe5c 100644
is in place).
Glauber Costa (9):
host uid and gid parameters
adjust fs_create parameter
pass parameters to open
user namespace support for upstream containers
add user mismatch test
allow local uid and gid to be specified at container creation
modify tar extraction to account for user
From: Glauber Costa glom...@parallels.com
When running with an upstream Linux kernel that supports user namespaces,
we will run the container using an unprivileged user in the system. That
can be any user, and it serves as base to a 1:1 mapping between users in
the container and users in the host
From: Glauber Costa glom...@parallels.com
We need to pass more information to fs_create. Instead of adding arguments, it
is preferred to pass the whole vps_p structure and unfold it inside the callee.
Signed-off-by: Glauber Costa glom...@parallels.com
---
src/lib/create.c | 12 +++-
1
.
Signed-off-by: Glauber Costa glom...@openvz.org
---
include/env.h | 6 +++---
src/lib/env.c | 7 ---
src/lib/hooks_ct.c | 2 +-
src/lib/hooks_vz.c | 2 +-
src/vzctl-actions.c | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/include/env.h b/include/env.h
From: Glauber Costa glom...@parallels.com
This patch allows the execution of unprivileged containers running ontop
of an upstream Linux Kernel. We will run at whatever UID is found in the
configuration file (so far empty, thus disabled).
Signed-off-by: Glauber Costa glom...@parallels.com
From: Glauber Costa glom...@parallels.com
In theory, we won't be able to run if our private area is not owned by
ourselves. We could, if it have very wide open security permissions, but we
should never set up a container like that.
Aside from a basic sanity check, this is intended to catch
From: Glauber Costa glom...@parallels.com
If we are running upstream with user namespaces, we need to create the
container filesystem not with the ownership preserved, but reflecting the
mapping we need to apply. Note that according to our documentation, we should
ignore this if the user
From: Glauber Costa glom...@parallels.com
The chosen architecture to deal with --ipadd with upstream containers is to
create a veth pair and add the host side information to a bridge called venet0.
This way, all the code that expects venet0 to exist can still work without
modifications
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
On 04/30/2013 01:48 PM, Kir Kolyshkin wrote:
On 04/29/2013 10:12 PM, Glauber Costa wrote:
The kernel memory controller cannot flip states from unlimited to
limited if
there are already tasks in it. Therefore, we always have to run with
*some*
value of kmem enabled. If we don't do it, we
On 04/01/2013 07:44 PM, Kir Kolyshkin wrote:
On 04/01/2013 08:37 AM, Glauber Costa wrote:
On 04/01/2013 07:13 PM, Dmitry Guryanov wrote:
On 130401 19:04:37, Glauber Costa wrote:
On 04/01/2013 06:58 PM, Dmitry Guryanov wrote:
On 130322 14:48:16, Glauber Costa wrote:
We need to pass more
implements --ipadd
(now all infrastructure is in place), we can ssh into containers due to issues
related to the proc filesystem.
Let me know if there are any issues, I'll happily fix them.
Glauber Costa (8):
host uid and gid parameters
adjust fs_create parameter
user namespace support
will be used for both uid and gid.
Signed-off-by: Glauber Costa glom...@parallels.com
---
include/res.h | 8
include/vzctl_param.h | 3 +++
src/lib/config.c | 32
3 files changed, 43 insertions(+)
diff --git a/include/res.h b/include/res.h
index
This patch allows the execution of unprivileged containers running ontop
of an upstream Linux Kernel. We will run at whatever UID is found in the
configuration file.
Signed-off-by: Glauber Costa glom...@parallels.com
---
include/env.h | 1 +
include/types.h| 1 +
src/lib/hooks_ct.c
the offset manually.
Signed-off-by: Glauber Costa glom...@parallels.com
---
scripts/vps-create.in | 19 ++
src/lib/Makefile.am | 3 ++
src/lib/chown_preload.c | 93 +
src/lib/create.c| 21 +++
vzctl.spec
already created containers that will be owned by root:root,
and will now try to run it unprivileged.
Signed-off-by: Glauber Costa glom...@parallels.com
---
src/lib/env.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/lib/env.c b/src/lib/env.c
index 2da848d..ff4dad2 100644
It is a valid use case to run a container with host uid and gid different
than the default. This patch provides and documents a way to do so.
Signed-off-by: Glauber Costa glom...@parallels.com
---
man/vzctl.8.in | 14 ++
src/vzctl-actions.c | 2 ++
src/vzctl.c | 1 +
3
that was actually already stated in the comments, but the
code was removed before merging because --ipadd would not work without full
unshare support anyway.
This patch implements that.
Signed-off-by: Glauber Costa glom...@parallels.com
---
scripts/vps-functions.in | 7 +++
src/lib/hooks_ct.c
operation done by /sbin/init
and rc.sysinit, therefore allowing operation to continue freely.
Signed-off-by: Glauber Costa glom...@parallels.com
---
etc/dists/redhat.conf | 1 +
etc/dists/scripts/fixups.sh | 43 +++
include/dist.h | 2
to be specified as uid/gid offset. It simplifies the code if
conf_parse_ulong is used, and well, if anyone *really* wants to run
privileged... We will apply the default value now only if the fields are
unset.
Glauber Costa (6):
host uid and gid parameters
adjust fs_create parameter
user namespace
will be used for both uid and gid.
Signed-off-by: Glauber Costa glom...@parallels.com
---
include/res.h | 8
include/vzctl_param.h | 3 +++
src/lib/config.c | 32
3 files changed, 43 insertions(+)
diff --git a/include/res.h b/include/res.h
index
We need to pass more information to fs_create. Instead of adding arguments, it
is preferred to pass the whole vps_p structure and unfold it inside the callee.
Signed-off-by: Glauber Costa glom...@parallels.com
---
src/lib/create.c | 13 -
1 file changed, 8 insertions(+), 5 deletions
This patch allows the execution of unprivileged containers running ontop
of an upstream Linux Kernel. We will run at whatever UID is found in the
configuration file.
Signed-off-by: Glauber Costa glom...@parallels.com
---
include/types.h| 1 +
src/lib/env.c | 16 ++
src/lib
the offset manually.
Signed-off-by: Glauber Costa glom...@parallels.com
---
scripts/vps-create.in | 19 ++
src/lib/Makefile.am | 3 ++
src/lib/chown_preload.c | 93 +
src/lib/create.c| 21 +++
vzctl.spec
1 - 100 of 979 matches
Mail list logo
