From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oren Laadan Subject: Re: kernel summit topic - 'containers end-game' Date: Thu, 02 Jul 2009 14:38:35 -0400 Message-ID: <4A4CFEAB.5080507@cs.columbia.edu> References: <20090623145611.GB19332@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090623145611.GB19332-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Serge E. Hallyn" Cc: Linux Containers , libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Daniel Lezcano , Daniel Veillard List-Id: containers.vger.kernel.org Serge E. Hallyn wrote: > A topic on ksummit agenda is 'containers end-game and how do we > get there'. > > So for starters, looking just at application (and system) containers, what do > the libvirt and liblxc projects want to see in kernel support that is currently > missing? Are there specific things that should be done soon to make containers > more useful and usable? > > More generally, the topic raises the question... what 'end-games' are there? > A few I can think of off-hand include: > > 1. resource control > 2. lightweight virtual servers > 3. (or 2.5) unprivileged containers/jail-on-steroids > (lightweight virtual servers in which you might, just > maybe, almost, be able to give away a root account, at > least as much as you could do so with a kvm/qemu/xen > partition) > 4. checkpoint, restart, and migration > > For each end-game, what kernel pieces do we think are missing? For instance, > people seem agreed that resource control needs io control :) Containers imo > need a user namespace. I think there are quite a few network namespace > exploiters who require sysfs directory tagging (or some equivalent) to > allow us to migrate physical devices into network namespaces. And > checkpoint/restart needs... checkpoint/restart. Heh ... it does need ... checkpoint/restart; and a few issues which we should think about sometime -- * Encapsulation of machine/OS config capabilities - how to detect (versioning, capabilities) ? - how to deal with mismatches ? (bail ? emulate ? hope for the best ?) - what happens if, e.g. VDSO page changes, or how to detect FPU changes... * Conversion of checkpoint image between kernel version (and automation) * Network namespaces, mnt namespaces - what's the best approach ? * Security assessment and brainstorming * Appealing use-cases for everyday use: - for hybernation - to reboot to new kernel without losing your session - to time travel back to before you lost in "bejewled" * Userspace tools - mainly for inspection of checkpoint images * Testing frameworks * Distributed c/r ? * Optimizations: low downtime, pre-copy, post-copy, cow, parallelization Now I really go hide :p Oren.