[Alupis]

> most container setups are vm-replacements, running either full OS or not, they're used for the same purpose in the end (ie resources separation)

No they are not. A VM is a completely different system, while a container is a packaged application.

VM's provide an awful lot more than just resource separation... security and isolation being at the top of the list.

The problem we see here is an awful lot of people think a container is a drop-in replacement for a VM, when it is usually not.

[buster]

> No they are not. A VM is a completely different system, while a container is a packaged application.

I think you have a misunderstanding of terms here, possibly confused by all the fuzz around Docker. A container is nothing more then a virtualization technology on OS level[1]. What you are talking about is something like rkt, which is how to run an app inside a container[2]. From the point of your app there is no difference between a VM, OpenVZ or LXC.

[1] https://en.wikipedia.org/wiki/Operating-system-level_virtual...

[2] https://github.com/coreos/rkt/blob/master/Documentation/app-...

[Alupis]

> What you are talking about is something like rkt, which is how to run an app inside a container

Rocket, and Docker, yes.

> I think you have a misunderstanding of terms here, possibly confused by all the fuzz around Docker

I agree Docker has spread a lot of FUD, causing great confusion about what Docker can do, but also what containers are.

> A container is nothing more then a virtualization technology on OS level[

Not quite. A container was intended to be the first (for linux) truly portable application. You create an application, "containerize" it, then you can run that application on any system with minimal effort (Ubuntu app running on CentOS, etc).

Containers are not virtualizing anything, and that is the entire point. They remove the virtualization/emulation overhead of a hypervisor and instead run your application at native speed on the native system.

Docker has tried to make a do-all application which then provides process isolation and other things to add "Security", but at the end of the day, an app running in a container on your system can still negatively impact other containers and/or the host OS (if your container needs to read/write to /etc for example).

In a VM, everything is isolated because it's literally it's own OS running on (what it thinks is) it's own hardware. An app can destroy the VM, or the VM can be exploited, but nothing outside the VM can be effected.

Xen/KVM have zero comparison to things like Rocket, and Docker.

[zobzu]

that's an incorrect understanding on many levels unfortunately.

About VMs:

A lot uses direct-host-communication-mechanisms such as paio, virtio, etc. These are close to running on-the-host. Them KVM and Xen both have bugs and these can be exploited to reach the host OS as root. Its just that they have a much smaller attack surface.

About namespacing (if we're into nitpicking, let's use the actual tech. name shall we?):

Most namespaces are used to create so-called containers which run entiere OS images (LXC, systemd-nxspawn, Docker, etc. all are used for that by default) in combination with chroot() and other technologies - even thus you can just call namespacing functions within a process or with a limited amount of programs in a chroot.

It does not matter that the kernel is shared, if you bring in your entiere userland, from a user perspective containers == VM. Sure, from a tech. point of view its different, but that's EXACTLY my point - most users use both the same way.

[buster]

> Containers are not virtualizing anything, and that is the entire point.

What is it when a process sees a different process tree, different filesystem tree, different network then the host?

http://man7.org/linux/man-pages/man7/namespaces.7.html

[Alupis]

As the link you provided states, it's called Namespacing.

> A namespace wraps a global system resource in an abstraction thatmakes it appear to the processes within the namespace that they havetheir own isolated instance of the global resource. Changes to theglobal resource are visible to other processes that are members ofthe namespace, but are invisible to other processes. One use ofnamespaces is to implement containers.

Virtualization via hypervisor does a lot more than just namespace isolation.[1]

> The basic idea behind a hypervisor based virtualization is to emulate the underlying physical hardware and create virtual hardware(with your desired resources like processor and memory). And on top of these newly created virtual hardware an operating system is installed. So this type of virtualization is basically operating system agnostic. In other words, you can have a hypervisor running on a windows system create a virtual hardware and can have Linux installed on that virtual hardware, and vice versa.

> So the main basic thing to understand about hypervisor based virtualization is that, everything is done based on a hardware level. Which means if the base operating system (the operating system on the physical server, which has hypervisor running), has to modify anything in the guest operating system(which is running on the virtual hardware created by the hypervisor), it can only modify the hardware resources, and nothing else.

[1] http://www.slashroot.in/difference-between-hypervisor-virtua...