From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKDfx-0003DL-AJ for qemu-devel@nongnu.org; Tue, 06 Jan 2009 10:17:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKDfw-0003D0-HT for qemu-devel@nongnu.org; Tue, 06 Jan 2009 10:17:00 -0500 Received: from [199.232.76.173] (port=56252 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKDfw-0003Ct-DQ for qemu-devel@nongnu.org; Tue, 06 Jan 2009 10:17:00 -0500 Received: from mail.sterilesecurity.com ([173.45.227.235]:42272) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LKDfv-0007Ex-U7 for qemu-devel@nongnu.org; Tue, 06 Jan 2009 10:17:00 -0500 Received: from localhost (bzq-79-182-129-25.red.bezeqint.net [79.182.129.25]) by mail.sterilesecurity.com (Postfix) with ESMTPSA id BFFA9C495 for ; Tue, 6 Jan 2009 17:16:57 +0200 (IST) Received: from [127.0.0.1] (oasis [127.0.0.1]) by localhost (Postfix) with ESMTP id 90081365DC8 for ; Tue, 6 Jan 2009 17:17:01 +0200 (IST) Message-ID: <496375ED.6000305@sterilesecurity.com> Date: Tue, 06 Jan 2009 17:17:01 +0200 From: Liraz Siri MIME-Version: 1.0 Subject: Re: [Qemu-devel] simulating a chroot-like interface with qemu References: <496221BB.8010909@turnkeylinux.org> <4963652A.9010306@redhat.com> In-Reply-To: <4963652A.9010306@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Avi Kivity wrote: > All of these (and many more) will be fixed by the namespace work that's > being merged into Linux bit by bit. Good point. I read up a bit on the progress the lxc folks have done since I last checked and it looks like functionality similar to what I am looking for has already been merged into the mainline kernel. The userspace tools are also coming along nicely. Making a super chroot like userspace tool would be much easier with lxc primitives. > You could easily use nfsroot in the guest together with -kernel and > -initrd to load a guest without a block device. With -append and > 'init=' you can have the guest start any script you like. Yep, the basics are there. You just have to tie it all together to make it appear to work transparently. It seems much easier to do this with the lxc primitives, but doing this with qemu still has some benefits (e.g., super chroot into another emulated architecture). Cheers, Liraz