On Tue, 12 Mar 2013 10:57:53 EDT "Joel C. Salomon" <joelcsalo...@gmail.com> wrote: > On Mon, Mar 11, 2013 at 11:52 PM, Bakul Shah <ba...@bitblocks.com> wrote: > > To do something similar you will have to constrain each jail > > to see a subset of processes, give it its own /dev, /env etc. > > Not sure how you do this. > > So long as processes in the jail use /dev, /env, etc., etc., as > inherited from/shared with their parent processes, this seems doable, > if tedious: provide a synthetic file system that shows a limited view > on /dev, /env, etc. > > But the child process can always mount #x for various x, and get out of jail.
The question really is, can we virtualize plan9 machines while staying pretty much within the plan9 framework or by extending it in a way consistent with its design? To fully virtualize plan9 you'd have to virtualize kernel services as well. May be you'd've to dream up a ## service that mediates access to hosts's #services! While one VM has no access to resources of another VM, the parent host or the "hypervisor" does need access to every VM to manage and connect up their resources as needed (for instance connect A and B's serial devices to each other). [Ideally this host is also virtualizable] And it is more than limiting the view; you may have to fabricate a new view! In the networkign example I previously mentioned, we had to provide virtual interfaces of various kinds for each VM where the corresponding physical interfaces didn't exist on the host. You can of course do all this in Qemu/Vbox/VMware etc. but the runtime cost is much higher. And you need to compile code into these emulators if you want to simulate new devices. With plan9 this could be much easier.
