LWN.net Logo

LCE: The failure of operating systems and how we can fix it

LCE: The failure of operating systems and how we can fix it

Posted Nov 15, 2012 21:31 UTC (Thu) by naptastic (subscriber, #60139)
Parent article: LCE: The failure of operating systems and how we can fix it

Parallels is the company responsible for the travesty of horrors that is Plesk.

The hosting company I work for (who shall remain nameless) uses OpenVZ for virtual servers. It is wholly inadequate and we have begun transitioning to KVM.

It's still trivial to forkbomb a container running the VZ kernel and take down the whole host. The container model also requires a number of really, really annoying limits (shared memory, locked memory, open files, total files, TCP sockets, total sockets, and on and on) that have to be there because of the fundamental weakness of the container model.

You can get around that by using a container just for one thing, but then you still have to have full operating system just for that one thing. If I want to have memcache by itself in a container, I need a full file system and Linux install to support it. You lose some overhead by using a container instead of a hypervisor, then get it all right back plus some with the requirements of containment.

The only advantage I can see is that you can update the hardware configuration in realtime. Other than that, use cgroups or use full virtualization.


(Log in to post comments)

LCE: The failure of operating systems and how we can fix it

Posted Nov 16, 2012 9:11 UTC (Fri) by kolyshkin (subscriber, #34342) [Link]

I am really sorry for you negative experience with travesty of horrors. Nevertheless, this product has no common roots (or common developers, managers etc) with OpenVZ, so this is hardly relevant.

> It's still trivial to forkbomb a container running
> the VZ kernel and take down the whole host.

If that would be true, all the hosting service providers using VZ (i.e. a majority of) would go out of business very soon. If CT resources (user beancounters) are configured in a sane way (and they are configured that way by default -- so unless host system administrator removes some very vital limits), this is totally and utterly impossible.

So, let's turn words into actions. I offer you $100 (one hundred US dollars) for demonstrating a way to bring the whole system down using a fork bomb in OpenVZ (or Virtuozzo, for that matter) container. A reproducible description of what to do to achieve it is sufficient.

> The container model also requires a number of really, really annoying limits

I can feel your pain. Have you ever heard of vswap? Here are some 1-year-old news for you?
- https://plus.google.com/113376330521944789537/posts/5WEzA...
- http://wiki.openvz.org/VSwap

In a nutshell, you only need to set RAM and SWAP for container, and keep the rest of really, really annoying limits unconfigured.

> because of the fundamental weakness of the container model

Could you please enlighten us on what exactly is this fundamental weakness?

> You can get around that

Now, I won't be commenting on the rest of your entry because it is based on wrong assumptions.

LCE: The failure of operating systems and how we can fix it

Posted Nov 20, 2012 1:40 UTC (Tue) by exel (subscriber, #87380) [Link]

I think a lot of people still associate OpenVZ with Plesk/Virtuozzo. I must admit I haven't seen where that stuff has been going, but 6 years ago it was all pretty horrible.

There is, at the core of OpenVZ, something that seems absolutely elegant and useful – a more isolating take on the FreeBSD jail concept, which itself was of course chroot on acid. Using it for advanced process isolation looks like a sensible application. The _typical_ application of OpenVZ, in the field right now, though, is that of a poor man's hypervisor. I think that a container technology is just the wrong approach for this.

The big elephant in the room, for me, is security isolation. Containers all run under the same kernel, which means that a kernel compromise is a compromise of all attached security domains. An actual hypervisor setup adds an extra privilege layer that has to be separately broken.

Again, this doesn't mean that OpenVZ cannot be tremendously useful. The most visible way Parallels is selling the technology, however, is not what people are looking for. This pans out in the market place.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds