| |||||||||||||
Containers and PID virtualizationContainers and PID virtualizationPosted Jan 19, 2006 10:03 UTC (Thu) by hingo (guest, #14792)Parent article: Containers and PID virtualization Just a curious uninformed question, what does this really offer that cannot be done with UML or Xen? Aside from possible performance enhancements and such. I mean I do understand how it's different technically, but if it's so much trouble and invasive on others, what's the real benefit?
(Log in to post comments)
Containers and PID virtualization Posted Jan 19, 2006 11:26 UTC (Thu) by eru (subscriber, #2753) [Link] > Just a curious uninformed question, what does this really offer that cannot be done with UML or Xen?Is UML even developed any more these days? Looking at its home page, it seems to talk about 2.4 kernels, like here: http://user-mode-linux.sourceforge.net/dl-sf.html Anyway, getting these isolated containers without having many copies of the kernel is probably a big enough performance enhancement to be worth the trouble.
Containers and PID virtualization Posted Jan 19, 2006 14:49 UTC (Thu) by Segora (subscriber, #8209) [Link] > Is UML even developed any more these days?
UML is included in 2.6 kernels and seems to be actively developed, see also the UML diary[1].
Segora
Containers and PID virtualization Posted Jan 22, 2006 8:38 UTC (Sun) by xorbe (subscriber, #3165) [Link] Just look further down that page, it says to look athttp://www.user-mode-linux.org/~blaisorblade/ for 2.6.9+ updates (which it has through 2.6.15)
Containers and PID virtualization Posted Jan 19, 2006 14:05 UTC (Thu) by smoogen (subscriber, #97) [Link] The future part of this that would seem to be useful would be the cluster aspects.
Machine A detects a system fault and is going to shutdown
A tells the cluster manager(s) it has these containers that need to be moved.
The cluster manager finds another machine (machine C and D) and tells Machine A
Machine A and C/Cdo the needed process handover and containers start running on C/D.
Machine A shutsdown.
[Of course this may be possible with Xen, but it would seem to be a heavier solution with the fact that C/D would then need to instantiate and start a new sub-kernel process and every other sub-process (nfs, etc) that was in the old Xen.]
Containers and PID virtualization Posted Jan 19, 2006 17:03 UTC (Thu) by swiftone (guest, #17420) [Link] what does this really offer that cannot be done with UML or Xen?I'm hardly an expert, but I'll post my understanding here so that if I'm wrong someone can point it out to me :) Xen, as far as I know, runs a virtual machine within the kernal (okay, it's not a virtual machine in the VMware sense, but that's the concept). A container is a collection of processes that are aware of each other. Basically, Xen is the kernel, and the container is the processes RUNNING on the kernel. If you have a series of long-running processes that can grow in memory/CPU usage, conventional load-balancing techniques won't help you at all. This would let you move some of those processes to other machines. (or perhaps to another CPU on the same machine...LWN didn't mention anything about threads). Heck, this could give you a "suspend-to-disk" method that would let you take your work from machine to machine. Imagine carrying a USB drive with your work container on it, and being able to load up that container on whatever linux system you're at. (although Xen probably can/will do something similar to that, except that it'd have to carry your whole OS with it)
Containers and PID virtualization Posted Jan 24, 2006 21:44 UTC (Tue) by zblaxell (subscriber, #26385) [Link] If I make a few assumptions about process migration:
1. A container cannot be divided--all of its processes move, or none.
2. Moving a container is transparent--the processes have the same open files and network sockets when they arrive at their destination
then there's very little difference between a VM and a migratable process container. A plain process container isn't sufficient--you'd need to keep file descriptors, memory maps, and a bunch of other state to make migration work. VM's have all that, but need nothing else since they can defer the rest to their host kernel.
I suspect that the cost/capability curves of "light VM" and "heavy process container" will intersect each other at some point. The nice thing about VM's is that they start off isolated from the kernel and gradually intrude into the kernel, while process containers start out intrusive and gradually become less intrusive.
|
|||||||||||||