| |||||||||||||
LCE: The failure of operating systems and how we can fix itLCE: The failure of operating systems and how we can fix itPosted Nov 16, 2012 9:11 UTC (Fri) by kolyshkin (subscriber, #34342)In reply to: LCE: The failure of operating systems and how we can fix it by naptastic Parent article: LCE: The failure of operating systems and how we can fix it
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
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?
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.
(Log in to post comments)
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.
|
|||||||||||||