public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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