3 ms·

Unikernels are awesome. But it looks like these are docker images for building unikernels, not running the unikernel itself using docker tooling. Is it possible

Unikernels are awesome. But it looks like these are docker images for building unikernels, not running the unikernel itself using docker tooling. Is it possible to do that? Or is the problem that docker inherits the host kernel and therefore you need to run the unikernel inside qemu inside docker? Is there any way to avoid this extra layer of virtualization so that you can run unikernels with docker tooling?

empath75 10y ago
That would be pointless because a docker container is explicitly everything but the kernel. Just run the unikernel as a vm.
- chatmasta 10y ago
  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?
  - empath75 10y ago
    boot times are faster in containers because they don't boot. They're piggy-backing on the host's kernel.
- deleted 10y ago
  [deleted]
lloeki 10y ago
> 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
ihsw2 10y ago
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.
geofft 10y ago
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.

empath75 10y ago

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

chatmasta 10y ago
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?
- empath75 10y ago
  boot times are faster in containers because they don't boot. They're piggy-backing on the host's kernel.
deleted 10y ago
[deleted]

lloeki 10y ago

> 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

ihsw2 10y ago

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.

geofft 10y ago

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.