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. 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. > 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. -- Jean-Yves Migeon jeanyves.mig...@free.fr