Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422916AbWBIRHk (ORCPT ); Thu, 9 Feb 2006 12:07:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1422917AbWBIRHj (ORCPT ); Thu, 9 Feb 2006 12:07:39 -0500 Received: from gprs189-60.eurotel.cz ([160.218.189.60]:40715 "EHLO spitz.ucw.cz") by vger.kernel.org with ESMTP id S965239AbWBIRGv (ORCPT ); Thu, 9 Feb 2006 12:06:51 -0500 Date: Wed, 8 Feb 2006 21:54:13 +0000 From: Pavel Machek To: "Eric W. Biederman" Cc: Dave Hansen , Kirill Korotaev , Linus Torvalds , Kirill Korotaev , Andrew Morton , Linux Kernel Mailing List , frankeh@watson.ibm.com, clg@fr.ibm.com, greg@kroah.com, alan@lxorguk.ukuu.org.uk, serue@us.ibm.com, arjan@infradead.org, Rik van Riel , Alexey Kuznetsov , Andrey Savochkin , devel@openvz.org, Pavel Emelianov Subject: swsusp done by migration (was Re: [RFC][PATCH 1/5] Virtualization/containers: startup) Message-ID: <20060208215412.GD2353@ucw.cz> References: <43E38BD1.4070707@openvz.org> <43E3915A.2080000@sw.ru> <43E71018.8010104@sw.ru> <1139243874.6189.71.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1485 Lines: 35 Hi! > > Could you explain a bit why the container ID would need to be > > virtualized? > > As someone said to me a little bit ago, for migration or checkpointing > ultimately you have to capture the entire user/kernel interface if > things are going to work properly. Now if we add this facility to > the kernel and it is a general purpose facility. It is only a matter > of time before we need to deal with nested containers. > > Not considering the case of having nested containers now is just foolish. > Maybe we don't have to implement it yet but not considering it is silly. > > As far as I can tell there is a very reasonable chance that when we > are complete there is a very reasonable chance that software suspend > will just be a special case of migration, done complete in user space. > That is one of the more practical examples I can think of where this > kind of functionality would be used. Well, for now software suspend is done at very different level (it snapshots complete kernel state), but being able to use migration for this is certainly nice option. BTW you could do whole-machine-migration now with uswsusp; but you'd need identical hardware and it would take a bit long... Pavel -- Thanks, Sharp! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/