On Sun Jul 11 2010 at 16:49:59 +0200, Jean-Yves Migeon wrote: > On 11.07.2010 15:00, Antti Kantee wrote: > > On Sat Jul 10 2010 at 12:30:07 +0200, Adam Hamsik wrote: > > Given that the idea of jails/zones is to limit a userspace process, > > doing this in a userspace process is not the obvious route. It probably > > could be done with a software-isolated process, but we are desperately > > "not there" with our toolchain. Another choice would be to port rumpuser > > on top of the Xen hypervisor interface, like jym recently envisioned. > > Let me get a bit more precise here :) the purpose is not to offer > container-like virtualization, but rather to have a finer grained > approach, close to microkernels, with small processes/tasks that perform > a specific functionality. What I would like to do is to get rid of the > "big dom0 uber-privileged" domain that you encounter in hypervisor-based > virtualization, by having smaller, isolated domains that perform > specific tasks (one for block device access, another for network, device > driver, so on). Without requiring to integrate > yet_another_monolithic_yet_modular_linux_kernel in.
I didn't mean to say you suggested to offer virtualization containers. Sorry. I merely intended to say you had the desire of using the Xen hypercall interface. Although I must say now I understand more clearly why you wanted to do that. > Frankly, I have no idea how this would perform; basically, dom0 can be > considered as one big uber-privileged domain, which is as critical as > the hypervisor itself; if it crashes, or gets compromised, the system is > entirely crippled. Purpose is to avoid a contamination of the whole dom0 > context if only one of its part is buggy, and one requirement is to get > it as small as possible. "perform"? Are you using that term for execution speed, or was it accidentally bundled with the rest of the paragraph? > > Even so, rump is about virtualizing the kernel, not the user interface > > layer. Given that jails/zones is a well-understood technology with at > > least some sort of NetBSD implementation already done, why not go the > > obvious route and finish that off? > > I think he was referring to using a rump kernel as a "syscall proxy > server" rather than having in-kernel virtualization like jails/zones. > > That would make sense, you already have proxy-like feature with rump. I'm not so sure. That would require a lot of "kernel help" to make everything work correctly. The first example is mmap: you run into it pretty fast when you start work on a syscall server ;) That's not to say there is not synergy. For example, a jail networking stack virtualized this way would avoid having to go over all the code, and "reboot" would be as simple as kill $serverpid. Plus, more obviously, it would not require every jail to share the same code, i.e. you can have text optimized in various ways for various applications.
