While namespacing allows you to do various things, 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.
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.
> 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.
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.