Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932305AbWBFTa6 (ORCPT ); Mon, 6 Feb 2006 14:30:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932301AbWBFTa6 (ORCPT ); Mon, 6 Feb 2006 14:30:58 -0500 Received: from mailhub.sw.ru ([195.214.233.200]:27470 "EHLO relay.sw.ru") by vger.kernel.org with ESMTP id S932309AbWBFTa5 (ORCPT ); Mon, 6 Feb 2006 14:30:57 -0500 Message-ID: <43E7A447.2090601@sw.ru> Date: Mon, 06 Feb 2006 22:32:23 +0300 From: Kirill Korotaev User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: "Eric W. Biederman" CC: Dave Hansen , 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: Re: [RFC][PATCH 1/5] Virtualization/containers: startup References: <43E38BD1.4070707@openvz.org> <43E3915A.2080000@sw.ru> <43E71018.8010104@sw.ru> <1139243874.6189.71.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1439 Lines: 28 > 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. Fully virtualized container is not a matter of virtualized ID - it is the easiest thing to do actually, but a whole global problem of other resources virtualization. We can ommit ID for now, if you like it more. > 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. No one told that it is not considered. In fact PID virtualization send both by IBM/us is abstract and doesn't care whether containers are nested or not. > 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. Kirill - 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/