“Faster than virtualization, but harder to implement, containers are a promising security technology for Linux. Watch the 2.6.24 kernel for experimental support for creating and managing containers.”
“Faster than virtualization, but harder to implement, containers are a promising security technology for Linux. Watch the 2.6.24 kernel for experimental support for creating and managing containers.”
so this sounds like solaris zones, or maybe BSD jails. I may be wrong though. All of these things kinda remind me of plan9’s namespace separation, and makes me wonder if it would have made a lot of lives easier.
It does indeed sound like Solaris zones. That’d be a very nice addition to Linux.
This isn’t quite solaris zones. This is the groundwork to allow for things like zones. The OpenVZ guys have been very slowly trying to get their code in the upstream kernel. As a result, they rework or generify their code so it works for everything.
It might be another kernel or two before you see full “Solaris Zone” functionality in the Linux kernel. This is a very solid start.
Yes, the goal for this work is an OS-level virtualization solution similar to Zones and OpenVZ/Virtuozzo. The namespaces referred to in the article aren’t per-process as with Plan9 but rather per-container. Or per-subsystem, per-container.
In any case, Linux has had per-process namespace capabilities since the 2.5.x series, courtesy of Al Viro. Kernel developers think they’re cool, but userspace developers haven’t really done anything with them. Union mounts (mounting multiple filesystems at the same mount point) seem more useful, and I believe the work there is still ongoing. The Glick application bundle solution uses a really neat FUSE trick to create process-private filesystems in userspace.
The container solution seems to be coming along nicely and on schedule. This is the sort of thing that shouldn’t be rushed. It’s easy for stuff like this to make a horrible mess of the kernel that developers will be stuck with for years. That’s why it’s important for out-of-tree projects like OpenVZ to make a mess of things so that we can step back, generate some lessons-learned, and figure out how to do this nicely. In the meantime, we already have a commercially-viable OS-virtualization solution that tracks the mainline fairly closely.
and when Debian produces a 2.6.23 kernel then I’ll start to even think about 2.6.24.
Tell me when they get this working.
I’ll be playing in my sandbox.
Linux is an excellent OS under the hood and this just adds to it’s solid design. This feature is fast, secure and a half-way to virtualization. As long as they keep adding useful features, linux will keep ahead of the curve, despite the MS FUD. I hope they continue to develop this feature, put it in the major distros and make it easier use.
A Solaris Container is different than a Zone, a Container is used to limit resources used by a specific process or group of processes. For example, if I wanted to limit the number of CPU’s “seen” by Oracle for licensing reasons, I would use a Container to accomplish this. Read the folloing PDF’s from Oracle and Sun for details:
http://www.oracle.com/corporate/pricing/partitioning.pdf
http://www.sun.com/third-party/global/oracle/consolidation/Containe…
The Computerworld article is talking about making Containers available for Linux, which is an important step in making Linux compete at the same level as Solaris, AIX and HP-UX in the Enterprise arena. From the article:
“Containers” are a form of lightweight virtualization as represented by projects like OpenVZ. While virtualization creates a new virtual machine upon which the guest system runs, containers implementations work by making walls around groups of processes. The result is that, while virtualized guests each run their own kernel (and can run different operating systems than the host), containerized systems all run on the host’s kernel.”
Yes, this is about the equivalent to Solaris’ containers, but the article confuses containers and zones. OpenVZ implements _zones_ (although every guest is running the host’s kernel, its userspace isn’t shared with the host and can even be a different distribution). Now, you can say that containers are actually the underlying technology for zones, so in that case OpenVZ does implement containers.
lwn.net edition from last Thursday (free one) has a good status report on ex-containers. Some parts of code are still in early state of development (network part), so it will be at least 2-3 kernel iterations until this gets ready for upstream.
Overall, it seems to be getting along nicely, support for containerization of much of kernel resources will be very interesting alternative to KVM/Xen etc.
>Faster than virtualization, but harder to implement
Because of an ever-changing environment with ‘so so’ ABIs. Maybe the should first introduce a stable and developer kernel again beforce trying to be professional.
“Because of an ever-changing environment with ‘so so’ ABIs. Maybe the should first introduce a stable and developer kernel again beforce trying to be professional.”
What do you mean? The kernel userspace ABI is very stable (you can run stuff compiled for linux 1.0 on a recent 2.6 kernel, as long as it is statically compiled, that is, since (g)libc has changed a lot since then). Now, the kernel _internal_ ABI isn’t stable, but I don’t see how that affects virtualization/containers…
dont bother with trolls. they trot out the same irrelevant and false/tired arguement at every oppurtunity simply to destroy any real discussion, just look at ANY bsd news on this site. total waste of time.
I was about to say:…
“A. Main-line tree kernel modules that are effected by any ABI change are fixed by the submitter.
B. Non-mainline tree kernel modules are of no interest to the ABI change submitter. (And rightly so)
Now, you may claim that working in a dynamic environment is harder then working in a static one, and you’ll be right – but nobody is forcing the vserver developer’s to do so.
Plus, the number of major ABI breakages is far lower then you imagine/claim. As someone that does maintain a very size-able out-of-tree project, I usually make one fix per 2-4 kernel releases, and unlike other environments (*Cough Windows NDIS *Cough) Linux ABI changes are well documented (LKML, code documentation, etc) in advance.”
… But then I saw this: “beforce trying to be professional.”
– Gilboa
P.S. someone that calld other people unprofessional should -really- consider checking his spelling before going on a rampage.
Edited 2007-11-11 14:27