You'd lose out on most of the awesome if you allowed unikernels to run without being kernels, no?

Docker is basically just a fancy chroot. In addition to changing the root directory, it changes the root pid, the set of network devices, the hostname, and a few other things, but at a conceptual level it's not doing anything fundamentally different from what chroot does to a process - it changes some pointers in the kernel's struct for the process. Instead of "root directory" being a global variable in the kernel, each process has a root directory pointer, and chroot changes that. Each process also now has a network-device-list pointer, a hostname pointer, etc., and Docker changes those too.

The flip side is that Docker (unless you're using boot2docker or something) isn't virtualization, so it is basically zero overhead. Running qemu inside Docker is as efficient as running it outside; it's not like nested virtualization or anything.

> Is it possible to do that? Or is the problem that docker inherits the host kernel

Since containers are "merely" sandboxed processes there is no "host"† to speak of and no "inheritance": it's just exactly the current kernel that exec() a process in a highly segregated environment (from mount points to network stack). So obviously that's not possible.

† as opposed to "guest" in VM parlance

The intention is to use the Docker image as a developer SDK rather than downloading and installing the relevant SDKs locally.

For running unikernels -- that is a task left to the user. There is a plethora of information publicly available for working with hypervisors (eg: Hyper-V, Xen, etc), and, as mentioned by other commenters, Docker does not run unikernels.

That would be pointless because a docker container is explicitly everything but the kernel. Just run the unikernel as a vm.

There are use cases where running a unikernel in isolated userspace can be advantageous. I'm building a multitenant routing and packet forwarding framework. The Linux kernel has matured to the point that it can handle routing logic efficiently, without the need for any application to listen for packets. Network namespaces further enable multitenancy of routing and packet forwarding. Of course, it would be nice to launch short-lived, stateless applications like L4-7 load balancers into those namespaces. I would like to use containers for this, because "boot" times are faster than any VM. However in a multitenant environment where security is critical, the greater attack surface of containers worries me. I want to mitigate the situation by running applications in unikernels to minimize the attack surface.

Or am I totally wrong in thinking containers are necessary here? Is the boot time of a VM limited by the kernel on the guest, or the hypervisor on the host? Do unikernels solve the slow boot problem of VM's entirely?

boot times are faster in containers because they don't boot. They're piggy-backing on the host's kernel.