Containers and PID virtualization [LWN.net]

Containers and PID virtualization

Posted Jan 19, 2006 17:03 UTC (Thu) by swiftone (guest, #17420)
In reply to: Containers and PID virtualization by hingo
Parent article: Containers and PID virtualization

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)

(Log in to post comments)

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.