[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1110111525450.28233@asgard.lang.hm>
Date: Tue, 11 Oct 2011 15:30:25 -0700 (PDT)
From: david@...g.hm
To: "Eric W. Biederman" <ebiederm@...ssion.com>
cc: Theodore Tso <tytso@....EDU>, Matt Helsley <matthltc@...ibm.com>,
Lennart Poettering <mzxreary@...inter.de>,
Kay Sievers <kay.sievers@...y.org>,
linux-kernel@...r.kernel.org, harald@...hat.com, david@...ar.dk,
greg@...ah.com, Linux Containers <containers@...ts.osdl.org>,
Linux Containers <lxc-devel@...ts.sourceforge.net>,
"Serge E. Hallyn" <serge@...lyn.com>,
Daniel Lezcano <daniel.lezcano@...e.fr>,
Paul Menage <paul@...lmenage.org>
Subject: Re: Detecting if you are running in a container
On Tue, 11 Oct 2011, Eric W. Biederman wrote:
> Theodore Tso <tytso@....EDU> writes:
>
>> On Oct 11, 2011, at 2:42 AM, Eric W. Biederman wrote:
>>
>>> I am totally in favor of not starting the entire world. But just
>>> like I find it convienient to loopback mount an iso image to see
>>> what is on a disk image. It would be handy to be able to just
>>> download a distro image and play with it, without doing anything
>>> special.
>>
>> Agreed, but what's wrong with firing up KVM to play with a distro
>> image? Personally, I don't consider that "doing something special".
>
> Then let me flip this around and give a much more practical use case.
> Testing. A very interesting number of cases involve how multiple
> machines interact. You can test a lot more logical machines interacting
> with containers than you can with vms. And you can test on all the
> aritectures and platforms linux supports not just the handful that are
> well supported by hardware virtualization.
but in containers, you are not really testing lots of machines, you are
testing lots of processes on the same machine (they share the same kernel)
> I admit for a lot of test cases that it makes sense not to use a full
> set of userspace daemons. At the same time there is not particularly
> good reason to have a design that doesn't allow you to run a full
> userspace.
how do you share the display between all the different containers if they
are trying to run the X server?
how do you avoid all the containers binding to the same port on the
default IP address?
how do you arbitrate dbus across the containers.
when a new USB device gets plugged in, which container gets control of it?
there are a LOT of hard questions when you start talking about running a
full system inside a container that do not apply for other use of
containers.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists