From: Greg Kurz <gkurz@fr.ibm.com>
To: Oren Laadan <orenl@cs.columbia.edu>
Cc: Chris Friesen <cfriesen@nortel.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Dave Hansen <dave@linux.vnet.ibm.com>,
containers@lists.osdl.org,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: C/R without "leaks"
Date: Fri, 17 Apr 2009 14:25:21 +0200 [thread overview]
Message-ID: <1239971121.6143.217.camel@bahia> (raw)
In-Reply-To: <49E85059.8070400@cs.columbia.edu>
On Fri, 2009-04-17 at 05:48 -0400, Oren Laadan wrote:
> You mean an sshd with an open connection probably; the server itself
> is clearly useful to be able to c/r.
>
Yes I mean C/R of sshd with active connections.
>
> A canonical example would a virtual-private-server: instead of doing
> server consolidation with a virtual machine, your do with containers.
> In a sense, containers lets you chop the OS into independent isolated
> pieces. You ca use a linux box to run multiple virtual execution
> environments (containers), each running services of your choice. They
> could range from a sshd for users, to apache servers, to database
> servers to users' vnc sessions, etc.
>
Indeed, containers allow to implement VPS just like virtual machines: we
call them system containers. Not much to say about that since they don't
introduce new concepts to users.
> Now comes the that you really need to take the machine down, for
> whatever reason. With c/r of live connections you can live-migrate
> these containers to another machine (on the same subnet) that will
> "steal" the IP as well, and voila - no service disruption.
>
Theorically, yes. Practicaly, you need a lot more than *simply* capturing
and restoring socket states for such a migration to be usable in the real
world.
>
> Such scenarios are the focus of Alexey.
>
So Alexey should provide some realistic examples, with several hosts,
routers, switches and overall network infrastructure.
> I'm also very interested in these scenarios, and I'm _also_ thinking
> of other scenarios, where either (a) an entire container is not
> necessary (example: user running long computation on laptop and wants
> to save it before a reboot), or (b) the program would like to make
> adjustments to its state compared to the time it was saved (example:
> change the location of an output log file depending on the machine
> on which your are running).
>
I'm _only_ interested in these other scenarios for the moment.
> Unfortunately, if we plan for and require, as per Alexey, that c/r
> would only work for whole-containers, these two cases will not be
> addressed.
>
Discussion must go on then. There's no hurry in getting C/R
mainlined. :)
--
Gregory Kurz gkurz@fr.ibm.com
Software Engineer @ IBM/Meiosys http://www.ibm.com
Tel +33 (0)534 638 479 Fax +33 (0)561 400 420
"Anarchy is about taking complete responsibility for yourself."
Alan Moore.
next prev parent reply other threads:[~2009-04-17 12:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-14 3:43 Creating tasks on restart: userspace vs kernel Oren Laadan
2009-04-14 9:59 ` Ingo Molnar
2009-04-14 14:53 ` Oren Laadan
2009-04-14 16:16 ` Serge E. Hallyn
2009-04-14 16:36 ` Alexey Dobriyan
2009-04-14 16:46 ` Alexey Dobriyan
2009-04-14 18:40 ` Oren Laadan
2009-04-14 19:59 ` Alexey Dobriyan
2009-04-14 20:10 ` Oren Laadan
2009-04-14 21:01 ` Alexey Dobriyan
2009-04-15 19:56 ` C/R without "leaks" (was: Re: Creating tasks on restart: userspace vs kernel) Alexey Dobriyan
2009-04-15 21:38 ` C/R without "leaks" Oren Laadan
2009-04-22 0:16 ` Nathan Lynch
2009-04-15 22:42 ` C/R without "leaks" (was: Re: Creating tasks on restart: userspace vs kernel) Greg Kurz
2009-04-16 16:12 ` Alexey Dobriyan
2009-04-16 18:10 ` C/R without "leaks" Chris Friesen
2009-04-16 18:39 ` Oren Laadan
2009-04-17 9:15 ` Greg Kurz
2009-04-17 9:48 ` Oren Laadan
2009-04-17 12:25 ` Greg Kurz [this message]
2009-04-17 8:46 ` C/R without "leaks" (was: Re: Creating tasks on restart: userspace vs kernel) Greg Kurz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1239971121.6143.217.camel@bahia \
--to=gkurz@fr.ibm.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cfriesen@nortel.com \
--cc=containers@lists.osdl.org \
--cc=dave@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=orenl@cs.columbia.edu \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox