Weekly Edition
Return to the Kernel page
| |||||||||||||
CRtools 0.1 released
The OpenVZ blog has the announcement of the
release of CRtools 0.1. "It is our ultimate goal to merge all bits
and pieces of OpenVZ to the mainstream Linux kernel. It's not a big secret
that we failed miserably trying to merge the checkpoint/restore [CPT] functionality (and yes, we have tried more than once). The fact that everyone else failed as well soothes the pain a bit, but is not really helpful. The reason is simple: CPT code is big, complex, and touches way too many places in the kernel.
So we* came up with an idea to implement most of CPT stuff in user space,
i.e. as a separate program not as a part of the Linux kernel. In practice
this is impossible because some kernel trickery is still required here and
there, but the whole point was to limit kernel intervention to the bare
minimum. Guess what? It worked even better that we expected. As of today, after about a year of development, up to 90% of the stuff that is needed to be in the kernel is already there, and the rest is ready and seems to be relatively easy to merge."
(Log in to post comments)
CRtools 0.1 released Posted Jul 24, 2012 23:08 UTC (Tue) by ntl (subscriber, #40518) [Link]
Speaking as someone who has participated in other C/R efforts (at least we soothed the pain :-), congratulations to the OpenVZ team on this milestone.
Future of OpenVZ? Posted Jul 24, 2012 23:33 UTC (Tue) by dskoll (subscriber, #1630) [Link] I hope this bodes well for the future of OpenVZ. We have a number of OpenVZ machines running on Debian hosts. Unfortunately, it looks like Debian is phasing out OpenVZ in favor of LXC. I've only played with LXC a little, but the user-space tools are nowhere near as good as OpenVZ and unless you're careful, you don't get as good guest/host isolation. So... what's the word? Does OpenVZ have a future or are we doomed to LXC?
Future of OpenVZ? Posted Jul 25, 2012 12:09 UTC (Wed) by Lennie (subscriber, #49641) [Link]
I think the goal is to get as much of OpenVZ in the mainline Linux kernel, that should reduce the effort the OpenVZ developers have to do to maintain it.
If only because the OpenVZ developers can use part of the in-kernel functions LXC also uses, this will reduce the OpenVZ code base.
If that means that the OpenVZ user-space tools will end up just as a wrapper around LXC-API for compatibility or easier management, because LXC can do everything OpenVZ can do, I don't know.
Future of OpenVZ? Posted Jul 25, 2012 12:49 UTC (Wed) by dskoll (subscriber, #1630) [Link] OK. I guess I should go post on a Debian forum... AFAIK, they're dropping OpenVZ support for Wheezy. At the same time, LXC is nowhere near ready for production use, so... ouch.
Future of OpenVZ? Posted Jul 25, 2012 16:43 UTC (Wed) by drag (subscriber, #31333) [Link]
I believe the OpenVZ developers are involved in LXC in some manner.
Something like LXC is the bits that the OpenVZ people have been able to merge. Or something like that. A 'vanilla' version of OpenVZ so-to-say.
I am not sure about this as it's been a while since I looked into it.
Future of OpenVZ? Posted Jul 26, 2012 3:17 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] That's right, OpenVZ will not be in wheezy. The Debian kernel team generally tries to avoid adding features without upstream support, and the OpenVZ project has not had the resources to support stable kernel branches other than one based on RHEL (I think bug #655385 illustrates the problem - and note that the fix for that is pending!). I would expect that OpenVZ's own kernel packages based on RHEL will be usable with a squeeze or wheezy userland.
Future of OpenVZ? Posted Aug 1, 2012 1:01 UTC (Wed) by lurdan (subscriber, #77641) [Link]
> I would expect that OpenVZ's own kernel packages based on RHEL will be usable with a squeeze or wheezy userland.
This is exactly what proxmox ve does. (http://pve.proxmox.com)
Future of OpenVZ? Posted Jul 26, 2012 23:51 UTC (Thu) by dowdle (subscriber, #659) [Link]
The solution is simple... if Debian is dropping OpenVZ support... and they do have a good reason... don't use Debian as your host node distro.
OpenVZ dropped all of the non-RHEL-based branches... some time ago... and while the Debian folks have been maintaining their own OpenVZ branch... there have been bugs and feature differences to the degree that I think the recommendation has been to actually use the RHEL-based OpenVZ kernel on Debian host nodes. The problem comes in with newer Debian releases may not be compatible with the current RHEL-based branches.
For those who really want to run Debian on their OpenVZ host node, perhaps a RHEL7-based OpenVZ kernel (very speculative) from the future will work. :)
Future of OpenVZ? Posted Jul 27, 2012 15:39 UTC (Fri) by dskoll (subscriber, #1630) [Link] The solution is simple... if Debian is dropping OpenVZ support... and they do have a good reason... don't use Debian as your host node distro. The solution is not that simple. All of our management tools and scripts assume Debian. I haven't used a RedHat-like distro in years, so I'd have to learn all the new management and packaging tools, modify my scripts, etc. It's not so easy to change a major thing like a distro. I realize OpenVZ has problems, but this decision means Debian Wheezy won't have a viable container system. They dropped Linux-VServer a while back and now they're dropping OpenVZ in favour of LXC, but LXC is nowhere near ready. :(
Future of OpenVZ? Posted Jul 30, 2012 8:04 UTC (Mon) by kolyshkin (subscriber, #34342) [Link]
You can use OpenVZ RHEL6-based kernel on Debian:
http://wiki.openvz.org/Install_kernel_from_RPM_on_Debian_6.0
Future of OpenVZ? Posted Jul 30, 2012 7:54 UTC (Mon) by kolyshkin (subscriber, #34342) [Link]
We feel your pain. And here are some good news: we are porting vzctl to be able to run on top of non-openvz kernel. That way, you won't get as good isolation and as much features as with OpenVZ kernel, but you will have basic functionality with a familiar and decent userspace tool.
The other thing is, we will provide DEB repository with our kernels so you'll be able to use it.
Future of OpenVZ? Posted Jul 31, 2012 16:40 UTC (Tue) by emmi3 (subscriber, #62443) [Link]
Even now I wouldn't recommend using Debian (Squeeze) as OpenVZ Host. We had some serious problems;
- CPU limits don't work. This was a known upstream OpenVZ-bug which was later on fixed, but this fix could not easily be backported to the (near vanilla) 2.6.32 Debian kernel, since OpenVZ-upstream only developes for the (far from vanilla) 2.6.32 RedHat kernel. (And Redhat does not release seperate patches anymore). IoW: in fact hardly any OpenVZ-upstream fixes can flow into Debian right now, so I would prefer if Debian would officially state that they cannot support OpenVZ anymore right now not only for wheezy. - Occasionally one guest would rum amok and only a reboot of the *host* would help. It was "fun" moving all the other guests to different hosts.
Even though we use only debian for everything else, it was decided to switch all the OpenVZ-hosts to Sientific Linux. This switch ist not quite complete yet, but a colleague said: "Now OpenVZ is fun again".
CRtools 0.1 released Posted Jul 25, 2012 0:16 UTC (Wed) by theophrastus (guest, #80847) [Link]
so OpenVZ is vaguely similar in functionality to VMWare or Xen. but unlike VMWare runs 'only' linux images (can't switch to windows to play some windows only video game). so, (if i didn't already louse-up that much), what's a couple of practical reasons one would want to do that? security? testing security? swapping active web-servers for updates? proper (GPL) licensing? i'm honestly curious. (thankee!)
CRtools 0.1 released Posted Jul 25, 2012 0:32 UTC (Wed) by price (subscriber, #59790) [Link]
The major advantages are about efficiency.
* You have only one kernel, so you're not duplicating the work and memory usage of the kernel.
* You have one memory manager, one scheduler, and one filesystem implemenation, so you can use resources more completely without having to give each VM an overallocation.
* You have one filesystem implementation (and one page cache), so you can give each VM a snapshot of a common filesystem and not duplicate all the system files (and not duplicate the in-memory cache of each of those files either.)
* When you create a new VM, its base system is already a filesystem snapshot and even its kernel is already running, so it comes up very quickly.
You can read more on the OpenVZ wiki: http://wiki.openvz.org/Introduction_to_virtualization or in marketing-speak at the page for Parallels Virtuozzo Containers for Linux, which is the commercial version from the primary sponsors of OpenVZ: http://www.parallels.com/products/pvc/#c2697
CRtools 0.1 released Posted Jul 25, 2012 0:52 UTC (Wed) by theophrastus (guest, #80847) [Link]
I fear you've over-estimated the crude level of my question. I have a single image of linux running in front of me now, and it (more or less) fulfills each of those bullet points of yours. Perhaps if i rephrase: if one can switch between multiple linux kernels (all much alike) what practical uses can one put them to? (as opposed to a rack of clustered servers, for example)
CRtools 0.1 released Posted Jul 25, 2012 1:41 UTC (Wed) by price (subscriber, #59790) [Link]
These advantages are in comparison to other forms of virtualization, like VMware or Xen (which your original post did mention.) If you're happy with a single image of Linux, then it's almost all moot. (You might still like, say, migration.)
Many people find they want to supply root-on-a-Linux-box to multiple mutually-untrusting users; VMware, Xen, and OpenVZ are all ways to do that (among other use cases.) Broadly, enterprises seem to like VMware, giant cloud providers Xen, and web hosters with their razor-thin margins like OpenVZ or its commercial version.
CRtools 0.1 released Posted Jul 25, 2012 1:46 UTC (Wed) by TRS-80 (subscriber, #1804) [Link] Who uses KVM then? Linux shops? REHV?
CRtools 0.1 released Posted Jul 25, 2012 1:53 UTC (Wed) by theophrastus (guest, #80847) [Link]
and, dammit [wink], what specific use of they making of these? give me the name of a program/process/"application" that one is running in one image and another name (which i suppose could be the same) that's running in another image and how that's useful relative to just two processes in a single image.
(thankee!) (just trying to understand how multiple kernel images that are nearly the same are used)
CRtools 0.1 released Posted Jul 25, 2012 2:09 UTC (Wed) by dskoll (subscriber, #1630) [Link] OpenVZ containers are quite isolated. So you can give someone root in one container and that doesn't allow him/her any access in another container or in the host system (barring bugs, of course.) You can also apply resource limits to OpenVZ containers so a fork bomb in one container doesn't bring down the system or affect other containers. OpenVZ is analogous to Solaris Zones with similar use cases.
CRtools 0.1 released Posted Jul 25, 2012 2:55 UTC (Wed) by theophrastus (guest, #80847) [Link]
ah. so it's "security". protecting the system (as a whole) against users who have root access. thank you! i think that answers my question as well as i've been able to express it.
CRtools 0.1 released Posted Jul 25, 2012 12:17 UTC (Wed) by Lennie (subscriber, #49641) [Link]
It is like chroot yes.
LXC is a bit more flexible in what it can be I believe, but normally OpenVZ, Linux V-Server and other are like a seperate process- and filesystem-namespace with sometimes a seperate network stack (in the case of the filesystem, that just means, each container is a seperate directory).
Or as Jonathan Corbet described it on this site:
"Containers" can be thought of as a lightweight form of virtualization. Virtualized guests appear to be running on their own dedicated hardware; containers, instead, run on the host's kernel, but in an environment where they appear to have that kernel to themselves. The result is more efficient; it is typically possible to run quite a few more containerized guests than virtualized guests on a given system. The cost, from the user's point of view, is flexibility; since virtualized guests can run their own kernel, they can run any operating system while containerized guests are stuck with what the host is running."
CRtools 0.1 released Posted Jul 25, 2012 15:04 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
> So you can give someone root in one container and that doesn't allow him/her any access in another container or in the host system (barring bugs, of course.)
You can't give root to A in a container and access to the filesystem from the main system as any user. Simply make a suid executable in the container and execute from the main system. Unless uids are jailed as well (and appear on disk as some offset from "root" permissions).
CRtools 0.1 released Posted Jul 25, 2012 16:22 UTC (Wed) by josh (subscriber, #17465) [Link]
Containers handle UIDs, yes; root in a container does not necessarily correspond to root in the parent container.
CRtools 0.1 released Posted Jul 25, 2012 2:30 UTC (Wed) by cmccabe (guest, #60281) [Link]
You can think of openVZ and lxc as better versions of chroot. Unlike chroot, they were designed to be secure against root inside the container.
I know that shared hosting providers use openVZ to give multiple users accounts on the same machine that look like root, but which can't interfere with the other users too much.
You could use virtual machines for the same thing, but it isn't as efficient. The main advantage is that with VMs you can offer Windows hosting, or hosting on more than one Linux kernel version.
I don't know exactly why Amazon still uses Xen instead of KVM, but I think at least part of it has to do with the fact that Xen came out first.
CRtools 0.1 released Posted Jul 25, 2012 2:00 UTC (Wed) by miguelzinho (subscriber, #40535) [Link]
Google Compute Engine
https://developers.google.com/compute/docs/faq#whatisgoog...
CRtools 0.1 released Posted Jul 25, 2012 9:32 UTC (Wed) by robert_s (subscriber, #42402) [Link]
It's probably best not to think of it as a desktop virtualization thing. Think cloud providers/IaaS. In theory someone like Amazon could use this type of virtualization on AWS and allow users to run pretty much any linux userspace they like (as long as it's compatible with the [single] running kernel) and waste a lot less memory. And cause a much smaller performance hit.
CRtools 0.1 released Posted Jul 25, 2012 16:24 UTC (Wed) by raven667 (subscriber, #5198) [Link]
> * You have only one kernel, so you're not duplicating the work and memory usage of the kernel.
One other point is that a single kernel can make much better scheduling decisions for processes across multiple CPU cores than for virtualized SMP blobs. To run a vSMP blob you have to clear the decks on the assigned CPU cores, reset them to an expected state and then give exclusive access to the VM for its time slice, without really knowing what its doing.
CRtools 0.1 released Posted Jul 25, 2012 9:45 UTC (Wed) by gebi (subscriber, #59940) [Link]
Thats really good news, congrats!
Though for most of us checkpoint/restart is the least interesting feature about OpenVZ. We'd just hope for a usable container solution which is both root save and has decent userspace tool support, AND a method to join the container from the host! Most of where LXC is just crap.
Beside that, nothing fancy like container in container support, or anything else, just a way to easily separate services on linux, like solaris zones. The thing that makes me sad is, that imho 95% of the infrastructure is already in place in the linux kernel for basic and secure container. And currently there are only out of tree implementation making it usable, openvz and oracle (solaris) zones, afaik in their kernel.
CRtools 0.1 released Posted Jul 25, 2012 12:27 UTC (Wed) by Lennie (subscriber, #49641) [Link]
This also went into 3.5:
"A new approach to user namespaces"
http://lwn.net/Articles/491310/
"user namespace enhancements for Linux 3.5-rc1"
http://thread.gmane.org/gmane.linux.kernel.containers/23229
Wouldn't that help to make it rootsave ? As you called it.
I think the real reason why LXC isn't such a complete solution yet, is because what goes into the kernel has to be maintained for a very long time and LXC will end up "virtualizing" a lot of parts of the kernel, so the developers want to only allow small/understandable changes each time.
It's the reason Linux V-Server, OpenVZ and I believe there was an other ? aren't already part of the kernel. The developers would never allow one big patch to add such functionality.
So every in-kernel API needs to be proposed and tweaked until it is ready and allowed into the kernel.
The theory is that each part will be better and more generalized than the independently developed ideas. If I'm not mistaken, LXC can already do a lot of things OpenVZ can't.
This takes time, but with almost each release it gets closer to 100%.
CRtools 0.1 released Posted Jul 25, 2012 12:36 UTC (Wed) by Lennie (subscriber, #49641) [Link]
Also if you are reading lwn.net you are probably a developer, if you don't like the userspace tools.
You could propose changes or even help develop/improve them.
I would love to see someone add the ability to run lxc-execute on a running container.
CRtools 0.1 released Posted Jul 25, 2012 15:17 UTC (Wed) by gebi (subscriber, #59940) [Link]
OpenVZ tools and management framework already exists and works quite well. But afaik they talked about being able to administer a reduced functionality OpenVZ which just uses lxc in the kernel.
Seems the only thing missing is really the join container functionality. But there afaik is the problem with lxc allowing containers inside containers.
CRtools 0.1 released Posted Jul 25, 2012 13:40 UTC (Wed) by slashdot (guest, #22014) [Link]
What's the point of "separating services into containers"?
Assuming no kernel bugs, the Linux security model will guarantee security within the same container, assuming you have an unique uid per service, or use SELinux or similar, so there's no advantage in using containers.
If kernel bugs are present, then using containers or not again makes no difference since exploiting a bug within a container gives you full access to kernel mode and thus root in all containers.
Hardware-level virtualization is a different matter though and can in principle improve security.
CRtools 0.1 released Posted Jul 25, 2012 15:12 UTC (Wed) by dskoll (subscriber, #1630) [Link] What's the point of "separating services into containers"? It can make the sysadmin's life easier. For example, we run our CRM tool in a container. When I want to upgrade it, I clone the entire container and run a test upgrade in the isolated environment. Similarly, I can upgrade the Debian release in a test container before doing it for real. It can be very convenient to have completely isolated user-spaces (and not just for security.)
CRtools 0.1 released Posted Jul 25, 2012 15:14 UTC (Wed) by gebi (subscriber, #59940) [Link]
> What's the point of "separating services into containers"?
What's the point of chroot?
In the end it's all about separation.
Some services are really bad in separation, be it syslog configuration of all the daemons, network configuration for additional ip addresses for the different services or even the reducing of necessary configuration!
As you see there are a _whole_ lot of reasons to split up services.
> Assuming no kernel bugs...
Assuming the earth is flat has about the same probability of being right.
> Hardware-level virtualization is a different matter though and can in principle improve security.
openVZ has near zero overhead both in terms of speed and resource usage.
CRtools 0.1 released Posted Jul 25, 2012 16:52 UTC (Wed) by drag (subscriber, #31333) [Link]
> What's the point of "separating services into containers"?
It makes root a unprivileged user. This allows you to separate application domains in a much more meaningful way then without containers.
It performs this through the use of namespace isolation. Unique set of namespaces provided by the kernel. Network namespaces, file system, uids, pids, etc.
With LXC and others you can choose your level of isolation also. You can run your browser with read-only file system support or a different home directory then the rest of your applications without having to use different users. Or you can isolate the browser entirely or whatever.
Combine that with SELinux or whatever and you can sandbox applications in a secure manner without having to change their code.
> Hardware-level virtualization is a different matter though and can in principle improve security.
No it can't.
If you are using virtualization to improve security you are doing it wrong.
Virtualization is about lowering administrative overhead and reducing hardware costs, among other things. It's not about improving security. People that say virtualization is for improving security are either trying to sell you on something or they don't really understand how security works.
If you have a security issues with buggy code throwing more code at the problem isn't probably going to help much. This is what virtualization does...
CRtools 0.1 released Posted Jul 25, 2012 18:07 UTC (Wed) by jmnovak (subscriber, #48627) [Link]
Surely saying that virtualization is not about improving security is an overstatement... The idea of virtualization for improving security is understanding that there *will* be security bugs in any sufficiently complex system, so limiting the damage those bugs can cause is an effective security measure (one of many, per layered defense doctrine). This is one of the concepts behind, say, Qubes-OS. As a general user, I employ a weaker form of this; I do the bulk of my web browsing on my home system from a virtual machine with a minimal OS from a read-only filesystem that I reset before and after transactions with sensitive information; surely this improves *my* security, though it naturally can't make the apps or services themselves any more secure. While it should still be possible to attack the rest of the system in this kind of setup, the attack surface is reduced, and many kinds of common security flaws are circumvented. Qubes takes this much further, with some of the key system components (e.g. networking) in their own VM contexts. The Qubes developers also argue that a smaller common base (Xen) can also be audited more thoroughly than an entire kernel, which I'm guessing is an advantage over containers; I haven't seen an analysis by the Qubes folks specifically addressing the containers approach.
Are there better approaches? Quite possibly; but it's certainly easy to implement a VM approach, and can be a major component of a total security policy.
--John N.
|
|||||||||||||