New Features in Clear Containers V2.1.0

Completely re-architected the communication between the host and guest, a prerequisite for many of the features of V2.1.0.
Added support for docker exec. We can now execute a new process inside an already running container.
Execution of docker Run now returns the proper exit status (that of the process within the VM) to the caller.
We now run the container in pid, mount, uts… namespaces inside the VM to isolate the workload from the guest OS.
stdout and stderr are correctly forwarded from the process inside the VM to the host.
We introduced the concept of a POD, enabling Kubernetes® to start Clear Containers via the Container Runtime Interface (CRI-O).
Improvements to networking: a container can now join multiple docker networks as we propagate the full configuration (interfaces, IPs, routes, hostname, ...) to the VM.
User & group support. We respond to directives from Docker to start the containerized workload with a specific user and group, one of the many layers to limit the container permissions.
Added signal support. We now forward signals to the container workload inside the VM:
docker kill works: For instance, we can use SIGHUP to gracefully restart Apache.
Improved TTY handling. For example, typing ctrl+c is correctly sent to the VM and resizing terminals works!

Issues & Limitations

Here’s a list of important issues that one should be aware of and will be addressed in future point releases:

Clear Container V2.1.0 was tested with Docker 1.12.1 and is known not to work with Docker 1.13 (issue #692).
File descriptor leakage in the Docker daemon (issue #616).
Qemu segfault (free(): invalid pointer) running dnf install (issue #669).
Swarm support is incomplete: iptables rules aren’t forwarded to the VM, neither are MTUs. We also have a hard problem to solve with the docker internal DNS proxy listening on a non-routable loopback IP, breaking DNS resolution in Clear Containers. (issue #578).

A more comprehensive list of limitations is available in the Wiki.