On Sat, 2015-05-09 at 16:55 +0000, Adrian Otto wrote: > I will also mention that it’s natural to be allergic to the idea of > nested virtualization. We all know that creating multiple levels of > hardware virtualization leads to bad performance outcomes. However, > "nested containers" do not carry that same drawback, because the > actual overhead of a Linux cgroup and Kernel Namespeaces are much > lighter than a hardware virtualization. There are cases where having a > container-in-container setup gives compelling benefits. That’s why > I’ll argue vigorously for both Nova and Magnum to be able to produce > container instances both at the machine level, and allow Magnum to > produce "nested containers” to produce better workload consolidation > density. in a setup with no hypervisors at all.
Actually, it's really important to emphasise that the reason nesting is nasty for hypervisors is because of the HW emulation. Every layer requires HW emulation and a kernel to run it, leading to rapid performance degradation. Containers, on the other hand, are a naturally nesting technology since the hierarchy is simply a management construct within the OS itself (hence no performance degradation once you're already using containers). The traditional way to think about it is, as you say, the container in OS use case emulating the container on hypervisor use case. In practical terms, it's becoming impossible to deploy a modern operating system in a container without nesting. The reason is the world's first containerised application (no, not docker): systemd. Any OS in a container running systemd already has a partially nested hierarchy. This will only magnify as the number of containerised applications grows. The point I'm trying to make is that container nesting isn't a nice side effect, it's an essential requirement ... and one people who deploy virtualization need to become used to thinking about. James __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
